Hi Uma, We'll add a couple of statements on that matter.
Thanks. s. -----Original Message----- From: Uma Chunduri [uma.chund...@huawei.com] Received: Monday, 30 Jan 2017, 6:40PM To: Stewart Bryant [stewart.bry...@gmail.com]; Stefano Previdi (sprevidi) [sprev...@cisco.com]; Martin Horneffer [m...@nic.dtag.de] CC: draft-ietf-spring-segment-routing-m...@ietf.org [draft-ietf-spring-segment-routing-m...@ietf.org]; spring@ietf.org [spring@ietf.org]; Martin Vigoureux [martin.vigour...@nokia.com]; m...@ietf.org [m...@ietf.org] Subject: RE: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Hi Martin, Stefano, >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. Sorry, that was not at all my intention to get into an endless discussion. Being an SR MPLS data plane document, I felt discussion or reference to SID depth related aspects would be important. This is one of the aspects we contended with, when SR is being discussed in MBH deployments in my previous organization. > 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. I am fine with referencing both or a summary as pointed by Stewart below at some appropriate place in the document. -- Uma C. -----Original Message----- From: Stewart Bryant [mailto:stewart.bry...@gmail.com] Sent: Monday, January 30, 2017 3:51 AM To: Stefano Previdi (sprevidi) <sprev...@cisco.com>; Martin Horneffer <m...@nic.dtag.de> Cc: draft-ietf-spring-segment-routing-m...@ietf.org; spring@ietf.org; Martin Vigoureux <martin.vigour...@nokia.com>; Uma Chunduri <uma.chund...@huawei.com>; m...@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Stefano, This is the document that someone interested in SR from and an MPLS perspective may well start with. A discussion on the issue of label stack depth and the practical constrains is thus very much in scope. The fact that you had a debate in the past immediately points to the need for a summary of the key issues and conclusions in this document. Stewart On 30/01/2017 11:27, Stefano Previdi (sprevidi) wrote: > 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-m >>> pls/ >>> [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
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
