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

From: <[email-masked]>
Date: Tue, 2 Oct 2018 12:16:05 +0000

Les,

Thanks for the follow up.
Please see inline [Bruno2]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, September 28, 2018 7:57 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

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,

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]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Alvaro –

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

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

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.

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

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.

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

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

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.

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

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

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

[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.
[Bruno2] In that case, I definitely think that the discussion was useful and that this point needs to be clarified in the document.
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.

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

[Bruno2] Given that the term “imposition” does not seem to be defined within the IETF, I would still favor a formal definition not using it. e.g. “BMI-MSD advertises the ability to increase the depth of the label stack by BMI-MSD labels”.
Alternatively, I’d propose the following rewording which seems clearer to me:
OLD: Imposition includes swap and/or push operations.
NEW: A swap operation counts as an imposition of one label; just like one push operation.

Thanks,
--Bruno

???

   Les

Thanks,
--Bruno

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

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 2 Oct 2018 18:19:40 +0000

Bruno –

Trimming the thread…

[Les3:] This gets into implementation specific issues that I would really like to avoid.
For example, some implementations perform one and only one  “operation”. Conceptually that may involve a swap and a push – but from the internal implementation POV it is simply one operation. And this may be true regardless of how many labels are involved. Other implementations might perform this in several discrete steps. The language we use here should not imply anything about how many labels are associated with a specific operation.

The term “increase” isn’t accurate because in the case of a swap there is no increase, yet the label which is replaced is counted.

https://tools.ietf.org/html/rfc3031#section-3.10 is relevant here.

The term “imposition” is generic – and as Alvaro has pointed out is used in RFC 4221. And the language proposed above does define the relationship between “swap and push” and “imposition”.

I appreciate your desire for clarity – and I am still open to new language – but at this point I still think what I proposed is  the most accurate.

   Les

Thanks,
--Bruno

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 2 Oct 2018 11:27:59 -0700

Gents,

I’m 100% with Les here, going into platform/asic specifics within this document would inevitably create ambiguity.

Cheers,
Jeff

---

From: <[email-masked]>
Date: Wed, 3 Oct 2018 08:34:15 +0000

Les,

Sent: Tuesday, October 02, 2018 8:20 PM

Bruno –

Trimming the thread…

[Les3:] This gets into implementation specific issues that I would really like to avoid.
[Bruno3] So am I
For example, some implementations perform one and only one  “operation”. Conceptually that may involve a swap and a push – but from the internal implementation POV it is simply one operation. And this may be true regardless of how many labels are involved. Other implementations might perform this in several discrete steps. The language we use here should not imply anything about how many labels are associated with a specific operation.
[Bruno3] Let’s not go into implementation specifics. Let’s reuse the terminology defined in the MPLS Architecture (RFC 3031) which does use the term “operation”.

https://tools.ietf.org/html/rfc3031#section-3.10 is relevant here.
[Bruno3] Absolutely. So let’s use RFC 3031 terminology

The term “imposition” is generic – and as Alvaro has pointed out is used in RFC 4221. And the language proposed above does define the relationship between “swap and push” and “imposition”.
[Bruno3] AFAIK, the term “imposition” is not defined in the IETF (If I missed it, please points to its definition). RFC 4271 uses it without defining it and RFC 2171 is informational.

[Bruno3] So let’s reuse RFC 3031 text verbatim
OLD: Imposition includes swap and/or push operations.

NEW: “When a LSR is capable of replacing the label at the top of the label stack with a
         specified new label, and then push N specified new labels onto the label stack, the LSR advertise a BMI-MSD of N+1.

Text is coming from the MPLS architecture which is the reference for everyone.
Thanks
--Bruno

   Les

Thanks,
--Bruno

---

From: <[email-masked]>
Date: Wed, 3 Oct 2018 08:37:00 +0000

Jeff,

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Tuesday, October 02, 2018 8:28 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN; Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Gents,

I’m 100% with Les here, going into platform/asic specifics within this document would inevitably create ambiguity.
Absolutely.
And nobody is asking for this.

Cheers
--Bruno

Cheers,
Jeff

Bruno –

Trimming the thread…

   Les

Thanks,
--Bruno