Subject: [OSPF] fwd: New Version Notification for draft-xu-ospf-global-label-sid-adv-00.txt

From: Xuxiaohu <[email-masked]>
Date: Mon, 27 Jan 2014 03:34:22 +0000

Hi all,

Any comments are welcome.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]]
> 发送时间: 2014年1月21日 13:53
> 收件人: Mach Chen; Mach Chen; Xuxiaohu; Xuxiaohu
> 主题: New Version Notification for draft-xu-ospf-global-label-sid-adv-00.txt
> 
> 
> A new version of I-D, draft-xu-ospf-global-label-sid-adv-00.txt
> has been successfully submitted by Xiaohu Xu and posted to the IETF repository.
> 
> Name:		draft-xu-ospf-global-label-sid-adv
> Revision:	00
> Title:		Advertising Global Labels or SIDs Using OSPF
> Document date:	2014-01-21
> Group:		Individual Submission
> Pages:		7
> URL:
> http://www.ietf.org/internet-drafts/draft-xu-ospf-global-label-sid-adv-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-xu-ospf-global-label-sid-adv/
> Htmlized:
> http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00
> 
> 
> Abstract:
>    Segment Routing (SR) is a new MPLS paradigm in which each SR-capable
>    router is required to advertise global MPLS labels or Segment IDs
>    (SID) for its attached prefixes by using link-state IGPs, e.g., OSPF.
>    One major challenge associated with such global MPLS label or SID
>    advertisement mechanism is how to avoid a given global MPLS label or
>    SID from being allocated by different routers to different prefixes.
>    Although such global label or SID allocation collision problem can be
>    addressed through manual allocation , it is error-prone and
>    nonautomatic therefore may not be suitable in large-scale SR network
>    environments.  This document proposes an alternative approach for
>    allocating and advertising global MPLS labels or SIDs via OSPF so as
>    to eliminate the potential risk of label allocation collision.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Peter Psenak <[email-masked]>
Date: Mon, 27 Jan 2014 09:41:19 +0100

Xiaohu,

1. draft-psenak-ospf-segment-routing-extensions has already defined the 
mapping server functionality - please read the section 4.2 and 6.1

2. TLVs that you defined in section 3 and 4 are very close to those 
defined in draft-psenak-ospf-segment-routing-extensions and have the 
exact same functionality as the ones defined in 
draft-psenak-ospf-segment-routing-extensions

3. The only new sub-TLV you defined is Label Request Sub-TLV.

First, given that we already have OSPF SR draft, you should have defined 
this as a sub-TLV of the OSPF Extended Prefix TLV that is defined in 
draft-psenak-ospf-segment-routing-extensions.

Second, you proposed to use Opaque LSA that is flooded either area or 
domain wide as a request mechanism between the router and mapping 
server. This means that all routers in an area/domain would have to 
store and maintain such 'request' LSAs, even though they would never use 
them locally. I seriously question if flooding of the LSA is the right 
mechanism to achieve what you want.

regards,
Peter

On 1/27/14 04:34 , Xuxiaohu wrote:
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 27 Jan 2014 09:29:10 +0000

On Jan 27, 2014, at 9:41 AM, Peter Psenak wrote:

> Xiaohu,
> 
> 
> 1. draft-psenak-ospf-segment-routing-extensions has already defined the mapping server functionality - please read the section 4.2 and 6.1
> 
> 2. TLVs that you defined in section 3 and 4 are very close to those defined in draft-psenak-ospf-segment-routing-extensions and have the exact same functionality as the ones defined in draft-psenak-ospf-segment-routing-extensions

I agree and the above also applies to draft-previdi-isis-segment-routing-extensions.

s.

> First, given that we already have OSPF SR draft, you should have defined this as a sub-TLV of the OSPF Extended Prefix TLV that is defined in draft-psenak-ospf-segment-routing-extensions.
> 
> Second, you proposed to use Opaque LSA that is flooded either area or domain wide as a request mechanism between the router and mapping server. This means that all routers in an area/domain would have to store and maintain such 'request' LSAs, even though they would never use them locally. I seriously question if flooding of the LSA is the right mechanism to achieve what you want.
> 
> regards,
> Peter
> 
> 
> 
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 27 Jan 2014 09:49:34 +0000

