IETF Logo Mail Archive

Re: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis

Lucy yong <lucy.yong@huawei.com> Mon, 12 September 2016 20:14 UTC

Return-Path: <lucy.yong@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 8B64112B0CD; Mon, 12 Sep 2016 13:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.729
X-Spam-Level:
X-Spam-Status: No, score=-5.729 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, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 smqqQZ5JIQ61; Mon, 12 Sep 2016 13:14:57 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E3212B095; Mon, 12 Sep 2016 13:14:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRD92677; Mon, 12 Sep 2016 20:14:54 +0000 (GMT)
Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 12 Sep 2016 21:14:54 +0100
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Mon, 12 Sep 2016 13:14:51 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis
Thread-Index: AQHSAlOkn+Q2pJtzXUC9k8qn+VK6laBhbEEAgBToVqA=
Date: Mon, 12 Sep 2016 20:14:50 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572D165A@dfweml501-mbb>
References: <f1eda3f9-e097-098a-dd47-2386ab3f1a67@pi.nu> <D3EAF0DD.7C3BC%acee@cisco.com>
In-Reply-To: <D3EAF0DD.7C3BC%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.153.246]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.57D70CBF.0018, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 49cc9a0f625d39ec6127acf2fb33d700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/CXKIKg1sA5Den8-UZWXePjGKoUA>
Cc: "draft-rosen-mpls-rfc3107bis.all@ietf.org" <draft-rosen-mpls-rfc3107bis.all@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Subject: Re: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 12 Sep 2016 20:14:59 -0000

I support the WG adoption.

Comments:

Section 5 only mentions that BGP session may convert a SAFI-4 to a SAFI-1 then propagate. 
IMO: the local policy could allow a BGP session to convert a SAFI-1 to a SAFI-4 then propagate it if other BGP sessions enable SAFI-4. In this case, the node of the BGP session changes the next hop to itself and adds label(s) to NLRI before propagating the route.

I made comments on 6/20 about the last use case on page 16. It does not make a sense to me. Node S1 changes <L11, L12, ..., L1k> with <L21, L22, ... L2k> and programs its data plane so that when s1 processes a received MPLS packet whose top label is L21, it replaces L21 with <L11, L12, ... L1k> and then tunnels the packet to N1.  Since this is very unusual case, pls give a concrete use case of this.  

Thanks,
Lucy

On 8/29/16, 8:10 PM, "mpls on behalf of Loa Andersson"
<mpls-bounces@ietf.org on behalf of loa@pi.nu> wrote:

>Working Group,
>
>This is to start a two week poll on adopting 
>draft-rosen-mpls-rfc3107bis as an MPLS working group document.
>
>Please send your comments (support/not support) to the mpls working 
>group mailing list (mpls@ietf.org). Please give a technical motivation 
>for your support/not support, especially if you think that the document 
>should not be adopted as a working group document.
>
>There are no IPR disclosures against this document.
>
>All the authors has stated on the on the mpls wg mailing list that they 
>are not aware of any IPRs that relate to this document.
>
>The working group adoption poll ends September 14, 2016.
>
>/Loa
>
>MPLS wg co-chair.
>--
>
>
>Loa Andersson                        email: loa@mail01.huawei.com
>Senior MPLS Expert                          loa@pi.nu
>Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
>_______________________________________________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls

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

v2.23.0 | Report a Bug | By Email