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 <[email protected]> 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:[email protected]] On Behalf Of Martin Vigoureux
Sent: Friday, January 27, 2017 3:05 AM
To: [email protected]
Cc: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
