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. > ____________________________________________________________ > _______________ >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
