[mpls] Progress with draft-farrel-mpls-sfc

["Adrian Farrel" <[e-mail]>]

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)