Hi Jeff, Thanks for your response. Comments inline..
On Wed, Apr 5, 2017 at 10:26 PM, Jeff Tantsura <[email protected]> wrote: > 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. > Since MSD is not derived from h/w capabilities, did you actually mean that no vendor provides an API to query the underlying h/w label imposition limit? MSD being a s/w attribute, I believe it can take any value from 1 to the label imposition limit supported by the h/w? > > > 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. > Ok, do we expect MSD types to be tied to the application/service, say one MSD to be used for L3VPN service on a node, one for L2VPN etc? > 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. > Again, guess you meant the label imposition limit of the h/w here? > > > 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. > Agree, this becomes really tricky with a router supporting different NPU types/generations, so node MSD is one thing a PCE can rely on for sure.. Regards, Muthu > > > 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 >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
