Rob hi!
Lots of thanks for a prompt response.
My understanding of the difference in our positions goes as following:
1. We both agree that Segment Routing must be supported on existing
MPLS-capable devices
2. We both agree existing MPLS-capable devices are limited with regard to
the number of labels that can be pushed on the packet
a. I also claim that they are limited with regard to the total depths of
the label stack that they can parse, but this is a less important issue
3. We both agree that disregarding this limitation may result in TE
entities computing paths that cannot be implemented “as computed”.
a. I say that:
i. This
problem/conflict should be publicly acknowledged as part of the of the Segment
Routing problem statement
ii. It can be
quite acute if the operator tries to implement strict routes using Segment
Routing
iii. It is not
specific to the MPLS data plane
b. You say that:
i. The
problem/conflict is not new (and I fully agree with that)
ii. In most
cases this problem/conflict be resolved by some trick (e.g., by replacing the
originally computed strict TE path by another – loose? - one) and hence is not
worth mentioning
iii.
Nevertheless it may be mentioned in the document defining Segment Routing with
the MPLS data plane.
Do you think that this summary correctly represents our differences?
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
From: Rob Shakir [mailto:[email protected]]
Sent: Wednesday, January 06, 2016 7:09 PM
To: Martin Horneffer; [email protected]; Alexander Vainshtein
Cc: [email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [spring] Last Call: <draft-ietf-spring-problem-statement-06.txt>
(SPRING Problem Statement and Requirements) to Informational RFC
Hi All,
On 6 January, 2016 at 8:21:22 AM, Martin Horneffer
([email protected]<mailto:[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
