Subject: Announcing draft-ietf-mpls-diff-ext-04.txt and progressing to Last Call

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 17 Mar 2000 14:45:24 +0100

Hello,

As agreed, draft-ietf-mpls-diff-ext-04.txt was issued as a result of the
informal Last Call on the alias. This is with the objective of issueing a
formal Last Call in Adelaide.

Here's the status regarding comments received during informal last call:

1) some comments related to some confusion on the purpose of signaling
bandwidth at LSP set-up. This has been addressed by the addition of section
1.6 "Bandwidth Reservation for E-LSPs and L-LSPs" and of "Appendix B
Example BAndwidth Reservation Scenarios".

2) some comments related to some confusion on the meaning of the signaled
Int-Serv service in RSVP, as well as the meaning of bandwidth signalled in
RSVP , for Diff-Serv (as opposed to Int-Serv). This has been addressed by a
new paragraph (4th paragraph) in section 5.6.

3) comments/suggestions on options for PHB determination in case of
hierarchical tunnels. We are still working on this one. In particular,
we're looking at how much can be resued from the Diff-SErv work regarding
"Diff-SErv over IP Tunnels". We will come back with a proposed resolution
before Adelaide.

4) suggestion to add extensions for signaling per-PHB/per-PSC bandwidth at
E-LSP set-up. See email thread titled "RE: BANDWIDTH RESERVATION - RE:
Announcing".

Let us know if we missed any outstanding issue

Thanks for the comments

Francois

