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) _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
