Subject: [Lsr] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

From: Julien Meuric <[email-masked]>
Date: Mon, 10 Sep 2018 17:28:21 +0200

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-isis-segment-routing-msd-15
Reviewer: Julien Meuric (with some inputs from Bruno Decraene)
Review Date: 2018-09-07
IETF LC End Date: 2018-09-12
Intended Status: ST

*Summary:*
I have some minor concerns about this document that I think should be
resolved before publication.

*Comments:"
The document is well focused on a solution to a clearly scoped problem.
The defined encodings are simple and clear. All the same, there are a
few loose wordings, implicit assumptions or fuzzy zones which require
clarification before publication.

*Minor issues:*

- The abstract uses the acronym "SID", however:
    * It should be expanded at first use,
    * It should be defined, e.g. by adding a (normative) reference to
RFC 8402 (at least in the introduction),
    * The SR context is missing and should be explicitly mentioned
(adding a phrase such as "in a Segment Routing-enabled network" would be
enough).

- OLD
   Path Computation Element Protocol (PCEP) SR extensions draft
   [I-D.ietf-pce-segment-routing] signals MSD in SR Path Computation
   Element (PCE) Capability TLV and METRIC Object.
  NEW
   The Path Computation Element communication Protocol (PCEP) SR
   extension document [I-D.ietf-pce-segment-routing] defines how to
   signal MSD using the SR-PCE-CAPABILITY sub-TLV (per node) and
   the METRIC object (per request).

- The introduction says that the solution to complement BGP-LS lies in
IS-IS (the OSPF draft claiming the counterpart on its side). This is a
bit rough, the sentence 2 paragraph below already does the necessary
scoping job: "This document defines an extension to <your favorite IGP
here>". I suggest to temper the early sentence by rephrasing the
beginning of page 3 into: "MSD capabilities should be advertised by
every router in the network involved in the IGP."

- The wording of the following sentence is not clear: "Note that in a
non-SR MPLS network, label depth is what is defined by the MSD
advertisements." Is it intended to say: "Note that MSD advertisements
are applicable beyond SR-enabled networks and may refer to label depth
in MPLS networks."?

- "SID" may deserve to join the terminology section.

- s/SIDs a node or a link on a node can support./SIDs supported by a
node or a link on a node./

- The same ASCII art is used for the 2 figures (sections 2 and 3). It
would be nice to specialize each one a little bit by explicitly adding
their respective codepoint in the type field (23 and 15).

- Section 3 says "any other value represents that of the link when used
as an outgoing link." Is it not excessive to be that prescriptive about
outgoing vs. incoming? E.g., if an implementation was to advertise ERLD
as a link MSD, that would rather refer to a capability of the
incominglink. This specification could be left to each MSD-Type definition.

- In section 4: s/the Link MSD MUST take preference/the Link MSD MUST
take precedence/

- In section 5, BMI-MSD is defined as "the total number of MPLS  labels
which can be imposed" (which is OK when the incoming packet is
unlabled). When the incoming packet is labeled (e.g. use of segment
routing binding SID), if the incoming label is to be "replaced" by N
outgoing labels, what processing model is assumed when advertising the MSD:
 * one swap and one imposition of N-1 labels?
 * one pop and one imposition of N labels?

- For the BMI-MSD use case, the draft seems to clearly target a value
attached to the outgoing link. However, this capability on a router is
highly hardware-dependent: some implementations may push a stack on the
egress linecard while some may perform it on the ingress linecard. The
I-D seems to make some implicit hardware assumption and the current link
MSD advertisement is not suited to describe these possible combinations
of hardware implementations. This needs to be addressed somehow.

