Subject: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

From: Xuxiaohu <[email-masked]>
Date: Fri, 19 Jul 2013 07:31:54 +0000

Hi all,

This draft proposes a new way to advertise global labels without any risk of label collision. Any comments are welcome.

Br,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]]
> 发送时间: 2013年7月11日 16:18
> 收件人: Mach Chen; Mach Chen; Xuxiaohu; Xuxiaohu
> 主题: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt
> 
> 
> A new version of I-D, draft-xu-rtgwg-global-label-adv-00.txt
> has been successfully submitted by Xiaohu Xu and posted to the
> IETF repository.
> 
> Filename:	 draft-xu-rtgwg-global-label-adv
> Revision:	 00
> Title:		 Advertising Global Labels Using IGP
> Creation date:	 2013-07-11
> Group:		 Individual Submission
> Number of pages: 9
> URL:
> http://www.ietf.org/internet-drafts/draft-xu-rtgwg-global-label-adv-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-xu-rtgwg-global-label-adv
> Htmlized:
> http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv-00
> 
> 
> Abstract:
>    Segment Routing (SR) [SR-ARCH] is a new MPLS paradigm in which each
>    SR-capable router is required to independently advertise global MPLS
>    labels for its attached prefixes using IGP [SR-ISIS-EXT][SR-OSPF-EXT].
>    One major challenge associated with such label advertisement
>    mechanism is how to avoid a given global MPLS label from being
>    allocated by different routers to different prefixes. Although manual
>    allocation can address such label allocation collision problem, it is
>    error-prone and therefore may not be suitable for large SR network
>    environments. This document proposes an alternative approach for
>    advertising global labels without any risk of label allocation
>    collision.
> 
> 
> 
> 
> The IETF Secretariat

---

From: Saku Ytti <[email-masked]>
Date: Fri, 19 Jul 2013 11:41:45 +0300

Hi Xiaohu,

If I understand correctly there are two unique obstacles why different
people oppose global labels

1. need for unique ID/label per node
       - your draft clearly solves this
       - but is this really a problem? Operators handle NET/CLNS/IPv4/IPv6
uniqueness today, so it's ingrained process?
       - I personally greatly favor local/static config to
signalling/states, less things to break

2. need for globally agreed block
       - every application of every device must have 'hole' in their label
manager for this block, so no other application tries to allocate label
from this block
       - as I see it, in your proposal this demand still remains, that is
if mapping server proposes that I use label 42, which I've already assigned
for another application, things break?
       - essentially solution would be to implement such guarantee which is
additional upgrade-cycle

I personally can accept both requirement and live with them. But I know
there are people who say 2. is show stopper and such requirement cannot
exist. 1. seem far less opposed.

Operationally I'm quite worried about the added external requirements for
my local forwarding, but this might be just rush reaction to new idea.

On 19 July 2013 10:31, Xuxiaohu <[email-masked]> wrote:

> Hi all,
>
> This draft proposes a new way to advertise global labels without any risk
> of label collision. Any comments are welcome.
>
> Br,
> Xiaohu
>
> > -----邮件原件-----
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

-- 
  ++ytti

---

From: Peter Psenak <[email-masked]>
Date: Fri, 19 Jul 2013 11:01:13 +0200

Xiaohu,

I do not see anything new in your draft.

1. Mapping Server functionality is described in SR use case draft 
(draft-filsfils-rtgwg-segment-routing-use-cases-00)

2. existing OSPF/ISIS SR drafts have already defined label-binding TLV 
and Extended Prefix Opaque LSA has been defined in OSPF SR draft.

3. Multiple Mapping Servers can advertise labels, there is no need to do 
any election.

regards,
Peter

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 19 Jul 2013 10:00:24 +0000

Hi Peter,

> -----邮件原件-----
> 发件人: Peter Psenak [mailto:[email-masked]]
> 发送时间: 2013年7月19日 17:01
> 收件人: Xuxiaohu
> 抄送: [email-masked]
> 主题: Re: [Status] fwd: New Version Notification for
> draft-xu-rtgwg-global-label-adv-00.txt
> 
> Xiaohu,
> 

If I understand the mapping server functionality described in the current SR drafts correctly, the mapping server is only used for advertising prefix segments on behalf of non-SR-capable routers. See the following quoted text from the SR use case draft:

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

In my draft, all the global labels for prefixes (i.e., prefix segments or node segments called in SR) should be allocated and advertised by the mapping server, rather than by any SR-capable routers. In the way, there is no risk of label allocation collision. SR-capable routers just need to allocated and advertise local labels for adjacencies (i.e., adjacency segments) . Furthermore, those prefixes which need to be allocated with global labels can be manually configured on the mapping servers or be advertised by the corresponding SR-capable by using the Label-request sub-TLVs.

