Thanks Acee, That does the job.
Adrian ----- Original Message ----- From: "Acee Lindem" <[EMAIL PROTECTED]> Cc: "CCAMP List" <[EMAIL PROTECTED]>; "OSPF List" <[email protected]> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> _______________________________________________ >>> OSPF mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