- Section 7 says that "an MSD that is incorrect, may result in [...]
instantiation of a path that can't be supported". It would be more
accurate to mention "instantiation attempt", as a proper state control
mechanism is expected to deny unsupported instantiation (e.g. PCEP
errors for "invalid objects" include "Unsupported number of SR-ERO
subobjects").

*Nits:*
- s/(IS-IS) Router to advertise/(IS-IS) router to advertise/
- s/link a given SR path/each node/link of a given SR path/
- s/path doesn't exceed/path does not exceed/
- s/and associated attributes and capabilities/as well as associated
attributes and capabilities/
- s/it is expected, that/it is expected that/
---
- s/an IANA managed registry/an IANA-managed registry/
- s/defined by this document/defined by this document:/
- s/path that can't be/path that cannot be/
---

Regards,

Julien

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 24 Sep 2018 06:11:35 +0000

Julien -

Thanx for your detailed review - and your patience in waiting for a response (I returned from vacation only a few days ago).

I have published V16 of the draft which addresses your comments except as noted inline below.

> -----Original Message-----
> From: Julien Meuric <[email-masked]>
> Sent: Monday, September 10, 2018 8:28 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RtgDir Review: draft-ietf-isis-segment-routing-msd-15
> 
> Hello,
> 
> The Routing Directorate seeks to review all routing or routing-related drafts
> as they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs. For more information about the Routing Directorate, please see 
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> Reviewer: Julien Meuric (with some inputs from Bruno Decraene) Review
> Date: 2018-09-07 IETF LC End Date: 2018-09-12 Intended Status: ST
> 
> *Summary:*
> The defined encodings are simple and clear. All the same, there are a few
> loose wordings, implicit assumptions or fuzzy zones which require
>     * It should be defined, e.g. by adding a (normative) reference to RFC 8402
> (at least in the introduction),
>     * The SR context is missing and should be explicitly mentioned (adding a
> phrase such as "in a Segment Routing-enabled network" would be enough).

[Les:] SID has been added to the terminology section and a reference to RFC 8402 added.
However, I don’t think "SR context" is missing. The first sentence of the Introduction starts with

" When Segment Routing (SR) paths are computed..."

>    the METRIC object (per request).
[Les:] I have updated this and included a reference to RFC 5440 where METRIC object was first defined.

> - The introduction says that the solution to complement BGP-LS lies in IS-IS
> (the OSPF draft claiming the counterpart on its side). This is a bit rough, the
> sentence 2 paragraph below already does the necessary scoping job: "This
> document defines an extension to <your favorite IGP
> beginning of page 3 into: "MSD capabilities should be advertised by every
> router in the network involved in the IGP."
> 
[Les:] The draft says 

" MSD capabilities should be
   advertised by every Intermediate System to Intermediate System(IS-IS)
   router in the network."

which I believe meets your suggestion.

> - The wording of the following sentence is not clear: "Note that in a non-SR
> MPLS network, label depth is what is defined by the MSD advertisements." Is
> it intended to say: "Note that MSD advertisements are applicable beyond SR-
> enabled networks and may refer to label depth in MPLS networks."?
> 
[Les:] The draft says:

" Although MSD advertisements are associated with Segment Routing, the
   advertisements MAY be present even if Segment Routing itself is not
   enabled."

I have made this sentence and the following sentence (which you quoted) a separate paragraph - which hopefully makes this a bit clearer.

> - "SID" may deserve to join the terminology section.

[Les:] Done.

> 
> - s/SIDs a node or a link on a node can support./SIDs supported by a node or
> a link on a node./

[Les:] Done

> 
> - The same ASCII art is used for the 2 figures (sections 2 and 3). It would be
> nice to specialize each one a little bit by explicitly adding their respective
> codepoint in the type field (23 and 15).
>
[Les:] The figure is intended to define the class of information in each field - not the actual values. The actual values are specified in the text which follows the ASCII art.

> - Section 3 says "any other value represents that of the link when used as an
> outgoing link." Is it not excessive to be that prescriptive about outgoing vs.
> incoming? E.g., if an implementation was to advertise ERLD as a link MSD,
> that would rather refer to a capability of the incominglink. This specification
> could be left to each MSD-Type definition.
> 
[Les:] Good point - I removed reference to outgoing.

> - In section 4: s/the Link MSD MUST take preference/the Link MSD MUST
[Les:] Done.

> - In section 5, BMI-MSD is defined as "the total number of MPLS  labels which
> can be imposed" (which is OK when the incoming packet is unlabled). When
> the incoming packet is labeled (e.g. use of segment routing binding SID), if
> the incoming label is to be "replaced" by N outgoing labels, what processing
> model is assumed when advertising the MSD:
[Les:] What is being defined is the maximum number of SIDs/labels which can be "imposed". If popping or swapping affects the MSD which can be supported this needs to be accounted for in the advertisement. BMI-MSD is not being used to advertise a value specific to labeled or unlabeled packets nor a value which is "swap specific" or "pop specific". 

> attached to the outgoing link. However, this capability on a router is highly
> hardware-dependent: some implementations may push a stack on the
> egress linecard while some may perform it on the ingress linecard. The I-D
> seems to make some implicit hardware assumption and the current link MSD
> advertisement is not suited to describe these possible combinations of
> hardware implementations. This needs to be addressed somehow.
> 
[Les:] If a platform does imposition on ingress, then it should advertise only a Node MSD - as there would be no way to advertise a value which is specific to the ingress-egress interface combination. So, link MSDs for BMI are associated with the use of that interface as the outgoing link.

> - Section 7 says that "an MSD that is incorrect, may result in [...] instantiation
> of a path that can't be supported". It would be more accurate to mention
> "instantiation attempt", as a proper state control mechanism is expected to
> deny unsupported instantiation (e.g. PCEP errors for "invalid objects" include
> "Unsupported number of SR-ERO subobjects").
>
[Les:] I replaced "instantiation" with "calculation".
 
> - s/(IS-IS) Router to advertise/(IS-IS) router to advertise/

[Les:] Done
> - s/link a given SR path/each node/link of a given SR path/

[Les:] Done
> - s/path doesn't exceed/path does not exceed/

[Les:] Done. You don't like contractions? :-)

> - s/and associated attributes and capabilities/as well as associated attributes
> and capabilities/

[Les:] I prefer the existing wording. 

> - s/it is expected, that/it is expected that/

[Les:] Done

> - s/an IANA managed registry/an IANA-managed registry/

[Les:] I am going to leave this to the RFC editor if you don’t mind. I am not fully convinced that a compound adjective is appropriate here.

> - s/defined by this document/defined by this document:/

[Les:] Done

> - s/path that can't be/path that cannot be/

[Les:] Done

    Les

---

From: Julien Meuric <[email-masked]>
Date: Mon, 24 Sep 2018 17:12:02 +0200

Hi Les,

Thanks for you feedback. Please find some responses, marked [JM] below.
You may consider the trimmed ones as resolved. For others, please keep
in mind that the directorate's purpose is to improve documents'
readability before publication, as opposed to store clarification in
mailing list archives.

Julien

>> Sent: Monday, September 10, 2018 8:28 AM
<snip>
> " When Segment Routing (SR) paths are computed..."
[JM] I fully agree about the introduction, but my comment was about the
abstract where the SR context needs to be guessed from the use of the
"SID" terminology: an explicit phrase would be welcome to a rookie
reading the abstract.

> [Les:] I have updated this and included a reference to RFC 5440 where METRIC object was first defined.
[JM] Even better about METRIC. Consistently, "SR Path Computation
Element (PCE) Capability TLV" still remains a loose phrase, the
technical name from [I-D.ietf-pce-segment-routing] is
"SR-PCE-CAPABILITY", which avoids ambiguity.

> which I believe meets your suggestion.
[JM] My comment was exactly starting from there. Let me rephrase:
- This I-D says "should be advertised by every IS-IS router";
- draft-ietf-ospf-segment-routing-msd says "should be advertised by
every OSPF router".
Now that we have a single LSR WG, I suggest to drop these competing
wordings and consider a more consensual "should be advertised in the
IGP". Both documents already include a sentence "This document defines
an extension to IS-IS/OSPF" at the end of their introduction, which is
enough to define the scope.

> I have made this sentence and the following sentence (which you quoted) a separate paragraph - which hopefully makes this a bit clearer.
[JM] Indeed, a separate paragraph is an improvement but doesn't fully
address my comment. The 2nd sentence I previously quoted combines the
passive voice on top of a subordinate clause starting with "what":
though grammatically correct, don't you disagree that the current
wording barely succeeds in achieving its purpose of building a loud and
clear message to be conveyed by an easy-to-parse sentence? Or do you?
;-) (Should you decide to leave it as is, be prepared to RFC Editor's
review.)

