Re: Comments on draft-ietf-ospf-ospfv3-traffic-02

[Acee Lindem <[e-mail]>]

Hi Alan,
I  was the one who suggested using the node address TLV to
advertise a routable IPv6 address. I guess there is nothing in
the node address draft that says this address has to be stable since it
is meant to advertise both loopback and non-TE interfaces without
having to advertise a complete link TLV.

There still seems to be overlapp here but maybe a unique TLV
code point is warrented. However, if this is done we should say
that the Router IPv6 address need not be re-advertised in a node
address TLV. A second alternative would be to say that the most
stable node address must be first in the TE LSA.

Others?

Thanks,
Acee



----- Original Message -----
From: "Alan Davey" <[e-mail]>
To: <[e-mail]>
Sent: Friday, July 23, 2004 5:17 AM
Subject: Comments on draft-ietf-ospf-ospfv3-traffic-02


> Authors
>
> I have some comments on draft-ietf-ospf-ospfv3-traffic-02.  I have divided
> these into
>
> *       suggested changes to the advertising of stable addresses
> *       suggested change to the value used as the Link State ID
> *       points requiring clarification
> *       minor editorial points.
>
> Could you please consider these comments and let me know
>
> *       in which cases you will update the draft as suggested
> *       in which cases you can correct my understanding.
>
> Suggested Changes to the Advertising of Stable Addresses
> --------------------------------------------------------
>
> The "Node Address TLV" and the "Router IPv6 Address TLV" are both defined to
> provide a stable IP address of the advertising router that is always
> reachable.  I think that only one TLV to define a stable IP address is
> required.
>
> Furthermore, the Node Address TLV, as defined in
> draft-ietf-ospf-te-node-addr, does not appear to be suitable for advertising
> a stable address as there is no way of defining which of any included
> addresses are stable.
>
> I suggest the following modifications.
>
> *       Only the "Router IPv6 Address TLV" is defined for advertising a
> stable address.
>
> *       The Node Address TLV is defined as an optional TLV to provide
> additional local addresses of the router.
>
> *       The Node Address TLV section is moved to after the Link TLV section
> as it is of reduced importance.
>
> _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).
>
> Points requiring Clarification
> ------------------------------
>
> *       Section 2. This section is entitled "Node Address TLV" but refers to
> draft-ietf-ospf-te-node-addr which defines a "Node Attribute TLV".  Should
> references to "Node Address TLV" be changed to read "Node Attribute TLV"?
>
> *       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.
>
> 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."
>
> *       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.
>
> *       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?
>
> *       Section 5.  For clarity, the draft could provide more details on
> Intra-Area-TE-LSA format.  That is, specify
>         o       a diagram giving the format of the standard OSPFv3 LSA
> header that is used
>         o       the TLV format, presumably as defined in RFC3630.
>
> *       RFC3630 states that unnumbered links are not supported.  Is this
> also the case in this draft?
>
> Minor editorial points
> ----------------------
>
> *       Suggest adding a "Terms" section referencing RFC2119.
>
> *       Section 1, paragraph 2.  Typo "applicabilty".
>
> *       Section 1, paragraph 3.  Typo "TLV" instead of "TLVs".
>
> *       Section 2, paragraph 1.
>         o       Suggest "This satisfies the requirements of the Traffic
> Engineering computation".
>         o       Instead of "This satisfy requirements of Traffic Engineering
> computation".
>
> *       Section 2, paragraph 1.
>         o       Suggest "In OSPFv3 TE, the Node Address TLV MUST be
> supported".
>         o       Instead of "In OSPFv3 TE, node address must be supported".
>
> *       Section 3, paragraph 1.  Suggest current tense instead of "will
> advertise".
>
> *       Section 3, paragraph 2.  Typo "extentions".
>
> *       Section 4, paragraph 1.
>         o       Suggest "consists of a set of...".
>         o       Instead of "consists a set of...".
>
> *       Section 4, sub-TLV description.
>         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.3, paragraph 2 and section 4.4, paragraph 2.  As the
> preceding paragraph has, correctly, stated that link-local addresses should
> not be included, I suggest deleting ", and contains the link's local
> addresses" to avoid possible confusion.
>
> *       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 ::."
>
> *       Section 4.4, paragraph 1.
>         o       Suggest "Link-local scope addresses MUST NOT be included in
> this sub-TLV".
>         o       Instead of "Link-local address should not be included in
> this sub-TLV".
>
> Please let me know if you have any questions on any of the above.
>
> Regards
>
> Alan
>
> ------------------------------------
> Alan Davey
> Data Connection Ltd
> Tel:   [phone]
> Fax:   [phone]
> Email: [e-mail]
> Web:   http://www.dataconnection.com