Re: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse

Jeff Tantsura <> Fri, 04 December 2015 21:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1E4F11A90E1 for <>; Fri, 4 Dec 2015 13:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mhJlwR_p-_vc for <>; Fri, 4 Dec 2015 13:31:27 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66B2E1A90E0 for <>; Fri, 4 Dec 2015 13:31:27 -0800 (PST)
X-AuditID: c618062d-f79d16d000001b1c-22-566205f50302
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F6.1E.06940.5F502665; Fri, 4 Dec 2015 22:30:29 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Fri, 4 Dec 2015 16:31:25 -0500
From: Jeff Tantsura <>
To: Chris Bowers <>
Thread-Topic: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse
Thread-Index: AQHRLtsgURFEVpb9Tke8VfuIrKZfDQ==
Date: Fri, 04 Dec 2015 21:31:24 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_9908429A3B314E448B246EDE883C051Aericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLrHW/cra1KYQc83U4sf610tWu7dY3dg 8liy5CeTx/Wmq+wBTFFcNimpOZllqUX6dglcGY9e3WYsWKBWsfvWfPYGxsMKXYycHBICJhJt My6wQthiEhfurWfrYuTiEBI4wihx8fBFRghnGaPEt/Vd7CBVbAIGEv+/HWcBsUUE1CT2X25l BrGZBRQkrl28xQZiCwt4Syw/3soIUeMj8fLyJiYIW0/i5LcmMJtFQEXi1pHjYDN5BewlJjTP BosLCURJ7Np+HWw+p0C0ROO+dWBzGIGu+35qDRPELnGJW0/mM0FcLSCxZM95ZghbVOLl43+s EDXJEs9/vWGFmC8ocXLmE5YJjCKzkLTPQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGL L2BkX8XIUVpckJObbmSwiREYPcck2HR3MN6f7nmIUYCDUYmHd8OjxDAh1sSy4srcQ4wSHMxK IrzMMkAh3pTEyqrUovz4otKc1OJDjNIcLErivIwMDAxCAumJJanZqakFqUUwWSYOTqkGRsaP vfz2HX624Srv07Osk095981b8dyiyZLlt/Ga849VWrgnHWdyuzBxYUGN1r1NrUpnHy6Wn391 xUS+tH8nlu6Pni8379xUmcs37zxleWxepHZ8d7bK5VW5gWkO+n/2Mgn0R7is13w/a2mm16GS uRMZqr/XR2zTfdVa4N5Xx+RrtPAfd8N3QyWW4oxEQy3mouJEAIbE3/+aAgAA
Archived-At: <>
Cc: OSPF WG List <>
Subject: Re: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Dec 2015 21:31:32 -0000

Hi Chris,

Thanks for your comments - sounds reasonable to me.
With inclusion of your comments - would you be satisfied with the solution proposed?

Thanks and have a great weekend!


On Dec 4, 2015, at 9:33 AM, Chris Bowers <<>> wrote:

Draft authors,

I would like to suggest the following text for the Backwards Compatibility section of this document.

Some deployments of LFA and remote LFA currently rely on link attributes (such as SRLG and admin groups) being carried in the TE Opaque LSA.  These applications are described in RFC 5286, RFC 7490,  draft-ietf-rtgwg-lfa-manageability, and draft-psarkar-rtgwg-rlfa-node-protection.  When a network is using an application that relies on link attributes being carried in the TE Opaque LSA , care should be taken to continue to advertise the appropriate link attributes in the TE Opaque LSA.

Note that a node that does not directly participate in remote LFA by originating repair tunnels itself may still need to continue originating link attributes in the TE Opaque LSA for use by other nodes in the network.   Therefore, when evaluating software upgrades or configuration changes which may result in changes to which link attributes are being advertised in the TE Opaque LSA, even for a subset of routers in the network,  care should be taken to evaluate the impact of that change across the entire network.


OSPF mailing list<>