Hi Peter,

> -----邮件原件-----
> 发件人: Peter Psenak [mailto:[email-masked]]
> 发送时间: 2014年1月27日 16:41
> 收件人: Xuxiaohu
> 抄送: [email-masked]; [email-masked]
> 主题: Re: [OSPF] fwd: New Version Notification for
> draft-xu-ospf-global-label-sid-adv-00.txt
> 
> Xiaohu,
> 
> 

According to the description about mapping servers (see below) which is in -01 version of the use case draft but is removed in -02 version of that draft, it seems that the mapping server is deemed to advertise the mappings on behalf of non-SR-capable routers. In contrast, my draft proposes to allow the mapping server to allocate and advertise mappings on behalf of SR-capable routers. Those two distinct design goals cause different implications on the implementation and usage.

   "The mappings advertised by an SR mapping server result from local
   policy information configured by the operator.  IF PE3 had been SR
   capable, the operator would have configured PE3 with node segment
   103.  Instead, as PE3 is not SR capable, the operator configures that
   policy at the SRMS and it is the latter which advertises the mapping."---quoted from -01 version of the use case draft.

> 2. TLVs that you defined in section 3 and 4 are very close to those defined in
> draft-psenak-ospf-segment-routing-extensions and have the exact same
> functionality as the ones defined in

If I understand your draft correctly, the prefix SID sub-TLV defined in your draft is intended to advertise index, rather than SID or global label. In contrast, the Label Binding Sub-TLV and SID Binding Sub-TLV defined in my draft are intended to advertise global labels and SIDs respectively. Besides, the Label Binding Sub-TLV and SID Binding sub-TLV are just intended for label or SID distribution without any correlation with the algorithm and MT-ID, which is different from the prefix SID sub-TLV, IMHO.

> First, given that we already have OSPF SR draft, you should have defined this as
> a sub-TLV of the OSPF Extended Prefix TLV that is defined in

> Second, you proposed to use Opaque LSA that is flooded either area or domain
> wide as a request mechanism between the router and mapping server. This
> means that all routers in an area/domain would have to store and maintain such
> 'request' LSAs, even though they would never use them locally. I seriously
> question if flooding of the LSA is the right mechanism to achieve what you want.

Agree that it may not be attractive in the OSPF case. However, this choice may be attractive in the IS-IS case since the label/SID request information can be carried in the IP reachability advertisement. Anyway, as said in the draft, the advertisement of label/SID request is just one option.

Best regards,
Xiaohu

> >> 主题: New Version Notification for
> >> draft-xu-ospf-global-label-sid-adv-00.txt
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> The IETF Secretariat
> >

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 27 Jan 2014 09:53:46 +0000

On Jan 27, 2014, at 10:49 AM, Xuxiaohu wrote:
> According to the description about mapping servers (see below) which is in -01 version of the use case draft but is removed in -02 version of that draft, it seems that the mapping server is deemed to advertise the mappings on behalf of non-SR-capable routers.

As it is defined now, there is nothing that prevents the MS 
to be used for mapping SIDs/labels to indistinctly SR and 
non-SR routers.

s.

> In contrast, my draft proposes to allow the mapping server to allocate and advertise mappings on behalf of SR-capable routers. Those two distinct design goals cause different implications on the implementation and usage.
>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 27 Jan 2014 10:03:16 +0000