> and Extended Prefix Opaque LSA has been defined in OSPF SR draft.

Besides, the approach defined in the current SR drafts requires additional work on the ABRs to deal with the label advertisement when reachability information is propagated across areas, see the following quoted text from the SR OSPF extension draft: 

" When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area
   route to all its connected areas it will also originate an Extended
   Prefix Opaque LSA, as described in Section 4.  The flooding scope of
   the Extended Prefix Opaque LSA type will be set to area-scope.  The
   route-type in OSPF Extended Prefix TLV is set to inter-area.  The
   Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID
   will be set as follows:"

In my draft, since the Opaque Prefix LSAs containing either the label-request sub-TLV or the label-binding sub-TLV be flooded within the domain scope, there is no complex work required on the ABRs.

> 3. Multiple Mapping Servers can advertise labels, there is no need to do

The reason for the mapping server election is to avoid the risk of label allocation collision between multiple mapping servers.

Anyway, differences lie in details.

Best regards,
Xiaohu

> > This draft proposes a new way to advertise global labels without any risk of
> label collision. Any comments are welcome.
> >
> > Br,
> > Xiaohu
> >
> >> -----邮件原件-----

---

From: Peter Psenak <[email-masked]>
Date: Fri, 19 Jul 2013 12:13:02 +0200

Xiaohu

> In my draft, all the global labels for prefixes (i.e., prefix segments or node segments called in SR) should be allocated and advertised by the mapping server, rather than by any SR-capable routers…

- nothing in existing SR drafts prevents you to advertise SIDs/labels 
from mapping server even for prefixes connected to SR capable routers.

- current SR drafts already defined a way to advertise SID/label, I do 
not see why Label-request sub-TLVs is any different.

> In my draft, since the Opaque Prefix LSAs containing either the label-request sub-TLV or the label-binding sub-TLV be flooded within the domain scope, there is no complex work required on the ABRs.

current OSPF SR draft does not prevent you to use domain-wide flooding 
if that is what you need:

"Flooding scope of the OSPFv2 Extended Prefix Opaque
  LSA depends on the content inside the LSA and is in control of the
  originating router."

> Anyway, differences lie in details.

right and too many details are too close to existing SR drafts.

regards,
Peter

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 22 Jul 2013 03:19:30 +0000

Peter

> 发送时间: 2013年7月19日 18:13
> > If I understand the mapping server functionality described in the current SR
> drafts correctly, the mapping server is only used for advertising prefix
> segments on behalf of non-SR-capable routers. See the following quoted text
> from the SR use case draft:
> >
> > In my draft, all the global labels for prefixes (i.e., prefix segments or node
> segments called in SR) should be allocated and advertised by the mapping
> server, rather than by any SR-capable routers. In the way, there is no risk of
> label allocation collision. SR-capable routers just need to allocated and
> advertise local labels for adjacencies (i.e., adjacency segments) . Furthermore,
> those prefixes which need to be allocated with global labels can be manually
> configured on the mapping servers or be advertised by the corresponding
> SR-capable by using the Label-request sub-TLVs.
> 

Yes, it doesn't prevent that case explicitly. However, I haven't seen any description of that case in the existing SR drafts. 

> not see why Label-request sub-TLVs is any different.

The label-request sub-TLV is used by SR-capable routers to notify the mapping server of what prefixes need label bindings. In other words, it's for the mapping server to automatically discover those prefixes which need label bindings.

> > Besides, the approach defined in the current SR drafts requires additional
> work on the ABRs to deal with the label advertisement when reachability
> information is propagated across areas, see the following quoted text from the
> SR OSPF extension draft:
> >
> > In my draft, since the Opaque Prefix LSAs containing either the label-request
> sub-TLV or the label-binding sub-TLV be flooded within the domain scope, there
> is no complex work required on the ABRs.
> 

As you pointed out, the flooding scope of the OSPFv2 Extended Prefix Opaque DEPENDS on the content inside the LSA in the SR draft. However, In my draft, the flooding scope of the OSPFv2 Prefix Opaque LSA DOESN'T DEPEND on the content inside the LSA.

Best regards,
Xiaohu

> > The reason for the mapping server election is to avoid the risk of label
> allocation collision between multiple mapping servers.
> >

---

From: Peter Psenak <[email-masked]>
Date: Mon, 22 Jul 2013 13:06:50 +0200

Xiaohu,

