Hi Wim, Thanks for reading the draft so carefully.
> 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? This is not about "replacing" the NSH. As you'll see from point 2, below, this is about providing an interim / migration technology. Clearly (and I think you agree) in the case where an SF is not SFC-aware, a proxy must be used. That proxy may be a bump in the wire between the SFF and SF, a module of the SFF, or a module of the SF. In the case of PNFs, only the first two options are available. In the case of a VNF, all three options exist. Now, let us recall where we are starting from. There are PNFs and there are VNFs built to look like PNFs. These SFs do not support MPLS or NSH. Similarly, there are routers that do not support the NSH. Now, of course, we would all love to sell major upgrades so that every component of the network is SFC-aware. But we would also like to start deploying SFC into existing network infrastructure. So your question misses the point. The question to ask is which brownfield routers and SFs support NSH? Cheers, Adrian > 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