<snip>
> [Les:] The figure is intended to define the class of information in each field - not the actual values. The actual values are specified in the text which follows the ASCII art.
[JM] This is acceptable to me, but twice the exact same figure makes the
reader wonder why not just two contexts with pointers to a single
definition.

<snip>
> [Les:] What is being defined is the maximum number of SIDs/labels which can be "imposed". If popping or swapping affects the MSD which can be supported this needs to be accounted for in the adverti…
[JM] We seem to agree on an architecture-agnostic use of BMI-MSD. "If
popping or swapping affects the MSD [...] this needs to be accounted
for" is a great introduction to the issue and deserves to be included in
the I-D. My comment now binds to: in order to have interoperable
implementations, I believe the document should be more prescriptive on
how we account that for.

>[JM] OK. Could you please include that clarification in the I-D itself?

<snip>
> [Les:] Done. You don't like contractions? :-)
[JM] I don't dislike 'em, but I prefer a slightly more formal language
when writing standard text. :-)

> [JM] Acceptable to me, but may trigger a two-cycle reading on some
parser implementations.

Regards,

Julien

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Sep 2018 20:21:38 +0000

Julien -

Thanx for the additional comments.
V17 has been published to address these - subject to my responses below.
See Les2

> From: rtg-dir <[email-masked]> On Behalf Of Julien Meuric
> Sent: Monday, September 24, 2018 8:12 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; draft-ietf-isis-segment-routing- 
> [email-masked]
> Subject: Re: [RTG-DIR] RtgDir Review: 
> draft-ietf-isis-segment-routing-msd-15
> 
> Hi Les,
> 
[Les2:]  I fully appreciate both the purpose of the review and the effort you have put in. Yours is one of the better reviews I have seen in my years...
If I push back it is not because I do not value your input - but simply because I disagree. :-)

> > Thanx for your detailed review - and your patience in waiting for a
> response (I returned from vacation only a few days ago).
> >
> > I have published V16 of the draft which addresses your comments 
> > except
> as noted inline below.
> >
> >
> >>     * It should be defined, e.g. by adding a (normative) reference 
> >> to RFC 8402 (at least in the introduction),
> >> (adding a phrase such as "in a Segment Routing-enabled network" 
> >> would
> be enough).
> >
> > [Les:] SID has been added to the terminology section and a reference 
> > to
> RFC 8402 added.
> [JM] I fully agree about the introduction, but my comment was about 
> the abstract where the SR context needs to be guessed from the use of 
> the "SID" terminology: an explicit phrase would be welcome to a rookie 
> reading the abstract.
> 
[Les2:] I have modified the abstract.

