Zafar, The authors will surely post a new version.
Adoption is now, and always has been, a matter for the chairs. We are putty in their hands. As to your judgement of "lack of support", I snorted when I read your comment. I may have startled the other people on the train. I think you know how the IETF consensus process works and who gets to call it, but just in case, you may find RFC 7282 helpful. Ciao, Adrian -- Support an author and your imagination Tales from the Wood - Eighteen new fairy tales More Tales from the Wood - Eighteen MORE new fairy tales Tales from Beyond the Wood - A bumper collection of twenty-two new tales https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct at IETF-101 > -----Original Message----- > From: Zafar Ali (zali) [mailto:z...@cisco.com] > Sent: 17 March 2018 07:09 > To: adr...@olddog.co.uk; m...@ietf.org; s...@ietf.org; 'SPRING WG List' > Subject: Re: [mpls] Progress with draft-farrel-mpls-sfc > > Hi Adrian, et al, > > Thanks for addressing the concerns and responding to the objections to the > draft. > > Given the amount and nature of the expected changes and lack of support, I > would assume authors will resubmit and ask for WG adaptation on a revised > revision. > > Thanks > > Regards … Zafar > > On 3/16/18, 5:12 PM, "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