> -----邮件原件-----
> 发件人: Stefano Previdi (sprevidi) [mailto:[email-masked]]
> 发送时间: 2014年1月27日 17:54
> 收件人: Xuxiaohu
> 抄送: Peter Psenak (ppsenak); [email-masked]; [email-masked]
> 主题: Re: [OSPF] New Version Notification for
> >> 1. draft-psenak-ospf-segment-routing-extensions has already defined
> >> the mapping server functionality - please read the section 4.2 and
> >> 6.1
> >
> > According to the description about mapping servers (see below) which is in -01
> version of the use case draft but is removed in -02 version of that draft, it seems
> that the mapping server is deemed to advertise the mappings on behalf of
> non-SR-capable routers.
> 
> 
> As it is defined now, there is nothing that prevents the MS to be used for
> mapping SIDs/labels to indistinctly SR and non-SR routers.

Hi,

   "Segment Routing requires each router to advertise its SR data-plane
   capability and the range of SID/Label values it uses for Segment
   Routing. Data-plane capabilities and SID/Label ranges are advertised
   using the newly defined SR-Capabilities Sub-TLV inserted into the
   IS-IS Router Capability TLV-242 that is defined in [RFC4971]. " -quoted from your ISIS extension for SR draft.

I understand that the MS could be used to advertise indexes on behalf of SR routers. However, I wonder whether the MS could also be used to advertise the SID/label range on behalf of SR routers according to the above specification.

Best regards,
Xiaohu

> s.
> 
> 
> > In contrast, my draft proposes to allow the mapping server to allocate and
> advertise mappings on behalf of SR-capable routers. Those two distinct design
> goals cause different implications on the implementation and usage.
> >
> >   policy at the SRMS and it is the latter which advertises the
> mapping."---quoted from -01 version of the use case draft.
> >
> > If I understand your draft correctly, the prefix SID sub-TLV defined in your
> draft is intended to advertise index, rather than SID or global label. In contrast,
> the Label Binding Sub-TLV and SID Binding Sub-TLV defined in my draft are
> intended to advertise global labels and SIDs respectively. Besides, the Label
> Binding Sub-TLV and SID Binding sub-TLV are just intended for label or SID
> distribution without any correlation with the algorithm and MT-ID, which is
> different from the prefix SID sub-TLV, IMHO.
> >
> >> First, given that we already have OSPF SR draft, you should have
> >> defined this as a sub-TLV of the OSPF Extended Prefix TLV that is
> >> defined in draft-psenak-ospf-segment-routing-extensions.
> >
> >> store and maintain such 'request' LSAs, even though they would never
> >> use them locally. I seriously question if flooding of the LSA is the right
> > Agree that it may not be attractive in the OSPF case. However, this choice may
> be attractive in the IS-IS case since the label/SID request information can be
> carried in the IP reachability advertisement. Anyway, as said in the draft, the
> advertisement of label/SID request is just one option.
> >
> > Best regards,
> > Xiaohu
> >
> >> regards,
> >> Peter
> >>
> >>
> >>
> >>>> http://www.ietf.org/internet-drafts/draft-xu-ospf-global-label-sid-
> >>>> ad
> >>>> v-00.txt
> >>>> Status:

---

From: Peter Psenak <[email-masked]>
Date: Mon, 27 Jan 2014 11:08:21 +0100

Xiaohu,

> According to the description about mapping servers (see below) which is in -01 version of the use case draft but is removed in -02 version of that draft, it seems that the mapping server is deemed…

that is not true. MS as we support it with existing drafts can be used 
to advertise SID/label for SR capable routers.

> If I understand your draft correctly, the prefix SID sub-TLV defined in your draft is intended to advertise index,  rather than SID or global label. In contrast, the Label Binding 
Sub-TLV and SID Binding Sub-TLV defined in my draft are intended to 
advertise global labels and SIDs respectively. Besides, the Label 
Binding Sub-TLV and SID Binding sub-TLV are just intended for label or 
SID distribution without any correlation with the algorithm and MT-ID, 
which is different from the prefix SID sub-TLV, IMHO.

you can advertise an absolute value of the label/SID with existing TLVs 
- simply advertise the label/sid range starting from 0. MT-ID and 
algorithm fields of 0 means default topology and SPT tree, which is what 
you want anyway.

