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

Peter Psenak <ppsenak@cisco.com> Sat, 05 December 2015 13:39 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395B01B2A22 for <ospf@ietfa.amsl.com>; Sat, 5 Dec 2015 05:39:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 kFijuQYF_4pE for <ospf@ietfa.amsl.com>; Sat, 5 Dec 2015 05:39:24 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C64C1B2A20 for <ospf@ietf.org>; Sat, 5 Dec 2015 05:39:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1721; q=dns/txt; s=iport; t=1449322764; x=1450532364; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Dd/KagA+SqNQpGFN3GfLaP6z8v6/A8hFu1eSZWy49uc=; b=b/1lucSVJ9WLbOfCCUKUncc5Qd5ChghgRymn8ZtUrBmKNRJLxCSbNfPS Fkg/Wu5FywBhtbflngR7+o68o9v+hNmwLviRZDCiiX9A1OYTOQOI0KHBN GtWHIE+0ZPz3Gk/NsAsuatE9Q2UNpker36YUIfwCxOdT4xNxjSOrOLcF+ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAAj52JW/xbLJq1ehA1uv0UXCoI9g?= =?us-ascii?q?zACgW4BAQEBAQGBC4Q0AQEBAwEBAQE1LwcKBgsLDgoJFg8JAwIBAgEVMAYBDAY?= =?us-ascii?q?CAQGIIwgNwBMBAQEBAQEBAQEBAQEBAQEBAQEXBIZUhH2ES4RwAQSWYY08iSGTT?= =?us-ascii?q?GOEBT00hCeBSAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,385,1444694400"; d="scan'208";a="607024424"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2015 13:39:21 +0000
Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tB5DdKbs001984; Sat, 5 Dec 2015 13:39:20 GMT
Message-ID: <5662E908.1000403@cisco.com>
Date: Sat, 05 Dec 2015 14:39:20 +0100
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Chris Bowers <cbowers@juniper.net>, OSPF WG List <ospf@ietf.org>
References: <DM2PR05MB62385A916E792E20E1EB583A90C0@DM2PR05MB623.namprd05.prod.outlook.com>
In-Reply-To: <DM2PR05MB62385A916E792E20E1EB583A90C0@DM2PR05MB623.namprd05.prod.outlook.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/9xpHHGKRUpujJzduG6RVotz3kKA>
Subject: Re: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 05 Dec 2015 13:39:26 -0000

Hi Chris,

On 12/4/15 18:32 , 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.

Here I would add:

"Doing so would make the link part of the traffic engineering topology 
as defined in RCF 3630."

"Advertising the particular link attribute in TE Opaque LSA does not 
prevent the same attribute to be advertised in Extended Prefix LSA for 
the same link."

thanks,
Peter

> 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.
> -------
> Thanks,
> Chris
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>