> Yes, it doesn't prevent that case explicitly. However, I haven't seen any description of that case in the existing SR drafts.

does not mean you can not do it.

> As you pointed out, the flooding scope of the OSPFv2 Extended Prefix Opaque DEPENDS on the content inside the LSA in the SR draft. However, In my draft, the flooding scope of the OSPFv2 Prefix Opaq…

given that OSPFv2 Extended Prefix Opaque LSA as defined in existing OSPF 
SR draft allows you to do what you need, there is no need to define a 
new LSA.

regards,
Peter

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 23 Jul 2013 01:06:22 +0000

Peter,

> 发送时间: 2013年7月22日 19:07
> > Yes, it doesn't prevent that case explicitly. However, I haven't seen any
> description of that case in the existing SR drafts.
> 

> >
> > As you pointed out, the flooding scope of the OSPFv2 Extended Prefix Opaque
> DEPENDS on the content inside the LSA in the SR draft. However, In my draft,
> the flooding scope of the OSPFv2 Prefix Opaque LSA DOESN'T DEPEND on the
> content inside the LSA.
> 

The major difference lies in the TLVs and sub-TLVs contained in that prefix specific opaque LSA rather than the opaque LSA itself which only needs a Opaque type code to be assigned.

Best regards,
Xiaohu

---

From: Peter Psenak <[email-masked]>
Date: Tue, 23 Jul 2013 09:02:21 +0200

Xuxiaohu,

> The major difference lies in the TLVs and sub-TLVs contained in that prefix specific opaque LSA rather than the opaque LSA itself which only needs a Opaque type code to be assigned.

then you should reuse the LSA as defined in the current SR draft.

thanks,
Peter

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 23 Jul 2013 09:37:27 +0000

> 发送时间: 2013年7月23日 15:02
> 主题: Re: 答复: [Status] fwd: New Version Notification for
> > The major difference lies in the TLVs and sub-TLVs contained in that prefix
> specific opaque LSA rather than the opaque LSA itself which only needs a
> Opaque type code to be assigned.
> 

There is no problem to reuse the prefix opaque LSA as defined in the SR draft once IANA has allocated a Opaque type code for it.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 24 Jul 2013 02:45:31 +0000

Hi Saku,

Sorry for missing the following email.

As you had pointed out, the second requirement has not been addressed in the current draft yet. It’s assumed in this draft that a label block has been agreed among all routers. As for the first requirement, operators could choose static allocation or dynamic allocation according to their operation custom. If they choose the static allocation approach, the potential label collision issue caused by mistaken configuration has to be taken into consideration.

Best regards,
Xiaohu

发件人: Saku Ytti [mailto:[email-masked]]
发送时间: 2013年7月19日 16:42
收件人: Xuxiaohu
抄送: [email-masked]
主题: Re: [Status] fwd: New Version Notification for draft-xu-rtgwg-global-label-adv-00.txt

Hi Xiaohu,

If I understand correctly there are two unique obstacles why different people oppose global labels

1. need for unique ID/label per node
       - your draft clearly solves this
       - but is this really a problem? Operators handle NET/CLNS/IPv4/IPv6 uniqueness today, so it's ingrained process?
       - I personally greatly favor local/static config to signalling/states, less things to break

2. need for globally agreed block
       - every application of every device must have 'hole' in their label manager for this block, so no other application tries to allocate label from this block
       - as I see it, in your proposal this demand still remains, that is if mapping server proposes that I use label 42, which I've already assigned for another application, things break?
       - essentially solution would be to implement such guarantee which is additional upgrade-cycle

I personally can accept both requirement and live with them. But I know there are people who say 2. is show stopper and such requirement cannot exist. 1. seem far less opposed.

Operationally I'm quite worried about the added external requirements for my local forwarding, but this might be just rush reaction to new idea.

On 19 July 2013 10:31, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Br,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> 发送时间: 2013年7月11日 16:18

_______________________________________________
status mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/status

--
  ++ytti

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 09:39:59 +0200

xuxiaohu,

the best proposal i have seen so far for resolving potential clashes
with global labels is roberts draft:

http://tools.ietf.org/html/draft-raszuk-mpls-domain-wide-labels-00

the draft proposes to use a context label for keying off in a separate
'domain-wide' label space - i.e. no clash with anybody in the networking
doing local label allocation.

note that i am still not convinced that we need domain-wide labels
(if we have SPT labels as per the latest SR protocol extensions).

/hannes

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 25 Jul 2013 08:07:06 +0000

Hi Hannes,

> -----邮件原件-----
> 发件人: Hannes Gredler [mailto:[email-masked]]
> 发送时间: 2013年7月25日 15:40
> 收件人: Xuxiaohu
> 抄送: Peter Psenak; [email-masked]; Robert Raszuk

