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

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

Jim,

> It sounds like it comes down to an argument of speed of progress -v-
> correctness. 
> 
> In the interest of speed and correctness, maybe the following addition
> to the dste-proto draft would work:
> 
> ---------------------------------
> // constraint based routing becomes section 8
> ---------------------------------
> 7.  Diffserv TE support with MPLS extensions.
> 
> There are a number of extensions to the initial base specification for
> signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE].  These
> include enhancements for generalization [GMPLS-SIG][GMPLS-ROUTE], as
> well as for additional functionality such as LSP hierarchy
> [HIERARCHY], link bundling [BUNDLE] and fast restoration
> [REROUTE]. These specifications may reference how to encode
> information at certain priorities, as well as how to treat LSPs at
> different priorities.
> 
> In order for an implementation to support both this specification for
> Diff-Serv-aware TE, and a given MPLS enhancement such as those listed
> above (but not limited to those), it must treat references to
> "priority" in a generalized manner, such as it is used in this
> specification.  Additionally, current and future enhancements may
> include specification for how they interact with Diff-Serve-aware TE.
> 
> Encoding of values of priority in signaling or at a priority for
> route-information should be considered to be an encoding of the same
> information at the equivalent TE-Class.  For instance, if an
> enhancement advertises parameters for routing information at priority
> N, it should actually advertise the information for that parameter at
> TE-Class N.  On receipt, Diff-Serv-aware TE routers should interpret
> it as such as well.
> 
> When there is discussion on how to comparatively treat LSPs of
> different priority, a Diff-Serv-aware will treat the priority in this
> context as the priorities associated with the TE-Classes of the LSPs
> in question.
> 
> ---------------------------------
> Non-normative reference additions.
> 
> [GMPLS-SIG] Berger et. al., "Generalized Multi-Protocol Label
> Switching (GMPLS) Signaling Functional Description", RFC3471
> 
> [GMPLS-ROUTE] Kompella et. al., "Routing Extensions in Support of
> Generalized MPLS", draft-ietf-ccamp-gmpls-routing-05.txt, work in
> progress.
> 
> [BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic
> Engineering", draft-ietf-mpls-bundle-04.txt, work in progress.
> 
> [HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS
> TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress.
> 
> [REROUTE] Pan et. al., "Fast Reroute Extensions to RSVP-TE for LSP
> Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, work in
> progress.
> 
> ---------------------------------

I agree with your proposed approach and additions to the dste-proto draft.  Hopefully we can move forward quickly to revise the dste-proto draft, and finalize it.

Thanks,
Jerry