RE: Another question on draft-ietf-tewg-diff-te-proto-01.txt

["David Allan" <dallan@nortelnetworks.com>]

Francois:

I agree that TT is not the idea term as the property changes once you switch
from E to E-LSP, and OA is misused similarly in other documents. I
originally didn't have a problem with TT as the definition in TE-REQs was
"placed inside an LSP" and I assumed that particular choice of words implied
cardinality did not have to be 1:1. But if there are other more restrictive
a-priori definitions, then that doesn't work either.

Not sure traffic aggregate works as defined. What we have is the subset of
an OA that is carried by a TT. And an E-LSP can carry a subset of one or
more OAs. How about "trunk ordered aggregate" and "link OA" to properly
distinguish the concepts....?

cheers
Dave
-----Original Message-----
From: Francois Le Faucheur [mailto:flefauch@cisco.com]
Sent: Friday, July 05, 2002 3:43 AM
To: Allan, David [CAR:NS00:EXCH]
Cc: Francois Le Faucheur; te-wg@ops.ietf.org; jboyle@pdnets.com;
kireeti@juniper.net; btownsend@tenornetworks.com; Skalecki, Darek
[SKY:QW12:EXCH]; flefauch@cisco.com; tnadeau@cisco.com
Subject: RE: Another question on draft-ietf-tewg-diff-te-proto-01.txt


David,

I think you're right that "OA" is not the ideal term since it is defined for
a given link, while what we want to say is "all packets belonging to a
Diff-Serv class and transitting between the same pair of tunnel Head-end and
tunnel Tail".

But your suggestion to replace "OA" with "Traffic Trunk" does not work
either because "traffic Trunk" is already a well defined term which by
definition means "everything transported on an LSP" (whether it comprises
one or many Diff-Serv "classes") 

I looked into the Diff-Serv document to see if I could find some better
term. And here's what I found in RFC3086:
" Traffic Aggregate: a collection of packets with a codepoint that
     maps to the same PHB, usually in a DS domain or some subset of a DS
     domain.  A traffic aggregate marked for the foo PHB is referred to
     as the "foo traffic aggregate" or "foo aggregate" interchangeably.
     This generalizes the concept of Behavior Aggregate from a link to a
     network.
I think this is exactly what we need. 
So we could update section 3.5 with this term
  e.g 
"The DS-TE solution must allow operation over E-LSPs onto which 
   traffic from a single Traffic Aggregate is transported...."

What do you think?

We'd need to agree fairly quickly because the -reqts- document should be on
its way to IESG already. Comments anyone else?

Thanks

Francois

At 14:55 04/07/2002 -0400, David Allan wrote:


Thanks Francois: 

I'd suggest for clarity that section 3.5 of the requirements document
replace the term  "OA" with "traffic trunk", so what you get is:

   The DS-TE solution must allow operation over E-LSPs onto which 
   traffic from a single traffic trunk is transported. 
    
   The DS-TE solution must allow operation over L-LSPs. 
    
   The DS-TE solution may allow operation over E-LSPs onto which 
   traffic from multiple traffic trunks is transported, under the condition
that 
   traffic from those trunks can effectively be treated by DS-TE as a 
   single atomic traffic trunk (in particular this means that traffic 
   from those multiple trunks is routed as a whole based on a single 
   collective bandwidth requirement, a single affinity attribute, a 
   single preemption level, a single Class-Type, ...). In that case, it 
   is also assumed that traffic trunks are transported in a consistent
manner 
   throughout the DS-TE domain (either entirely by E-LSPs or L-LSPs but not
via a 
   concatenation of LSP types). 

IMHO it would be a more consistent application of the terminology. 

cheers 
Dave 

> -----Original Message----- 
> From: Francois Le Faucheur [mailto:flefauch@cisco.com] 
> Sent: Thursday, July 04, 2002 1:27 PM 
> To: Allan, David [CAR:NS00:EXCH] 
> Cc: te-wg@ops.ietf.org 
> Subject: Re: Another question on draft-ietf-tewg-diff-te-proto-01.txt 
> 
> 
> Dave, 
> 
> At 12:48 04/07/2002 -0400, David Allan wrote: 
> 
> 
> >Section 3.3.1 states: 
> >...LSRs MUST support for every LSP, an additional 
> configurable parameter 
> >which indicates the Class Type of the Traffic trunk 
> transported by the 
> >LSP... 
> > 
> >This implies a 1:1 relationship between TTs and LSPs, this wouldn't 
> >necessarily be true for an E-LSP. Now the mechanisms don't 
> currently exist 
> >to support associating multiple class types/bandwidth 
> constraints for an 
> >E-LSP, but if traffic trunk is exclusively an L-LSP concept, 
> couldn't we pin 
> >this down a bit more explicitly..? 
> 
> This is detailed in section "3.5. Mapping of Traffic to LSPs" of 
> <draft-ietf-tewg-diff-te-reqts-05.txt>. 
> We have not restated all assumptions of -reqts in the -proto 
> draft. We just 
> describe what extensions are required to satisfy those 
> assumptions/requirements. 
> 
> Thanks 
> 
> Francois 
> 
> 
> >thanks 
> >Dave 
> 
>