>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
>Date: Fri, 25 Feb 2000 15:35:04 -0500
>To: Shahram Davari <[email-masked]>
>From: Francois Le Faucheur <[email-masked]>
>Subject: BANDWIDTH RESERVATION - RE: Announcing
>  draft-ietf-mpls-diff-ext-03.txt 
>Cc: "'Juha Heinanen'" <[email-masked]>, [email-masked],
>        Francois Le Faucheur <[email-masked]>, [email-masked],
[email-masked],
>        [email-masked], [email-masked], [email-masked],
>        [email-masked]
>Sender: [email-masked]
>X-SMTP-HELO: wodc7-1.corprelay.mail.uu.net
>X-SMTP-MAIL-FROM: [email-masked]
>X-SMAP-Received-From: outside
>X-SMTP-PEER-INFO: wodc7-1.corprelay.mail.uu.net [192.48.96.68]
>
>Everyone,
>
>I had the impression that, behind the discussion, there may have been a few
>assumptions which did not seem valid to me. Let me discuss those first and
>then make a proposal.  
>
>(1) Doing per-label bandwidth signaling/reservation does NOT mean doing
>scheduling on a per-LSP-basis.
>I can signal bandwidth for each LSP, do admission control for that signaled
>bandwidth over a common pool of resources (eg the scheduling
>bandwidth/weight of a class queue) and then schedule that LSP on an
>aggregate basis as part of the common class queue. This is what the current
>draft assumed when discussing bandwidth reservations.
>
>One example of that, is MPLS Traffic Engineering in a pure Best Effort
>network. A bandwidth is signaled for each LSP at set-up time (be it via
>RSVP or CR-LDP), every node does admission control for EACH LSP over the
>"Maximum Reservable Bandwidth for Traffic Engineering" , if successful the
>LSP is set-up and its packets get queued on an aggregate basis (with
>packets from every other LSPs) into the common FIFO queue (Default PHB).
>
>RSVP Aggregation (draft-ietf-issll-rsvp-aggr-01.txt) is another example of
>environment where admission control and scheduling are performed at
>different levels of granularity: admission control in the core is performed
>on a per AGGREGATE reservation basis while scheduling is performed on a
>much more aggregated basis: pure Diff-Serv scheduling (not
>per-aggregate-Reservation scheduling).
>
>(2) Doing bandwidth signaling/reservation for a BA does NOT require
>modifying the corresponding scheduling/PHB  parameters.
>I may want to signal bandwidth for a BA to be transported over an LSP,
>purely to do admission control over PHB/scheduling resources which have
>been provisioned before (via CLI, SNMP, COPS,..) and which do not get
>modified dynamically. One may want to be able to modify them dynamically in
>some future but certainly does not have to.
>
>
>Having said this, my proposal to address the concerns discussed in the
>thread is the following:
>
>	- To absolutely avoid any misconceptions, the RSVP section of the draft
>could explicitely state that this draft defines usage of E-LSPs and L-LSPs
>for support of the Diff-Serv service ONLY and NOT for support of Int-Serv
>services. Regardless of whether the signaling messages actually indicate an
>Int-Serv service of COS, GS or CL and regardless of whether the signalling
>message contain a signaled bandwidth or not, E-LSPs and L-LSPs are only
>defined here for support of Diff-SErv services (and not Int-Serv services). 
>Achieving support of Int-Serv services over a Diff-Serv backbone (and in
>particular over Aggregated RSVP reservations) is within the scope of the
>ISSLL working group and progressed there.
>
>	- the draft could contain a bandwidth reservation section applicable to
>both RSVP and LDP. The current text already clearly states that Diff-Serv
>LSPs can be set-up with or WITHOUT bandwidth reservations. But we should
>expand by saying that:
>		* an example of a valid model is to not signal bandwidth at LSP set-up
>where straight Diff-Serv is to be supported (eg. no Constraint BAsed
>Routing). This is the closest model to Diff-Serv over non-MPLS (all
>Diff-Serv resources provisioned off-line eg CLI, SNMP, COPS..., Diff-Serv
>traffic is SPF routed).
>		* an example of valid model is to signal bandwidth at LSP set-up where
>Diff-Serv and Constraint Based Routing (TE) is to be supported. This allows
>the Network Administrator to combine the benefits of Diff-Serv (Classes of
>Services) and of MPLS TRaffic Engineering/Constraint-BAsed-Routing (ie
>distribute my network load).
>		* Some text would clarify point (1) above : Doing per-label bandwidth
>signaling/reservation does NOT mean doing scheduling on a per-LSP-basis.
>some text would restate that the required scheduling is always pure
>Diff-Serv PHB at the granularity of BA (not label), whether bandwidth is
>signaled or not. 
>		* some text could clarify point (2) above : Doing bandwidth
>signaling/reservation for a BA does NOT require modifying the corresponding
>scheduling/PHB parameters. Signaled bandwidth may be used only for
>admission control purposes over Provisioned/static Diff-SErv resources.
>Optionally it could be used to modify the Diff-Serv resources dynamically.
>		* some text would clarify that when a bandwidth is signaled for an L-LSP,
>the signaled bandwidth is obviously associated with the corresponding PSC.
>		* some text would clarify that when a bandwidth is signaled for an E-LSP,
>the bandwidth is an aggregated bandwidth across all the PSCs supported. (I
>agree with Curtis that it is useful to be able to signal a bandwidth
>separately for a BA [eg for per-Diff-SErv-Class Traffic Engineering as
>being discussed by the TE Working Group] but I don't agree that we need
>this over E-LSPs. I think it is sufficient to be able to do that using
>L-LSPs , which can be done as defined in current version of the draft).
>
>Francois
>
>
>
>At 06:43 23/02/2000 -0800, Shahram Davari wrote:
>>Hi Curtis,
>>
>>As Juha said, I don't think it is a good idea to introduce LSP BW
>>reservation in a Diffserv core. After all Diffserv was invented to get rid
>>of per-flow state. Similarly, I don't think it is feasible (although it is
>>certainly possible) to implement another level of scheduling before the
>>Class queues at high speeds (OC-192 and higher) used in the core.
>>
>>However, I think the BW signaling may be used for either LSP setup Admission
>>Control (similar to Yoram Bernet's draft in ISSL WG), or for fine tuning the
>>manual provisioned BW which is already assigned to each Class (which no
>>draft or RFC has talked about it yet). 
>>
>>Regards,
>>Shahram 
>>
>>> -----Original Message-----
>>> From: Juha Heinanen [mailto:[email-masked]]
>>> Sent: Wednesday, February 23, 2000 2:09 AM
>>> To: [email-masked]
>>> Cc: Francois Le Faucheur; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]
>>> Subject: Re: Announcing draft-ietf-mpls-diff-ext-03.txt 
>>> 
>>> 
>>> curtis,
>>> 
>>> ok, i didn't notice that you proposed separate weights for each ba in
>>> the lsp.  i did couple of years ago the same proposal for atm diffserv
>>> support, but then it was thought that it is simpler to have traffic
>>> class spcific weights in all links of the network.  that way 
>>> it doesn't
>>> matter which way the vcs are routed, since the weights will 
>>> be the same
>>> everywhere.  
>>> 
>>> weights per traffic class are also much simpler to implement 
>>> in routers,
>>> since you only would need as many queues as there are traffic classes.
>>> if you have weights per traffic class per lsp, you need hierarchical
>>> scheduler that first allocates the resources for the lsp and 
>>> then inside
>>> the lsps for the traffic classes.
>>> 
>>> the question is, how complex we want to make this?  it is easy to
>>> specify things, but are the router vendors really willing to support
>>> hierarchical scheduling?
>>> 
>>> -- juha
>>> 
>> 
>_________________________________________________________________
>Francois Le Faucheur   
>Development Engineer, IOS Layer 3 Services 
>Cisco Systems 
>Office Phone:   	+33 4 92 96 75 64
>Home Office Phone:     +33 4 92 94 00 78
>Mobile :               +33 6 89 10 81 59
>Vmail:                 +33 1 58 04 62 66
>Fax:                   +33 4 92 96 79 08
>Email:          	[email-masked]
>_________________________________________________________________
>Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
>_________________________________________________________________ 
> 

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	[email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________