Alvaro – Thanx for helping drive this to closure. Please see inline.
From: Alvaro Retana <aretana.i...@gmail.com> Sent: Thursday, September 27, 2018 10:54 AM To: Julien Meuric <julien.meu...@orange.com>; Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: lsr@ietf.org; draft-ietf-isis-segment-routing-...@ietf.org; rtg-...@ietf.org; rtg-...@ietf.org Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15 On September 27, 2018 at 6:26:57 AM, Julien Meuric (julien.meu...@orange.com<mailto:julien.meu...@orange.com>) 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. 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?? 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.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
