Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt

Lucy yong <lucy.yong@huawei.com> Thu, 17 September 2015 19:01 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8561B3143; Thu, 17 Sep 2015 12:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 FpuQeuAoWRum; Thu, 17 Sep 2015 12:01:11 -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 3D7971B3103; Thu, 17 Sep 2015 12:01:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXS99655; Thu, 17 Sep 2015 19:00:59 +0000 (GMT)
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Sep 2015 20:00:57 +0100
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Thu, 17 Sep 2015 12:00:21 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: Lucy yong <lucy.yong@huawei.com>, Eric C Rosen <erosen@juniper.net>, "Keyur Patel (keyupate)" <keyupate@cisco.com>, Lou Berger <lberger@labn.net>, Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt
Thread-Index: AQHQ5Z2IbixHkljG+EWSCCy1qaMAZ54qBy8AgBcddOA=
Date: Thu, 17 Sep 2015 19:00:21 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571E7F3E@dfweml701-chm>
References: <20150819185950.7160.20919.idtracker@ietfa.amsl.com> <55E5CA6B.1000308@labn.net> <D20B2EC6.26AC6%keyupate@cisco.com> <CA+b+ERmEEO4_6_tdih68BAjrFVOxJ-VaAuAR=Ms=zj7NdF0YiA@mail.gmail.com> <55E5F8FA.6020108@labn.net> <D20B4955.26B4C%keyupate@cisco.com> <55E72562.5070405@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D8043@dfweml701-chm>
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571D8043@dfweml701-chm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.153.85]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/zn6OdcM6y6_WbjisT2is8iLbXa4>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2015 19:01:14 -0000

One comment:

Tunnel Encapsulation Extended Community defined in [RFC5512] is adopted and is specified in this draft. The changes are 1) can be attached to any AFI/SAFI which Tunnel Encapsulation attribute may be attached; 2) has a Remote Endpoint sub-TLV in Tunnel encapsulation Extended Community; 3) has no other sub-TLVs.

If tunnel encapsulation attribute is used to convey the tunnel property applying to a NLRI, no need to keep this extended community since tunnel encapsulation attribute can meet these 3 points.

In addition, this community specified here will not have the backward compatibility.

Regards,
Lucy 

  

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Wednesday, September 02, 2015 9:18 PM
To: Eric C Rosen; Keyur Patel (keyupate); Lou Berger; Robert Raszuk
Cc: idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt

My 2 cent is inline below.

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric C Rosen
Sent: Wednesday, September 02, 2015 11:36 AM
To: Keyur Patel (keyupate); Lou Berger; Robert Raszuk
Cc: idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-00.txt

Originally I was hoping to leave RFC5512 in place, and just have the tunnel-encaps draft update it.  But the feedback (both public and
private) has been overwhelmingly in favor of obsoleting RFC5512, with the goal of having a single RFC that specifies the tunnel encapsulation attribute.  Then folks won't have to figure out exactly which parts of
RFC5512 still apply and which parts don't.

With regard to encaps-SAFI, given that there are zero implementations (assuming that Lou withdraws his ;-)), zero deployments, and (as far as I can tell) no current interest in implementing or deploying it, I don't think it makes sense to carry it forward in the new document.

Of course, nothing stops someone from writing a new draft specifying something like the Encaps-SAFI, and specifying the semantics of attaching various attributes (including the tunnel encapsulation
attribute) to it.
[Lucy] For the given situation (RFC5512 and what the tunnel-encap draft covers), agree this approach. When specifying a new SAFI, the semantics in using the tunnel encapsulation attribute will be different from what the semantics described in the tunnel encap. draft, otherwise, no point to define a new SAFI for it. As Keyur mentioned in offline discussion, the tunnel encap. draft aims in for BGP and MP-BGP to support VXLAN/IP, NVGRE/IP transport in data plane, no intention to support any new BGP application.       

If the tunnel-encaps draft is to obsolete RFC5512, I think it will need to incorporate the material on the encapsulation extended community, and on the various sub-tlvs that are defined in RFC5512.  Note that the tunnel-encaps draft already specifies how the encapsulation extended community interacts with the tunnel encapsulation attribute.
[Lucy] if we expand the encapsulation attribute and allow it to work with certain AFI/SAFI, we may obsolete the encapsulation extended community or at least discourage use of it.

I believe that the material in RFC5566 (on using the tunnel encapsulation attribute to specify various sorts of IPsec tunnels) is complex enough to merit an RFC of its own.  So I would propose that the tunnel-encaps draft not include material from RFC5566, but that a separate rfc5566bis draft be prepared.
[Lucy] Agree. There are quite stuff related to tunnel security, good to cover all in a separate draft that obsoletes the RFC5566 as we talked offline.

Lucy





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

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