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

[Julien Meuric <[e-mail]>]

Hi Les,

We're converging. Please see below.

Julien

Sep. 27, 2018 - [e-mail]:

Julien -

 

Snipping out the resolved bits.

 

> -----Original Message-----

> From: Julien Meuric <[e-mail]>

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

>

> Hi Les,

>

> Please see inline.

>

> Thank you,

>

> Julien

>

>

> >>>>

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

> >>>>

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

> >>

> >

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

> *communication* Protocol" (and SHOULD avoid asking about the missing C

> ;-) ).

 

[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

> >> MSD:

> >>>>  * one swap and one imposition of N-1 labels?

> >>>>  * one pop and one imposition of N labels?

> >>>>

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

> >>>

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

> >>

> > [Les2:] Added text

> >

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

>

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