> Agree that it may not be attractive in the OSPF case. However, this choice may be attractive in the IS-IS case since the label/SID request information can be carried in the IP reachability advertis…

I do not see how ISIS is different - LSP is still flooded with area scope.

regards,
Peter

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 27 Jan 2014 11:29:51 +0000

> I understand that the MS could be used to advertise indexes on behalf of SR routers. However, I wonder whether the MS could also be used to advertise the SID/label range on behalf of SR routers acc…

it can. Maybe we can add some more words.

s.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 28 Jan 2014 03:46:54 +0000

Hi Peter,

> 发送时间: 2014年1月27日 18:08
> non-SR-capable routers. In contrast, my draft proposes to allow the mapping
> server to allocate and advertise mappings on behalf of SR-capable routers.
> Those two distinct design goals cause different implications on the
> implementation and usage.
> 
> that is not true. MS as we support it with existing drafts can be used to advertise
> SID/label for SR capable routers.

This above argument may be true for the OSPF extension for SR draft since the Prefix-SID are attached to OSPFv2 Extended Prefix Opaque LSA which is not used for building the normal IP routing table. But I doubt whether the above argument is still true for the ISIS extension for SR draft since the Prefix-SID Sub-TLV is attached to the Extended IP Reachability TLV which is exactly used for building the normal IP routing table, according to the existing description of that draft. 

Best regard,
Xiaohu

> > If I understand your draft correctly, the prefix SID sub-TLV defined
> > in your draft is intended to advertise index,  rather than SID or
> > global label. In contrast, the Label Binding
> Sub-TLV and SID Binding Sub-TLV defined in my draft are intended to advertise
> global labels and SIDs respectively. Besides, the Label Binding Sub-TLV and SID
> Binding sub-TLV are just intended for label or SID distribution without any
> correlation with the algorithm and MT-ID, which is different from the prefix SID
> sub-TLV, IMHO.
> 
> - simply advertise the label/sid range starting from 0. MT-ID and algorithm fields
> of 0 means default topology and SPT tree, which is what you want anyway.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 28 Jan 2014 09:15:16 +0100

Xiaohu,

