Subject: Re: [Isis-wg] Advertising MPLS labels in IGP

From: Hannes Gredler <[email-masked]>
Date: Thu, 25 Apr 2013 14:19:53 +0200

+ isis-wg, as some of my customers have already complained that the
discussion on segment routing is not done on public mailing lists.

On Apr 25, 2013, at 1:58 PM, Saku Ytti wrote:

> Yeah, this is quite like in BGP/VPLS. 
> 
> It's been discussed/suggested in SR, but at least to me it seems like additional complexity.  

well first and foremost it is inline with current MPLS framework and domain-wide labels
are not - so the IESG police is going to ask some tough questions.
if you are breaking the law you rather need to have some good reasoning.

i fail to see what additional complexity it is if i use an ordinal to
the label range offered by my downstream router to determine the actual
label value, rather than explicitly signaling the label value (and hoping) that
no router in the domain will clash with the reserved label range.

my take is that giving up the notion of router-local label assignment
is something which can not easily done as one might not oversee the
consequences if doing so.

> I'm not against it at all personally, but I'd just like to understand why introduce this additional complexity. I like idea of global labels quite much, much like I like idea of global IP loopbacks.

global-significant labels have been discussed before and people
have decided against it; why open the discussion again,
and what facts have been changed since then ?

> But if there is practical problem with them, I'm happy to root for this range+index solution. Right now I get feeling rationale is 'lets do it like this, because it's been like this before' and I think how it is like today was wrong decision to begin with. 

may i ask you to go back to IETF60 meeting minutes:
http://www.ietf.org/proceedings/60/195.htm

scroll down to the following paragraph:

---
Source Routed MPLS LSP using Domain Wide Label 
draft-tian-mpls-lsp-source-route-01.txt, Albert Tian 

This draft introduces global labels as a means of source routing or loose source routing a packet in an MPLS network. If each destination of interest (say all of the loopback addresses used as router-IDs) had a label which was both globally known and globally used by all routers, then one could source route a packet by stacking up labels for each of the routers in the source route. This technique could be applied to fast reroute. 

In the ensuing discussion it was pointed out that the idea of global labels had been discussed in the early days of MPLS. At that time it was decided that labels would only have local significance (within the forwarding plane). Many workgroup members expressed opposition to such a fundamental change to the MPLS architecture. Alex Zinin stated, "The workgroup is done with architecture. Unless it can be proved that architecture is not sufficient then this doesn't fit in charter." --
---

> 
> On 25 April 2013 14:46, Hannes Gredler <[email-masked]> wrote:
> saku, et al,
> 
> the main question is why do we need to have a need for a domain-wide
> label allocation pool, if this can be avoided ?
> 
> there are well known techniques where every router independently
> advertises a label block and an ordinal for himself.
> see http://tools.ietf.org/html/rfc4761 for a working example
> of this.
> 
> label-block advertisement would allow to create SPT labels for every
> destination *without* the need for a domain-wide punch in the label space.
> 
> see attached an example for this.
> an SPT path to R7 is created here.
> 
> /hannes
> 
> 
> On Apr 16, 2013, at 8:20 AM, Saku Ytti wrote:
> 
>> On 16 April 2013 05:47, Hannes Gredler <[email-masked]> wrote:
>>> HG> domain-wide labels needs the ability from all *neighboring* potential
>>> non-SR routers to *not* use a certain label range. so thats a pre-cursor.
>> 
>> I'm probably confused but can someone open this bit up for me.
>> 
>> As I see it, I would use my SRB(s) only towards SR capable node, all
>> other nodes that I may want to reach I have to use [SRB MAGIC] stack?
>> Conversely I would not signal to non-SR islands dynamically anything
>> from my SRB.
>> 
>> From non-SR POV, does it not look like happy coincidence that entire
>> domain has allocated same set of local labels?
>> 
>> I fully accept that label manager today has issue (as you can't tell
>> it context from which to allocate, label_manager_register('sr', 1000,
>> 10000)) but it does not look like hard to solve problem.
>> 
>> 
>> 
>> --
>>  ++ytti
>> 
> 
> 
> 
> 
> -- 
>   ++ytti

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Apr 2013 23:50:09 +0200

Hi Hannes,

> see http://tools.ietf.org/html/rfc4761 for a working example

So how would this work if I want to encap each segment in v4 or v6
address rather then mpls label ?

Would you send an address block with ordinal ?

Cheers,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 26 Apr 2013 10:32:50 +0200

On Thu, Apr 25, 2013 at 11:50:09PM +0200, Robert Raszuk wrote:
| > there are well known techniques where every router independently
| > advertises a label block and an ordinal for himself.
| > see http://tools.ietf.org/html/rfc4761 for a working example
| > of this.
| | So how would this work if I want to encap each segment in v4 or v6
| address rather then mpls label ?

i can only speculate how this would work as clarence has not
yet submitted a spec - all i have is his slides from MPLSWC/IPv6WC
in paris. my understanding is that for e.g. the IPv6-SR plane tries
to mimicry an MPLS data-plane (fixed size 32-bit segment-IDs
embedded into an IPv6 extension-header) and the behavior would be
pretty much identical for MPLS/IPv6-SR for the transit (=non PHP (POP))
case. i'll defer to him for making a comment;
  | Would you send an address block with ordinal ?

i can only comment on the PHP behavior of MPLS (where i think your 
question also applies,
see similar thread asking stefano to add the notion of an 'AF' to
disambiguate label-advertisement).

so in that spirit we could either have a
1. per-node ordinal (and use IPv6 explicit null to disambiguate whats 
inside)

    so PHP would program:

    label N, BOS=1, POP->IPv4
    label N, BOS=0, POP->recurse
      2. allocate one ordinal per-AF / per-node.

    so PHP would program:

    label N1, BOS=1, POP->IPv4
    label N2, BOS=1, POP->IPv6

so whether you do 1) or 2) depends on you hardware cap., i know that not 
everybody
can do recursive lookups, so perhaps 2) is safer to use.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Apr 2013 10:57:22 +0200

Hi Hannes,

> embedded into an IPv6 extension-header)

Well I think the issue with that would be that existing boxes would
not be able to switch based on the v6 extension header without an
upgrade ... I was rather thinking that compatibility with existing
data plane is very important. Stacking just v6 or v4 headers would be
perhaps simpler.

Of course with MPLS there is no issue in this respect.

> and the behavior would be

Indeed.

> i can only comment on the PHP behavior of MPLS (where i think your question also applies,

Yes I saw this. I also think per AF would be clean.

Thx,
R.

---

From: stefano previdi <[email-masked]>
Date: Fri, 26 Apr 2013 12:31:21 +0200

On Apr 25, 2013, at 2:19 PM, Hannes Gredler wrote:
> + isis-wg,

sure.

> as some of my customers have already complained that the

well... you did initiate the thread... ;-)

s.