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

[Alvaro Retana <[e-mail]>]

On September 27, 2018 at 6:26:57 AM, Julien Meuric ([e-mail])
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.


 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.