please see inline (##PP):

> This above argument may be true for the OSPF extension for SR draft since the Prefix-SID are attached to OSPFv2 Extended Prefix Opaque LSA which is not used for building the normal IP routing table…

##PP
in ISIS, you can use SID/Label Binding TLV to advertise SID/label for 
prefix for which you do not want to advertise IP reachability.

regards,
Peter

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 28 Jan 2014 08:53:40 +0000

Hi Peter,

> 发送时间: 2014年1月28日 16:15
> 抄送: [email-masked]; [email-masked]; [email-masked]
> >> version of the use case draft but is removed in -02 version of that
> >> draft, it seems that the mapping server is deemed to advertise the
> >> mappings on behalf of non-SR-capable routers. In contrast, my draft
> >> proposes to allow the mapping server to allocate and advertise mappings on
> behalf of SR-capable routers.
> >> that is not true. MS as we support it with existing drafts can be
> >> used to advertise SID/label for SR capable routers.
> >
> > This above argument may be true for the OSPF extension for SR draft since the
> Prefix-SID are attached to OSPFv2 Extended Prefix Opaque LSA which is not
> used for building the normal IP routing table. But I doubt whether the above
> argument is still true for the ISIS extension for SR draft since the Prefix-SID
> Sub-TLV is attached to the Extended IP Reachability TLV which is exactly used for
> building the normal IP routing table, according to the existing description of that
> draft.
> 
> ##PP
> in ISIS, you can use SID/Label Binding TLV to advertise SID/label for prefix for
> which you do not want to advertise IP reachability.

In the SID/Label Binding TLV, the MT-ID information is missed. I wonder why not directly reuse the extended IP reachability TLVs to carry the Label/SID bindings by setting the Metric field to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000).  According to the following specification as defined in [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...".  

In addition, as stated in the section 2.2 of Prefix-SID Sub-TLV, "The 'Prefix SID' is an index to determine the actual SID/label value inside the set of all advertised SID/label ranges of a given router. " In section 2.1 of SID/Label Sub-TLV, it said "... The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in this document and contains a SID or a MPLS Label". In the section 2.4 of SID/Label Binding TLV, it said "...X-Flag: Index flag.  Set if the value of the SID/Label Sub-TLV carries an index.  Unset if the value of the SID/Label Sub-TLV carries a local SID/Label. " Does the above description seem conflicting? Furthermore, in case the SID/Label Sub-TLV carries a "local" SID/Label, does that mean this Sub-TLV is not suitable for a mapping server to advertise the global ID (of whatever format) for a given prefix?

Best regards,
Xiaohu

> >>>> defined in draft-psenak-ospf-segment-routing-extensions and have
> >>>> the exact same functionality as the ones defined in
> >> Binding Sub-TLV and SID Binding sub-TLV are just intended for label
> >> or SID distribution without any correlation with the algorithm and
> >> MT-ID, which is different from the prefix SID sub-TLV, IMHO.
> >>
> >> algorithm fields of 0 means default topology and SPT tree, which is what you
> want anyway.
> >
> >>>
> >>>> Second, you proposed to use Opaque LSA that is flooded either area
> >>>> or domain wide as a request mechanism between the router and
> >>>> mapping server. This means that all routers in an area/domain would
> >>>> have to store and maintain such 'request' LSAs, even though they
> >>>> would never use them locally. I seriously question if flooding of
> >>>> the LSA is the right
> >> be attractive in the IS-IS case since the label/SID request
> >> information can be carried in the IP reachability advertisement.
> >> Anyway, as said in the draft, the advertisement of label/SID request is just
> one option.
> >>
> >>>>>> has been successfully submitted by Xiaohu Xu and posted to the
> >>>>>> IETF
> >>>> repository.
> >>>>>>
> >>>>>> https://datatracker.ietf.org/doc/draft-xu-ospf-global-label-sid-a
> >>>>>> dv
> >>>>>> /
> >>>>>> Htmlized:
> >>>>>>       advertisement mechanism is how to avoid a given global MPLS
> >>>>>> label
> >> or
> >>>>>>       nonautomatic therefore may not be suitable in large-scale
> >>>>>> SR
> >> network
> >>>>>>       environments.  This document proposes an alternative
> >>>>>> approach
> >> for

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 28 Jan 2014 09:17:44 +0000

On Jan 28, 2014, at 9:53 AM, Xuxiaohu wrote:

> In the SID/Label Binding TLV, the MT-ID information is missed. I wonder why not directly reuse the extended IP reachability TLVs to carry the Label/SID bindings by setting the Metric field to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000). 

we evaluated that option a while ago and discarded because of the complexity. 
So, today in ISIS, the SID is advertised with:
	. an optional TLV inside TLV135
	. the binding TLV

let's keep it simple.

