Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Wed, Sep 26, 2018 at 11:09:10PM +0000, Les Ginsberg (ginsberg) wrote:
> Benjamin -
> 
> Responses inline.
> 
> > -----Original Message-----
> > From: Benjamin Kaduk <[e-mail]>
> > Sent: Wednesday, September 26, 2018 2:46 PM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; Christian Hopps
> > <[e-mail]>; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-
> > msd-17: (with COMMENT)
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-isis-segment-routing-msd-17: No Objection
> > 
> > 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-isis-segment-routing-msd/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > The shepherd writeup is silent about the WG's discussion of the IPR
> > disclosure (but the corresponding ospf draft says this sort of thing is typical
> > for LSR drafts).
> > 
> > Section 3
> > 
> >    The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
> >    223 to carry the MSD of the interface associated with the link.  MSD
> > 
> > Please add the appropriate qualifier (IS-IS?) before the list of TLV numbers.
> > 
> [Les:] The document is an IS-IS document. Such a statement is therefore unnecessary.
> 
> >    MSD-Value is a number in the range of 0-255.  For all MSD-Types, 0
> >    represents lack of the ability to support SID stack of any depth; any
> >    other value represents that of the link.
> > 
> > It's unclear that there's a referent for "that of the link" to attach to.
> > That is, is it better to say "represents the maximum SID depth supported by
> > the link" (or similar)?
> > 
> [Les:] Would you be satisfied with the corresponding text in the OSPF document?
> 
> " any other value represents that of the particular link when used as an outgoing
>    interface."

That's better text (IMHO), but on a different axis.  I was thinking more
like "represents the MSD of the link".  However, my opinion doesn't have to
count for much here, so feel free to leave it as-is.

> > Section 6
> > 
> > As discussed in the secdir review, this section needs to include guidance to
> > the Experts to check that the meaning of the absence of an MSD type is
> > specified.  Given the text in draft-ietf-ospf-segment-routing-msd that
> > attempts to place a similar requirement on future MSD types (but for OSPF
> > vs. IS-IS usage thereof), hopefully this guidance can be phrased in an
> > appropriately general fashion so as to apply to all places where the registered
> > MSD value would be used.
> > 
> [Les:] I have answered this twice already. :-)

And  I have agreed to leave it to Alvaro :)

> > Section 7
> > 
> >    Advertisement of the additional information defined in this document
> >    that is false, e.g., an MSD that is incorrect, may result in a path
> >    computation failing, having a service unavailable, or calculation of
> >    a path that cannot be supported by the head-end (the node performing
> >    the imposition).
> > 
> > In the analogous OSPF document we split out the case of a value that is too
> > small and a value that is too large, to describe the different consequences.
> > 
> > I would also suggest rewording to something like "calculation by the head-
> > end of a path that cannot be supported" to avoid the mis-parsing
> > "(calculation of a path) (that cannot be supported by the head-end)".
> > 
> 
> [Les:] I will align w the equivalent OSPF text in the next revision.


Thanks!

-Benjamin