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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 14:46:15 -0700

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.

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

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.

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

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 26 Sep 2018 15:41:23 -0700

On September 26, 2018 at 5:46:18 PM, Benjamin Kaduk ([email-masked]) wrote:

Benjamin:

Hi!

I don’t see your updated ballot in my archive…hmmm..??

But I wanted to reply to the additional point.  You wrote:

===
I'm not sure I followed correctly some discussion around the rtgdir
review, specifically the meaning of the indicated MSD value for SR-enabled
vs. non-SR-enabled networks.  In particular, I still don't really understand
why it's okay to use the same codepoint (value 1 as assigned here) for
the max SID depth in SR-enabled networks and for the max label depth
in non-SR MPLS networks.  Why couldn't they just be separate MSD Type
codepoints?
===

The answer is relatively simple: SR doesn’t change the MPLS architecture,
it just looks at the label stack in a different way by calling the labels a
segment [rfc8402].  IOW, the SID depth is the same as the max label depth
because a segment is the same as a label (for the purposes of forwarding
and considering the max segment/label depth).

Alvaro.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 17:46:57 -0500

> and considering the max segment/label depth).

That helps, thanks.  I was probably getting confused with some other system
that interspersed the "new type of label" (whatever it was) and other
existing labels.  Maybe entropy labels; I think we read that recently...

I may try to suggest some new text that would help clarify this
relationship, but probably not until after the telechat, and there's no
need to wait for it, regardless.

-Benjamin

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Sep 2018 23:09:10 +0000

Benjamin -

Responses inline.

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: Wednesday, September 26, 2018 2:46 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Christian Hopps
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-
> msd-17: (with COMMENT)
> 
> 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.)
> 
> 
> disclosure (but the corresponding ospf draft says this sort of thing is typical
> for LSR drafts).
> 
> Section 3
> 
> 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.

> That is, is it better to say "represents the maximum SID depth supported by
[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."

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

> 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

[Les:] I will align w the equivalent OSPF text in the next revision.

   Les

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 27 Sep 2018 13:32:24 -0500

> " any other value represents that of the particular link when used as an outgoing

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.

> [Les:] I have answered this twice already. :-)

And  I have agreed to leave it to Alvaro :)

> [Les:] I will align w the equivalent OSPF text in the next revision.

Thanks!

-Benjamin