> According to the following specification as defined in [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...".  
> 
> In addition, as stated in the section 2.2 of Prefix-SID Sub-TLV, "The 'Prefix SID' is an index to determine the actual SID/label value inside the set of all advertised SID/label ranges of a given router. " In section 2.1 of SID/Label Sub-TLV, it said "... The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in this document and contains a SID or a MPLS Label". In the section 2.4 of SID/Label Binding TLV, it said "...X-Flag: Index flag.  Set if the value of the SID/Label Sub-TLV carries an index.  Unset if the value of the SID/Label Sub-TLV carries a local SID/Label. " Does the above description seem conflicting?

yes, I have updated the drafts and will submit them soon. There's no 
mention of the X-flag anymore.

> Furthermore, in case the SID/Label Sub-TLV carries a "local" SID/Label, does that mean this Sub-TLV is not suitable for a mapping server to advertise the global ID (of whatever format) for a given prefix?

a mapping server is used for advertising prefix labels/SIDs which are
global (even if translated into MPLS data plane this means a local label).

Local SIDs are adjacencies/interfaces which are not advertised by 
the mapping server.

s.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 29 Jan 2014 03:31:53 +0000

Hi Stefano,

> 发送时间: 2014年1月28日 17:18
> 抄送: Peter Psenak (ppsenak); [email-masked]; [email-masked]; [email-masked]
> >>>>>> 1. draft-psenak-ospf-segment-routing-extensions has already
> >>>>>> defined the mapping server functionality - please read the
> >>>>>> section 4.2 and
> >>>>>> 6.1
> >>>>>
> >> Prefix-SID are attached to OSPFv2 Extended Prefix Opaque LSA which is
> >> not used for building the normal IP routing table. But I doubt
> >> whether the above argument is still true for the ISIS extension for
> >> SR draft since the Prefix-SID Sub-TLV is attached to the Extended IP
> >> Reachability TLV which is exactly used for building the normal IP
> >> routing table, according to the existing description of that draft.
> >>
> >> ##PP
> > In the SID/Label Binding TLV, the MT-ID information is missed. I wonder why
> not directly reuse the extended IP reachability TLVs to carry the Label/SID
> bindings by setting the Metric field to a value larger than MAX_PATH_METRIC
> (i.e., 0xFE000000).
> 
> 

Could you explain why that option is complex?

> 	. an optional TLV inside TLV135

By using the above two TLVs, ISIS SR cannot support ISIS MT scenario. However, the OSPF SR can support MT. IMHO, it would be better to keep the SR feature/capability as consistent as possible no matter whether ISIS or OSPF is used for label/SID binding advertisement.

Best regards,
Xiaohu

> > According to the following specification as defined in [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...".
> >
> > In addition, as stated in the section 2.2 of Prefix-SID Sub-TLV, "The 'Prefix SID'
> is an index to determine the actual SID/label value inside the set of all advertised
> SID/label ranges of a given router. " In section 2.1 of SID/Label Sub-TLV, it said "...
> The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in this document
> and contains a SID or a MPLS Label". In the section 2.4 of SID/Label Binding TLV,
> it said "...X-Flag: Index flag.  Set if the value of the SID/Label Sub-TLV carries an
> index.  Unset if the value of the SID/Label Sub-TLV carries a local SID/Label. "
> Does the above description seem conflicting?
> 
> 
> yes, I have updated the drafts and will submit them soon. There's no mention of
> the X-flag anymore.
> 
> 
> > Furthermore, in case the SID/Label Sub-TLV carries a "local" SID/Label, does
> that mean this Sub-TLV is not suitable for a mapping server to advertise the
> global ID (of whatever format) for a given prefix?
> 
> 
> you
> >>>>>>>>      allocating and advertising global MPLS labels or SIDs via OSPF
> so
> >> as

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 29 Jan 2014 04:01:47 +0000

Hi Peter,

> of 0 means default topology and SPT tree, which is what you want anyway.

According to the following text quoted from ISIS SR draft, 

   Routing."

If you advertise the label range starting from 0, does that mean the reserved label block of 0-15 is also used for segment routing? IMO, as long as it's possible for most SR routers to allocate a common label block for SR purpose, the global label should be advertised in the control plane. For those seldom SR nodes which could not allocate that label block, the global label advertised in the control plane would be used to determine the corresponding local label which is used in the data plane. 

Best regards,
Xiaohu

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 29 Jan 2014 08:47:11 +0000

> Could you explain why that option is complex?

We didn't like the idea of blasting multiple copy of the same prefix: one 
from the real owner (with a valid metric) and one from each MS (with 
MAXMETRIC). Very easy to come to a situation where a bogus implementation 
installs a maxmetric prefix.

The maxmetric option doesn't help much. We just need to enhance the Binding 
TLV with MT capability.

> By using the above two TLVs, ISIS SR cannot support ISIS MT scenario.

As specified in the isis draft, the SID subTLV is defined for TLV135, 
235, 236 and 237  which includes MT and MI (the two multi-topology flavors).

What's missing is the ability of the Binding TLV to be MT aware/capable.
This can be easily fixed.

> However, the OSPF SR can support MT. IMHO, it would be better to keep the SR feature/capability as consistent as possible no matter whether ISIS or OSPF is used for label/SID binding advertisement.

agree... let's make binding TLV MT aware.

s.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 29 Jan 2014 08:53:22 +0000

> -----邮件原件-----
> 发件人: spring [mailto:[email-masked]] 代表 Xuxiaohu
> 发送时间: 2014年1月29日 12:02
> 收件人: Peter Psenak
> 抄送: [email-masked]; [email-masked]
> 主题: Re: [spring] [OSPF] fwd: New Version Notification for
> If you advertise the label range starting from 0, does that mean the reserved
> label block of 0-15 is also used for segment routing? IMO, as long as it's possible
> for most SR routers to allocate a common label block for SR purpose, the global
> label should be advertised in the control plane. For those seldom SR nodes which
> could not allocate that label block, the global label advertised in the control
> plane would be used to determine the corresponding local label which is used in
> the data plane.

For example, assume a label block {1000, 1999} is allocated for prefix segments by almost all SR routers and a global label 1005 is allocated to a given prefix segment, for a given seldom SR router which couldn't preserve the above label block and allocates a different label block (e.g., {2000, 2999}) instead, a local label corresponding to that global label (or that prefix segment) could be calculated through offsetting, i.e., the result is 1005+ (2000-1000)=2005. In this way, there is no need for introducing the Index concept anymore and therefore the architecture becomes much easy to understand. More importantly, compared to the index binding advertisement, the label binding advertised by the IGP is exactly the same as that in the label forwarding table for those most SR routers which have allocated the above common label block, which is much beneficial when doing troubleshooting. This approach does not violate the strongest MPLS dogma (i.e., labels MUST be local) while taking into account the actual situation, IMHO

Best regards,
Xiaohu

> > Anyway, as said in the draft, the advertisement of label/SID request is just one
> option.
> >

---

From: Peter Psenak <[email-masked]>
Date: Wed, 29 Jan 2014 10:10:33 +0100

Xiaohu,

On 1/29/14 09:53 , Xuxiaohu wrote:
> For example, assume a label block {1000, 1999} is allocated for prefix segments by almost all SR routers and a global label 1005 is allocated to a given prefix segment, for a given seldom SR router which couldn't preserve the above label block and allocates a different label block (e.g., {2000, 2999}) instead, a local label corresponding to that global label (or that prefix segment) could be calculated through offsetting, i.e., the result is 1005+ (2000-1000)=2005. In this way, there is no need for introducing the Index concept anymore and therefore the architecture becomes much easy to understand. More importantly, compared to the index binding advertisement, the label binding advertised by the IGP is exactly the same as that in the label forwarding table for those most SR routers which have allocated the above common label block, which is much beneficial when doing troubleshooting. This approach does not violate the strongest MPLS dogma (i.e., labels MUST be local) while taking i
 n
to account the actual situation, IMHO

above would require the "seldom SR router" to know the offset from the 
SRGB used by other routers. How do you envision that to be learned?

regards,
Peter

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 29 Jan 2014 09:16:33 +0000

> 发送时间: 2014年1月29日 17:11
> > For example, assume a label block {1000, 1999} is allocated for prefix
> segments by almost all SR routers and a global label 1005 is allocated to a given
> prefix segment, for a given seldom SR router which couldn't preserve the above
> label block and allocates a different label block (e.g., {2000, 2999}) instead, a
> local label corresponding to that global label (or that prefix segment) could be
> calculated through offsetting, i.e., the result is 1005+ (2000-1000)=2005. In this
> way, there is no need for introducing the Index concept anymore and therefore
> the architecture becomes much easy to understand. More importantly,
> compared to the index binding advertisement, the label binding advertised by
> the IGP is exactly the same as that in the label forwarding table for those most SR
> routers which have allocated the above common label block, which is much
> beneficial when doing troubleshooting. This approach does not violate the
> strongest MPLS dogma (i.e., labels MUST be local) while!
>  taking in
> above would require the "seldom SR router" to know the offset from the SRGB
> used by other routers. How do you envision that to be learned?

Hi Peter,

I don't think it's a big problem. The common SRGB could either be manually configured on the seldom SR router or advertised by the MS.

Best regards,
Xiaohu

---

From: Peter Psenak <[email-masked]>
Date: Wed, 29 Jan 2014 10:23:46 +0100

Xuxiaohu,

> I don't think it's a big problem. The common SRGB could either be manually configured on the seldom SR router or advertised by the MS.

manual configuration is not an option - just imagine you have multiple 
"seldom SR routers", each having a different label block. Now you not 
only need an offset for "common" block, but also offset between label 
blocks used on these "seldom SR routers".

Once you start to advertise it, you are back to the model we have 
already, but you made it even worse with offsets.

regards,
Peter

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 29 Jan 2014 09:58:04 +0000

> 发送时间: 2014年1月29日 17:24
> >> segments by almost all SR routers and a global label 1005 is
> >> allocated to a given prefix segment, for a given seldom SR router
> >> which couldn't preserve the above label block and allocates a
> >> different label block (e.g., {2000, 2999}) instead, a local label
> >> corresponding to that global label (or that prefix segment) could be
> >> calculated through offsetting, i.e., the result is 1005+
> >> (2000-1000)=2005. In this way, there is no need for introducing the
> >> Index concept anymore and therefore the architecture becomes much
> >> easy to understand. More importantly, compared to the index binding
> >> advertisement, the label binding advertised by the IGP is exactly the
> >> same as that in the label forwarding table for those most SR routers
> >> which have allocated the above common label block, which is much
> >> above would require the "seldom SR router" to know the offset from
> >> the SRGB used by other routers. How do you envision that to be learned?
> >
> > Hi Peter,
> >
> > I don't think it's a big problem. The common SRGB could either be manually
> configured on the seldom SR router or advertised by the MS.
> 
> manual configuration is not an option - just imagine you have multiple "seldom
> SR routers", each having a different label block. Now you not only need an
> offset for "common" block, but also offset between label blocks used on these
> "seldom SR routers".

Peter,

Why do you need offset between label blocks used on these seldom SR routers? The common block is the only frame of reference, IMO. 

> Once you start to advertise it, you are back to the model we have already, but
> you made it even worse with offsets.

I don't think so. Take the above situation as an example, in the index binding mode, you could allow the most SR routers to advertise its label range starting with zero to achieve the above effect (although it conflicts with the definition of label range). However, for the seldom SR router, what label range should it advertise?

Best regards,
Xiaohu

---

From: Peter Psenak <[email-masked]>
Date: Wed, 29 Jan 2014 11:28:50 +0100

Xuxiaohu,

> Why do you need offset between label blocks used on these seldom SR routers? The common block is the only frame of reference, IMO.

let's imagine you have two "seldom SR routers", A and B, directly 
connected. A is using label block 1000-2000, B is using 2000-3000. For 
simplicity, let's assume rest of the routers use the block 0-1000.

Now let's imagine you have a prefix X, which is advertised with label 25 
from a router that uses the common block (0-1000). On A you configure 
the offset +1000, so it allocate a local label of 1025 for X. Now A 
wants to send a traffic for X via B. You would have to configure on A 
the offset of B as +2000 (against the common block) or as +1000 (against 
the A's block), so when A sends a traffic to B, it will use label 2025. 
No matter which method of specifying the offset you use, the point is 
that on A you need to know the offset of all "seldom SR" routers that 
you may end up sending traffic to - either directly, or indirectly. Such 
a configuration model does not scale.

> I don't think so. Take the above situation as an example, in the index binding mode, you could allow the most SR routers to advertise its label range starting with zero to achieve the above effect…

the simplest model is for every router (seldom or common) to advertise 
its label block.

regards,
Peter