Hi All, On 6 January, 2016 at 8:21:22 AM, Martin Horneffer ([email protected]) wrote:
There's more than enough analyses that show that in typical carrier topologies traffic engineering with segment routing can achieve almost everything with just adding one or maybe two segments (labels). However those analyses are not neccessarily public, nor would I think an Internet Draft or RFC would be a good place for this kind of information. Maybe we should add a section to draft-ietf-spring-segment-routing-mpls saying that the operators are responsible for understanding the capabilities of the hardware they use, and to consider those when setting up their specific traffic-engineering tricks. I agree with Martin here, but I also don’t really agree that there is a new conflict that is being raised here. 1) SR must be realisable on existing iLER hardware where there may be limits in terms of the number of labels that can be pushed. SPRING does not mandate a requirement to be able to push an arbitrary number labels - like RSVP-TE does not mandate any particular head-end path computation requirements. If any change is to be made to this document it should be to highlight that there MAY be operational limitations w.r.t how complex the policy specified at the iLER can be (_or_ optimisations may be required to map one path onto another path - e.g., through binding a SID to a stack of labels on another device). I find this quite self-evident though. I have analysed label stack depth in a number of networks - and discussed it with hardware implementors in that context, and not found this to be a significant operational concern. The problem of publishing any analysis in this area is it contains information relating to topology (which may be considered sensitive); and to the operator’s policy requirements. 2) SR must be realisable on existing LSR hardware where there may be limits in terms of the depth of label stack that can be examined. SPRING is generally always realisable by forwarding on the outermost label (be in Node-SID or Prefix-SID) - in some cases, there may be a need to pop that label and forward on the following one (e.g., an anycast segment or where there is an Adj-SID that terminates on the node) which is a capability of the existing MPLS forwarding plane. The case of entropy is generally something that is complex, and the work on EL means that there is a requirement for a device to be able to find the ELI+EL pair in the label stack - this isn’t something that SR introduces. So, we should note that _as with anything that increases the label stack depth_, then if we have that ELI+EL deeper than where a midpoint can read to, then we may lose entropy. But this is no different than any other hierarchical LSPs that we have today - so again, I’m not sure I find this a necessary note. Essentially, what is being highlighted here is that certain MPLS forwarding planes may have optimised for a) limited push capabilities, or b) limited midpoint visibility into the label stack - these are optimisations that might have been acceptable in some deployments in the past, and may not be going forward. I would really want to consider whether there is anything that is not already noted in RFC 7325 that has been raised here. I also disagree that this should be in the problem statement document — this document tries to describe the requirements and use-cases for the SPRING architecture. It seems to me that if we do address these concerns, then really the document that they should be addressed in is draft-ietf-spring-segment-routing-mpls - which specifically deals with the realisation of the SPRING architecture in the MPLS data-plane. r.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
