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

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 04 Jul 2002 19:27:00 +0200

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

---

From: "David Allan" <[email-masked]>
Date: Thu, 4 Jul 2002 14:55:55 -0400

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:[email-masked]]
> Sent: Thursday, July 04, 2002 1:27 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]
> Subject: Re: Another question on draft-ietf-tewg-diff-te-proto-01.txt
> 
> 
> Dave,
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 05 Jul 2002 09:42:44 +0200

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:

>    traffic from multiple traffic trunks is transported, under the 
> condition that
>    throughout the DS-TE domain (either entirely by E-LSPs or L-LSPs but 
> not via a
> > From: Francois Le Faucheur 
> [<mailto:[email-masked]>mailto:[email-masked]]

---

From: "David Allan" <[email-masked]>
Date: Mon, 8 Jul 2002 13:11:09 -0400

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

> From: Nabil Seddigh [mailto:[email-masked]]
> Sent: Monday, July 08, 2002 12:37 PM
> Cc: Francois Le Faucheur; [email-masked]
> 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
> > Sent: Friday, July 05, 2002 3:43 AM
> > Cc: Francois Le Faucheur; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; Skalecki, Darek
> > [SKY:QW12:EXCH]; [email-masked]; [email-masked]
> > 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".
> >

---

From: "David Allan" <[email-masked]>
Date: Mon, 8 Jul 2002 13:24:40 -0400

You mean to support the engineering of individual class types in an E-LSP?
An E-LSP by definition carries mulitple class types....

cheers
Dave

> Sent: Monday, July 08, 2002 12:29 PM
> Mechanisms to support multiple class types on an E-LSP were proposed
> in this WG. Some providers and vendors expressed interest in 
> such schemes. However, in Utah, the WG felt that standardizing
> multiple OA-ELSP would be premature until the basic DS-TE
> mechanisms are standardized and shown to be viably deployable.
> 
> Updated versions of the related drafts can be found below:
> 
> http://www.ietf.org/internet-drafts/draft-ganti-tewg-diffserv-
> multicos-elspreq-00.txt
> http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-
> elsp-02.txt
> 
> Best,
> Nabil Seddigh
> 
> 
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 09 Jul 2002 10:48:40 +0200

Dave,

>An E-LSP by definition carries mulitple class types....

Not quite.
By definition and E-LSP is CAPABLE of carrying traffic from multiple 
Traffic Aggregate. But it is perfectly fine to transport traffic from 
differnet Traffic Aggregates on differnet E-LSPs (i.e. one Traffic 
Aggregate per E-LSP).

When you do not do DS-TE, you woudl generally transport multiple Traffic 
Aggregates over E-LSPs.

When you do DS-TE you would either:
         - use L-LSPs
         - use E-LSPs with traffic from a single Traffic Aggregate
         - use E-LSPs with traffic from multiple Traffic Aggregates BUT you 
then have a few constraints (see REQTS draft) such as not being able to 
perform separate Constraint Based Routing of each TA on  a given E-LSP.

Cheers

Francois

> > From: Nabil Seddigh 
> [<mailto:[email-masked]>mailto:[email-masked]]
> <http://www.ietf.org/internet-drafts/draft-ganti-tewg-diffserv->http://www.ietf.org/internet-drafts/draft-ganti-tewg-diffserv- 
>
> > multicos-elspreq-00.txt
> > 
> <http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv->http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv- 
>
> > elsp-02.txt
> >
> > Best,
> > Nabil Seddigh
> >
> >
> >

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 09 Jul 2002 10:58:44 +0200

David,

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

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

---

From: "David Allan" <[email-masked]>
Date: Tue, 9 Jul 2002 09:09:43 -0400

I'm not spotting the difference between what you are saying and what I am
saying....only potential correction to my statement is that I should have
been more precise and said '"can" carry multiple class types.'
 
rgds
Dave

 -----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 4:49 AM
To: Allan, David [CAR:NS00:EXCH]
Cc: Nabil Seddigh; [email-masked]
Subject: RE: Another question on draft-ietf-tewg-diff-te-proto-01.txt

Dave,

Not quite.
By definition and E-LSP is CAPABLE of carrying traffic from multiple Traffic
Aggregate. But it is perfectly fine to transport traffic from differnet
Traffic Aggregates on differnet E-LSPs (i.e. one Traffic Aggregate per
E-LSP).

Cheers

Francois

cheers 
Dave

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 09 Jul 2002 16:29:45 +0200

>been more precise and said '"can" carry multiple class types.'

that's the point.
It is a significant differenece in the context of DS-TE since one major 
deployment option for DS-TE is precisely to use E-LSPs each transporting 
traffic from a single Diff-SErv class.

Cheers

Francois

---

From: "David Allan" <[email-masked]>
Date: Fri, 12 Jul 2002 09:05:41 -0400

Nabil:

Understood, my issue is not the functionality, it is the terminology. Sort
this out in Yokahoma....

later
Dave

> Sent: Wednesday, July 10, 2002 4:32 PM
> Yes indeed this issue was vigorously discussed on the list -
> circa the Utah IETF. 
> 
> In summary: the current DS-TE mechanisms are not tailored to 
> carrying multiple classes of traffic on a single E-LSP. They are 
> geared towards carrying a single class per E-LSP or L-LSP. 
> 
> The proposals I referred to in a previous email allow signaling 
> of bw requirements for mutiple classes on an E-LSP. However,
> at present, the WG did not deem it timely to adopt them
> as WG items.
> 
> > So what do we do about E-LSPs carrying traffic from more 
> than one aggregate.
> > It is engineerable (at some level of granularity)? Looks like an
> > orphan...and I'll apologise in advance if this has already 
> been flogged on
> > the list...
> > 
> 
> Best,
> Nabil Seddigh
>