Muthu, Two clarifications: 1. The number of “service-related” labels depends on the service. Flow-aware PWs (RFC 6391<https://tools.ietf.org/html/rfc6391>), entropy labels for IP VPN (RFC 6790<https://tools.ietf.org/html/rfc6790>) and, possibly, using GAL as a VCCV Indicator (RFC 7708<https://tools.ietf.org/html/rfc7708>) give you some examples. To the best of my understanding, the MSD value reflects maximum imposable label stack depth that includes all labels, it is not SR-specific at all.
2. I believe that I have already explained how the same HW may support different MSD values depending on usage of some HW resources. In the example I’ve given, if a single “egress encapsulation database” entry can contain “N” labels, and “M” such entries are available in the forwarding HW memory, the user may configure MSD to N and expect HW to support “M”LSP out-segments, or he/she may configure MSD to (2*N) and expect forwarding HW to support only (M/2) LSP out-segments. Hope this clarifies my position. Regards, Sasha Office: +972-39266302Muthu, Cell: +972-549266302 Email: [email protected] From: Muthu Arul Mozhi Perumal [mailto:[email protected]] Sent: Wednesday, April 05, 2017 9:54 PM To: Alexander Vainshtein <[email protected]> Cc: Jeff Tantsura <[email protected]>; [email protected]; Shell Nakash <[email protected]>; Michael Gorokhovsky <[email protected]>; Ron Sdayoor <[email protected]>; Rotem Cohen <[email protected]> Subject: Re: [spring] Is MSD really a configurable attribute? Hi Saha, Please see inline.. On Wed, Apr 5, 2017 at 11:54 PM, Alexander Vainshtein <[email protected]<mailto:[email protected]>> wrote: Muthu hi, Two points: 1. My reading of the text in the draft to which you refer is different: from my POV it means that the MSD advertised in the protocol must take into account all labels that can be pushed on a packet (including L3VPN or PW “application” labels, entropy labels/flow labels) That makes MSD same as the label imposition limit supported by the h/w, right? What is the motivation for s/w configuring the MSD on a node then? My interpretation was that the label stack has 2 parts -- the service part and the LSP part. MSD is the maximum no. of SIDs that can go into the LSP part. Now, MSD can be modified by the s/w and advertised in IGP/PCEP/BGP-LS depending on what MPLS services the node provides.. Regards, Muthu and not just the labels that represent the list of SIDs for SR-TE 2. When I mentioned increase of MSD at expense of some other parameters, I had in mind something else. E.g., if the label stack to be pushed on the packet is stored in a fixed size entry in the “egress encapsulation” database in the forwarding HW, one option would be to use one such entry (with the resulting limit on the MSD) per LSP, while another option would be to use a linked list of such entries per LSP. This would increase the MSD at the expense of the number of LSP out segments that the device can support. Hope this helps. Regards, Sasha Office: +972-39266302<tel:+972%203-926-6302> Cell: +972-549266302<tel:+972%2054-926-6302> Email: [email protected]<mailto:[email protected]> From: Muthu Arul Mozhi Perumal [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, April 05, 2017 9:13 PM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Cc: Jeff Tantsura <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Shell Nakash <[email protected]<mailto:[email protected]>>; Michael Gorokhovsky <[email protected]<mailto:[email protected]>>; Ron Sdayoor <[email protected]<mailto:[email protected]>>; Rotem Cohen <[email protected]<mailto:[email protected]>> Subject: Re: [spring] Is MSD really a configurable attribute? Hi Saha, Thanks for your inputs. Comments inline.. On Wed, Apr 5, 2017 at 10:34 PM, Alexander Vainshtein <[email protected]<mailto:[email protected]>> wrote: Jeff, Muthu and all, I concur with Jeff – MSD is not defined just by HW but also by SW. Same HW may yield different MSD values with SW defining different data paths thru it. And it may well be a matter of tradeoff where higher MSD could be achieved at the expense of some other parameters. draft-ietf-isis-segment-routing-msd has the foll: In case, there are additional labels (e.g. service) that are to be pushed to the stack - MSD SHOULD be adjusted to reflect that If the node needs 2 labels to support L3VPN and the h/w label imposition limit is 6 (say), then MSD could be set to 4 to support up to 4 SIDs in a SR-TE tunnel, right? OTOH, if the node is just a 'P' router, MSD could be set as high as 6. Is that what you mean by trading off higher MSD at the expense of something else? Regards, Muthu This is exactly why MSD should be treated as a configurable attribute. Of course this does not preclude implementations when exactly one MSD value would be supported. Regards, Sasha Office: +972-39266302<tel:+972%203-926-6302> Cell: +972-549266302<tel:+972%2054-926-6302> Email: [email protected]<mailto:[email protected]> From: spring [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Jeff Tantsura Sent: Wednesday, April 05, 2017 7:57 PM To: Muthu Arul Mozhi Perumal <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [spring] Is MSD really a configurable attribute? Hi Muthu, Thanks for your comments! MSD is a configurable attribute, it is not derived directly from HW capabilities, in fact no vendor today provides an API to query underlying HW for the MSD supported, there’s also dependency on SW support. That’s why we have introduced “Type” field, so more than a single MDS type could be signaled, as of now, we have only defined “Base” Type, that describes total number of SID’s supported. I’d expect vendors to provide clear guidance wrt MSD semantics, in disaggregated case, when HW and SW are coming from different vendors, I’d expect HW to be the limiting factor and HW vendors to provide an API to query for the MSD supported and auto-populate the value in IGPs. I have reached out to BCM and Barefoot, plan to discuss with more HW vendors. Per node vs per LC capability – even on a same generation NPU, depending on revision, MSD supported could vary drastically, routers with 3 generations of line cards are not an exception either, so MSD per adj/interface is a rather valuable information to a PCE if a tunnel could exit over different line cards. Per node MSD limits computation to the lowest value supported by the node. Hope this helps, Cheers, Jeff From: spring <[email protected]<mailto:[email protected]>> on behalf of Muthu Arul Mozhi Perumal <[email protected]<mailto:[email protected]>> Date: Wednesday, April 5, 2017 at 09:38 To: <[email protected]<mailto:[email protected]>> Subject: [spring] Is MSD really a configurable attribute? draft-ietf-spring-sr-yang seems to describe Maximum SID Depth (MSD) as a read-write attribute that is configurable on the node, but I really wonder how many vendors actually support changing the MSD on a node. Suppose a node is capable of pushing a maximum of K labels in h/w and the node MSD is configured as K, then a SR-TE tunnel on the node can specify up to K SIDs. This means the node will not be able to push a VPN label, so cannot do L3VPN/L2VPN. Given that a miss-configuration like would result in service failure, is there a real motivation for changing MSD on a node? Should MSD be a node capability instead, like the 'readable-label-stack-depth' defined in the yang draft? Regards, Muthu _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