> > [Les:] I have updated this and included a reference to RFC 5440 
> > where
> METRIC object was first defined.
> >
> Element
> (PCE) Capability TLV" still remains a loose phrase, the technical name 
> from [I- D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY", which 
> avoids ambiguity.
> 

[Les2:] I removed naming the specific TLVs and replaced it with " Path  Computation Element Protocol (PCEP)".
I think this is better than mentioning specific TLV names - particularly since one of them is part of a draft and the TLV name might change before the document becomes an RFC. So any possible naming inconsistency is now eliminated.

> >
> >> - The introduction says that the solution to complement BGP-LS lies 
> >> in IS-IS (the OSPF draft claiming the counterpart on its side). 
> >> This is a bit rough, the sentence 2 paragraph below already does 
> >> the necessary scoping job: "This document defines an extension to 
> >> <your favorite IGP
> wordings and consider a more consensual "should be advertised in the IGP".
> Both documents already include a sentence "This document defines an 
> extension to IS-IS/OSPF" at the end of their introduction, which is 
[Les2:] Sorry - here I will pushback. 
If the initial version of the MSD drafts had been written after (or close to) when the two IGP WGs were combined into LSR, we undoubtedly would have written one draft and included the IGP specific encodings for each protocol in that one draft - and we then would have used "IGP" in many places. But by the time LSR was formed the MSD drafts were already fairly mature, so we have kept them separate. Given that, I see no reason to replace "OSPF/IS-IS" with "IGP" given that we have protocol specific drafts.

> >> - The wording of the following sentence is not clear: "Note that in 
> >> a non-SR MPLS network, label depth is what is defined by the MSD 
> >> advertisements." Is it intended to say: "Note that MSD 
> >> advertisements are applicable beyond SR- enabled networks and may 
> >> refer to label depth
> in MPLS networks."?
> >>
> > [Les:] The draft says:
> >
> > I have made this sentence and the following sentence (which you 
> > quoted)
> a separate paragraph - which hopefully makes this a bit clearer.
> >
> wording barely succeeds in achieving its purpose of building a loud 
> and clear message to be conveyed by an easy-to-parse sentence? Or do you?
[Les2:] I rewrote the paragraph - hopefully you will find it more acceptable.

> <snip>
> >>
> >> - The same ASCII art is used for the 2 figures (sections 2 and 3). 
> >> It would be nice to specialize each one a little bit by explicitly 
> >> adding their respective codepoint in the type field (23 and 15).
> >>
> > [Les:] The figure is intended to define the class of information in 
> > each field -
> not the actual values. The actual values are specified in the text 
> which follows the ASCII art.
> >
> [JM] This is acceptable to me, but twice the exact same figure makes 
> the reader wonder why not just two contexts with pointers to a single definition.
> 
[Les2:] With TLV/sub-TLV encodings it is commonplace to provide the ASCII art in the section(s) specific to each advertisement. This avoids "flipping pages" in order to see the actual encoding.

> <snip>
> >
> >> - In section 5, BMI-MSD is defined as "the total number of MPLS 
> >> labels which can be imposed" (which is OK when the incoming packet 
> >> is unlabled). When the incoming packet is labeled (e.g. use of 
> >> segment routing binding SID), if the incoming label is to be 
> >> "replaced" by N outgoing labels, what processing model is assumed 
> >> when advertising the
> MSD:
> > [Les:] What is being defined is the maximum number of SIDs/labels 
> > which
> can be "imposed". If popping or swapping affects the MSD which can be 
> supported this needs to be accounted for in the advertisement. BMI-MSD 
> is not being used to advertise a value specific to labeled or 
> unlabeled packets nor a value which is "swap specific" or "pop specific".
> >
> for" is a great introduction to the issue and deserves to be included 
> in the I-D. My comment now binds to: in order to have interoperable 
[Les2:] Added text
 
> >> - For the BMI-MSD use case, the draft seems to clearly target a 
> >> value attached to the outgoing link. However, this capability on a 
> >> router is highly
> >> egress linecard while some may perform it on the ingress linecard.
> >> The I-D seems to make some implicit hardware assumption and the 
> >> current link MSD advertisement is not suited to describe these 
> >> possible combinations of hardware implementations. This needs to be
> addressed somehow.
> >>
> > [Les:] If a platform does imposition on ingress, then it should 
> > advertise only
> a Node MSD - as there would be no way to advertise a value which is 
> specific to the ingress-egress interface combination. So, link MSDs 
> for BMI are associated with the use of that interface as the outgoing link.
[Les2:] Done

    Les

> >> - s/and associated attributes and capabilities/as well as 
> >> associated attributes and capabilities/
> >

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 26 Sep 2018 13:28:36 -0700

