Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR

Peter Psenak <> Fri, 13 June 2014 08:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A32A1A0312; Fri, 13 Jun 2014 01:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 91PfOaVfmNvL; Fri, 13 Jun 2014 01:31:40 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B28871A021E; Fri, 13 Jun 2014 01:31:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3804; q=dns/txt; s=iport; t=1402648300; x=1403857900; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1g4YqG6oqmuQc4K3tjw/8q0WrQZ4dyN52YJYE3B/oaw=; b=m1KutfkD33yG6fp7yvgudpsLWe7yCyRwdKkiczgS5OUbBHpGj5qYgzGs GaJN0v6J0DLDDvRJ1/LjpWxDaR0nWyZSEK/DnvMOzIVfYzSwfpo/58sof uK1On4UM4wqbF0h8sfbjArSJJ5XrME+fSLnDQEf6pqMGrk3SOXIXdi6SU M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.01,470,1400025600"; d="scan'208";a="79960486"
Received: from (HELO ([]) by with ESMTP; 13 Jun 2014 08:31:38 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id s5D8Vb3w015408; Fri, 13 Jun 2014 08:31:37 GMT
Message-ID: <>
Date: Fri, 13 Jun 2014 10:31:37 +0200
From: Peter Psenak <>
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: Xuxiaohu <>, " list" <>, OSPF List <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Jun 2014 08:31:42 -0000


please see inline:

On 6/13/14 09:51 , Xuxiaohu wrote:
> Hi all,
> There are some encoding inconsistencies between OSPFv2 extensions and ISIS extensions for SR as follows:
> 1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the IP reachability advertisement. In OSPF-SR, the prefix-sid advertisement is piggybacked on OSPF Extended Prefix LSA which is used to advertise other attributes associated with the prefix, rather than the reachability. IMHO, the OSPF encoding is more flexible since the label distribution and the reachability advertisement are independent. As a result, the route summary on area boundaries at least can be enabled as before. Besides, the prefix-SID sub-TLV can be used to advertise a range of prefix/SID pairs (see item2). In fact, ISIS allows us to do the same way as OSPF with a much lower cost (see section 3 of Of course, it seems that you co-authors prefer to the piggyback way.

OSPF LSAs that are used to advertise the prefixex are not extensible, so 
we had to define a new LSA for the purpose of advertising a prefix 
related attributes. ISIS is different, as they can add sub-TLVs to 
existing TLVs.

> 2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to advertise an SID for a single prefix. And it relays on the SID/Label Binding TLV to advertise a range of prefix/SID pairs. In contrast, In OSPF-SR, the prefix-sid sub-TLV can be used to specify a range of addresses and their associated Prefix SIDs. By the way, in the 4.3.  SID/Label Binding sub-TLV. it has the following text: "Range Size: usage is the same as described in Section 4.2." Did you co-authors want to propose two ways (i.e., prefix-sid sub-TLV and SID-Label Binding sub-TLV) to achieve the same goal (i..e, advertise a range of prefix/SID pairs)?

because in OSPF advertisement of the prefix SID is decoupled from the 
advertisement of prefix reachability, we can afford to advertise the 
range of SIDs in the prefix-SID sub-TLV as such.

No, we do not define two ways to achieve the same thing. Binding TLV is 
used for a different purpose and the same usage is only applicable to 
the Range semantics, not to the whole Binding TLV.

> 6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID field since the MT-ID field is already contained in the parent TLV of the prefix-SID sub-TLV. In OSPF, the MT-ID field is contained in the Prefix SID Sub-TLV since the parent TLV of the prefix-sid sub-TLV doesn't contain that MT-ID field. IMHO, it's better to contain the MT-ID in the parent prefix-specific TLV of the prefix-SID sub-TLV. In other words, why not contain the MT-ID in the OSPF Extended Prefix TLV, instead of the prefix-sid sub-TLV (see section 3 of

no, we do not want to put the MT-ID in the OSPF Extended Prefix TLV. The 
reason is that attributes are MT specific, not the prefix itself - e.g. 
you may want to advertise different metrics for the same prefix in 
different topologies, not the same prefix twice.


> Anyway, although it is unavoidable for us to define extensions to both ISIS and OSPF for the same thing due to the fact that both protocols have been widely used, could we try our best to keep the encodings of ISIS and OSPF as consistent as possible for the same functionality? In this way, once someone has read the ISIS extension draft, he or she can easily think of what has been done in the OSPF extension draft accordingly, and vice verse.
> Best regards,
> Xiaohu
> _______________________________________________
> Isis-wg mailing list
> .