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

["Ash, Gerald R (Jerry), ALABS" <gash@att.com>]

Jim,

> 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 be of use
> 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.

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