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

[Alexey Melnikov <[e-mail]>]

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

Best Regards,
Alexey

On Thu, Dec 14, 2017, at 12:37 PM, Peter Psenak wrote:
> 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.
> >
> >
> > .
> >
>