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

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 3 Sep 2003 12:22:44 +0100

Hello Jim,

I've edited the RDM and MAM I-Ds to reflect the proposal I posted
earlier on the TEWG list regarding relationship with Shared Mesh
Restoration. The only item left before we can post the drafts and go to
last call is the issue you raised below on how to handle Link Bundles
and FA-LSPs. What's your recommandation on that? May I follow approach
2?

Thanks

Francois

>> -----Original Message-----
>> From: Francois Le Faucheur (flefauch) 
>> Sent: 27 August 2003 14:54
>> To: Jim Boyle; [email-masked]
>> Subject: RE: How to progress DSTE, particularly p -> 
>> TE-Class[i] = {CT, p}
>> 
>> 
>> 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}
>> >> 
>> >> 
>> >> 
>> >> 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: raymond zhang <[email-masked]>
Date: Tue, 09 Sep 2003 14:03:51 -0700

Hi,

Option 2 below seems to be a better choice to address this in a timely
fashion.

Regards,
Raymond

    * To: <mailto:[email-masked]>[email-masked]
    * Subject: How to progress DSTE, particularly p -> TE-Class[i] = {CT, p}
    * From: Jim Boyle <<mailto:[email-masked]>[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:

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.

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.

thanks,

Jim

---

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Wed, 10 Sep 2003 09:36:10 +0200

Hi Jim and all,

I support option 2, as it avoids postponing proto draft.

JL

-----Message d'origine-----
De : Jim Boyle [mailto:[email-masked]]
Envoye : mardi 19 aout 2003 07:03
A : [email-masked]
Objet : How to progress DSTE, particularly p -> TE-Class[i] = {CT, p}

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.  

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

thanks,

Jim

---

From: Jim Boyle <[email-masked]>
Date: Wed, 10 Sep 2003 10:51:22 -0400 (EDT)

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:

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

---------------------------------

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 10 Sep 2003 10:20:01 -0500

Jim,

> // constraint based routing becomes section 8
> signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE].  These
> Encoding of values of priority in signaling or at a priority for
> information at the equivalent TE-Class.  For instance, if an

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

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 10 Sep 2003 16:30:45 +0100

Hi Jim,

>> Sent: 10 September 2003 16:51
>> To: [email-masked]
>> Subject: Re: How to progress DSTE, particularly p -> 
>> TE-Class[i] = {CT, p}
>> 
>> 
>> 

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

Thanks

Francois