Yes, there is no clash with existing transport or application labels which are locally significant. However, you still need some mechanism to ensure that a given domain-wide labels would not be assigned to different FECs (i.e., different node segments).

> (if we have SPT labels as per the latest SR protocol extensions).

What does the SPT label mean?

Best regards,
Xiaohu

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 10:20:00 +0200

> Yes, there is no clash with existing transport or application labels which are locally significant. However, you still need some mechanism to ensure that a given domain-wide labels would not be ass…

yes and that mechanism is administrative policy. if you treat a MPLS
label as global identifier you have to ensure that it does
to get allocated twice.

> What does the SPT label mean?

an SPT label  is a label inside a label block. the actual label
is determined by an index advertised by egress routers.
the path to the egress router gets determined using an SPT
calculation.

see

http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-02
http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-extensions-02

and

http://tools.ietf.org/html/draft-gredler-isis-label-advertisement-03
http://tools.ietf.org/html/draft-gredler-ospf-label-advertisement-03

for manifestations of this.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Jul 2013 10:22:36 +0200

> Yes, there is no clash with existing transport or application labels which
> are locally significant. However, you still need some mechanism to ensure
> that a given domain-wide labels would not be assigned to different FECs
> (i.e., different node segments).

You use the same mechanis as you use today to assign IPv4 or IPv6
prefix and make sure there is no overlap or duplication within your
IGP flooding scope.

Cheers,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 25 Jul 2013 08:43:07 +0000

> 发送时间: 2013年7月25日 16:20
> 抄送: [email-masked]; Robert Raszuk; Peter Psenak
> 主题: Re: [Status] 答复: fwd: New Version Notification for
> > Yes, there is no clash with existing transport or application labels which are
> locally significant. However, you still need some mechanism to ensure that a
> given domain-wide labels would not be assigned to different FECs (i.e., different
> node segments).
> 

It uses the trick which has been used by BGP-based VPLS solution. Interesting.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 25 Jul 2013 09:15:19 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Xuxiaohu
> 发送时间: 2013年7月25日 16:43
> 收件人: Hannes Gredler
> 主题: [Status] 答复: 答复: fwd: New Version Notification for

In this way, the labels would be locally significant. Then how to achieve source routing by using stacked MPLS tunnels ?

Xiaohu 

> > >>>> the flooding scope of the OSPFv2 Prefix Opaque LSA DOESN'T DEPEND
> on
> > the
> > >>>> content inside the LSA.
> > >>>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Jul 2013 11:21:51 +0200

Xu,

> routing by using stacked MPLS tunnels ?

With SPT label space is local, but label value and meaning is domain
wide. That's the beauty of it. Remember you are flooding ranges/block
as well as SID in IGP so your peers know it.

But It does add complexity in troubleshooting and operation :(.

Cheers,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 25 Jul 2013 09:33:02 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Robert
> Raszuk
> 发送时间: 2013年7月25日 17:22
> 收件人: Xuxiaohu
> 抄送: Hannes Gredler; [email-masked]; Peter Psenak
> 主题: Re: [Status] 答复: 答复: 答复: fwd: New Version Notification for

Oh, I see.

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 09:39:59 +0200

xuxiaohu,

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 17:28:53 +0200

> It uses the trick which has been used by BGP-based VPLS solution. Interesting.

precisely: BGP-VPLS with reversed semantics -

BGP-VPLS use source semantics (where does it come from)
SPT-labels use destination semantics (where does it go to)

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Jul 2013 17:40:27 +0200

On Jul 25, 2013, at 11:15 AM, Xuxiaohu wrote:

[ … ]

> In this way, the labels would be locally significant. Then how to achieve source routing by using stacked MPLS tunnels ?

SPT labels are used complimentary to 1-hop strict labels
(which are used for explicit routing)

in fact SPT labels can be seen as a way of compressing the
label-stack. lets say you have a given path with <N> segments
to a destination. what you can then do is to replace some of the <N>
segments with corresponding SPT labels.

furthermore the draft allows to have <M> algos infrastructure labels.
i.e. SPT(IGP metric), SPT(latency), SPT(TE-metric), MRT(red), MRT(blue) etc.
that way you increase the likelihood of finding a corresponding shared
path segment to replace an explicit segment.

the idea for multiple algos is that there aren't many dimensions to
optimize a network for (latency, utilization, bandwidth).

pre-computing all those topologies will give you
an "instruction set" for guiding your traffic with the most
minimal instructions possible.

/hannes