[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ospf-ospfv3-traffic-02
Hi Jon,
I also think this is a good alternative. Let's go with
this.
Thanks,
Acee
----- Original Message -----
From: "Jon Berger" <Jon.Berger at DATACONNECTION.COM>
To: <OSPF at PEACH.EASE.LSOFT.COM>
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: +44 20 8366 1177
> Fax: +44 20 8363 1039
> Email: mailto:jon.berger at dataconnection.com
> Web: http://www.dataconnection.com
>
>
>
> -----Original Message-----
> From: Mailing List [mailto:OSPF at PEACH.EASE.LSOFT.COM]On Behalf Of Acee
> Lindem
> Sent: 28 July 2004 18:00
> To: OSPF at PEACH.EASE.LSOFT.COM
> 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" <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