[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ospf-ospfv3-traffic-02
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" <Alan.Davey at DATACONNECTION.COM>
To: <OSPF at PEACH.EASE.LSOFT.COM>
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: +44 20 8366 1177
> Fax: +44 20 8363 1039
> Email: Alan.Davey at dataconnection.com
> Web: http://www.dataconnection.com