Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Yingzhen Qu <yingzhen.qu@huawei.com> Thu, 04 May 2017 22:18 UTC

Return-Path: <yingzhen.qu@huawei.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECEF129469 for <ospf@ietfa.amsl.com>; Thu, 4 May 2017 15:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 11ETScvZN-JI for <ospf@ietfa.amsl.com>; Thu, 4 May 2017 15:18:51 -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 5032F127333 for <ospf@ietf.org>; Thu, 4 May 2017 15:18:50 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGA01967; Thu, 04 May 2017 22:18:47 +0000 (GMT)
Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 4 May 2017 23:18:47 +0100
Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Thu, 4 May 2017 15:18:42 -0700
From: Yingzhen Qu <yingzhen.qu@huawei.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, OSPF WG List <ospf@ietf.org>
Thread-Topic: WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"
Thread-Index: AQHSxQanGGW4vWTLFUe0gcAxuCky/6Hkn50AgAAdzDA=
Date: Thu, 04 May 2017 22:18:41 +0000
Message-ID: <594D005A3CB0724DB547CF3E9A9E810B3D5F19@dfweml501-mbx>
References: <D530EF1D.ACB7C%acee@cisco.com> <D53106AD.ACBA9%acee@cisco.com>
In-Reply-To: <D53106AD.ACBA9%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.49.90]
Content-Type: multipart/alternative; boundary="_000_594D005A3CB0724DB547CF3E9A9E810B3D5F19dfweml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.590BA8C8.00E8, 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: f65e8d31868241a97f6cc4c2edf4b3c2
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/gjavEOCfp39sbvYcXkPSjT_YUtQ>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 May 2017 22:18:53 -0000

Strong support +1 here.

The draft provides a generic way for the missing info and it’s needed.

Thanks,
Yingzhen

From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 04, 2017 1:27 PM
To: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Speaking as a WG member:

I believe we should move forward with this simple mechanism for OSPFv2 neighbors to learn each other’s interface ID. Both IS-IS and, more importantly, OSPFv3 learn the interface ID via their respective hello mechanisms. Just because one implementation has repurposed the Generalized MPL (GMPL) extensions described in RFC 4302 for interface ID learning is not a reason to preclude using the more generally accepted IGP Hello packet learning. Additionally, there is the undesirable side effect of TE LSAs resulting in inclusion in the TE topology for multiple implementations.

Finally, when the right technical direction is clear and there is rough consensus, the OSPF WG MUST NOT be obstructed.

Thanks,
Acee

From: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Date: Thursday, May 4, 2017 at 2:45 PM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"


This draft was presented in Chicago and there was acknowledgment that a solution was needed. The authors have asked for WG adoption and we are now doing a WG adoption poll. Please indicate your support or objection by May 20th, 2017.

Thanks,
Acee