Gents,

Thanks for the great review!

Both drafts are on the Telechat tomorrow, would be great to come to the agreement, so ospf draft could be updated before tomorrow’s call.

Regards,
Jeff

> On Sep 26, 2018, at 13:21, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Julien -
>

---

From: Julien Meuric <[email-masked]>
Date: Thu, 27 Sep 2018 12:26:35 +0200

Hi Les,

Please see inline.

Thank you,

Julien

> [Les2:] I have modified the abstract.
[JM2] ...and addressed most of my comment, thanks. (The RFC Editor may
still request you to expand "SID".)

> I think this is better than mentioning specific TLV names - particularly since one of them is part of a draft and the TLV name might change before the document becomes an RFC. So any possible namin…
[JM2] As there's an early IANA allocation on this TLV, I don't expect
any change in its name, but I can hear that argument. If you want a full
phrase, then I prefer the text from v16, because "SR Path Computation
Element (PCE) Capability" matches the section title of the PCEP draft
(and a slight change later wouldn't have much impact). In case you're
into removing the TLV/objects names and just point to PCEP, then you
MUST use the full expansion which is "Path Computation Element
*communication* Protocol" (and SHOULD avoid asking about the missing C
;-) ).

> If the initial version of the MSD drafts had been written after (or close to) when the two IGP WGs were combined into LSR, we undoubtedly would have written one draft and included the IGP specific…
[JM2] The protocol-specific scope is already well defined by the last
paragraph of the introduction. Whatever the WG legacy, there is no
technical reason to say "I, IS-IS, am the solution" on one side and "I,
OSPF, am the solution" on the other side. I still believe this claim is
both wrong and unnecessary in these drafts, but it's rhetorical and
doesn't impact the technical specification, so I can live with that.

> [Les2:] I rewrote the paragraph - hopefully you will find it more acceptable.
[JM2] Yes, it's much clearer now.

> [Les2:] With TLV/sub-TLV encodings it is commonplace to provide the ASCII art in the section(s) specific to each advertisement. This avoids "flipping pages" in order to see the actual encoding.
[JM2] I agree with that, all the more as a small figure instantiated
twice in a 9-page document isn't a big deal.

>> implementations, I believe the document should be more prescriptive on 
[JM2] Thanks, this is a significant improvement. After talking to Bruno,
we however feel that the proposed wording remains ambiguous, and
especially the phrases "imposed under all conditions" and "be accounted
for". Indeed, section 3.10 of RFC 3031 defines "the operation to perform
on the packet's label stack" and doesn't mention "impose". The closest
concept may be found in:
"        replace the label at the top of the label stack with a
         specified new label, and then push one or more specified new
         labels onto the label stack."
Combining this split to your current text may lead to different
interpretations. Could you clarify the paragraph to be more specific on
the corresponding definitions and fully clear the fuzzy zone?

>>> [JM] OK. Could you please include that clarification in the I-D itself?
[JM2] Thanks.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Sep 2018 17:45:13 +0000

Julien -

Snipping out the resolved bits.

> Sent: Thursday, September 27, 2018 3:27 AM

> Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

> >>>>    [I-D.ietf-pce-segment-routing] signals MSD in SR Path

> >>>> Computation

> >> (PCE) Capability TLV" still remains a loose phrase, the technical

