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

Xuxiaohu <> Fri, 13 June 2014 10:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 520BE1A0460; Fri, 13 Jun 2014 03:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5YXC6dy3k_k7; Fri, 13 Jun 2014 03:12:13 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 416661B28DA; Fri, 13 Jun 2014 03:12:12 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BFJ44441; Fri, 13 Jun 2014 10:12:10 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 13 Jun 2014 11:10:00 +0100
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 18:09:53 +0800
From: Xuxiaohu <>
To: Peter Psenak <>, " list" <>, OSPF List <>
Thread-Topic: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR
Thread-Index: Ac+G3FEp8zYfOWcFTgiN+WbMbdhxlP//hQmA//91kcA=
Date: Fri, 13 Jun 2014 10:09:53 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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 10:12:15 -0000

Hi peter,

> -----Original Message-----
> From: Isis-wg [] On Behalf Of Peter Psenak
> Sent: Friday, June 13, 2014 4:32 PM
> To: Xuxiaohu; list; OSPF List
> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2
> extensions for SR
> Xiaohu,
> 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.

I see. For ISIS, you use the piggyback way (piggyback the label/sid advertisement on the reachability advertisement messages). For OSPFv2, you have no way to use the piggyback way anymore, so you defined a new LSA... That's why I said you prefer to the piggyback way. However, I don't think the piggyback way is much worthwhile from the perspective of flexibility and extensibility. 

> >
> > 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.

IMHO, the ISIS and OSPFv3 advertisement of the prefix SIDs should be decoupled from the prefix reachability advertisement as well:)  

> 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.

Does that mean the Binding sub-TLV in the OSPF-SR could not be used to advertise a range of prefix/sid pairs while the binding sub-TLV in the ISIS-SR could?

> > 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.

Make the prefix-sid as a sub-TLV of the Multi-Topology sub-TLV?

Best regards,

> regards,
> Peter
> >
> > 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
> >
> >
> > .
> >
> _______________________________________________
> Isis-wg mailing list