Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse
Chris Bowers <cbowers@juniper.net> Tue, 01 November 2016 16:04 UTC
Return-Path: <cbowers@juniper.net>
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 7D7001294FA for <ospf@ietfa.amsl.com>; Tue, 1 Nov 2016 09:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
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 Y6_CgnOzXDOt for <ospf@ietfa.amsl.com>; Tue, 1 Nov 2016 09:04:57 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0094.outbound.protection.outlook.com [104.47.32.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FDC12941D for <ospf@ietf.org>; Tue, 1 Nov 2016 09:04:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oABpMqeHVJgr/Yvfwk+aDxwD8gi/uPvjRx2CgqmpZtM=; b=kSkv9gS6A5ftBiT0GJ8LKHvzZ6kpCgj36hkdz8FzdrEzp8xkRCVqpm6JK1rHsRDH8x5HP6rEV6sL2jmOqbZNkGfwVSEk9GtDQ/rCpIjir0YICQQlZk9lDB2XCeFgqEUMltKHsR4byvUdVtVjSa0x1S/2z99rTn8hZY67HcXKOL0=
Received: from MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) by MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Tue, 1 Nov 2016 16:04:55 +0000
Received: from MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) by MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) with mapi id 15.01.0707.004; Tue, 1 Nov 2016 16:04:55 +0000
From: Chris Bowers <cbowers@juniper.net>
To: "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse
Thread-Index: AQHSL0m5NeYUU8oFQkSZ2vkcWoxM5KDEVEjw
Date: Tue, 01 Nov 2016 16:04:55 +0000
Message-ID: <MWHPR05MB2829BADEB7A0B1C499C008ABA9A10@MWHPR05MB2829.namprd05.prod.outlook.com>
References: <dbfc809d-83d3-4643-cf5a-11fbe426c327@cisco.com>
In-Reply-To: <dbfc809d-83d3-4643-cf5a-11fbe426c327@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net;
x-originating-ip: [66.129.239.15]
x-ms-office365-filtering-correlation-id: 646064aa-60b7-410f-b678-08d40270d2a1
x-microsoft-exchange-diagnostics: 1; MWHPR05MB2829; 7:RDsX+RdY70nAFV4lYgMO3YKRtebrLYlsKmnkhPAwJHHtYLAh/1tce3v25dVNvccPKCcumoA6+TM3pPGL5fd2OHfq6OXsRwX5SkxwImuvjSwNEVf7TpBT3yzhK8JIc2QO45RPRit6CNRjmU2S1Jv28SIOA3GkOWxzFTXPPcyiD12vlc06CzFv/eyxvz+IAM0RykkpfvCDCDAhVGEtNYsPEe8WzDaJVgp4Yi9copEGpEX9gv6PCwrEfeVL6EyVn/pmV3pN5xdHmasiI6wW70Ty2Rf++ix+Qx+CGaNZ/WqPOg608RVFjiSgjuGTWfM7lS9Bj8yPoIQeEOAucDA3M1sH+UBAdeTKOmScV3uZQ7C5pDs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR05MB2829;
x-microsoft-antispam-prvs: <MWHPR05MB2829D6DA859F7DE31857EB11A9A10@MWHPR05MB2829.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:MWHPR05MB2829; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2829;
x-forefront-prvs: 01136D2D90
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(189002)(37854004)(13464003)(86362001)(106116001)(5002640100001)(106356001)(2351001)(6916009)(101416001)(19580395003)(97736004)(105586002)(189998001)(99286002)(33656002)(92566002)(2950100002)(7736002)(15975445007)(66066001)(2900100001)(54356999)(76176999)(19580405001)(305945005)(50986999)(2906002)(8936002)(77096005)(7846002)(9686002)(87936001)(110136003)(7696004)(81156014)(6116002)(3846002)(102836003)(68736007)(2501003)(230783001)(11100500001)(8676002)(4326007)(122556002)(5660300001)(1730700003)(81166006)(74316002)(76576001)(586003)(10400500002)(3280700002)(3660700001)(5640700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2829; H:MWHPR05MB2829.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2016 16:04:55.7016 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2829
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/xJT2XpdxmwHzgNB_TYuSjnEJYHc>
Cc: "draft-ppsenak-ospf-te-link-attr-reuse@tools.ietf.org" <draft-ppsenak-ospf-te-link-attr-reuse@tools.ietf.org>
Subject: Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 01 Nov 2016 16:04:59 -0000
OSPF WG, I do not support adoption of draft-ppsenak-ospf-te-link-attr-reuse-03 as a WG document. The draft-ppsenak-ospf-te-link-attr-reuse has highlighted a real issue that needs to be addressed. OSPF does not have a standardized mechanism to determine if RSVP is enable on a link. Implementations have instead relied on the presence of the TE Opaque LSA with a given Link TLV to infer that RSVP is enabled on a link. This presents a problem when one wants to use TE attributes carried in the Link TLV of the TE Opaque LSA in an environment with both RSVP and non-RSVP applications. There is currently no standardized way for a TE attribute to be advertised on a link for use by a non-RSVP application without causing existing implementations to infer that RSVP is enabled on the link. The solution proposed by draft-ppsenak-ospf-te-link-attr-reuse is to allow the TE attributes originally defined to be carried in the Link TLV of the TE Opaque LSA to be advertised in the Extended Link TLV of the Extended Link Opaque LSA. The current draft proposes allowing the advertisement of the following attributes in either the Link TLV of TE Opaque LSA or the Extended Link TLV of the Extended Link Opaque LSA. Remote interface IP address Link Local/Remote Identifiers Shared Risk Link Group Unidirectional Link Delay Min/Max Unidirectional Link Delay Unidirectional Delay Variation Unidirectional Link Loss Unidirectional Residual Bandwidth Unidirectional Available Bandwidth Unidirectional Utilized Bandwidth There has already been a great deal of discussion on the OSPF list about the potential problems caused by moving or replicating the advertisement of existing TE attributes in different containers. It can create problems for both implementers and network operators when the same attribute can be advertised in multiple places. Implementers need to apply some logic to figure out where to advertise and where to find the value of the attribute that should be used in a given set of circumstances. Different implementers may apply subtly different logic. Network operators will have to test the different implementations against each other to make sure that the logic applied produces the desired result in their network. In many cases, they will also have to test these different new implementations against existing software that only sends and receives TE attributes in the TE Opaque LSA. A few months ago we published draft-hegde-isis-advertising-te-protocols which addresses the same basic issue in ISIS. The same approach also works for OSPF, so we recently published draft-hegde-ospf-advertising-te-protocols. draft-hegde-ospf-advertising-te-protocols-00 proposes a straightforward solution to the problem described above. It defines a new TE-protocol sub-TLV to be carried in the Link TLV of the TE Opaque LSA to indicate which TE protocols are enabled on a link. Currently it defines values for RSVP and SR. The draft also provides clear backward compatibility mechanisms for routers that have not yet been upgraded to software that understands this new sub-TLV. The approach in draft-hegde-ospf-advertising-te-protocols-00 is straightforward. It leaves the existing TE attributes in the TE Opaque LSA, allowing implementations to continue to advertise and find traffic engineering the information in the TE Opaque LSA. The latest version of draft-ppsenak-ospf-te-link-attr-reuse (the -03 version) added an Application Bit Mask. The idea of the Application Bit Mask is to allow different values of TE attributes to be defined for different applications. It is not clear to me that this part of the draft addresses an existing problem. The text gives one example use case involving having different sets of SRLGs for SR and for LFA. If network operators do in fact have a need for different sets of SRLGs, then we should figure out what is needed and propose a solution based on what is actually needed. This draft would also provide encodings to advertise different Link Delay and Link Loss values for a given link. I can't think of a potential use case for that, since Link Delay and Link Loss are measured values. Overall, this draft has been useful in highlighting the existing lack of a standardized mechanism to indicate whether or not RSVP is enabled on a link. However, I don't think that the solution it proposes is a good starting point for the WG to address this issue. Chris -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Abhay Roy Sent: Wednesday, October 26, 2016 12:28 AM To: ospf@ietf.org; draft-ppsenak-ospf-te-link-attr-reuse@tools.ietf.org Subject: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse Dear WG, Authors of draft-ppsenak-ospf-te-link-attr-reuse would like to poll the WG for adoption of this document as a WG Draft. Please send your opinions / concerns. This begins the two week WG adoption poll which will conclude on Nov 9th 2016. Authors, we need your explicit response on this thread to capture your answer on if you are aware of any IPR related to this draft. Regards, -Abhay _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
- [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te… Abhay Roy
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Les Ginsberg (ginsberg)
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Jeff Tantsura
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Yingzhen Qu (yiqu)
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Jeff Tantsura
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Acee Lindem (acee)
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Peter Psenak
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Ketan Jivan Talaulikar (ketant)
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Chris Bowers
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Peter Psenak
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Acee Lindem (acee)
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Jeff Tantsura
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Rob Shakir
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Les Ginsberg (ginsberg)
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Jeff Tantsura
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Shraddha Hegde
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… bruno.decraene
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Acee Lindem (acee)
- [OSPF] 答复: WG Adoption Poll for draft-ppsenak-osp… Xuxiaohu
- Re: [OSPF] WG Adoption Poll for draft-ppsenak-osp… Huaimo Chen