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