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

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

Hi Peter,

> -----邮件原件-----
> 发件人: Peter Psenak [mailto:[email-masked]]
> 发送时间: 2014年1月27日 18:08
> 收件人: Xuxiaohu
> 抄送: [email-masked]; [email-masked]
> 主题: Re: [OSPF] fwd: New Version Notification for
> draft-xu-ospf-global-label-sid-adv-00.txt
> 
> Xiaohu,
> 
> On 1/27/14 10:49 , Xuxiaohu wrote:
> > 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,
> >>
> >>
> >> 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. 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

> >     "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
> >> draft-psenak-ospf-segment-routing-extensions
> >
> > 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.

> >
> >> 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.
> >
> > 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.
> 
> I do not see how ISIS is different - LSP is still flooded with area scope.
> 
> regards,
> Peter
> 
> >
> > Best regards,
> > Xiaohu
> >
> >> regards,
> >> Peter
> >>
> >>
> >>
> >> On 1/27/14 04:34 , Xuxiaohu wrote:
> >>> 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-
> >>>> ad
> >>>> v-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
> >>>
> >>> _______________________________________________
> >>> OSPF mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/ospf
> >>>
> >

---

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

---

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,

> -----邮件原件-----
> 发件人: Stefano Previdi (sprevidi) [mailto:[email-masked]]
> 发送时间: 2014年1月28日 17:18
> 收件人: Xuxiaohu
> 抄送: 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?
> 
> 
> >>>>>>>>      allocating and advertising global MPLS labels or SIDs via OSPF
> so
> >> as

---

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.