[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Dave,

At 09:03 09/07/2002 -0400, David Allan wrote:


If we are explicitly constraining applicability to E-LSPs (single traffic
aggregate), and our terminology only applys to the contrained version, then
the sentence is fine. It is confusing that that the terminology/scope does
not cover all possible attributes of E-LSPs.

There are two topics which in my opinion are completely separate:

1) mapping of traffic from different Diff-SErv "classes" onto E-LSPs/L-LSPs
2) vocabulary question on how to refer to Diff-SErv "classes"

I believe 1) is addressed correctly in the DSTE-REQTS document (except it happens to use the wrong term, but its content is correct). There are three cases:
        - traffic from a single "class" per E-LSP
        - L-LSP
        - traffic from Multiple "classes" per E-LSP but then there are some constraints/restrictions.
Do you agree?

Issue 2) is that we simply need the right term to be able to formulate 1).  We just need to be able to refer to Diff-Serv "classes" correctly to formulate 1). "TRaffic Aggregate" has been defined for that, so we should use it.
Do you agree?

There is no question that we currently do NOT have a term to designate the subset of traffic which is the intersection of (i) a particular Traffic Trunk AND (ii) a Traffic Aggregate. But we do NOT need such a term. Or do we?


So what do we do about E-LSPs carrying traffic from more than one aggregate.
It is engineerable (at some level of granularity)?

yes. It is engineerable at some granularity. DSTE-REQTS document already discusses that. It is the third case I mentioned above:

"
The DS-TE solution may allow operation over E-LSPs onto which traffic from multiple OAs is transported, under the condition that traffic from those OAs can effectively be treated by DS-TE as a single atomic traffic trunk (in particular this means that traffic from those multiple OAs 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 OAs are grouped together in a consistent manner throughout the DS-TE domain (e.g. if OA1 and OA2 are transported together on an E-LSP, then there will not be any L-LSP transporting OA1 or OA2 on its own and there will not be any E-LSP transporting OA1 or OA2 with another OA).
"

Looks like an
orphan...and I'll apologise in advance if this has already been flogged on
the list...

It is not an orphan . It is discussed, as per text included above.

Cheers

Francois

PS: I changed the title of that thread because it actually does NOT relate to the PROTO draft, but rather to the REQTS draft

cheers
Dave


-----Original Message-----
From: Francois Le Faucheur [mailto:flefauch@cisco.com]
Sent: Tuesday, July 09, 2002 4:59 AM
To: Allan, David [CAR:NS00:EXCH]
Cc: Nabil Seddigh; Francois Le Faucheur; te-wg@ops.ietf.org
Subject: RE: Another question on draft-ietf-tewg-diff-te-proto-01.txt


David,

At 13:11 08/07/2002 -0400, David Allan wrote:


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

No, we are not exactly looking for such a term. We could, but that is not
where we started from, and I don't think we need that term.

We are just looking for a correct way to designate traffic from the same
Diff-Serv "class". Because we just want to say that traffic from a given
Traffic Trunk (ie transported by a given LSP) may be a subset of one "class"
or of multiple "classes".

I think the following sentence is perfectly correct . No?
"The DS-TE solution must allow operation over E-LSPs onto which traffic from
a single Traffic Aggregate is transported...."

Now, if you wanted a term to designate the subset of a Traffic Trunk which
belongs to a particular Traffic Aggregate, then you would need a new term.
But I don't this we need that.

Thanks

Francois


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