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

[Acee Lindem <[e-mail]>]

Hi Jon,
I also think this is a good alternative. Let's go with
this.

Thanks,
Acee

----- Original Message -----
From: "Jon Berger" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, July 29, 2004 11:43 AM
Subject: Re: Comments on draft-ietf-ospf-ospfv3-traffic-02


> 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