Subject: RE: Question on RSVP LSP Tunnel Spec

From: Lou Berger <[email-masked]>
Date: Thu, 02 Sep 1999 17:03:36 -0400

At 01:40 PM 9/2/99 -0700, Shahram Davari wrote:
>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. 
>
>

Huh.  I think of non0 CoS as translating into administratively controlled
resource allocation.  It primarily differs from the "traditional TSpec (ie
with bandwidth), with DiffServ_PHS" case in how the allocation is
established, i.e. configured versus signaled.  If traditional TSpec works
then non0 CoS should work.  (Assuming that the non0 CoS to allocations must
be locally configured on each LSR.)

Lou

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 06 Sep 1999 17:29:37 +0200

Lou,

as usual, see below:

>be locally configured on each LSR.)

I am not with you. To me what indicates "administratively controlled
resource allocation" is not strictly a "non0 COS". It is simply the fact
that you have a COS TSpec. In other words, if you have a COS-TSpec , then
no bandwidth is signaled (whether the COS field of the COS Tspec is equal
to zero or not).

Then, once you have opted for "administratively controlled resource
allocation" and thus use a "COS TSpec", you may either :
	- (i) indicate some Diff-SErv information (via the Diff-SErv_PHS Object)so
that the resource allocation takes into account the PHS -eg this LSP will
use resources configured for this PHS- , 
	- or (ii) indicate some TOS information (via the non-zero COS field inside
the COS TSpec) so that the resource allocation takes into account the TOS
for Pre-Diff-SErv support -eg this LSP will use resources configured for
this TOS- .

So, I do not understand what it would mean to indicate both Diff-SErv info
and TOS info for a given LSP. 
On which of the above assumptions do we diverge? 

Thanks

Francois

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Phone:  +33 4 92 96 75 64
Mobile : +33 6 07 78 69 67
Vmail:   +33 1 69 18 62 66
Fax:      +33 4 92 96 79 08
Email: [email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________

---

From: Lou Berger <[email-masked]>
Date: Tue, 07 Sep 1999 08:40:01 -0400

>On which of the above assumptions do we diverge? 

I was thinking primarily about case (ii) for nodes that don't know what to
do with PHS information while other nodes could use the PHS information.
There's no question I'm talking about a fringe (transition) case here.  As
I said before, I'm not advocating this approach as a right or good way,
just that there doesn't seem to be value in precluding it.

Do you think there's benefit by prohibiting this case?

Lou

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 07 Sep 1999 16:06:49 +0200

>At 05:29 PM 9/6/99 +0200, Francois Le Faucheur wrote:
clip....

>just that there doesn't seem to be value in precluding it.

I am with you. Thanks for the clarification.

>Do you think there's benefit by prohibiting this case?

I am happy to leave it in now that we have an agreed meaning for the
combination : "use the PHS if you understand it, use the COS value otherwise".

I will try to capture this discussion clarifying the meaning of various
combinations (COSTSpec/BwTSpec/PHS) in the next version of the Diff-Serv ID.

Francois

---

From: Lou Berger <[email-masked]>
Date: Tue, 07 Sep 1999 10:17:47 -0400

Great.  I guess it would have helped had I started out by stating it as
succinctly as you did!

Lou