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

[Alexey Melnikov <[e-mail]>]

On Wed, Dec 13, 2017, at 07:52 PM, Acee Lindem (acee) wrote:
> Hi Alexey
> 
> These all seem to be valid comments except for the one on byte order.
> Note
> that section 3.1 of RFC 2360 already states that IETF document packet
> encodings are in Network-Byte Order (NBO).
> https://www.ietf.org/rfc/rfc2360.txt

Well, lots of recent RFCs violate this, so repeating it doesn't hurt.

> Typically, we have not defined Reserved field usage. However, I guess we
> could say that they SHOULD be set to 0 on transmission and MUST be
> ignored
> on reception.

Yes, please. Just mention it once early in the document.

> This will allow for future reuse in a backward compatible
> manner. 
> Thanks,
> Acee 
> 
> 
> 
> 
> 
> On 12/13/17, 5:47 AM, "Alexey Melnikov" <[e-mail]> 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-extension
> >s/
> >
> >
> >
> >----------------------------------------------------------------------
> >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.
> >
> >
>