Nabil:
No, traffic aggregate is not the correct term, it is the set of BAs with a common code point in some diffserv domain. So it is independent of link, or path. It certainly is not the concept of a set of BAs with common forwarding and sharing a common constraint (which is what we are looking for). So IMHO the term is in not deficient, it is inaccurate.
If traffic trunk was not constrained to a granularity wall when hitting the LSP level, it would be the correct term, so we need to fix the definition, or coin a new term that decouples the concept of a common constrain aggregate with common forwarding from an LSP instantiation of the same.
cheers
Dave
> -----Original Message-----
> From: Nabil Seddigh [mailto:nseddigh@tropicnetworks.com]
> Sent: Monday, July 08, 2002 12:37 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Francois Le Faucheur; te-wg@ops.ietf.org
> Subject: Re: Another question on draft-ietf-tewg-diff-te-proto-01.txt
>
>
>
> 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
> > >
> > >
>