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

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Jun 2014 07:51:44 +0000

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 http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of course, it seems that you co-authors prefer to the piggyback way. 

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)?

3. In ISIS-SR, the range of SID/Label values is advertised by the SR Capability sub-TLV. Meanwhile, the data-plane capability is advertised by such sub-TLV as well. In OSPF-SR, the range of SID/Label values is advertised by the label/sid range sub-TLV. I wonder what the special purpose of the data-plane capability advertisement is in the ISIS-SR case. 

4. In ISIS-SR, the Prefix-SID Sub-TLV can be sub-TLV of the SID/Label Binding-TLV and its' the the prefix-sid sub-TLV which is used to associate prefix-sids with the range of prefixes advertised by the SID/Label Binding TLV. In OSPF-SR, the prefix-sid sub-TLV and the SID/label binding sub-TLV are now at the same level of the sub-TLV hierarchy(i.e., both of them are sub-TLVs of the OSPF Extended Prefix TLV ). As a result. it's the SID/Label sub-TLV, rather than the prefix-sid sub-TLV which is used to associate prefix-sids with the range of prefixes.

5. In ISIS-SR, "The SID/Label Sub-TLV (Type: TBD, suggested value 1) contains the SID/Label value as defined in Section 2.3.  It MAY be present in the SID/Label Binding TLV" . However, in OSPF-SR, "SID/Label sub-TLV as described in Section 2.1.  This sub-TLV MUST appear in the SID/Label Binding Sub-TLV". In other words, the sid/label sub-TLV is optional to the SID/Label binding sub-TLV in the ISIS-SR case while the sid/label sub-TLV is mandatory to the SID/label binding TLV in the OSPF-SR case.

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 http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)?

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

---

From: Peter Psenak <[email-masked]>
Date: Fri, 13 Jun 2014 10:31:37 +0200

Xiaohu,

please see inline:

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

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…

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 i…

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.

regards,
Peter

> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
> .
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Jun 2014 10:09:53 +0000

Hi peter,

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of Peter Psenak
> Sent: Friday, June 13, 2014 4:32 PM
> To: Xuxiaohu; [email-masked] list; OSPF List
> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2
> extensions for SR
> 
> Xiaohu,
> 
> please see inline:
> 
> > 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
> http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). 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)?
> 
> 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
> http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)?
> 
> 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,
Xiaohu

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

---

From: Peter Psenak <[email-masked]>
Date: Fri, 13 Jun 2014 14:30:30 +0200

Hi Xiaohu,

please see inline:

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

in OSPFv3 case, we have a way to advertise the prefix using the proposed 
encoding in draft-acee-ospfv3-lsa-extend, but do not advertise the 
reachability of the prefix - it's call NU-bit (rfc5340, A.4.1.1.)

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

Binding TLV in OSPF is only used to advertise a "LSP path" local to the 
advertising router, it's not used for anything else. YOu can still 
advertise a single "LSP path" for range of prefixes.

In ISIS, due to the need to decouple prefix reachability from SID 
advertisement, Binding TLV is used for SR Mapping Server (SRMS) 
adevrtisement on top of what it is used in OSPF (in OSPF SRMS 
advertisements are using the Prefix/SID sub-TLV).

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

no, we don't want to end up with sub-sub-TLVs right from the beginning.

regards,
Peter

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 16 Jun 2014 02:58:33 +0000

Hi Peter,

Please see my response inline

> From: Peter Psenak [mailto:[email-masked]]
> Sent: Friday, June 13, 2014 8:31 PM
> >>> There are some encoding inconsistencies between OSPFv2 extensions
> >>> and ISIS
> >> extensions for SR as follows:
> >>>
> >> 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
> >> 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.
> > 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.
> >
> >>>
> >> 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)?
> >>
> > IMHO, the ISIS and OSPFv3 advertisement of the prefix SIDs should be
> > decoupled from the prefix reachability advertisement as well:)
> 
> encoding in draft-acee-ospfv3-lsa-extend, but do not advertise the reachability
> of the prefix - it's call NU-bit (rfc5340, A.4.1.1.)

That's great. BTW, don't you believe the ISIS protocol has provided almost the same capability as the NU-bit (see the following text quoted from RFC5305)?

"...If a prefix is advertised
   with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph
   3.0), this prefix MUST NOT be considered during the normal SPF
   computation.  This allows advertisement of a prefix for purposes
   other than building the normal IP routing table...".  

> >
> >> 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?
> 
> Binding TLV in OSPF is only used to advertise a "LSP path" local to the advertising
> router, it's not used for anything else. YOu can still advertise a single "LSP path"
> for range of prefixes.

Don't you believe it's better for the Binding TLV in ISIS to be used to advertise a LSP as well? 

> In ISIS, due to the need to decouple prefix reachability from SID advertisement,
> Binding TLV is used for SR Mapping Server (SRMS) adevrtisement on top of what
> it is used in OSPF (in OSPF SRMS advertisements are using the Prefix/SID
> sub-TLV).

To decouple prefix reachability from SID advertisement, why not consider the approach of using the MAX_PATH_METRIC trick (see section 3 of http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00)?

Best regards,
Xiaohu

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

---

From: Peter Psenak <[email-masked]>
Date: Mon, 16 Jun 2014 09:16:51 +0200

Xiaohu,

please see inline:

> That's great. BTW, don't you believe the ISIS protocol has provided almost the same capability as the NU-bit (see the following text quoted from RFC5305)?

correct, max-metric means unreachable in ISIS.

> Don't you believe it's better for the Binding TLV in ISIS to be used to advertise a LSP as well?

Binding TLV in ISIS can be used to advertise "LSP path" as well as SRMS 
mappings.

> To decouple prefix reachability from SID advertisement, why not consider the approach of using the MAX_PATH_METRIC trick (see section 3 of http://tools.ietf.org/html/draft-xu-isis-global-label-sid-…

it's a matter of choice. Authors of ISIS draft choose the cleaner way IMHO.

regards,
Peter

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 16 Jun 2014 09:10:56 +0000

> Sent: Monday, June 16, 2014 3:17 PM
> >>>> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and
> >>>> OSPFv2 extensions for SR
> >>>>
> >>>> Xiaohu,
> >>>>
> >>>> please see inline:
> >>>>
> >> http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). 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.
> >> 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.
> >>>
> >>>>>
> >>>> 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
> >>>> 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.
> >>>
> >> in OSPFv3 case, we have a way to advertise the prefix using the
> >> proposed encoding in draft-acee-ospfv3-lsa-extend, but do not
> >> advertise the reachability of the prefix - it's call NU-bit (rfc5340,
> >> A.4.1.1.)
> >
> > That's great. BTW, don't you believe the ISIS protocol has provided almost the
> same capability as the NU-bit (see the following text quoted from RFC5305)?
> 

> >>>> 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.
> >>>
> >> advertise a range of prefix/sid pairs while the binding sub-TLV in
> >> the ISIS-SR could?
> >>
> >> Binding TLV in OSPF is only used to advertise a "LSP path" local to
> >> the advertising router, it's not used for anything else. YOu can still advertise a
> single "LSP path"
> >> for range of prefixes.
> >

I had wanted to say: "Don't you believe it's better for the Binding TLV in ISIS to be used ONLY to advertise a
LSP as well?" In this way, the functionality of the Binding TLV keeps fully consistent in OSPF and ISIS.

Best regards,
Xiaohu

> > To decouple prefix reachability from SID advertisement, why not consider the
> approach of using the MAX_PATH_METRIC trick (see section 3 of
> http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00)?
> 

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