Subject: RE: Question on RSVP LSP Tunnel Spec

From: Shahram Davari <[email-masked]>
Date: Thu, 2 Sep 1999 13:40:49 -0700

See below:

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Thursday, September 02, 1999 1:03 PM
To: Francois Le Faucheur
Cc: Lou Berger; [email-masked]; [email-masked]';
[email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: Question on RSVP LSP Tunnel Spec

see below...

At 03:41 PM 9/2/99 +0200, Francois Le Faucheur wrote:
>Lou, Arvind,
>
>At 12:49 26/08/1999 -0400, Lou Berger wrote:
>>Arvind,
>>
>>Glad to hear things are clear on the CoS object.  
>>
>>In terms of the other draft, and draft-ietf-mpls-diff-ext-01.txt, I
suggest
>>you as ask the authors.  My reading was that the object was sufficiently
>>defined, but it's use was not.  I assumed that the authors meant:
>>	For path messages:
>>	<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> 
>>                                    [ <ADSPEC> ] [<DIFFSERV_PHS> ...]
>>	For resv:
>>       <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
>>                               [<DIFFSERV_PHS> ...] [ <RECORD_ROUTE> ]
>>
>>	and
>>
>>       <SE filter spec> ::=     <FILTER_SPEC> <LABEL> [<DIFFSERV_PHS> ...]
>>				[ <RECORD_ROUTE> ]
>>
>>
>
>Good suggestion. I will add this in the next version.
>
>To further clarify the usage of objects, our draft (which focuses
>exclusively on Diff-Serv - as opposed to pre-Diff-SErv TOS capabilities)
>assumed the following possible combinations for Diff-SErv support:
>	- traditional TSpec (ie with bandwidth), no DiffServ_PHS --> this is
an
>E-LSP with bandwith allocation
>	- traditional TSpec (ie with bandwidth), with DiffServ_PHS --> this
is an
>L-LSP with bandwith allocation
>	- "COS TSpec" (no bandwidth) COS=0, no Diff-Serv_PHS --> this is
E-LSP
>without bandwidth allocation
>	- "COS TSpec" (no bandwidth) COS=0, Diff-Serv_PHS --> this is L-LSP
>without bandwidth allocation
>
>Depending on the outcome of our open discussion on the need to support
>multiple E-LSPs, we may also have to allow signaling of PHS for E-LSPs.
>This would result in the following additional combinations:
>	- "COS TSpec" (no bandwidth) COS=0,  Diff-Serv_PHS --> this is E-LSP
>without bandwidth allocation
>	- traditional TSpec (ie with bandwidth) COS=0,  Diff-Serv_PHS -->
this is
>E-LSP with bandwidth allocation
>
>Now with respect to use of non-zero COS_FlowSpec/TSpec, Lou will
>confirm/correct my understanding:
><draft-ietf-mpls-rsvp-lsp-tunnel-02.txt> says:
>"The intent is to enable networks to support the  IP  ToS  Octet  as
>defined in RFC1349 [7].  It is noted that there is ongoing work within the
>IETF to update the use of  the  IP  ToS  Octet. In particular, RFC2474
>[8], obsoletes RFC1349.  However at this time the new uses of this field
>(now termed the  DS  byte)  are still being defined."
>Thus, I understand that use of non-zero value in the COS_FlowSpec/TSpec is
>intended to support pre-Diff-Serv TOS capabilities (as opposed to Diff-SErv
>capabilities). Therefore, an additional possible combination of object is:
>	- "COS TSpec" (no bandwidth) COS=non0, no Diff-Serv_PHS --> this is
LSP
>offering TOS-based Pre-Diff-SErv service without bandwidth allocation (This
>LSP does not offer a Diff-SErv service).
>

>>Agreed.

>I also understand that the following combination would NOT be allowed:
>	- "COS TSpec" (no bandwidth) COS=non0, Diff-Serv_PHS --> since the
>non-zero COS object would indicate pre-Diff-SErv TOS-based service while
>the Diff-Serv_PHS would indicate Diff-Serv service.
>

>>I think it should be allowed.  While this case is less likely to be used,
I
>>don't see a good reason to preclude its use by a provider.

>>Lou

It won't work, because these are two different requirements. Unless we agree
on one of them to have preference. 

>Do we agree on the above?
>
>Cheers
>
>Francois
>
>
[rest deleted]