[mpls-tp] RE: 答复: Looking for alternative term for per-interface MIP

[maarten vissers <[e-mail]>]

Sasha,

The text in section 3 of RFC 5331 defines the concept of context-specific label spaces

   RFC 3031 describes per-platform and per-interface label spaces. This
   document introduces the more general concept of a "Context-Specific
   Label Space".  An LSR may maintain one or more context-specific label
   spaces.

The text in this section 3 lists a couple of context-specific label space examples and ends with the following notion:

   There may be other sorts of contexts as well.  For instance, we
   define the notion of an MPLS label being used to establish a context,
   i.e., identify a label space.  A "context label" is one that
   identifies a label table in which the label immediately below the
   context label should be looked up.

RFC 5331 is as such open to other context-specific label spaces.

An example of such other context-specific label space is a MPLS-TP Section and a MPLS-TP transport-LSP. Other examples could be Working and Protection SPME-LSPs.

I can't find in this specification of context-specific label space that each such label space must support ~1M label entries. This would be a complete overkill. In most cases 256, 512, 1024, 2048 or 4096 entries would be more than enough.

A system with e.g. 16 Section label spaces, each such label space supporting 512 transport-LSPs, 512 transport-LSP label spaces, each such label space supporting 511 service-LSP/PW/(H)VPLS entries can be supported by a single ~1M label table.

Regards,
Maarten


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Alexander Vainshtein
> Sent: 10 December 2010 08:01
> To: [e-mail]; Greg Mirsky
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] 答复: Looking for alternative term for per-
> interface MIP
> 
> Steven, Greg and all,
> IMHO and FWIW, the definition of Section in MPLS-TP is one of the most
> problematic ones, because it represents an attempt to hide the
> differences between data links (physical, or logical as in the case of
> VLANs) and Tunnel LSPs, by treating the former as "LSPs with the label
> stack of depth 0".
> 
> Tons of confusion have already stemmed from this attempt.
> The recent discussion about the requirement to carry different clients
> over a Section (after publication of RFC 5960) is just one more example
> of such a confusion.
> 
> And of course per-Section label space is yet another example of this
> confusion.
> 
> RFC 3031 has defined per-platform and per-interface label spaces; and
> at that time nobody dealing with MPLS had any doubts about what an
> interface means.
> 
> At the same time RFC 3391 has more or less explicitly prohibited label
> space per terminated LSP when it stated that the position of the label
> in the label stack cannot affect its treatment when it is looked up.
> 
> This has been somewhat tweaked in RFC 5331 which has defined context-
> specific label spaces and "context labels" to be used in conjunction
> with upstream label allocation in LSPs crossing LAN interfaces.
> 
> But this is a far cry for a full-fledged "per-Section" label space when
> Section can be a terminated LSP.
> 
> The main technical reason against  is per-Section label spaces is
> scalability:
> - Existing label spaces assume that incoming labels are looked up in a
> small number of ILM supporting 1M entries each (since the number of
> interfaces and/or contexts is usually small)
> - Supporting full-fledged "per-Section" label space for LSP-based
> Sections would mean that we would need (at least in theory) to
> implement ~1M of ILMs with 1M entries each. IMO this goes far beyond
> reason and existing technical capabilities.
> 
> Does this make sense to you?
> 
> Regards,
>      Sasha