Adrian, on replacement of NSH. You will have to change the SF with this
proposal in Non proxy case so this proposal does not solve a brownfield case.
Which SF(s) support MPLS?
On 16/03/2018, 22:12, "mpls on behalf of Adrian Farrel" <mpls-boun...@ietf.org
on behalf of adr...@olddog.co.uk> wrote:
All,
The authors of draft-farrel-mpls-sfc have listened carefully to the reviews
and
comments starting with MPLS-RT reviews, continuing through the debate on
various
mailing lists, and including private emails sent to some of us.
We see three points to address:
1. Discussion of Segment Routing
In retrospect we should not have mentioned SR in this document. That's my
fault
and I'm sorry: I was trying too hard to get a document posted and to achieve
convergence with other ideas that had been floated, and I was not thinking
clearly.
Our plan is to remove all discussion of SR (specifically MPLS-SR) from this
document. That will leave a document that talks only about the MPLS data
plane
(as already defined with only the normal label operations of push, pop, and
swap) and the use of labels to encode the information included in the NSH.
2. What is the purpose of MPLS SFC?
I'm a bit surprised that we did not state this clearly in the document.
There is
some text but it is neither clear nor prominent.
I think that what happened was that *we* knew why we were writing it, and we
discussed the point with the SFC chairs, but we never wrote it down.
That needs to be fixed in the Abstract and the Introduction.
For the record: This document describes how Service Function Chaining
can be
achieved in an MPLS network by means of a logical representation of the NSH
in
an MPLS label stack. It does not deprecate or replace the NSH, but
acknowledges
that there may be a need for an interim deployment of SFC functionality in
brownfield networks. The mechanisms described are a compromise between the
full
function that can be achieved using the NSH, and the benefits of reusing the
existing MPLS forwarding paradigms.
3. Support for SFs that do not handle MPLS
There is, in our opinion no difference between an SF that does not handle
the
NSH in RFC 8300 and an SF that does not handle MPLS in this document. Both
need
to use an SFC Proxy as described in this document.
We already have a section on SFC Proxies, but it is late in the document. We
should fix that by highlighting the issue in the Introduction and pointing
to
the later section.
Thanks,
Adrian (in consultation with the co-authors)
_______________________________________________
mpls mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
