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

[Alan Davey <[e-mail]>]

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