> >> name from [I- D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY",

> >> which avoids ambiguity.

> > [Les2:] I removed naming the specific TLVs and replaced it with " Path

> Computation Element Protocol (PCEP)".

> > I think this is better than mentioning specific TLV names - particularly since

> one of them is part of a draft and the TLV name might change before the

> document becomes an RFC. So any possible naming inconsistency is now

> eliminated.

> [JM2] As there's an early IANA allocation on this TLV, I don't expect any

> change in its name, but I can hear that argument. If you want a full phrase,

> then I prefer the text from v16, because "SR Path Computation Element

> (PCE) Capability" matches the section title of the PCEP draft (and a slight

> change later wouldn't have much impact). In case you're into removing the

> TLV/objects names and just point to PCEP, then you MUST use the full

> expansion which is "Path Computation Element

[Les:] I don't really care, but I am having trouble with your suggestion.

IT is true that RFC 5440 is entitled:  "Path Computation Element (PCE) Communication Protocol (PCEP)"

However, in the body of the RFC we see

"This document specifies the Path Computation Element Protocol (PCEP)".

Also, in draft-ietf-pce-segment-routing-12 we also see

"[RFC5440] describes the Path Computation Element Protocol (PCEP) ..."

So explain to me why this document should deviate from these other PCE oriented documents???

> >> supported this needs to be accounted for in the advertisement.

> >> BMI-MSD is not being used to advertise a value specific to labeled or

> >> implementations, I believe the document should be more prescriptive

> >> on how we account that for.

> [JM2] Thanks, this is a significant improvement. After talking to Bruno, we

> however feel that the proposed wording remains ambiguous, and especially

> the phrases "imposed under all conditions" and "be accounted for". Indeed,

> section 3.10 of RFC 3031 defines "the operation to perform on the packet's

> label stack" and doesn't mention "impose". The closest concept may be

> found in:

> interpretations. Could you clarify the paragraph to be more specific on the

> corresponding definitions and fully clear the fuzzy zone?

[Les:] I am trying to understand exactly what is desired here.

It seems you do not like the term “impose/imposition” – which affects other places in the draft. I appreciate that RFC 3031 does not use the term “impose”. However the usage here is not to formally define a specific MPLS operation but to use a generic term which covers all the flavors of MPLS operations (swap, pop, push).

I can eliminate perhaps some of the “fuzziness” by:

OLD

“The value advertised MUST indicate what can be imposed under

   all conditions e.g., if label popping/swapping affects the number of

   labels which can be imposed this MUST be accounted for in the value

   which is advertised.”

NEW

“The value advertised MUST indicate the lowest maximum number of labels which  can be imposed under

   all conditions e.g., if label popping/swapping reduces the maximum number of

   labels which can be imposed this lower number MUST be what is advertised.”

But I suspect this does not address all of your concerns.

???

   Les

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 27 Sep 2018 10:54:03 -0700

On September 27, 2018 at 6:26:57 AM, Julien Meuric ([email-masked])
wrote:

Hi!

It looks like the outstanding item is this one about the terminology used
in §5.

tl;dr: I think that the terminology can be slightly improved to be in line
with other documents.  See suggestion at the bottom.

The document currently (-17) reads:

   Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  The value advertised MUST indicate what can be imposed under
   all conditions e.g., if label popping/swapping affects the number of
   labels which can be imposed this MUST be accounted for in the value
   which is advertised.

   If the advertising router performs label imposition in the context of
   the ingress interface, it is not possible to meaningfully advertise
   per link values.  In such a case only the Node MSD SHOULD be
   advertised.

I think that the term “label imposition” is relatively well understood, as
the act of putting labels on the packet (labeling a packet).  However,
rfc3031 doesn’t talk about imposition; instead it says that a ""labeled
packet" is a packet into which a label has been encoded”, and it talks
about pushing labels on the stack.  The SR documents (rfc8402
and draft-ietf-spring-segment-routing-mpls) also don’t talk about
imposition, nor do they offer a better alternative.

The text may be interpreted from the point of view of what the LSR can
impose, vs what can be imposed on the packet…which can result in
confusion.  Note that §7 clarifies which node is expected to do the
imposition: "the head-end (the node performing the imposition)”.

rfc4221 does provide a clear precedent of the use of imposition, and a
related definition (referring to the LSR MIB / rfc3813):
"mplsMaxLabelStackDepth defines the maximum size of a imposed label stack
supported at this LSR”.  This definition is akin to what this document
already says: “MSD...the number of SIDs supported” (§1.1).  The definition
in rfc4221 also presents a subtle difference (from the text in this
document): it talks about the “imposed label stack supported” (not “labels
which can be imposed”).  I interpret the “imposed label stack” as already
taking into consideration any operations that can be performed (rfc3031).

My suggestion is to borrow from rfc4221 and simplify the definition:

NEW>

   Base MPLS Imposition MSD (BMI-MSD) indicates the maximum size of an
   imposed label stack supported by the node.

   If it is not possible to meaningfully advertise
   per link values, then only the Node MSD SHOULD be
   advertised.

 In line with that suggestion, we could clean up some of the related text:

§1 s/the controller learns the Maximum SID Depth (MSD) that can be imposed
at each node/link/the controller learns the Maximum SID Depth (MSD)
supported at each node/link

§1 s/not exceed the number of SIDs the node is capable of imposing/not
exceed the number of SIDs the node is capable of supporting

§1.1: s/BMI: Base MPLS Imposition…/BMI: Base MPLS Imposition is the size of
the imposed label stack supported

Does this work?

Thanks!

Alvaro.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Sep 2018 18:44:32 +0000

Alvaro –

Thanx for helping drive this to closure.
Please see inline.

From: Alvaro Retana <[email-masked]>
Sent: Thursday, September 27, 2018 10:54 AM
To: Julien Meuric <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

On September 27, 2018 at 6:26:57 AM, Julien Meuric ([email-masked]<mailto:[email-masked]>) wrote:

Hi!

It looks like the outstanding item is this one about the terminology used in §5.

tl;dr: I think that the terminology can be slightly improved to be in line with other documents.  See suggestion at the bottom.

   which is advertised.

   advertised.

I think that the term “label imposition” is relatively well understood, as the act of putting labels on the packet (labeling a packet).  However, rfc3031 doesn’t talk about imposition; instead it says that a ""labeled packet" is a packet into which a label has been encoded”, and it talks about pushing labels on the stack.  The SR documents (rfc8402 and draft-ietf-spring-segment-routing-mpls) also don’t talk about imposition, nor do they offer a better alternative.

The text may be interpreted from the point of view of what the LSR can impose, vs what can be imposed on the packet…which can result in confusion.  Note that §7 clarifies which node is expected to do the imposition: "the head-end (the node performing the imposition)”.

rfc4221 does provide a clear precedent of the use of imposition, and a related definition (referring to the LSR MIB / rfc3813): "mplsMaxLabelStackDepth defines the maximum size of a imposed label stack supported at this LSR”.  This definition is akin to what this document already says: “MSD...the number of SIDs supported” (§1.1).  The definition in rfc4221 also presents a subtle difference (from the text in this document): it talks about the “imposed label stack supported” (not “labels which can be imposed”).  I interpret the “imposed label stack” as already taking into consideration any operations that can be performed (rfc3031).

NEW>

   advertised.

[Les:] There are some key elements missing here.

1)Specifying that the value advertised includes “all service/transport/special  labels” is vital. This eliminates ambiguity which might occur if someone is trying to use this value to (for example) determine how many labels can be used for a repair path. It is possible that in the future we might specify other MSD-types advertising what can be imposed for a specific purpose (e.g., for repair only). Such a number would have factored out labels used for other purposes.

