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

[Francois Le Faucheur <flefauch@cisco.com>]

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 
> > 
> >