Hi Muthu,
Please see inline Cheers, Jeff From: Muthu Arul Mozhi Perumal <[email protected]> Date: Wednesday, April 5, 2017 at 11:02 To: Jeff Tantsura <[email protected]> Cc: <[email protected]> Subject: Re: [spring] Is MSD really a configurable attribute? 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? [jeff] No HW vendor, obviously if your device and SW it runs are vertically integrated (ie cisco/juniper router), there’s no difference, the MSD they should provide is the system/line card MSD as supported by the system 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? [jeff] I don’t really see a use case here, however if there’s one, it is easy to realize with a new “Type” 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? [jeff] as explained above, it depends, in a vertically integrated system it would be a system capability, if it is HW only (i.e.white box), it would be HW capability. The end result would be the same though, the path, as computed by a PCE must not have MSD larger than communicated 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.. [jeff] Link MSD is optional and provides additional information, in absence of Link MSD, Node MSD (that represents the lowest MSD supported by a system) should be used 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
