Les, Thanks for the follow up. Please see inline [Bruno2]
From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Friday, September 28, 2018 7:57 PM To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: RE: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15 Bruno – Inline. From: [email protected] <[email protected]> Sent: Friday, September 28, 2018 1:02 AM To: Les Ginsberg (ginsberg) <[email protected]>; Alvaro Retana <[email protected]>; MEURIC Julien IMT/OLN <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] 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 protected]] On Behalf Of Les Ginsberg (ginsberg) Sent: Thursday, September 27, 2018 8:45 PM To: Alvaro Retana; MEURIC Julien IMT/OLN Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]>> Sent: Thursday, September 27, 2018 10:54 AM To: Julien Meuric <[email protected]<mailto:[email protected]>>; Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]>) 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.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
