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

Adrian, et al, 

I understand that this is chair's call and will certainly respect their decision. 

For what it worth, I would just like to point out that we are talking about a substantial amount of changes and the support votes may have been influence by the contents authors kindly agreed to remove. 

Thanks

Regards … Zafar 

On 3/17/18, 4:02 AM, "sfc on behalf of Adrian Farrel" <sfc-bounces@ietf.org on behalf of adrian@olddog.co.uk> wrote:

    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
    > 

    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    https://www.ietf.org/mailman/listinfo/sfc