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

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:zali@cisco.com]
> Sent: 17 March 2018 07:09
> To: adrian@olddog.co.uk; mpls@ietf.org; sfc@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-bounces@ietf.org
> on behalf of adrian@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
>     mpls@ietf.org
>     https://www.ietf.org/mailman/listinfo/mpls
> 