Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments

From: Shahram Davari <[email-masked]>
Date: Mon, 26 Jun 2000 12:58:04 -0700

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 

>-----Original Message-----
>From: Bora Akyol [mailto:[email-masked]]
>Sent: Monday, June 26, 2000 3:45 PM
>To: Shahram Davari
>Cc: 'Puneet Agarwal'; [email-masked]'
>Subject: Re: draft-ietf-mpls-diff-ext-05.txt comments
>
>
>Shahram
>Comments within.
>
>Shahram Davari wrote:
>
>> Puneet,
>>
>> Please see my comments:
>>
>
><<snipped>>
>
>> >4) pg 36, 5th paragraph: when a LSR can only support preconfigured
>> >EXP <--> PHB mapping, if someone wants to set up the per label
>> >EXP <--> PHB
>> >mapping, what error should the LSR return? Hopefully this 
>error code is
>> >different than "Diff-Serv Error" to differentiate it from invalid
>> >EXP <--> PHB mapping.
>>
>> As mentioned in section 5.3, two scenarios may exist:
>>
>> 1) In case the node only supports configured E-LSP, the node does not
>> recognize Diffserv object at all -> "Unknown Object Error"
>>
>> 2) In case the node supports configured E-LSP and L-LSP, The 
>node does not
>> recognize C-type = 1 (Signaled E-LSP) -> "Unknown Object C-type"
>>
>
>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.
>
>
>>
>> Regards,
>> -Shahram
>>
>> >
>> >-Puneet
>> >
>
>

---

From: "tom worster" <[email-masked]>
Date: Tue, 27 Jun 2000 11:33:59 -0400

From: [email-masked] [mailto:[email-masked]]On Behalf Of 
Shahram Davari

> >From: Bora Akyol [mailto:[email-masked]]
      <snip>
> >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

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Shahram
> Davari
> Sent: Tuesday, June 06, 2000 11:54 AM
> To: 'tom worster'; [email-masked]
> Cc: 'CATANZARITI Sergio FTR&D/TI'; [email-masked]
> 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.