Hi Sasha, On Thu, Apr 6, 2017 at 1:46 PM, Alexander Vainshtein < [email protected]> wrote:
> 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. > Isn't it the same as the mplsMaxLabelStackDepth object defined in the MPLS LSR MIB (RFC 3813), then ? mplsMaxLabelStackDepth OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum stack depth supported by this LSR." ::= { mplsLsrObjects 11 } This is a read-only object, so I am wondering why MSD is read-write. Anyway, we could perhaps name it as MPLS Label Stack Depth (MLSD), instead of MSD,to indicate that it is not SR specific at all. We should also clarify this in draft-ietf-isis-segment-routing-msd and other MSD drafts to avoid misinterpretation, IMHO. > 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. > This looks interesting. If I understood you correctly, you are saying that a higher MSD value could be traded for a lower scale (in terms of LSP out segments). But, I wonder which h/w vendor currently support it this way. My understanding is that BCM supports only a fixed maximum impossible label stack depth on a packet. Regards, Muthu > > > Hope this clarifies my position. > > > > Regards, > > > Sasha > > > > Office: +972-39266302Muthu, > > > > Cell: +972-549266302 <+972%2054-926-6302> > > 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]> 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 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: [email protected] > > > > *From:* Muthu Arul Mozhi Perumal [mailto:[email protected]] > *Sent:* Wednesday, April 05, 2017 9:13 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, > > > > Thanks for your inputs. Comments inline.. > > > > On Wed, Apr 5, 2017 at 10:34 PM, Alexander Vainshtein < > [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 <+972%203-926-6302> > > Cell: +972-549266302 <+972%2054-926-6302> > > Email: [email protected] > > > > *From:* spring [mailto:[email protected]] *On Behalf Of *Jeff > Tantsura > *Sent:* Wednesday, April 05, 2017 7:57 PM > *To:* Muthu Arul Mozhi Perumal <[email protected]>; [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]> on behalf of Muthu Arul Mozhi > Perumal <[email protected]> > *Date: *Wednesday, April 5, 2017 at 09:38 > *To: *<[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] 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
