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

Hi Jim,

>> -----Original Message-----
>> From: Jim Boyle [mailto:[email protected]] 
>> Sent: 10 September 2003 16:51
>> To: [email protected]
>> Subject: Re: How to progress DSTE, particularly p -> 
>> TE-Class[i] = {CT, p}
>> 
>> 
>> 
>> It sounds like it comes down to an argument of speed of progress -v-
>> correctness. 
>> 

I didn't really see it as speed vs accuracy. I imagined that approach 2
would give us speed for the -proto AND correctness for the MPLS
extensions (because we could go in more details on the actual
interactions of DS-TE with the actual MPLS extension).

But I can live with approach 1. In which case, I'd suggest your text
below would also want to discuss the generalisation of "Max Resv-->Max
Resv + BCs" (in addition to the generalisation "p-->TE-class" ).

If we go approach 1, could you also comment on the following point from
my earlier message :
>> 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.

Thanks

Francois


>> In the interest of speed and correctness, maybe the 
>> following addition
>> to the dste-proto draft would work:
>>
>> ---------------------------------
>> // constrait based routing becomes section 8
>> ---------------------------------
>> 7.  Diffserv TE support with MPLS extensions.
>> 
>> There are a number of extensions to the initial base 
>> specification for
>> signalling [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 signalling or at a priority for
>> route-information should be considered to be an encoding of the same
>> information at the equivilant 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.
>> 
>> ---------------------------------
>> 
>> 
>>