I agree with Martin, I think we have discussed this at length and I wouldn't re-spin the debate (and come to the same conclusion again and again). The manageability section of the architecture draft mention that a node may want to signal its stack capabilities and we have igp extensions for that.
s. > On Jan 30, 2017, at 10:13 AM, Martin Horneffer <m...@nic.dtag.de> wrote: > > Hello Uma, > > what kind of label depth discussion are you thinking of? > > It seems to me this could easily become an endless discussion again. People > seem to have very different views on it. Thus I'm not sure whether it would > be suitable for this document. > > BTW: > > For my needs, bandwidth optimization is one of the major use cases for all > traffic engineering technologies such as SR or RSVP. > > We are currently supporting scientific university research about this, and > first results give strong confirmation that for bandwidth optimization in > real world networks you rarely need more than 1 additional segment. Or > rather, the additional efficiency gained by using mor than 1 additional > segment is very small. We compare a global real backbone network with current > routing, theoretical MCF optimization and realistic optimization with 1 (or 2 > or 3) additional traffic engineering segments (aka 2-SR, 3-SR, 4-SR). > Thus, from my point of view, an SR optimized network would typically have the > same label stack depth as a similarily RSVP optimized network in some places, > and a smaller label stack for the overall average . > > All other use-cases I found of serious interest so far all work with 1 > additional segment (i.e. label) at most. > > Best regards, Martin > > > Am 27.01.17 um 20:59 schrieb Uma Chunduri: >> Support. >> >> One quick comment: >> >> While section 3 correctly documents MPLS instantiation of SR - given the >> constructs SR has (ADJ SID for example) it's good to document SID/Label >> depth implications in the deployments. >> >> -- >> Uma C. >> >> -----Original Message----- >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Martin Vigoureux >> Sent: Friday, January 27, 2017 3:05 AM >> To: spring@ietf.org >> Cc: draft-ietf-spring-segment-routing-m...@ietf.org >> Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 >> >> Hello Working Group, >> >> This email starts a 2-week Working Group Last Call on >> draft-ietf-spring-segment-routing-mpls-06 [1]. >> >> ¤ Please read the document if you haven't read the most recent version yet, >> and send your comments to the list, no later than the *12th of February*. >> Note that this is *not only* a call for comments on the document; it is also >> a call for support (or not) to publish this document as a Proposed Standard >> RFC. >> >> ¤ We have already polled for IPR knowledge on this document and all Authors >> have replied. >> IPR exists against this document and has been disclosed [2]. >> >> Thank you >> >> M&B >> >> --- >> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ >> [2] >> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-mpls >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
