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

James N Guichard <james.n.guichard@huawei.com> Sat, 17 March 2018 11:30 UTC

Return-Path: <james.n.guichard@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FFD12D885; Sat, 17 Mar 2018 04:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvedUP2VY-l9; Sat, 17 Mar 2018 04:30:18 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9B812D80E; Sat, 17 Mar 2018 04:30:18 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id AFC46CD1D71FB; Sat, 17 Mar 2018 11:30:14 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 17 Mar 2018 11:30:16 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML701-CHM.china.huawei.com ([169.254.3.93]) with mapi id 14.03.0382.000; Sat, 17 Mar 2018 04:30:10 -0700
From: James N Guichard <james.n.guichard@huawei.com>
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "mpls@ietf.org" <mpls@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, 'SPRING WG List' <spring@ietf.org>
Thread-Topic: [mpls] Progress with draft-farrel-mpls-sfc
Thread-Index: AdO9ayKD4JPnXXJ8T2+9KxmqpJz/qwAYKD8AAAV59YA=
Date: Sat, 17 Mar 2018 11:30:09 +0000
Message-ID: <BF1BE6D99B52F84AB9B48B7CF6F17DA3134ED142@sjceml521-mbs.china.huawei.com>
References: <019501d3bd6b$657d7ef0$30787cd0$@olddog.co.uk> <BB36A9A4-284C-4B36-BDE0-6B919273AB02@nokia.com>
In-Reply-To: <BB36A9A4-284C-4B36-BDE0-6B919273AB02@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.151.56]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/TWpP5EKrnPVmT0g9K4Ukq_IG4xI>
Subject: Re: [mpls] Progress with draft-farrel-mpls-sfc
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Mar 2018 11:30:26 -0000

Hi Adrian,

-----Original Message-----

     
    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.

Jim> from the SF perspective yes as it has no clue what is being used between SFFs. However, this is IMHO not a true statement from an SFF perspective;  consider metadata as an example. Yes I know you can cobble together a nice long label stack to try and mimic NSH behavior but seriously I do not see this as a viable solution and even if it was it would not be normal MPLS forwarding behavior so would not work for brownfield. Same comment for MPLS-SR FWIW.

Jim
    
    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