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

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 04 Jul 2000 10:29:15 +0200

Hello,

Here's a proposal for review, to address the thread on New Error Codes.

1) "per-LSP context allocation failure"
=========================================

* Add one Error Value to the "Diff-Serv Error" (in RSVP section 5.5): 
    5     Per-label context allocation failure   

* Add corresponding text in the RSVP section "5.3 Handling Diff-Serv Object".
Something like:
"A node receiving a PAth message with the DIFFSERV object, which recognizes the
DIFFSERV object but that is unable to allocate the required per-LSP Diff-Serv
context sends a PathErr with the error code "Diff-Serv Error" and the error
value "Per-label context allocation failure".

* similar additions to coresponding LDP sections

2) "Policy Control Failure"
===========================

This refers to the last example given below by Tom where an LSP set-up may be
rejected because of policies.

Regular RSVP already has an Error Code for reservations rejected because of
Policy Control:
"Error Code = 02: Policy Control failure
        Reservation or path message has been rejected for administrative
        reasons, for example, required credentials not submitted,
        insufficient quota or balance, or administrative preemption.
        This Error Code may appear in a PathErr or ResvErr message.
        Contents of the Error Value field are to be determined in the
        future."

I would propose to rely on this existing error code.

Would that be acceptable or do you see a lot of value in identifying that it is
a "Diff-Serv Policy Control Failure"?

Thanks

Francois

At 11:33 27/06/2000 -0400, tom worster wrote:
>From: [email-masked] [mailto:[email-masked]]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:[email-masked]]
>>
>      <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: [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.
>  
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	[email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________

---

From: Bora Akyol <[email-masked]>
Date: Wed, 05 Jul 2000 10:31:17 -0700

These look good to me.

Bora

---

From: "tom worster" <[email-masked]>
Date: Wed, 5 Jul 2000 18:16:39 -0400

From: [email-masked] [mailto:[email-masked]]On
> 1) "per-LSP context allocation failure"

this looks fine.

> 2) "Policy Control Failure"

not really. your suggestion for rsvp looks ok. but i'm unsure
what to do with ldp. i checked through the ldp and crldp specs
and didn't notice anything suitable. hmmm.

btw: as i was checking through the docs i noticed that in section
5.3 of the -05 draft the term "the reservation" is used in a way
that is potentially confusing. elsewhere in the document the word
is only used to refer to bandwidth reservations (this seems also 
to be true of the rsvp-lsp-tunnel draft) but in section 5.3 it 
seems to be used to refer to a label request.

c u
tom