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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Dec 2017 02:47:45 -0800

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Dec 2017 19:52:40 +0000

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

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. This will allow for future reuse in a backward compatible
manner. 

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 14 Dec 2017 13:37:50 +0100

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Dec 2017 12:59:46 +0000

> https://www.ietf.org/rfc/rfc2360.txt

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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Dec 2017 13:03:34 +0000

Hi Peter,
Thank you for the changes, I cleared my DISCUSS.

Best Regards,
Alexey

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Dec 2017 13:32:14 +0000

>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 
>> >Please refer to
>>https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensi
>>>on
>> >s/
>> >
>> >
>> >
>> >RFC 2119 keyword usage makes the reference a Normative reference, yet
>>it
>> >is
>> >either explicitly explaining what Reserved means in each case or
>>specify
>> >this