The MPLS WG Archive

["tom worster" <tom@ennovatenetworks.com>]

From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of 
Shahram Davari

> Bora,
> 
> Could you please identify why/how a node could understand the Diffserv
> object and the E-LSP C-type and still can't support the 
> signaled E-LSP.
> 
> -Shahram 
>
> >From: Bora Akyol [mailto:akyol@pluris.com]
>
      <snip>
> >
> >Why not have another error code for nodes that understand the 
> >DS object but can
> >not provide per-label context. This makes sense to me.


i think bora's suggestion makes sense.

one example that fits: you recently described a method of 
cacheing exp->phb mappings (excerpt from your mail below). the 
method was an example of an lsr design that requires less 
memory in total than one that stores a mapping with each lsp. 
it's probably not worth using that cacheing method unless the 
maximum number of mappings the lsr can cache is designed to be 
smaller than the maximum number of lsps it can simultaneously 
support. if the mapping cache were to be exhausted, the error 
code bora described would be appropriate.

none of the error/status codes defined seem appropriate in
this case: the ds object/tlv was not unexpected; the 
mapping is not invalid; and the phbs are not unsupported.
"cannot provide per-label context" sounds like it would
fit.

another example: for reasons associated with routeing, a 
network may want to keep certain sets of phbs separated 
from each other on different lsps. in such a case, lsrs might 
be configured to not accept certain combinations of phbids 
in an e-lsp ds object/tlv. (i can imagine other reasons to
use similar policies.)

c u
tom



> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram
> Davari
> Sent: Tuesday, June 06, 2000 11:54 AM
> To: 'tom worster'; curtis@avici.com
> Cc: 'CATANZARITI Sergio FTR&D/TI'; mpls@UU.NET
> Subject: RE: MPLS Diffserv Extensions related questions/comments 

  <snip>

> Regarding the reduction of per-LSP memory; well it all 
> depends on what you
> are comparing it to. One solution which will reduce the 
> per-LSP memory and
> still uses the signaled EXP->PHB mapping is to build a few 
> general purpose
> EXP->PHB mapping tables (in each LSR), from the first few LSP setup
> messages, and use them as an index in per-LSP ILM/NHLFE 
> tables.  Using this
> method, the amount of per-LSP memory is less than  or equal to your
> proposal.