2)From the comments Julien has previously provided, clarification as to how popping/swapping “might” impact what a given LSR can do has been requested – and your proposal does not address that.

IN a recent email I proposed:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  The value advertised MUST indicate the lowest maximum number of labels which  can be imposed under
   all conditions e.g., if label popping/swapping reduces the maximum number of
   labels which can be imposed this lower number MUST be what is advertised.

   advertised.”

Given you have provided a justification for retaining “imposition”, does the above work??

§1 s/the controller learns the Maximum SID Depth (MSD) that can be imposed at each node/link/the controller learns the Maximum SID Depth (MSD) supported at each node/link
[Les:] “supported” does not cover the same ground as “imposed”. For example, “supported” could be “supported for reading” – which is not what we are specifying in BMI.

   Les

§1 s/not exceed the number of SIDs the node is capable of imposing/not exceed the number of SIDs the node is capable of supporting

§1.1: s/BMI: Base MPLS Imposition…/BMI: Base MPLS Imposition is the size of the imposed label stack supported

Does this work?

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 27 Sep 2018 12:03:37 -0700

On September 27, 2018 at 2:44:34 PM, Les Ginsberg (ginsberg) (
[email-masked]) wrote:

Les:

Sometimes less is more. ;-)

My personal opinion is that, given the precedent from rfc4221, the
additional considerations are implied.

I’ll approve the publication either way once you and Julien agree.

Thanks!

Alvaro.

---

From: <[email-masked]>
Date: Fri, 28 Sep 2018 08:02:03 +0000

Les, Alvaro,

Jumping in the conversation, please see comments inlined [Bruno]

From: Lsr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, September 27, 2018 8:45 PM
To: Alvaro Retana; MEURIC Julien IMT/OLN
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Alvaro –

Hi!

   which is advertised.

   advertised.

NEW>

   advertised.

[Bruno] I agree with Les here.
Trying to rephrase the comment:
- I don’t think the term “imposed” is well defined for the case where the received packet is already labeled. If I’m missing a definition, please point to it.
- To give an example, suppose that I receive a packet with the label stack “12” and forward it with the label stack “14, 15”. Am I doing an imposition of 2 labels (1 POP, 2 PUSH) or an imposition of 1 label (1 SWAP, 1 PUSH)? Any option works for me, but I’d like the definition to be crystal clear in order to avoid interop issues.

[Bruno] I think the new proposed text is better (thanks Les), yet, could may be made more obvious by either replacing “labeled imposed” by “labelled added” or “label pushed” or “additional label added”.
May be even better by referring to the size of the label stack, something like “BMI-MSD advertises the ability to increase the depth of the label stack by BMI-MSD labels”. Alternatively, explain the behavior in case of a swap. (e.g. “performing a label swap corresponds to an imposition of zero label”.)

Thanks,
--Bruno

   Les

Does this work?

Thanks!

Alvaro.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Julien Meuric <[email-masked]>
Date: Fri, 28 Sep 2018 16:21:45 +0200

Hi Les,

We're converging. Please see below.

Julien

Sep. 27, 2018 - [email-masked]:

Julien -

> >>>>    Path
Computation Element Protocol (PCEP) SR extensions draft

> >>>>    The Path
Computation Element communication Protocol (PCEP) SR

> >>>>    extension
document [I-D.ietf-pce-segment-routing] defines how to

> >>>>    signal MSD
using the SR-PCE-CAPABILITY sub-TLV (per node) and

> >>> [Les:] I have updated
this and included a reference to RFC 5440

> >> [JM] Even better about
METRIC. Consistently, "SR Path Computation

> >> (PCE) Capability TLV"
still remains a loose phrase, the technical

