Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Wed, 24 October 2018 10:06 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89FA130E7E for <lsr@ietfa.amsl.com>; Wed, 24 Oct 2018 03:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level:
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 matvHkKipQuS for <lsr@ietfa.amsl.com>; Wed, 24 Oct 2018 03:06:10 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7673130E23 for <lsr@ietf.org>; Wed, 24 Oct 2018 03:06:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20456; q=dns/txt; s=iport; t=1540375569; x=1541585169; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rT9S+QHcsAcPcjMmraamkN86p1lkN8yafamZaXIx22U=; b=fESst3JCflGuRMwMJQrUH5G23qvicfkb7D0ACSZwl6ZxvyNvJgo9nufx nUdA6IokiVImhj4CUjNykH0NlZsdu657nKFG50U7w/HgV1C7YnhEisUKd m+TcpBPNdk77eShU4vpThgkMboBqZbkhWnISYBQLZuDFQaS5IW1y3vbR4 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAADKQtBb/49dJa1ZChoBAQEBAQIBAQEBBwIBAQEBgVEFAQEBAQsBgQ1IL2Z/KAqDa4gYjBiCDZFOhUqBegsBASOESQIXgnMhNA0NAQMBAQIBAQJtHAyFOgEBAQEDHQYKXAIBCBEEAQEkBwICAjAdCAIEARIIgxqBHWQPpz2BLoQ+QIUiBYtiF4FBP4ERgmQugxsBAQMBgTKDLoJXAo48kCQJAoZkigofgVKEdYlwgmaJfIZwgn8CERSBJh04QYEUcBU7gmyCT4hKhT5viyOBHwEB
X-IronPort-AV: E=Sophos;i="5.54,420,1534809600"; d="scan'208,217";a="190226923"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 10:06:08 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w9OA68Lm016866 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <lsr@ietf.org>; Wed, 24 Oct 2018 10:06:08 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Oct 2018 05:06:08 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Wed, 24 Oct 2018 05:06:08 -0500
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
Thread-Index: AQHUalYXl2Z4skvnDEu/Rd//ZGkJo6UuJ/bg
Date: Wed, 24 Oct 2018 10:06:07 +0000
Message-ID: <a0d5bee9e8f34f2683f60a3d368b1d96@XCH-ALN-008.cisco.com>
References: <1E930DB6-2ED9-43A3-8EC7-338DAD1C3803@cisco.com>
In-Reply-To: <1E930DB6-2ED9-43A3-8EC7-338DAD1C3803@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.41.46]
Content-Type: multipart/alternative; boundary="_000_a0d5bee9e8f34f2683f60a3d368b1d96XCHALN008ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/jRAJ9T-DWvGbVzh7udZAM8W8unM>
Subject: Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 10:06:12 -0000

Hello All,

I support this simple but important extension.

A couple of minor comments on the draft:


1)     Sec 3 says


   A node that implements X-AF routing SHOULD advertise, in the

   corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6

   addresses local to the router that can be used by Constrained SPF

   (CSPF) to calculate MPLS TE LSPs.  In general, OSPF SHOULD advertise

   the IP address listed in the Router Address TLV [RFC3630<https://tools.ietf.org/html/rfc3630>] [RFC5329<https://tools.ietf.org/html/rfc5329>]

   of the X-AF instance maintaining the MPLS TE database, plus any

   additional local addresses advertised by the X-AF OSPF instance in

   its Node Local Address sub-TLVs.  An implementation MAY advertise

   other local X-AF addresses.

Generally speaking, should the IP address (TE router ID in common terms) which is candidate for inclusion in the Router Address TLV not be a MUST candidate for X-AF advertisement?

I also have a question about the first statement with the SHOULD in it. Consider we are using the TE topology from OSPFv2 to compute a tunnel for use with OSPFv3. Any IPv6 addresses associated with the OSPFv3 instance on a router would be advertised as a Node attribute and would not help identify a specific link. So practically, if any IPv6 addresses (if at all) were to be used for CSPF then it would just identify the node – in this case, isn’t advertising the IPv6 address (TE router ID used in Router Address TLV) sufficient?

For practical deployment, it think it would help if this was clarified that we really need only the TE Router ID Address to go X-AF in most/general cases and not the others?


2)     Isn’t the mapping algorithm in Sec 3 actually going to be used for IGP short-cut use-case with its reference to the IGP cost of the tunnel? If so, would a reference to rfc3906 be helpful in this document.

Thanks,
Ketan

From: Lsr <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
Sent: 23 October 2018 03:55
To: lsr@ietf.org
Subject: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt

This begins an LSR WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, November 13th , 2018. While its only an 8 page document, I added an extra week due to the IETF. Please let me know if anyone needs any more time.

https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/

Thanks,
Acee