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

[Jon Berger <[e-mail]>]

Hi Acee (and all),

Thanks for your comments.  I'm responding on behalf of Alan as he is on
vacation this week.

We think it makes sense to keep the Router IPv6 Address TLV and, as you say,
not to readvertise the same address in the Node Address TLV.  That seems
both the clearest method of indicating the stable address, and the most in
keeping with OSPFv2 TE.

Any thoughts you have on Alan's other suggestions would be welcome.

Jon


Jon Berger
Network Protocols Group
Data Connection Ltd
Tel:      [phone]
Fax:      [phone]
Email:  mailto:[e-mail]
Web:    http://www.dataconnection.com



-----Original Message-----
From: Mailing List [mailto:[e-mail]]On Behalf Of Acee
Lindem
Sent: 28 July 2004 18:00
To: [e-mail]
Subject: 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" <[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