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

[Nabil Seddigh <nseddigh@tropicnetworks.com>]

Dave,

Traffic Trunk is a heavily loaded word. I would prefer to stick
with accepted Diffserv terminology unless it is deficient. 
In this regard, I think Francois suggestion of "Traffic Aggregate"
(previous email) is more appropriate.

Best,
Nabil


David Allan wrote:
> 
> 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
> >
> >