[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions toOSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt
Thanks Acee,
That does the job.
Adrian
----- Original Message -----
From: "Acee Lindem" <acee at redback.com>
Cc: "CCAMP List" <ccamp at ops.ietf.org>; "OSPF List" <ospf at ietf.org>
Sent: Sunday, April 06, 2008 12:15 PM
Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions
toOSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt
> Alan Davey pointed out that I was missing the word "is" in my text. I
> went ahead with a more verbose explanation of the protocol differences.
>
> ***************
> *** 342,348 ****
> The Link TLV describes a single link and consists of a set of sub-
> TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID
> sub-
> TLV are applicable to OSPFv3. The Link ID sub-TLV can't be
> used in
> ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3.
>
> Three new sub-TLVs for the Link TLV are defined:
>
> --- 342,356 ----
> The Link TLV describes a single link and consists of a set of sub-
> TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID
> sub-
> TLV are applicable to OSPFv3. The Link ID sub-TLV can't be
> used in
> ! OSPFv3 since it is defined to use the OSPFv2 identification for the
> ! Designated Router (DR) on multi-access networks. In OSPFv2,
> ! neighbors on point-to-point networks and virtual links are
> identified
> ! by their Router IDs while neighbors on broadcast, Non-Broadcast
> ! Multi-Access (NBMA), and Point-to-Multipoint links are
> identified by
> ! their IPv4 interface addresses (Refer to section 8.2 in [OSPFV2]).
> ! The IPv4 interface address is not known to OSPFv3. In contrast to
> ! OSPFv2, OSPFv3 always identifies neighboring routers by their
> Router
> ! IDs (Refer to section 2.11 in [OSPFV3]).
>
> Three new sub-TLVs for the Link TLV are defined:
>
> ***************
>
>
> On Apr 5, 2008, at 12:51 PM, Acee Lindem wrote:
>
>> Adrian,
>>
>> How's this:
>>
>> ***************
>> *** 342,348 ****
>> The Link TLV describes a single link and consists of a set of
>> sub-
>> TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID
>> sub-
>> TLV are applicable to OSPFv3. The Link ID sub-TLV can't be
>> used in
>> ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3.
>>
>> Three new sub-TLVs for the Link TLV are defined:
>>
>> --- 342,351 ----
>> The Link TLV describes a single link and consists of a set of
>> sub-
>> TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID
>> sub-
>> TLV are applicable to OSPFv3. The Link ID sub-TLV can't be
>> used in
>> ! OSPFv3 since it defined to contain the IPv4 address of the
>> Designated
>> ! Router (DR) for multi-access interfaces. In contrast to OSPFv2,
>> ! OSPFv3 always identifies a neighboring router by the Router ID
>> (Refer
>> ! to section 2.11 in [OSPFV3]).
>>
>> Three new sub-TLVs for the Link TLV are defined:
>>
>> ***************
>>
>> I plan to wait until the WG last call has completed to submit the
>> update.
>> Thanks,
>> Acee
>>
>> On Apr 5, 2008, at 11:50 AM, Acee Lindem wrote:
>>
>>> Hi Adrian,
>>>
>>> Thanks for the review.
>>>
>>> On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote:
>>>
>>>> Hi,
>>>>
>>>> Just a couple of comments...
>>>>
>>>> ===
>>>> Section 1
>>>> s/proposes the addition of/defines/
>>>
>>> Changed.
>>>
>>>
>>>> ===
>>>> Section 4
>>>> Forgive me for not remembering this discussion...
>>>> The draft says that we cannot use the Link ID sub-TLV "due to the
>>>> protocol
>>>> differences."
>>>
>>> The link-ID is cannot be used since, in the case of multi-access
>>> network, it contains the IPv4 address of the Designated Router (DR).
>>> OSPFv3 doesn't have this information.
>>>
>>>
>>>> It then says that the Link ID sub-TLV SHOULD NOT be included
>>>> (implying that
>>>> it MAY be included under certain circumstances) but MUST be ignored.
>>>
>>> This is the spirit of being conservative in what one sends and
>>> liberal in what one excepts.
>>>
>>>
>>>
>>>> 1. Does ignored mean "continue to be flooded" or "stripped from the
>>>> LSA"?
>>>
>>> In OSPF, only the originator should modify an LSA. So, it means
>>> neither.
>>>
>>>
>>>
>>>> 2. Is it not possible to consider operating a GMPLS control plane
>>>> in an IPv6
>>>> network where the routers use IPv6 addresses to communicate (so all
>>>> control
>>>> plane messages will be addressed using IPv6, and the router address
>>>> will be
>>>> IPv6 as described in Section 3) but where the data channel
>>>> identifiers are
>>>> assigned from an IPv4 address space? Recall that in GMPLS the
>>>> interfaces
>>>> used for OSPF exchange are not those used for data exchange.
>>>
>>> I believe it is probable that IPv4 and IPv6 will coexist. However,
>>> OSPFv3 doesn't know the IPv4 address of the DR (at least it is not
>>> standardized). Hence, this isn't the right sub-TLV to reflect this
>>> topology.
>>>
>>>
>>>
>>>>
>>>> Whatever the answers, I think it would help if the reasons were
>>>> clarified
>>>> beyond "protocol differences."
>>>
>>> I'll expand this to describe the multi-access network case. Sound
>>> good?
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>>> ===
>>>>
>>>> Cheers,
>>>> Adrian
>>>>
>>>> PS I wouldn't mind if you spelled my name right in the acks
>>>> section :-)
>>>>
>>>>
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> OSPF at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF at ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>
>> _______________________________________________
>> OSPF mailing list
>> OSPF at ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> OSPF at ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www.ietf.org/mailman/listinfo/ospf