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

["Acee Lindem (acee)" <[e-mail]>]

On 12/14/17, 7:59 AM, "Alexey Melnikov" <[e-mail]> wrote:

>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.

Can you provide an example? IETF standard packets should always be in
Network-Byte Order.

Thanks,
Acee 
>
>> 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-extensi
>>>on
>> >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.
>> >
>> >
>>