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
