Subject: How to progress DSTE, particularly p -> TE-Class[i] = {CT, p}

From: Jim Boyle <[email-masked]>
Date: Tue, 19 Aug 2003 01:03:06 -0400 (EDT)

One issue that draft-sivabalan-diff-te-bundling-02.txt highlights is that 
there may be text in existing RFCs and I-Ds for MPLS/TE which address how 
to support priority preemption between LSPs.  

draft-ietf-tewg-diff-te-proto-04.txt redefines the reservable bandwidth 
available at priority "p" to be the reservable bandwidth available for 
TE-Class "i" where that is defined as:

     TE-Class[i]  <-->  < CTc , preemption p >  

Where this mapping is defined locally.

This creates a problem, as improvements to the base of MPLS, for
instance bundled links refer to how to address the particulars of that
improvement with regards to priority, would also likely beof use e
might want to in a diff-serv TE environment as well.

It is obvious that one should assume that where one reads about "p" they 
should be thinking TE-Class[i], however it would be best for this to be 
explicitly stated somewhere.

Before the DSTE proto draft and the BC models progress to WG last call, 
I'd like to see this resolved.

There are 3 approaches that I've heard suggested.

1) Address this in the diff-te-proto draft. State that for the IGP and
RSVP RFCs, as well as technologies that improve upon them
(e.g. FA-LSP, link bundling, etc..), in order to be diff-serv TE
compliant, you need to map all references of "p" to TE-Class[i]

2) Address this in a parallel document to diff-te-proto, and let 
diff-te-proto progress to IESG before this is resolved.  This parallel 
document will somehow generalize "p" in base documents, and diff-te-proto 
will fit on-top of that (somehow)

3) Generalize "p" in the base documents, RFC3209, the igp-traffic drafts, 
all of the other MPLS/TE and GMPLS drafts as well.  For the record, I am 
not personally in favor of this approach.

Please advise how you propose we move forward with this,

thanks,

Jim

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 20 Aug 2003 08:04:19 -0500

Jim,

> improvement with regards to priority, would also likely be of use
> Please advise how you propose we move forward with this.

I'd favor option 1, the issue relates directly to the proto spec and needs to be addressed there.  Option 2 is complicated, and only addresses the issue indirectly, the issue is left hanging until the 'proto-2' draft is issued as an RFC.  Option 3 seems far too complex.

Hopefully we can move forward quickly to revise the proto draft, and finalize it.

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 27 Aug 2003 13:53:58 +0100

Jim and all,

I favor approach 2). Specifically, this separate document would make the
necessary generalisation to cover Link Bundles and FA-LSPs.
One of the benefits I can see in that approach is that we can be more
explicit about exactly how DS-TE works in the context of Link Bundles
and in the context of FA-LSP. It would make it very clear exactly where
DS-TE has an impact on each of Link-Bundling and FA-LSP and how it will
work.
Also, it would allow us to address details which are specific to the
DS-TE-over-Bundle or DSTE-over-FA-LSP and would not be captured by
generalisation statements a la "p is mapped to TE-class[i]". For
example, the lsp-hierarchy draft defines how the Traffic Engineering
parameters of a FA-LSP are derived including the Unreserved Bandwdith
and the Max Reservable bandwidth. Where DS-TE runs over the FA-LSP, it
may be that the natural behaviour would no longer be to set all intial
Unreserved Bw values to the FA-LSP bandwidth, but rather to set to zero
all those that relate to TE-classes whose CT is different to the FA-LSP
CT. Similarly, there is a question as to how you select the BC values
over an FA-LSP (for example assuming RDM, perhaps it should be that, if
FA-LSP belongs to CTn, then BCm=<FA-LSP Bandwidth> if m<=n, and BCm=0 if
m>n ). These rules are open to discussion of course and they may not be
the right ones, I don't know yet, but there are just examples of things
which are specific to DSTE operations over FA-LSP and that we may want
to think about and specify.
Another benefit of course, is that we can finalise DS-TE proto without
any further delays.

If we were to go with approach 1), we would also need some words to
capture the other dimension of the generalisation, which is that
references to "Max Reservable Banwdith" should be mapped to "<Max
Reservable Bw, BCs>"

I agree 3) is not very viable.

Cheers

Francois

>> -----Original Message-----
>> From: Jim Boyle [mailto:[email-masked]] 
>> Sent: 19 August 2003 07:03
>> To: [email-masked]
>> Subject: How to progress DSTE, particularly p -> TE-Class[i] 
>> = {CT, p}
>> 
>> 
>>