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