Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)

From: Maarten Vissers <[email-masked]>
Date: Mon, 01 Jun 2009 14:53:34 +0200

Sasha,

I assume that it is **possible** to define that a "tunnel LSP" is used as an
"interface" for per-interface label space. If I understand the current
specification as quoted below, the existing RFC do not include this
definition. This implies that this definition needs to be added to the
specification.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: vrijdag 29 mei 2009 21:22
To: Francesco Fondelli
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI
(wasAssociatedbidirectionaltransportpathrequirements)

Francesco,
Lots of thanks for pointing to this statement in 3031.
I fully agree that "tunnel LSPs" cannot be used as "interfaces" for defining
per-interface label spaces.

Regards,
     Sasha

________________________________________
From: Francesco Fondelli [[email-masked]]
Sent: Friday, May 29, 2009 4:58 PM
To: Alexander Vainshtein
Cc: Heiles, Juergen (NSN - DE/Munich); [email-masked]
Subject: Re: [mpls-tp] AIS/FDI
(wasAssociatedbidirectionaltransportpathrequirements)

Hi Alexander,

On Thu, May 28, 2009 at 7:26 AM, Alexander Vainshtein
<[email-masked]> wrote:
[cut]
> RFC 3031 does not make it clear if a server layer LSP could be 
> considered an "interface" with a separate per-interface label space. 
> But taking into

No, it's clear.  Don't you know the earth is flat :-)?  You may represent a
LSP end-point as an i/f [RFC3812, Section 8], but you can't allocate a *new*
per-interface label space for that
(virtual) i/f.  "In MPLS, there is no notion of having a different label
space for different levels of the hierarchy; when interpreting a label, the
level of the label is irrelevant" [RFC3031, Section 3.14].

So there is no hierarchy form a label space view point and silicon has been
designed with this concept in mind.

> account unlimited depth of label stacking in MPLS, this would hardly 
> be feasible as the number of "label spaces" a LER has to maintain 
> would grow exponentially.
> AFAIK, per-platform label space is highly popular in MPLS and (as 
> noted earlier on this list), its usage is MANDATED for PW labels.
> IMHO and FWIW, ability of MPLS-TP to coexist with per-platform label 
> space is one of the key unresolved issues of the MPLS-TP project
[cut]

I agree, someone will realize it soon or later.

> Regards,
>      Sasha

Ciao
FF
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 1 Jun 2009 06:42:00 -0700

You should also read RFC5331 (http://www.ietf.org/rfc/rfc5331.txt) 

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: Monday, June 01, 2009 5:54 AM
> To: 'Alexander Vainshtein'
> Cc: [email-masked]
> Subject: Re: [mpls-tp] 
> AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements)
> 
> Sasha,
> 
> I assume that it is **possible** to define that a "tunnel 
> LSP" is used as an "interface" for per-interface label space. 
> If I understand the current specification as quoted below, 
> the existing RFC do not include this definition. This implies 
> that this definition needs to be added to the specification.
> 
> Regards,
> Maarten
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> I fully agree that "tunnel LSPs" cannot be used as 
> "interfaces" for defining per-interface label spaces.
> 
> Regards,
>      Sasha
> 
> No, it's clear.  Don't you know the earth is flat :-)?  You 
> may represent a LSP end-point as an i/f [RFC3812, Section 8], 
> but you can't allocate a *new* per-interface label space for that
> (virtual) i/f.  "In MPLS, there is no notion of having a 
> different label space for different levels of the hierarchy; 
> when interpreting a label, the level of the label is 
> irrelevant" [RFC3031, Section 3.14].
> 
> So there is no hierarchy form a label space view point and 
> silicon has been designed with this concept in mind.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 1 Jun 2009 18:29:19 +0300

John,
Lots of thanks for an advice.

Could you please clarify, whether you imply that MPLS-TP must use only upstream-allocated labels even for P2P LSPs?
IMHO and FWIW this could be indeed in line with one of the statements in 5331:

<quote>
   If the binding between L (label) and F (FEC) was made by a third party, say R3, and
   then advertised to both Ru and Rd, we also refer to the label binding
   as "upstream-assigned".
<end quote>

Regards,
     Sasha

> From: Drake, John E [mailto:[email-masked]] 
> Sent: Monday, June 01, 2009 4:42 PM
> To: Maarten Vissers; Alexander Vainshtein
> Cc: [email-masked]
> Subject: RE: [mpls-tp]

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 1 Jun 2009 09:07:21 -0700

Sasha,

I didn't mean to suggest anything.  I was simply pointing out that
RFC5331 had generalized RFC3031 to some extent and that hence it should
be included in the discussions as well.

Thanks,

John 

> From: Alexander Vainshtein [mailto:[email-masked]] 
> Sent: Monday, June 01, 2009 8:29 AM
> To: Drake, John E
> Cc: [email-masked]; Maarten Vissers
> Subject: RE: 
> [mpls-tp]AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements)
> 
> John,
> Could you please clarify, whether you imply that MPLS-TP must 
> use only upstream-allocated labels even for P2P LSPs?
> > > I assume that it is **possible** to define that a "tunnel LSP" is 
> > > used as an "interface" for per-interface label space.
> > > If I understand the current specification as quoted below, the 
> > > existing RFC do not include this definition. This implies 
> that this 
> > > definition needs to be added to the specification.
> > > 
> > > Regards,
> > > Maarten
> > > 
> > > No, it's clear.  Don't you know the earth is flat :-)?  You may 
> > > represent a LSP end-point as an i/f [RFC3812, Section 8], but you 
> > > can't allocate a *new* per-interface label space for that
> different 
> > > label space for different levels of the hierarchy; when 
> interpreting 
> > > a label, the level of the label is irrelevant" [RFC3031, Section 
> > > 3.14].
> > > 
> > > So there is no hierarchy form a label space view point 
> and silicon 
> > > has been designed with this concept in mind.
> > >

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 1 Jun 2009 09:08:17 -0700

But your quoted text does make one wonder.