Subject: Re: Comments on draft-ietf-ospf-ospfv3-traffic-03

From: Acee Lindem <[email-masked]>
Date: Wed, 23 Feb 2005 10:24:28 -0500

Hi Alan,

Thanks much for your review and comments.  I'm copying the OSPF  list
to see if there is any discussion.  See comments inline.

Alan Davey wrote:

>Folks
>
>I have some comments on draft-ietf-ospf-ospfv3-traffic-03.  Also, I note that some previous comments of mine have not made it into this revision and so I have reproduced them in this mail for completeness.
>
>The new comments are all minor editorial points.
>
>The previous comments include a suggested change to the value used as the LSA Link State ID, points for clarification and more minor editorial comments.
>
>Please let me know what you think.
>
>Regards
>
>Alan
>------------------------------------
>Alan Davey
>Data Connection Ltd
>Tel:   +44 20 8366 1177       
>Fax:   +44 20 8363 1039
>Email: [email-masked]  
>Web:   http://www.dataconnection.com 
>
>
>New Comments
>------------
>
>_Minor editorial points_
>
>*	Section 1, paragraph 2.  s/TLSs/TLVs/
>
>*	Section 1, paragraph 2, final sentence.  s/Some TLVs/Some existing TLVs/ ?
>
>*	Section 2, paragraph 1.  s/When the   U bit/When the U bit/
>
>*	Section 2, Intra-Area-TE-LSA definition should be 
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |            LS age             |1|0|1|          10             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>	instead of
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |            LS age             |1|1|0|          10             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>*	Section 2, paragraphs 3 and 4.  s/TLV's/TLVs/
>
>*	Section 4.4, paragraph 1.  s/associated with neighbor's interface/associated with the neighbor's interface/
>  
>
These are all errors I injected when editting the draft and I will 
gladly incorporate them.

>Previously Noted Comments
>-------------------------
>
>_Suggested Change to the Value Used as the Link State ID_
>
>I do not think that the interface ID of the link is suitable for use as the Link State ID of the Intra-Area-TE-LSA.  In particular, it is not suitable for the Link State ID of the single Intra-Area-TE-LSA containing the Router IPv6 Address TLV advertised by a router as this Link State ID must be different to all Link State IDs used for Intra-Area-TE-LSAs containing Link TLVs.
>
>I suggest using an arbitrary value with no topological significance as the Link State ID for Intra-Area-TE-LSAs, in a similar manner to LSA IDs in RFC3630 (Traffic Engineering (TE) Extensions to OSPF Version 2).
>  
>
In practice, many implementations do use the IfIndex for the the 23 bit  
OSPF opaque ID.
My previous implementation used the IfIndex for the LSA opaque type for 
the link TLVs
and 0 for the LSA opaque type for the router address TLV. 

Anyway, I can see arguments for going both ways. In the case of using 
Interface ID and 0 (router IPv6
address TLV), we simplify access and mapping between TE LSAs and 
Network-LSAs.
In the case of the arbitrary IDs, we are not limiting ourselves to 
specific ID when adding future
Intra-Area-TE-LSA TLVs.

Any other opinions here?

>_Points requiring Clarification_
>
>*       Section 4.2.  The Neighbor ID replaces the OSPFv2 TE Link ID to identify the remote end of a link.  The Link ID is mandatory in OSPFv2 TE.  I think that Neighbor ID should be mandatory in OSPFv3 TE.
>  
>
Agreed.

>I suggest adding paragraph defining which sub-TLVs are mandatory for OSPFv3 support.  For example: "The Neighbor ID sub-TLV is mandatory for OSPFv3 Traffic Engineering support, that is, it MUST appear exactly once in a Link TLV.  All other sub-TLVs defined here MAY occur at most once in a Link TLV."
>  
>
Agreed.

>*       Section 4.4.  This section correctly states that link-local addresses should not be contained in this sub-TLV.  I suggest adding a sentence stating that IPv6 addresses advertised by the neighbor in Link-LSAs
>as 128-bit prefixes with the LA-bit set MAY be included.
>  
>
Agreed.

>*       Section 5.  In RFC3630, it is defined that an LSA contains one and only one top-level TLV.  Is this also the case for the Intra-Area-TE-LSA?
>  
>
I see no reason to change this and believe it simplifies things.

>*       RFC3630 states that unnumbered links are not supported.  Is this also the case in this draft?
>  
>
IMHO,  No.  Personally, I don't see the requirement to even define the 
concept of
an unnumbered IPv6 link :^) Anyway, IPv6 links are no longer identified 
by their
addresses - we have OSPF interface ID and our neighbor's interface ID so
there is no ambiguity among parrallel unnumbered links.

>_Minor editorial points_
>
>*	Suggest adding a "Terms" section referencing RFC2119.  RFC2119 appears in the Normative References section but is not referenced in the body of the draft.
>
>*	Section 1, paragraph 2.  s/applicabilty/applicability/
>
>*	Section 1, paragraph 3.  s/TLV/TLVs/
>
>*	Section 3, paragraph 1.  Suggest current tense instead of "will advertise".
>
>*	Section 4, paragraph 1.
>      o	Suggest "consists of a set of...".
>      o	Instead of "consists a set of...".
>
>*	Section 4, paragraph 1.  s/All of sub-TLVs/All of the sub-TLVs/
>
>*	Section 4, sub-TLV descriptions.
>      o	Suggest "(16N octets, where N is the number of IPv6 addresses)".
>      o	Instead of "(16N octets)".
>
>*	Section 4.1, paragraph 1.
>      o	Suggest "In OSPFv3, the Link ID sub-TLV SHOULD NOT be sent and MUST be ignored upon receipt".
>      o	Instead of "In OSPFv3, The Link ID sub-TLV should not be sent and should be ignored upon receipt".
>
>*	Section 4.3, paragraph 1.
>      o	Suggest "If there are multiple local addresses assigned to the link then they MAY all be listed in this sub-TLV.  Link-local scope addresses MUST NOT be included in this sub-TLV".
>	o	Instead of "If there are multiple local addresses on the link, they are all listed in this sub-TLV.  Link-local address should not be included in this sub-TLV".
>
>*	Section 4.4, paragraph 1.
>	o	Suggest "If the link type is multi-access, the Remote Interface IPv6 Address MAY be set to ::.  Alternatively, an implementation MAY choose not to send this sub-TLV".
>	o	Instead of "If the Link Type is multi-access, the Remote Interface IPv6 Address is set to ::."
>  
>
These sound reasonable. I know I've already addressed at least one of 
them when editting.

Thanks,
Acee