> >> name from [I-
D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY",

> > [Les2:] I removed naming the
specific TLVs and replaced it with " Path

> > I think this is better than
mentioning specific TLV names - particularly since

> [JM2] As there's an early IANA
allocation on this TLV, I don't expect any

> change in its name, but I can hear
that argument. If you want a full phrase,

> (PCE) Capability" matches the
section title of the PCEP draft (and a slight

> change later wouldn't have much
impact). In case you're into removing the

[Les:] I don't really care, but I
am having trouble with your suggestion.

IT is true that RFC 5440 is
entitled:  "Path Computation Element (PCE) Communication
Protocol (PCEP)"

However, in the body of the RFC we
see

"This
document specifies the Path Computation Element Protocol
(PCEP)".

Also, in
draft-ietf-pce-segment-routing-12 we also see

"[RFC5440]
describes the Path Computation Element Protocol (PCEP)
..."

So explain to me why this document
should deviate from these other PCE oriented documents???

[JM3] That's a recurrent issue. It's true that here are a few
inconsistencies out there, starting from RFC 5440 (the RFC Editor
can be picky, but remains human). This legacy isn't serious enough
to require bis documents. The expansion which has been used most of
the time in the PCE documents (e.g., RFC 8306, 8356, 8408) is the
one from RFC 5440's title and abstract, which includes
"Communication". This is the one we try to enforce with Jon in the
documents we review, so please be my guest. :-)

(By the way, thank you for pointing this issue on
draft-ietf-pce-segment-routing: we may include this update even
before reaching the RFC Editor.)

> >>>> - In section 5,
BMI-MSD is defined as "the total number of MPLS

> >>>> labels which can
be imposed" (which is OK when the incoming packet

> >>>> is unlabled). When
the incoming packet is labeled (e.g. use of

> >>>> segment routing
binding SID), if the incoming label is to be

> >>>> "replaced" by N
outgoing labels, what processing model is assumed

> >>>> when advertising
the

> >>> [Les:] What is being
defined is the maximum number of SIDs/labels

> >> can be "imposed". If
popping or swapping affects the MSD which can be

> >> BMI-MSD is not being used
to advertise a value specific to labeled or

> >> unlabeled packets nor a
value which is "swap specific" or "pop specific".

> >> [JM] We seem to agree on
an architecture-agnostic use of BMI-MSD. "If

> >> popping or swapping
affects the MSD [...] this needs to be accounted

> >> for" is a great
introduction to the issue and deserves to be included

> however feel that the proposed
wording remains ambiguous, and especially

> the phrases "imposed under all
conditions" and "be accounted for". Indeed,

> section 3.10 of RFC 3031 defines
"the operation to perform on the packet's

[Les:] I
am trying to understand exactly what is desired here.

It seems
you do not like the term “impose/imposition” – which
affects other places in the draft. I appreciate that RFC
3031 does not use the term “impose”. However the usage
here is not to formally define a specific MPLS operation
but to use a generic term which covers all the flavors
of MPLS operations (swap, pop, push).

I can
eliminate perhaps some of the “fuzziness” by:

OLD

“The
value advertised MUST indicate what can be imposed under

all
conditions e.g., if label popping/swapping affects the
number of

labels which can be imposed this MUST be accounted for
in the value

which
is advertised.”

NEW

“The
value advertised MUST indicate the lowest maximum number
of labels which  can be imposed under

all
conditions e.g., if label popping/swapping reduces the
maximum number of

labels which can be imposed this lower number MUST be
what is advertised.”

But I
suspect this does not address all of your concerns.

???

Les

[JM3] Actually, my point is to clarify this very document and your
NEW wording is a significant improvement; thank you for that.
Nevertheless, the text still relies on this under-defined term
"impose", which might be subject to different interpretation. To
quote Bruno, if we're talking about "adding" or "pushing", why not
just using the well-defined vocabulary?

---

From: Julien Meuric <[email-masked]>
Date: Fri, 28 Sep 2018 16:24:06 +0200

Thank you Alvaro. Though not less, I think we're about to find an
agreement on Les's wording.

Julien

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 28 Sep 2018 17:57:17 +0000

Bruno –

Inline.

From: [email-masked] <[email-masked]>
Sent: Friday, September 28, 2018 1:02 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Alvaro Retana <[email-masked]>; MEURIC Julien IMT/OLN <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Les, Alvaro,

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Alvaro –

From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 27, 2018 10:54 AM
To: Julien Meuric <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Hi!

   which is advertised.

   advertised.

NEW>

   advertised.

[Les2:] Label imposition is meant to cover both the SWAP operation and the PUSH operation. In the example you provided above where a label stack of “12” is replaced by a label stack of “14,15” the number of labels “imposed” is 2.
Whether you choose to call that (1 POP, 2 PUSH) or (1 SWAP, 1 PUSH)  or simply a SWAP isn’t relevant here (though it might matter to folks like the RFC 3031 authors).

With that ibn mind, here is proposed text:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  Imposition includes swap and/or push operations.

???

   Les

Thanks,
--Bruno

   Les

Does this work?

Thanks!

Alvaro.

Thank you.