Re: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT)

[Peter Psenak <[e-mail]>]

Hi Alexey,

thanks for your comments. I have addressed them all except the one on 
the byte ordering, because as Acee has mentioned already all encodings 
are always in Network-Byte order.

Please see the updated version at:
https://www.ietf.org/internet-drafts/draft-ietf-ospf-segment-routing-extensions-24.txt


thanks,
Peter

On 13/12/17 11:47 , Alexey Melnikov wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-ospf-segment-routing-extensions-23: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This is generally a clearly written document, but it needs a few minor changes
> before I can recommend its approval for publication.
>
> 1) In Section 3.2:
>
>     o  When a router receives multiple overlapping ranges, it MUST
>        conform to the procedures defined in
>        [I-D.ietf-spring-conflict-resolution].
>
> RFC 2119 keyword usage makes the reference a Normative reference, yet it is
> currently listed as informative.
>
> 3.4.  SRMS Preference TLV
>
>     The Segment Routing Mapping Server Preference TLV (SRMS Preference
>     TLV) is used to advertise a preference associated with the node that
>     acts as an SR Mapping Server.  The role of an SRMS is described in
>     [I-D.ietf-spring-segment-routing-ldp-interop].
>
> As draff-ietf-spring-segment-routing-ldp-interop needs to be read in order to
> understand what SR Mapping Server is, this reference must also be Normative.
>
>    SRMS preference is defined in [I-D.ietf-spring-conflict-resolution].
>
> This just confirms that this reference must be Normative.
>
> 2) In Section 3.1:
>
>     When multiple SR-Algorithm TLVs are received from a given router, the
>     receiver SHOULD use the first occurrence of the TLV in the Router
>     Information LSA.  If the SR-Algorithm TLV appears in multiple Router
>     Information LSAs that have different flooding scopes, the SR-
>     Algorithm TLV in the Router Information LSA with the area-scoped
>     flooding scope SHOULD be used.  If the SR-Algorithm TLV appears in
>     multiple Router Information LSAs that have the same flooding scope,
>     the SR-Algorithm TLV in the Router Information (RI) LSA with the
>     numerically smallest Instance ID SHOULD be used and subsequent
>     instances of the SR-Algorithm TLV SHOULD be ignored.
>
> In the last 2 sentences: why are you using SHOULD (twice) instead of MUST? This
> seems to affect interoperability.
>
> (I think there is similar text in another section.)
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Several TLVs have "Reserved" fields, yet you never explain what "Reserved"
> means. You do explain what reserved flags mean in some of them. I suggest
> either explicitly explaining what Reserved means in each case or specify this
> in the terminology section near the beginning of the document.
>
> The document never specifies byte order for length fields.
>
> The acronym NSSA is never explained and it has no reference.
>
>
> .
>