[OSPF] Re: Picky nits in draft-ietf-ospf-te-node-addr-04.txt

[Rahul Aggarwal <rahul at juniper.net>]

Hi Adrian,

Thanks for the comments. Please see below:

On Mon, 17 Dec 2007, Adrian Farrel wrote:

> Hi,
>
> A few picky nits with your excellent draft.
>
> Cheers,
> Adrian
>
> ---
>
> Abstract
>
> I have a couple of issues with the Abstract. The first sentence is
> ambiguous - seems to say that it enhances the OSPF TE extensions that
> already exist to advertise a router's local addresses. And the order
> of presentation of material is back to front.
>
> Can I suggest...
>
> OLD
>    This document describes procedures that enhance OSPF Traffic
>    Engineering (TE) extensions for advertising a router's local
>    addresses.  This is needed to enable other routers in a network to
>    compute traffic engineered MPLS LSPs to a given router's local
>    addresses.  Currently, the only addresses belonging to a router that
>    are advertised in TE LSAs are the local addresses corresponding to TE
>    enabled links and the local address corresponding to the Router ID.
> NEW
>    OSPF Traffic Engineering (TE) extensions are used to advertise TE
>    Link State Advertisements (LSAs) containing information about TE-
>    enabled links. The only addresses belonging to a router that are
>    advertised in TE LSAs are the local addresses corresponding to TE-
>    enabled links, and the local address corresponding to the Router ID.
>
>    In order to allow other routers in a network to compute Multiprotocol
>    Label Switching (MPLS) traffic engineered Label Switched Paths (TE
>    LSPs) to a given router's local addresses, those addresses must also
>    be advertised by OSPF TE.
>
>    This document describes procedures that enhance OSPF TE to advertise
>    a router's local addresses.

Done.

> ===
> Section 2
> s/to setup/to set up/
> s/MPLS TE LSPs/Multiprotocol Label Switching (MPLS) Traffic Engineered Label
> Switched Paths (TE LSPs)/

Done.

> ===
> Section 3
> Suggest you rename this section "Rejected Potential Solution"

Done.

> ===
> Section 4
> Assuming you intend this to become an RFC, suggest you rename this section
> "Solution" and make the same change in the text.
>

Done.

> s/node attribute TLV. node attribute TLV./node attribute TLV/
>

Done.

> s/anticipated that a node attribute TLV/anticipated that the node attribute
> TLV/

Done.

> ===
> Section 4.1
>
> Your figure does not match the text. Assuming that the text is correct (i.e.
> you want to allow prefixes, not just full /32 addresses),

That is correct.

> and assuming that
> you want to use the full 32 bits for each address regardless of the prefix
> length, your figure should look like...
>

That is correct too.

>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |              1                |             Length            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |   Addr Len 1  |          IPv4 Address 1                       |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |IPv4 Addr cont.|                                               :
>       +-+-+-+-+-+-+-+-+                                               ~
>       :                               .                               :
>       ~                               .               +-+-+-+-+-+-+-+-+
>       :                               .               |   Addr Len n  |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                          IPv4 Address n                       |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>

Done.

> But perhaps you need to clarify the text and the figures for IPv4 and IPv6
> to indicate:
> - whether Length is in octets
> - whether Address is always octet-aligned
> - whether Address is always 4/16 octet aligned (IPv4/6)

Done.

> - whether Length is always a multiple of 5/17 (IPv4/6)
>

I don't that is necessary once all the other changes are made.

> ===
> Section 4.2
> s/SHOULD not/SHOULD NOT/
>

Ok.

> Having said "SHOULD NOT" don't you need to say what happens if, or why an
> implementation MAY vary this?
>

I am open to changing this to MUST NOT if there are no objections as this
would just be duplicate information.

> You need to clarify:
> - What happens if > 1 Node Attribute TLV in an OSPF TE LSA
> - What happens if a router advertises two OSPF TE LSAs each with a Node
> Attribute TLV
> - What happens if > 1 sub-TLV of the same type in a Node Attribute TLV
>

Will clarify these cases in the next revision.

> ===
> Section 5
>
> This is a brave section given the current climate :-)
>
> Aren't you advertising information that was not previously advertised?
> Doesn't that increase the risk if the protocol is compromised?

I am open to any suggested text.

> ===
> Section 6
>
> Suggest you point the IANA at the registry and subregistry by name, to make
> sure they understand where to make the assignment.
>

Ok.

> Don't you need IANA to manage a new registry for the sub-TLV type values?
> ===
>

That is a good idea. Will add text for that.

rahul

>
>

_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www1.ietf.org/mailman/listinfo/ospf