Re: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing

Hannes Gredler <hannes@juniper.net> Thu, 07 November 2013 23:24 UTC

Return-Path: <hannes@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 29D5721E808A for <ospf@ietfa.amsl.com>; Thu, 7 Nov 2013 15:24:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.055
X-Spam-Level:
X-Spam-Status: No, score=-5.055 tagged_above=-999 required=5 tests=[AWL=1.544, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax6ZZwAfxEU0 for <ospf@ietfa.amsl.com>; Thu, 7 Nov 2013 15:24:33 -0800 (PST)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id C50F811E812F for <ospf@ietf.org>; Thu, 7 Nov 2013 15:24:31 -0800 (PST)
Received: from mail220-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 23:24:30 +0000
Received: from mail220-tx2 (localhost [127.0.0.1]) by mail220-tx2-R.bigfish.com (Postfix) with ESMTP id 12EBC340372; Thu, 7 Nov 2013 23:24:31 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zz98dI9371I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h1155h)
Received-SPF: pass (mail220-tx2: domain of juniper.net designates 157.56.236.101 as permitted sender) client-ip=157.56.236.101; envelope-from=hannes@juniper.net; helo=BY2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ;
Received: from mail220-tx2 (localhost.localdomain [127.0.0.1]) by mail220-tx2 (MessageSwitch) id 138386666992681_29345; Thu, 7 Nov 2013 23:24:29 +0000 (UTC)
Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.240]) by mail220-tx2.bigfish.com (Postfix) with ESMTP id 08604740062; Thu, 7 Nov 2013 23:24:29 +0000 (UTC)
Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 23:24:24 +0000
Received: from hannes-sslvpn-nc.jnpr.net (66.129.224.53) by pod51010.outlook.com (10.255.84.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 7 Nov 2013 23:24:23 +0000
MIME-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Gredler <hannes@juniper.net>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>
Date: Fri, 08 Nov 2013 00:24:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <B8D7A766-1FC0-4E64-AB18-CCD5DBAAB6C0@juniper.net>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0822770A@NKGEML512-MBS.china.huawei.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
X-Mailer: Apple Mail (2.1283)
X-Originating-IP: [66.129.224.53]
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "ospf@ietf.org" <ospf@ietf.org>, "isis@ietf.org" <isis@ietf.org>
Subject: Re: [OSPF] Inconsistency between OSPF extention and IS-IS extension for segment routing
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 07 Nov 2013 23:24:40 -0000

hi xuxiaohu,

On Nov 7, 2013, at 11:51 PM, Xuxiaohu wrote:
> OSPF extension draft proposes to use Extended Prefix Opaque LSA to carry SR-related attributes. Since the Extended Prefix Opaque LSA does not advertise reachability of the prefix, but only its attributes, the prefixes contained within those LSAs for building IP routing table (e.g., Router LSAs) can be aggregated when crossing area boundaries while the Extended Prefix Opaque LSAs containing prefix SIDs can be intactly propagated across area boudaries. The final effect is much similar to the mechanism defined in RFC5283.
> 
> In contract, IS-IS extension draft proposes to reuse those Extended IP Reachability TLVs which are used for building IP routing table to carry SR-related attributes. Although this choice has the benefit of propagating less LSAs, it loses the capability of aggregating routes when a crossing level boudaries. Furthermore, it requires the L1/L2 routers much be SR-capable.

and why is it a problem squeezing a few thousand transport loopbacks
across an ABR / L1L2 router ?

> Although these two drafts are proposing extensions to two different IGPs, IMHO, it would better to provide similar capabilities if possible, especially advoid destroying the existing capabilities of these two IGPs,  e.g., inter-area/level route aggregation capability.

most SPs running hierarchical IS-IS have turned on domain wide prefix leaking.
in fact doing aggregation in those environments is prohibitive in determining
the true cost to a particular BGP next hop. - so we do not really loose
much.

> To Peter Psenak,
> 
> I don't agree with your argrment that the reason that IS-IS extension draft made that choice is because there is no choice for IS-IS.

i second that opinion - the only extensible container for IP prefixes are the 
extended IP reach TLVs.

> In fact, you can use the signalling mechanism for Label Request which has been proposed in draft-xu-rtgwg-global-label-adv-00. That's to say, you can use separate Extended IP Reachability TLVs other than those for IP reachability advertisement to carry SR-related attibutes. Since the former TLVs are intened for advertising label bindings other than building IP routing table, the Metric field of these TLVs is set to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000). It's a normal approach for IS-IS. Of course, if SR is just used within a single level, it's good to use the existing approach proposed in the IS-IS extension draft.


keep in mind that we do not advertise a label per prefix but rather a global *index*.
it is my understanding that the semantics of draft-xu-rtgwg-global-label-adv-00
are quite different in the sense that absolute label values are being advertised here.

/hannes