From owner-mpls@UU.NET Wed Mar 1 07:46:41 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29638 for ; Wed, 1 Mar 2000 07:46:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieqc23428; Wed, 1 Mar 2000 12:43:53 GMT Received: by mail-control.mail.uu.net id QQieqc29493 for mpls-outgoing; Wed, 1 Mar 2000 12:43:28 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQieqc29488 for ; Wed, 1 Mar 2000 12:43:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieqc25065 for ; Wed, 1 Mar 2000 07:43:13 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQieqc22881 for ; Wed, 1 Mar 2000 12:43:12 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA27873 for mpls@uu.net; Wed, 1 Mar 2000 07:43:12 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQieqc29473 for ; Wed, 1 Mar 2000 12:42:43 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieqc25010 for ; Wed, 1 Mar 2000 07:42:25 -0500 (EST) Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQieqc22305 for ; Wed, 1 Mar 2000 12:42:24 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 67538125; Wed, 1 Mar 2000 13:42:22 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (flefauch-isdn-home.cisco.com [10.49.89.146]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id NAA24834; Wed, 1 Mar 2000 13:42:18 +0100 (MET) Message-Id: <200003011242.NAA24834@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 01 Mar 2000 11:36:43 -0500 To: curtis@avici.com From: Francois Le Faucheur Subject: Re: BANDWIDTH RESERVATION - RE: Announcing draft-ietf-mpls-diff-ext-03.txt Cc: Francois Le Faucheur , Shahram Davari , "'Juha Heinanen'" , curtis@avici.com, mpls@UU.NET, bsd@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@ntc.nokia.com, ram@nexabit.com, Pierrick.Cheval@alcatel.fr In-Reply-To: <200002260022.TAA09916@curtis-lt.avici.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Curtis, At 19:22 25/02/2000 -0500, Curtis Villamizar wrote: >You have a fine I-D and I do agree that L-LSPs can be used if >reservation per BA is desired. It is just more efficient to use an >E-LSP if more than one BA can be accomodated given the limited EXP >bits and also given the requirements of the BAs wrt fast-reroute, >adaptivity, and resilience match. In the interest of making that >improvement in efficience possible, I would prefer if you would add >per BA (or per PHB as the MAPs are now defined) bandwidth as an option >to the MAPs for E-LSPs. > >Please consider making this change to the I-D. > I am considering... but not convinced. We agree that if one wants to do per-OA Routing and per-OA admission Control, then this can be done using L-LSPs + bandwidth reservation as currently defined. Call this Mode 1. We also agree that if one wants to do aggregate routing of Multiple-OAs and Aggregate Admission Control of Multiple-OAs, then this can be done using E-LSPs + bandwidth reservation as currently defined. CAll this Mode 2. The suggestion above is for extensions allowing aggregate routing/transport of multiple-OAs with per-OA admission control. Call this MOde 3. Firstly, such an extension would also require defining the procedures and error code for handling situations where the admission control for one OA is successful while the admission control for another OA is rejected. You woudl have to reject the E-LSP explaining which admission control failed. Secondly, that would mean that you cannot route one OA onto a Path which has capacity for it simply because it happens to travel on an E-LSP along another OA which has run out of capacity. In other words, multi-OA Routing with per-OA admission control achieves less efficient routing than Mode 2 would. Is this not right? So, all in all, I still think: - you can do pretty good and label-efficient with Mode 1 - you can do the ideal per-OA thing with Mode 2. - Mode 3 does not have a strong application in between these 2. - there are already quite a lot of options in our spec... Do you still see a strong application for Mode 3 which would justify extensions in the MAP but also extensions in all the error codes and procedures (today we rely on normal RSVP error handling to signal rejection because of admission control)? Opinions from others? Cheers Francois >Thanks, > >Curtis > _________________________________________________________________ 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: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Wed Mar 1 10:03:20 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03834 for ; Wed, 1 Mar 2000 10:03:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieqm24659; Wed, 1 Mar 2000 15:00:04 GMT Received: by mail-control.mail.uu.net id QQieql25273 for mpls-outgoing; Wed, 1 Mar 2000 14:59:43 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQieql25264 for ; Wed, 1 Mar 2000 14:59:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieql12172 for ; Wed, 1 Mar 2000 09:59:16 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQieql20084 for ; Wed, 1 Mar 2000 14:59:15 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA08310 for ; Wed, 1 Mar 2000 07:00:02 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA29042 for mpls@uu.net; Wed, 1 Mar 2000 09:59:13 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQienj08863 for ; Tue, 29 Feb 2000 18:55:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQienj11750 for ; Tue, 29 Feb 2000 13:55:07 -0500 (EST) Received: from fortress.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1]) id QQienj06315 for ; Tue, 29 Feb 2000 18:55:06 GMT Received: from fnc01.fnc.fujitsu.com (fnc01.fnc.fujitsu.com [167.254.100.17]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id MAA05732; Tue, 29 Feb 2000 12:54:45 -0600 (CST) Received: from tddny.fujitsu.com (pc182.tddny.fujitsu.com [167.254.242.182]) by fnc01.fnc.fujitsu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FK2MTW2C; Tue, 29 Feb 2000 12:54:48 -0600 Message-ID: <38BC15ED.5FF51F07@tddny.fujitsu.com> Date: Tue, 29 Feb 2000 13:54:38 -0500 From: "Indra.Widjaja" X-Mailer: Mozilla 4.61 [en]C-CCK-MCD fnc_08_99 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Telecom Tom CC: mpls@UU.NET Subject: Re: MPLS: What For and How To? References: <38BA9D59.A5FDB6BC@veda-home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Telecom Tom wrote: > > 2. How to: Graph theory seems to be an issue that is seldom discussed > on this list. But if TE is an application of MPLS, why don't we have > more references to this area of applied math? My guess is that this > group is oriented to practical engineering and protocol development. > In that case, could anyone refer me to lists or newsgroups that > discuss the graph theoretical foundations of traffic engineering in > general and MPLS-based TE in particular, or to researchers and their > published articles on the latter (MPLS TE)? Tom: For information, we tried to reference the relevant articles in the TE framework document, and we'll add more in the next iterations. Online TE references are scattered throughout the literature. For offline TE, you can find a very good collection of techniques developed by Debasis Mitra (a real TE expert!) which is located at http://cm.bell-labs.com/cm/ms/who/mitra/pub.html indra > > > --Thanks, TT > ------------------------------------------------ > Tom Nelson Scott tom.scott@veda-home.com > The Veda Home Company Bowling Green, Ohio USA > "In IP We Trust" "E Pluribus Unix" > ------------------------------------------------ From owner-mpls@UU.NET Wed Mar 1 10:09:43 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04098 for ; Wed, 1 Mar 2000 10:09:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieqm28216; Wed, 1 Mar 2000 15:04:52 GMT Received: by mail-control.mail.uu.net id QQieqm29102 for mpls-outgoing; Wed, 1 Mar 2000 15:04:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQieqm29083 for ; Wed, 1 Mar 2000 15:04:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieqm19792 for ; Wed, 1 Mar 2000 10:03:58 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQieqm23039 for ; Wed, 1 Mar 2000 15:03:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA11673 for mpls@uu.net; Wed, 1 Mar 2000 10:03:42 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQieqm28183 for ; Wed, 1 Mar 2000 15:03:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieqm12775 for ; Wed, 1 Mar 2000 10:03:08 -0500 (EST) Received: from drawbridge.ascend.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: drawbridge.ascend.com [198.4.92.1]) id QQieqm22634 for ; Wed, 1 Mar 2000 15:03:08 GMT Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id GAA05220; Wed, 1 Mar 2000 06:56:45 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 1 Mar 2000 15:03:07 UT Received: from spud.ascend.com (spud [192.207.23.51]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id HAA18714; Wed, 1 Mar 2000 07:03:07 -0800 (PST) Received: from amalis ([152.148.173.91]) by spud.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id HAA10910; Wed, 1 Mar 2000 07:03:04 -0800 (PST) Message-Id: <4.2.2.20000301094927.025ce300@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 01 Mar 2000 10:02:58 -0500 To: mpls@UU.NET From: "Andrew G. Malis" Subject: Inconsistancy in draft-ietf-mpls-atm-02.txt? Cc: amalis@lucent.com, parkermr@boat.bt.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I'm at the ITU Study Group 13 meeting in Kyoto, and I was asked a question I don't really have a good answer for, so I'm going to the list. In draft-ietf-mpls-atm-02.txt, section 7.1, regarding direct connections between LSRs, says: The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI 32. Other values can be configured, as long as both parties are aware of the configured value. However, section 7.2, regarding the use of VPs between LSRs, says: In this case, the default VCI value of the non-MPLS connection between the LSRs is 32. The VPI is set to whatever is required to make use of the Virtual Path. Section 7.2 is missing the sentence "Other VCI values can be configured, as long as both parties are aware of the configured value.". Is there any good reason why this was omitted? If not, it really should be in there, since an ATM LSR/switch may want to use VCI 32 on the VP for other uses, especially if the VP is shared in "ships in the night" mode. On another note, I believe I have found a typo that also really needs to be fixed. In section 7, the text says: It SHOULD be possible to configure an LC-ATM interface with additional VPI/VCIs that are used to carry control information or non-labelled packets. In that case, the VCI values MUST be in the 0-32 range. I think that the final line should say "MUST NOT", not "MUST", since the range 0-31 is reserved by the ITU and ATM Forum for non-user traffic only. We still have time to get these fixed before the RFC comes out ... comments? Thanks, Andy From owner-mpls@UU.NET Wed Mar 1 15:11:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12117 for ; Wed, 1 Mar 2000 15:11:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQierg13971; Wed, 1 Mar 2000 20:09:12 GMT Received: by mail-control.mail.uu.net id QQierg05011 for mpls-outgoing; Wed, 1 Mar 2000 20:08:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQierg04994 for ; Wed, 1 Mar 2000 20:08:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQierg03205 for ; Wed, 1 Mar 2000 15:08:11 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQierg10470 for ; Wed, 1 Mar 2000 20:08:10 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id PAA27941; Wed, 1 Mar 2000 15:08:08 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id PAA16327; Wed, 1 Mar 2000 15:08:15 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003012008.PAA16327@curtis-lt.avici.com> To: Juha Heinanen cc: curtis@avici.com, Adrian Farrel , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: soft permanent lsps In-reply-to: Your message of "Wed, 01 Mar 2000 02:31:21 +0200." <14524.25817.810694.386860@lohi.eng.telia.fi> Date: Wed, 01 Mar 2000 15:08:15 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <14524.25817.810694.386860@lohi.eng.telia.fi>, Juha Heinanen writes: > Curtis Villamizar writes: > > > If the tunnel is truly transparent it appears as a single hop. When > > the customer LSR at one end sends a RSVP path message, it puts the > > fixed label over the IP packet. When it gets back a RESV message, it > > knows the label the other side wants to use. When it uses the LSP > > that was set up using that PATH and RESV message it puts the fixed > > label over the one negotiated in the setup. > > now you suddenly started assume that the customer routers exchange > signaling messages between each other, which is a totally different ball > game than what splsp i-d is all about. > > -- juha The customer can static route if they want. The point is that if they WANT to exchange information encapsulated as CLNP, IP, IP/RSVP, or MPLS, they CAN do it because it will all work. The label that gets traffic to go through the ISP is fixed. The label that indicates to the far end where the traffic came from is fixed and is completely up to the customer. The ISP is not involved in any of this except to agree to get traffic that comes in with a specific label to come out someplace else with one less label. Curtis From owner-mpls@UU.NET Wed Mar 1 16:19:10 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13400 for ; Wed, 1 Mar 2000 16:19:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQierl25556; Wed, 1 Mar 2000 21:16:08 GMT Received: by mail-control.mail.uu.net id QQierl17062 for mpls-outgoing; Wed, 1 Mar 2000 21:15:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQierl17049 for ; Wed, 1 Mar 2000 21:15:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQierl12107 for ; Wed, 1 Mar 2000 16:15:13 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQierl22480 for ; Wed, 1 Mar 2000 21:15:12 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id PAA01631; Wed, 1 Mar 2000 15:59:54 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id QAA16449; Wed, 1 Mar 2000 16:00:01 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003012100.QAA16449@curtis-lt.avici.com> To: Francois Le Faucheur cc: curtis@avici.com, Shahram Davari , "'Juha Heinanen'" , mpls@UU.NET, bsd@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@ntc.nokia.com, ram@nexabit.com, Pierrick.Cheval@alcatel.fr Reply-To: curtis@avici.com Subject: Re: BANDWIDTH RESERVATION - RE: Announcing draft-ietf-mpls-diff-ext-03.txt In-reply-to: Your message of "Wed, 01 Mar 2000 11:36:43 EST." <200003011242.NAA24834@europe.cisco.com> Date: Wed, 01 Mar 2000 16:00:01 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200003011242.NAA24834@europe.cisco.com>, Francois Le Faucheur write s: > Curtis, Francois, Thanks for the reply. There is one thing I may not have been clear about. > At 19:22 25/02/2000 -0500, Curtis Villamizar wrote: > > >You have a fine I-D and I do agree that L-LSPs can be used if > >reservation per BA is desired. It is just more efficient to use an > >E-LSP if more than one BA can be accomodated given the limited EXP > >bits and also given the requirements of the BAs wrt fast-reroute, > >adaptivity, and resilience match. In the interest of making that > >improvement in efficience possible, I would prefer if you would add > >per BA (or per PHB as the MAPs are now defined) bandwidth as an option > >to the MAPs for E-LSPs. > > > >Please consider making this change to the I-D. > > > > I am considering... but not convinced. > > We agree that if one wants to do per-OA Routing and per-OA admission > Control, then this can be done using L-LSPs + bandwidth reservation as > currently defined. Call this Mode 1. > We also agree that if one wants to do aggregate routing of Multiple-OAs > and Aggregate Admission Control of Multiple-OAs, then this can be done > using E-LSPs + bandwidth reservation as currently defined. CAll this Mode 2. > > The suggestion above is for extensions allowing aggregate routing/transport > of multiple-OAs with per-OA admission control. Call this MOde 3. Firstly, > such an extension would also require defining the procedures and error code > for handling situations where the admission control for one OA is > successful while the admission control for another OA is rejected. You > woudl have to reject the E-LSP explaining which admission control failed. > Secondly, that would mean that you cannot route one OA onto a Path which > has capacity for it simply because it happens to travel on an E-LSP along > another OA which has run out of capacity. In other words, multi-OA Routing > with per-OA admission control achieves less efficient routing than Mode 2 > would. > Is this not right? The purpose is not to do per OA admission control. From the standpoint of admission, the reservation is the sum of the OA reservations at a given holding-priority and the whole thing is either accepted or rejected. If accepted, some of the queue weights need to be adjusted. The per OA amounts are then used solely to adjust the correct queue wights by the correct amount. { \begin{aside} In my view of the world ATM CAC was a mistake worth not repeating. Overbooking (MAM in Awduche-speak) allows a transient condition where too much bandwidth may be temporarily accepted but later (not too much later if you get it right) attempts to reoptimize (ie: using a good adaptivity implementation, rather than the naive fixed timer approach) will then move traffic away from the transient congestion. \end{aside} } You may also want to do strict CAC, but if so, the LSP would be accepted or rejected based on the sum of the per-OA reservations. In either case this sum is what is subtracted from the advertised available reservable bandwidth per priority. > So, all in all, I still think: > - you can do pretty good and label-efficient with Mode 1 > - you can do the ideal per-OA thing with Mode 2. > - Mode 3 does not have a strong application in between these 2. > - there are already quite a lot of options in our spec... > > Do you still see a strong application for Mode 3 which would justify > extensions in the MAP but also extensions in all the error codes and > procedures (today we rely on normal RSVP error handling to signal rejection > because of admission control)? Yes. See above. You may have been thinking that we had some intention to use the per OA reservations for CAC. That was mistaken. When a reservation arrives we can configure the router to steal queue weight from best effort. This just provides an accurate means to determine where to apply the queue weight stolen from best effort. > Opinions from others? > > Cheers > > Francois Curtis From owner-mpls@UU.NET Wed Mar 1 18:01:22 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15906 for ; Wed, 1 Mar 2000 18:01:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQierr00185; Wed, 1 Mar 2000 22:59:17 GMT Received: by mail-control.mail.uu.net id QQierr03622 for mpls-outgoing; Wed, 1 Mar 2000 22:58:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQierr03609 for ; Wed, 1 Mar 2000 22:58:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQierr27358 for ; Wed, 1 Mar 2000 17:58:29 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQierr01195 for ; Wed, 1 Mar 2000 22:58:24 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id RAA09483; Wed, 1 Mar 2000 17:57:43 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id RAA16577; Wed, 1 Mar 2000 17:57:49 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003012257.RAA16577@curtis-lt.avici.com> To: "Ashish Monga" cc: "Kireeti Kompella" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: tunnels within tunnels and MPLS/RSVP ERO In-reply-to: Your message of "Wed, 01 Mar 2000 09:33:31 +0530." <00d301bf8333$1b7a16a0$160d85a5@testrras.dti.daewoo.co.kr> Date: Wed, 01 Mar 2000 17:57:49 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <00d301bf8333$1b7a16a0$160d85a5@testrras.dti.daewoo.co.kr>, "Ashish Monga" writes: > How is tunneling handled in case we use CR-LDP with ER-HoP TLV having LSPID > of LSP thru which new LSP is to be tunneled. > How are label request and label mapping messages processed in that case. From the standpoint of the pair of customer routers each router has a virtual interface. If you send traffic into the virtual interface on one customer router it comes out on the virtual interface on the other. If the customer wants to run LDP over such an interface that is fine. In each direction, the customer router adds two labels. One gets the traffic across the ISP who may be running RSVP, not LDP, and the other label identifies the source and gets the traffic to come out the correct virtual interface on the other customer router (and is entirely administered by the customer). As I've described it, there is no change to any of the signaling protocols or encapsulation required to do this except the conventions for processing the ERO last hop that I suggested earlier. This is simply a usage of MPLS. Curtis > -----Original Message----- > From: Kireeti Kompella > To: Curtis Villamizar > Cc: mpls@UU.NET ; kireeti@juniper.net > Date: Wednesday, March 01, 2000 8:07 PM > Subject: Re: tunnels within tunnels and MPLS/RSVP ERO > > > >Hi Curtis, > > > >> I have another question. This may be more of a usage question. This > >> time regarding how the ERO should appear when supporting tunnels > >> within tunnels. > > > >There are at least two issues here. Suppose we wish to tunnel LSPa > >(access LSR to access LSR) through LSPb (backbone). > > > >1) What does the ERO for LSPa look like? > >2) How does the head end of LSPb know when it gets the path message > > for LSPa to tunnel it through LSPb? > > > >Both are addressed in draft-kompella-mpls-optical, section 4.3. > >Issue 1) has two subcases: a) LSPb doesn't exist when LSPa is first > >signalled -- the signalling for LSPa creates LSPb; and b) LSPb exists > >when LSPa is signalled. > > > >> One way to do this is specify loose hops. The initial ERO would > >> contain from the ingress (a-LSR1) would contain a set of one or more > >> strict hops to the near end backbone LSR (b-LSR1), a single loose hop > >> specifying the far end backbone LSR (b-LSR2), and a single loose hop > >> to the egress LSR (a-LSR2). > > > >Note that in the above draft, we suggest that LSPb be advertised as > >a 'forwarding adjacency' as far as traffic engineering goes, so the > >hop from b-LSR1 to b-LSR2 can in fact be a strict hop. Yes, RSVP > >would need to see TE links as well as physical links for this to work. > > > >> One interpretation of this would create > >> separate tunnels across the backibone from each access LSR to each far > >> end access LSR. An alternate is for b-LSR1 to push a label on the > >> stack, and place the traffic within a tunnel with b-LSR2 at the > >> egress. > > > >How does b-LSR1 know which to do, i.e. to which LSPs the former applies, > >and to which the latter? > > > >We solve this problem by marking each link with an LSP hierarchy number. > >All links (unidirectional) on access LSRs are PSC-1. All links from > >backbone LSRs to access LSRs are also PSC-1. Links from a backbone LSR > >to another backbone LSR are PSC-2. > > > >If an LSR sees an ERO for LSPa such that the previous hop is over a > >PSC-1 link and the next hop over a PSC-2 link, the LSR knows that > >LSPa needs to be tunneled through another. The LSR determines the > >end point of the enclosing LSP, checks if there is an LSP going that > >way with enough bandwidth; if so, the LSR tunnels LSPa through it. > >Otherwise the LSR creates the enclosing LSP. Again, RSVP would have > >to have access to the TE database to do all this. > > > >> The ERO would need to be modified, replacing the loose hop > >> with SOMETHING maybe followed by a "MPLS label switched path > >> termination" subobject in the ERO. The backbone router is free to > >> reroute the backbone tunnel and all the access tunnels within it. The > >> far end backbone LSR (b-LSR2) would do a similar replacement on the > >> next loose hop. > >> > >> My question is what is that "SOMETHING". It would seem that a strict > >> hop would be needed but the type IPv4 might not be as appropriate as a > >> type which indicates an LSP and provide the LSP-ID of the backbone > >> tunnel in which the tunnel is encapsulated. > > > >Our approach was to IP-number the enclosing LSP (forwarding adjacency), > >so normal IPv4 strict hops just work. > > > >Also, the "MPLS label switched path termination" subobject would not > >be necessary in our framework, as the egress of the enclosing LSP sees > >a transition from PSC-2 to PSC-1 link in the ERO. > > > >Note that an ERO-based scheme for determining where to start and end > >a tunnel (such as yours) provides a finer granularity of control than > >one that marks interfaces (such as ours). > > > >> Alternately, the IP > >> address of the egress of the tunnel can be put in the ERO and sent > >> through the tunnel. > >> > >> Either way it seems that this requires that an RSVP adjacency be > >> formed through the tunnel. This means that in a network of 100 > >> routers where each has 5 physical adjacencies, 104 (99+5) RSVP > >> adjacencies would be needed. That doesn't seem like a good solution > >> but I don't know of an alternative. > > > >New topic: is it worth tunneling LSPs within LSPs? > > > >Let's take your example: 100 backbone routers with an out-degree of > >5. The average number of hops between router pairs is about 3. > >Let's say the typical path across the backbone looks like: A-B-C-D. > > > >Suppose there are N access-to-access LSPs passing through A-B-C-D. > >If there was no forwarding adjacency, A, B, C and D all see 5 RSVP > >adjacencies and RSVP state for N LSPs. > > > >If there was a forwarding adjacency A->B->C->D, and all N LSPs went > >over this adjacency, then for the cost of one new LSP and one new > >RSVP adjacency, the RSVP state has nearly been halved: A and D have > >state for N+1 LSPs while B and C have state for 1 LSP. > > > >If the average hops between LSRs (diameter?) goes up, the state > >savings increase. If the number of tunneled LSPs per forwarding > >adjacency (N) increases, the overhead decreases. > > > >My humble opinion is that the size of the RSVP state is of greater > >significance than the number of RSVP adjacencies, but I'm willing > >to be educated. > > > >Going back to the question "is it worth tunneling LSPs within LSPs?" > >I would say, "Probably". > > > >> I'd be very happy if someone told me that the answer was already > >> clearly spelled out in one of the drafts and that I just somehow > >> missed it. > > > >We'd like to think the our draft spells this out, although perhaps > >not clearly. Note that the draft is focused on MPL(ambda)S, but > >the tunneling of electronic LSPs through electronic LSPs falls out > >fairly naturally in the paradigm of electronic LSPs tunneled through > >SONET trails tunneled through optical trails ... > > > >Kireeti. > > > > From owner-mpls@UU.NET Wed Mar 1 23:22:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23362 for ; Wed, 1 Mar 2000 23:22:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiesn02215; Thu, 2 Mar 2000 04:20:25 GMT Received: by mail-control.mail.uu.net id QQiesn08366 for mpls-outgoing; Thu, 2 Mar 2000 04:20:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiesn08349 for ; Thu, 2 Mar 2000 04:19:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiesn00018 for ; Wed, 1 Mar 2000 23:19:41 -0500 (EST) Received: from osf1.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQiesn09910 for ; Thu, 2 Mar 2000 04:19:41 GMT Received: from localhost (bjabbari@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id XAA19405 for ; Wed, 1 Mar 2000 23:19:39 -0500 (EST) Date: Wed, 1 Mar 2000 23:19:39 -0500 (EST) From: Bijan Jabbari To: mpls@UU.NET Subject: AIL - The MPLS Interoperability Lab Funded by UUNET Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Dear Colleagues, On March 1, the Advanced Internet Laboratory (AIL) at George Mason University (GMU) held its day-long technical meeting with its potential sponsors in advance of its MPLS interoperability testing. The participating companies were those who attended the December 1, 1999 sponsorship agreement meeting and consisted of major MPLS router vendors and ISPs. The meeting included presentations and discussions of AIL's testing methodology, detailed test plans and schedule. It is expected that AIL will receive the MPLS capable equipment from its sponsors in the latter part of March and begin the MPLS interoperability testing in early April. The testing will be conducted on an on-going basis. The Advanced Internet Lab at GMU, Fairfax, VA (a suburb of Washington DC) has been established and funded by a grant from UUNET Technologies. Although the lab's objective is to establish a cohesive program of research and possibly development on the Internet technology in particular MPLS, the initial mission is to help foster the MPLS interoperability among major router vendors, through the interoperability testing. As you might know, in 1998, UUNET Technologies and GMU jointly launched the first major MPLS Conference. For the past several months, AIL has been working with major vendors to iron out the issues of intellectual property rights, non-disclosure and confidentiality. As a result two documents have been prepared which govern participation as sponsor of the Lab and a multilateral agreement among all Lab participants. If your company is involved in MPLS service or product and you wish to join this effort and become a sponsor of the lab, we will be pleased to provide you with additional information. Regards, - Bijan -------------------------------------- Bijan Jabbari, PhD Advanced Internet Lab George Mason University, Johnson Center, G10 Fairfax, VA 22030-4444 Tel: +1 703.993.4705 (Direct) Tel: +1 703.993.4700 (Assistant) email: bjabbari@gmu.edu From owner-mpls@UU.NET Thu Mar 2 10:56:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15995 for ; Thu, 2 Mar 2000 10:56:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieuh09041; Thu, 2 Mar 2000 15:52:48 GMT Received: by mail-control.mail.uu.net id QQieuh09371 for mpls-outgoing; Thu, 2 Mar 2000 15:52:17 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQieuh09363 for ; Thu, 2 Mar 2000 15:52:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieuh27588 for ; Thu, 2 Mar 2000 10:51:50 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQieuh08227 for ; Thu, 2 Mar 2000 15:51:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA26255 for mpls@uu.net; Thu, 2 Mar 2000 10:51:48 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQieuh09220 for ; Thu, 2 Mar 2000 15:51:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieuh27405 for ; Thu, 2 Mar 2000 10:51:10 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQieuh07504 for ; Thu, 2 Mar 2000 15:51:10 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA00638; Thu, 2 Mar 2000 07:51:02 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Mar 2000 07:11:31 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4041E@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Andrew G. Malis'" , mpls@UU.NET Cc: parkermr@boat.bt.com Subject: RE: Inconsistancy in draft-ietf-mpls-atm-02.txt? Date: Thu, 2 Mar 2000 07:09:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Andy, I think you are right. Because VCI=0-31 is used for ATM F4 cells (I.610), and VCI=32 is used as the default non-MPLS (e.g. LDP) connection, so if additional VPI/VCIs is being configured they should not use VCI=0-32. Regards, -Shahram > -----Original Message----- > From: Andrew G. Malis [mailto:amalis@lucent.com] > Sent: Wednesday, March 01, 2000 10:03 AM > To: mpls@UU.NET > Cc: amalis@lucent.com; parkermr@boat.bt.com > Subject: Inconsistancy in draft-ietf-mpls-atm-02.txt? > > > I'm at the ITU Study Group 13 meeting in Kyoto, and I was > asked a question > I don't really have a good answer for, so I'm going to the list. > > In draft-ietf-mpls-atm-02.txt, section 7.1, regarding direct > connections > between LSRs, says: > > The default VPI/VCI value for the non-MPLS connection is > VPI 0, VCI > 32. Other values can be configured, as long as both parties are > aware of the configured value. > > However, section 7.2, regarding the use of VPs between LSRs, says: > > In this case, the default VCI value of the non-MPLS connection > between the LSRs is 32. The VPI is set to whatever is required to > make use of the Virtual Path. > > Section 7.2 is missing the sentence "Other VCI values can be > configured, as > long as both parties are aware of the configured value.". Is > there any > good reason why this was omitted? If not, it really should > be in there, > since an ATM LSR/switch may want to use VCI 32 on the VP for > other uses, > especially if the VP is shared in "ships in the night" mode. > > On another note, I believe I have found a typo that also > really needs to be > fixed. In section 7, the text says: > > It SHOULD be possible to configure an LC-ATM interface with > additional VPI/VCIs that are used to carry control information or > non-labelled packets. In that case, the VCI values MUST be in the > 0-32 range. > > I think that the final line should say "MUST NOT", not > "MUST", since the > range 0-31 is reserved by the ITU and ATM Forum for non-user > traffic only. > > We still have time to get these fixed before the RFC comes > out ... comments? > > Thanks, > Andy > > From owner-mpls@UU.NET Thu Mar 2 13:23:02 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21871 for ; Thu, 2 Mar 2000 13:23:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieur22412; Thu, 2 Mar 2000 18:15:33 GMT Received: by mail-control.mail.uu.net id QQieuq12847 for mpls-outgoing; Thu, 2 Mar 2000 18:14:58 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQieuq12842 for ; Thu, 2 Mar 2000 18:14:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieuq28281 for ; Thu, 2 Mar 2000 13:12:26 -0500 (EST) Received: from rout-LRC-01.lrc.deene.ufu.br by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: rout-lrc-01.lrc.deene.ufu.br [200.19.152.13]) id QQieuq28394 for ; Thu, 2 Mar 2000 18:12:24 GMT Received: from lrc.deene.ufu.br (200.19.148.62) by rout-LRC-01.lrc.deene.ufu.br (EMWAC SMTPRS 0.80) with SMTP id ; Thu, 02 Mar 2000 15:12:25 -0300 Message-ID: <38BEB065.F36886AB@lrc.deene.ufu.br> Date: Thu, 02 Mar 2000 15:18:13 -0300 From: Daniela Cunha X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS and DiffServ References: <336ECDAFDF7DD311B9E30090277AEE4101B4041E@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Is there anyone who has already done any simulation modeling about the support of Diffserv in MPLS? Or has any simulation results related to this? Or does anybody know any link where I can find something related to this?Any simulator program? Thanks Daniela From owner-mpls@UU.NET Thu Mar 2 13:38:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22378 for ; Thu, 2 Mar 2000 13:38:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieus16152; Thu, 2 Mar 2000 18:35:00 GMT Received: by mail-control.mail.uu.net id QQieus14081 for mpls-outgoing; Thu, 2 Mar 2000 18:34:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQieus14076 for ; Thu, 2 Mar 2000 18:34:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieus01438 for ; Thu, 2 Mar 2000 13:34:05 -0500 (EST) Received: from rout-LRC-01.lrc.deene.ufu.br by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: rout-lrc-01.lrc.deene.ufu.br [200.19.152.13]) id QQieus15500 for ; Thu, 2 Mar 2000 18:34:03 GMT Received: from lrc.deene.ufu.br (200.19.148.62) by rout-LRC-01.lrc.deene.ufu.br (EMWAC SMTPRS 0.80) with SMTP id ; Thu, 02 Mar 2000 15:34:22 -0300 Message-ID: <38BEB58A.74ADFD43@lrc.deene.ufu.br> Date: Thu, 02 Mar 2000 15:40:10 -0300 From: Daniela Cunha X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS and DiffServ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Is there anyone who has already done any simulation modeling about the support of Diffserv in MPLS? Or has any simulation results related to this? Or does anybody know any link where I can find something related to this?Any simulator program? Thanks Daniela From owner-mpls@UU.NET Thu Mar 2 17:44:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00300 for ; Thu, 2 Mar 2000 17:44:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQievi10182; Thu, 2 Mar 2000 22:42:12 GMT Received: by mail-control.mail.uu.net id QQievi04532 for mpls-outgoing; Thu, 2 Mar 2000 22:41:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQievi04526 for ; Thu, 2 Mar 2000 22:41:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQievi05396 for ; Thu, 2 Mar 2000 17:41:44 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQievi09680 for ; Thu, 2 Mar 2000 22:41:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA28977 for mpls@uu.net; Thu, 2 Mar 2000 17:41:42 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQievi04465 for ; Thu, 2 Mar 2000 22:41:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQievi01278 for ; Thu, 2 Mar 2000 17:41:09 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQievi22446 for ; Thu, 2 Mar 2000 22:41:09 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id OAA14713; Thu, 2 Mar 2000 14:41:04 -0800 (PST) Message-Id: <4.2.2.20000303093326.00a8c9d0@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 03 Mar 2000 09:40:49 +1100 To: "Andrew G. Malis" From: Jeremy Lawrence Subject: Re: Inconsistancy in draft-ietf-mpls-atm-02.txt? Cc: mpls@UU.NET, amalis@lucent.com, parkermr@boat.bt.com In-Reply-To: <4.2.2.20000301094927.025ce300@alpo.casc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Andy, Thanks for raising this, and thanks to whoever asked the question. Comments inline... At 10:02 03/01/2000 -0500, Andrew G. Malis wrote: >I'm at the ITU Study Group 13 meeting in Kyoto, and I was asked a question I don't really have a good answer for, so I'm going to the list. > >In draft-ietf-mpls-atm-02.txt, section 7.1, regarding direct connections between LSRs, says: > > The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI > 32. Other values can be configured, as long as both parties are > aware of the configured value. > >However, section 7.2, regarding the use of VPs between LSRs, says: > > In this case, the default VCI value of the non-MPLS connection > between the LSRs is 32. The VPI is set to whatever is required to > make use of the Virtual Path. > >Section 7.2 is missing the sentence "Other VCI values can be configured, as long as both parties are aware of the configured value.". Is there any good reason why this was omitted? No. >If not, it really should be in there, since an ATM LSR/switch may want to use VCI 32 on the VP for other uses, especially if the VP is shared in "ships in the night" mode. Agreed. >On another note, I believe I have found a typo that also really needs to be fixed. In section 7, the text says: > > It SHOULD be possible to configure an LC-ATM interface with > additional VPI/VCIs that are used to carry control information or > non-labelled packets. In that case, the VCI values MUST be in the > 0-32 range. > >I think that the final line should say "MUST NOT", not "MUST", since the range 0-31 is reserved by the ITU and ATM Forum for non-user traffic only. Agreed. >We still have time to get these fixed before the RFC comes out ... comments? They're fairly minor, so it might be possible to slip these in the final edits, or otherwise is a slightly changed I-D. I'll ask the Area Directors, as the draft status is listed as "AD Review" at the moment. Regards, Jeremy Lawrence From owner-mpls@UU.NET Fri Mar 3 03:27:20 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21123 for ; Fri, 3 Mar 2000 03:27:19 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiewv10021; Fri, 3 Mar 2000 08:25:47 GMT Received: by mail-control.mail.uu.net id QQiewv02787 for mpls-outgoing; Fri, 3 Mar 2000 08:25:27 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiewv02779 for ; Fri, 3 Mar 2000 08:25:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiewv16073 for ; Fri, 3 Mar 2000 03:24:58 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiewv19852 for ; Fri, 3 Mar 2000 08:24:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA07294 for mpls@uu.net; Fri, 3 Mar 2000 03:24:57 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiewv02738 for ; Fri, 3 Mar 2000 08:24:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiewv12070 for ; Fri, 3 Mar 2000 03:24:29 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQiewv09286 for ; Fri, 3 Mar 2000 08:24:28 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id AAA17842 for ; Fri, 3 Mar 2000 00:24:25 -0800 (PST) Message-Id: <4.2.2.20000303190053.00aa5bc0@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 03 Mar 2000 19:23:48 +1100 To: mpls@UU.NET From: Jeremy Lawrence Subject: Re: Inconsistancy in draft-ietf-mpls-atm-02.txt? In-Reply-To: <4.2.2.20000301094927.025ce300@alpo.casc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Andy has proposed two changes to draft-ietf-mpls-atm-02.txt, and there appears to be agreement with these proposed changes. Does anyone on the list object to these changes being made without a working group last call? A last call would consider these two proposed changes only, as draft-ietf-mpls-atm-02.txt has already passed working group last call. Specifically, the two changes are: - In section 7.2, after the sentences "In this case, the default VCI value of the non-MPLS connection between the LSRs is 32. The VPI is set to whatever is required to make use of the Virtual Path" insert the sentence "Other VCI values can be configured, as long as both parties are aware of the configured value." - In section 7, in the sentences "It SHOULD be possible to configure an LC-ATM interface with additional VPI/VCIs that are used to carry control information or non-labelled packets. In that case, the VCI values MUST be in the 0-32 range." change the "MUST" to "MUST NOT". Jeremy Lawrence At 10:02 03/01/2000 -0500, Andrew G. Malis wrote: >I'm at the ITU Study Group 13 meeting in Kyoto, and I was asked a question I don't really have a good answer for, so I'm going to the list. > >In draft-ietf-mpls-atm-02.txt, section 7.1, regarding direct connections between LSRs, says: > > The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI > 32. Other values can be configured, as long as both parties are > aware of the configured value. > >However, section 7.2, regarding the use of VPs between LSRs, says: > > In this case, the default VCI value of the non-MPLS connection > between the LSRs is 32. The VPI is set to whatever is required to > make use of the Virtual Path. > >Section 7.2 is missing the sentence "Other VCI values can be configured, as long as both parties are aware of the configured value.". Is there any good reason why this was omitted? If not, it really should be in there, since an ATM LSR/switch may want to use VCI 32 on the VP for other uses, especially if the VP is shared in "ships in the night" mode. > >On another note, I believe I have found a typo that also really needs to be fixed. In section 7, the text says: > > It SHOULD be possible to configure an LC-ATM interface with > additional VPI/VCIs that are used to carry control information or > non-labelled packets. In that case, the VCI values MUST be in the > 0-32 range. > >I think that the final line should say "MUST NOT", not "MUST", since the range 0-31 is reserved by the ITU and ATM Forum for non-user traffic only. > >We still have time to get these fixed before the RFC comes out ... comments? > >Thanks, >Andy > > From owner-mpls@UU.NET Fri Mar 3 06:56:33 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23172 for ; Fri, 3 Mar 2000 06:56:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiexj07175; Fri, 3 Mar 2000 11:53:44 GMT Received: by mail-control.mail.uu.net id QQiexj10424 for mpls-outgoing; Fri, 3 Mar 2000 11:53:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiexj10419 for ; Fri, 3 Mar 2000 11:53:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiexj28829 for ; Fri, 3 Mar 2000 06:53:02 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiexj09539 for ; Fri, 3 Mar 2000 11:53:01 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA15269 for mpls@uu.net; Fri, 3 Mar 2000 06:53:01 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiexj10323 for ; Fri, 3 Mar 2000 11:52:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiexj28809 for ; Fri, 3 Mar 2000 06:52:27 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQiexj09246 for ; Fri, 3 Mar 2000 11:52:27 GMT Received: from kcheung-pc.cisco.com (sj-dial-1-116.cisco.com [171.68.179.117]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with SMTP id DAA07710 for ; Fri, 3 Mar 2000 03:52:24 -0800 (PST) Message-Id: <4.1.20000303195052.02286a10@dogwood.cisco.com> X-Sender: kcheung@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 03 Mar 2000 19:51:38 +0800 To: mpls@UU.NET From: Kenneth Cheung Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Unsubscribe. From owner-mpls@UU.NET Fri Mar 3 07:08:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23579 for ; Fri, 3 Mar 2000 07:08:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiexk15807; Fri, 3 Mar 2000 12:05:46 GMT Received: by mail-control.mail.uu.net id QQiexk13777 for mpls-outgoing; Fri, 3 Mar 2000 12:05:13 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiexk13686 for ; Fri, 3 Mar 2000 12:05:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiexk25143 for ; Fri, 3 Mar 2000 07:05:00 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiexk15244 for ; Fri, 3 Mar 2000 12:04:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA16246 for mpls@uu.net; Fri, 3 Mar 2000 07:04:59 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiexk13543 for ; Fri, 3 Mar 2000 12:04:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiexk29459 for ; Fri, 3 Mar 2000 07:04:46 -0500 (EST) Received: from qhars001.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qhars001.NortelNetworks.com [192.100.101.18]) id QQiexk13856 for ; Fri, 3 Mar 2000 12:04:45 GMT Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars001.nortel.com; Fri, 3 Mar 2000 11:59:00 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Mar 2000 11:59:00 -0000 Message-ID: <0979C0AA41FED111BCFB00204804FC130211C2A6@zhard000.europe.nortel.com> From: "Joe Shone" To: "'mpls@UU.NET'" Subject: HELP Date: Fri, 3 Mar 2000 11:58:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8507.DBE04D9E" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8507.DBE04D9E Content-Type: text/plain HELP ------_=_NextPart_001_01BF8507.DBE04D9E Content-Type: text/html HELP

HELP

------_=_NextPart_001_01BF8507.DBE04D9E-- From owner-mpls@UU.NET Fri Mar 3 07:24:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23939 for ; Fri, 3 Mar 2000 07:24:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiexl23877; Fri, 3 Mar 2000 12:21:30 GMT Received: by mail-control.mail.uu.net id QQiexl20717 for mpls-outgoing; Fri, 3 Mar 2000 12:20:56 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiexl20686 for ; Fri, 3 Mar 2000 12:20:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiexl26178 for ; Fri, 3 Mar 2000 07:20:28 -0500 (EST) Received: from fire.integralaccess.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.160.25.239]) id QQiexl23214 for ; Fri, 3 Mar 2000 12:20:28 GMT Received: from akankkunen [192.168.1.23] by fire.integralaccess.com (SMTPD32-6.00) id AE59E0F0106; Fri, 03 Mar 2000 07:21:45 -0500 From: "Antti Kankkunen" To: Subject: VoMPLS Framework ID Date: Fri, 3 Mar 2000 07:22:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit FYI >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-kankkunen-vompls-fw-00.txt >Date: Thu, 02 Mar 2000 10:32:20 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Voice over MPLS Framework > Author(s) : A. Kankkunen, G. Ash, J. Hopkins, > B. Rosen, D. Stacey, A. Yelundur, L. Berger > Filename : draft-kankkunen-vompls-fw-00.txt > Pages : 51 > Date : 01-Mar-00 > >This document provides a Framework for using MPLS as the >underlying technology for transporting IP based public voice >services. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kankkunen-vompls-fw-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-kankkunen-vompls-fw-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-kankkunen-vompls-fw-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20000301084456.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kankkunen-vompls-fw-00.txt > > Best regards, Antti K. ------------------- Antti Kankkunen Integral Access Inc. 6 Omni Way Chelmsford, MA 01824 Phone: +1 978 256 8833 x 232 Mobile: +1 617 513 2172 Fax: +1 978 256 8077 e-mail: anttik@integralaccess.com From owner-mpls@UU.NET Fri Mar 3 10:53:28 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01298 for ; Fri, 3 Mar 2000 10:53:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiexz29582; Fri, 3 Mar 2000 15:53:12 GMT Received: by mail-control.mail.uu.net id QQiexz01124 for mpls-outgoing; Fri, 3 Mar 2000 15:52:38 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiexz01113 for ; Fri, 3 Mar 2000 15:52:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiexz23934 for ; Fri, 3 Mar 2000 10:52:10 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiexz29257 for ; Fri, 3 Mar 2000 15:52:10 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id KAA06746; Fri, 3 Mar 2000 10:47:32 -0500 Message-ID: <38BFEDAC.300FAAC9@tellium.com> Date: Fri, 03 Mar 2000 10:51:56 -0600 From: Debanjan X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: FYI Content-Type: multipart/alternative; boundary="------------CADB0236757E6B67A3C85634" Sender: owner-mpls@UU.NET Precedence: bulk --------------CADB0236757E6B67A3C85634 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: I-D ACTION:draft-rstb-optical-signaling-framework-00.txt Date: Thu, 02 Mar 2000 10:32:47 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce:;@loki.ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Signaling Framework for Automated Provisioning and Restoration of Paths in Optical Mesh Networks Author(s) : B. Rajagopalan, D. Saha, B. Tang, K. Bala Filename : draft-rstb-optical-signaling-framework-00.txt Pages : Date : 01-Mar-00 This draft describes the issues that must be addressed in developing signaling mechanisms for automated establishment and restoration of paths in optical mesh networks. This draft is the first attempt at developing a framework for RSVP or CR-LDP-based signaling for interconnected optical networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rstb-optical-signaling-framework-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rstb-optical-signaling-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rstb-optical-signaling-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------CADB0236757E6B67A3C85634 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Subject:
       I-D ACTION:draft-rstb-optical-signaling-framework-00.txt
   Date:
       Thu, 02 Mar 2000 10:32:47 -0500
  From:
       Internet-Drafts@ietf.org
    To:
       IETF-Announce:;@loki.ietf.org
 
 
 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 

        Title           : Signaling Framework for Automated Provisioning and
                          Restoration of Paths in Optical Mesh Networks
        Author(s)       : B. Rajagopalan, D. Saha, B. Tang,  K. Bala
        Filename        : draft-rstb-optical-signaling-framework-00.txt
        Pages           :
        Date            : 01-Mar-00
 
This draft describes the issues that must be addressed in developing
signaling mechanisms for automated establishment and restoration of
paths in optical mesh networks. This draft is the first attempt at
developing a framework for RSVP or CR-LDP-based signaling for
interconnected optical networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rstb-optical-signaling-framework-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-rstb-optical-signaling-framework-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-rstb-optical-signaling-framework-00.txt".
 
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.
 
 
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft. --------------CADB0236757E6B67A3C85634-- From owner-mpls@UU.NET Fri Mar 3 10:53:53 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01318 for ; Fri, 3 Mar 2000 10:53:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiexz00223; Fri, 3 Mar 2000 15:53:32 GMT Received: by mail-control.mail.uu.net id QQiexz01157 for mpls-outgoing; Fri, 3 Mar 2000 15:52:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiexz01142 for ; Fri, 3 Mar 2000 15:52:47 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiexz24005 for ; Fri, 3 Mar 2000 10:52:27 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiexz29404 for ; Fri, 3 Mar 2000 15:52:26 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA09324 for mpls@uu.net; Fri, 3 Mar 2000 10:52:25 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiexz00998 for ; Fri, 3 Mar 2000 15:51:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiexz23731 for ; Fri, 3 Mar 2000 10:51:28 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiexz28729 for ; Fri, 3 Mar 2000 15:51:27 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Mar 2000 10:49:44 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F7BC@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Jeremy Lawrence'" , mpls@UU.NET Subject: RE: Inconsistancy in draft-ietf-mpls-atm-02.txt? Date: Fri, 3 Mar 2000 10:49:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Jeremy Lawrence [mailto:jlawrenc@cisco.com] > Sent: Friday, March 03, 2000 3:24 AM > To: mpls@UU.NET > Subject: Re: Inconsistancy in draft-ietf-mpls-atm-02.txt? > > > Andy has proposed two changes to draft-ietf-mpls-atm-02.txt, and > there appears to be agreement with these proposed changes. Does > anyone on the list object to these changes being made without a > working group last call? > > A last call would consider these two proposed changes only, as > draft-ietf-mpls-atm-02.txt has already passed working group last > call. > > Specifically, the two changes are: > > - In section 7.2, after the sentences > "In this case, the default VCI value of the non-MPLS connection > between the LSRs is 32. The VPI is set to whatever is required > to make use of the Virtual Path" > insert the sentence > "Other VCI values can be configured, as long as both parties > are aware of the configured value." This is a nit but, could the above be modified, such as: "Other VCI values, greater than 31, can be configured..." > > - In section 7, in the sentences > "It SHOULD be possible to configure an LC-ATM interface with > additional VPI/VCIs that are used to carry control information or > non-labelled packets. In that case, the VCI values MUST > be in the > 0-32 range." > change the "MUST" to "MUST NOT". I agree with this one. Thanks, Joan > > Jeremy Lawrence > > > At 10:02 03/01/2000 -0500, Andrew G. Malis wrote: > >I'm at the ITU Study Group 13 meeting in Kyoto, and I was > asked a question I don't really have a good answer for, so > I'm going to the list. > > > >In draft-ietf-mpls-atm-02.txt, section 7.1, regarding direct > connections between LSRs, says: > > > > The default VPI/VCI value for the non-MPLS connection is > VPI 0, VCI > > 32. Other values can be configured, as long as both parties are > > aware of the configured value. > > > >However, section 7.2, regarding the use of VPs between LSRs, says: > > > > In this case, the default VCI value of the non-MPLS connection > > between the LSRs is 32. The VPI is set to whatever is > required to > > make use of the Virtual Path. > > > >Section 7.2 is missing the sentence "Other VCI values can be > configured, as long as both parties are aware of the > configured value.". Is there any good reason why this was > omitted? If not, it really should be in there, since an ATM > LSR/switch may want to use VCI 32 on the VP for other uses, > especially if the VP is shared in "ships in the night" mode. > > > >On another note, I believe I have found a typo that also > really needs to be fixed. In section 7, the text says: > > > > It SHOULD be possible to configure an LC-ATM interface with > > additional VPI/VCIs that are used to carry control information or > > non-labelled packets. In that case, the VCI values MUST > be in the > > 0-32 range. > > > >I think that the final line should say "MUST NOT", not > "MUST", since the range 0-31 is reserved by the ITU and ATM > Forum for non-user traffic only. > > > >We still have time to get these fixed before the RFC comes > out ... comments? > > > >Thanks, > >Andy > > > > > > From owner-mpls@UU.NET Fri Mar 3 15:24:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08367 for ; Fri, 3 Mar 2000 15:24:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieyr20445; Fri, 3 Mar 2000 20:23:35 GMT Received: by mail-control.mail.uu.net id QQieyr01408 for mpls-outgoing; Fri, 3 Mar 2000 20:23:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQieyr01390 for ; Fri, 3 Mar 2000 20:22:48 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieyr28983 for ; Fri, 3 Mar 2000 15:22:31 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQieyr27938 for ; Fri, 3 Mar 2000 20:22:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA19468 for mpls@uu.net; Fri, 3 Mar 2000 15:22:30 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQieyr01192 for ; Fri, 3 Mar 2000 20:21:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieyr02668 for ; Fri, 3 Mar 2000 15:21:43 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQieyr27394 for ; Fri, 3 Mar 2000 20:21:43 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA08963; Fri, 3 Mar 2000 12:21:41 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Mar 2000 12:21:42 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40428@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" , MPLS@UU.NET Subject: RE: link bundling in MPLS TE Date: Fri, 3 Mar 2000 12:19:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, 1) I can't figure out how advertising bundle UB(p), can help a node compute multiple LSPs without waiting for the IGP update of bundle MLB(p). The reason is that there is no relationship between these two values except that: bundle MLB(p)<= bundle UB(p) But this bound is so loose that it is of no practical use. Am I missing something here? 2) There seems to be some problem with your LSP set up logic. In your example, let's add another LSP of priority 0 and b/w 100M to the top link. This LSP will be accepted because for priority 0 in the top link you have: top link --------------- max-LSP Unres prio 0 100 100 Therefore we now have 2 LSPs of priority 0, each 100M passing through the top link. Now if instead of these 2 LSPs you had tried to setup a single LSP of priority 0 and b/w 200M for the top link it would have failed, because max-LSP= 100M. Right? Regards, Shahram >-----Original Message----- >From: Kireeti Kompella [mailto:kireeti@juniper.net] >Sent: Sunday, February 27, 2000 3:58 PM >To: MPLS@UU.NET; rahul@fore.com >Cc: kireeti@juniper.net; yakov@cisco.com >Subject: Re: link bundling in MPLS TE > > >Hi Rahul, > >Thanks very much for the comments, to you and others. Yes, there are >several things that should be clarified. Let me run the following by >you, and once we get feedback, we'll make the changes in the draft. > >Advertised bandwidth quantities: >1) Max LSP bandwidth (per priority p) [MLB(p)] >2) Reservable link bandwidth [RLB] >3) Unreserved bandwidth (per priority p) [UB(p)] >4) Maximum link bandwidth (to be deprecated? not discussed below) > >For a simple (unbundled) link, the initial values are: >1) MLB(p): either assigned by the administrator, or set to the > link capacity. Call the initial value IMLB(p). >2) RLB: assigned by administrator; defaults to link capacity. >3) UB(p): is set to RLB. > >As LSPs come and go, the values change as follows: >1) MLB(p): min of {IMLB(p), UB(p)} >2) RLB: doesn't change. >3) UB(p) decreases by B if an LSP of holding priority <= p and b/w B > is set up throught this link; increases by B if an LSP of holding > priority <= p is torn down. (Note: smaller p means higher >priority.) > >Extending this to bundled links: >1) MLB(p) of a bundled link is max {MLB(p) of component links}. >2) RLB of a bundled link is sum {RLB of component links}. >3) UB(p) of a bundled link is sum {UB(p) of component links}. > >As mentioned in the draft, RSVP must keep state per component link; >but RSVP only needs to tell the IGP the 'bundled' values. > >As far as CSPF/RSVP is concerned, a link (bundled or otherwise) has >enough b/w for an LSP with setup priority p and b/w B iff MLB(p) >= B. > >Advertising unreserved b/w allows an LSR to compute multiple successive >LSPs without receiving IGP updates by locally tracking the UB for each >link. Of course, there are several potential holes in such a scheme; >bundled links add the further problem that there may in fact be >sufficient unreserved bandwidth but max LSP b/w is too small. > >Unreserved b/w and reservable b/w are also useful for >tie-breaking purposes. > >Comments and suggestions are very welcome. > >Example: consider the three links from A->B as a bundle. Note: only >the 'bundled link' values are advertised; the others are local state >maintained by RSVP. > > --------> > A --------> B > --------> > >Top link is 100Mbps (reservable 200M), middle one is 50M >(reservable 150M) >and bottom is also 50M (reservable 100M). Let's consider just >3 priority >levels. > >Initially: > > bundled link top link middle link bottom link > -------------- ------------- ------------- ------------- >prio max-LSP unres max-LSP unres max-LSP unres max-LSP unres > 0 100M 450M 100M 200M 50M 150M 50M 100M > 1 100M 450M 100M 200M 50M 150M 50M 100M > 2 100M 450M 100M 200M 50M 150M 50M 100M > >An LSP with priority 1 and b/w 50M is set up on the middle link. Now, >the b/w picture is: > > bundled link top link middle link bottom link > -------------- ------------- ------------- ------------- >prio max-LSP unres max-LSP unres max-LSP unres max-LSP unres > 0 100M 450M 100M 200M 50M 150M 50M 100M > 1 100M 400M 100M 200M 50M 100M 50M 100M > 2 100M 400M 100M 200M 50M 100M 50M 100M > >An LSP with priority 2 and b/w 100M is set up on the top link. Now, >the b/w picture is: > > bundled link top link middle link bottom link > -------------- ------------- ------------- ------------- >prio max-LSP unres max-LSP unres max-LSP unres max-LSP unres > 0 100M 450M 100M 200M 50M 150M 50M 100M > 1 100M 400M 100M 200M 50M 100M 50M 100M > 2 100M 300M 100M 100M 50M 100M 50M 100M > >An LSP with priority 0 and b/w 100M is set up on the top link. Now, >the b/w picture is: > > bundled link top link middle link bottom link > -------------- ------------- ------------- ------------- >prio max-LSP unres max-LSP unres max-LSP unres max-LSP unres > 0 100M 350M 100M 100M 50M 150M 50M 100M > 1 100M 300M 100M 100M 50M 100M 50M 100M > 2 50M 200M 0M 0M 50M 100M 50M 100M > >An LSP with priority 1 and b/w 80M is set up on the top link. To >do this, the 100M LSP at priority 2 has to be preempted. Now, the >b/w picture is: > > bundled link top link middle link bottom link > -------------- ------------- ------------- ------------- >prio max-LSP unres max-LSP unres max-LSP unres max-LSP unres > 0 100M 350M 100M 100M 50M 150M 50M 100M > 1 50M 220M 20M 20M 50M 100M 50M 100M > 2 50M 220M 20M 20M 50M 100M 50M 100M > >etc. > >Kireeti. > From owner-mpls@UU.NET Fri Mar 3 15:49:47 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08752 for ; Fri, 3 Mar 2000 15:49:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieyt13848; Fri, 3 Mar 2000 20:47:56 GMT Received: by mail-control.mail.uu.net id QQieyt03589 for mpls-outgoing; Fri, 3 Mar 2000 20:47:31 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQieyt03578 for ; Fri, 3 Mar 2000 20:47:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQieyt02153 for ; Fri, 3 Mar 2000 15:47:08 -0500 (EST) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQieyt04835 for ; Fri, 3 Mar 2000 20:47:07 GMT Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id MAA04882; Fri, 3 Mar 2000 12:46:36 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id MAA02588; Fri, 3 Mar 2000 12:46:36 -0800 (PST) Date: Fri, 3 Mar 2000 12:46:36 -0800 (PST) From: Kireeti Kompella Message-Id: <200003032046.MAA02588@kummer.juniper.net> To: kireeti@juniper.net, MPLS@UU.NET, Shahram_Davari@pmc-sierra.com Subject: RE: link bundling in MPLS TE Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, > 1) I can't figure out how advertising bundle UB(p), can help a node compute > multiple LSPs without waiting for the IGP update of bundle MLB(p). The > reason is that there is no relationship between these two values except > that: > > bundle MLB(p)<= bundle UB(p) > > But this bound is so loose that it is of no practical use. Am I missing > something here? There are no guarantees that an LSP setup will work: a node sees that 100M is available on some link, and sets up an LSP through it, only to find that another node got there first. Or, thanks to IGP holding down updates, the link-state database could be stale. That said, one does one's best with the info available. If MLB and UB are both advertised (say 100M and 1000M respectively), a node can say "maybe setting up 10 100M LSPs will work". If the actual link bundle consists of 10 100M links, that works. If the bundle was 5 100M links and 10 50M links, only 5 of the LSPs work. etc. If only MLB was advertised, a node has no info as to whether a link with MLB 100M can accommodate 1 or 100 100M LSPs. Of course, the whole point of bundling is reducing information -- in the process you lose some useful info, but you gain scalability. If the above bundle of 5 100M links and 10 50M links were individually advertised (not bundled), you would have 'perfect' info, for some notion of perfect. However, your IGP state would be 15 times as large. > 2) There seems to be some problem with your LSP set up logic. In your > example, let's add another LSP of priority 0 and b/w 100M to the top link. > This LSP will be accepted because for priority 0 in the top link you have: > > top link > --------------- > max-LSP Unres > prio > 0 100 100 > > Therefore we now have 2 LSPs of priority 0, each 100M passing through the > top link. Now if instead of these 2 LSPs you had tried to setup a single LSP > of priority 0 and b/w 200M for the top link it would have failed, because > max-LSP= 100M. Right? Right. Where is the problem? Kireeti. From owner-mpls@UU.NET Fri Mar 3 15:59:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09220 for ; Fri, 3 Mar 2000 15:59:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieyt20411; Fri, 3 Mar 2000 20:58:23 GMT Received: by mail-control.mail.uu.net id QQieyt04412 for mpls-outgoing; Fri, 3 Mar 2000 20:58:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQieyt04407 for ; Fri, 3 Mar 2000 20:58:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieyt07190 for ; Fri, 3 Mar 2000 15:57:39 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQieyt19829 for ; Fri, 3 Mar 2000 20:57:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA24606 for mpls@uu.net; Fri, 3 Mar 2000 15:57:37 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQieyt04392 for ; Fri, 3 Mar 2000 20:57:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieyt07152 for ; Fri, 3 Mar 2000 15:57:12 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQieyt19542 for ; Fri, 3 Mar 2000 20:57:11 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA10282; Fri, 3 Mar 2000 12:57:08 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Mar 2000 12:57:09 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40429@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" , MPLS@UU.NET, Shahram Davari Subject: RE: link bundling in MPLS TE Date: Fri, 3 Mar 2000 12:54:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, >-----Original Message----- >From: Kireeti Kompella [mailto:kireeti@juniper.net] >Sent: Friday, March 03, 2000 3:47 PM >To: kireeti@juniper.net; MPLS@UU.NET; Shahram_Davari@pmc-sierra.com >Subject: RE: link bundling in MPLS TE > > >Hi Shahram, > >> 1) I can't figure out how advertising bundle UB(p), can help >a node compute >> multiple LSPs without waiting for the IGP update of bundle >MLB(p). The >> reason is that there is no relationship between these two >values except >> that: >> >> bundle MLB(p)<= bundle UB(p) >> >> But this bound is so loose that it is of no practical use. >Am I missing >> something here? > >There are no guarantees that an LSP setup will work: a node sees that >100M is available on some link, and sets up an LSP through it, only to >find that another node got there first. Or, thanks to IGP holding down >updates, the link-state database could be stale. > >That said, one does one's best with the info available. If MLB and UB >are both advertised (say 100M and 1000M respectively), a node can say >"maybe setting up 10 100M LSPs will work". If the actual link bundle >consists of 10 100M links, that works. If the bundle was 5 100M links >and 10 50M links, only 5 of the LSPs work. etc. > >If only MLB was advertised, a node has no info as to whether a >link with >MLB 100M can accommodate 1 or 100 100M LSPs. > >Of course, the whole point of bundling is reducing information -- in >the process you lose some useful info, but you gain scalability. If >the above bundle of 5 100M links and 10 50M links were individually >advertised (not bundled), you would have 'perfect' info, for >some notion >of perfect. However, your IGP state would be 15 times as large. > Fine. Thanks for the explanation. >> 2) There seems to be some problem with your LSP set up logic. In your >> example, let's add another LSP of priority 0 and b/w 100M to >the top link. >> This LSP will be accepted because for priority 0 in the top >link you have: >> >> top link >> --------------- >> max-LSP Unres >> prio >> 0 100 100 >> >> Therefore we now have 2 LSPs of priority 0, each 100M >passing through the >> top link. Now if instead of these 2 LSPs you had tried to >setup a single LSP >> of priority 0 and b/w 200M for the top link it would have >failed, because >> max-LSP= 100M. Right? > >Right. Where is the problem? The problem is that in both cases you want to route 200M traffic on a single component link. If you do it as 2*100M you will succeed, but if you do it as a single 200M you won't. But in fact you are routing the same traffic through that component. This is rather odd? isn't it? Regards, -Shahram > >Kireeti. > From owner-mpls@UU.NET Fri Mar 3 16:06:17 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09354 for ; Fri, 3 Mar 2000 16:06:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieyu16356; Fri, 3 Mar 2000 21:05:44 GMT Received: by mail-control.mail.uu.net id QQieyu10813 for mpls-outgoing; Fri, 3 Mar 2000 21:05:28 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQieyu10452 for ; Fri, 3 Mar 2000 21:05:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQieyu04582 for ; Fri, 3 Mar 2000 16:04:55 -0500 (EST) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQieyu15708 for ; Fri, 3 Mar 2000 21:04:54 GMT Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id NAA05784; Fri, 3 Mar 2000 13:04:23 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id NAA02663; Fri, 3 Mar 2000 13:04:23 -0800 (PST) Date: Fri, 3 Mar 2000 13:04:23 -0800 (PST) From: Kireeti Kompella Message-Id: <200003032104.NAA02663@kummer.juniper.net> To: kireeti@juniper.net, MPLS@UU.NET, Shahram_Davari@pmc-sierra.com Subject: RE: link bundling in MPLS TE Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, > The problem is that in both cases you want to route 200M traffic on a single > component link. If you do it as 2*100M you will succeed, but if you do it as > a single 200M you won't. I see your problem: the notion of oversubscription. Oversubscription is taking advantage of stat mux. Two 100M LSPs whose instantaneous traffic never adds up to more than 100M can share a 100M link. A 200M LSP just doesn't fit in a 100M link. Kireeti. From owner-mpls@UU.NET Fri Mar 3 16:33:36 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09980 for ; Fri, 3 Mar 2000 16:33:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQieyw12400; Fri, 3 Mar 2000 21:32:21 GMT Received: by mail-control.mail.uu.net id QQieyw15129 for mpls-outgoing; Fri, 3 Mar 2000 21:31:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQieyw15122 for ; Fri, 3 Mar 2000 21:31:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQieyw08508 for ; Fri, 3 Mar 2000 16:31:40 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQieyw02098 for ; Fri, 3 Mar 2000 21:31:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA29818 for mpls@uu.net; Fri, 3 Mar 2000 16:31:39 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQieyw15042 for ; Fri, 3 Mar 2000 21:31:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQieyw11706 for ; Fri, 3 Mar 2000 16:30:19 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQieyw01214 for ; Fri, 3 Mar 2000 21:30:19 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA11434; Fri, 3 Mar 2000 13:30:17 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Mar 2000 13:30:18 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4042A@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella'" , MPLS@UU.NET, Shahram Davari Subject: RE: link bundling in MPLS TE Date: Fri, 3 Mar 2000 13:27:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Kiteeti, >-----Original Message----- >From: Kireeti Kompella [mailto:kireeti@juniper.net] >Sent: Friday, March 03, 2000 4:04 PM >To: kireeti@juniper.net; MPLS@UU.NET; Shahram_Davari@pmc-sierra.com >Subject: RE: link bundling in MPLS TE > > >Hi Shahram, > >> The problem is that in both cases you want to route 200M >traffic on a single >> component link. If you do it as 2*100M you will succeed, but >if you do it as >> a single 200M you won't. > >I see your problem: the notion of oversubscription. > >Oversubscription is taking advantage of stat mux. Two 100M LSPs >whose instantaneous traffic never adds up to more than 100M can >share a 100M link. A 200M LSP just doesn't fit in a 100M link. > >Kireeti. Could you also please clarify that when you say a 100M LSP, are you talking about the Peak rate (PIR) or Committed rate (CIR)? If in the above example we are talking about CIR then it is impossible to pass 2*100M LSP or a single 200M LSP through a 100M link. While if we are talking about PIR then you are right we can't pass a 200M LSP through a 100M link, but we are most likely unable to pass the 2*100M LSPs either, because there is no way to guarantee that the instantaneous traffic of the two LSPs never adds up to more than 100M. Is there any? Regards, -Shahram > From owner-mpls@UU.NET Fri Mar 3 17:48:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11403 for ; Fri, 3 Mar 2000 17:48:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiezb20203; Fri, 3 Mar 2000 22:46:46 GMT Received: by mail-control.mail.uu.net id QQiezb28266 for mpls-outgoing; Fri, 3 Mar 2000 22:46:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiezb28189 for ; Fri, 3 Mar 2000 22:46:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiezb19236 for ; Fri, 3 Mar 2000 17:45:55 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiezb01418 for ; Fri, 3 Mar 2000 22:45:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA09129 for mpls@uu.net; Fri, 3 Mar 2000 17:45:38 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQieza27954 for ; Fri, 3 Mar 2000 22:44:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQieza21092 for ; Fri, 3 Mar 2000 17:44:04 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQieza28247 for ; Fri, 3 Mar 2000 22:44:04 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA28722; Fri, 3 Mar 2000 17:43:43 -0500 (EST) Message-Id: <4.2.2.20000303144557.00c994c0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 03 Mar 2000 17:43:40 -0500 To: Adrian Farrel From: "Thomas D. Nadeau" Subject: RE: draft-ietf-mpls-lsr-mib-01.txt Released Cc: Arun Viswanathan , cheenu@tachion.com, MPLS mailing list In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E14027A@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_32674790==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_32674790==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Adrian, We were able to follow up on the remainder of your questions. The responses are contained inline. --Tom >9. Scope of Statistics > > >>It is good to add a sysUpTime stamp to show the scope of the > >>counters returned. > > >We refer you to the ifMIB and MIB II for this. There is guidance in > >the MIB which refers you to this, I believe. > >OK, I can't find the guidance or reference, but that doesn't matter. > >RFC2233 seems to support what I'm saying. It uses a "discontinuity time" to >stamp the counters and show their relevance. I quote... Since MPLS interfaces are derived interfaces from RFC2233, the 2233 Discontinuity timer should apply here as well, so there is no need to add these to the Perf tables. >I suggest you add similar discontinuity times alongside each of your >perfTables. > >10. Something Else to Count > > >>In addition to the counters you already have, I think you need to > >>count the number of labeled packets that have been received on an > >>interface/in-segment and were discarded because there was no > >>cross-connect. Or is this covered by one of your existing counts? > > >mplsInterfaceFailedLabelLookup > >Well, the text for this count says... > > "This value indicates the number of labeled packets > that have been received on this interface and were > discarded because there were no matching entries > found for them in mplsInSegmentTable." > >I'm asking where we count the case that the inSegment _does_ exist, but that >there is no cross-connect. Why do you want to count this case? Please explain the situation where you would want to count this. >20. mplsXCAdminStatus > > >>I think this would benefit from a DEFVAL. > > >The other adminStatus values do not have DEFVALS so > >we would prefer to leave this one alone. > >See mplsInterfaceAdminStatus which has... > DEFVAL { down } We left the DEFVAL out on the other adminStatus values because each has a rowStatus associated with it. With respect to the pending comments from Arun, here they are. 1) The modifications to the XcEntry which you suggested have been made as follows: Special labels: Entries indexed by reserved MPLS label values 0 through 15 imply terminating LSPs and MUST have mplsOutSegmentIndex = 0. Note that situations where LSPs are terminated with incomming label equal to 0, should have mplsInSegmentIndex = 0 as well, but can distinguished from originating LSPs because the mplsOutSegmentIndex = 0. The mplsOutSegmentIndex MUST only be set to 0 in cases of terminating LSPs. An entry can be created by a network administrator or by an SNMP agent as instructed by CR-LDP or RSVP. 2) The comment you made with regard to the BitRate textual convention has been made to comply with that defined in RFC2233, and will appear in the new draft as: BitRate ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An estimate of bandwidth in units of 1,000 bits per second. If this object reports a value of 'n' then the rate of the object is somewhere in the range of 'n-500' to 'n+499'. For objects which do not vary in bitrate, or for those where no accurate estimation can be made, this object should contain the nominal bitrate." SYNTAX INTEGER (0..'7FFFFFFF'h) --Tom --=====================_32674790==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi Adrian,

        We were able to follow up on the remainder of your questions.
The responses are contained inline.

        --Tom

9. Scope of Statistics

>>It is good to add a sysUpTime stamp to show the scope of the
>>counters returned.
       
>We refer you to the ifMIB and MIB II for this. There is guidance in
>the MIB which refers you to this, I believe.

OK, I can't find the guidance or reference, but that doesn't matter.

RFC2233 seems to support what I'm saying. It uses a "discontinuity time" to
stamp the counters and show their relevance.  I quote...

        Since MPLS interfaces are derived interfaces from RFC2233,
the 2233 Discontinuity timer should apply here as well, so there is no
need to add these to the Perf tables.

I suggest you add similar discontinuity times alongside each of your
perfTables.

10. Something Else to Count

>>In addition to the counters you already have, I think you need to
>>count the number of labeled packets that have been received on an
>>interface/in-segment and were discarded because there was no
>>cross-connect.  Or is this covered by one of your existing counts?

>mplsInterfaceFailedLabelLookup     

Well, the text for this count says...

       "This value indicates the number of labeled packets
        that have been received on this interface and were
        discarded because there were no matching entries
        found for them in mplsInSegmentTable."

I'm asking where we count the case that the inSegment _does_ exist, but that
there is no cross-connect.

        Why do you want to count this case? Please explain
the situation where you would want to count this.

20. mplsXCAdminStatus

>>I think this would benefit from a DEFVAL.

>The other adminStatus values do not have DEFVALS so
>we would prefer to leave this one alone.

See mplsInterfaceAdminStatus which has...
   DEFVAL        { down }

        We left the DEFVAL out on the other adminStatus values
because each has a rowStatus associated with it.

        With respect to the pending comments from Arun, here they
are.

        1) The modifications to the XcEntry which you suggested have
been made as follows:
Special labels:
Entries indexed by reserved MPLS label values 0 through 15 imply terminating LSPs and MUST have mplsOutSegmentIndex = 0. Note that situations where LSPs are terminated with incomming label equal to 0, should have mplsInSegmentIndex = 0 as well, but can distinguished from originating LSPs because the mplsOutSegmentIndex = 0. The mplsOutSegmentIndex MUST only be set to 0 in cases of terminating LSPs.

An entry can be created by a network administrator or by an SNMP agent as instructed by CR-LDP or RSVP.


        2) The comment you made with regard to the BitRate textual
convention has been made to comply with that defined in RFC2233,
and will appear in the new draft as:

BitRate ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS      current
DESCRIPTION
"An estimate of bandwidth in units of 1,000 bits per second.  If this object reports a value of 'n' then the rate of the object is somewhere in the range of 'n-500' to 'n+499'. For objects which do not vary in bitrate, or for those where no accurate estimation can be made, this object should contain the nominal bitrate."
SYNTAX      INTEGER (0..'7FFFFFFF'h)


        --Tom
--=====================_32674790==_.ALT-- From owner-mpls@UU.NET Sat Mar 4 20:59:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09801 for ; Sat, 4 Mar 2000 20:59:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifdf04520; Sun, 5 Mar 2000 01:58:53 GMT Received: by mail-control.mail.uu.net id QQifdf15851 for mpls-outgoing; Sun, 5 Mar 2000 01:58:38 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifdf15846 for ; Sun, 5 Mar 2000 01:58:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifdf24636 for ; Sat, 4 Mar 2000 20:58:30 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQifdf28752 for ; Sun, 5 Mar 2000 01:58:30 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id UAA16039; Sat, 4 Mar 2000 20:58:05 -0500 Date: Sat, 4 Mar 2000 20:58:05 -0500 From: "J. Noel Chiappa" Message-Id: <200003050158.UAA16039@ginger.lcs.mit.edu> To: tony1@home.net, wrath@cs.umbc.edu Subject: Re: tunnels within tunnels and MPLS/RSVP ERO Cc: curtis@avici.com, jnc@ginger.lcs.mit.edu, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk > From: Vijay Gill > On Sat, 26 Feb 2000, Tony Li wrote: >> However, I'm concerned that LSPs will not be evenly distributed. In >> particular, the backbone routers would seem to be a concentration >> point. ... this implies that the backbone router ends up knowing about >> each and every LSP that crosses the backbone/region boundary for that >> particular region. ... that's on the order of 50,000-90,000 LSPs that >> the backbone router needs to support. I think it was Vadim who first pointed this problem out to me, several years ago. I've been pondering it ever since; my thoughts below. > An approach might be to break the regions down into a n level hierarchy > ... and construct n hierarchical domains. One set of routers that > aggregate circuits that span regions and act as purely label switching > boxes, and another set of routers that aggregate regional LSPs and have > a dual mesh with some other set of routers in another region that > perform the same function. >> I'm suggesting that individual LSPs not transit the backbone router. >> Instead, they terminate at the backbone and that the only LSPs in the >> backbone are region-to-region. This would imply that the backbone >> router would make a layer 3 forwarding decision for all transit packets. There are really several different possible solutions to doing "large-scale" label-based packet switching, none of them perfect. Which, of course, means that in real life we'll probably use all of them, depending on which fits the exact circumstances best. The first is the one you mention - terminate the LSP (so that no LSP's cross a "label-switching-region" boundary), and re-examine the internetwork level address. This way, there's something of a match between the graph of the routing table entries to X (which form a tree), and the LSP entries; because as you get close to X, routes to X disappear anyway, to be replaced by routes to X.1, X.2, etc - at that kind of boundary you *have* to terminate an LSP for X. The second is to maintain N^2 LSP's, including in the core - not a pretty sight. The third is to do what has been under discussing for a long time, which is flow aggregation. In other words, local site L1 does have a flow F1 set up to local site L2, via large core ISP's I1 and I2, but going across the core, that flow is aggregated into flow A1 (along with some other flows, F2...Fn, which happen to be congruent with A1 inside I1 and I2), and the core only knows about A1. As A1 exits the core, it is broken up into its consituent flows, F1...Fn. The mechanism to do this is simple; when F1 gets to the last-hop router before it enters A1, the A1 label is pushed onto the front of the packet, hiding the F1 label; and when the packet exits A1, the A1 label is popped, revealing F1, and the packet continues on. This takes less state, but a little more bandwidth - a common tradeoff when you start thinking about flow-based packet handling. This is probably an OK tradeoff as long as you're not on some hyper-expensive link. There, one of the other alternatives is probably the way to go. This is a very brief gloss on a much more complex situation with aggregation, for a number of reasons. For one, the chances of F1, where F1 is a flow from one site to another, being congruent with other flows along its entire length is not so great, so you wind up doing multiple levels of aggregation. This in turn leads you into what I call assymetric aggregation [don't ask :-], which you can fix with still more labels. So it really comes down to whether you want to spend state (for N^2 flows), or bandwidth (aggregation, with pushed labels), or processing power (to re-parse the internetwork level address). Depending on the particular technological base you're working with, one may look better than others. E.g. in an optical substrate where you have lots of bandwidth, and complex processing is hard, aggregation may look good. If you're on a hyper-expensive undersea link, you may prefer to pay for the processing power. Etc, etc... Noel From owner-mpls@UU.NET Sat Mar 4 21:10:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09901 for ; Sat, 4 Mar 2000 21:10:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifdg04333; Sun, 5 Mar 2000 02:09:30 GMT Received: by mail-control.mail.uu.net id QQifdg23969 for mpls-outgoing; Sun, 5 Mar 2000 02:08:58 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifdg23962 for ; Sun, 5 Mar 2000 02:08:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifdg25176 for ; Sat, 4 Mar 2000 21:08:44 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQifdg03819 for ; Sun, 5 Mar 2000 02:08:44 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id VAA16060; Sat, 4 Mar 2000 21:08:42 -0500 Date: Sat, 4 Mar 2000 21:08:42 -0500 From: "J. Noel Chiappa" Message-Id: <200003050208.VAA16060@ginger.lcs.mit.edu> To: curtis@avici.com, tony1@home.net Subject: Re: tunnels within tunnels and MPLS/RSVP ERO Cc: jnc@ginger.lcs.mit.edu, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk > From: Tony Li > The point of all of this is that the scalability of the signaling is a > concern ... I can't help wondering if there is a real need to provide > entry-to-exit LSPs and if the architecture could not be greatly > simplified by using concatenated LSPs instead. Oh, duh, I forgot one option (which reading this reminded me of) - which is to use concatenated LSP's - but not via having the router at the end of one LSP make an internet-level forwarding decision. Rather, the packet can contain a source route (in the form of a stack of labels), so that when it exits one LSP, it is immediately guided down another LSP by the next label. (Feel free to do a vector product of this with flow aggregation, but the mental model gets pretty complicated, there's now ay I'm gogin to try and write it down! :-) Anyway, this kind of source routing, with a label stack, is just another different kind of space/bandwidth/etc tradeoff - although in this case the extra space in the header (when the packet starts off) is gone by the time the packet gets to the destination. Noel From owner-mpls@UU.NET Mon Mar 6 01:54:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21229 for ; Mon, 6 Mar 2000 01:54:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifhr09648; Mon, 6 Mar 2000 06:53:34 GMT Received: by mail-control.mail.uu.net id QQifhr07441 for mpls-outgoing; Mon, 6 Mar 2000 06:53:04 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifhr07436 for ; Mon, 6 Mar 2000 06:53:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifhr05331 for ; Mon, 6 Mar 2000 01:52:43 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQifhr07587 for ; Mon, 6 Mar 2000 06:52:26 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id OAA18695 for ; Sat, 4 Mar 2000 14:28:12 -0600 (GMT) Message-ID: <000801bf85b9$240f7520$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Subject: Admission Control and Policing in CR-LDP Date: Sat, 4 Mar 2000 14:36:39 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BF85E7.0D2A9FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF85E7.0D2A9FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi How do I go about doing Admission Control and Policing in CR-LDP ? = At present I am following draft-ietf-mpls-ldp-06 and = draft-ietf-mpls-cr-ldp-03. Between 2 LERs in different MPLS domains it = could be a simple TCP session to exchange labels and forward trafic. But = how does one go about negotiating the traffic parameters ( receiving = request ) when the traffic is coming from non MPLS domain into an MPLS = domain. Can anyone help me out with some references. santosh santosh_g@hotmail.com http://members.tripod.com/~santoshg ------=_NextPart_000_0005_01BF85E7.0D2A9FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
    How do I go about doing Admission Control and = Policing=20 in CR-LDP ? At present I am following draft-ietf-mpls-ldp-06 and=20 draft-ietf-mpls-cr-ldp-03. Between 2 LERs in different MPLS domains it = could be=20 a simple TCP session to exchange labels and forward trafic. But how does = one go=20 about negotiating the traffic parameters ( receiving request ) when the = traffic=20 is coming from non MPLS domain into an MPLS domain.
 
Can anyone help me out with some references.
santosh
 
santosh_g@hotmail.com
http://members.tripod.com/~s= antoshg
------=_NextPart_000_0005_01BF85E7.0D2A9FA0-- From owner-mpls@UU.NET Mon Mar 6 01:58:09 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21452 for ; Mon, 6 Mar 2000 01:58:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifhr16230; Mon, 6 Mar 2000 06:57:37 GMT Received: by mail-control.mail.uu.net id QQifhr07621 for mpls-outgoing; Mon, 6 Mar 2000 06:57:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifhr07616 for ; Mon, 6 Mar 2000 06:57:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifhr26149 for ; Mon, 6 Mar 2000 01:56:49 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifhr14799 for ; Mon, 6 Mar 2000 06:56:47 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA26521 for mpls@uu.net; Mon, 6 Mar 2000 01:56:47 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifhr07599 for ; Mon, 6 Mar 2000 06:56:21 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifhr05441 for ; Mon, 6 Mar 2000 01:56:06 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQifhr13606 for ; Mon, 6 Mar 2000 06:56:05 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id IAA27177; Mon, 6 Mar 2000 08:53:48 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14531.22011.841193.707987@lohi.eng.telia.fi> Date: Mon, 6 Mar 2000 08:53:47 +0200 (EET) To: Theimer Thomas Cc: mpls@UU.NET Subject: RE: soft permanent lsps In-Reply-To: <3B59676F9ADBD211B5360060086E64EE45E7F5@MCHH237E> References: <3B59676F9ADBD211B5360060086E64EE45E7F5@MCHH237E> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Theimer Thomas writes: > don't you need exactly the same functionality when MPLS is used to control > optical lambda routers? In this case the label represents the wavelength on > the outgoing interface. yes. may be curtis could comment on how this can be achieved using his tunneling scheme. > However, you may also need some way to address a > specific port (unless all ports have individual IP addresses, which may not > always be the case) on your (lambda) router. i don't see why interfaces in optical switches could not be identified by ip addresses especially if the control plane is based on ip. > It would be nice to have a > common generic mechanism for signalling and addressing that covers both > applications, perhaps based on your draft. I have not seen any detailled > specs on this from the optical folks. the only thing that would need to be changed in the sementics of the label value and that can be taken care of in the base ldp documents. -- juha From owner-mpls@UU.NET Mon Mar 6 07:00:20 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02667 for ; Mon, 6 Mar 2000 07:00:19 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifil00246; Mon, 6 Mar 2000 11:58:55 GMT Received: by mail-control.mail.uu.net id QQifil00612 for mpls-outgoing; Mon, 6 Mar 2000 11:58:24 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifil00607 for ; Mon, 6 Mar 2000 11:58:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifil12172 for ; Mon, 6 Mar 2000 06:58:10 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifil29703 for ; Mon, 6 Mar 2000 11:58:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA07583 for mpls@uu.net; Mon, 6 Mar 2000 06:58:08 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifil00583 for ; Mon, 6 Mar 2000 11:57:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifil12125 for ; Mon, 6 Mar 2000 06:57:26 -0500 (EST) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQifil29303 for ; Mon, 6 Mar 2000 11:57:25 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02466; Mon, 6 Mar 2000 06:57:24 -0500 (EST) Message-Id: <200003061157.GAA02466@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mannie-mpls-sdh-control-00.txt Date: Mon, 06 Mar 2000 06:57:23 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS for SDH control Author(s) : E. Mannie Filename : draft-mannie-mpls-sdh-control-00.txt Pages : 13 Date : 03-Mar-00 This document is an attempt to specify how MPLS could be used to control the establishment of SDH paths. It identifies the elements that could be switched in SDH, proposes a way to build labels for SDH 'intelligent' switching and discusses several problems. Annexes A and B are intended to specify how to support this specification using CR-LDP and TE-RSVP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mannie-mpls-sdh-control-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mannie-mpls-sdh-control-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mannie-mpls-sdh-control-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000303133700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mannie-mpls-sdh-control-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mannie-mpls-sdh-control-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000303133700.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Mar 6 07:37:51 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03360 for ; Mon, 6 Mar 2000 07:37:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifin21084; Mon, 6 Mar 2000 12:29:36 GMT Received: by mail-control.mail.uu.net id QQifin10638 for mpls-outgoing; Mon, 6 Mar 2000 12:29:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifin10633 for ; Mon, 6 Mar 2000 12:29:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifin25910 for ; Mon, 6 Mar 2000 07:28:44 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifin15949 for ; Mon, 6 Mar 2000 12:28:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA09324 for mpls@uu.net; Mon, 6 Mar 2000 07:28:43 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifin10596 for ; Mon, 6 Mar 2000 12:27:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifin13890 for ; Mon, 6 Mar 2000 07:27:37 -0500 (EST) From: ssimlo@cisco.com Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQifin19917 for ; Mon, 6 Mar 2000 12:27:37 GMT Received: from amsterdam.cisco.com (amsterdam.cisco.com [144.254.74.36]) by ogma.cisco.com (Postfix) with ESMTP id 282AFE6; Mon, 6 Mar 2000 13:27:36 +0100 (MET) Received: from stockley12-dhcp93.cisco.com (leeuw.cisco.com [144.254.74.5]) by amsterdam.cisco.com (8.8.8+Sun/8.8.8) with SMTP id NAA19479; Mon, 6 Mar 2000 13:27:35 +0100 (MET) Message-Id: <200003061227.NAA19479@amsterdam.cisco.com> To: ssimlo@hotmail.com Cc: mpls@UU.NET Subject: Fwd: I-D ACTION:draft-mannie-mpls-sdh-control-00.txt Date: Mon, 6 Mar 100 12:27:35 +0000 X-Mailer: Endymion MailMan v2.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MailMan_Boundary" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --MailMan_Boundary Content-Type: text/plain Forwarded Message: > To: IETF-Announce:; > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-mannie-mpls-sdh-control-00.txt > Date: Mon, 06 Mar 2000 06:57:23 -0500 > ----- > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : MPLS for SDH control > Author(s) : E. Mannie > Filename : draft-mannie-mpls-sdh-control-00.txt > Pages : 13 > Date : 03-Mar-00 > > This document is an attempt to specify how MPLS could be used to control the establishment of SDH paths. It identifies the elements that could be switched in SDH, proposes a way to build labels for SDH 'intelligent' switching and discusses several problems. Annexes A and B are intended to specify how to support this specification using CR-LDP and TE-RSVP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mannie-mpls-sdh-control-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-mannie-mpls-sdh-control-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-mannie-mpls-sdh-control-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <20000303133700.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-mannie-mpls-sdh-control-00.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-mannie-mpls-sdh-control-00.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <20000303133700.I-D@ietf.org> > > --OtherAccess-- > > --NextPart-- > > > --MailMan_Boundary-- From owner-mpls@UU.NET Mon Mar 6 10:24:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09392 for ; Mon, 6 Mar 2000 10:23:58 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifiz10879; Mon, 6 Mar 2000 15:21:39 GMT Received: by mail-control.mail.uu.net id QQifiz12597 for mpls-outgoing; Mon, 6 Mar 2000 15:21:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifiz12585 for ; Mon, 6 Mar 2000 15:21:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifiz22398 for ; Mon, 6 Mar 2000 10:20:47 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQifiz10131 for ; Mon, 6 Mar 2000 15:20:47 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Mon, 6 Mar 2000 10:19:22 -0500 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GC0NR6Q8; Mon, 6 Mar 2000 10:19:22 -0500 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FLDFGJP6; Mon, 6 Mar 2000 10:19:20 -0500 Message-ID: <38C3CC19.D3110431@americasm01.nt.com> Date: Mon, 06 Mar 2000 10:17:45 -0500 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Gupta CC: mpls Subject: Re: Admission Control and Policing in CR-LDP References: <000801bf85b9$240f7520$100d85a5@dti.daewoo.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I understand your question to be: How do I determine the traffic parameters to use for my constraint-routed LSP? (If I understand your question correctly, then the fact that you are signalling with CR-LDP is unimportant, the same question comes up with RSVP) The answer is typically related to how your box knows to set up the LSP in the first case. For example, your box might be configured to set up an LSP for this non-MPLS traffic. In this case, the traffic parameters would be configured too. Another possibility is that you are mapping from non-MPLS traffic where your box has an understanding what the traffic parameters for that traffic might be. (For example, all the traffic arrives over a T1 link) In this case, your box can generate the traffic parameters automatically. These are just two examples. Many others exist. Hope this helps. - Philip Matthews From owner-mpls@UU.NET Mon Mar 6 10:32:52 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09973 for ; Mon, 6 Mar 2000 10:32:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifiz25772; Mon, 6 Mar 2000 15:29:58 GMT Received: by mail-control.mail.uu.net id QQifiz13317 for mpls-outgoing; Mon, 6 Mar 2000 15:29:27 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifiz13312 for ; Mon, 6 Mar 2000 15:29:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifiz23713 for ; Mon, 6 Mar 2000 10:29:08 -0500 (EST) Received: from ext1.csi.forth.gr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ext1.csi.forth.gr [139.91.151.10]) id QQifiz25069 for ; Mon, 6 Mar 2000 15:29:07 GMT Received: from ismene.csi.forth.gr (ismene.csi.forth.gr [139.91.157.51]) by ext1.csi.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id RAA14044 for ; Mon, 6 Mar 2000 17:29:00 +0200 (EET) Received: from sappho.ics.forth.gr (sappho-lane.csi.forth.gr [139.91.157.50]) by ismene.csi.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id RAA06628 for ; Mon, 6 Mar 2000 17:28:59 +0200 (EET) Received: from localhost (gikas@localhost) by sappho.ics.forth.gr (8.8.8/ICS-FORTH/C1) with ESMTP id RAA14426 for ; Mon, 6 Mar 2000 17:28:58 +0200 (EET) Posted-Date: Mon, 6 Mar 2000 17:28:58 +0200 (EET) X-Authentication-Warning: sappho.csi.forth.gr: gikas owned process doing -bs Organization: Date: Mon, 6 Mar 2000 17:28:58 +0200 (EET) From: Grigoris Gikas To: mpls@UU.NET Subject: Cisco's MPLS TE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello, i'm conducting some experiments in order to test Cisco's MPLS Traffic Engineering implementation. I'm facing problems in creating a Traffic Engineering Tunnel. The testbed consists of two Cisco routers (7200 and 7500) that have two ATM interfaces (subinterfaces to be precise) connected end to end through a pvc (permanent vc). Extented IS-IS (a requirement for Cisco's MPls TE), that runs on the pvc, seems to work properly. When i attempt to create a TE Tunnel, it is created with state down and an invalid path indication. Any suggestions/solutions would be more than welcomed. Thanks in advance, Gikas Gregory Postgraduate Student Computer Science Department University Of Crete, Heraklion From owner-mpls@UU.NET Mon Mar 6 10:42:23 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10436 for ; Mon, 6 Mar 2000 10:42:22 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifja02058; Mon, 6 Mar 2000 15:39:02 GMT Received: by mail-control.mail.uu.net id QQifja13935 for mpls-outgoing; Mon, 6 Mar 2000 15:38:31 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifja13921 for ; Mon, 6 Mar 2000 15:38:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifja13785 for ; Mon, 6 Mar 2000 10:38:06 -0500 (EST) Received: from alcor.Teleglobe.CA by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.202.44.92]) id QQifja01372 for ; Mon, 6 Mar 2000 15:38:06 GMT Received: from cahqsms01.teleglobe.ca (cahqsms01.Teleglobe.CA [192.168.10.10]) by alcor.Teleglobe.CA (SMTP_Gateway) with ESMTP id AB8B13426D; Mon, 6 Mar 2000 15:38:05 +0000 (GMT) Received: by cahqsms01-bkp.Teleglobe.CA with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Mar 2000 10:38:12 -0500 Message-ID: From: "Hamza, Ahmed" To: "'Grigoris Gikas'" , mpls@UU.NET Subject: RE: Cisco's MPLS TE Date: Mon, 6 Mar 2000 10:38:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA10436 Gikas, I would recommend that you contact your local Cisco support engineer for this kind of questions. It is a general rule on the list not to discuss manufacturers related issues. Regards, Ahmed > -----Message d'origine----- > De: Grigoris Gikas [mailto:gikas@csi.forth.gr] > Date: 6 mars, 2000 10:29 > À: mpls@UU.NET > Objet: Cisco's MPLS TE > > > Hello, > i'm conducting some experiments in order to test Cisco's MPLS Traffic > Engineering implementation. I'm facing problems in creating a Traffic > Engineering Tunnel. The testbed consists of two Cisco routers > (7200 and > 7500) that have two ATM interfaces (subinterfaces to be > precise) connected > end to end through a pvc (permanent vc). Extented IS-IS (a > requirement for > Cisco's MPls TE), that runs on the pvc, seems to work properly. When i > attempt to create a TE Tunnel, it is created with state down and an > invalid path indication. Any suggestions/solutions would be more than > welcomed. > > Thanks in advance, > > Gikas Gregory > Postgraduate Student > Computer Science Department > University Of Crete, Heraklion > From owner-mpls@UU.NET Mon Mar 6 10:42:42 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10463 for ; Mon, 6 Mar 2000 10:42:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifja04078; Mon, 6 Mar 2000 15:41:32 GMT Received: by mail-control.mail.uu.net id QQifja14099 for mpls-outgoing; Mon, 6 Mar 2000 15:40:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifja14018 for ; Mon, 6 Mar 2000 15:40:36 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifja14170 for ; Mon, 6 Mar 2000 10:40:25 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQifja03147 for ; Mon, 6 Mar 2000 15:40:25 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id KAA19365; Mon, 6 Mar 2000 10:40:23 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id KAA21121; Mon, 6 Mar 2000 10:40:34 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003061540.KAA21121@curtis-lt.avici.com> To: Shahram Davari cc: "'Kireeti Kompella'" , MPLS@UU.NET Reply-To: curtis@avici.com Subject: Re: link bundling in MPLS TE In-reply-to: Your message of "Fri, 03 Mar 2000 13:27:50 PST." <336ECDAFDF7DD311B9E30090277AEE4101B4042A@nt-exchange-bby.pmc-sierra.bc.ca> Date: Mon, 06 Mar 2000 10:40:33 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <336ECDAFDF7DD311B9E30090277AEE4101B4042A@nt-exchange-bby.pmc-sierra .bc.ca>, Shahram Davari writes: > Hi Kiteeti, > > >-----Original Message----- > >From: Kireeti Kompella [mailto:kireeti@juniper.net] > >Sent: Friday, March 03, 2000 4:04 PM > >To: kireeti@juniper.net; MPLS@UU.NET; Shahram_Davari@pmc-sierra.com > >Subject: RE: link bundling in MPLS TE > > > > > >Hi Shahram, > > > >> The problem is that in both cases you want to route 200M > >traffic on a single > >> component link. If you do it as 2*100M you will succeed, but > >if you do it as > >> a single 200M you won't. > > > >I see your problem: the notion of oversubscription. > > > >Oversubscription is taking advantage of stat mux. Two 100M LSPs > >whose instantaneous traffic never adds up to more than 100M can > >share a 100M link. A 200M LSP just doesn't fit in a 100M link. > > > >Kireeti. > > > Could you also please clarify that when you say a 100M LSP, are you talking > about the Peak rate (PIR) or Committed rate (CIR)? > > If in the above example we are talking about CIR then it is impossible to > pass 2*100M LSP or a single 200M LSP through a 100M link. While if we are > talking about PIR then you are right we can't pass a 200M LSP through a 100M > link, but we are most likely unable to pass the 2*100M LSPs either, because > there is no way to guarantee that the instantaneous traffic of the two LSPs > never adds up to more than 100M. Is there any? > > Regards, > -Shahram There is no Committed rate (CIR) in the Tspec for the Controlled-Load service which most MPLS deployments (all major deployments to my knowledge) are using. There is a token rate "r" in bytes per second which is a prediction of how much might be used and the network accepts this if the traffic has a sufficient probability of acceptable performance (where the vaules of sufficient and acceptable are intentionally vague). Setting an overbooking of 200% is one way to directly specify how to apply constraints to meet those vague sufficient and acceptable criteria. The implementations that I have seen use only "r" and ignore the other parameters in the Tspec. This is one of my reasons for suggesting that we put a rate in MAP in draft-ietf-mpls-diff-ext-03.txt so we can depricate use (misuse/abuse?) of the Controlled-Load Tspec for MPLS/RSVP. Of course, if you did have two 100M flows and had two paths each of which had 100M available, you'd probably be better off spreading the load than putting both on the same path and that's exactly what many algorithms strive to accomplish rather than keep using the shortest path until it is full to its overbooking capacity. Curtis From owner-mpls@UU.NET Mon Mar 6 11:08:28 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12372 for ; Mon, 6 Mar 2000 11:08:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifjc12270; Mon, 6 Mar 2000 16:07:46 GMT Received: by mail-control.mail.uu.net id QQifjc23726 for mpls-outgoing; Mon, 6 Mar 2000 16:07:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifjc23665 for ; Mon, 6 Mar 2000 16:07:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifjc00094 for ; Mon, 6 Mar 2000 11:06:52 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifjc21551 for ; Mon, 6 Mar 2000 16:06:51 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA02654 for mpls@uu.net; Mon, 6 Mar 2000 11:06:50 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifjc23371 for ; Mon, 6 Mar 2000 16:06:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifjc19098 for ; Mon, 6 Mar 2000 11:06:22 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQifjc21212 for ; Mon, 6 Mar 2000 16:06:22 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA21485; Mon, 6 Mar 2000 08:06:18 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Mar 2000 08:06:19 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4042C@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@avici.com'" , Shahram Davari Cc: "'Kireeti Kompella'" , MPLS@UU.NET Subject: RE: link bundling in MPLS TE Date: Mon, 6 Mar 2000 08:03:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, >-----Original Message----- >From: Curtis Villamizar [mailto:curtis@avici.com] >Sent: Monday, March 06, 2000 10:41 AM >To: Shahram Davari >Cc: 'Kireeti Kompella'; MPLS@UU.NET >Subject: Re: link bundling in MPLS TE > > > >In message ><336ECDAFDF7DD311B9E30090277AEE4101B4042A@nt-exchange-bby.pmc-sierra >.bc.ca>, Shahram Davari writes: >> Hi Kiteeti, >> >> >-----Original Message----- >> >From: Kireeti Kompella [mailto:kireeti@juniper.net] >> >Sent: Friday, March 03, 2000 4:04 PM >> >To: kireeti@juniper.net; MPLS@UU.NET; Shahram_Davari@pmc-sierra.com >> >Subject: RE: link bundling in MPLS TE >> > >> > >> >Hi Shahram, >> > >> >> The problem is that in both cases you want to route 200M >> >traffic on a single >> >> component link. If you do it as 2*100M you will succeed, but >> >if you do it as >> >> a single 200M you won't. >> > >> >I see your problem: the notion of oversubscription. >> > >> >Oversubscription is taking advantage of stat mux. Two 100M LSPs >> >whose instantaneous traffic never adds up to more than 100M can >> >share a 100M link. A 200M LSP just doesn't fit in a 100M link. >> > >> >Kireeti. >> >> >> Could you also please clarify that when you say a 100M LSP, >are you talking >> about the Peak rate (PIR) or Committed rate (CIR)? >> >> If in the above example we are talking about CIR then it is >impossible to >> pass 2*100M LSP or a single 200M LSP through a 100M link. >While if we are >> talking about PIR then you are right we can't pass a 200M >LSP through a 100M >> link, but we are most likely unable to pass the 2*100M LSPs >either, because >> there is no way to guarantee that the instantaneous traffic >of the two LSPs >> never adds up to more than 100M. Is there any? >> >> Regards, >> -Shahram > > >There is no Committed rate (CIR) in the Tspec for the Controlled-Load >service which most MPLS deployments (all major deployments to my >knowledge) are using. > I don't think this draft is talking about CLS. Could the authors please clarify which rate is being considered in the MPLS Admission control, CIR or PIR? >There is a token rate "r" in bytes per second which is a prediction of >how much might be used and the network accepts this if the traffic has >a sufficient probability of acceptable performance (where the vaules >of sufficient and acceptable are intentionally vague). Setting an >overbooking of 200% is one way to directly specify how to apply >constraints to meet those vague sufficient and acceptable criteria. > >The implementations that I have seen use only "r" and ignore the other >parameters in the Tspec. This is one of my reasons for suggesting >that we put a rate in MAP in draft-ietf-mpls-diff-ext-03.txt so we can >depricate use (misuse/abuse?) of the Controlled-Load Tspec for >MPLS/RSVP. > >Of course, if you did have two 100M flows and had two paths each of >which had 100M available, you'd probably be better off spreading the >load than putting both on the same path and that's exactly what many >algorithms strive to accomplish rather than keep using the shortest >path until it is full to its overbooking capacity. > Right, but my question is still valid. >Curtis > Regards, -Shahram From owner-mpls@UU.NET Mon Mar 6 11:10:16 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12470 for ; Mon, 6 Mar 2000 11:10:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifjc13127; Mon, 6 Mar 2000 16:08:42 GMT Received: by mail-control.mail.uu.net id QQifjc23917 for mpls-outgoing; Mon, 6 Mar 2000 16:07:55 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifjc23894 for ; Mon, 6 Mar 2000 16:07:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifjc19140 for ; Mon, 6 Mar 2000 11:06:32 -0500 (EST) Received: from bgslc02.TBG.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.104.68.2]) id QQifjc21322 for ; Mon, 6 Mar 2000 16:06:31 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Mar 2000 08:42:56 -0700 Message-ID: <0C875DC28791D21192CD00104B95BFE75573F5@BGSLC02> From: Irwin Lazar To: "'Hamza, Ahmed'" , "'Grigoris Gikas'" , mpls@UU.NET Subject: RE: Cisco's MPLS TE Date: Mon, 6 Mar 2000 08:42:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF8782.A3C3717A" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF8782.A3C3717A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI, The MPLS Resource Center - http://www.mplsrc.com/ - maintains a = mailing list for the discussion of operational issues related to the deployment = of MPLS-based networks. This would be an ideal list to direct this = question to. Irwin > -----Original Message----- > From: Hamza, Ahmed [mailto:Ahmed.Hamza@teleglobe.ca] > Sent: Monday, March 06, 2000 10:38 AM > To: 'Grigoris Gikas'; mpls@UU.NET > Subject: RE: Cisco's MPLS TE >=20 >=20 > Gikas,=20 > I would recommend that you contact your local Cisco support=20 > engineer for > this kind of questions.=20 > It is a general rule on the list not to discuss manufacturers related > issues. >=20 > Regards, > Ahmed=20 >=20 > > -----Message d'origine----- > > De: Grigoris Gikas [mailto:gikas@csi.forth.gr] > > Date: 6 mars, 2000 10:29 > > =C0: mpls@UU.NET > > Objet: Cisco's MPLS TE > >=20 > >=20 > > Hello, > > i'm conducting some experiments in order to test Cisco's=20 > MPLS Traffic > > Engineering implementation. I'm facing problems in creating=20 > a Traffic > > Engineering Tunnel. The testbed consists of two Cisco routers=20 > > (7200 and > > 7500) that have two ATM interfaces (subinterfaces to be=20 > > precise) connected > > end to end through a pvc (permanent vc). Extented IS-IS (a=20 > > requirement for > > Cisco's MPls TE), that runs on the pvc, seems to work=20 > properly. When i > > attempt to create a TE Tunnel, it is created with state down and an > > invalid path indication. Any suggestions/solutions would be=20 > more than > > welcomed. > >=20 > > Thanks in advance, > >=20 > > Gikas Gregory > > Postgraduate Student > > Computer Science Department > > University Of Crete, Heraklion > >=20 >=20 ------_=_NextPart_000_01BF8782.A3C3717A Content-Type: application/octet-stream; name="Irwin Lazar (E-mail).vcf" Content-Disposition: attachment; filename="Irwin Lazar (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Lazar;Irwin FN:Irwin Lazar (E-mail) ORG:The Burton Group (Formerly NetReference, Inc.) TITLE:Senior Consultant TEL;WORK;VOICE:(703) 742-9659 TEL;WORK;FAX:(703) 742-8038 ADR;WORK:;;45615 Willow Pond Plaza;Sterling;Va;20164;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:45615 Willow Pond Plaza=0D=0ASterling, Va 20164=0D=0AUSA EMAIL;PREF;INTERNET:ilazar@tbg.com REV:20000112T150132Z END:VCARD ------_=_NextPart_000_01BF8782.A3C3717A-- From owner-mpls@UU.NET Mon Mar 6 11:22:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12956 for ; Mon, 6 Mar 2000 11:22:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifjd00091; Mon, 6 Mar 2000 16:18:43 GMT Received: by mail-control.mail.uu.net id QQifjd25218 for mpls-outgoing; Mon, 6 Mar 2000 16:18:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifjd25213 for ; Mon, 6 Mar 2000 16:18:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifjd02070 for ; Mon, 6 Mar 2000 11:17:44 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifjd29275 for ; Mon, 6 Mar 2000 16:17:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA04630 for mpls@uu.net; Mon, 6 Mar 2000 11:17:42 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifjd25190 for ; Mon, 6 Mar 2000 16:17:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifjd21227 for ; Mon, 6 Mar 2000 11:16:55 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQifjd19146 for ; Mon, 6 Mar 2000 16:16:54 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id SAA28587; Mon, 6 Mar 2000 18:16:50 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14531.55794.873837.306742@lohi.eng.telia.fi> Date: Mon, 6 Mar 2000 18:16:50 +0200 (EET) To: curtis@avici.com Cc: Shahram Davari , "'Kireeti Kompella'" , MPLS@UU.NET Subject: Re: link bundling in MPLS TE In-Reply-To: <200003061540.KAA21121@curtis-lt.avici.com> References: <336ECDAFDF7DD311B9E30090277AEE4101B4042A@nt-exchange-bby.pmc-sierra.bc.ca> <200003061540.KAA21121@curtis-lt.avici.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar writes: > The implementations that I have seen use only "r" and ignore the other > parameters in the Tspec. This is one of my reasons for suggesting > that we put a rate in MAP in draft-ietf-mpls-diff-ext-03.txt so we can > depricate use (misuse/abuse?) of the Controlled-Load Tspec for MPLS/RSVP. for resource allocation, r alone is fine, but if someone also wants to do policing of the traffic at the edge, then also the depth of the bucket should be specified. -- juha From owner-mpls@UU.NET Mon Mar 6 11:28:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13191 for ; Mon, 6 Mar 2000 11:28:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifjd02623; Mon, 6 Mar 2000 16:21:50 GMT Received: by mail-control.mail.uu.net id QQifjd25397 for mpls-outgoing; Mon, 6 Mar 2000 16:21:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifjd25389 for ; Mon, 6 Mar 2000 16:21:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifjd21849 for ; Mon, 6 Mar 2000 11:20:22 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifjd01297 for ; Mon, 6 Mar 2000 16:20:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA05223 for mpls@uu.net; Mon, 6 Mar 2000 11:20:21 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifjd25321 for ; Mon, 6 Mar 2000 16:20:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifjd21746 for ; Mon, 6 Mar 2000 11:19:57 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQifjd21271 for ; Mon, 6 Mar 2000 16:19:56 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id SAA28603; Mon, 6 Mar 2000 18:19:53 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14531.55977.800671.405022@lohi.eng.telia.fi> Date: Mon, 6 Mar 2000 18:19:53 +0200 (EET) To: Shahram Davari Cc: "'curtis@avici.com'" , "'Kireeti Kompella'" , MPLS@UU.NET Subject: RE: link bundling in MPLS TE In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B4042C@nt-exchange-bby.pmc-sierra.bc.ca> References: <336ECDAFDF7DD311B9E30090277AEE4101B4042C@nt-exchange-bby.pmc-sierra.bc.ca> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari writes: > I don't think this draft is talking about CLS. Could the authors please > clarify which rate is being considered in the MPLS Admission control, CIR or > PIR? i don't think that it is either. the rate tells how much of the link bandwidth should be allocated for this lsp. -- juha From owner-mpls@UU.NET Mon Mar 6 12:01:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14773 for ; Mon, 6 Mar 2000 12:01:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifjg27664; Mon, 6 Mar 2000 17:00:22 GMT Received: by mail-control.mail.uu.net id QQifjf27600 for mpls-outgoing; Mon, 6 Mar 2000 16:59:58 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifjf27595 for ; Mon, 6 Mar 2000 16:59:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifjf08235 for ; Mon, 6 Mar 2000 11:58:46 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifjf26353 for ; Mon, 6 Mar 2000 16:58:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA11622 for mpls@uu.net; Mon, 6 Mar 2000 11:58:44 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifjf27563 for ; Mon, 6 Mar 2000 16:58:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifjf28340 for ; Mon, 6 Mar 2000 11:58:01 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQifjf25860 for ; Mon, 6 Mar 2000 16:58:00 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA23860; Mon, 6 Mar 2000 08:57:55 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Mar 2000 08:57:56 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4042D@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Juha Heinanen'" , Shahram Davari Cc: "'curtis@avici.com'" , "'Kireeti Kompella'" , MPLS@UU.NET Subject: RE: link bundling in MPLS TE Date: Mon, 6 Mar 2000 08:55:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Juha, ----Original Message----- >From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi] >Sent: Monday, March 06, 2000 11:20 AM >To: Shahram Davari >Cc: 'curtis@avici.com'; 'Kireeti Kompella'; MPLS@UU.NET >Subject: RE: link bundling in MPLS TE > > >Shahram Davari writes: > > > I don't think this draft is talking about CLS. Could the >authors please > > clarify which rate is being considered in the MPLS >Admission control, CIR or > > PIR? > >i don't think that it is either. the rate tells how much of the link >bandwidth should be allocated for this lsp. > But according to this draft the Sigma of the BW of all admitted LSPs can have a higher BW than the link BW. That is why max-LSP-BW and Unreserved-BW are introduced separately for a link. Max-LSP-BW does not necessarily reduce when an LSP is admitted, but unreserved-BW does!!! In other words unreserved-BW ,which includes an oversubscription factor, is mainly used for Admission control. So when an LSP of rate "r" wants to be admitted then "r" should also include an oversubscription factor. Right? -Shahram >-- juha > From owner-mpls@UU.NET Mon Mar 6 12:15:44 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15500 for ; Mon, 6 Mar 2000 12:15:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifjg27642; Mon, 6 Mar 2000 17:14:57 GMT Received: by mail-control.mail.uu.net id QQifjg06267 for mpls-outgoing; Mon, 6 Mar 2000 17:14:19 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifjg06261 for ; Mon, 6 Mar 2000 17:14:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifjg10542 for ; Mon, 6 Mar 2000 12:13:02 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQifjg26382 for ; Mon, 6 Mar 2000 17:13:02 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id MAA26271; Mon, 6 Mar 2000 12:13:01 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id MAA21274; Mon, 6 Mar 2000 12:13:11 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003061713.MAA21274@curtis-lt.avici.com> To: Juha Heinanen cc: Theimer Thomas , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: soft permanent lsps In-reply-to: Your message of "Mon, 06 Mar 2000 08:53:47 +0200." <14531.22011.841193.707987@lohi.eng.telia.fi> Date: Mon, 06 Mar 2000 12:13:11 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <14531.22011.841193.707987@lohi.eng.telia.fi>, Juha Heinanen writes: > Theimer Thomas writes: > > > don't you need exactly the same functionality when MPLS is used to control > > optical lambda routers? In this case the label represents the wavelength > on > > the outgoing interface. > > yes. may be curtis could comment on how this can be achieved using his > tunneling scheme. Since we've had some clarifications from Kireeti and I've been exchanging some private email with Yakov, it appears that the ideas I put forth and the PSC in draft-kompella-mpls-optical-00.txt are very similar. The only thing that I proposed that is not covered is the conventions for the ERO that would be needed to do transparent tunnels and the local configuration at the ingress to map a fixed label to a tunnel that is localized entirely to the ingress LSR really could be documented as a usage in an informational RFC. The idea is that the outer tunnel simply provides a means to get across a major region of the topology. The RSVP adjacency could be through the tunnel or as Yakov pointed out, somewhat out-of-band through a simple technique already mentioned in the draft: If the LSR at the tail of the FA-LSP is not capable of packet switching, the Path message is unicast over the control plane to the tail of the carrier LSP, without the Router Alert option. > > However, you may also need some way to address a > > specific port (unless all ports have individual IP addresses, which may no > t > > always be the case) on your (lambda) router. > > i don't see why interfaces in optical switches could not be identified > by ip addresses especially if the control plane is based on ip. > > > It would be nice to have a > > common generic mechanism for signalling and addressing that covers both > > applications, perhaps based on your draft. I have not seen any detailled > > specs on this from the optical folks. > > the only thing that would need to be changed in the sementics of the label > value and that can be taken care of in the base ldp documents. > > -- juha I think you should take a second look at draft-kompella-mpls-optical-00.txt and draft-kompella-mpls-bundle-00.txt. Both draft may need some clarification since it was only after some email exchange that I better understood how the authors intended to use this. [Or maybe I'm just denser than most readers.] Curtis From owner-mpls@UU.NET Mon Mar 6 12:46:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17057 for ; Mon, 6 Mar 2000 12:46:23 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifjj26236; Mon, 6 Mar 2000 17:45:20 GMT Received: by mail-control.mail.uu.net id QQifji08224 for mpls-outgoing; Mon, 6 Mar 2000 17:44:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifji08190 for ; Mon, 6 Mar 2000 17:44:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifji14483 for ; Mon, 6 Mar 2000 12:44:18 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifji25500 for ; Mon, 6 Mar 2000 17:44:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA18823 for mpls@uu.net; Mon, 6 Mar 2000 12:44:16 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifji07977 for ; Mon, 6 Mar 2000 17:43:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifji14433 for ; Mon, 6 Mar 2000 12:43:49 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQifji25242 for ; Mon, 6 Mar 2000 17:43:48 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id TAA28754; Mon, 6 Mar 2000 19:43:45 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14531.61009.37346.731971@lohi.eng.telia.fi> Date: Mon, 6 Mar 2000 19:43:45 +0200 (EET) To: curtis@avici.com Cc: Theimer Thomas , mpls@UU.NET Subject: Re: soft permanent lsps In-Reply-To: <200003061713.MAA21274@curtis-lt.avici.com> References: <14531.22011.841193.707987@lohi.eng.telia.fi> <200003061713.MAA21274@curtis-lt.avici.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar writes: > The idea is that the outer tunnel simply provides a means to get > across a major region of the topology. The RSVP adjacency could be > through the tunnel or as Yakov pointed out, somewhat out-of-band > through a simple technique already mentioned in the draft: > > If the LSR at the tail of the FA-LSP is not capable of packet > switching, the Path message is unicast over the control plane to the > tail of the carrier LSP, without the Router Alert option. in case of optical SPLSPs the lambda device connected to the terminating interface of the optical SPLSP may not participate in any kind of mpls signaling. there must be a means for the originating lambda switch to select the lambda to be used for the optical SPLSP at the terminating interface. -- juha From owner-mpls@UU.NET Mon Mar 6 13:34:10 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18547 for ; Mon, 6 Mar 2000 13:34:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifjm15497; Mon, 6 Mar 2000 18:32:26 GMT Received: by mail-control.mail.uu.net id QQifjm19884 for mpls-outgoing; Mon, 6 Mar 2000 18:31:50 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifjm19879 for ; Mon, 6 Mar 2000 18:31:48 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifjm11935 for ; Mon, 6 Mar 2000 13:31:34 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQifjm25868 for ; Mon, 6 Mar 2000 18:31:30 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id NAA01880; Mon, 6 Mar 2000 13:31:28 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id NAA21654; Mon, 6 Mar 2000 13:31:38 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003061831.NAA21654@curtis-lt.avici.com> To: Shahram Davari cc: "'curtis@avici.com'" , "'Kireeti Kompella'" , MPLS@UU.NET Reply-To: curtis@avici.com Subject: Re: link bundling in MPLS TE In-reply-to: Your message of "Mon, 06 Mar 2000 08:03:51 PST." <336ECDAFDF7DD311B9E30090277AEE4101B4042C@nt-exchange-bby.pmc-sierra.bc.ca> Date: Mon, 06 Mar 2000 13:31:38 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <336ECDAFDF7DD311B9E30090277AEE4101B4042C@nt-exchange-bby.pmc-sierra .bc.ca>, Shahram Davari writes: > Hi, > > >-----Original Message----- > >From: Curtis Villamizar [mailto:curtis@avici.com] > >Sent: Monday, March 06, 2000 10:41 AM > >To: Shahram Davari > >Cc: 'Kireeti Kompella'; MPLS@UU.NET > >Subject: Re: link bundling in MPLS TE > > > > > > > >In message > ><336ECDAFDF7DD311B9E30090277AEE4101B4042A@nt-exchange-bby.pmc-sierra > >.bc.ca>, Shahram Davari writes: > >> Hi Kiteeti, > >> > >> >-----Original Message----- > >> >From: Kireeti Kompella [mailto:kireeti@juniper.net] > >> >Sent: Friday, March 03, 2000 4:04 PM > >> >To: kireeti@juniper.net; MPLS@UU.NET; Shahram_Davari@pmc-sierra.com > >> >Subject: RE: link bundling in MPLS TE > >> > > >> > > >> >Hi Shahram, > >> > > >> >> The problem is that in both cases you want to route 200M > >> >traffic on a single > >> >> component link. If you do it as 2*100M you will succeed, but > >> >if you do it as > >> >> a single 200M you won't. > >> > > >> >I see your problem: the notion of oversubscription. > >> > > >> >Oversubscription is taking advantage of stat mux. Two 100M LSPs > >> >whose instantaneous traffic never adds up to more than 100M can > >> >share a 100M link. A 200M LSP just doesn't fit in a 100M link. > >> > > >> >Kireeti. > >> > >> > >> Could you also please clarify that when you say a 100M LSP, > >are you talking > >> about the Peak rate (PIR) or Committed rate (CIR)? > >> > >> If in the above example we are talking about CIR then it is > >impossible to > >> pass 2*100M LSP or a single 200M LSP through a 100M link. > >While if we are > >> talking about PIR then you are right we can't pass a 200M > >LSP through a 100M > >> link, but we are most likely unable to pass the 2*100M LSPs > >either, because > >> there is no way to guarantee that the instantaneous traffic > >of the two LSPs > >> never adds up to more than 100M. Is there any? > >> > >> Regards, > >> -Shahram > > > > > >There is no Committed rate (CIR) in the Tspec for the Controlled-Load > >service which most MPLS deployments (all major deployments to my > >knowledge) are using. > > > > I don't think this draft is talking about CLS. Could the authors please > clarify which rate is being considered in the MPLS Admission control, CIR or > PIR? > > >There is a token rate "r" in bytes per second which is a prediction of > >how much might be used and the network accepts this if the traffic has > >a sufficient probability of acceptable performance (where the vaules > >of sufficient and acceptable are intentionally vague). Setting an > >overbooking of 200% is one way to directly specify how to apply > >constraints to meet those vague sufficient and acceptable criteria. > > > >The implementations that I have seen use only "r" and ignore the other > >parameters in the Tspec. This is one of my reasons for suggesting > >that we put a rate in MAP in draft-ietf-mpls-diff-ext-03.txt so we can > >depricate use (misuse/abuse?) of the Controlled-Load Tspec for > >MPLS/RSVP. > > > >Of course, if you did have two 100M flows and had two paths each of > >which had 100M available, you'd probably be better off spreading the > >load than putting both on the same path and that's exactly what many > >algorithms strive to accomplish rather than keep using the shortest >path until it is full to its overbooking capacity. > > > > Right, but my question is still valid. > > >Curtis > > Regards, > -Shahram The only CIR I could find was in the three color marker and essentially describes a token bucket. If applied to AF, the only commitment implied is if the bucket is not exceeeded mark the packet accordingly. If marking green means no loss (which IMHO should be for better service classes), respect that but if the drop probability of green is non-zero, there still could be loss. A marking of yellow or red will certainly imply a non-zero loss probability. Now the question is whether the number in the Tspec is the amount of AF green traffic (AFx1), or the total amount of AF traffic (AFxy for all y). If one interprets the Tspec rate "r" to be the amount of AFx1 (which apparenlty you do), then overbooking by 200% sounds more than a bit risky, particularly if the service calls for lossless or near lossless AFx1. If one interprets the Tspec rate "r" to be the total of AFx1, AFx2, AFx3, (as I did) then you can oversubscribe by 200% and toss AFx3 traffic if you need to (was intended for AF). I don't know if this answers your question but it does raise the question as to whether interpretation of the Tspec "r" parameter is ambiguous and should be clarified in draft-ietf-mpls-diff-ext-03.txt if not superceded by putting rates directly in the MAP. Curtis From owner-mpls@UU.NET Mon Mar 6 13:35:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18611 for ; Mon, 6 Mar 2000 13:35:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifjm17485; Mon, 6 Mar 2000 18:35:28 GMT Received: by mail-control.mail.uu.net id QQifjm20027 for mpls-outgoing; Mon, 6 Mar 2000 18:35:02 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifjm19982 for ; Mon, 6 Mar 2000 18:34:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifjm12369 for ; Mon, 6 Mar 2000 13:34:44 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQifjm27924 for ; Mon, 6 Mar 2000 18:34:43 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id NAA02159; Mon, 6 Mar 2000 13:34:41 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id NAA21670; Mon, 6 Mar 2000 13:34:51 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003061834.NAA21670@curtis-lt.avici.com> To: Juha Heinanen cc: curtis@avici.com, Shahram Davari , "'Kireeti Kompella'" , MPLS@UU.NET Reply-To: curtis@avici.com Subject: Re: link bundling in MPLS TE In-reply-to: Your message of "Mon, 06 Mar 2000 18:16:50 +0200." <14531.55794.873837.306742@lohi.eng.telia.fi> Date: Mon, 06 Mar 2000 13:34:51 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <14531.55794.873837.306742@lohi.eng.telia.fi>, Juha Heinanen writes: > Curtis Villamizar writes: > > > The implementations that I have seen use only "r" and ignore the other > > parameters in the Tspec. This is one of my reasons for suggesting > > that we put a rate in MAP in draft-ietf-mpls-diff-ext-03.txt so we can > > depricate use (misuse/abuse?) of the Controlled-Load Tspec for MPLS/RSVP. > > for resource allocation, r alone is fine, but if someone also wants to > do policing of the traffic at the edge, then also the depth of the > bucket should be specified. > > -- juha I agree. Then unless policing is also done within the core all that is needed in the signaling is "r" and the other Tspec parameters serve no purpose when used in MPLS/RSVP except to confuse people. Curtis From owner-mpls@UU.NET Tue Mar 7 06:33:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00448 for ; Tue, 7 Mar 2000 06:33:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifmc05770; Tue, 7 Mar 2000 11:32:16 GMT Received: by mail-control.mail.uu.net id QQifmc02225 for mpls-outgoing; Tue, 7 Mar 2000 11:31:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifmc02218 for ; Tue, 7 Mar 2000 11:31:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifmc29114 for ; Tue, 7 Mar 2000 06:31:13 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifmc04989 for ; Tue, 7 Mar 2000 11:31:12 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA14411 for mpls@uu.net; Tue, 7 Mar 2000 06:31:11 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifmc02116 for ; Tue, 7 Mar 2000 11:30:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifmc25404 for ; Tue, 7 Mar 2000 06:30:04 -0500 (EST) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQifmc04145 for ; Tue, 7 Mar 2000 11:30:03 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29471; Tue, 7 Mar 2000 06:30:02 -0500 (EST) Message-Id: <200003071130.GAA29471@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-mib-05.txt Date: Tue, 07 Mar 2000 06:30:01 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) Author(s) : J. Cucchiara, H. Sjostrand, J. Luciani Filename : draft-ietf-mpls-ldp-mib-05.txt Pages : 74 Date : 06-Mar-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000306120701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000306120701.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Mar 7 08:04:58 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19912 for ; Tue, 7 Mar 2000 08:04:58 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifmi24214; Tue, 7 Mar 2000 13:03:02 GMT Received: by mail-control.mail.uu.net id QQifmi16851 for mpls-outgoing; Tue, 7 Mar 2000 13:02:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifmi16780 for ; Tue, 7 Mar 2000 13:02:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifmi05023 for ; Tue, 7 Mar 2000 08:02:13 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQifmi23240 for ; Tue, 7 Mar 2000 13:01:41 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id SAA20498; Tue, 7 Mar 2000 18:27:21 -0600 (GMT) Message-ID: <001701bf8835$de3dcea0$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: "Philip Matthews" Cc: "mpls" References: <000801bf85b9$240f7520$100d85a5@dti.daewoo.co.kr> <38C3CC19.D3110431@americasm01.nt.com> Subject: Re: Admission Control and Policing in CR-LDP Date: Tue, 7 Mar 2000 18:35:49 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Please see the comments inline. ----- Original Message ----- From: Philip Matthews To: Santosh Gupta Cc: mpls Sent: Monday, March 06, 2000 8:47 PM Subject: Re: Admission Control and Policing in CR-LDP > I understand your question to be: > How do I determine the traffic parameters > to use for my constraint-routed LSP? > (If I understand your question correctly, > then the fact that you are signalling with > CR-LDP is unimportant, the same question comes > up with RSVP) > > The answer is typically related to how your box > knows to set up the LSP in the first case. > For example, your box might be configured to > set up an LSP for this non-MPLS traffic. > In this case, the traffic parameters would be > configured too. Non - MPLS traffic can be Differentiated or Integrated. For the Differentiated case, the box would know as to what parameters it should use to form the LSP according to SLA. But for the Integrated signallling, it should recv a request and then make the LSP.But there is no such feature in LDP to receive such requests and handle them. This feature is required if peer in the other domain is say RSVP aware. For that the box should be able to receive requests and form the LSPs accordingly. How does the LER in my domain handle such traffic and requests ? I have a little confusion here . Are the terms differentiated and Integrated Signalling specific to RSVP or they are genaral terms and they are to be supported in all the protocols like RSVP/LDP. There is no such mention of two different signalling in LDP drafts. > > Another possibility is that you are mapping > from non-MPLS traffic where your box has an > understanding what the traffic parameters for > that traffic might be. (For example, all the > traffic arrives over a T1 link) In this case, your box > can generate the traffic parameters automatically. > > These are just two examples. Many others exist. > > Hope this helps. > > - Philip Matthews > Regards Santosh From owner-mpls@UU.NET Tue Mar 7 09:33:52 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10716 for ; Tue, 7 Mar 2000 09:33:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifmn06944; Tue, 7 Mar 2000 14:19:20 GMT Received: by mail-control.mail.uu.net id QQifmn05954 for mpls-outgoing; Tue, 7 Mar 2000 14:18:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifmn05949 for ; Tue, 7 Mar 2000 14:18:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifmn13519 for ; Tue, 7 Mar 2000 09:18:36 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQifmn06405 for ; Tue, 7 Mar 2000 14:18:36 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA21917 for ; Tue, 7 Mar 2000 06:18:35 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA16664 for mpls@uu.net; Tue, 7 Mar 2000 09:18:34 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifln20402 for ; Tue, 7 Mar 2000 07:48:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifln11048 for ; Tue, 7 Mar 2000 02:48:01 -0500 (EST) Received: from hme0.s0092.idc1.oss.level3.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gdffw1.Denver1.Level3.net [209.244.1.161]) id QQifln24499 for ; Tue, 7 Mar 2000 07:48:01 GMT Received: from boyle.jimp.l3.com (qfe0.buzz.idc1.oss.level3.com [10.1.116.4]) by hme0.s0092.idc1.oss.level3.com (8.8.8+Sun/8.8.8) with ESMTP id AAA28602 for ; Tue, 7 Mar 2000 00:47:52 -0700 (MST) Message-Id: <4.2.2.20000307003211.046eb4a0@localhost> X-Sender: jboyle@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 07 Mar 2000 00:51:57 -0700 To: mpls@UU.NET From: Jim Boyle Subject: Re: tunnels within tunnels and MPLS/RSVP ERO In-Reply-To: <200002262250.RAA11533@curtis-lt.avici.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I like Noel's analysis, which says there are several ways to approach this, which means of course that all will be used as appropriate. Here is another approach which probably is not appropriate to networks like curtis describes which have congestion issues to manage within a "region". If one wants to avoid 1M LSPs below, but retain end2end MPLS capability (for VPN, for instance), and can manage congestion in a "region" via other mechanisms..... You can run LDP out into the region to give, in curtis's example, a-LSR1 a binding to use to get through the core to a-LSR2. All backbone routers would run RSVP-TE to manage congestion/utilization in the high capacity WAN. They also have to run directed LDP sessions so when the penultimate backbone router pops the RSVP-TE learned label, the ultimate b-LSR knows how to forward. Want to add an a-LSR? no problem, no need to touch all the other a-LSRs. It can also be argued that LDP is an easier barrier for regional/edge routers than RSVP, but to be sure that would be one one would have to argue. The numbers this design should work for is on the order of 100 or so "b"/backbone routers w/ 10-20 "a"/ regional routers per region. regards, Jim >Lets make the example more concrete and slightly smaller. There are a >doxen or so backbone routers covering "regions" and on the order of 50 >routers in a given region. The backbone routers are all MPLS capable. >They RSVP neighbor with their adjacent routers. They have a full mesh >of tunels among themselves. They also have a tunnel to each MPLS >capable access router within their region (assume a reasonable subset >are). > >The access routers could set up tunnels that go end to end but to keep >the number of tunnels down in the backbone, hierarchical tunnels are >used. The access router (same naming convention) creates an ERO with >"hop hop .. hop b-SLR1 b-LSR2 a-LSR2". b-LSR2 must send RSVP through >the tunnel and therefore has a RSVP neighbor b-LSR2. b-LSR2 has >traffic engineered a path to a-lSR2 and therefore has a RSVP neighbor >a-LSR2. This would mean that each backbone router has 1) on the order >of 4-5 RSVP neighbors that are directly connected on the backbone, 2) >at least a few that are directly connected on the access side, 3) >about a dozen RSVP neighbors that are the loopbacks (router-ID) of >other backbone routers, 4) and 50-100 RSVP neighbors that are the MPLS >capable routers in the same region. > >In this scenario there may be 500-1000 routers (maybe more). If they >are exhaustively connected that's up to 1,000,000 LSPs. Multiple >services and that's still more. That would involve a lot of setup on >a link failure. > >The network as a whole can still be quite scalable if hierarchical >tunnels are used. For example, the backbone LSR may have 1,000,000 >tunnels, but when a physical link is lost in the backbone, in this >example less than a dozen need to rerouted (those in the backbone that >were affected). The "link" being used by the hierarchical tunnels is >not considered down unless the underlying tunnel can't be rerouted (if >its local-protected or has a precomputed alternative, this is >particularly a non-issue). > > > > I apologize that this is half-baked and I apologize further if I'm > > accidentally reinventing parts of PNNI. The important meta point here is > > that there are reasonable alternatives. > > > > Tony > > >It sounds like you agree that RSVP neighbors must be formed through >the tunnels but don't see any need for a new subobject. > >The only question to you and other implementers is then what to put in >the ERO. I would imagine that if we are strictly using the existing >ERO subobjects it would be two type 1 "IPv4 prefix" subobject, with a >prefix length of 32 and the router-Id of the two ends of the tunnel. > >For example, with the tunnel setup going left to right where 10.1.1.1 >is an interface in a router N-1 and 10.1.2.2 is an interface in router >N+2. > > ------ router N ------ ---- router N+1 ---- > Id = 10.128.1.1 Id = 10.128.1.2 > 10.1.1.1 -- 10.1.1.2 ===== LSP ===== 10.1.2.1 -- 10.1.2.2 > > the ERO would have: > > ... 10.1.1.1 10.1.1.2 10.128.1.1 10.128.1.2 10.1.2.1 10.1.2.2 ... > >If this is how others interpret how to form the ERO for tunnels in >tunnels then all is fine and I can be quiet an go back to coding. > >Best Regards, > >Curtis From owner-mpls@UU.NET Wed Mar 8 06:34:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29531 for ; Wed, 8 Mar 2000 06:34:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifpu21797; Wed, 8 Mar 2000 11:33:06 GMT Received: by mail-control.mail.uu.net id QQifpu03646 for mpls-outgoing; Wed, 8 Mar 2000 11:32:34 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifpu03640 for ; Wed, 8 Mar 2000 11:32:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifpu28124 for ; Wed, 8 Mar 2000 06:32:01 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifpu25206 for ; Wed, 8 Mar 2000 11:32:00 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA20408 for mpls@uu.net; Wed, 8 Mar 2000 06:31:59 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifpu03619 for ; Wed, 8 Mar 2000 11:31:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifpu27972 for ; Wed, 8 Mar 2000 06:31:16 -0500 (EST) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQifpu20713 for ; Wed, 8 Mar 2000 11:31:16 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28406; Wed, 8 Mar 2000 06:31:14 -0500 (EST) Message-Id: <200003081131.GAA28406@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zhang-crldp-ext-for-vpn-00.txt Date: Wed, 08 Mar 2000 06:31:14 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to CR-LDP for VPNs Author(s) : P. Houlik, Z. Zhang, S. Balaji Filename : draft-zhang-crldp-ext-for-vpn-00.txt Pages : 5 Date : 07-Mar-00 This document proposes to add an optional VPN-ID TLV to CR-LDP label request message to identify the VPN that the request is meant for. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhang-crldp-ext-for-vpn-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zhang-crldp-ext-for-vpn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zhang-crldp-ext-for-vpn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000307114113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zhang-crldp-ext-for-vpn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zhang-crldp-ext-for-vpn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000307114113.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Mar 8 06:34:26 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29661 for ; Wed, 8 Mar 2000 06:34:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifpu26064; Wed, 8 Mar 2000 11:33:10 GMT Received: by mail-control.mail.uu.net id QQifpu03651 for mpls-outgoing; Wed, 8 Mar 2000 11:32:35 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifpu03641 for ; Wed, 8 Mar 2000 11:32:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifpu28123 for ; Wed, 8 Mar 2000 06:32:01 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifpu25205 for ; Wed, 8 Mar 2000 11:32:00 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA20407 for mpls@uu.net; Wed, 8 Mar 2000 06:31:59 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifpu03620 for ; Wed, 8 Mar 2000 11:31:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifpu27958 for ; Wed, 8 Mar 2000 06:31:07 -0500 (EST) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQifpu20641 for ; Wed, 8 Mar 2000 11:31:06 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28299; Wed, 8 Mar 2000 06:31:04 -0500 (EST) Message-Id: <200003081131.GAA28299@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-fujita-mpls-crldp-crankback-00.txt Date: Wed, 08 Mar 2000 06:31:04 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Routing Extensions for CR-LDP Author(s) : N. Fujita, A. Iwata, G. Ash Filename : draft-fujita-mpls-crldp-crankback-00.txt Pages : 11 Date : 07-Mar-00 This draft proposes crankback routing extensions for CR-LDP signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that label requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the proposed crankback routing schemes can be also applied to end-to-end LSP restoration by indicating the location of the failure link or node. This would significantly improve the recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fujita-mpls-crldp-crankback-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fujita-mpls-crldp-crankback-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fujita-mpls-crldp-crankback-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000307114051.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fujita-mpls-crldp-crankback-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-fujita-mpls-crldp-crankback-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000307114051.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Mar 8 10:33:41 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20555 for ; Wed, 8 Mar 2000 10:33:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifqk21547; Wed, 8 Mar 2000 15:31:51 GMT Received: by mail-control.mail.uu.net id QQifqk19126 for mpls-outgoing; Wed, 8 Mar 2000 15:31:16 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifqk19119 for ; Wed, 8 Mar 2000 15:31:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifqk25899 for ; Wed, 8 Mar 2000 10:30:47 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQifqk16731 for ; Wed, 8 Mar 2000 15:30:46 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA25182; Wed, 8 Mar 2000 07:54:47 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA18272; Wed, 8 Mar 2000 10:30:08 -0500 (EST) Message-Id: <200003081530.KAA18272@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: mpls@UU.NET Subject: I-D ACTION:draft-rosen-mpls-profiles-00.txt User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: multipart/mixed; boundary="Multipart_Wed_Mar__8_10:30:07_2000-1" Date: Wed, 08 Mar 2000 10:30:07 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk --Multipart_Wed_Mar__8_10:30:07_2000-1 Content-Type: text/plain; charset=US-ASCII I'd like to call your attention to the following draft, which is a first attempt to specify small set of MPLS "profiles" in a way which is detailed enough to ensure interoperability. We anticipate working with the authors of draft-loa-mpls-cap-set to merge the two documents. In the meantime, the document below specifies only those profiles which the authors believe are useful, although we recognize that other members of the Working Group prefer other profiles. We would like to try to keep this document focused though on things that are actually being implemented. --Multipart_Wed_Mar__8_10:30:07_2000-1 Content-Type: message/rfc822 Message-Id: <200003081132.GAA28912@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rosen-mpls-profiles-00.txt Date: Wed, 08 Mar 2000 06:32:21 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: loki.ietf.org X-SMTP-MAIL-FROM: ietf-123-owner@loki.ietf.org X-SMAP-Received-From: outside X-SMTP-PEER-INFO: loki.ietf.org [132.151.1.177] --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS Profiles Author(s) : E. Rosen, B. Thomas, L. Levine, C. Iturralde, G. Swallow Filename : draft-rosen-mpls-profiles-00.txt Pages : 9 Date : 07-Mar-00 The MPLS protocol specifications provide a large number of options, and it can be difficult to know exactly which protocol messages, objects, and procedures must be supported in order to provide some particular application of MPLS, or in order to interoperate with some other implementation. This document specifies a number of MPLS 'Profiles'. Each Profile is a subset of the full MPLS functionality, specified in enough detail to ensure that two implementations of a given Profile will interoperate. This document also specifies which Profiles may be used for which purposes. In the future, it is hoped that specifications for the applications of MPLS will specify the Profiles that must be implemented in order to support the application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-mpls-profiles-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosen-mpls-profiles-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosen-mpls-profiles-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000307115916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-mpls-profiles-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosen-mpls-profiles-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000307115916.I-D@ietf.org> --OtherAccess-- --NextPart-- --Multipart_Wed_Mar__8_10:30:07_2000-1-- From owner-mpls@UU.NET Wed Mar 8 11:11:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04250 for ; Wed, 8 Mar 2000 11:11:20 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifqm16298; Wed, 8 Mar 2000 16:09:54 GMT Received: by mail-control.mail.uu.net id QQifqm29426 for mpls-outgoing; Wed, 8 Mar 2000 16:09:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifqm29413 for ; Wed, 8 Mar 2000 16:09:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifqm07258 for ; Wed, 8 Mar 2000 11:09:05 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifqm11033 for ; Wed, 8 Mar 2000 16:09:04 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA17345 for mpls@uu.net; Wed, 8 Mar 2000 11:09:03 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifqm29326 for ; Wed, 8 Mar 2000 16:08:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifqm01652 for ; Wed, 8 Mar 2000 11:08:29 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifqm10704 for ; Wed, 8 Mar 2000 16:08:28 GMT Received: from rschmitt-nt (ch2-dhcp134-243.cisco.com [161.44.134.243]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA17185 for ; Wed, 8 Mar 2000 11:08:27 -0500 (EST) Message-Id: <4.2.0.58.20000308094052.00a47560@pilgrim.cisco.com> X-Sender: rschmitt@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Mar 2000 11:11:34 -0800 To: mpls@UU.NET From: Rob Schmitt Subject: LDP MIB Indexing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >With regards to draft-ietf-mpls-ldp-mib-05, specifically the INDEX sets of various tables. The tables in question are shown here; my comment relates to the inclusion of the index object 'mplsLdpPeerLdpId'. I show the table, followed by my comments about that table. @ { mplsLdpEntityPeerTable } INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId } Are there _any_ scenarios anticipated where, having specified both 'mplsLdpEntityLdpId' and 'mplsLdpEntityIndex', where a further qualifier would be required to differentiate a row in this table? The third index object is redundant, inconvenient for implementation, has previously been so recognized by the authors, and there have been no arguments put forward as to why it should be reintroduced into the MIB. There are really two choices for crafting an INDEX for this table 1) { mplsLdpEntityLdpId, mplsLdpEntityIndex } or 2) { mplsLdpPeerLdpId }. We should pick one of the above two options, not a union of the two. @ { mplsLdpSessionTable } INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId } The index objects 'mplsLdpEntityLdpId' and 'mplsLdpEntityIndex' together and alone serve to identity sessions (and potential sessions in other tables). 'mplsLdpPeerLdpId' is extraneous as an index. @ { mplsLdpHelloAdjacencyTable } INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpHelloAdjacencyIndex } In this table 'mplsLdpEntityLdpId' and 'mplsLdpEntityIndex' serve to uniquely select a session that supports {n} adjacencies. The {n-th} instance is resolved by 'mplsLdpHelloAdjacencyIndex. But again, the interjection of 'mplsLdpPeerLdpId' is redundant, difficult for implementation, and does not add any benefit. @ { mplsLdpAtmSessionTable } INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpSessionAtmLabelRangeLowerBoundVpi, mplsLdpSessionAtmLabelRangeLowerBoundVci } Since we are dealing here with the labels in the domain of an Entity, what is the benefit of interjecting 'mplsLdpPeerLdpId' here as an index. This is going to be problematic for any implementor of this MIB. @ { mplsLdpFrameRelaySessionTable } INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpFrSessionMinDlci } Same comment as for AtmSessionTable: mplsLdpPeerLdpId is extraneous. @ { mplsLdpSessionPeerAddressTable } INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpSessionPeerAddressIndex } Same comment as for mplsLdpHelloAdjacencyTable : mplsLdpPeerLdpId is extraneous. MORE DISCUSSION -------------------------------- In recent discussions, there was a hypothetical situation described whereby one might want to instantiate multiple Entities having the same LdpId. From the perspective of a remote entity, the multiple instances would be differentiated with another index called mplsLdpPeerIndex. If the above inclusions of 'mplsLdpPeerLdpId' are intended to address that scenario, they have failed to do so. It had been conjectured that one might want to assign differing Label Distribution methods to the same Entity, (a Peer when viewed from a remote Entity). This could only be done for platform-wide label spaces, where the norm would be to assign downstream-unsolicited for _all_ instances of the Entity. In case of conflict arising during discovery, the LDP spec states that downstream-unsolicited 'wins' in the negotiation. So specifying this functionality in the MIB imputes to the LDP engine itself a burden of support that is non-trivial and hypothetical in the extreme. While not precluded by the LDP Specification, this functionality is implicitly _not_ included, and therefore should not be wired into the MIB. MORE ---------- From day one of this MIB design, the term 'Peer' has meant 'remote entity'. Prefixing this with 'Entity' to make 'EntityPeer' is, in my humble opinion, an obfuscation of the term. A Peer is a remote Entity, whether there is a session with it, a potential session, or even a failed session with it. It is still a 'Peer'. > :) > /rs > > +---------------------------------------+------------------------------+ > | | | Robert Schmitt > | | | rschmitt@cisco.com (w) > ||| ||| | Chelmsford, MA > ||||| ||||| | 978-244-3076 > ..:|||||||:...:|||||||:.. | > C i s c o S y s t e m s | > +----------------------------------+-----------------------------------+ From owner-mpls@UU.NET Wed Mar 8 12:36:00 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04636 for ; Wed, 8 Mar 2000 12:35:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifqs10701; Wed, 8 Mar 2000 17:34:43 GMT Received: by mail-control.mail.uu.net id QQifqs13016 for mpls-outgoing; Wed, 8 Mar 2000 17:34:24 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifqs13006 for ; Wed, 8 Mar 2000 17:34:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifqs20499 for ; Wed, 8 Mar 2000 12:33:57 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifqs10128 for ; Wed, 8 Mar 2000 17:33:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA29279 for mpls@uu.net; Wed, 8 Mar 2000 12:33:55 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifqs12955 for ; Wed, 8 Mar 2000 17:32:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifqs13597 for ; Wed, 8 Mar 2000 12:32:09 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQifqs03289 for ; Wed, 8 Mar 2000 17:32:08 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Mar 2000 12:30:25 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F80F@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Rob Schmitt'" , mpls@UU.NET Subject: RE: LDP MIB Indexing Date: Wed, 8 Mar 2000 12:30:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Rob Schmitt [mailto:rschmitt@cisco.com] > Sent: Wednesday, March 08, 2000 2:12 PM > To: mpls@UU.NET > Subject: LDP MIB Indexing > > > > > >With regards to draft-ietf-mpls-ldp-mib-05, specifically the > INDEX sets of > various tables. The tables in question are shown here; my comment > relates to the inclusion of the index object 'mplsLdpPeerLdpId'. I > show the table, followed by my comments about that table. > @ > { mplsLdpEntityPeerTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId } > > Are there _any_ scenarios anticipated where, having specified > both 'mplsLdpEntityLdpId' and 'mplsLdpEntityIndex', > where a further qualifier would be required to differentiate > a row in this table? The third index object is redundant, Robert, I would implore you to refer to version 01 of the MIB which is available from Noritoshi Demizu's page http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ This version has what you are suggesting in this email. Then, I would like you to take a look at the archives from July 1999 where several companies requested an additional index in the Entity table (i.e. mplsLdpEntityIndex). Then, if you would be so kind as to review the Oslo meeting minutes, specifically where Bob Thomas (cisco) raised the issue also (i.e that one-to-one mapping is probably not sufficient for indexing), and Jim Luciani agreed that it should be fixed (which we have in subsequent versions of the LDP MIB). Perhaps I am missing something from this long email, but as far as I can tell, this issue has already been addressed in the version 01 MIB and in subsequent emails and Oslo meeting minutes. Having said this, I agree with you that not all implementations need mplsLdpEntityIndex, BUT the working group wanted this additional index, because some implementations obviously do need it. Adding indexes and objects because some implementations need them is not uncommon in Standard MIBs. This has been my experience with the IETF Standard MIBs and with MIBs in other standards bodies as well. -Joan > inconvenient > for implementation, has previously been so recognized by > the authors, > and there have been no arguments put forward as to why it should be > reintroduced into the MIB. There are really two choices > for crafting > an INDEX for this table > 1) { mplsLdpEntityLdpId, mplsLdpEntityIndex } or > 2) { mplsLdpPeerLdpId }. > We should pick one of the above two options, not a union of the two. > > @ > { mplsLdpSessionTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId } > > The index objects 'mplsLdpEntityLdpId' and 'mplsLdpEntityIndex' > together and alone serve to identity sessions (and potential > sessions in other tables). 'mplsLdpPeerLdpId' is extraneous > as an index. > > @ > { mplsLdpHelloAdjacencyTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpHelloAdjacencyIndex } > > In this table 'mplsLdpEntityLdpId' and 'mplsLdpEntityIndex' serve to > uniquely select a session that supports {n} adjacencies. The {n-th} > instance is > resolved by 'mplsLdpHelloAdjacencyIndex. But again, the > interjection of > 'mplsLdpPeerLdpId' is redundant, difficult for implementation, and > does not add any benefit. > > @ > { mplsLdpAtmSessionTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpSessionAtmLabelRangeLowerBoundVpi, > > mplsLdpSessionAtmLabelRangeLowerBoundVci } > > Since we are dealing here with the labels in the domain > of an Entity, what is the benefit of interjecting > 'mplsLdpPeerLdpId' here > as an index. This is going to be problematic for any > implementor of this MIB. > > @ > { mplsLdpFrameRelaySessionTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpFrSessionMinDlci } > > Same comment as for AtmSessionTable: mplsLdpPeerLdpId is extraneous. > > @ > { mplsLdpSessionPeerAddressTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpSessionPeerAddressIndex } > > Same comment as for mplsLdpHelloAdjacencyTable : > mplsLdpPeerLdpId is extraneous. > > MORE DISCUSSION > -------------------------------- > In recent discussions, there was a hypothetical situation > described whereby one might want to instantiate multiple Entities > having the same LdpId. From the perspective of a remote entity, the > multiple instances would be differentiated with another index called > mplsLdpPeerIndex. If the > above inclusions of 'mplsLdpPeerLdpId' are intended to address that > scenario, they have failed to do so. It had been > conjectured that one > might want to assign differing Label Distribution methods to the > same Entity, (a Peer when viewed from a remote Entity). This > could only be done for platform-wide label spaces, where the norm > would be to assign downstream-unsolicited for _all_ instances of the > Entity. In case of conflict arising during discovery, the > LDP spec states that downstream-unsolicited 'wins' in the > negotiation. > So specifying this functionality in the MIB imputes to the > LDP engine > itself a burden of support that is non-trivial and > hypothetical in the > extreme. While not precluded by the LDP Specification, this > functionality is implicitly _not_ included, and therefore should not > be wired into the MIB. > > > MORE > ---------- > From day one of this MIB design, the term 'Peer' has meant > 'remote entity'. > Prefixing this with 'Entity' to make 'EntityPeer' is, in my > humble opinion, an > obfuscation of the term. A Peer is a remote Entity, whether there is > a session with it, a potential session, or even a failed > session with it. > It is still a 'Peer'. > > > > :) > > /rs > > > > > +---------------------------------------+--------------------- > ---------+ > > | | | Robert Schmitt > > | | | > rschmitt@cisco.com (w) > > ||| ||| | Chelmsford, MA > > ||||| ||||| | 978-244-3076 > > ..:|||||||:...:|||||||:.. | > > C i s c o S y s t e m s | > > > +----------------------------------+-------------------------- > ---------+ > > From owner-mpls@UU.NET Wed Mar 8 14:42:59 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12181 for ; Wed, 8 Mar 2000 14:42:58 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifra02182; Wed, 8 Mar 2000 19:31:08 GMT Received: by mail-control.mail.uu.net id QQifra05153 for mpls-outgoing; Wed, 8 Mar 2000 19:30:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifra05148 for ; Wed, 8 Mar 2000 19:30:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifra00914 for ; Wed, 8 Mar 2000 14:30:23 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQifra06494 for ; Wed, 8 Mar 2000 19:30:23 GMT Received: from mjork-pc (mjork-pc.avici.com [10.1.2.168]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id OAA05544; Wed, 8 Mar 2000 14:30:19 -0500 (EST) Received: by localhost with Microsoft MAPI; Wed, 8 Mar 2000 14:30:19 -0500 Message-ID: <01BF890A.D45C72D0.mjork@avici.com> From: Markus Jork To: "'Eric Rosen'" , "mpls@UU.NET" Subject: RE: I-D ACTION:draft-rosen-mpls-profiles-00.txt Date: Wed, 8 Mar 2000 14:30:18 -0500 Organization: Avici X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, I believe section 3.1 ("Part 1: RSVP signalling and reliability extensions") needs some more detail to ensure interoperability. Specifically, I noticed interoperability problems because the latest version of IOS I tried did not support the CoS Tspec/Flowspec object. Your draft states: "This Part also includes support for the Controlled Load Service [CLOAD]." How about changing this to something like: For LSPs with no bandwidth requirements, the CoS Tspec/Flowspec is used. Otherwise, intserv Tspec and Controlled-Load Service Flowspec are used. The LSP bandwidth is carried in the intserv Tspec token bucket rate. Admission control is based only on this value, other intserv Tspec parameters are ignored. Markus From owner-mpls@UU.NET Wed Mar 8 15:14:28 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21129 for ; Wed, 8 Mar 2000 15:14:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifrc03813; Wed, 8 Mar 2000 20:13:36 GMT Received: by mail-control.mail.uu.net id QQifrc15239 for mpls-outgoing; Wed, 8 Mar 2000 20:13:20 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifrc15226 for ; Wed, 8 Mar 2000 20:13:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifrc07235 for ; Wed, 8 Mar 2000 15:12:42 -0500 (EST) Received: from exchsrv1.cosinecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQifrc03090 for ; Wed, 8 Mar 2000 20:12:41 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Mar 2000 12:13:17 -0800 Message-ID: From: Vijay Srinivasan To: mpls@UU.NET Subject: new contact information Date: Wed, 8 Mar 2000 12:13:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF893A.BD8FDCF6" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF893A.BD8FDCF6 Content-Type: text/plain Hi all, My new contact information effective 3/6/00 is: email: vsriniva@cosinecom.com phone: 650-628-4892 Also, I will update the charter based on the comments send it out to the list in the next few days. Regards, - Vijay ------_=_NextPart_001_01BF893A.BD8FDCF6 Content-Type: text/html new contact information

Hi all,

My new contact information effective 3/6/00 is:

email: vsriniva@cosinecom.com
phone: 650-628-4892

Also, I will update the charter based on the comments send it out to the list in the next few days.

Regards,
- Vijay

------_=_NextPart_001_01BF893A.BD8FDCF6-- From owner-mpls@UU.NET Wed Mar 8 20:37:30 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23376 for ; Wed, 8 Mar 2000 20:37:30 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifry07052; Thu, 9 Mar 2000 01:36:15 GMT Received: by mail-control.mail.uu.net id QQifry15732 for mpls-outgoing; Thu, 9 Mar 2000 01:35:47 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifry15727 for ; Thu, 9 Mar 2000 01:35:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifry25974 for ; Wed, 8 Mar 2000 20:35:35 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifry24896 for ; Thu, 9 Mar 2000 01:35:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA27780 for mpls@uu.net; Wed, 8 Mar 2000 20:35:29 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifry15714 for ; Thu, 9 Mar 2000 01:35:01 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifry15907 for ; Wed, 8 Mar 2000 20:34:02 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQifry24045 for ; Thu, 9 Mar 2000 01:34:01 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA00768; Wed, 8 Mar 2000 20:34:00 -0500 (EST) Message-Id: <4.2.2.20000308202412.00dc6a70@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Mar 2000 20:33:43 -0500 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: draft-ietf-mpls-te-mib-02.txt released Cc: Cheenu Srinivasan , "Arun Viswanathan (E-mail)" , "Thomas D. Nadeau (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Please be advised that we have sent version 02 of the Label Switch Router MIB (LSR MIB) to the internet drafts folks at the IETF. The aforementioned document will appear on the MPLS IETF website in a few days. In the meantime, you can pick up a copy of the latest version anonymously from the public Cisco web site at: ftp://ftp-eng.cisco.com/tnadeau/draft-ietf-mpls-lsr-mib-01.txt Regards, --Tom From owner-mpls@UU.NET Wed Mar 8 22:40:34 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01223 for ; Wed, 8 Mar 2000 22:40:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifsg09639; Thu, 9 Mar 2000 03:31:05 GMT Received: by mail-control.mail.uu.net id QQifsg08356 for mpls-outgoing; Thu, 9 Mar 2000 03:30:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifsg08350 for ; Thu, 9 Mar 2000 03:30:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifsg23865 for ; Wed, 8 Mar 2000 22:30:36 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifsg09197 for ; Thu, 9 Mar 2000 03:30:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA04631 for mpls@uu.net; Wed, 8 Mar 2000 22:30:34 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifsg08340 for ; Thu, 9 Mar 2000 03:30:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifsg23812 for ; Wed, 8 Mar 2000 22:30:05 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQifsg27366 for ; Thu, 9 Mar 2000 03:30:05 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA05889; Wed, 8 Mar 2000 22:30:03 -0500 (EST) Message-Id: <4.2.2.20000308222922.00db7c70@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Mar 2000 22:29:31 -0500 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: draft-ietf-mpls-te-mib-02.txt released Cc: Cheenu Srinivasan , "Arun Viswanathan (E-mail)" , "Thomas D. Nadeau (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Please be advised that we have sent version 02 of the Label Switch Router MIB (LSR MIB) to the internet drafts folks at the IETF. The aforementioned document will appear on the MPLS IETF website in a few days. In the meantime, you can pick up a copy of the latest version anonymously from the public Cisco web site at: ftp://ftp-eng.cisco.com/tnadeau/draft-ietf-mpls-lsr-mib-02.txt Regards, --Tom From owner-mpls@UU.NET Thu Mar 9 07:00:14 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05113 for ; Thu, 9 Mar 2000 07:00:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiftn16582; Thu, 9 Mar 2000 11:58:38 GMT Received: by mail-control.mail.uu.net id QQiftn04969 for mpls-outgoing; Thu, 9 Mar 2000 11:58:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiftn04964 for ; Thu, 9 Mar 2000 11:58:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiftn06499 for ; Thu, 9 Mar 2000 06:57:56 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQiftn01171 for ; Thu, 9 Mar 2000 11:57:55 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Thu, 9 Mar 2000 05:57:44 -0600 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GHMXC8A5; Thu, 9 Mar 2000 06:57:29 -0500 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FLDFGWDD; Thu, 9 Mar 2000 06:57:30 -0500 Message-ID: <38C79149.7894229E@americasm01.nt.com> Date: Thu, 09 Mar 2000 06:55:53 -0500 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Gupta CC: mpls Subject: Re: Admission Control and Policing in CR-LDP References: <000801bf85b9$240f7520$100d85a5@dti.daewoo.co.kr> <38C3CC19.D3110431@americasm01.nt.com> <001701bf8835$de3dcea0$100d85a5@dti.daewoo.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Santosh: Sorry to be slow in responding. See my embedded comments. - Philip Santosh Gupta wrote: > > I understand your question to be: > > How do I determine the traffic parameters > > to use for my constraint-routed LSP? > > (If I understand your question correctly, > > then the fact that you are signalling with > > CR-LDP is unimportant, the same question comes > > up with RSVP) > > > > The answer is typically related to how your box > > knows to set up the LSP in the first case. > > For example, your box might be configured to > > set up an LSP for this non-MPLS traffic. > > In this case, the traffic parameters would be > > configured too. > Non - MPLS traffic can be Differentiated or Integrated. For the > Differentiated case, the box would know as to what parameters it should use > to form the LSP according to SLA. But for the Integrated signallling, it > should recv a request and then make the LSP.But there is no such feature in > LDP to receive such requests and handle them. > > This feature is required if peer in the other domain is say RSVP aware. For > that the box should be able to receive requests and form the LSPs > accordingly. How does the LER in my domain handle such traffic and requests? > > I have a little confusion here . Are the terms differentiated and Integrated > Signalling specific to RSVP or they are genaral terms and they are to be > supported in all the protocols like RSVP/LDP. There is no such mention of > two different signalling in LDP drafts. Integrated Services is an approach to adding QoS capabilities to the Internet. Classical RSVP is a protocol that was developed to support Integrated Services. Differentiated Services is a different approach to adding QoS capabilities to the Internet. Diff-Serv does not have an associated signalling protocol. RSVP was later extended to also do MPLS signalling. The extension is called RSVP-TE. LDP and CR-LDP are two other protocols for MPLS signalling. These protocols were developed expressly for MPLS signalling. The QoS parameters in CR-LDP are modelled on QoS signalling for ATM, rather than the intserv model. If I understand you correctly, then one way to do what you want to do is to map an RSVP session into a LSP signalled using CR-LDP. In this case, you need to map the intserv QoS specification into the CR-LDP QoS parameters. Though I am not an expert in this area, I understand that it is possible to do this. However, depending on how many flows you expect to handle, you may find that this solution is not particularly scalable. - Philip From owner-mpls@UU.NET Thu Mar 9 08:52:12 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08431 for ; Thu, 9 Mar 2000 08:52:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiftu27478; Thu, 9 Mar 2000 13:41:43 GMT Received: by mail-control.mail.uu.net id QQiftu26461 for mpls-outgoing; Thu, 9 Mar 2000 13:41:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiftu26418 for ; Thu, 9 Mar 2000 13:41:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiftu01662 for ; Thu, 9 Mar 2000 08:41:01 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiftu26902 for ; Thu, 9 Mar 2000 13:41:00 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA04344 for mpls@uu.net; Thu, 9 Mar 2000 08:40:59 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiftu26371 for ; Thu, 9 Mar 2000 13:40:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiftu01606 for ; Thu, 9 Mar 2000 08:40:38 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQiftu13247 for ; Thu, 9 Mar 2000 13:40:37 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA26459; Thu, 9 Mar 2000 08:40:36 -0500 (EST) Message-Id: <4.2.2.20000309083817.00dba690@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 09 Mar 2000 08:38:40 -0500 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: draft-ietf-mpls-lsr-mib-02.txt released Cc: Cheenu Srinivasan , "Arun Viswanathan (E-mail)" , "Thomas D. Nadeau (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk [Sorry about the typos. It was late!] Please be advised that we have sent version 02 of the Label Switch Router MIB (LSR MIB) to the internet drafts folks at the IETF. The aforementioned document will appear on the MPLS IETF website in a few days. In the meantime, you can pick up a copy of the latest version anonymously from the public Cisco web site at: ftp://ftp-eng.cisco.com/tnadeau/draft-ietf-mpls-lsr-mib-02.txt Regards, --Tom From owner-mpls@UU.NET Thu Mar 9 10:29:42 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08497 for ; Thu, 9 Mar 2000 10:29:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifub20750; Thu, 9 Mar 2000 15:27:49 GMT Received: by mail-control.mail.uu.net id QQifub18295 for mpls-outgoing; Thu, 9 Mar 2000 15:27:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifub18286 for ; Thu, 9 Mar 2000 15:27:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifub00013 for ; Thu, 9 Mar 2000 10:26:40 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifub19886 for ; Thu, 9 Mar 2000 15:26:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA17466 for mpls@uu.net; Thu, 9 Mar 2000 10:26:38 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifub18206 for ; Thu, 9 Mar 2000 15:26:02 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifub29915 for ; Thu, 9 Mar 2000 10:25:40 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifub19365 for ; Thu, 9 Mar 2000 15:25:39 GMT Received: from rschmitt-nt (ch2-dhcp134-243.cisco.com [161.44.134.243]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA17265; Thu, 9 Mar 2000 10:25:38 -0500 (EST) Message-Id: <4.2.0.58.20000309094259.00a1e570@pilgrim.cisco.com> X-Sender: rschmitt@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 09 Mar 2000 10:28:46 -0800 To: mpls@UU.NET From: Rob Schmitt Cc: rschmitt@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I raised an issue yesterday with regards to an INDEX set that is common to most of the tables in the LDP-MIB. Inspection shows that the subset INDEX sequence of { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId } appears in all of these tables. I argued that the third element, namely 'mplsLdpPeerLdpId' is extraneous as a row selector, since the first two elements are sufficient. During earlier revisions of the MIB a fourth element temporarily appeared, namely 'mplsLdpPeerLdpIndex'. While we argued successfully to have this removed, we had acquiesed in accepting 'mplsLdpPeerLdpId', as a 'not necessary but desirable' INDEX element. The authors correctly reminded me of this; sorry for the temporary lapse in brain-wave output. :) /rs @ { mplsLdpEntityPeerTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId } > > @ { mplsLdpSessionTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId } > > @ { mplsLdpHelloAdjacencyTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpHelloAdjacencyIndex } > > @ { mplsLdpAtmSessionTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpSessionAtmLabelRangeLowerBoundVpi, > @ > { mplsLdpFrameRelaySessionTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpFrSessionMinDlci } > @ > { mplsLdpSessionPeerAddressTable } > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpSessionPeerAddressIndex } From owner-mpls@UU.NET Thu Mar 9 10:48:36 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14590 for ; Thu, 9 Mar 2000 10:48:35 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifud04261; Thu, 9 Mar 2000 15:47:07 GMT Received: by mail-control.mail.uu.net id QQifud19316 for mpls-outgoing; Thu, 9 Mar 2000 15:46:35 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifud19276 for ; Thu, 9 Mar 2000 15:46:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifud19712 for ; Thu, 9 Mar 2000 10:46:08 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQifud03418 for ; Thu, 9 Mar 2000 15:46:08 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA02003 for ; Thu, 9 Mar 2000 08:10:52 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA03145 for mpls@uu.net; Thu, 9 Mar 2000 10:46:06 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiftd11607 for ; Thu, 9 Mar 2000 09:29:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiftd15464 for ; Thu, 9 Mar 2000 04:29:42 -0500 (EST) Received: from ficon-tech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [12.10.198.190]) id QQiftd29574 for ; Thu, 9 Mar 2000 09:29:30 GMT Received: from ficon-tech.com (jkochar.india.ficon-tech.com [172.25.1.102]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id OAA94348 for ; Thu, 9 Mar 2000 14:53:43 +0530 (IST) (envelope-from jkochar@ficon-tech.com) Message-ID: <38C76D88.C6D88FE9@ficon-tech.com> Date: Thu, 09 Mar 2000 14:53:20 +0530 From: Jhilmil Kochar Organization: Ficon Technology X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: loop detection and label mapping procedures Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I am facing a small issue in the LDP draft. The LDP -06 draft talks about loop detection in label mapping message in DoD mode in the following possible ways - 1. sec 2.8.2 says that if R has detected a loop in a label mapping message it should respond to the downstream with a notification with loop detected status code and drop the label mapping message. 2. Appendix A.1.2 receive label mapping procedures indicate that the loop detected notification must be sent (LMp.3, check received attributes procedure) followed by label release message (LMp.8). 3. The notes following the same Appendix points out that the LSR "should simply release the label". What is being tried to achieve here is that the downstream LSR must realize that the mapping message it sent across created a loop and also it needs a label release message so that it can free up the resources acquired by the cross connect. The draft also does not talk about how a downstream LSR should behave on receiving a loop detected notification after having sent a mapping. Instead of sending multiple messages/ or sending one message that does not give the complete indication; the same thing can be achieved in a different way. The upstream LSR on detecting a loop in label mapping message must send a label release message only which must also carry a status tlv indicating loop detection. This serves both purpose in a single message and the downstream LSR realizes that it created a loop and it must release the resources. This approch is already followed in CRLDP draft (sec 4.3.2.2) when a release is sent with an indicative status code. regards Jhilmil -- ------------------------------ Jhilmil Kochar Ficon Technology E-mail:jkochar@ficon-tech.com Web: www.ficon-tech.com From owner-mpls@UU.NET Thu Mar 9 13:31:10 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08008 for ; Thu, 9 Mar 2000 13:31:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifuo16224; Thu, 9 Mar 2000 18:30:34 GMT Received: by mail-control.mail.uu.net id QQifuo24378 for mpls-outgoing; Thu, 9 Mar 2000 18:30:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifun24340 for ; Thu, 9 Mar 2000 18:29:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifun26536 for ; Thu, 9 Mar 2000 13:29:46 -0500 (EST) Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQifun26299 for ; Thu, 9 Mar 2000 18:29:45 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Mar 2000 10:30:20 -0800 Message-ID: From: Vijay Srinivasan To: "'mpls@uu.net'" Cc: "'swallow@cisco.com'" Subject: LDP MIB last call Date: Thu, 9 Mar 2000 10:30:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF89F5.8628AD0E" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF89F5.8628AD0E Content-Type: text/plain; charset="iso-8859-1" We would like to commence the last call for: Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) draft-ietf-mpls-ldp-mib-05.txt Last call will end on Friday, March 17. Please send your comments to the list. Regards, - Vijay ------_=_NextPart_001_01BF89F5.8628AD0E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LDP MIB last call

We would like to commence the last = call for:

Definitions of Managed Objects for the = Multiprotocol Label Switching, Label Distribution Protocol (LDP)
draft-ietf-mpls-ldp-mib-05.txt

Last call will end on Friday, March = 17.  Please send your comments to the list.

Regards,
- Vijay

------_=_NextPart_001_01BF89F5.8628AD0E-- From owner-mpls@UU.NET Thu Mar 9 13:34:22 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09224 for ; Thu, 9 Mar 2000 13:34:20 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifuo28906; Thu, 9 Mar 2000 18:33:39 GMT Received: by mail-control.mail.uu.net id QQifuo24537 for mpls-outgoing; Thu, 9 Mar 2000 18:33:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifuo24531 for ; Thu, 9 Mar 2000 18:33:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifuo12642 for ; Thu, 9 Mar 2000 13:32:45 -0500 (EST) Received: from ns2.net.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns2.net.com [134.56.3.102]) id QQifuo17673 for ; Thu, 9 Mar 2000 18:32:44 GMT Received: from isis.net.com.net.com (fremont-ns1.net.com [134.56.112.20]) by ns2.net.com (8.9.3/8.9.3) with ESMTP id KAA13968 for ; Thu, 9 Mar 2000 10:32:43 -0800 (PST) Received: from west-mail.net.com by isis.net.com.net.com (8.9.3/SMI-SVR4) id KAA23045; Thu, 9 Mar 2000 10:35:49 -0800 (PST) Received: from net.com ([134.56.103.187]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA761 for ; Thu, 9 Mar 2000 10:32:52 -0800 Message-ID: <38C7EEB8.7645429D@net.com> Date: Thu, 09 Mar 2000 10:34:32 -0800 From: Harsha Vardhan Organization: N.E.T. http://www.net.com X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS on Broadband References: <4.2.2.20000309083817.00dba690@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Can somebody give me pointers on the topic "MPLS popularity/growth/usage in the broadband world". Thanks in advance, Harsha From owner-mpls@UU.NET Thu Mar 9 14:16:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21743 for ; Thu, 9 Mar 2000 14:16:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifur14368; Thu, 9 Mar 2000 19:15:53 GMT Received: by mail-control.mail.uu.net id QQifur04868 for mpls-outgoing; Thu, 9 Mar 2000 19:15:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifuq04703 for ; Thu, 9 Mar 2000 19:14:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifuq18357 for ; Thu, 9 Mar 2000 14:14:46 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifuq13446 for ; Thu, 9 Mar 2000 19:14:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA22248 for mpls@uu.net; Thu, 9 Mar 2000 14:14:44 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifuq04663 for ; Thu, 9 Mar 2000 19:14:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifuq02861 for ; Thu, 9 Mar 2000 14:13:58 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQifuq23470 for ; Thu, 9 Mar 2000 19:13:58 GMT Received: from tnadeau-pc02 (ch2-dhcp134-171.cisco.com [161.44.134.171]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA29620; Thu, 9 Mar 2000 14:13:54 -0500 (EST) Message-Id: <4.2.2.20000309140538.00de3830@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 09 Mar 2000 14:11:44 -0500 To: Vijay Srinivasan , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: Re: LDP MIB last call Cc: "'swallow@cisco.com'" , Cheenu Srinivasan , "Arun Viswanathan (E-mail)" , "Thomas D. Nadeau (E-mail)" , rschmitt@cisco.com, jluciani@tollbridgetech.com, hans.sjostrand@etx.ericsson.se, jcucchiara@brixnet.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_13735788==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_13735788==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I still have two major objections to the current state of the LDP MIB. There are two tables: the LIB and the FEC tables, which I and the authors of the TE/LSR MIBs would like removed. Rob Schmitt also requested that these tables be removed prior to version -05 of the MIB. These tables are at least in part, redundant to that which is present in the LSR MIB. I have posted several messages to the mailing list requesting discussion on this issue, and both times I have not received any responses from the authors, nor have they replied to the mailing list. I will ask again for this discussion to commence. --Tom >We would like to commence the last call for: > >Definitions of Managed Objects for the Multiprotocol Label Switching, >Label Distribution Protocol (LDP) >draft-ietf-mpls-ldp-mib-05.txt > >Last call will end on Friday, March 17. Please send your comments to the >list. > >Regards, >- Vijay --=====================_13735788==_.ALT Content-Type: text/html; charset="us-ascii"
        I still have two major objections to the current
state of the LDP MIB. There are two tables: the LIB
and the FEC tables, which I and the authors of the
TE/LSR MIBs would like removed. Rob Schmitt also
requested that these tables be removed prior to
version -05 of the MIB. These tables are at least in
part, redundant to that which is present in the LSR
MIB. I have posted several messages to the mailing list
requesting discussion on this issue, and both times
I have not received any responses from the authors, nor
have they replied to the mailing list.  I will ask again for
this discussion to commence.

        --Tom



We would like to commence the last call for:

Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)
draft-ietf-mpls-ldp-mib-05.txt

Last call will end on Friday, March 17.  Please send your comments to the list.

Regards,
- Vijay
--=====================_13735788==_.ALT-- From owner-mpls@UU.NET Thu Mar 9 16:53:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05028 for ; Thu, 9 Mar 2000 16:52:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifvb05639; Thu, 9 Mar 2000 21:51:50 GMT Received: by mail-control.mail.uu.net id QQifvb00258 for mpls-outgoing; Thu, 9 Mar 2000 21:51:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifvb00249 for ; Thu, 9 Mar 2000 21:51:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifvb29541 for ; Thu, 9 Mar 2000 16:51:01 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQifvb29955 for ; Thu, 9 Mar 2000 21:51:00 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id QAA12654; Thu, 9 Mar 2000 16:46:17 -0500 Message-ID: <38C82AE2.4EE2F6B8@tellium.com> Date: Thu, 09 Mar 2000 16:51:14 -0600 From: Debanjan X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: [Fwd: I-D ACTION:draft-saha-rsvp-optical-signaling-00.txt] Content-Type: multipart/mixed; boundary="------------FE3193BA21CBAC3F61B4638A" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------FE3193BA21CBAC3F61B4638A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------FE3193BA21CBAC3F61B4638A Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from loki.ietf.org by alpha.tellium.com (SMI-8.6/SMI-SVR4) id IAA20965; Wed, 8 Mar 2000 08:00:37 -0500 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA14672 for ietf-123-outbound.05@ietf.org; Wed, 8 Mar 2000 07:45:04 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA13775 for ; Wed, 8 Mar 2000 06:31:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28518 for ; Wed, 8 Mar 2000 06:31:30 -0500 (EST) Message-Id: <200003081131.GAA28518@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@loki.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-saha-rsvp-optical-signaling-00.txt Date: Wed, 08 Mar 2000 06:31:30 -0500 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RSVP Extensions for Signaling Optical Paths Author(s) : D. Saha, B. Rajagopalan, B. Tang Filename : draft-saha-rsvp-optical-signaling-00.txt Pages : 8 Date : 07-Mar-00 This document has two objectives. First, we identify signaling requirements for setting up and maintaining Optical Switched Paths (OSPs) in mesh-connected optical networks. We then propose extensions to RSVP to satisfy some of these requirements within the context of MPLS-based traffic engineering framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saha-rsvp-optical-signaling-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-saha-rsvp-optical-signaling-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-saha-rsvp-optical-signaling-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000307114238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-saha-rsvp-optical-signaling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-saha-rsvp-optical-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000307114238.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------FE3193BA21CBAC3F61B4638A-- From owner-mpls@UU.NET Fri Mar 10 05:25:33 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08639 for ; Fri, 10 Mar 2000 05:25:31 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifwz23821; Fri, 10 Mar 2000 10:24:32 GMT Received: by mail-control.mail.uu.net id QQifwz20071 for mpls-outgoing; Fri, 10 Mar 2000 10:24:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifwz20066 for ; Fri, 10 Mar 2000 10:24:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifwz09511 for ; Fri, 10 Mar 2000 05:23:47 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifwz23080 for ; Fri, 10 Mar 2000 10:23:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA02795 for mpls@uu.net; Fri, 10 Mar 2000 05:23:45 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifwz20053 for ; Fri, 10 Mar 2000 10:23:24 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifwz09491 for ; Fri, 10 Mar 2000 05:23:17 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQifwz22591 for ; Fri, 10 Mar 2000 10:23:16 GMT Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 10:23:01 -0000 Message-ID: <37701240971DD31193970000F6CCB9F7B9AD5B@duke.datcon.co.uk> From: Piers Finlayson To: "'Thomas D. Nadeau'" , Vijay Srinivasan , "'mpls@uu.net'" Cc: "'swallow@cisco.com'" , Cheenu Srinivasan , "Arun Viswanathan (E-mail)" , rschmitt@cisco.com, jluciani@tollbridgetech.com, hans.sjostrand@etx.ericsson.se, jcucchiara@brixnet.com, Adrian Farrel Subject: RE: LDP MIB last call Date: Fri, 10 Mar 2000 10:19:54 -0000 Deferred-Delivery: Fri, 10 Mar 2000 10:23:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8A7A.9CE58456" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8A7A.9CE58456 Content-Type: text/plain; charset="iso-8859-1" Tom, There is some common information stored in both the LIB and FEC tables in the LDP MIB and in the LSR MIB. However, there is no way in the LSR MIB to associate FECs with labels. You mentioned in reply to an email from Adrian Farrel that you were working on a Packet Classifier MIB. I suspect there is some concern on the mailing list in removing the LIB and FEC tables from the LDP MIB before seeing the Packet Classifier MIB - we certainly have this concern. Is the Packet Classifier MIB nearing completion? If not, could you go into some more detail on exactly what this MIB will contain? Thanks, Piers --------------------------------------------------------- Piers Finlayson ATM, MPLS and Telecoms Group Data Connection Ltd. Tel: +44 20 8366 1177 Fax: +44 20 8363 4478 Email: pdf@datcon.co.uk Web: http://www.datcon.co.uk --------------------------------------------------------- -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thursday, March 09, 2000 7:12 PM To: Vijay Srinivasan; 'mpls@uu.net' Cc: 'swallow@cisco.com'; Cheenu Srinivasan; Arun Viswanathan (E-mail); Thomas D. Nadeau (E-mail); rschmitt@cisco.com; jluciani@tollbridgetech.com; hans.sjostrand@etx.ericsson.se; jcucchiara@brixnet.com Subject: Re: LDP MIB last call I still have two major objections to the current state of the LDP MIB. There are two tables: the LIB and the FEC tables, which I and the authors of the TE/LSR MIBs would like removed. Rob Schmitt also requested that these tables be removed prior to version -05 of the MIB. These tables are at least in part, redundant to that which is present in the LSR MIB. I have posted several messages to the mailing list requesting discussion on this issue, and both times I have not received any responses from the authors, nor have they replied to the mailing list. I will ask again for this discussion to commence. --Tom We would like to commence the last call for: Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) draft-ietf-mpls-ldp-mib-05.txt Last call will end on Friday, March 17. Please send your comments to the list. Regards, - Vijay ------_=_NextPart_001_01BF8A7A.9CE58456 Content-Type: text/html; charset="iso-8859-1"
Tom,
 
There is some common information stored in both the LIB and FEC tables in the LDP MIB and in the LSR MIB.  However, there is no way in the LSR MIB to associate FECs with labels.
 
You mentioned in reply to an email from Adrian Farrel that you were working on a Packet Classifier MIB.  I suspect there is some concern on the mailing list in removing the LIB and FEC tables from the LDP MIB before seeing the Packet Classifier MIB - we certainly have this concern.  Is the Packet Classifier MIB nearing completion?  If not, could you go into some more detail on exactly what this MIB will contain?
 
Thanks,
Piers

---------------------------------------------------------
Piers Finlayson

ATM, MPLS and Telecoms Group
Data Connection Ltd.

Tel:   +44 20 8366 1177     Fax: +44 20 8363 4478
Email: pdf@datcon.co.uk     Web: http://www.datcon.co.uk
---------------------------------------------------------

-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Thursday, March 09, 2000 7:12 PM
To: Vijay Srinivasan; 'mpls@uu.net'
Cc: 'swallow@cisco.com'; Cheenu Srinivasan; Arun Viswanathan (E-mail); Thomas D. Nadeau (E-mail); rschmitt@cisco.com; jluciani@tollbridgetech.com; hans.sjostrand@etx.ericsson.se; jcucchiara@brixnet.com
Subject: Re: LDP MIB last call


        I still have two major objections to the current
state of the LDP MIB. There are two tables: the LIB
and the FEC tables, which I and the authors of the
TE/LSR MIBs would like removed. Rob Schmitt also
requested that these tables be removed prior to
version -05 of the MIB. These tables are at least in
part, redundant to that which is present in the LSR
MIB. I have posted several messages to the mailing list
requesting discussion on this issue, and both times
I have not received any responses from the authors, nor
have they replied to the mailing list.  I will ask again for
this discussion to commence.

        --Tom



We would like to commence the last call for:

Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)
draft-ietf-mpls-ldp-mib-05.txt

Last call will end on Friday, March 17.  Please send your comments to the list.

Regards,
- Vijay
------_=_NextPart_001_01BF8A7A.9CE58456-- From owner-mpls@UU.NET Fri Mar 10 05:56:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17713 for ; Fri, 10 Mar 2000 05:56:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifxb18353; Fri, 10 Mar 2000 10:55:45 GMT Received: by mail-control.mail.uu.net id QQifxb21481 for mpls-outgoing; Fri, 10 Mar 2000 10:55:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifxb21476 for ; Fri, 10 Mar 2000 10:55:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifxb11195 for ; Fri, 10 Mar 2000 05:55:12 -0500 (EST) Received: from crid.u-bourgogne.fr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: crid.u-bourgogne.fr [192.134.59.59]) id QQifxb18198 for ; Fri, 10 Mar 2000 10:55:10 GMT Received: from maroc.crid.u-bourgogne.fr (maroc [192.168.1.12]) by crid.u-bourgogne.fr (8.9.3/8.9.3) with ESMTP id LAA27373 for ; Fri, 10 Mar 2000 11:55:29 +0100 (MET) Received: from maroc (maroc [192.168.1.12]) by maroc.crid.u-bourgogne.fr (8.9.1b+Sun/8.9.1) with SMTP id LAA08473 for ; Fri, 10 Mar 2000 11:50:37 GMT Message-Id: <200003101150.LAA08473@maroc.crid.u-bourgogne.fr> Date: Fri, 10 Mar 2000 11:50:37 +0000 (WET) From: Zouhair ECHCHELH Reply-To: Zouhair ECHCHELH Subject: Any simulation programme with Qnap To: mpls@UU.NET MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: IdlCyqssG6uggUbqmy2vqg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id FAA17713 Hi, There is any program simualtion model with QNAP for the MPLS vc-merging. Zouhair ECHCHELH E-mail: ze@crid.u-bourgogne.fr Adresse: Université de Bourgogne Tél : (33)80395882/17 Laboratoire LIRSIA Fax : (33)80395887 Faculté des Sciences Mirande 9, allée Alain Savary B.P. 47870 21078 DIJON CEDEX FRANCE From owner-mpls@UU.NET Fri Mar 10 06:23:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27139 for ; Fri, 10 Mar 2000 06:23:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifxd01243; Fri, 10 Mar 2000 11:22:27 GMT Received: by mail-control.mail.uu.net id QQifxd00929 for mpls-outgoing; Fri, 10 Mar 2000 11:22:04 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifxd00868 for ; Fri, 10 Mar 2000 11:21:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifxd00582; Fri, 10 Mar 2000 06:21:35 -0500 (EST) Received: from research.gate.nec.co.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: research.gate.nec.co.jp [202.247.6.217]) id QQifxd06136; Fri, 10 Mar 2000 11:21:34 GMT Received: from tomato.nwk.cl.nec.co.jp (IDENT:iewzoKu/o4iRATVQy9Cpo23Aungw+mfr@tomato.nwk.cl.nec.co.jp [10.56.32.1]) by research.gate.nec.co.jp (8.9.3+3.2W/000201) with ESMTP id UAA25395; Fri, 10 Mar 2000 20:21:29 +0900 (JST) Received: from tea.nwk.cl.nec.co.jp by tomato.nwk.cl.nec.co.jp (8.9.3/NWKM19990405) with ESMTP id UAA29993; Fri, 10 Mar 2000 20:21:29 +0900 (JST) Received: from iwata-pc2 (iwata-pc2.nwk.cl.nec.co.jp [10.56.32.77]) by tea.nwk.cl.nec.co.jp (8.9.0/3.7W) with ESMTP id UAA07553; Fri, 10 Mar 2000 20:21:29 +0900 (JST) Message-Id: <4.2.0.58.J.20000310201953.00a51430@tea.nwk.cl.nec.co.jp> X-Sender: iwata@tea.nwk.cl.nec.co.jp Reply-To: iwata@ccm.CL.nec.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 10 Mar 2000 20:24:34 +0900 To: ospf@discuss.microsoft.com, mpls@UU.NET, te-wg@UU.NET From: Atsushi Iwata Subject: Internet Draft Submission Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, all I'm Atsushi Iwata in NEC Corporation. We submitted the following internet-draft for extension of OSPF. We would appreciate if you could give us any comments or suggestions Just for your information. --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Traffic Engineering Extensions to OSPF Summary LSA Author(s) : N. Fujita, A. Iwata Filename : draft-fujita-ospf-te-summary-00.txt Pages : 6 Date : 07-Mar-00 Various Traffic Engineering extensions for OSPF have been proposed in [KATZ, OSPFEXT] and others. However, these are basically applicable only to intra-area Traffic Engineering since they do not support inter-area advertisements of the resource information. This draft proposes a new scheme for advertising the summarized resource information for Traffic Engineering outside the area. It also specifies a new LSA to achieve this advertisement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fujita-ospf-te-summary-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fujita-ospf-te-summary-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fujita-ospf-te-summary-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20000307114301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fujita-ospf-te-summary-00.txt ---------------------------------------------------------------- Atsushi Iwata Assistant Manager Network System TG, C&C Media Research Labs, NEC Corporation 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555 TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 E-mail: iwata@ccm.CL.nec.co.jp From owner-mpls@UU.NET Fri Mar 10 06:30:30 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29589 for ; Fri, 10 Mar 2000 06:30:30 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifxd10953; Fri, 10 Mar 2000 11:29:55 GMT Received: by mail-control.mail.uu.net id QQifxd01333 for mpls-outgoing; Fri, 10 Mar 2000 11:29:37 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifxd01328 for ; Fri, 10 Mar 2000 11:29:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifxd12846 for ; Fri, 10 Mar 2000 06:29:07 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifxd04443 for ; Fri, 10 Mar 2000 11:29:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA05673 for mpls@uu.net; Fri, 10 Mar 2000 06:29:05 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifxd01301 for ; Fri, 10 Mar 2000 11:28:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifxd00899; Fri, 10 Mar 2000 06:28:16 -0500 (EST) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQifxd10029; Fri, 10 Mar 2000 11:28:15 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28493; Fri, 10 Mar 2000 06:28:14 -0500 (EST) Message-Id: <200003101128.GAA28493@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, te-wg@UU.NET, policy@raleigh.ibm.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wright-policy-mpls-00.txt Date: Fri, 10 Mar 2000 06:28:14 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Policy Enabled MPLS Author(s) : S. Wright, S. Herzog, R. Jaeger Filename : draft-wright-policy-mpls-00.txt Pages : 16 Date : 09-Mar-00 This memo provides a brief overview of MPLS networks and policy- based network architectures. It proposes that MPLS networks be Policy-Enabled in order to facilitate easier administration. To facilitate further discussion, an Intra-net example of a policy- based MPLS network architecture is described. Example policies applicable to the MPLS network are discussed. A scenario of operation example is provided to illustrate some of the dynamics associated with Policy-Enabled MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wright-policy-mpls-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wright-policy-mpls-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-wright-policy-mpls-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000309140035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wright-policy-mpls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-wright-policy-mpls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309140035.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Mar 10 06:31:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00259 for ; Fri, 10 Mar 2000 06:31:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifxe05916; Fri, 10 Mar 2000 11:31:11 GMT Received: by mail-control.mail.uu.net id QQifxe01419 for mpls-outgoing; Fri, 10 Mar 2000 11:30:44 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifxe01410 for ; Fri, 10 Mar 2000 11:30:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifxe01075 for ; Fri, 10 Mar 2000 06:30:28 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifxe05321 for ; Fri, 10 Mar 2000 11:30:27 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA05803 for mpls@uu.net; Fri, 10 Mar 2000 06:30:26 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifxe01391 for ; Fri, 10 Mar 2000 11:30:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifxd12869 for ; Fri, 10 Mar 2000 06:29:44 -0500 (EST) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQifxd10735 for ; Fri, 10 Mar 2000 11:29:44 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29183; Fri, 10 Mar 2000 06:29:43 -0500 (EST) Message-Id: <200003101129.GAA29183@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsr-mib-02.txt Date: Fri, 10 Mar 2000 06:29:43 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Label Switch Router Management Information Base Using SMIv2 Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-lsr-mib-02.txt Pages : 91 Date : 09-Mar-00 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling a Multi-Protocol Label Switching (MPLS) [MPLSArch, MPLSFW] Label Switch Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsr-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsr-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000309140319.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsr-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsr-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309140319.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Mar 10 06:31:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00284 for ; Fri, 10 Mar 2000 06:31:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifxe11985; Fri, 10 Mar 2000 11:31:20 GMT Received: by mail-control.mail.uu.net id QQifxe01422 for mpls-outgoing; Fri, 10 Mar 2000 11:30:49 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifxe01411 for ; Fri, 10 Mar 2000 11:30:40 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifxe01029 for ; Fri, 10 Mar 2000 06:30:10 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifxe05110 for ; Fri, 10 Mar 2000 11:30:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA05772 for mpls@uu.net; Fri, 10 Mar 2000 06:30:08 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifxd01339 for ; Fri, 10 Mar 2000 11:29:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifxd00937 for ; Fri, 10 Mar 2000 06:29:38 -0500 (EST) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQifxd10683 for ; Fri, 10 Mar 2000 11:29:38 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29140; Fri, 10 Mar 2000 06:29:37 -0500 (EST) Message-Id: <200003101129.GAA29140@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-rsvp-lsp-tunnel-05.txt Date: Fri, 10 Mar 2000 06:29:37 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP for LSP Tunnels Author(s) : D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow,V. Srinivasan Filename : draft-ietf-mpls-rsvp-lsp-tunnel-05.txt Pages : 53 Date : 09-Mar-00 This document describes the use of RSVP, including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS. Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in [3]. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-lsp-tunnel-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000309140308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-lsp-tunnel-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309140308.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Mar 10 07:28:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19542 for ; Fri, 10 Mar 2000 07:28:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifxh09456; Fri, 10 Mar 2000 12:24:05 GMT Received: by mail-control.mail.uu.net id QQifxh12702 for mpls-outgoing; Fri, 10 Mar 2000 12:23:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifxh12694 for ; Fri, 10 Mar 2000 12:23:37 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifxh04688 for ; Fri, 10 Mar 2000 07:23:15 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifxh04975 for ; Fri, 10 Mar 2000 12:23:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA09217 for mpls@uu.net; Fri, 10 Mar 2000 07:23:14 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifxh12655 for ; Fri, 10 Mar 2000 12:22:48 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifxh16401 for ; Fri, 10 Mar 2000 07:21:09 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQifxh07613 for ; Fri, 10 Mar 2000 12:21:08 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA18129; Fri, 10 Mar 2000 07:21:04 -0500 (EST) Message-Id: <4.2.2.20000310071756.00df1b60@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 10 Mar 2000 07:18:09 -0500 To: Vijay Srinivasan , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: LDP MIB last call Cc: "'swallow@cisco.com'" , Cheenu Srinivasan , "Arun Viswanathan (E-mail)" , "Thomas D. Nadeau (E-mail)" , rschmitt@cisco.com, jluciani@tollbridgetech.com, hans.sjostrand@etx.ericsson.se, jcucchiara@brixnet.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_42481979==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_42481979==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I still have two major objections to the current state of the LDP MIB. There are two tables: the LIB and the FEC tables, which I and the authors of the TE/LSR MIBs would like removed. Rob Schmitt also requested that these tables be removed prior to version -05 of the MIB. These tables are at least in part, redundant to that which is present in the LSR MIB. I have posted several messages to the mailing list requesting discussion on this issue, and both times I have not received any responses from the authors, nor have they replied to the mailing list. I will ask again for this discussion to commence. --Tom >We would like to commence the last call for: > >Definitions of Managed Objects for the Multiprotocol Label Switching, >Label Distribution Protocol (LDP) >draft-ietf-mpls-ldp-mib-05.txt > >Last call will end on Friday, March 17. Please send your comments to the >list. > >Regards, >- Vijay --=====================_42481979==_.ALT Content-Type: text/html; charset="us-ascii"
        I still have two major objections to the current
state of the LDP MIB. There are two tables: the LIB
and the FEC tables, which I and the authors of the
TE/LSR MIBs would like removed. Rob Schmitt also
requested that these tables be removed prior to
version -05 of the MIB. These tables are at least in
part, redundant to that which is present in the LSR
MIB. I have posted several messages to the mailing list
requesting discussion on this issue, and both times
I have not received any responses from the authors, nor
have they replied to the mailing list.  I will ask again for
this discussion to commence.

        --Tom



We would like to commence the last call for:

Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)
draft-ietf-mpls-ldp-mib-05.txt

Last call will end on Friday, March 17.  Please send your comments to the list.

Regards,
- Vijay
--=====================_42481979==_.ALT-- From owner-mpls@UU.NET Fri Mar 10 07:37:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22441 for ; Fri, 10 Mar 2000 07:37:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifxi12358; Fri, 10 Mar 2000 12:36:52 GMT Received: by mail-control.mail.uu.net id QQifxi13391 for mpls-outgoing; Fri, 10 Mar 2000 12:36:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifxi13385 for ; Fri, 10 Mar 2000 12:36:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifxi05575 for ; Fri, 10 Mar 2000 07:36:03 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifxi11807 for ; Fri, 10 Mar 2000 12:36:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA10290 for mpls@uu.net; Fri, 10 Mar 2000 07:35:58 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifxi13268 for ; Fri, 10 Mar 2000 12:35:36 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifxi17534; Fri, 10 Mar 2000 07:35:18 -0500 (EST) Received: from beamer.mchh.siemens.de by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQifxi15408; Fri, 10 Mar 2000 12:35:17 GMT Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA15304; Fri, 10 Mar 2000 13:34:37 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([218.1.68.147]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA23895; Fri, 10 Mar 2000 13:32:34 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2448.0) id ; Fri, 10 Mar 2000 13:36:03 +0100 Message-ID: From: Hummel Heinrich To: mpls@UU.NET, te-wg@UU.NET Subject: Internet Draft Submission: Orchestrally Conducted Traffic Date: Fri, 10 Mar 2000 13:36:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I emailed draft-hummel-te-oct-01.txt to internet-drafts@ietf.org. I also applied for a time-slot in the TE-WG for presenting this traffic balancing concept in Adelaide. I appreciate any comment on this topic. Regards Heinrich Hummel Siemens AG heinrich.hummel@icn.siemens.de From owner-mpls@UU.NET Fri Mar 10 10:06:33 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12761 for ; Fri, 10 Mar 2000 10:06:31 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifxr06404; Fri, 10 Mar 2000 14:58:27 GMT Received: by mail-control.mail.uu.net id QQifxr05590 for mpls-outgoing; Fri, 10 Mar 2000 14:58:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifxr05585 for ; Fri, 10 Mar 2000 14:57:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifxr01842 for ; Fri, 10 Mar 2000 09:57:09 -0500 (EST) From: erosen@cisco.com Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQifxr05561 for ; Fri, 10 Mar 2000 14:57:08 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA05868 for ; Fri, 10 Mar 2000 06:57:06 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA06347 for ; Fri, 10 Mar 2000 09:57:06 -0500 (EST) Date: Fri, 10 Mar 2000 09:57:06 -0500 (EST) Message-Id: <200003101457.JAA06347@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs Prev-Resent: Fri, 10 Mar 2000 09:57:06 -0500 Prev-Resent: "mpls@uu.net " To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk From ietf-123-owner@loki.ietf.org Fri Mar 10 08: 00:44 2000 Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA12385; Fri, 10 Mar 2000 08:00:44 -0500 (EST) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id FAA03778; Fri, 10 Mar 2000 05:00:17 -0800 (PST) Received: from (loki.ietf.org [132.151.1.177]) by proxy2.cisco.com with SMTP (MailShield v1.5); Fri, 10 Mar 2000 05:00:16 -0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA27339 for ietf-123-outbound.02@ietf.org; Fri, 10 Mar 2000 07:35:05 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA26567 for ; Fri, 10 Mar 2000 06:27:22 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28113 for ; Fri, 10 Mar 2000 06:27:20 -0500 (EST) Message-Id: <200003101127.GAA28113@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rosen-rfc2547bis-00.txt Date: Fri, 10 Mar 2000 06:27:20 -0500 Sender: nsyracus@cnri.reston.va.us X-SPAM: Yes X-SPAM-REASON: Suspicious TO Address X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam X-SMTP-HELO: loki.ietf.org X-SMTP-MAIL-FROM: ietf-123-owner@loki.ietf.org X-SMAP-Received-From: outside X-SMTP-PEER-INFO: loki.ietf.org [132.151.1.177] Resent-To: mpls@uu.net Resent-Date: Fri, 10 Mar 2000 09:57:06 -0500 Resent-From: Eric Rosen --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP/MPLS VPNs Author(s) : E. Rosen, Y. Rekhter, S. Brannon et.al Filename : draft-rosen-rfc2547bis-00.txt Pages : 30 Date : 09-Mar-00 This document describes a method by which a Service Provider may use an IP backbone to provide VPNs for its customers. MPLS is used for forwarding packets over the backbone, and BGP is used for distributing routes over the backbone. The primary goal of this method is to support the case in which a client obtains IP backbone services from a Service Provider or Service Providers with which it maintains contractual relationships. The client may be an enterprise, a group of enterprises which need an extranet, an Internet Service Provider, another VPN Service Provider (even one which uses this same method to offer VPNs to clients of its own), an application service provider, etc. The method makes it very simple for the client to use the backbone services. It is also very scalable and flexible for the Service Provider, and allows the Service Provider to add value. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-rfc2547bis-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosen-rfc2547bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosen-rfc2547bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000309135853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-rfc2547bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosen-rfc2547bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309135853.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Mar 10 13:39:19 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24267 for ; Fri, 10 Mar 2000 13:39:19 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifyg19838; Fri, 10 Mar 2000 18:38:14 GMT Received: by mail-control.mail.uu.net id QQifyg19545 for mpls-outgoing; Fri, 10 Mar 2000 18:37:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifyg19540 for ; Fri, 10 Mar 2000 18:37:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifyg22860 for ; Fri, 10 Mar 2000 13:37:40 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQifyg14034 for ; Fri, 10 Mar 2000 18:37:39 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA24930 for ; Fri, 10 Mar 2000 10:37:37 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA07115 for mpls@uu.net; Fri, 10 Mar 2000 13:37:37 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifyg19408 for ; Fri, 10 Mar 2000 18:35:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifyg22644 for ; Fri, 10 Mar 2000 13:35:26 -0500 (EST) Received: from mailserver-ng.cs.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailserver-ng.cs.umbc.edu [130.85.100.230]) id QQifyg18281 for ; Fri, 10 Mar 2000 18:35:26 GMT Received: from sunserver1.cs.umbc.edu (actaeon.cs.umbc.edu [130.85.99.51]) by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with ESMTP id NAA06274 for ; Fri, 10 Mar 2000 13:35:25 -0500 (EST) Received: from localhost (magupta@localhost) by sunserver1.cs.umbc.edu (8.9.3/8.9.3) with SMTP id NAA20874 for ; Fri, 10 Mar 2000 13:35:25 -0500 (EST) X-Authentication-Warning: sunserver1.cs.umbc.edu: magupta owned process doing -bs Date: Fri, 10 Mar 2000 13:35:25 -0500 (EST) From: Manish Gupta To: mpls@UU.NET Subject: BGP Extensions for MPLS Label Distribution : Code ?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Is there any implementation/design available for the above ? Thanks Manish ------------------> http://www.mctr.umbc.edu/~magupta <------------------- From owner-mpls@UU.NET Fri Mar 10 15:18:05 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00452 for ; Fri, 10 Mar 2000 15:18:03 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifyn19990; Fri, 10 Mar 2000 20:17:19 GMT Received: by mail-control.mail.uu.net id QQifyn11676 for mpls-outgoing; Fri, 10 Mar 2000 20:17:00 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQifyn11664 for ; Fri, 10 Mar 2000 20:16:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifyn06796 for ; Fri, 10 Mar 2000 15:16:44 -0500 (EST) Received: from ariel.ecn.umkc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ariel.ecn.umkc.edu [134.193.133.67]) id QQifyn12107 for ; Fri, 10 Mar 2000 20:16:43 GMT Received: from localhost (gbrahim@localhost) by ariel.ecn.umkc.edu with ESMTP (8.8.6 (PHNE_14041)/8.7.1) id OAA04109 for ; Fri, 10 Mar 2000 14:16:42 -0600 (CST) Date: Fri, 10 Mar 2000 14:16:42 -0600 (CST) From: Ghassen Benbrahim To: mpls@UU.NET Subject: Questions in "draft-katz-yeung-ospf-traffic-01.txt" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello everybody, I have 2 questions in the draft "Traffic Engineering Extension to OSPF" (draft-katz-yeung-ospf-traffic-01.txt) : * Question 1: This question relates to the metric sub-TLV section 2.5.5 (Traffic Engineering Metric) type = 5 length = 4 octets What is in the value field ? is it the administrative weight ? Also I do not see how it (this sub-TLV) relates to the other metric fields that have been defined in sections 2.5.6, 2.5.7. etc * Question 2: relates to the 8 priority levels section 2.5.8 are these priorities the same as the one expressed by the EXP field in the MPLS label.? If no, would you please provide with more explanation.. Any clarification on these points will be greately appreciated. Thanks Sincerely, --Ben From owner-mpls@UU.NET Fri Mar 10 17:46:40 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22144 for ; Fri, 10 Mar 2000 17:46:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifyx06249; Fri, 10 Mar 2000 22:46:13 GMT Received: by mail-control.mail.uu.net id QQifyx06528 for mpls-outgoing; Fri, 10 Mar 2000 22:45:50 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifyx06519 for ; Fri, 10 Mar 2000 22:45:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifyx01351 for ; Fri, 10 Mar 2000 17:45:32 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifyx14806 for ; Fri, 10 Mar 2000 22:45:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA29221 for mpls@uu.net; Fri, 10 Mar 2000 17:45:30 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifyx06504 for ; Fri, 10 Mar 2000 22:45:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifyw01215 for ; Fri, 10 Mar 2000 17:44:12 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQifyw14111 for ; Fri, 10 Mar 2000 22:44:11 GMT Received: from stripedbass.cisco.com (stripedbass.cisco.com [161.44.134.83]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA11979; Fri, 10 Mar 2000 17:44:08 -0500 (EST) Received: (tnadeau@localhost) by stripedbass.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id RAA02360; Fri, 10 Mar 2000 17:44:07 -0500 (EST) Date: Fri, 10 Mar 2000 17:44:07 -0500 (EST) Message-Id: <200003102244.RAA02360@stripedbass.cisco.com> From: "Thomas D. Nadeau" To: mpls@UU.NET CC: csrinivasan@tachion.com, arun@force10networks.com Subject: draft-nadeau-mpls-packet-classifier-mib-00.txt Sender: owner-mpls@UU.NET Precedence: bulk We have posted the initial version of the MPLS Packet Classifier MIB to the IETF secretat. It should be available shortly. In the meantime you can pick it up anonymously from the Cisco Engineering Website: ftp://ftp-eng.cisco.com/tnadeau/draft-nadeau-mpls-packet-classifier-mib-00.txt Regards, Tom Nadeau Cheenu Srinivasan Arun Viswanathan From owner-mpls@UU.NET Fri Mar 10 18:00:29 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26966 for ; Fri, 10 Mar 2000 18:00:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifyx21696; Fri, 10 Mar 2000 22:58:02 GMT Received: by mail-control.mail.uu.net id QQifyx07065 for mpls-outgoing; Fri, 10 Mar 2000 22:57:43 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifyx07060 for ; Fri, 10 Mar 2000 22:57:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifyx02356 for ; Fri, 10 Mar 2000 17:57:19 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQifyx21186 for ; Fri, 10 Mar 2000 22:57:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA00703 for mpls@uu.net; Fri, 10 Mar 2000 17:57:08 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQifyx07045 for ; Fri, 10 Mar 2000 22:56:49 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifyx26224 for ; Fri, 10 Mar 2000 17:56:34 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQifyx20804 for ; Fri, 10 Mar 2000 22:56:34 GMT Received: from tnadeau-pc02 (ch2-dhcp134-171.cisco.com [161.44.134.171]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA12850; Fri, 10 Mar 2000 17:56:33 -0500 (EST) Message-Id: <4.2.2.20000310174316.00ddcc90@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 10 Mar 2000 17:53:50 -0500 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: draft-ietf-mpls-te-mib-03.txt Cc: "Arun Viswanathan (E-mail)" , "Thomas D. Nadeau (E-mail)" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8319180==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_8319180==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, We have published version 03 of The MPLS Traffic Engineering Management Information Base Using SMIv2 (draft-ietf-mpls-te-mib-03.txt). You may obtain the file from the Cisco Engineering web site anonymously at: ftp://ftp-eng.cisco.com/tnadeau/draft-ietf-mpls-te-mib-03.txt We are not sure if the submission was made in time for the IETF Secretat, so ftp-eng maybe the only place to get a copy of it until they open the doors for submissions again. For the record, we submitted the document at 5:05PM EST. --Tom --=====================_8319180==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

        We have published version 03 of The MPLS Traffic Engineering
Management Information Base Using SMIv2 (draft-ietf-mpls-te-mib-03.txt).
You may obtain the file from the Cisco Engineering web site anonymously
at:

        ftp://ftp-eng.cisco.com/tnadeau/draft-ietf-mpls-te-mib-03.txt

        We are not sure if the submission was made in time for the IETF Secretat,
so ftp-eng maybe the only place to get a copy of it until they open the
doors for submissions again. For the record, we submitted the document
at 5:05PM EST.

        --Tom

 --=====================_8319180==_.ALT-- From owner-mpls@UU.NET Fri Mar 10 19:43:57 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01014 for ; Fri, 10 Mar 2000 19:43:57 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifze07949; Sat, 11 Mar 2000 00:42:54 GMT Received: by mail-control.mail.uu.net id QQifze27616 for mpls-outgoing; Sat, 11 Mar 2000 00:42:33 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQifze27611 for ; Sat, 11 Mar 2000 00:42:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifze11473 for ; Fri, 10 Mar 2000 19:42:15 -0500 (EST) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQifze07508 for ; Sat, 11 Mar 2000 00:42:15 GMT Received: from fuinar.juniper.net (fuinar.juniper.net [207.79.80.140]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id QAA09631; Fri, 10 Mar 2000 16:42:14 -0800 (PST) Received: (from qv@localhost) by fuinar.juniper.net (8.8.8/8.7.3) id QAA09816; Fri, 10 Mar 2000 16:42:14 -0800 (PST) From: Quaizar Vohra Message-Id: <200003110042.QAA09816@fuinar.juniper.net> Subject: Re: Questions in "draft-katz-yeung-ospf-traffic-01.txt" In-Reply-To: from Ghassen Benbrahim at "Mar 10, 2000 2:16:42 pm" To: gbrahim@ariel.ecn.umkc.edu (Ghassen Benbrahim) Date: Fri, 10 Mar 2000 16:42:14 -0800 (PST) Cc: mpls@UU.NET X-Mailer: ELM [version 2.4ME+ PL45 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Traffic engineering metric is to constrained shortest path first what a link metric is to shortest path first. It is a 32 bit integer which one assigns to the link for TE purpose, i.e. for use by constrained shortest path first or some such algorithm. Its a value a network admin assigns to a link (very similar to how a link metric is assigned in routing protocols). No the priorities are not related to the EXP field in an MPLS label. The meaning of priorities in the TE context is explained in RFC 2702 (Requirements for Traffic Engineering over MPLS). Quaizar > > > Hello everybody, > > > I have 2 questions in the draft "Traffic Engineering Extension to OSPF" > (draft-katz-yeung-ospf-traffic-01.txt) : > > * Question 1: This question relates to the metric sub-TLV > > section 2.5.5 (Traffic Engineering Metric) > > type = 5 > length = 4 octets > What is in the value field ? > > is it the administrative weight ? > > Also I do not see how it (this sub-TLV) relates to the other metric fields > that have been defined in sections 2.5.6, 2.5.7. etc > > > * Question 2: relates to the 8 priority levels > > section 2.5.8 > are these priorities the same as the one expressed by the EXP > field in the MPLS label.? > > If no, would you please provide with more explanation.. > > > Any clarification on these points will be greately appreciated. > > Thanks > > Sincerely, > > --Ben > > From owner-mpls@UU.NET Fri Mar 10 19:51:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02650 for ; Fri, 10 Mar 2000 19:51:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQifzf11622; Sat, 11 Mar 2000 00:50:05 GMT Received: by mail-control.mail.uu.net id QQifzf28011 for mpls-outgoing; Sat, 11 Mar 2000 00:49:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifzf28006 for ; Sat, 11 Mar 2000 00:49:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQifzf11776 for ; Fri, 10 Mar 2000 19:49:32 -0500 (EST) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQifzf11189 for ; Sat, 11 Mar 2000 00:49:32 GMT Received: from fuinar.juniper.net (fuinar.juniper.net [207.79.80.140]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id QAA10170; Fri, 10 Mar 2000 16:49:31 -0800 (PST) Received: (from qv@localhost) by fuinar.juniper.net (8.8.8/8.7.3) id QAA09965; Fri, 10 Mar 2000 16:49:31 -0800 (PST) From: Quaizar Vohra Message-Id: <200003110049.QAA09965@fuinar.juniper.net> Subject: Re: Questions in "draft-katz-yeung-ospf-traffic-01.txt" In-Reply-To: <200003110042.QAA09816@fuinar.juniper.net> from Quaizar Vohra at "Mar 10, 2000 4:42:14 pm" To: qv@juniper.net (Quaizar Vohra) Date: Fri, 10 Mar 2000 16:49:31 -0800 (PST) Cc: gbrahim@ariel.ecn.umkc.edu, mpls@UU.NET X-Mailer: ELM [version 2.4ME+ PL45 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Offcourse, this metric is used by CSPF (or something similar) as one of the constraints in addition to available b/w constraints, colors etc. > Traffic engineering metric is to constrained shortest path first what a > link metric is to shortest path first. It is a 32 bit integer which > one assigns to the link for TE purpose, i.e. for use by constrained > shortest path first or some such algorithm. Its a value a network > admin assigns to a link (very similar to how a link metric is > assigned in routing protocols). > > No the priorities are not related to the EXP field in an MPLS label. > The meaning of priorities in the TE context is explained in RFC 2702 > (Requirements for Traffic Engineering over MPLS). > > Quaizar > > > > > > > Hello everybody, > > > > > > I have 2 questions in the draft "Traffic Engineering Extension to OSPF" > > (draft-katz-yeung-ospf-traffic-01.txt) : > > > > * Question 1: This question relates to the metric sub-TLV > > > > section 2.5.5 (Traffic Engineering Metric) > > > > type = 5 > > length = 4 octets > > What is in the value field ? > > > > is it the administrative weight ? > > > > Also I do not see how it (this sub-TLV) relates to the other metric fields > > that have been defined in sections 2.5.6, 2.5.7. etc > > > > > > * Question 2: relates to the 8 priority levels > > > > section 2.5.8 > > are these priorities the same as the one expressed by the EXP > > field in the MPLS label.? > > > > If no, would you please provide with more explanation.. > > > > > > Any clarification on these points will be greately appreciated. > > > > Thanks > > > > Sincerely, > > > > --Ben > > > > > > From owner-mpls@UU.NET Sat Mar 11 07:23:47 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20961 for ; Sat, 11 Mar 2000 07:23:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigaz24860; Sat, 11 Mar 2000 12:17:18 GMT Received: by mail-control.mail.uu.net id QQigaz02972 for mpls-outgoing; Sat, 11 Mar 2000 12:16:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigaz02954 for ; Sat, 11 Mar 2000 12:16:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigaz23374 for ; Sat, 11 Mar 2000 07:15:16 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigaz08745 for ; Sat, 11 Mar 2000 12:15:10 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA06796 for mpls@uu.net; Sat, 11 Mar 2000 07:15:09 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigay02289 for ; Sat, 11 Mar 2000 12:14:43 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigay18663 for ; Sat, 11 Mar 2000 07:14:21 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQigay23369 for ; Sat, 11 Mar 2000 12:14:21 GMT Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Sat, 11 Mar 2000 12:14:14 -0000 Message-ID: <37701240971DD31193970000F6CCB9F7B9AD70@duke.datcon.co.uk> From: Piers Finlayson To: 'jcucchiara@brixnet.com' Cc: mpls@UU.NET, Adrian Farrel Subject: RE: I-D ACTION:draft-ietf-mpls-ldp-mib-05.txt Date: Sat, 11 Mar 2000 12:10:59 -0000 Deferred-Delivery: Sat, 11 Mar 2000 12:14:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Joan, I have reviewed your latest draft of the LDP MIB and have a few comments for you. - Section 3.6.1 describes the LDP notifications and should be expanded to cover both the mplsLdpSessionUp and Down and the mplsLdpLibUp and Down notifications. It may also be worth referencing the mplsLdpSessionUpDownTrapEnable, mplsLdpLibLspUpDownTrapEnable, mplsLdpEntityFailedInitSessionTrapEnable and mplsLdpEntityPVLimitMismatchTrapEnable objects within this section, indicating that these objects control whether the notifications are sent. - With regards to the following objects: mplsLdpEntityHopCountLoopDetection OBJECT-TYPE SYNTAX INTEGER { disabled(0), enabled(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether loop detection based on hop count is disabled or enabled for this Entity. If this object has the value of 'disabled(0)', then loop detection using hop counts is disabled. Otherwise, if this object has a value of 'enabled(1)', then loop detection based on hop counts is enabled. Also, the value of the object, 'mplsLdpLsrLoopDetectionCapable', must have the value of either: 'hopCount(3)' or 'hopCountAndPathVector(5)'." ::= { mplsLdpEntityEntry 15 } mplsLdpEntityHopCount OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of 'mplsLdpEntityHopCountLoopDetection' for this entry is 'enabled(1)', then this object represents the initial Hop Count for this Entity. If the value of 'mplsLdpEntityHopCountLoopDetection' is 'disabled(0)', then the value of this object is undefined." ::= { mplsLdpEntityEntry 16 } I think that the second object (mplsLdpEntityHopCount) should actually be the configured maximum allowable value of the Hop Count. In the LDP specification, section 3.4.4 it states that "The first LSR in the LSP(ingress for a Label Request message, egress for a Label Mapping message) should set the hop count value to 1.". Therefore this should not be configurable. Each LSR then increments this value, and the spec states "If an LSR receives a message containing a Hop Count TLV, it must check the hop count value to determine whether the hop count has exceeded the maximum allowable value.". This is the value that should be configured in the LDP MIB. The range from this object should be (1..255). Given this change, it is also possible to merge the two Hop Count objects together as follows. mplsLdpEntityHopCounterLimit OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "If the value of this object is 0 (zero), then Loop Detection using Hop Counters is disabled. If the value of this object is greater than 0 (zero) then Loop Detection using Hop Counters is enabled, and this object specifies this Entity's maximum allowable value for the Hop Count. Also, the value of the object mplsLdpLsrLoopDetectionCapable must be set to either 'hopCount(3)' or 'hopCountAndPathVector(5)' if this object has a value greater than 0 (zero)." ::= { mplsLdpEntityEntry 15 } - Typo in section 3.5.2 "... Then and only then is it save to ..." should be changed to "... Then and only then is it safe to ...". - Typo in the mplsLdpSessionUp notification description. "... changes from any state accept ..." should be "... changes from any state except ...". Cheers, Piers --------------------------------------------------------- Piers Finlayson ATM, MPLS and Telecoms Group Data Connection Ltd. Tel: +44 20 8366 1177 Fax: +44 20 8363 4478 Email: pdf@datcon.co.uk Web: http://www.datcon.co.uk --------------------------------------------------------- -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, March 07, 2000 11:30 AM To: IETF-Announce Cc: mpls@UU.NET Subject: I-D ACTION:draft-ietf-mpls-ldp-mib-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) Author(s) : J. Cucchiara, H. Sjostrand, J. Luciani Filename : draft-ietf-mpls-ldp-mib-05.txt Pages : 74 Date : 06-Mar-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-mpls@UU.NET Mon Mar 13 11:06:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02998 for ; Mon, 13 Mar 2000 11:06:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigiw14424; Mon, 13 Mar 2000 15:36:52 GMT Received: by mail-control.mail.uu.net id QQigiw03643 for mpls-outgoing; Mon, 13 Mar 2000 15:36:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigiw03638 for ; Mon, 13 Mar 2000 15:36:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigiw03876 for ; Mon, 13 Mar 2000 10:35:35 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQigiw05257 for ; Mon, 13 Mar 2000 15:35:33 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA11661 for ; Mon, 13 Mar 2000 07:35:30 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA16615 for mpls@uu.net; Mon, 13 Mar 2000 10:35:30 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQifyz16356 for ; Fri, 10 Mar 2000 23:24:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQifyz05792 for ; Fri, 10 Mar 2000 18:23:49 -0500 (EST) Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQifyz05999 for ; Fri, 10 Mar 2000 23:23:48 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id RAA03565; Fri, 10 Mar 2000 17:22:51 -0600 (CST) Received: from tellabs.com (hdqpcq2150.lisle.tellabs.com [138.111.90.150]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id RAA11488; Fri, 10 Mar 2000 17:22:52 -0600 (CST) Message-ID: <38C98351.459C5ECB@tellabs.com> Date: Fri, 10 Mar 2000 17:20:49 -0600 From: Srinivas Makam Organization: Tellabs Operations, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, ben , kowens , vsharma , kbenson , smakam , chuang , fiffi@nortelnetworks.com, bcain@baynetworks.com, jamoussi@nortelnetworks.com, landerss@nortelnetworks.com, jonweil@nortelnetworks.com, scivanlar@att.com, alchiu@att.com, vsriniva@cosinecom.com, swallow@cisco.com Subject: New IETF internet draft submitted Content-Type: multipart/mixed; boundary="------------9B0F8A70B2FC2D20FA94EF92" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------9B0F8A70B2FC2D20FA94EF92 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, We have submitted a new draft on Framework for MPLS Based Recovery to the IETF. We request the MPLS mailing list group to provide comments on the attached draft. We are planning to present this draft at the Adelaide MPLS working group meeting. Thanks Vas Makam --------------9B0F8A70B2FC2D20FA94EF92 Content-Type: text/plain; charset=iso-8859-1; name="draft-makam-mpls-recovery-frmwrk-00.txt" Content-Disposition: inline; filename="draft-makam-mpls-recovery-frmwrk-00.txt" Content-Transfer-Encoding: 8bit Internet Draft Srinivas Makam Multi-Protocol Label Switching Vishal Sharma Expiration Date: September 2000 Ken Owens Changcheng Huang Ben Mack-Crane Tellabs Fiffi Hellstrand Jon Weil Brad Cain Loa Andersson Bilel Jamoussi Nortel Networks Seyhan Civanlar Angela Chiu AT&T Labs March 2000 Framework for MPLS Based Recovery Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Multiprotocol label switching (MPLS) [1] integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switched routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling [2] [3] [4] [5] [6] support the configuration of working and recovery paths. With these objectives in mind, this document specifies a framework for MPLS based recovery. Table of Contents 1.0 Introduction 1.1 Background 1.2 Motivations for MPLS-Based Recovery 1.3 Objectives 2.0 Overview 2.1 Recovery Models 2.2 Recovery Cycles 2.3 Terminology 2.4 Abbreviations 3.0 MPLS Recovery Principles 3.1 Recovery Models 3.2 Configuration of Recovery 3.3 Scope of Recovery 3.3.1 Topology 3.3.2 Path Mapping 3.3.3 Bypass Tunnels 3.3.4 Recovery Granularity 3.3.4.1 Selective Traffic Recovery 3.3.4.2 Bundling 3.4 Fault Detection 3.5 Fault Notification 3.6 Switch Over Operation 3.6.1 Recovery Trigger 3.6.2 Recovery Action 3.7 Switch Back Operation 3.7.1 Revertive and Non-revertive Mode 3.7.2 Restoration and Notification 3.7.3 Reverting to Preferred LSP 3.8 Performance 4.0 Recovery Requirements 5.0 MPLS Recovery Options 6.0 Comparison Criteria 7.0 Security Considerations 8.0 Intellectual Property Considerations 9.0 Author's Addresses 10.0 References 1.0 Introduction This memo describes a framework for MPLS-based recovery. We provide a detailed taxonomy of recovery terminology, and discuss the motivation for, the objectives of, and the requirements for MPLS- based recovery. We outline principles for MPLS-based recovery, and also provide comparison criteria that may serve as a basis for comparing and evaluating different recovery schemes. 1.1 Background Network routing deployed today is focussed primarily on connectivity and typically supports only one class of service, the best effort class. Multi-protocol label switching, on the other hand, by integrating forwarding based on label-swapping of a link local label with network layer routing allows flexibility in the delivery of new routing services. MPLS allows for using media specific forwarding mechanisms as label swapping. This enables more sophisticated features such as quality-of-service (QoS) and traffic engineering [7] to be implemented more effectively. An important component of providing QoS, however, is the ability to transport data reliably and efficiently. Although the current routing algorithms are very robust and survivable, the amount of time they take to recover from a fault can be significant, on the order of several seconds or minutes, causing serious disruption of service for some applications in the interim. This is unacceptable to many organizations that aim to provide a highly reliable service, and thus require recovery times on the order of tens of milliseconds, as specified, for example, in the GR253 specification for SONET. Since MPLS binds packets to a route (or path) via labels and is likely to be the technology of choice in the future IP-based transport network, it is imperative that MPLS be able to provide protection and restoration of traffic. In fact, a protection priority could be used as a differentiating mechanism for premium services that require high reliability. The remainder of this document provides a framework for MPLS based recovery. 1.1 Motivation for MPLS-Based Recovery MPLS based protection of traffic (called MPLS-based Recovery) is useful for a number of reasons. The most important is its ability to increase network reliability by enabling a faster response to faults than is possible with traditional Layer 3 (or the IP layer) alone. Furthermore, a protection mechanism using could enable IP traffic to be put directly over WDM optical channels, without an intervening SONET layer, which would facilitate the construction of IP-over-WDM networks. The need for MPLS-based recovery arises because of the following: I. Layer 3 or IP rerouting may be too slow for a core MPLS network that needs to support high reliability/availability. II. Layer 0 (for example, optical layer) or Layer 1 (for example, SONET) mechanisms may be deployed in ring topologies and may not always include mesh protection. That is, layer 0 or layer 1 networks may not be deployed in topologies that meet carriers’ protection goals. III. The granularity at which the lower layers may be able to protect traffic may be too coarse for traffic that is switched using MPLS-based mechanisms. IV. Layer 0 or Layer 1 mechanisms may have no visibility into higher layer operations. Thus, while they may provide, for example, link protection, they cannot easily provide node protection. Furthermore there is a need for open standards. V. Establishing interoperability of protection mechanisms between routers/LSRs from different vendors in IP or MPLS networks is urgently required to enable the adoption of MPLS as a viable core transport and traffic engineering technology. 1.3 Objectives/Goals We lay down the following objectives for MPLS-based recovery. I. MPLS-based recovery mechanisms should facilitate fast (10’s of ms) recovery times. II. MPLS-based recovery should maximize network reliability and availability. III. MPLS-based recovery techniques should be applicable for protection of traffic at various granularities. For example, it should be possible to specify MPLS-based recovery for a portion of the traffic on an individual path, for all traffic on an individual path, or for all traffic on a group of paths. IV. MPLS-based recovery techniques may be applicable for an entire end-to-end path or for segments of an end-to-end path. V. MPLS-based recovery actions should not adversely affect other network operations. VI. MPLS-based recovery actions in one MPLS protection domain (defined in Section 2.2) should not affect the recovery actions in other MPLS protection domains. VII. MPLS-based recovery mechanisms should be able to take into consideration the recovery actions of other layers. VIII. MPLS-based recovery actions should avoid network-layering violations. That is, defects in MPLS-based mechanisms should not trigger lower layer protection switching. IX. MPLS-based recovery mechanisms should minimize the loss of data and packet reordering during recovery operations. (The current MPLS specification has itself no explicit requirement on reordering). X. MPLS-based recovery mechanisms should minimize, if required by the traffic, the additive latency that may be incurred when a recovery path is activated. XI. MPLS-based recovery mechanisms should minimize the state overhead incurred for each recovery path maintained. XII. MPLS-based recovery mechanisms should be able to preserve the constraints on traffic after switchover, if desired. That is, if desired, the recovery path should meet the resource requirements of, and achieve the same performance characteristics, as the working path. 2.0 Overview There are several options for providing protection of traffic using MPLS. The most generic requirement is the specification of whether recovery should be via Layer 3 (or IP) rerouting or via protection switching actions. More importantly, MPLS-based protection should give the flexibility to select the recovery mechanism, choose the granularity at which traffic is protected, and to also choose the specific types of traffic that are protected. Generally network operators aim to provide the fastest and the best protection mechanism that can be provided at a reasonable cost. The higher the level of protection, the more resources it consumes. With MPLS-based recovery, it can be possible to provide different levels of protection for different classes of service, based on their service requirements. For example, a VLL service that supports real-time applications like VoIP may be supported using link/node protection together with pre-established, pre-reserved path protection, while best effort traffic may use established-on- demand path protection or simply rely on – IP re-route or higher layer recovery mechanisms. 2.1 Recovery Models There are two basic models for path recovery: rerouting and protection switching. 2.1.1 Rerouting Recovery by rerouting is defined as establishing new paths or path segments on demand for restoring traffic after the occurrence of a fault. The new paths may be based upon fault information, network routing policies, pre-defined configurations and network topology information. Thus, upon detecting a fault, the affected paths are re-established using signaling. Reroute mechanisms are inherently slower than protection switching mechanisms, since more must be done following the detection of a fault. Once the network routing algorithms have converged after a fault, it may be preferable, in some cases, to reoptimize the network by performing a reroute based on the current state of the network and network policies. This is currently discussed further in Section 3.8, but will also be clarified further in upcoming revisions of this document. 2.1.2 Protection Switching Protection switching recovery mechanisms pre-establish a recovery path or path segment, based upon network routing policies, the restoration requirements of the traffic on the working path, and administrative considerations. The recovery path may or may not be link and node disjoint with the working path [8]. When a fault is detected on the working path, a switch to the recovery path restores traffic. The resources (bandwidth, buffers, processing) on the recovery path may be used to carry either a copy of the working path traffic or extra traffic that is displaced when a protection switch occurs. Protection switching and rerouting may be used together. For example, protection switching to a recovery path may be used for rapid restoration of connectivity while rerouting determines a new optimal network configuration, rearranging paths, as needed, at a later time [9] [10]. Additional specifications of the recovery actions are found in Section 3. 2.2 The Recovery Cycles The MPLS recovery cycle model is illustrated in Figure 1. Definitions and a key to abbreviations follow. --Network Impairment | --Fault Detected | | --Start of Notification | | | -- Start of Recovery Operation | | | | --Recovery Operation Complete | | | | | --Path Traffic Restored | | | | | | | | | | | | v v v v v v ----------------------------------------------------------------- ------ | T1 | T2 | T3 | T4 | T5 | Figure 1. MPLS Recovery Cycle Model The various timing measures used in the model are described below. T1 Fault Detection Time T2 Hold-off Time T3 Notification Time T4 Recovery Operation Time T5 Traffic Restoration Time Definitions of the recovery cycle times are as follows: Fault Detection Time The time between the occurrence of a network impairment and the moment the fault is detected by MPLS-based recovery mechanisms. This time may be highly dependent on lower layer protocols. Hold-Off Time The configured waiting time between the detection of a fault and taking MPLS-based recovery action, to allow time for lower layer protection to take effect. The Hold-off Time may be zero. Note: The Hold-Off Time may occur after the Notification Time interval if the node responsible for the switchover, the Path Switch LSR (PSL), rather than the detecting LSR, is configured to wait. Notification Time The time between initiation of an FIS by the LSR detecting the fault and the time at which the Path Switch LSR (PSL) begins the recovery operation. This is zero if the PSL detects the fault itself. Note: If the PSL detects the fault itself, there still may be a Hold-Off Time period between detection and the start of the recovery operation. Recovery Operation Time The time between the first and last recovery actions. This may include message exchanges between the PSL and PML to coordinate recovery actions. Traffic Restoration Time The time between the last recovery action and the time that the traffic (if present) is completely - recovered. This interval is intended to account for the time required for traffic to once again –arrive at the point in the network that experienced disrupted or degraded service due to the occurrence of the fault (e.g. the PML). This time may depend on the location of the fault, the recovery mechanism, and the propagation delay along the recovery path. In protection switching, revertive mode requires the LSP to be switched back to a preferred path when the fault on that path is cleared. The MPLS reversion cycle model is illustrated in Figure 2. Note that the cycle shown below comes after the recovery cycle shown in Fig. 1. --Network Impairment Repaired | --Fault Cleared | | -- Path Available | | | -- Start of Reversion Operation | | | | --Reversion Operation Complete | | | | | --Traffic Restored on Preferred Path | | | | | | | | | | | | v v v v v v ------------------------------------------------------------------ ----- | T7 | T8 | T9 | T10| T11| Figure 2. MPLS Reversion Cycle Model The various timing measures used in the model are described below. T7 Fault Clearing Time T8 Wait-to-Restore Time T9 Notification Time T10 Reversion Operation Time T11 Traffic Restoration Time Note that time T6 (not shown above) is the time for which the network impairment is not repaired and traffic is flowing on the recovery path. Definitions of the reversion cycle times are as follows: Fault Clearing Time The time between the repair of a network impairment and the time that MPLS-based mechanisms learn that the fault has been cleared. This time may be highly dependent on lower layer protocols. Wait-to-Restore Time The configured waiting time between the clearing of a fault and MPLS-based recovery action(s). Waiting time may be needed to ensure the path is stable and to avoid flapping in cases where a fault is intermittent. The Wait-to-Restore Time may be zero. Note: The Wait-to-Restore Time may occur after the Notification Time interval if the PSL is configured to wait. Notification Time The time between initiation of an FRS by the LSR clearing the fault and the time at which the path switch LSR begins the reversion operation. This is zero if the PSL clears the fault itself. Note: If the PSL clears the fault itself, there still may be a Wait- to-Restore Time period between fault clearing and the start of the reversion operation. Reversion Operation Time The time between the first and last reversion actions. This may include message exchanges between the PSL and PML to coordinate reversion actions. Traffic Restoration Time The time between the last reversion action and the time that traffic (if present) is completely restored on the preferred path. This interval is expected to be quite small since both paths are working and care may be taken to limit the traffic disruption (e.g., using “make before break” techniques and synchronous switch- over). In practice, the only interesting times in the reversion cycle are the Wait-to-Restore Time and the Traffic Restoration Time (or some other measure of traffic disruption). Given that both paths are available, there is no need for rapid operation, and a well- controlled switch-back with minimal disruption is desirable. Recovery based on dynamic rerouting requires the MPLS network to be in a stable state after a network impairment occurs. The goal is to reoptimize the network after the routing protocols converge, and move the traffic from a recovery path to a (possibly) new working path. The steps involved in this mode are illustrated in Figure 3. Note that the cycle shown below may follow the recovery cycle shown in Fig. 1 or the reversion cycle shown in Fig. 2, or both (in the event that both the recovery cycle and the reversion cycle take place before the routing protocols converge, and after the convergence of the routing protocols it is determined (based on on- line algorithms or off-line traffic engineering tools, network configuration, or a variety of other possible criteria) that there is a better route for the working path). --Network Enters a Semi-stable State after an Impairment | --Dynamic Routing Protocols Converge | | -- Initiate Setup of New Working Path between PSL and PML | | | -- –Switchover Operation Complete | | | | --Traffic -Moved to Preferred Path | | | | | | | | | | v v v v v ------------------------------------------------------------------ ----- | T12 | T13 | T14 | T15 | Figure 3. MPLS Dynamic Rerouting Cycle Model The various timing measures used in the model are described below. T12 Network Route Convergence Time T13 Hold-down Time (optional) T14 Switchover Operation Time T15 Traffic Restoration Time Network Route Convergence Time We define the network route convergence time as the time taken for the network routing protocols to converge and for the network to reach a stable state. Holddown Time We define the holddown period as a bounded time for which a recovery path must be used. In some scenarios it may be difficult to determine if the working path is stable. In these cases a holddown time may be used to prevent excess flapping of traffic between a working and a recovery path. Switchover Operation Time The time between the first and last switchover actions. This may include message exchanges between the PSL and PML to coordinate the switchover actions. As an example of the recovery cycle, we present a sequence of events that occur after a network impairment occurs and when a protection switch is followed by dynamic rerouting. I. Link or path fault occurs II. Signaling initiated (FIS) for the fault detected III. FIS arrives at the PSL IV. The PSL initiates a protection switch to a pre-configured recovery path V. The PSL switches over the traffic from the working path to the recovery path VI. The network enters a semi-stable state VII. Dynamic routing protocols converge after the fault, and a new working path is calculated (based, for example, on some of the criteria mentioned earlier in Section 2.1.1). VIII. A new working path is established between the PSL and the PML (assumption is that PSL and PML have not changed) IX. Traffic is switched over to the new working path. 2.2 Definitions and Terminology This document assumes the terminology given in Error! Reference source not found., and, in addition, introduces the following new terms. 2.2.1 General Recovery Terminology Rerouting A recovery mechanism in which the recovery path or path segments are created dynamically after the detection of a fault on the working path. In other words, a recovery mechanism in which the recovery path is not pre-established. Protection Switching A recovery mechanism in which the recovery path or path segments are created prior to the detection of a fault on the working path. In other words, a recovery mechanism in which the recovery path is pre-established. Working Path The protected path that carries traffic before the occurrence of a fault. Recovery Path The path by which traffic is restored after the occurrence of a fault. In other words, the path on which the traffic is directed by the recovery mechanism. The recovery path can either be an equivalent recovery path and ensure no reduction in quality of service, or be a limited recovery path and thereby not guarantee the same quality of service (or some other criteria of performance) as the working path. A limited recovery path is not expected to be used for an extended period of time. Path Group (PG) A logical bundling of multiple working paths, each of which is routed identically between a Path Switch LSR and a Path Merge LSR. Protected Path Group (PPG) A path group that requires protection. Protected Traffic Portion (PTP) The portion of the traffic on an individual path that requires protection. For example, code points in the EXP bits of the shim header may identify a protected portion. Path Switch LSR (PSL) An LSR that is the transmitter of both the working path traffic and its corresponding recovery path traffic. The PSL is responsible for switching of the traffic between the working path and the recovery path. Path Merge LSR (PML) An LSR that receives both working path traffic and its corresponding recovery path traffic, and either merges their traffic into a single outgoing path, or, if it is itself the destination, passes the traffic on to the higher layer protocols. Intermediate LSR An LSR on a working or recovery path that is neither a PSL nor a PML for that path. Bypass Tunnel A path that serves to backup a set of working paths using the label stacking approach. The working paths and the bypass tunnel must all share the same path switch LSR (PSL) and the path merge LSR (PML). Switch-Over The process of switching the traffic from a working path onto one or more alternate path(s). This may involve moving traffic from a working path onto one or more recovery paths, or may involve moving traffic from a recovery path(s) on to a more optimal working path(s). Switch-Back The process of -returning the traffic from one or more recovery paths back to –the working path(s). Revertive Mode A recovery mode in which traffic is automatically switched back from the recovery path to the original working path upon the restoration of the working path to a fault-free condition. Non-revertive Mode A recovery mode in which traffic is not automatically switched back to the original working path after this path is restored to a fault- free condition. (Depending on the configuration, the original working path may, upon moving to a fault free condition, become the recovery path, or it may be used for new working traffic, and be no longer associated with its original recovery path). MPLS Protection Domain The set of LSRs over which a working path and its corresponding recovery path are routed. Liveness Message A message exchanged periodically between two adjacent LSRs that serves as a link probing mechanism. It provides an integrity check of the forward and the backward directions of the link between the two LSRs as well as a check of neighbor aliveness. Path Continuity Test A test that verifies the integrity and continuity of a path or path segment. The details of such a test are beyond the scope of this draft.(This could be accomplished, for example, by the transmitting a control message along the same links and nodes as the data traffic.) 2.2.2 Failure Terminology Path Failure (PF) Path failure is fault detected by MPLS-based recovery mechanisms, which is define as the failure of the liveness message test or a path continuity test, which indicates that path connectivity is lost. Path Degraded (PD) Path degraded is a fault detected by MPLS-based recovery mechanisms that indicates that the quality of the path is unacceptable. Link Failure (LF) A lower layer fault indicating that link continuity is lost. This may be communicated to the MPLS-based recovery mechanisms by the lower layer. Link Degraded (LD) A lower layer indication to MPLS-based recovery mechanisms that the link is performing below an acceptable level. Fault Indication Signal (FIS) A signal that indicates that a fault along a path has occurred. It is relayed by each intermediate LSR to its upstream or downstream neighbor, until it reaches an LSR that is setup to perform MPLS recovery. Fault Recovery Signal (FRS) A signal that indicates a fault along a working path has been repaired. Again, like the FIS, it is relayed by each intermediate LSR to its upstream or downstream neighbor, until is reaches the LSR that performs recovery of the original path. 2.3 Abbreviations FIS: Fault Indication Signal. FRS: Fault Recovery Signal. LD: Link Degraded. LF: Link Failure. PD: Path Degraded. PF: Path Failure. PML: Path Merge LSR. PG: Path Group. PPG: Protected Path Group. PTP: Protected Traffic Portion. PSL: Path Switch LSR. 3.0 MPLS-based Recovery Principles MPLS-based recovery refers to the ability to effect quick and complete restoration of traffic affected by a fault in MPLS-based transport mechanisms or in or lower layers over which MPLS is transported. Fast MPLS protection may be viewed as the MPLS LSR switch completion time that is comparable to, or equivalent to, the 50 ms switch-over completion time of the SONET layer. This section provides a discussion of the concepts and principles of MPLS-based recovery. We do not make any assumptions about the underlying layer 1 or layer 2 transport mechanisms or their recovery mechanisms. 3.1 Initiation of Path Setup As explained in Section 2.2, there are two options for the initiation of the recovery path setup. Pre-established: This is the same as the protection switching option. Here a recovery path(s) is established prior to any failure on the working path. The path selection can either be determined by an administrative centralized tool (online or offline), or chosen based on some algorithm implemented at the PSL and possibly intermediate nodes. To guard against the situation when the pre- established recovery path fails before or at the same time as the working path, the recovery path should have secondary configuration options as explained in Section 3.3 below. Established-on-Demand: This is the same as the rerouting option. Here, a recovery path is established after a failure on its working path has been detected and notified to the PSL. 3.2 Initiation of Resource Allocation A recovery path may support the same traffic contract as the working path, or it may not. We will distinguish these two situations by using different additive terms. If the recovery path is capable of replacing the working path without degrading service, it will be called an equivalent recovery path. If the recovery path lacks the resources (or resource reservations) to replace the working path without degrading service, it will be called a limited recovery path. Based on this, there are two options for the initiation of resource allocation: Pre-reserved: This option applies only to protection switching. Here a pre- established recovery path reserves required resources on all hops along its route during its establishment. Although the reserved resources (e.g., bandwidth and/or buffers) at each node cannot be used to admit more working paths, they are available to be used by all traffic that is present at the node before a failure occurs, which results in better resource usage than SONET APS. Reserved-on-Demand: This option may apply either to rerouting or to protection switching. Here a recovery path reserves the required resources after a failure on the working path has been detected and notified to the PSL and before the traffic on the working path is switched over to the recovery path. Note that under both the options above, depending on the amount of resources reserved on the recovery path, it could either be an equivalent recovery path or a limited recovery path. 3.3 Configuration of Recovery The recovery path should allow for configuration of the following recovery options: Default-recovery (No MPLS-based recovery enabled): Traffic on the working path is recovered only via Layer 3 or IP rerouting. This is equivalent to having no MPLS-based recovery. This option may be used for low priority traffic or for traffic that is “recovered” in another way (for example load shared traffic on parallel working paths, may be automatically “recovered” upon a fault along one of the working paths by distributing it among the remaining working paths) Recoverable (MPLS-based recovery enabled): This working path is recovered using one or more recovery paths, either via rerouting or via protection switching. 3.4 Scope of Recovery 3.4.1 Topology Local Repair The intent of local repair is to protect against a single link or neighbor node fault. In local repair (also known as local recovery [11] [9]), the node detecting the fault is the one to initiate recovery (either rerouting or protection switching). Local repair can be of two types: Link Recovery/Restoration In this case, the recovery path may be configured to route around a certain link deemed to be unreliable. If protection switching is used, several recovery paths may be configured for one working path, depending on the specific faulty link that each protects against. Alternatively, if rerouting is used then, upon the occurrence of a fault on the specified link, each path is rebuilt such that it detours around the faulty link. In this case, the recovery path need only be disjoint from its working path at a particular link on the working path, and may have overlapping segments with the working path. Traffic on the working path is switched over to an alternate path at the upstream LSR that connects to the failed link. This method is potentially the fastest, and can be effective in situations where certain path components are much more unreliable than others. Node Recovery/Restoration In this case, the recovery path may be configured to route around a neighbor node deemed to be unreliable. Thus the recovery path is disjoint from the working path only at a particular node and at links associated with the working path at that node. Once again, the traffic on the primary path is switched over to the recovery path at the upstream LSR that directly connects to the failed node, and the recovery path shares overlapping portions with the working path. Global Repair The intent of global repair is to protect against any link or node fault on the entire path or on a segment of a path (with the obvious exception of the ingress and egress nodes). In global repair (also known as path recovery/restoration) the node that initiates the recovery may be distant from the faulty link or node. In some cases, a fault notification (in the form of a FIS) must be sent from the node detecting the fault to the node responsible for initiating the recovery action. The recovery path can be made completely link and node disjoint with its working path. This has the advantage of protecting against all link and node fault(s) on the working path (or path segment), and being more efficient than per-hop link or node recovery. In addition, it can be potentially more optimal in resource usage than the link or node recovery. However, it is in some cases slower than local repair since it takes longer for the fault notification message to get to the PSL to trigger the recovery action. 3.4.2 Path Mapping Path mapping refers to the methods of mapping traffic from a faulty working path on to the recovery path. There are several options for this. The first four require standard path semantics, while the fifth requires extended path semantics, and is for further study. i) 1+1 Protection In 1+1 (“one plus one”) protection, the resources (bandwidth, buffers, processing capacity) on the recovery path are fully reserved and carry the same traffic as the working path. Selection between the traffic on the working and recovery paths is made at the path merge LSR (PML). ii) 1:1 Protection In 1:1 (“one for one”) protection, the resources (bandwidth, buffers, and processing capacity) allocated on the recovery path are fully available to preemptable low priority traffic except when the recovery path is in use due to a fault on the working path. In other words, in 1:1 protection, the protected traffic normally travels only on the working path, and is switched to the recovery path only when the working path has a fault. Once the protection switch is initiated, the low priority traffic being carried on the recovery path may be displaced by the protected traffic. This method affords a way to make efficient use of the recovery path resources. iii) 1:n Protection In 1:n protection, up to n working paths are protected using only one recovery path. If the intent is to protect against any single fault on any of the working paths, the n working paths should be diversely routed between the same PSL and PML. In some cases, handshaking between PSL and PML may be required to complete the recovery, the details of which are beyond the scope of this draft. iv) m:n Protection In m:n protection, up to n working paths are protected using m recovery paths. Once again, if the intent is to protect again any single fault on any of the n working paths, the n working paths and the m recovery paths should be diversely routed between the same PSL and PML. In some cases, handshaking between PSL and PML may be required to complete the recovery, the details of which are beyond the scope of this draft. m:n protection is for further study. v) Split Path Protection In split path protection, multiple recovery paths are allowed to carry the traffic of a working path based on a certain configurable load splitting ratio. This is especially useful when no single recovery path can be found that can carry the entire traffic of the working path in case of a fault. Split path protection may require handshaking between the PSL and the PML, and may require the PML to correlate the traffic arriving on multiple recovery paths with the working path. Although this is an attractive option, the details of split path protection are beyond the scope of this draft, and are for further study. 3.4.3 Bypass Tunnels It may be convenient, in some cases, to create a “bypass tunnel” for a PPG between a PSL and PML, thereby allowing multiple recovery paths to be transparent to intervening LSRs [11]. In this case, one LSP (the tunnel) is established between the PSL and PML following an acceptable route and a number of recovery paths are supported through the tunnel via label stacking. A bypass tunnel can be used with any of the path mapping options discussed in the previous section. As with recovery paths, the bypass tunnel may or may not have resource reservations sufficient to provide recovery without service degradation. It is possible that the bypass tunnel may have sufficient resources to recover some number of working paths, but not all at the same time. If the number of recovery paths carrying traffic in the tunnel at any given time is restricted, this is similar to the 1:n or m:n protection cases mentioned in Section 3.3.2. 3.4.4 Recovery Granularity Another dimension of recovery considers the amount of traffic requiring protection. This may range from a fraction of a path to a bundle of paths. 3.4.4.1 Selective Traffic Recovery This option allows for the protection of a fraction of traffic within the same path. The portion of the traffic on an individual path that requires protection is called a protected traffic portion (PTP). A single path may carry different classes of traffic, with different protection requirements. The protected portion of this traffic may be identified by its class, as for example, via the EXP bits in the MPLS shim header or via the priority bit in the ATM header. 3.4.4.2 Bundling Bundling is a technique used to group multiple working paths together in order to recover them simultaneously. The logical bundling of multiple working paths requiring protection, each of which is routed identically between a PSL and a PML, is called a protected path group (PPG). When a fault occurs on the working path carrying the PPG, the PPG as a whole can be protected either by being switched to a bypass tunnel or by being switched to a recovery path. 3.5 Fault Detection MPLS recovery is initiated after the detection of either a lower layer fault or a fault in the operation of MPLS-based mechanisms. We consider four classes of impairments: Path Failure, Path Degraded, Link Failure, and Link Degraded. Path Failure (PF) is a fault that indicates to an MPLS-based recovery scheme that the connectivity of the path is lost. This may be detected by a path continuity test between the PSL and PML. Some, and perhaps the most common, path failures may be detected using a link probing mechanism between neighbor LSRs. An example of a probing mechanism is a liveness message that is exchanged periodically along the working path between peer LSRs. For either a link probing mechanism or path continuity test to be effective, the test message must be guaranteed to follow the same route as the working or recovery path, over the segment being tested. In addition, the path continuity test must take the path merge points into consideration. In the case of a bi-directional link implemented as two unidirectional links, path failure could mean that either one or both unidirectional links are damaged. Path Degraded (PD) is a fault that indicates to MPLS-based recovery schemes/mechanisms that the LSP has connectivity, but that the quality of the connection is unacceptable. This may be detected by a path performance monitoring mechanism, or some other MPLS-based mechanism for determining the error rate on the path or some portion of the path. This is local to the LSR and consists of excessive discarding of packets at an interface, either due to label mismatch or due to TTL errors, for example. Link Failure (LF) is an indication from a lower layer that the link over which the LSP is carried has failed. If the lower layer supports detection and reporting of this fault (that is, any fault that indicates link failure e.g., SONET LOS), this may be used by the MPLS recovery mechanism. In some cases, using LF indications may provide faster fault detection than using only MPLS –based fault detection mechanisms. Link Degraded (LD) is an indication from a lower layer that the link over which the LSP is carried is performing below an acceptable level. If the lower layer supports detection and reporting of this fault, it may be used by the MPLS recovery mechanism. In some cases, using LD indications may provide faster fault detection than using only MPLS-based fault detection mechanisms. 3.6 Fault Notification Protection switching relies on rapid notification of faults. Once a fault is detected, the node that detected the fault must determine if the fault is severe enough to require path recovery. Then the node should send out a notification of the fault by transmitting a FIS to those of its upstream LSRs that were sending traffic on the working path that is affected by the fault. This notification is relayed hop-by-hop by each subsequent LSR to its upstream neighbor, until it eventually reaches a PSL. A PSL is the only LSR that can terminate the FIS and initiate a protection switch of the working path to a recovery path. Since the FIS is a control message, it should be transmitted with high priority to ensure that it propagates rapidly towards the affected PSL(s). Depending on how fault notification is configured in the LSRs of an MPLS domain, the FIS could be sent either as a Layer 2 or Layer 3 packet. An example of a FIS could be the liveness message sent by a downstream LSR to its upstream neighbor, with an optional fault notification field set. Alternatively, it could be a separate fault notification packet. The intermediate LSR should identify which of its incoming links (upstream LSRs) to propagate the FIS on. In the case of 1+1 protection, the FIS should also be sent downstream to the PML where the recovery action is taken. 3.7 Switch-Over Operation 3.7.1 Recovery Trigger The activation of an MPLS protection switch following the detection or notification of a fault requires a trigger mechanism at the PSL. MPLS protection switching may be initiated due to automatic inputs or external commands. The automatic activation of an MPLS protection switch results from a response to a defect or fault conditions detected at the PSL or to fault notifications received at the PSL. It is possible that the fault detection and trigger mechanisms may be combined, as is the case when a PF, PD, LF, or LD is detected at a PSL and triggers a protection switch to the recovery path. In most cases, however, the detection and trigger mechanisms are distinct, involving the detection of fault at some intermediate LSR followed by the propagation of a fault notification back to the PSL via the FIS, which serves as the protection switch trigger at the PSL. MPLS protection switching in response to external commands results when the operator initiates a protection switch by a command to a PSL (or alternatively by a configuration command to an intermediate LSR, which transmits the FIS towards the PSL). Note that the PF fault applies to hard failures (fiber cuts, transmitter failures, or LSR fabric failures), as does the LF fault, with the difference that the LF is a lower layer impairment that may be communicated to - MPLS-based recovery mechanisms. The PD (or LD) fault, on the other hand, applies to soft defects (excessive errors due to noise on the link, for instance). The PD (or LD) results in a fault declaration only when the percentage of lost packets exceeds a given threshold, which is provisioned and may be set based on the service level agreement(s) in effect between a service provider and a customer. 3.7.2 Recovery Action After a fault is detected or FIS is received by the PSL, the recovery action involves either a rerouting or protection switching operation. In both scenarios, the next hop label forwarding entry for a recovery path is bound to the working path. 3.8 Switch-Back Operation 3.8.1 Revertive and Non-Revertive Modes These protection modes indicate whether or not there is a “preferred” path for the protected traffic. If there is a preferred path, this path will be used whenever it is available. If the preferred path has a fault, traffic is switched to the recovery path. In the revertive mode of operation, when the preferred path is restored the traffic is automatically switched back to it. In the non-revertive mode of operation, there is no preferred path. If there is a fault on the working path, traffic is switched to the recovery path. When or if the faulty path is restored, it may become the recovery path (either by configuration, or by management action, if desired). On the other hand, once the traffic is switched over to a recovery path, the association between the original working path and the recovery path may no longer exist. Instead, when the network reaches a stable state following routing convergence, the recovery path may be switched over to a different preferred path based either on pre-configured information or optimization based on the new network topology and associated information. 3.8.2 Restoration and Notification MPLS restoration deals with returning the working traffic from the recovery path to the original working path. Reversion is performed by the PSL upon receiving notification, via FRS, that the working path is repaired. As before, an LSR that detected the fault on the working path also detects the restoration of the working path. If the working path had experienced a LF defect, the LSR detects a return to normal operation via the receipt of a liveness message from its peer. If the working path had experienced a LD defect at an LSR interface, the LSR could detect a return to normal operation via the resumption of error-free packet reception on that interface. Alternatively, a lower layer that no longer detects a LF defect may inform the MPLS-based recovery mechanisms at the LSR that the link to its peer LSR is operational. The LSR then transmits FRS to its upstream LSR(s) that were transmitting traffic on the working path. This is relayed hop-by-hop until it reaches the PSL(s), at which point the PSL switches the working traffic back to the original working path. In the non-revertive mode of operation, the working traffic may or may not be restored to the original working path. This is because it might be useful, in some cases, to either: (a) administratively perform a protection switch back to the original working path after gaining further assurances about the integrity of the path, or (b) it may be acceptable to continue operation without the recovery path being protected, or (c) it may be desirable to move the traffic to a new working path that is calculated based on network topology and network policies, after the dynamic routing protocols have converged. We note that if there is a way to transmit fault information back along a recovery path towards a PSL and if the recovery path is an equivalent recovery path, it is possible for the working path and its recovery path to exchange roles once the original working path is repaired following a fault. This is because, in that case, the recovery path effectively becomes the working path, and the restored working path functions as a recovery path for the original recovery path. This is important, since it affords the benefits of non-revertive switch operation outlined in Section 3.8.1, without leaving the recovery path unprotected. 3.8.3 Reverting to Preferred LSP (or Controlled Rearrangement) In the revertive mode, a “make before break” restoration switching can be used, which is less disruptive than performing protection switching upon the occurrence of network impairments. This will minimize both packet loss and packet reordering. The controlled rearrangement of LSPs can also be used to satisfy traffic engineering requirements for load balancing across an MPLS domain. 3.9 Performance Resource/performance requirements for recovery paths should be specified in terms of the following attributes: I. Resource class attribute: Equivalent Recovery Class: The recovery path has the same resource reservations and performance guarantees as the working path. In other words, the recovery path meets the same SLAs as the working path. Limited Recovery Class: The recovery path does not have the same resource reservations and performance guarantees as the working path. A. Lower Class: The recovery path has lower resource requirements or less stringent performance requirements than the working path. B. Best Effort Class: The recovery path is best effort. II. Priority Attribute: The recovery path has a priority attribute just like the working path (i.e., the priority attribute of the associated traffic trunks). It can have the same priority as the working path or lower priority. III. Preemption Attribute: The recovery path can have the same preemption attribute as the working path or a lower one. 4.0 MPLS Recovery Requirements The following are the MPLS recovery requirements: I. MPLS recovery SHALL provide an option to identify protection groups (PPGs) and protection portions (PTPs). II. Each PSL SHALL be capable of performing MPLS recovery upon the detection of the impairments or upon receipt of notifications of impairments. III. A MPLS recovery method SHALL not preclude manual protection switching commands. This implies that it would be possible under administrative commands to transfer traffic from a working path to a recovery path, or to transfer traffic from a recovery path to a working path, once the working path becomes operational following a fault. IV. A PSL SHALL be capable of performing either a switch back to –the original working path after the fault is corrected or a switchover to a new working path, upon the discovery of a more optimal working path. V. The recovery model should take into consideration path merging at intermediate LSRs. If a fault affects the merged segment, all the paths sharing that merged segment should be able to recover. Similarly, if a fault affects a non-merged segment, only the path that is affected by the fault should be recovered. 5.0 MPLS Recovery Options There SHOULD be an option for: I. Configuration of the recovery path as excess or reserved, with excess as the default. The recovery path that is configured as excess SHALL provide lower priority preemptable traffic access to the protection bandwidth, while the recovery path configured as reserved SHALL not provide any other traffic access to the protection bandwidth. II. Each protected path SHALL provide an option for configuring the protection alternatives as either rerouting or protection switching. III. Each protected path SHALL provide a configuration option for enabling restoration as either non-revertive or revertive, with revertive as the default. IV. Each LSR supporting protection switching SHALL provide an option for fault notification to the PSL. 6.0 Comparison Criteria Possible criteria to use for comparison of MPLS-based recovery schemes are as follows: Recovery Time We define recovery time as the time required for a recovery path to be activated (and traffic flowing) after a fault. Recovery Time is the sum of the Fault Detection Time, Hold-off Time, Notification Time, Recovery Operation Time, and the Traffic Restoration Time. In other words, it is the time between a failure of a node or link in the network and the time before a recovery path is installed and the traffic starts flowing on it. Full Restoration Time We define full restoration time as the time required for a permanent restoration. This is the time required for traffic to be routed onto links which are capable of or have been engineered sufficiently to handle traffic in recovery scenarios. Note that this time may or may not be different from the "Recovery Time" depending on whether equivalent or limited recovery paths are used. Backup Capacity Recovery schemes may require differing amounts of "backup capacity" in the event of a fault. This capacity will be dependent on the traffic characteristics of the network. However, it may also be dependent on the particular recovery path selection algorithms as well as the signaling and re-routing methods. Additive Latency Recovery schemes may introduce additive latency to traffic. For example, a recovery path may take many more hops than the working path. This may be dependent on the recovery path selection algorithms. Re-ordering Recovery schemes may introduce re-ordering of packets. Also the action of putting traffic back on preferred paths might cause packet re-ordering. State Overhead As the number of recovery paths grows, the state required to maintain them also grows. Schemes may require differing numbers of paths to maintain certain levels of coverage, etc. The state required may also depend on the particular scheme used to recover. In many cases the state overhead will be in proportion to the number of recovery paths. Loss Recovery schemes may introduce a certain amount of packet loss during switchover to a recovery path. Schemes which introduce loss during recovery can measure this loss by evaluating recovery times in proportion to the link speed. In case of link or node failure a certain packet loss is inevitable. Coverage Recovery schemes may offer various types of failover coverage. The total coverage may be defined in terms of several metrics: I. Fault Types: Recovery schemes may account for only link faults or both node and link faults or also degraded service. For example, a scheme may require more recovery paths to take node faults into account. II. Number of concurrent faults: dependent on the layout of recovery paths, multiple fault scenarios may be able to be restored. III. Number of recovery paths: for a given fault, there may be one or more recovery paths. IV. Percentage of coverage: dependent on a scheme and its implementation, a certain percentage of faults may be covered. This may be subdivided into percentage of link faults and percentage of node faults. V. The number of protected paths will highly effect how fast the total set of paths affected by a fault could be recovered. The ratio of protected is n/N, where n is the number of protected paths and N is the total number of paths. 7.0 Security Considerations The MPLS recovery that is specified herein does not raise any security issues that are not already present in the MPLS architecture. 8.0 Intellectual Property Considerations The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 9.0 Authors’ Addresses Srinivas Makam Tellabs 4951 Indiana Avenue Lisle, IL 60532 Ph: 630-512-7217 Email: srinivas.makam@tellabs.com Vishal Sharma Tellabs Research Center One Kendall Square Cambridge, MA 02139 Ph: 617-577-8760 Email: vishal.sharma@tellabs.com Ken Owens Tellabs 4951 Indiana Avenue Lisle, IL 60532 Ph: 314-918-1579825-7009 Email: ken.owens@tellabs.com Changcheng Huang Tellabs 4951 Indiana Avenue Lisle, IL 60532 Ph: 630-512-7754 Email: changcheng.huang@tellabs.com Ben Mack-Crane Tellabs 4951 Indiana Avenue Lisle, IL 60532 Email: ben.mack-crane@tellabs.com Ph: 630-512-7255 Fiffi Hellstrand Nortel Networks St Eriksgatan 115, PO Box 6701 113 85 Stockholm, Sweden Ph: +46 8 5088 3687 e-mail: fiffi@nortelnetworks.com Jon Weil Nortel Networks Harlow Laboratories London Road Harlow Essex CM17 9NA, UK Phone: +44 (0)1279 403935 e-mail: jonweil@nortelnetworks.com Brad Cain Nortel Networks 3 Federal Street, BL3-03 Billerica, MA 01821, USA Email: bcain@baynetworks.com Loa Andersson Nortel Networks St Eriksgatan 115, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34 e-mail: loa.andersson@nortelnetworks.com Bilel Jamoussi Nortel Networks 3 Federal Street, BL3-03 Billerica, MA 01821, USA Email: jamoussi@nortelnetworks.com Seyhan Civanlar AT&T Labs Room C4-3A25 200 Laurel Ave. Middletown, NJ 07748 Phone: (732) 420-2640 Email: scivanlar@att.com Angela Chiu AT&T Labs Room C4-3A22 200 Laurel Ave. Middletown, NJ 07748 Phone: (732) 420-2290 Email: alchiu@att.com 10.0 References _______________________________ 1 Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label Switching Architecture", Work in Progress, Internet Draft , August 1999. 2 Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., "LDP Specification", Work in Progress, Internet Draft , September 1999. 3 Awduche, D. Hannan, A., and Xiao, X., “Applicability Statement for Extensions to RSVP for LSP-Tunnels”, draft-ietf-mpls-rsvp- tunnel-applicability-00.txt”, work in progress, Sept. 1999. 4 Jamoussi, B. "Constraint-Based LSP Setup using LDP", Work in Progress, Internet Draft , September 1999. 5 Braden, R., Zhang, L., Berson, S., Herzog, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. 6 Awduche, D. et al "Extensions to RSVP for LSP Tunnels", Work in Progress, Internet Draft ; Mon, 13 Mar 2000 11:43:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigja25509; Mon, 13 Mar 2000 16:39:50 GMT Received: by mail-control.mail.uu.net id QQigja15479 for mpls-outgoing; Mon, 13 Mar 2000 16:39:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigja15468 for ; Mon, 13 Mar 2000 16:39:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigja02595 for ; Mon, 13 Mar 2000 11:38:51 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigja14662 for ; Mon, 13 Mar 2000 16:38:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA22936 for mpls@uu.net; Mon, 13 Mar 2000 11:38:43 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigja15432 for ; Mon, 13 Mar 2000 16:38:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigja13893 for ; Mon, 13 Mar 2000 11:37:44 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQigja24219 for ; Mon, 13 Mar 2000 16:37:43 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Mar 2000 11:36:01 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F842@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'cheenu@tachion.com'" , "'arun@force10networks.com'" , "'tnadeau@cisco.com'" Cc: "'mpls@uu.net'" Subject: draft-nadeau-mpls-packet-classifier-mib-00.txt comments Date: Mon, 13 Mar 2000 11:35:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tom, Arun and Cheenu, I have some questions and comments and concerns on: draft-nadeau-mpls-packet-classier-mib-00.txt General comments ----------------- * MIB doesn't compile with any of my mib compilers, can you tell me which one you are using? * In general, I find the MIB approach to be top-down which leads to a gap in the logic between the MIB and what is actually needed to set on the hardware-side in order to provide for mpls packet classification. You have barely scratched the surface for ALL MPLS protocols. (it is not clear from the document that the intent is to provide a way to support ALL MPLS protocols, but since this references the LSR MIB, then I assumed this was the case: is that a correct assumption?) It's as if the design was from picturing a GUI screen which has something called interface and attaching a bunch of classifier rules to try on the interface. But this doesn't quite cut it as a MIB which can be used to actually do this on hardware, at least not as it is written now. For example, when an ifIndex goes away then all the configuration that is done is GONE. This is NOT a good design. It is a configuration nightmare. Do you really expect that a System Admin person would be keeping track of all of this? That is paramount to having a sys admin keep track of every route through an ISP. And then CONFIGURE for it by knowing the ifIndex at any point in time. Which is not possible when setting up redundant LSPs. It is not realistic that a Sys Admin would do this, do you agree? The way you are treating LSPs is as if they are ALL PVC-like, which may be true in some, but certainly not ALL instances, it is not a flexible design, and it is not scalable design. It is a configuration nightmare. Furthermore, the use of a DISPLAY strings as indices is not viable for timely execution on the agent-side. Modeling a linked list which contains (Integer, DisplayString, DisplayString) where the only other thing in the table is RowStatus is also quite a poor design for the agent-side. What about redirection to a different LSP? The MIB doesn't work unless redirection is to an LSP which has been set up apriori, but what is this based on? Where is the logic to determine when to redirect and where to redirect to? Is the System Admin supposed to know magically when to do this and where? Isn't this better handled by allowing software algorithms to do redirect versus a sys admin? Currently, the MIB only allows this to be configured. Again, this is neither flexible, nor scalable. What about mapping back to Labels? (for easy clean up on in a teardown scenario) What about load balancing? Seems like this is NOT supported in the MIB. My greatest concern is that this MIB is completely useless unless ifIndex a "static, persistent index". By definition, ifIndex doesn't have to be persistent, especially not through reboots OR DISCONTINUTY types of situations. How on earth can your MIB be done by an implementation that does NOT make ifIndex persistent? Is your intention to re-write how IfIndex is used? This MIB is not viable because what you are calling interfaceIndex is not a true ifIndex, OR maybe the expectation is that someone will be continually configuring this MIB. Not a job I would want. Since the basis of the MIB is mapping packet classifier rule sets to ifIndex, is this MIB going to allow for INTEROPERABILITY? Right now it does not! In fact, I would like to see a new rev with a complete explanation of HOW this MIB will be INTEROPERABLE before seeing it as adopted as a working group document. It appears to me at least, that very little thought was actually given to interoperability. If the basis of the packet classifier identifier is a DisplayString, then is this going to be interoperable? Thus, the way you are identifying packet classifiers has absolutely no meaning, even from devices by the same vendor. For example, I could have the SAME exact classifier appear several times under different names, what good is this? Section 4. Motivation * I was expecting a simply stated goal for this MIB, which I couldn't find. Is this MIB intended to be used for all MPLS protocols? If so, could you state it plainly? * The statement: "Conceptually, some of the FTN table functionality could be implemented usig the Forwarding Information Base(FIB) to map all packets destined to a prefix to an LSP. However, this mapping is course in nature." What is meant by "course in nature", certainly for LDP this is fine. Again, if the intent of the MIB was more clearly stated that would be helpful. * The last sentence: "...as well as new ones (i.e. classifier rules?) such as those required by MPLS and Diff-Serv." may lead the audience to believe that this somehow works with diff-serv, I didn't see anything in this MIB which was diff-serv specific, if so could you point this out? Also, Diff-serv MIBs are being developed in about 3 different groups, is it your intention to work with any of these other efforts? If so, could you elaborate on what the plans are? I would like to see all of the above issues explained, particularly, the issue of InterfaceIndex and interoperability. BEFORE it is adopted as a working group document. The entire point of having a standard MIB is for interoperability, and I do not see how this MIB will provide any sort of interoperability due to the assumptions regarding InterfaceIndex which have been made but are NOT at all discussed anywhere in the MIB. Thank you, Joan From owner-mpls@UU.NET Mon Mar 13 11:47:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19179 for ; Mon, 13 Mar 2000 11:47:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigja18456; Mon, 13 Mar 2000 16:44:32 GMT Received: by mail-control.mail.uu.net id QQigja15687 for mpls-outgoing; Mon, 13 Mar 2000 16:44:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigja15682 for ; Mon, 13 Mar 2000 16:44:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigja14812 for ; Mon, 13 Mar 2000 11:43:25 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigja16796 for ; Mon, 13 Mar 2000 16:42:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA23479 for mpls@uu.net; Mon, 13 Mar 2000 11:42:02 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigja15626 for ; Mon, 13 Mar 2000 16:41:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigja14398 for ; Mon, 13 Mar 2000 11:41:14 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQigja16227 for ; Mon, 13 Mar 2000 16:41:13 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Mar 2000 11:39:31 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F843@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Piers Finlayson'" , Joan Cucchiara Cc: mpls@UU.NET, Adrian Farrel Subject: RE: I-D ACTION:draft-ietf-mpls-ldp-mib-05.txt Date: Mon, 13 Mar 2000 11:39:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Piers, > -----Original Message----- > From: Piers Finlayson [mailto:pdf@datcon.co.uk] > Sent: Saturday, March 11, 2000 7:11 AM > To: jcucchiara@brixnet.com > Cc: mpls@UU.NET; Adrian Farrel > Subject: RE: I-D ACTION:draft-ietf-mpls-ldp-mib-05.txt > > > Joan, > > I have reviewed your latest draft of the LDP MIB and have a > few comments for > you. > > - Section 3.6.1 describes the LDP notifications and should > be expanded to > cover both the mplsLdpSessionUp and Down and the mplsLdpLibUp and Down > notifications. It may also be worth referencing the > mplsLdpSessionUpDownTrapEnable, mplsLdpLibLspUpDownTrapEnable, > mplsLdpEntityFailedInitSessionTrapEnable and > mplsLdpEntityPVLimitMismatchTrapEnable objects within this section, > indicating that these objects control whether the > notifications are sent. I agree. > > - With regards to the following objects: > > mplsLdpEntityHopCountLoopDetection OBJECT-TYPE > SYNTAX INTEGER { > disabled(0), > enabled(1) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "An indication of whether loop detection based > on hop count is disabled or enabled for this > Entity. If this object has the value of > 'disabled(0)', then loop detection using > hop counts is disabled. > > Otherwise, if this object has a value of 'enabled(1)', > then loop detection based on hop counts is enabled. > Also, the value of the object, > 'mplsLdpLsrLoopDetectionCapable', must have the value > of either: 'hopCount(3)' or 'hopCountAndPathVector(5)'." > ::= { mplsLdpEntityEntry 15 } > > > mplsLdpEntityHopCount OBJECT-TYPE > SYNTAX Unsigned32 (0..255) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "If the value of 'mplsLdpEntityHopCountLoopDetection' > for this entry is 'enabled(1)', then this object > represents the initial Hop Count for this Entity. > > If the value of 'mplsLdpEntityHopCountLoopDetection' > is 'disabled(0)', then the value of this object is > undefined." > ::= { mplsLdpEntityEntry 16 } > > I think that the second object (mplsLdpEntityHopCount) > should actually be > the configured maximum allowable value of the Hop Count. In the LDP > specification, section 3.4.4 it states that "The first LSR in the > LSP(ingress for a Label Request message, egress for a Label > Mapping message) > should set the hop count value to 1.". Therefore this should not be > configurable. > > Each LSR then increments this value, and the spec states "If an LSR > receives a message containing a Hop Count TLV, it must check > the hop count > value to determine whether the hop count has exceeded the > maximum allowable > value.". This is the value that should be configured in the > LDP MIB. The > range from this object should be (1..255). > > Given this change, it is also possible to merge the two > Hop Count objects > together as follows. > > mplsLdpEntityHopCounterLimit OBJECT-TYPE > SYNTAX Integer32 (0..255) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "If the value of this object is 0 (zero), > then Loop Detection using Hop Counters is > disabled. > If the value of this object is greater than > 0 (zero) then Loop Detection using Hop > Counters is enabled, and this object > specifies this Entity's maximum allowable > value for the Hop Count. > Also, the value of the object > mplsLdpLsrLoopDetectionCapable must be set > to either 'hopCount(3)' or > 'hopCountAndPathVector(5)' if this object > has a value greater than 0 (zero)." > ::= { mplsLdpEntityEntry 15 } I agree here also. > > - Typo in section 3.5.2 "... Then and only then is it save > to ..." should > be changed to "... Then and only then is it safe to ...". > > - Typo in the mplsLdpSessionUp notification description. > "... changes from > any state accept ..." should be "... changes from any state > except ...". Got it! Thanks for your comments. -Joan > > Cheers, > Piers > > --------------------------------------------------------- > Piers Finlayson > > ATM, MPLS and Telecoms Group > Data Connection Ltd. > > Tel: +44 20 8366 1177 Fax: +44 20 8363 4478 > Email: pdf@datcon.co.uk Web: http://www.datcon.co.uk > --------------------------------------------------------- > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, March 07, 2000 11:30 AM > To: IETF-Announce > Cc: mpls@UU.NET > Subject: I-D ACTION:draft-ietf-mpls-ldp-mib-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label > Switching Working Group > of the IETF. > > Title : Definitions of Managed Objects for the > Multiprotocol > Label Switching, Label Distribution > Protocol (LDP) > Author(s) : J. Cucchiara, H. Sjostrand, J. Luciani > Filename : draft-ietf-mpls-ldp-mib-05.txt > Pages : 74 > Date : 06-Mar-00 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes managed objects for the Multiprotocol > Label Switching, Label Distribution Protocol (LDP). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-05.txt > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mpls-ldp-mib-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-ldp-mib-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-mpls@UU.NET Mon Mar 13 13:43:11 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06109 for ; Mon, 13 Mar 2000 13:43:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigji10161; Mon, 13 Mar 2000 18:43:05 GMT Received: by mail-control.mail.uu.net id QQigji08132 for mpls-outgoing; Mon, 13 Mar 2000 18:42:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigji08127 for ; Mon, 13 Mar 2000 18:42:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigji20914 for ; Mon, 13 Mar 2000 13:42:23 -0500 (EST) Received: from ns2.net.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns2.net.com [134.56.3.102]) id QQigji09458 for ; Mon, 13 Mar 2000 18:42:23 GMT Received: from isis.net.com.net.com (fremont-ns1.net.com [134.56.112.20]) by ns2.net.com (8.9.3/8.9.3) with ESMTP id KAA20901 for ; Mon, 13 Mar 2000 10:42:22 -0800 (PST) Received: from west-mail.net.com by isis.net.com.net.com (8.9.3/SMI-SVR4) id KAA26028; Mon, 13 Mar 2000 10:42:21 -0800 (PST) Received: from net.com ([134.56.103.187]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA6F57; Mon, 13 Mar 2000 10:42:32 -0800 Message-ID: <38CD36FE.453A72A8@net.com> Date: Mon, 13 Mar 2000 10:44:14 -0800 From: Harsha Vardhan Organization: N.E.T. http://www.net.com X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 To: Richard Holben , mpls@UU.NET Subject: Re: MPLS on Broadband References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit What about VPN support by MPLS. Are there any products in the market routers/BRAS whose interfaces support purely MPLS based VPNS. Thanks in Advance, Harsha Richard Holben wrote: > > Harsha > > MPLS is becomming more popular in real live networks but its limited by the interoperability issues the operators are face with today, in the short to medium term things will get better and there are a large number of vendors with product in the DWDM market that are minimising the SDH content and are looking for something like MPLS or Digital Wrappers to provide the routing/switching intelligence. > > Realistically it will be a while before we reach the ideal network where layers 1 to 4 are seen as one network from all aspects be they technology or daya to day running. > > Regards, > > Richard Holben > Technical Account Manager > Ericsson Converged Networks > > M: 07770 731101 E: Richard.Holben@etl.ericsson.se > > -----Original Message----- > From: Harsha Vardhan [mailto:harsha_vardhan@net.com] > Sent: 09 March 2000 18:35 > To: mpls@UU.NET > Subject: MPLS on Broadband > > Hi, > > Can somebody give me pointers on the topic "MPLS popularity/growth/usage > in the broadband world". > > Thanks in advance, > > Harsha From owner-mpls@UU.NET Mon Mar 13 13:56:45 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11124 for ; Mon, 13 Mar 2000 13:56:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigjj14773; Mon, 13 Mar 2000 18:56:33 GMT Received: by mail-control.mail.uu.net id QQigjj08912 for mpls-outgoing; Mon, 13 Mar 2000 18:56:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigjj08882 for ; Mon, 13 Mar 2000 18:56:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigjj22761 for ; Mon, 13 Mar 2000 13:55:55 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigjj20700 for ; Mon, 13 Mar 2000 18:55:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA17419 for mpls@uu.net; Mon, 13 Mar 2000 13:55:53 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigjj08804 for ; Mon, 13 Mar 2000 18:55:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigjj22639 for ; Mon, 13 Mar 2000 13:54:55 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQigjj19793 for ; Mon, 13 Mar 2000 18:54:45 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA29737; Mon, 13 Mar 2000 13:54:35 -0500 (EST) Message-Id: <4.2.2.20000313134730.00ddd100@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 13 Mar 2000 13:50:31 -0500 To: Joan Cucchiara , "'cheenu@tachion.com'" , "'arun@force10networks.com'" From: "Thomas D. Nadeau" Subject: Re: draft-nadeau-mpls-packet-classifier-mib-00.txt comments Cc: mpls@UU.NET In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F842@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_194064616==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_194064616==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Joan, Thanks for your very thorough comments. We will go over them and get back to you and the MPLS group shortly. Let me first say that many of your comments, although warranted, are the result of an initial design, but you probably know that already. ;) It was our intent to get something reasonable out for WG members to look at and comment on. We will be working hard in the future to adjust the MIB to meet the needs of the MPLS WG. --Tom >Tom, Arun and Cheenu, > >I have some questions and comments and concerns on: >draft-nadeau-mpls-packet-classier-mib-00.txt > >General comments >----------------- >* MIB doesn't compile with any of my mib compilers, can >you tell me which one you are using? >* In general, I find the MIB approach to be top-down >which leads to a gap in the logic between the MIB and what >is actually needed to set on the hardware-side in order to >provide for mpls packet classification. You have barely scratched >the surface for ALL MPLS protocols. (it is not clear >from the document that the intent is to provide a way >to support ALL MPLS protocols, but since this references >the LSR MIB, then I assumed this was the case: is that >a correct assumption?) > >It's as if the design was from picturing a GUI screen which has >something called interface and attaching >a bunch of classifier rules to try on the interface. >But this doesn't quite cut it as a MIB which can be >used to actually do this on hardware, at least not >as it is written now. > >For example, when an ifIndex goes away then all the >configuration that is done is GONE. This is NOT >a good design. It is a configuration nightmare. > >Do you really expect that a System Admin person would be >keeping track of all of this? That is paramount to having >a sys admin keep track of every route through an ISP. >And then CONFIGURE for it by knowing the ifIndex at any >point in time. Which is not possible when setting up >redundant LSPs. It is not realistic that a Sys Admin >would do this, do you agree? > >The way you are treating LSPs is as if they are ALL PVC-like, which >may be true in some, but certainly not ALL instances, it is not a >flexible design, and it is not scalable design. It >is a configuration nightmare. > >Furthermore, the use of a DISPLAY strings as indices is not viable >for timely execution on the agent-side. Modeling a >linked list which contains (Integer, DisplayString, >DisplayString) where the only other thing in the table >is RowStatus is also quite a poor design for the agent-side. > >What about redirection to a different LSP? The MIB >doesn't work unless redirection is to an LSP which >has been set up apriori, but what is this based on? >Where is the logic to determine when to redirect and >where to redirect to? Is the System Admin supposed to >know magically when to do this and where? Isn't this better >handled by allowing software algorithms to do redirect >versus a sys admin? Currently, the MIB only allows this >to be configured. Again, this is neither flexible, nor scalable. > >What about mapping back to Labels? (for easy clean up on in a teardown >scenario) > >What about load balancing? Seems like this is NOT supported in >the MIB. > >My greatest concern is that this MIB is completely useless unless >ifIndex a "static, persistent index". By definition, ifIndex doesn't >have to be persistent, especially not through reboots OR DISCONTINUTY >types of situations. > >How on earth can your MIB be done by an implementation >that does NOT make ifIndex persistent? Is your intention to >re-write how IfIndex is used? > >This MIB is not viable because what you are calling >interfaceIndex is not a true ifIndex, OR maybe the expectation is that >someone >will be continually configuring this MIB. Not a job I would want. > >Since the basis of the MIB is mapping packet classifier rule sets to >ifIndex, is this MIB going to allow for INTEROPERABILITY? Right now >it does not! In fact, I would like to see a new rev with a complete >explanation of HOW this MIB will be INTEROPERABLE before seeing >it as adopted as a working group document. It appears to me at least, >that very little thought was actually given to interoperability. > >If the basis of the packet classifier identifier is a DisplayString, then is >this going to be interoperable? Thus, the way you are identifying packet >classifiers has absolutely no meaning, even from devices by the same vendor. >For example, I could have the SAME exact classifier appear several times >under different names, what good is this? > >Section 4. Motivation > >* I was expecting a simply stated goal for >this MIB, which I couldn't find. Is this MIB >intended to be used for all MPLS protocols? > >If so, could you state it plainly? > >* The statement: "Conceptually, some of the >FTN table functionality could be implemented usig >the Forwarding Information Base(FIB) to map all packets >destined to a prefix to an LSP. However, this mapping is >course in nature." > >What is meant by "course in nature", certainly for LDP >this is fine. Again, if the intent of the MIB was >more clearly stated that would be helpful. > >* The last sentence: "...as well as new ones (i.e. classifier >rules?) such as those required by MPLS and Diff-Serv." may >lead the audience to believe that this somehow works with >diff-serv, I didn't see anything in this MIB which was diff-serv >specific, if so could you point this out? > >Also, Diff-serv MIBs are being developed in about 3 different >groups, is it your intention to work with any of these >other efforts? If so, could you elaborate on what the plans >are? > >I would like to see all of the above issues explained, >particularly, the issue of InterfaceIndex and interoperability. >BEFORE it is adopted as a working group document. > >The entire point of having a standard MIB is for interoperability, and >I do not see how this MIB will provide any sort of interoperability >due to the assumptions regarding InterfaceIndex which have been made >but are NOT at all discussed anywhere in the MIB. > >Thank you, > Joan > > --=====================_194064616==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi Joan,

        Thanks for your very thorough comments. We
will go over them and get back to you and the MPLS
group shortly. Let me first say that many of your
comments, although warranted, are the result of an
initial design, but you probably know that
already. ;) It was our intent to get something reasonable
out for WG members to look at and comment on. We
will be working hard in the future to adjust the MIB
to meet the needs of the MPLS WG.

        --Tom


Tom, Arun and Cheenu,

I have some questions and comments and concerns on:
draft-nadeau-mpls-packet-classier-mib-00.txt

General comments
-----------------
* MIB doesn't compile with any of my mib compilers, can
you tell me which one you are using?
* In general, I find the MIB approach to be top-down
which leads to a gap in the logic between the MIB and what
is actually needed to set on the hardware-side in order to
provide for mpls packet classification.  You have barely scratched
the surface for ALL MPLS protocols.  (it is not clear
from the document that the intent is to provide a way
to support ALL MPLS protocols, but since this references
the LSR MIB, then I assumed this was the case: is that
a correct assumption?) 

It's as if the design was from picturing a GUI screen which has
something called interface and attaching
a bunch of classifier rules to try on the interface.
But this doesn't quite cut it as a MIB which can be
used to actually do this on hardware, at least not
as it is written now. 

For example, when an ifIndex goes away then all the
configuration that is done is GONE.  This is NOT
a good design.  It is a configuration nightmare.

Do you really expect that a System Admin person would be
keeping track of all of this?  That is paramount to having
a sys admin keep track of every route through an ISP. 
And then CONFIGURE for it by knowing the ifIndex at any
point in time.  Which is not possible when setting up
redundant LSPs.  It is not realistic that a Sys Admin
would do this, do you agree?

The way you are treating LSPs is as if they are ALL PVC-like, which
may be true in some, but certainly not ALL instances, it is not a
flexible design, and it is  not scalable design.  It
is a configuration nightmare.

Furthermore, the use of a DISPLAY strings as indices is not viable
for timely execution on the agent-side.  Modeling a
linked list which contains (Integer, DisplayString,
DisplayString) where the only other thing in the table
is RowStatus is also quite a poor design for the agent-side.

What about redirection to a different LSP?  The MIB
doesn't work unless redirection is to an LSP which
has been set up apriori, but what is this based on?
Where is the logic to determine when to redirect and
where to redirect to?  Is the System Admin supposed to
know magically when to do this and where?  Isn't this better
handled by allowing software algorithms to do redirect
versus a sys admin?  Currently, the MIB only allows this
to be configured.  Again, this is neither flexible, nor scalable.

What about mapping back to Labels? (for easy clean up on in a teardown
scenario)

What about load balancing?  Seems like this is NOT supported in
the MIB.

My greatest concern is that this MIB is completely useless unless
ifIndex a "static, persistent index".  By definition, ifIndex doesn't
have to be persistent, especially not through reboots OR DISCONTINUTY
types of situations.
 
How on earth can your MIB be done by an implementation
that does NOT make ifIndex persistent?  Is your intention to
re-write how IfIndex is used?

This MIB is not viable because what you are calling
interfaceIndex is not a true ifIndex, OR maybe the expectation is that
someone 
will be continually configuring this MIB. Not a job I would want.

Since the basis of the MIB is mapping packet classifier rule sets to
ifIndex, is this MIB going to allow for INTEROPERABILITY?  Right now
it does not!  In fact, I would like to see a new rev with a complete
explanation of HOW this MIB will be INTEROPERABLE before seeing
it as adopted as a working group document.  It appears to me at least,
that very little thought was actually given to interoperability.

If the basis of the packet classifier identifier is a DisplayString, then is
this going to be interoperable?  Thus, the way you are identifying packet
classifiers has absolutely no meaning, even from devices by the same vendor.
For example, I could have the SAME exact classifier appear several times
under different names, what good is this?

Section 4. Motivation

* I was expecting a simply stated goal for
this MIB, which I couldn't find.  Is this MIB
intended to be used for all MPLS protocols?

If so, could you state it plainly?

* The statement: "Conceptually, some of the
FTN table functionality could be implemented usig
the Forwarding Information Base(FIB) to map all packets
destined to a prefix to an LSP.  However, this mapping is
course in nature."

What is meant by "course in nature", certainly for LDP
this is fine.   Again, if the intent of the MIB was
more clearly stated that would be helpful.

* The last sentence:  "...as well as new ones (i.e. classifier
rules?) such as those required by MPLS and Diff-Serv."  may
lead the audience to believe that this somehow works with
diff-serv, I didn't see anything in this MIB which was diff-serv
specific, if so could you point this out?

Also, Diff-serv MIBs are being developed in about 3 different
groups, is it your intention to work with any of these
other efforts?  If so, could you elaborate on what the plans
are?

I would like to see all of the above issues explained,
particularly, the issue of InterfaceIndex and interoperability.
BEFORE it is adopted as a working group document.

The entire point of having a standard MIB is for interoperability, and
I do not see how this MIB will provide any sort of interoperability
due to the assumptions regarding InterfaceIndex which have been made
but are NOT at all discussed anywhere in the MIB.

Thank you,
 Joan


--=====================_194064616==_.ALT-- From owner-mpls@UU.NET Mon Mar 13 16:36:18 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14404 for ; Mon, 13 Mar 2000 16:36:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigju09622; Mon, 13 Mar 2000 21:36:10 GMT Received: by mail-control.mail.uu.net id QQigju14192 for mpls-outgoing; Mon, 13 Mar 2000 21:35:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigju14187 for ; Mon, 13 Mar 2000 21:35:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigju29975 for ; Mon, 13 Mar 2000 16:35:24 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigju08950 for ; Mon, 13 Mar 2000 21:35:23 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id QAA24546; Mon, 13 Mar 2000 16:30:38 -0500 Message-ID: <38CD5FB3.9F7E846@tellium.com> Date: Mon, 13 Mar 2000 16:37:55 -0500 From: Bo Tang X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: [Fwd: [Fwd: I-D ACTION:draft-tang-crldp-optical-00.txt]] Content-Type: multipart/mixed; boundary="------------A03A786A628E952A32C776DE" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------A03A786A628E952A32C776DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------A03A786A628E952A32C776DE Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id QAA24371; Mon, 13 Mar 2000 16:26:09 -0500 Message-ID: <38CD5FC3.60C78914@tellium.com> Date: Mon, 13 Mar 2000 16:38:11 -0500 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bo Tang Subject: [Fwd: I-D ACTION:draft-tang-crldp-optical-00.txt] Content-Type: multipart/mixed; boundary="------------18C3D4E699AA5D2FB8DD7B11" X-Mozilla-Status2: 00000000 This is a multi-part message in MIME format. --------------18C3D4E699AA5D2FB8DD7B11 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com --------------18C3D4E699AA5D2FB8DD7B11 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from loki.ietf.org by alpha.tellium.com (SMI-8.6/SMI-SVR4) id IAA14317; Tue, 7 Mar 2000 08:10:56 -0500 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA07193 for ietf-123-outbound.05@ietf.org; Tue, 7 Mar 2000 07:55:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA06362 for ; Tue, 7 Mar 2000 06:28:50 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28984 for ; Tue, 7 Mar 2000 06:28:50 -0500 (EST) Message-Id: <200003071128.GAA28984@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@loki.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-tang-crldp-optical-00.txt Date: Tue, 07 Mar 2000 06:28:50 -0500 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to CR-LDP for Path Establishment in Optical Networks Author(s) : Z. Tang, D. Saha, B. Rajagopalan Filename : draft-tang-crldp-optical-00.txt Pages : 7 Date : 06-Mar-00 This draft describes the extensions to the CR-LDP for establishing optical switched paths (OSP). This document does not advocate CR-LDP as the sole mechanism for setting up such paths. RSVP extensions for path set-up are described in [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tang-crldp-optical-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-tang-crldp-optical-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-tang-crldp-optical-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000306120359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tang-crldp-optical-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-tang-crldp-optical-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000306120359.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------18C3D4E699AA5D2FB8DD7B11-- --------------A03A786A628E952A32C776DE-- From owner-mpls@UU.NET Tue Mar 14 06:22:29 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20672 for ; Tue, 14 Mar 2000 06:22:29 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiglx23206; Tue, 14 Mar 2000 11:22:28 GMT Received: by mail-control.mail.uu.net id QQiglx13192 for mpls-outgoing; Tue, 14 Mar 2000 11:22:05 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiglx13187 for ; Tue, 14 Mar 2000 11:21:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiglx03780 for ; Tue, 14 Mar 2000 06:21:49 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiglx29687 for ; Tue, 14 Mar 2000 11:21:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA02279 for mpls@uu.net; Tue, 14 Mar 2000 06:21:48 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiglx12985 for ; Tue, 14 Mar 2000 11:21:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiglx26415 for ; Tue, 14 Mar 2000 06:20:50 -0500 (EST) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQiglx29120 for ; Tue, 14 Mar 2000 11:20:50 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20015; Tue, 14 Mar 2000 06:20:49 -0500 (EST) Message-Id: <200003141120.GAA20015@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-diff-ext-04.txt Date: Tue, 14 Mar 2000 06:20:48 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Support of Differentiated Services Author(s) : F. Le Faucheur, L. Wu, B. Davie ,S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen Filename : draft-ietf-mpls-diff-ext-04.txt Pages : 49 Date : 13-Mar-00 This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-diff-ext-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-diff-ext-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000313135931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-diff-ext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-diff-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000313135931.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Mar 14 10:24:51 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25379 for ; Tue, 14 Mar 2000 10:24:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigmn14142; Tue, 14 Mar 2000 15:24:43 GMT Received: by mail-control.mail.uu.net id QQigmn00292 for mpls-outgoing; Tue, 14 Mar 2000 15:24:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigmn00286 for ; Tue, 14 Mar 2000 15:24:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigmn28890 for ; Tue, 14 Mar 2000 10:23:52 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigmn13531 for ; Tue, 14 Mar 2000 15:23:51 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA22642 for mpls@uu.net; Tue, 14 Mar 2000 10:23:50 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigmn00250 for ; Tue, 14 Mar 2000 15:23:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigmn22646 for ; Tue, 14 Mar 2000 10:23:12 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQigmn05139 for ; Tue, 14 Mar 2000 15:23:11 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Mar 2000 10:21:30 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F84F@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Thomas D. Nadeau'" , Joan Cucchiara , "'cheenu@tachion.com'" , "'arun@force10networks.com'" Cc: mpls@UU.NET Subject: RE: draft-nadeau-mpls-packet-classifier-mib-00.txt comments Date: Tue, 14 Mar 2000 10:21:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8DC8.F8CB679E" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8DC8.F8CB679E Content-Type: text/plain; charset="iso-8859-1" Tom, The MIB design is quite seriously flawed to the point that it is not interoperable. As I said, the use of InterfaceIndex is inappropriate, and needs to be replaced by something along the lines of a "physical entity", or some other more concrete model. Another alternative would be to tie these PVC-like LSPs directly to classifiers similar to the way that Traffic Descriptors are tied to VPL/VCLs in the AToM MIB. Those ideas are just of the top of my head, and are not offered as suggestions, but merely to point out that this MIB needs to be redesigned. The issue isn't that this is an initial design and has some small issues because it was rushed to get in under a deadline; the issue is that the MIB design is seriously flawed and I would like to see a redesign prior to accepting this document as a working group document. I'm not asking for perfection, but it is clear to me that the design is flawed to begin with and more text and more objects aren't going to correct this. It needs a redesign, and that is what I'm asking for. -Thanks, Joan -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Monday, March 13, 2000 1:51 PM To: Joan Cucchiara; 'cheenu@tachion.com'; 'arun@force10networks.com' Cc: mpls@UU.NET Subject: Re: draft-nadeau-mpls-packet-classifier-mib-00.txt comments Hi Joan, Thanks for your very thorough comments. We will go over them and get back to you and the MPLS group shortly. Let me first say that many of your comments, although warranted, are the result of an initial design, but you probably know that already. ;) It was our intent to get something reasonable out for WG members to look at and comment on. We will be working hard in the future to adjust the MIB to meet the needs of the MPLS WG. --Tom Tom, Arun and Cheenu, I have some questions and comments and concerns on: draft-nadeau-mpls-packet-classier-mib-00.txt General comments ----------------- * MIB doesn't compile with any of my mib compilers, can you tell me which one you are using? * In general, I find the MIB approach to be top-down which leads to a gap in the logic between the MIB and what is actually needed to set on the hardware-side in order to provide for mpls packet classification. You have barely scratched the surface for ALL MPLS protocols. (it is not clear from the document that the intent is to provide a way to support ALL MPLS protocols, but since this references the LSR MIB, then I assumed this was the case: is that a correct assumption?) It's as if the design was from picturing a GUI screen which has something called interface and attaching a bunch of classifier rules to try on the interface. But this doesn't quite cut it as a MIB which can be used to actually do this on hardware, at least not as it is written now. For example, when an ifIndex goes away then all the configuration that is done is GONE. This is NOT a good design. It is a configuration nightmare. Do you really expect that a System Admin person would be keeping track of all of this? That is paramount to having a sys admin keep track of every route through an ISP. And then CONFIGURE for it by knowing the ifIndex at any point in time. Which is not possible when setting up redundant LSPs. It is not realistic that a Sys Admin would do this, do you agree? The way you are treating LSPs is as if they are ALL PVC-like, which may be true in some, but certainly not ALL instances, it is not a flexible design, and it is not scalable design. It is a configuration nightmare. Furthermore, the use of a DISPLAY strings as indices is not viable for timely execution on the agent-side. Modeling a linked list which contains (Integer, DisplayString, DisplayString) where the only other thing in the table is RowStatus is also quite a poor design for the agent-side. What about redirection to a different LSP? The MIB doesn't work unless redirection is to an LSP which has been set up apriori, but what is this based on? Where is the logic to determine when to redirect and where to redirect to? Is the System Admin supposed to know magically when to do this and where? Isn't this better handled by allowing software algorithms to do redirect versus a sys admin? Currently, the MIB only allows this to be configured. Again, this is neither flexible, nor scalable. What about mapping back to Labels? (for easy clean up on in a teardown scenario) What about load balancing? Seems like this is NOT supported in the MIB. My greatest concern is that this MIB is completely useless unless ifIndex a "static, persistent index". By definition, ifIndex doesn't have to be persistent, especially not through reboots OR DISCONTINUTY types of situations. How on earth can your MIB be done by an implementation that does NOT make ifIndex persistent? Is your intention to re-write how IfIndex is used? This MIB is not viable because what you are calling interfaceIndex is not a true ifIndex, OR maybe the expectation is that someone will be continually configuring this MIB. Not a job I would want. Since the basis of the MIB is mapping packet classifier rule sets to ifIndex, is this MIB going to allow for INTEROPERABILITY? Right now it does not! In fact, I would like to see a new rev with a complete explanation of HOW this MIB will be INTEROPERABLE before seeing it as adopted as a working group document. It appears to me at least, that very little thought was actually given to interoperability. If the basis of the packet classifier identifier is a DisplayString, then is this going to be interoperable? Thus, the way you are identifying packet classifiers has absolutely no meaning, even from devices by the same vendor. For example, I could have the SAME exact classifier appear several times under different names, what good is this? Section 4. Motivation * I was expecting a simply stated goal for this MIB, which I couldn't find. Is this MIB intended to be used for all MPLS protocols? If so, could you state it plainly? * The statement: "Conceptually, some of the FTN table functionality could be implemented usig the Forwarding Information Base(FIB) to map all packets destined to a prefix to an LSP. However, this mapping is course in nature." What is meant by "course in nature", certainly for LDP this is fine. Again, if the intent of the MIB was more clearly stated that would be helpful. * The last sentence: "...as well as new ones (i.e. classifier rules?) such as those required by MPLS and Diff-Serv." may lead the audience to believe that this somehow works with diff-serv, I didn't see anything in this MIB which was diff-serv specific, if so could you point this out? Also, Diff-serv MIBs are being developed in about 3 different groups, is it your intention to work with any of these other efforts? If so, could you elaborate on what the plans are? I would like to see all of the above issues explained, particularly, the issue of InterfaceIndex and interoperability. BEFORE it is adopted as a working group document. The entire point of having a standard MIB is for interoperability, and I do not see how this MIB will provide any sort of interoperability due to the assumptions regarding InterfaceIndex which have been made but are NOT at all discussed anywhere in the MIB. Thank you, Joan ------_=_NextPart_001_01BF8DC8.F8CB679E Content-Type: text/html; charset="iso-8859-1"
 
Tom,
 
The MIB design is quite seriously flawed to the point
that it is not interoperable.
 
As I said, the use of InterfaceIndex is inappropriate,
and needs to be replaced by something along the
lines of a "physical entity", or some other more 
concrete model.   Another alternative would be to
tie these PVC-like LSPs directly to classifiers
similar to the way that Traffic Descriptors are
tied to VPL/VCLs in the AToM MIB.
 
Those ideas are just of the top of my head, and are
not offered as suggestions, but merely to point out
that this MIB needs to be redesigned. 
 
The issue isn't that this is an initial design and has some small
issues because it was rushed to get in under a deadline;
the issue is that the MIB design is seriously flawed and
I would like to see a redesign prior to accepting
this document as a working group document.   I'm not 
asking for perfection, but it is clear to me that the design
is flawed to begin with and more text and more objects
aren't going to correct this.  It needs a redesign, and that
is what I'm asking for.  
 
-Thanks, Joan
 
-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Monday, March 13, 2000 1:51 PM
To: Joan Cucchiara; 'cheenu@tachion.com'; 'arun@force10networks.com'
Cc: mpls@UU.NET
Subject: Re: draft-nadeau-mpls-packet-classifier-mib-00.txt comments


        Hi Joan,

        Thanks for your very thorough comments. We
will go over them and get back to you and the MPLS
group shortly. Let me first say that many of your
comments, although warranted, are the result of an
initial design, but you probably know that
already. ;) It was our intent to get something reasonable
out for WG members to look at and comment on. We
will be working hard in the future to adjust the MIB
to meet the needs of the MPLS WG.

        --Tom


Tom, Arun and Cheenu,

I have some questions and comments and concerns on:
draft-nadeau-mpls-packet-classier-mib-00.txt

General comments
-----------------
* MIB doesn't compile with any of my mib compilers, can
you tell me which one you are using?
* In general, I find the MIB approach to be top-down
which leads to a gap in the logic between the MIB and what
is actually needed to set on the hardware-side in order to
provide for mpls packet classification.  You have barely scratched
the surface for ALL MPLS protocols.  (it is not clear
from the document that the intent is to provide a way
to support ALL MPLS protocols, but since this references
the LSR MIB, then I assumed this was the case: is that
a correct assumption?) 

It's as if the design was from picturing a GUI screen which has
something called interface and attaching
a bunch of classifier rules to try on the interface.
But this doesn't quite cut it as a MIB which can be
used to actually do this on hardware, at least not
as it is written now. 

For example, when an ifIndex goes away then all the
configuration that is done is GONE.  This is NOT
a good design.  It is a configuration nightmare.

Do you really expect that a System Admin person would be
keeping track of all of this?  That is paramount to having
a sys admin keep track of every route through an ISP. 
And then CONFIGURE for it by knowing the ifIndex at any
point in time.  Which is not possible when setting up
redundant LSPs.  It is not realistic that a Sys Admin
would do this, do you agree?

The way you are treating LSPs is as if they are ALL PVC-like, which
may be true in some, but certainly not ALL instances, it is not a
flexible design, and it is  not scalable design.  It
is a configuration nightmare.

Furthermore, the use of a DISPLAY strings as indices is not viable
for timely execution on the agent-side.  Modeling a
linked list which contains (Integer, DisplayString,
DisplayString) where the only other thing in the table
is RowStatus is also quite a poor design for the agent-side.

What about redirection to a different LSP?  The MIB
doesn't work unless redirection is to an LSP which
has been set up apriori, but what is this based on?
Where is the logic to determine when to redirect and
where to redirect to?  Is the System Admin supposed to
know magically when to do this and where?  Isn't this better
handled by allowing software algorithms to do redirect
versus a sys admin?  Currently, the MIB only allows this
to be configured.  Again, this is neither flexible, nor scalable.

What about mapping back to Labels? (for easy clean up on in a teardown
scenario)

What about load balancing?  Seems like this is NOT supported in
the MIB.

My greatest concern is that this MIB is completely useless unless
ifIndex a "static, persistent index".  By definition, ifIndex doesn't
have to be persistent, especially not through reboots OR DISCONTINUTY
types of situations.
 
How on earth can your MIB be done by an implementation
that does NOT make ifIndex persistent?  Is your intention to
re-write how IfIndex is used?

This MIB is not viable because what you are calling
interfaceIndex is not a true ifIndex, OR maybe the expectation is that
someone 
will be continually configuring this MIB. Not a job I would want.

Since the basis of the MIB is mapping packet classifier rule sets to
ifIndex, is this MIB going to allow for INTEROPERABILITY?  Right now
it does not!  In fact, I would like to see a new rev with a complete
explanation of HOW this MIB will be INTEROPERABLE before seeing
it as adopted as a working group document.  It appears to me at least,
that very little thought was actually given to interoperability.

If the basis of the packet classifier identifier is a DisplayString, then is
this going to be interoperable?  Thus, the way you are identifying packet
classifiers has absolutely no meaning, even from devices by the same vendor.
For example, I could have the SAME exact classifier appear several times
under different names, what good is this?

Section 4. Motivation

* I was expecting a simply stated goal for
this MIB, which I couldn't find.  Is this MIB
intended to be used for all MPLS protocols?

If so, could you state it plainly?

* The statement: "Conceptually, some of the
FTN table functionality could be implemented usig
the Forwarding Information Base(FIB) to map all packets
destined to a prefix to an LSP.  However, this mapping is
course in nature."

What is meant by "course in nature", certainly for LDP
this is fine.   Again, if the intent of the MIB was
more clearly stated that would be helpful.

* The last sentence:  "...as well as new ones (i.e. classifier
rules?) such as those required by MPLS and Diff-Serv."  may
lead the audience to believe that this somehow works with
diff-serv, I didn't see anything in this MIB which was diff-serv
specific, if so could you point this out?

Also, Diff-serv MIBs are being developed in about 3 different
groups, is it your intention to work with any of these
other efforts?  If so, could you elaborate on what the plans
are?

I would like to see all of the above issues explained,
particularly, the issue of InterfaceIndex and interoperability.
BEFORE it is adopted as a working group document.

The entire point of having a standard MIB is for interoperability, and
I do not see how this MIB will provide any sort of interoperability
due to the assumptions regarding InterfaceIndex which have been made
but are NOT at all discussed anywhere in the MIB.

Thank you,
 Joan


------_=_NextPart_001_01BF8DC8.F8CB679E-- From owner-mpls@UU.NET Tue Mar 14 12:37:10 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19380 for ; Tue, 14 Mar 2000 12:37:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigmw21276; Tue, 14 Mar 2000 17:37:08 GMT Received: by mail-control.mail.uu.net id QQigmw24520 for mpls-outgoing; Tue, 14 Mar 2000 17:36:36 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigmw24515 for ; Tue, 14 Mar 2000 17:36:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigmw18877 for ; Tue, 14 Mar 2000 12:36:01 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQigmw20399 for ; Tue, 14 Mar 2000 17:36:00 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA07065 for ; Tue, 14 Mar 2000 10:01:20 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA21416 for mpls@uu.net; Tue, 14 Mar 2000 12:35:50 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigmv23558 for ; Tue, 14 Mar 2000 17:18:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigmv16528 for ; Tue, 14 Mar 2000 12:18:02 -0500 (EST) Received: from tnnt3.tachion.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQigmv27900 for ; Tue, 14 Mar 2000 17:18:01 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Mar 2000 12:19:07 -0500 Message-ID: <633D356A20D0D311BBC1009027DC856C0260C9@TNNT3> From: Cheenu Srinivasan To: mpls@UU.NET Cc: "'swallow@cisco.com'" , "Arun Viswanathan (E-mail)" , rschmitt@cisco.com, jluciani@tollbridgetech.com, hans.sjostrand@etx.ericsson.se, jcucchiara@brixnet.com, "'Thomas D. Nadeau'" , Vijay Srinivasan Subject: RE: LDP MIB last call Date: Tue, 14 Mar 2000 12:19:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I have the same objections to the current LDP MIB as Tom. The LIB and the FEC tables are not specific to LDP and do not belong here. The first one is part of the LSR MIB already and the second one should be in a seperate packet classifier MIB. They should be removed before the LDP MIB goes to last call. I have seen several messages on this topic but no response from the authors thus far. Thanks, Cheenu Srinivasan -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Friday, March 10, 2000 7:18 AM To: Vijay Srinivasan; mpls@uu.net Cc: 'swallow@cisco.com'; Cheenu Srinivasan; Arun Viswanathan (E-mail); Thomas D. Nadeau (E-mail); rschmitt@cisco.com; jluciani@tollbridgetech.com; hans.sjostrand@etx.ericsson.se; jcucchiara@brixnet.com Subject: Re: LDP MIB last call I still have two major objections to the current state of the LDP MIB. There are two tables: the LIB and the FEC tables, which I and the authors of the TE/LSR MIBs would like removed. Rob Schmitt also requested that these tables be removed prior to version -05 of the MIB. These tables are at least in part, redundant to that which is present in the LSR MIB. I have posted several messages to the mailing list requesting discussion on this issue, and both times I have not received any responses from the authors, nor have they replied to the mailing list. I will ask again for this discussion to commence. --Tom We would like to commence the last call for: Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) draft-ietf-mpls-ldp-mib-05.txt Last call will end on Friday, March 17. Please send your comments to the list. Regards, - Vijay From owner-mpls@UU.NET Tue Mar 14 13:35:22 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11088 for ; Tue, 14 Mar 2000 13:35:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigna27208; Tue, 14 Mar 2000 18:35:11 GMT Received: by mail-control.mail.uu.net id QQigna05547 for mpls-outgoing; Tue, 14 Mar 2000 18:34:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigna05540 for ; Tue, 14 Mar 2000 18:34:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigna26267 for ; Tue, 14 Mar 2000 13:34:22 -0500 (EST) Received: from lobster.baynetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns3.BayNetworks.COM [192.32.253.3]) id QQigna26607 for ; Tue, 14 Mar 2000 18:34:19 GMT Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id NAA21969; Tue, 14 Mar 2000 13:36:51 -0500 (EST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id NAA24496; Tue, 14 Mar 2000 13:37:23 -0500 (EST) Received: from bubba.engeast (bubba [192.168.136.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id NAA29154; Tue, 14 Mar 2000 13:32:44 -0500 for Received: by bubba.engeast (SMI-8.6/SMI-SVR4) id NAA15216; Tue, 14 Mar 2000 13:32:44 -0500 From: dwilder@baynetworks.com (David Wilder) Message-Id: <200003141832.NAA15216@bubba.engeast> Subject: Re: LDP MIB last call In-Reply-To: <633D356A20D0D311BBC1009027DC856C0260C9@TNNT3> from Cheenu Srinivasan at "Mar 14, 2000 12:19:06 pm" To: Cheenu Srinivasan Date: Tue, 14 Mar 2000 13:32:43 -0500 (EST) CC: mpls@UU.NET, "'swallow@cisco.com'" , "Arun Viswanathan (E-mail)" , rschmitt@cisco.com, jluciani@tollbridgetech.com, hans.sjostrand@etx.ericsson.se, jcucchiara@brixnet.com, "'Thomas D. Nadeau'" , Vijay Srinivasan X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Cheenu, Isn't it a little premature to remove those tables from the LDP MIB when there has not been an acceptable alternative? I'd rather a little redundancy than the to use the new proposed MIB which hasn't had the scrutiny that the LDP MIB has had. Dave [Charset iso-8859-1 unsupported, filtering to ASCII...] > I have the same objections to the current LDP MIB as Tom. The LIB > and the FEC tables are not specific to LDP and do not belong here. > The first one is part of the LSR MIB already and the second one > should be in a seperate packet classifier MIB. They should be removed > before the LDP MIB goes to last call. > > I have seen several messages on this topic but no response from the > authors thus far. > > Thanks, > Cheenu Srinivasan > > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Friday, March 10, 2000 7:18 AM > To: Vijay Srinivasan; mpls@uu.net > Cc: 'swallow@cisco.com'; Cheenu Srinivasan; Arun Viswanathan (E-mail); > Thomas D. Nadeau (E-mail); rschmitt@cisco.com; jluciani@tollbridgetech.com; > hans.sjostrand@etx.ericsson.se; jcucchiara@brixnet.com > Subject: Re: LDP MIB last call > > > > I still have two major objections to the current > state of the LDP MIB. There are two tables: the LIB > and the FEC tables, which I and the authors of the > TE/LSR MIBs would like removed. Rob Schmitt also > requested that these tables be removed prior to > version -05 of the MIB. These tables are at least in > part, redundant to that which is present in the LSR > MIB. I have posted several messages to the mailing list > requesting discussion on this issue, and both times > I have not received any responses from the authors, nor > have they replied to the mailing list. I will ask again for > this discussion to commence. > > --Tom > > > > > We would like to commence the last call for: > > Definitions of Managed Objects for the Multiprotocol Label Switching, Label > Distribution Protocol (LDP) > draft-ietf-mpls-ldp-mib-05.txt > > Last call will end on Friday, March 17. Please send your comments to the > list. > > Regards, > - Vijay > From owner-mpls@UU.NET Tue Mar 14 14:27:30 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02152 for ; Tue, 14 Mar 2000 14:27:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQignd05274; Tue, 14 Mar 2000 19:27:20 GMT Received: by mail-control.mail.uu.net id QQignd16640 for mpls-outgoing; Tue, 14 Mar 2000 19:27:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQignd16635 for ; Tue, 14 Mar 2000 19:26:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQignd03135 for ; Tue, 14 Mar 2000 14:26:42 -0500 (EST) Received: from hercules by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQignd04805 for ; Tue, 14 Mar 2000 19:26:42 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id LAA29987; Tue, 14 Mar 2000 11:23:51 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Mar 2000 11:23:51 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A6346825@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'David Wilder'" , "'Cheenu Srinivasan'" Cc: "'mpls@UU.NET'" , "'swallow@cisco.com'" , "'Arun Viswanathan (E-mail)'" , "'rschmitt@cisco.com'" , "'jluciani@tollbridgetech.com'" , "'hans.sjostrand@etx.ericsson.se'" , "'jcucchiara@brixnet.com'" , "'Thomas D. Nadeau'" , "'Vijay Srinivasan'" Subject: RE: LDP MIB last call Date: Tue, 14 Mar 2000 11:23:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I think there are two separate issues here. First is the self-contained LSR table in the LDP MIB. I believe this must go. The LSR MIB has been around for a while and has been through several rounds of scrutiny. The LDP MIB needs only to point to a cross-connect entry in the LSR MIB and be done with. The second issue here is that of the FEC in the LDP MIB. The proposed packet-classifier MIB was primarily designed for redirecting traffic into MPLS tunnels at the head-end. The FEC requirements in the LDP MIB is more like extending the FIB MIB (rfc2096?) with label information. The right way to address the LDP requirement IMHO would be to extend the FIB MIB to include label information. The packet-classifier does encompass this functionality in a way, however, I can understand the debate over the second issue. -arun > -----Original Message----- > From: David Wilder [mailto:dwilder@baynetworks.com] > Sent: Tuesday, March 14, 2000 10:33 AM > To: Cheenu Srinivasan > Cc: mpls@UU.NET; 'swallow@cisco.com'; Arun Viswanathan (E-mail); > rschmitt@cisco.com; jluciani@tollbridgetech.com; > hans.sjostrand@etx.ericsson.se; jcucchiara@brixnet.com; 'Thomas D. > Nadeau'; Vijay Srinivasan > Subject: Re: LDP MIB last call > > > Cheenu, > > Isn't it a little premature to remove those tables from the > LDP MIB when there > has not been an acceptable alternative? I'd rather a little > redundancy than > the to use the new proposed MIB which hasn't had the scrutiny > that the LDP > MIB has had. > > Dave > > > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > I have the same objections to the current LDP MIB as Tom. The LIB > > and the FEC tables are not specific to LDP and do not belong here. > > The first one is part of the LSR MIB already and the second one > > should be in a seperate packet classifier MIB. They should > be removed > > before the LDP MIB goes to last call. > > > > I have seen several messages on this topic but no response from the > > authors thus far. > > > > Thanks, > > Cheenu Srinivasan > > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Friday, March 10, 2000 7:18 AM > > To: Vijay Srinivasan; mpls@uu.net > > Cc: 'swallow@cisco.com'; Cheenu Srinivasan; Arun > Viswanathan (E-mail); > > Thomas D. Nadeau (E-mail); rschmitt@cisco.com; > jluciani@tollbridgetech.com; > > hans.sjostrand@etx.ericsson.se; jcucchiara@brixnet.com > > Subject: Re: LDP MIB last call > > > > > > > > I still have two major objections to the current > > state of the LDP MIB. There are two tables: the LIB > > and the FEC tables, which I and the authors of the > > TE/LSR MIBs would like removed. Rob Schmitt also > > requested that these tables be removed prior to > > version -05 of the MIB. These tables are at least in > > part, redundant to that which is present in the LSR > > MIB. I have posted several messages to the mailing list > > requesting discussion on this issue, and both times > > I have not received any responses from the authors, nor > > have they replied to the mailing list. I will ask again for > > this discussion to commence. > > > > --Tom > > > > > > > > > > We would like to commence the last call for: > > > > Definitions of Managed Objects for the Multiprotocol Label > Switching, Label > > Distribution Protocol (LDP) > > draft-ietf-mpls-ldp-mib-05.txt > > > > Last call will end on Friday, March 17. Please send your > comments to the > > list. > > > > Regards, > > - Vijay > > > > From owner-mpls@UU.NET Tue Mar 14 16:34:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22859 for ; Tue, 14 Mar 2000 16:34:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQignm28072; Tue, 14 Mar 2000 21:34:37 GMT Received: by mail-control.mail.uu.net id QQignm10546 for mpls-outgoing; Tue, 14 Mar 2000 21:34:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQignm10541 for ; Tue, 14 Mar 2000 21:34:01 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQignm25004 for ; Tue, 14 Mar 2000 16:33:23 -0500 (EST) Received: from exchsrv1.cosinecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQignm26866 for ; Tue, 14 Mar 2000 21:33:22 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Mar 2000 13:33:19 -0800 Message-ID: From: Vijay Srinivasan To: "'mpls@uu.net'" Subject: revised charter for MPLS WG Date: Tue, 14 Mar 2000 13:33:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8DFC.EA9279EA" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8DFC.EA9279EA Content-Type: text/plain; charset="iso-8859-1" Here is an update of the WG charter. There weren't many comments on the list -- the main comments were: Item 1. Support for Aggregated QoS Andy Malis (amalis@lucent.com) >8. Define the use of Differentiated and Integrated Services in an MPLS >environment. I suggest the above objective be changed to "aggregated QoS", as discussed in November. There was not much discussion this subject matter. George Swallow felt such a change would limit the charter, while Grenville Armitage felt the current wording limits the charter to two specific QoS models. I have reworded the objective to read: 8. Define the support of Differentiated and Integrated Services, including aggregated QoS, in an MPLS environment. Item 2. Liaison with other standards bodies Andy Malis (amalis@lucent.com) On a different charter topic, I think the charter should specifically mention that the WG plans to liaise with other standards bodies, especially in the optical area, such as OIF, ITU-T, ANSI, ODSI, etc.. There was no consensus on this issue. However, ODSI was added to the list of standard bodies already mentioned in the charter. If a formal liaison is required with a particular standards body, the IAB will be contacted to set one up. Item 3. Division of work between TE-WG and MPLS WG Philip Matthews Should the new charter contain some words about the division of work between the MPLS WG and the TE WG? There was no further discussion on this subject. The charter currently does not address this subject. Item 4. LSP Recovery Vishal Sharma (Vishal.Sharma@tellabs.com) I would like to suggest adding the following as a milestone: Produce specifications for protocols and procedures that support LSP recovery A milestone has been added for this. ---------------------------------------------------------------------------- ---------- Multiprotocol Label Switching (mpls) Charter Problem Statement: Label switching in conjunction with network layer routing has emerged as an important new technology. It is actively being applied to applications such as traffic engineering and virtual private networks. Among the problems this technology is expected to address are the following: 1. Greater flexibility in delivering routing services Using labels to identify particular traffic which are to receive special services, e.g. QoS. Using labels to provide forwarding along an explicit path different from the one constructed by destination-based forwarding. 2. Scalability of network layer routing Using labels as a means to aggregate forwarding information, while working in the presence of routing hierarchies. 3. Simplify integration of routers with cell switching based technologies a) making cell switches behave as peers to routers (thus reducing the number of routing peers that a router has to maintain), b) by making information about physical topology available to Network Layer routing procedures, and c) by employing common addressing, routing, and management procedures. 4. Simplify integration of routers with optical cross-connect based technologies a) making optical cross connects behave as peers to routers (thus reducing the number of routing peers that a router has to maintain), b) by making information about physical topology available to Network Layer routing procedures, and c) by employing common addressing, routing, and management procedures. High Level Requirements 1. The solution should be general with respect to data link technologies. Specific optimizations for particular media will be considered. 2. The solution must be compatible with existing internetwork technologies and routing protocols. 3. The solution should support a wide range of forwarding granularities associated with a given label, from a single application flow to a group of topologically related destinations. 4. The solution should support operations, administration, and maintenance facilities at least as extensive as those supported in IP networks. 5. The solution should provide stable routing. The protocols defined by MPLS must provide protocol mechanism(s) to either prevent the formation of loops and/or contain the amount of (networking) resources that could be consumed due to the presence of such loops. 6. The solution should be very scalable. Scalability issues will be considered and analyzed. Charter Statement: The working group is responsible for standardizing a base technology for using label switching in conjunction with network layer routing and for the implementation of that technology over various link level technologies, which may include Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,... This includes procedures and protocols for the distribution of labels between routers, encapsulations, multicast considerations, and the use of labels to support higher layer resource reservation and QoS mechanisms. The working group will also specify a control plane for optical cross connects. In this environment specific wave lengths or Lambdas are used instead of labels. Objectives: 1. Specify standard protocol(s) for maintenance and distribution of label binding information to support unicast destination-based routing. 2. Specify standard protocol(s) for maintenance and distribution of label binding information to support multicast routing. 3. Specify standard protocol(s) for maintenance and distribution of label binding information to support hierarchy of routing knowledge (e.g., complete segregation of intra and inter-domain routing). 4. Specify standard protocol(s) for maintenance and distribution of label binding information to support explicit paths in support of applications such as Traffic Engineering. 5. Specify standard protocols and procedures to support the fast recovery of Label Switched Paths. 6. Specify extensions to the protocols and procedures used for signaling explicit routes and to effect fast recovery of LSPs for use in Optical Cross Connects. 7. Specify standard procedures of carrying label information over various link level technologies including ATM. 8. Define the support of Differentiated and Integrated Services, including aggregated QoS, in an MPLS environment. 9. Specify standard protocols and procedures to support operations, administration, and maintenance facilities. Coordination: The working group will coordinate its activities with other working groups as appropriate. For specific technologies, the WG will cooperate with the appropriate standards bodies such as OIF, ITU-T, ANSI, ODSI etc. Goals and Milestones: Mar 00 - Produce a document which defines support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks (Standards Track). Aug 00 - Produce a document which defines operation with RSVP for unicast destinations. (Standards Track). Aug 00 - Produce specifications for protocols and procedures that support fault recovery in an MPLS environment Dec 00 - Produce specifications for a MPLS control plane for optical cross-connects (Standards Track). ------_=_NextPart_001_01BF8DFC.EA9279EA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable revised charter for MPLS WG

Here is an update of the WG = charter.  There weren't many comments on the
list -- the main comments = were:

Item 1. Support for Aggregated = QoS

   Andy Malis = (amalis@lucent.com)
   >8.  = Define the use of Differentiated and Integrated Services in an = MPLS
   = >environment.

   I suggest the above = objective be changed to "aggregated QoS", as discussed =
   in = November.

There was not much discussion = this subject matter.  George Swallow felt such
a change would limit the = charter, while Grenville Armitage felt the current
wording limits the charter to = two specific QoS models.

I have reworded the objective to = read:

   8.  Define the = support of Differentiated and Integrated Services,
including aggregated QoS, in an = MPLS environment.

Item 2. Liaison with other = standards bodies

   Andy Malis = (amalis@lucent.com)
   On a different = charter topic, I think the charter should specifically
   mention that the = WG plans to liaise with other standards bodies, especially
   in the optical = area, such as OIF, ITU-T, ANSI, ODSI, etc..

There was no consensus on this = issue.  However, ODSI was added to the list
of standard bodies already = mentioned in the charter.  If a formal liaison
is required with a particular = standards body, the IAB will be contacted
to set one up.

Item 3. Division of work between = TE-WG and MPLS WG

   Philip Matthews = <philipma@nortelnetworks.com>
   Should the new = charter contain some words about the
   division of work = between the MPLS WG and the TE WG?

There was no further discussion = on this subject.  The charter currently
does not address this = subject.

Item 4. LSP Recovery

   Vishal Sharma = (Vishal.Sharma@tellabs.com)
   I would like to = suggest adding the following as a milestone:

   Produce = specifications for protocols and procedures that support
   LSP = recovery

A milestone has been added for = this.

-------------------------------------------------------------------= -------------------

Multiprotocol Label Switching = (mpls) Charter


Problem Statement:

Label switching in conjunction = with network layer routing has emerged
as an important new = technology.  It is actively being applied to
applications such as traffic = engineering and virtual private networks.
Among the problems this = technology is expected to address are the
following:

1.  Greater flexibility in = delivering routing services

Using labels to identify = particular traffic which are to receive
special services, e.g. = QoS.

Using labels to provide = forwarding along an explicit path different
from the one constructed by = destination-based forwarding.

2.  Scalability of network = layer routing

Using labels as a means to = aggregate forwarding information, while
working in the presence of = routing hierarchies.

3.  Simplify integration of = routers with cell switching based
technologies

a) making cell switches behave = as peers to routers (thus reducing
the number of routing peers = that a  router has to maintain),

b) by making information about = physical topology available to
Network Layer routing = procedures, and

c) by employing common = addressing, routing, and management
procedures.

4.  Simplify integration of = routers with optical cross-connect based
technologies

a) making optical cross connects = behave as peers to routers (thus
reducing the number of routing = peers that a router has to maintain),

b) by making information about = physical topology available to
Network Layer routing = procedures, and

c) by employing common = addressing, routing, and management
procedures.

High Level Requirements

1.  The solution should be = general with respect to data link
technologies. Specific = optimizations for particular media will be
considered.

2.  The solution must be = compatible with existing internetwork
technologies and routing = protocols.

3.  The solution should = support a wide range of forwarding
granularities associated with a = given label, from a single
application flow to a group of = topologically related destinations.

4.  The solution should = support operations, administration, and
maintenance facilities at least = as extensive as those supported in
IP networks.

5.  The solution should = provide stable routing.  The protocols defined
by MPLS must provide protocol = mechanism(s) to either prevent the
formation of loops and/or = contain the amount of (networking) resources
that could be consumed due to = the presence of such loops.

6.  The solution should be = very scalable.  Scalability issues will be
considered and analyzed.


Charter Statement:

The working group is responsible = for standardizing a base technology
for using label switching in = conjunction with network layer routing
and for the implementation of = that technology over various link level
technologies, which may include = Packet-over-Sonet, Frame Relay, ATM,
Ethernet (all forms, such as = Gigabit Ethernet, etc.), Token Ring,...

This includes procedures and = protocols for the distribution of labels
between routers, = encapsulations, multicast considerations, and the use
of labels to support higher = layer resource reservation and QoS
mechanisms.

The working group will also = specify a control plane for optical cross
connects.  In this = environment specific wave lengths or Lambdas are
used instead of labels.


Objectives:

1.  Specify standard = protocol(s) for maintenance and distribution of
label binding information to = support unicast destination-based
routing.

2.  Specify standard = protocol(s) for maintenance and distribution of
label binding information to = support multicast routing.

3.  Specify standard = protocol(s) for maintenance and distribution of
label binding information to = support hierarchy of routing knowledge
(e.g., complete segregation of = intra and inter-domain routing).

4.  Specify standard = protocol(s) for maintenance and distribution of
label binding information to = support explicit paths in support of
applications such as Traffic = Engineering.

5.  Specify standard = protocols and procedures to support the fast
recovery of Label Switched = Paths.

6.  Specify extensions to = the protocols and procedures used for
signaling explicit routes and = to effect fast recovery of LSPs
for use in Optical Cross = Connects. 

7.  Specify standard = procedures of carrying label information over
various link level technologies = including ATM.

8.  Define the support of = Differentiated and Integrated Services,
including aggregated QoS, in an = MPLS environment.

9.  Specify standard = protocols and procedures to support operations,
administration, and maintenance = facilities.


Coordination:

The working group will = coordinate its activities with other working
groups as appropriate.  = For specific technologies, the WG will
cooperate with the appropriate = standards bodies such as OIF, ITU-T,
ANSI, ODSI etc.


Goals and Milestones:

Mar 00 - Produce a document = which defines support of Differentiated
         Services = (Diff-Serv) over Multi-Protocol Label Switching
         (MPLS) networks = (Standards Track).

Aug 00 - Produce a document = which defines operation with RSVP for
         unicast = destinations. (Standards Track).

Aug 00 - Produce specifications = for protocols and procedures that support
         fault recovery in = an MPLS environment

Dec 00 - Produce specifications = for a MPLS control plane for optical
         cross-connects = (Standards Track).

















------_=_NextPart_001_01BF8DFC.EA9279EA-- From owner-mpls@UU.NET Tue Mar 14 17:15:02 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07535 for ; Tue, 14 Mar 2000 17:15:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQignp19210; Tue, 14 Mar 2000 22:15:03 GMT Received: by mail-control.mail.uu.net id QQigno21085 for mpls-outgoing; Tue, 14 Mar 2000 22:14:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigno21071 for ; Tue, 14 Mar 2000 22:14:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigno00541 for ; Tue, 14 Mar 2000 17:14:08 -0500 (EST) Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQigno22537 for ; Tue, 14 Mar 2000 22:14:08 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id QAA00629 for ; Tue, 14 Mar 2000 16:14:05 -0600 (CST) Received: from tellabs.com (hdqpcm139.lisle.tellabs.com [138.111.22.139]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA12789 for ; Tue, 14 Mar 2000 16:14:06 -0600 (CST) Message-ID: <38CEB9B1.BB571BB9@tellabs.com> Date: Tue, 14 Mar 2000 16:14:09 -0600 From: Changcheng Huang X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: draft on path protection Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We have submitted a new draft on path protection mechanism for MPLS. It's available at http://search.ietf.org/internet-drafts/draft-chang-mpls-path-protection-00.txt If you need a PDF version please feel free to contact me. Your comments are welcomed. Chang -- Changcheng Huang Tellabs 4951 Indiana Avenue, MS 64 Lisle, IL 60532 Tel: (630) 512-7954 Fax: (630) 512-8037 From owner-mpls@UU.NET Tue Mar 14 17:48:28 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20399 for ; Tue, 14 Mar 2000 17:48:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQignr12777; Tue, 14 Mar 2000 22:48:29 GMT Received: by mail-control.mail.uu.net id QQignr22891 for mpls-outgoing; Tue, 14 Mar 2000 22:48:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQignr22886 for ; Tue, 14 Mar 2000 22:48:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQignr04582 for ; Tue, 14 Mar 2000 17:48:00 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQignr17076 for ; Tue, 14 Mar 2000 22:47:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA29534 for mpls@uu.net; Tue, 14 Mar 2000 17:47:54 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQignr22845 for ; Tue, 14 Mar 2000 22:46:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQignr01693 for ; Tue, 14 Mar 2000 17:46:45 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQignr16197 for ; Tue, 14 Mar 2000 22:46:44 GMT Received: from tnadeau-pc02 (ch2-dhcp134-171.cisco.com [161.44.134.171]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA24112; Tue, 14 Mar 2000 17:46:07 -0500 (EST) Message-Id: <4.2.2.20000314160924.00dec310@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 14 Mar 2000 17:37:49 -0500 To: dwilder@baynetworks.com (David Wilder) From: "Thomas D. Nadeau" Subject: Re: LDP MIB last call Cc: mpls@UU.NET, "Arun Viswanathan (E-mail)" , rschmitt@cisco.com, Cheenu Srinivasan , jluciani@tollbridgetech.com, hans.sjostrand@etx.ericsson.se, jcucchiara@brixnet.com In-Reply-To: <200003141832.NAA15216@bubba.engeast> References: <633D356A20D0D311BBC1009027DC856C0260C9@TNNT3> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_26505135==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_26505135==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Dave, >Isn't it a little premature to remove those tables from the >LDP MIB when there has not been an acceptable alternative? I actually think that now is the time to make sure that these issues are addressed since the LDP MIB has gone into WG Last Call. >I'd rather a little redundancy than the to use the new proposed >MIB which hasn't had the scrutiny that the LDP MIB has had. That may be true in terms of the new MPLS Packet Classifier MIB which deals most closely with the LDP FEC table. However, as Arun pointed out, the LIB Table contained in the LDP MIB is redundant with the LSR MIB. The LSR MIB has been out for quite a while now, and has been under as much scrutiny as the LDP MIB. --Tom >Dave > > >[Charset iso-8859-1 unsupported, filtering to ASCII...] > > I have the same objections to the current LDP MIB as Tom. The LIB > > and the FEC tables are not specific to LDP and do not belong here. > > The first one is part of the LSR MIB already and the second one > > should be in a seperate packet classifier MIB. They should be removed > > before the LDP MIB goes to last call. > > > > I have seen several messages on this topic but no response from the > > authors thus far. > > > > Thanks, > > Cheenu Srinivasan > > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Friday, March 10, 2000 7:18 AM > > To: Vijay Srinivasan; mpls@uu.net > > Cc: 'swallow@cisco.com'; Cheenu Srinivasan; Arun Viswanathan (E-mail); > > Thomas D. Nadeau (E-mail); rschmitt@cisco.com; jluciani@tollbridgetech.com; > > hans.sjostrand@etx.ericsson.se; jcucchiara@brixnet.com > > Subject: Re: LDP MIB last call > > > > > > > > I still have two major objections to the current > > state of the LDP MIB. There are two tables: the LIB > > and the FEC tables, which I and the authors of the > > TE/LSR MIBs would like removed. Rob Schmitt also > > requested that these tables be removed prior to > > version -05 of the MIB. These tables are at least in > > part, redundant to that which is present in the LSR > > MIB. I have posted several messages to the mailing list > > requesting discussion on this issue, and both times > > I have not received any responses from the authors, nor > > have they replied to the mailing list. I will ask again for > > this discussion to commence. > > > > --Tom > > > > > > > > > > We would like to commence the last call for: > > > > Definitions of Managed Objects for the Multiprotocol Label Switching, Label > > Distribution Protocol (LDP) > > draft-ietf-mpls-ldp-mib-05.txt > > > > Last call will end on Friday, March 17. Please send your comments to the > > list. > > > > Regards, > > - Vijay > > > --=====================_26505135==_.ALT Content-Type: text/html; charset="us-ascii"         
        Hi Dave,


Isn't it a little premature to remove those tables from the
LDP MIB when there has not been an acceptable alternative? 

        I actually think that now is the time to make sure
that these issues are addressed since the LDP MIB has gone
into WG Last Call.

I'd rather a little redundancy than the to use the new proposed
MIB which hasn't had the scrutiny that the LDP MIB has had.

        That may be true in terms of the new MPLS Packet
Classifier MIB which deals most closely with the LDP
FEC table. However, as Arun pointed out, the LIB Table
contained in the LDP MIB is redundant with the LSR MIB.
The LSR MIB has been out for quite a while now, and has been
under as much scrutiny as the LDP MIB.

        --Tom


Dave


[Charset iso-8859-1 unsupported, filtering to ASCII...]
> I have the same objections to the current LDP MIB as Tom. The LIB
> and the FEC tables are not specific to LDP and do not belong here.
> The first one is part of the LSR MIB already and the second one
> should be in a seperate packet classifier MIB. They should be removed
> before the LDP MIB goes to last call.
>
> I have seen several messages on this topic but no response from the
> authors thus far.
>
> Thanks,
> Cheenu Srinivasan
>
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Friday, March 10, 2000 7:18 AM
> To: Vijay Srinivasan; mpls@uu.net
> Cc: 'swallow@cisco.com'; Cheenu Srinivasan; Arun Viswanathan (E-mail);
> Thomas D. Nadeau (E-mail); rschmitt@cisco.com; jluciani@tollbridgetech.com;
> hans.sjostrand@etx.ericsson.se; jcucchiara@brixnet.com
> Subject: Re: LDP MIB last call
>
>
>
>         I still have two major objections to the current
> state of the LDP MIB. There are two tables: the LIB
> and the FEC tables, which I and the authors of the
> TE/LSR MIBs would like removed. Rob Schmitt also
> requested that these tables be removed prior to
> version -05 of the MIB. These tables are at least in
> part, redundant to that which is present in the LSR
> MIB. I have posted several messages to the mailing list
> requesting discussion on this issue, and both times
> I have not received any responses from the authors, nor
> have they replied to the mailing list.  I will ask again for
> this discussion to commence.
>
>         --Tom
>
>
>
>
> We would like to commence the last call for:
>
> Definitions of Managed Objects for the Multiprotocol Label Switching, Label
> Distribution Protocol (LDP)
> draft-ietf-mpls-ldp-mib-05.txt
>
> Last call will end on Friday, March 17.  Please send your comments to the
> list.
>
> Regards,
> - Vijay
>

--=====================_26505135==_.ALT-- From owner-mpls@UU.NET Tue Mar 14 17:59:17 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24063 for ; Tue, 14 Mar 2000 17:59:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQignr26244; Tue, 14 Mar 2000 22:59:18 GMT Received: by mail-control.mail.uu.net id QQignr23386 for mpls-outgoing; Tue, 14 Mar 2000 22:58:51 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQignr23381 for ; Tue, 14 Mar 2000 22:58:41 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQignr02849 for ; Tue, 14 Mar 2000 17:58:18 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQignr25285 for ; Tue, 14 Mar 2000 22:58:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA01075 for mpls@uu.net; Tue, 14 Mar 2000 17:58:17 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQignr23357 for ; Tue, 14 Mar 2000 22:57:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQignr02784 for ; Tue, 14 Mar 2000 17:57:34 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQignr24706 for ; Tue, 14 Mar 2000 22:57:33 GMT Received: from tnadeau-pc02 (ch2-dhcp134-171.cisco.com [161.44.134.171]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA24969; Tue, 14 Mar 2000 17:57:32 -0500 (EST) Message-Id: <4.2.2.20000314174805.00d13f00@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 14 Mar 2000 17:49:12 -0500 To: mpls@UU.NET, swallow@cisco.com, Vijay Srinivasan From: "Thomas D. Nadeau" Subject: LSR MIB WG Last Call Cc: Cheenu Srinivasan , arun@force10networks.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Since we have not received any additional comments on the current version of the LSR MIB, we would like to raise the document to WG Last Call. --Tom From owner-mpls@UU.NET Tue Mar 14 20:25:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14740 for ; Tue, 14 Mar 2000 20:25:05 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigob19736; Wed, 15 Mar 2000 01:25:01 GMT Received: by mail-control.mail.uu.net id QQigob24907 for mpls-outgoing; Wed, 15 Mar 2000 01:24:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigob24902 for ; Wed, 15 Mar 2000 01:24:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigob18321 for ; Tue, 14 Mar 2000 20:24:28 -0500 (EST) Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63]) id QQigob04212 for ; Wed, 15 Mar 2000 01:24:28 GMT Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Tue, 14 Mar 2000 17:23:48 -0800 Message-ID: <337055FBC675D311A85D00508B5A9C4F25420E@u-mail.rd.francetelecom.com> From: CATANZARITI Sergio FTR&D/TI To: "'ip-optical@lists.research.bell-labs.com'" Cc: "'mpls@UU.NET'" Subject: Optical IP activities Date: Tue, 14 Mar 2000 17:23:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8E1D.1CE5E54C" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8E1D.1CE5E54C Content-Type: text/plain Today I was reading the MPLS revised charter sent by Vijay and I have found optical IP related activities, like that: 6. Specify extensions to the protocols and procedures used for signaling explicit routes and to effect fast recovery of LSPs for use in Optical Cross Connects. Now, reading from the IP over Optical BoF description, I find: - Modifying existing IP and MPLS routing and connection signaling protocols I know that it is still pretty much immature to talk about results of the upcoming IP over Optical BoF, but how will an eventual WG coming out from this BoF reconcile with the MPLS WG activity in the Optical IP arena? By working on a generic control plane architecture and requirements definition, and leaving out to the MPLS WG specific work on the generic mechanisms and procedure for an MPLS implementation of an Optical IP control plane? Is this a possible intra-IETF activity scenario? Which others? Looking for a brief and rough hint. Thanks, Sergio > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > ------_=_NextPart_001_01BF8E1D.1CE5E54C Content-Type: text/html Content-Transfer-Encoding: quoted-printable Optical IP activities

Today I was reading the MPLS revised = charter sent by Vijay and I have found optical IP related activities, = like that:

6.  Specify extensions to the = protocols and procedures used for
signaling explicit routes and to effect fast recovery of LSPs
for use in Optical Cross Connects. 
 
Now, reading from the IP over Optical = BoF description, I find:

- Modifying existing IP and MPLS = routing and connection signaling
  protocols=20

I know that it is still pretty much = immature to talk about results of the upcoming IP over Optical BoF, but = how will an eventual WG coming out from this BoF reconcile with the = MPLS WG activity in the Optical IP arena?

By working on a generic control plane = architecture and requirements definition, and leaving out to the MPLS = WG specific work on the generic mechanisms and procedure for an MPLS = implementation of an Optical IP control plane? Is this a possible = intra-IETF activity scenario? Which others?

Looking for a brief and rough = hint.

Thanks,
Sergio

    ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior Project = Manager, Technology Integration
    France Telecom = R&D
    1000 Marina = Boulevard Suite 300
    Brisbane CA = 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com =
    ---------------------------------------------------------= -----------


------_=_NextPart_001_01BF8E1D.1CE5E54C-- From owner-mpls@UU.NET Tue Mar 14 20:45:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22004 for ; Tue, 14 Mar 2000 20:45:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigod02566; Wed, 15 Mar 2000 01:45:26 GMT Received: by mail-control.mail.uu.net id QQigoc25804 for mpls-outgoing; Wed, 15 Mar 2000 01:44:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigoc25797 for ; Wed, 15 Mar 2000 01:44:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigoc17974 for ; Tue, 14 Mar 2000 20:44:19 -0500 (EST) Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQigoc16696 for ; Wed, 15 Mar 2000 01:44:19 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Mar 2000 17:44:15 -0800 Message-ID: From: Vijay Srinivasan To: "'CATANZARITI Sergio FTR&D/TI'" , "'ip-optical@lists.research.bell-labs.com'" Cc: "'mpls@UU.NET'" Subject: RE: Optical IP activities Date: Tue, 14 Mar 2000 17:44:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8E1F.F8A0FD36" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8E1F.F8A0FD36 Content-Type: text/plain; charset="iso-8859-1" Hi Sergio, Here is an excerpt from the IP over Optical BOF description, that might help answer your question: The proposed IP over Optical WG will not duplicate work already being done elsewhere, such as MPLS per-LSP protection switching as provided by LSRs, OSPF and IS-IS extensions to support constrained routing, extensions to PPP to support direct carriage over fiber in a SONET-less environment, and so on. However, the WG may generate requirements or other input to be considered in other WGs. - Vijay -----Original Message----- From: CATANZARITI Sergio FTR&D/TI [mailto:sergio.catanzariti@rd.francetelecom.com] Sent: Tuesday, March 14, 2000 5:24 PM To: 'ip-optical@lists.research.bell-labs.com' Cc: 'mpls@UU.NET' Subject: Optical IP activities Today I was reading the MPLS revised charter sent by Vijay and I have found optical IP related activities, like that: 6. Specify extensions to the protocols and procedures used for signaling explicit routes and to effect fast recovery of LSPs for use in Optical Cross Connects. Now, reading from the IP over Optical BoF description, I find: - Modifying existing IP and MPLS routing and connection signaling protocols I know that it is still pretty much immature to talk about results of the upcoming IP over Optical BoF, but how will an eventual WG coming out from this BoF reconcile with the MPLS WG activity in the Optical IP arena? By working on a generic control plane architecture and requirements definition, and leaving out to the MPLS WG specific work on the generic mechanisms and procedure for an MPLS implementation of an Optical IP control plane? Is this a possible intra-IETF activity scenario? Which others? Looking for a brief and rough hint. Thanks, Sergio -------------------------------------------------------------------- Sergio Catanzariti Senior Project Manager, Technology Integration France Telecom R&D 1000 Marina Boulevard Suite 300 Brisbane CA 94005 Tel. 650-875-1526 Fax. 650-875-1505 email:sergio.catanzariti@rd.francetelecom.com -------------------------------------------------------------------- ------_=_NextPart_001_01BF8E1F.F8A0FD36 Content-Type: text/html; charset="iso-8859-1" Optical IP activities
 
Hi Sergio,
 
Here is an excerpt from the IP over Optical BOF description, that might help answer your question:

The proposed IP over Optical WG will not duplicate work already being
done elsewhere, such as MPLS per-LSP protection switching as provided
by LSRs, OSPF and IS-IS extensions to support constrained routing,
extensions to PPP to support direct carriage over fiber in a SONET-less
environment, and so on. However, the WG may generate requirements or
other input to be considered in other WGs.
 
 
- Vijay
-----Original Message-----
From: CATANZARITI Sergio FTR&D/TI [mailto:sergio.catanzariti@rd.francetelecom.com]
Sent: Tuesday, March 14, 2000 5:24 PM
To: 'ip-optical@lists.research.bell-labs.com'
Cc: 'mpls@UU.NET'
Subject: Optical IP activities

Today I was reading the MPLS revised charter sent by Vijay and I have found optical IP related activities, like that:

6.  Specify extensions to the protocols and procedures used for
signaling explicit routes and to effect fast recovery of LSPs
for use in Optical Cross Connects. 
 
Now, reading from the IP over Optical BoF description, I find:

- Modifying existing IP and MPLS routing and connection signaling
  protocols

I know that it is still pretty much immature to talk about results of the upcoming IP over Optical BoF, but how will an eventual WG coming out from this BoF reconcile with the MPLS WG activity in the Optical IP arena?

By working on a generic control plane architecture and requirements definition, and leaving out to the MPLS WG specific work on the generic mechanisms and procedure for an MPLS implementation of an Optical IP control plane? Is this a possible intra-IETF activity scenario? Which others?

Looking for a brief and rough hint.

Thanks,
Sergio

    --------------------------------------------------------------------
    Sergio Catanzariti
    Senior Project Manager, Technology Integration
    France Telecom R&D
    1000 Marina Boulevard Suite 300
    Brisbane CA 94005
    Tel. 650-875-1526
    Fax. 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com
    --------------------------------------------------------------------


------_=_NextPart_001_01BF8E1F.F8A0FD36-- From owner-mpls@UU.NET Tue Mar 14 20:51:09 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23861 for ; Tue, 14 Mar 2000 20:51:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigod20091; Wed, 15 Mar 2000 01:51:09 GMT Received: by mail-control.mail.uu.net id QQigod26208 for mpls-outgoing; Wed, 15 Mar 2000 01:50:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigod26202 for ; Wed, 15 Mar 2000 01:50:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigod19890 for ; Tue, 14 Mar 2000 20:50:37 -0500 (EST) Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63]) id QQigod19702 for ; Wed, 15 Mar 2000 01:50:36 GMT Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Tue, 14 Mar 2000 17:49:57 -0800 Message-ID: <337055FBC675D311A85D00508B5A9C4F25420F@u-mail.rd.francetelecom.com> From: CATANZARITI Sergio FTR&D/TI To: "'Vijay Srinivasan'" Cc: "'mpls@UU.NET'" , "'ip-optical@lists.research.bell-labs.com'" Subject: RE: Optical IP activities Date: Tue, 14 Mar 2000 17:49:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8E20.C41F72DA" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8E20.C41F72DA Content-Type: text/plain Vijay, thanks. Okay. I thought that the list was a coverage of the possible duplication works, in that case I was wondering why I did not find the Optical IP topic, instead of a not-exhaustive list of possible duplication work instances. Sergio > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Vijay Srinivasan [SMTP:vsriniva@cosinecom.com] > Sent: Tuesday, March 14, 2000 5:44 PM > To: 'CATANZARITI Sergio FTR&D/TI'; > 'ip-optical@lists.research.bell-labs.com' > Cc: 'mpls@UU.NET' > Subject: RE: Optical IP activities > > > Hi Sergio, > > Here is an excerpt from the IP over Optical BOF description, that might > help answer your question: > > The proposed IP over Optical WG will not duplicate work already being > done elsewhere, such as MPLS per-LSP protection switching as provided > by LSRs, OSPF and IS-IS extensions to support constrained routing, > extensions to PPP to support direct carriage over fiber in a SONET-less > environment, and so on. However, the WG may generate requirements or > other input to be considered in other WGs. > > > - Vijay > > -----Original Message----- > From: CATANZARITI Sergio FTR&D/TI > [mailto:sergio.catanzariti@rd.francetelecom.com] > Sent: Tuesday, March 14, 2000 5:24 PM > To: 'ip-optical@lists.research.bell-labs.com' > Cc: 'mpls@UU.NET' > Subject: Optical IP activities > > > > Today I was reading the MPLS revised charter sent by Vijay and I > have found optical IP related activities, like that: > > 6. Specify extensions to the protocols and procedures used for > signaling explicit routes and to effect fast recovery of LSPs > for use in Optical Cross Connects. > > Now, reading from the IP over Optical BoF description, I find: > > - Modifying existing IP and MPLS routing and connection signaling > protocols > > I know that it is still pretty much immature to talk about results > of the upcoming IP over Optical BoF, but how will an eventual WG coming > out from this BoF reconcile with the MPLS WG activity in the Optical IP > arena? > > By working on a generic control plane architecture and requirements > definition, and leaving out to the MPLS WG specific work on the generic > mechanisms and procedure for an MPLS implementation of an Optical IP > control plane? Is this a possible intra-IETF activity scenario? Which > others? > > Looking for a brief and rough hint. > > Thanks, > Sergio > > > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > ------_=_NextPart_001_01BF8E20.C41F72DA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical IP activities

Vijay,

thanks. Okay. I thought that the list = was a coverage of the possible duplication works, in that case I was = wondering why I did not find the Optical IP topic, instead of a = not-exhaustive list of possible duplication work instances.

Sergio

    ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior Project = Manager, Technology Integration
    France Telecom = R&D
    1000 Marina = Boulevard Suite 300
    Brisbane CA = 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com =
    ---------------------------------------------------------= -----------


    -----Original Message-----
    From:   Vijay Srinivasan = [SMTP:vsriniva@cosinecom.com]
    Sent:   Tuesday, March 14, 2000 5:44 PM
    To:     'CATANZARITI Sergio FTR&D/TI'; = 'ip-optical@lists.research.bell-labs.com'
    Cc:     'mpls@UU.NET'
    Subject:       = RE: Optical IP activities

    =A0
    Hi Sergio,
    =A0
    Here is an excerpt = from the IP over Optical BOF description, that might help answer your = question:

    The proposed IP = over Optical WG will not duplicate work already being
    done elsewhere, such as MPLS per-LSP protection switching as = provided
    by LSRs, OSPF and IS-IS extensions to support constrained routing,
    extensions to PPP to support direct carriage over fiber in a = SONET-less
    environment, and so on. However, the WG may generate requirements = or
    other input to be considered in other WGs.
    =A0
    =A0
    - Vijay

      -----Original Message-----
      From: CATANZARITI Sergio FTR&D/TI = [mailto:sergio.ca= tanzariti@rd.francetelecom.com]
      Sent: Tuesday, March 14, 2000 5:24 PM
      To: 'ip-optical@lists.research.bell-labs.com'
      Cc: 'mpls@UU.NET'
      Subject: Optical IP activities

      Today I was reading the MPLS revised = charter sent by Vijay and I have found optical IP related activities, = like that:

      6.=A0 Specify extensions to the = protocols and procedures used for
      signaling explicit routes and to effect fast recovery of LSPs
      for use in Optical Cross Connects.=A0
      =A0
      Now, reading from the IP over = Optical BoF description, I find:

      - Modifying existing IP and MPLS = routing and connection signaling
      =A0 protocols

      I know that it is still pretty much = immature to talk about results of the upcoming IP over Optical BoF, but = how will an eventual WG coming out from this BoF reconcile with the = MPLS WG activity in the Optical IP arena?

      By working on a generic control plane = architecture and requirements definition, and leaving out to the MPLS = WG specific work on the generic mechanisms and procedure for an MPLS = implementation of an Optical IP control plane? Is this a possible = intra-IETF activity scenario? Which others?

      Looking for a brief and rough = hint.

      Thanks,
      Sergio =

              ---------------------------------------------------------= -----------
      Sergio = Catanzariti
      Senior = Project Manager, Technology Integration
      France = Telecom R&D
      1000 Marina = Boulevard Suite 300
      Brisbane CA = 94005
      Tel. = 650-875-1526
      Fax. = 650-875-1505
      email:sergio.catanzariti@rd.francetelecom.com<= BR> ---------------------------------------------------------= -----------


------_=_NextPart_001_01BF8E20.C41F72DA-- From owner-mpls@UU.NET Tue Mar 14 20:57:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26033 for ; Tue, 14 Mar 2000 20:57:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigod11942; Wed, 15 Mar 2000 01:57:50 GMT Received: by mail-control.mail.uu.net id QQigod26535 for mpls-outgoing; Wed, 15 Mar 2000 01:57:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigod26530 for ; Wed, 15 Mar 2000 01:57:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigod18846 for ; Tue, 14 Mar 2000 20:57:18 -0500 (EST) Received: from research.gate.nec.co.jp by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: research.gate.nec.co.jp [202.247.6.217]) id QQigod23136 for ; Wed, 15 Mar 2000 01:57:16 GMT Received: from tomato.nwk.cl.nec.co.jp (IDENT:92pASlxfJ8MYfevRPCTJXdV74DwBXr4P@tomato.nwk.cl.nec.co.jp [10.56.32.1]) by research.gate.nec.co.jp (8.9.3+3.2W/000201) with ESMTP id KAA08195 for ; Wed, 15 Mar 2000 10:57:11 +0900 (JST) Received: from tea.nwk.cl.nec.co.jp by tomato.nwk.cl.nec.co.jp (8.9.3/NWKM19990405) with ESMTP id KAA21914; Wed, 15 Mar 2000 10:57:10 +0900 (JST) Received: from iwata-pc2 (iwata-pc2.nwk.cl.nec.co.jp [10.56.32.77]) by tea.nwk.cl.nec.co.jp (8.9.0/3.7W) with ESMTP id KAA21961; Wed, 15 Mar 2000 10:57:08 +0900 (JST) Message-Id: <4.2.0.58.J.20000315105716.00a17430@tea.nwk.cl.nec.co.jp> X-Sender: iwata@tea.nwk.cl.nec.co.jp Reply-To: iwata@ccm.CL.nec.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 15 Mar 2000 11:01:14 +0900 To: mpls@UU.NET From: Atsushi Iwata Subject: I-D for Crankback routing extension Cc: Norihito Fujita Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, all I'm Atsushi Iwata in NEC Corporation. We submitted the following internet draft which proposes crankback routing extensions for MPLS signaling. We would appreciate if you could give us any suggestions or comments on this before IETF. Regards, -- Precedence: bulk X-UIDL: d6f7f9a3bc4c4cf28bcc6c4e44079689 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Routing Extensions for CR-LDP Author(s) : N. Fujita, A. Iwata, G. Ash Filename : draft-fujita-mpls-crldp-crankback-00.txt Pages : 11 Date : 07-Mar-00 This draft proposes crankback routing extensions for CR-LDP signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that label requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the proposed crankback routing schemes can be also applied to end-to-end LSP restoration by indicating the location of the failure link or node. This would significantly improve the recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fujita-mpls-crldp-crankback-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fujita-mpls-crldp-crankback-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fujita-mpls-crldp-crankback-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20000307114051.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fujita-mpls-crldp-crankback-00.txt ---------------------------------------------------------------- Atsushi Iwata Assistant Manager Network System TG, C&C Media Research Labs, NEC Corporation 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555 TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 E-mail: iwata@ccm.CL.nec.co.jp From owner-mpls@UU.NET Tue Mar 14 23:19:05 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15485 for ; Tue, 14 Mar 2000 23:19:05 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigon28295; Wed, 15 Mar 2000 04:19:06 GMT Received: by mail-control.mail.uu.net id QQigon27046 for mpls-outgoing; Wed, 15 Mar 2000 04:18:43 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigon27036 for ; Wed, 15 Mar 2000 04:18:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigon00831 for ; Tue, 14 Mar 2000 23:18:26 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQigon00979 for ; Wed, 15 Mar 2000 04:18:10 GMT Received: from testras ([165.133.13.22]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id JAA12897 for ; Wed, 15 Mar 2000 09:44:29 -0600 (GMT) Message-ID: <011901bf8e35$179d7830$160d85a5@dti.daewoo.co.kr> From: "ashish" To: Subject: MIB for CR-LDP Date: Wed, 15 Mar 2000 09:45:23 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0116_01BF8E63.2F2343D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0116_01BF8E63.2F2343D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello is there any document relating to MIB support for CR-LDP? ashish ------=_NextPart_000_0116_01BF8E63.2F2343D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello
is there any document relating to MIB = support for=20 CR-LDP?
ashish
------=_NextPart_000_0116_01BF8E63.2F2343D0-- From owner-mpls@UU.NET Tue Mar 14 23:20:55 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16090 for ; Tue, 14 Mar 2000 23:20:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigon02532; Wed, 15 Mar 2000 04:20:54 GMT Received: by mail-control.mail.uu.net id QQigon27132 for mpls-outgoing; Wed, 15 Mar 2000 04:20:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigon27122 for ; Wed, 15 Mar 2000 04:20:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigon00893 for ; Tue, 14 Mar 2000 23:19:53 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQigon01816 for ; Wed, 15 Mar 2000 04:19:48 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id JAA12958 for ; Wed, 15 Mar 2000 09:46:28 -0600 (GMT) Message-ID: <004201bf8e36$68a9cd40$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Subject: mib for cr-ldp Date: Wed, 15 Mar 2000 09:54:52 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01BF8E64.822FAEA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_003F_01BF8E64.822FAEA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all Is there any mib document especially for cr-ldp or the = draft-ietf-mpls-ldp-mib-05 is the only one available. Please specify. santosh santoshgupta@poboxes.com ------=_NextPart_000_003F_01BF8E64.822FAEA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all
    Is there any mib document especially for cr-ldp = or the=20 draft-ietf-mpls-ldp-mib-05 is the only one available. Please = specify.
santosh
 
santoshgupta@poboxes.com ------=_NextPart_000_003F_01BF8E64.822FAEA0-- From owner-mpls@UU.NET Wed Mar 15 00:01:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01494 for ; Wed, 15 Mar 2000 00:01:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigoq23672; Wed, 15 Mar 2000 05:01:54 GMT Received: by mail-control.mail.uu.net id QQigoq00902 for mpls-outgoing; Wed, 15 Mar 2000 05:01:22 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigoq00621 for ; Wed, 15 Mar 2000 05:01:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigoq02701 for ; Wed, 15 Mar 2000 00:00:52 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQigoq27988 for ; Wed, 15 Mar 2000 05:00:52 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 05:00:45 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E026377@monk.datcon.co.uk> From: Adrian Farrel To: "Thomas D. Nadeau" Cc: mpls@UU.NET Subject: RE: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 05:00:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tom, Your latest version is dated 6th March. It is now 14th. I think it reasonable to give us all a little time to read your work after all of the effort you have put into it. Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Tuesday, March 14, 2000 10:49 PM >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan >Cc: Cheenu Srinivasan; arun@force10networks.com >Subject: LSR MIB WG Last Call > > > > Since we have not received any additional comments >on the current version of the LSR MIB, we would like >to raise the document to WG Last Call. > > --Tom > > From owner-mpls@UU.NET Wed Mar 15 01:04:59 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24538 for ; Wed, 15 Mar 2000 01:04:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigou08674; Wed, 15 Mar 2000 06:04:59 GMT Received: by mail-control.mail.uu.net id QQigou14031 for mpls-outgoing; Wed, 15 Mar 2000 06:04:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigou13951 for ; Wed, 15 Mar 2000 06:04:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigou08213 for ; Wed, 15 Mar 2000 01:04:02 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQigou08131 for ; Wed, 15 Mar 2000 06:04:02 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 06:03:55 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E02637B@monk.datcon.co.uk> From: Adrian Farrel To: mpls@UU.NET Cc: "Thomas D. Nadeau" Subject: LSR MIB typo Date: Wed, 15 Mar 2000 06:03:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk mplsOutSegmentEntry OBJECT-TYPE SYNTAX MplsOutSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents one incoming segment... Hopefully these are actually outgoing segments :-) Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Mar 15 01:05:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24608 for ; Wed, 15 Mar 2000 01:05:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigou01378; Wed, 15 Mar 2000 06:05:06 GMT Received: by mail-control.mail.uu.net id QQigou14038 for mpls-outgoing; Wed, 15 Mar 2000 06:04:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigou13714 for ; Wed, 15 Mar 2000 06:04:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigou06785 for ; Wed, 15 Mar 2000 01:04:05 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQigou08163 for ; Wed, 15 Mar 2000 06:04:05 GMT Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 06:04:02 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E02637C@monk.datcon.co.uk> From: Adrian Farrel To: "Thomas D. Nadeau" , dwilder@baynetworks.com Cc: mpls@UU.NET, "Arun Viswanathan (E-mail)" , Cheenu Srinivasan , jcucchiara@brixnet.com Subject: LIB Table - LSR MIB v. LDP MIB Date: Wed, 15 Mar 2000 06:03:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tom, you wrote in response to Dave in response to Arun... >>> I have the same objections to the current LDP MIB as Tom. The LIB >>> and the FEC tables are not specific to LDP and do not belong here. >>> The first one is part of the LSR MIB already and the second one >>> should be in a separate packet classifier MIB. They should be removed >>> before the LDP MIB goes to last call. >>I'd rather a little redundancy than the to use the new proposed >>MIB which hasn't had the scrutiny that the LDP MIB has had. >That may be true in terms of the new MPLS Packet >Classifier MIB which deals most closely with the LDP >FEC table. However, as Arun pointed out, the LIB Table >contained in the LDP MIB is redundant with the LSR MIB. >The LSR MIB has been out for quite a while now, and has been >under as much scrutiny as the LDP MIB. It is true that some of the information contained in the LDP MIB's LIB table is also contained in the LSR MIB, but consider mplsLdpLibInLabelType, mplsLdpLibOutLabelType and mplsLdpLibLspLastChange. Note also that to walk the 'LIB table' in the LSR MIB involves walking the XC table and for each entry looking up the out label and out interface in the Out Segment table. This is, perhaps, less graceful. Did you consider putting a simple LIB table in the LSR MIB? Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Mar 15 01:05:22 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24731 for ; Wed, 15 Mar 2000 01:05:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigou09126; Wed, 15 Mar 2000 06:05:21 GMT Received: by mail-control.mail.uu.net id QQigou14331 for mpls-outgoing; Wed, 15 Mar 2000 06:04:47 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigou14070 for ; Wed, 15 Mar 2000 06:04:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigou06789 for ; Wed, 15 Mar 2000 01:04:12 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQigou08201 for ; Wed, 15 Mar 2000 06:04:11 GMT Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 06:04:08 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E02637D@monk.datcon.co.uk> From: Adrian Farrel To: Arun Viswanathan , "'mpls@UU.NET'" Cc: "'jcucchiara@brixnet.com'" , "'Thomas D. Nadeau'" , "'Vijay Srinivasan'" , "'David Wilder'" , "'Cheenu Srinivasan'" Subject: FEC Table - LDP MIB v. Packet Classifier MIB Date: Wed, 15 Mar 2000 06:04:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Arun wrote... >The second issue here is that of the FEC in the LDP MIB. The proposed >packet-classifier MIB was primarily designed for redirecting >traffic into MPLS tunnels at the head-end. The FEC requirements >in the LDP MIB is more like extending the FIB MIB (rfc2096?) >with label information. The right way to address the LDP requirement >IMHO would be to extend the FIB MIB to include label information. >The packet-classifier does encompass this functionality in a way, >however, I can understand the debate over the second issue. I agree that purpose of the FEC information in the two MPLS MIBs is different. The Packet Classifier is concerned with data ingress. The LDP MIB has to consider LSP merging and LSP segment matching. In my opinion it clouds the implementation to remove this information from core of the MPLS signaling function. You could make a case for putting the FIB in the LSR MIB, but since it is specific to LDP that might be a shame. Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Mar 15 07:37:34 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27133 for ; Wed, 15 Mar 2000 07:37:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigpu16577; Wed, 15 Mar 2000 12:37:34 GMT Received: by mail-control.mail.uu.net id QQigpu23789 for mpls-outgoing; Wed, 15 Mar 2000 12:37:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigpu23779 for ; Wed, 15 Mar 2000 12:37:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigpu01113 for ; Wed, 15 Mar 2000 07:37:01 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQigpu16057 for ; Wed, 15 Mar 2000 12:37:01 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Wed, 15 Mar 2000 06:34:23 -0600 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GXRMJDZC; Wed, 15 Mar 2000 07:34:07 -0500 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G9NS2T6V; Wed, 15 Mar 2000 07:34:05 -0500 Message-ID: <38CF82D6.17B1A4B1@americasm01.nt.com> Date: Wed, 15 Mar 2000 07:32:23 -0500 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Gupta , ashish@daewoo.dti.daewoo.co.kr CC: mpls Subject: Re: mib for cr-ldp References: <004201bf8e36$68a9cd40$100d85a5@dti.daewoo.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit There is no MIB specifically for CR-LDP at this time. The LDP mib (draft-ietf-mpls-ldp-mib-05.txt) and the LSR mib (draft-ietf-mpls-lsr-mib-02.txt) are the only standard (well, pre-standard ...) MPLS mibs available. This means that there are some aspects of CR-LDP that cannot be configured using a standards-track MIB at present. However, I know that a number of companies have defined their own Enterprise MIBs for this purpose. - Philip From owner-mpls@UU.NET Wed Mar 15 08:19:29 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14903 for ; Wed, 15 Mar 2000 08:19:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigpx08235; Wed, 15 Mar 2000 13:19:25 GMT Received: by mail-control.mail.uu.net id QQigpx03867 for mpls-outgoing; Wed, 15 Mar 2000 13:19:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigpx03862 for ; Wed, 15 Mar 2000 13:19:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigpx05543 for ; Wed, 15 Mar 2000 08:18:57 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigpx19118 for ; Wed, 15 Mar 2000 13:18:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA26257 for mpls@uu.net; Wed, 15 Mar 2000 08:18:56 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigpx03840 for ; Wed, 15 Mar 2000 13:18:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigpx05483 for ; Wed, 15 Mar 2000 08:18:04 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQigpx07413 for ; Wed, 15 Mar 2000 13:18:04 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA01833; Wed, 15 Mar 2000 08:17:59 -0500 (EST) Message-Id: <4.2.2.20000315080814.00dedd00@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 08:09:46 -0500 To: Adrian Farrel From: "Thomas D. Nadeau" Subject: RE: LSR MIB WG Last Call Cc: mpls@UU.NET In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E026377@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1717888==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_1717888==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Please do give comments if there are any. The WG Last Call should not preclude that. The reason why we decided to go WGLC at this point was that even during the last round of reviewed comments (most were from you in fact), the comments were relatively minor. We feel that the MIB is pretty solid and mature at this point. --Tom >Your latest version is dated 6th March. >It is now 14th. > >I think it reasonable to give us all a little time to read your work after >all of the effort you have put into it. > >Adrian >-- >Adrian Farrel mailto:af@datcon.co.uk >ATM, MPLS and Telecoms Development Group >Data Connection Ltd., Chester, UK >http://www.datcon.co.uk/ >Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > >-----Original Message----- > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >Sent: Tuesday, March 14, 2000 10:49 PM > >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan > >Cc: Cheenu Srinivasan; arun@force10networks.com > >Subject: LSR MIB WG Last Call > > > > > > > > Since we have not received any additional comments > >on the current version of the LSR MIB, we would like > >to raise the document to WG Last Call. > > > > --Tom > > > > --=====================_1717888==_.ALT Content-Type: text/html; charset="us-ascii"         
        Please do give comments if there are any.
The WG Last Call should not preclude that. The
reason why we decided to go WGLC at this point
was that even during the last round of reviewed
comments (most were from you in fact), the comments
were relatively minor. We feel that the MIB is pretty
solid and mature at this point.

        --Tom



Your latest version is dated 6th March.
It is now 14th.

I think it reasonable to give us all a little time to read your work after
all of the effort you have put into it.

Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
ATM, MPLS and Telecoms Development Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


>-----Original Message-----
>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
>Sent: Tuesday, March 14, 2000 10:49 PM
>To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan
>Cc: Cheenu Srinivasan; arun@force10networks.com
>Subject: LSR MIB WG Last Call
>
>
>
>       Since we have not received any additional comments
>on the current version of the LSR MIB, we would like
>to raise the document to WG Last Call.
>
>       --Tom
>
>
--=====================_1717888==_.ALT-- From owner-mpls@UU.NET Wed Mar 15 08:51:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27978 for ; Wed, 15 Mar 2000 08:51:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigpz11596; Wed, 15 Mar 2000 13:51:07 GMT Received: by mail-control.mail.uu.net id QQigpz05650 for mpls-outgoing; Wed, 15 Mar 2000 13:50:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigpz05645 for ; Wed, 15 Mar 2000 13:50:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigpz08474 for ; Wed, 15 Mar 2000 08:50:25 -0500 (EST) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQigpz11046 for ; Wed, 15 Mar 2000 13:50:24 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA10338 for ; Wed, 15 Mar 2000 05:50:22 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA23556 for mpls@uu.net; Wed, 15 Mar 2000 08:50:22 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigon27549 for ; Wed, 15 Mar 2000 04:29:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigon01495 for ; Tue, 14 Mar 2000 23:29:06 -0500 (EST) Received: from smtp.263.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.44.19]) id QQigon05800 for ; Wed, 15 Mar 2000 04:28:58 GMT Received: from 263.net (unknown [202.112.109.83]) by smtp.263.net (Postfix) with ESMTP id 73E361C3DF151; Tue, 14 Mar 2000 16:25:00 +0800 (CST) Message-ID: <38CDF6AC.FD8EC25C@263.net> Date: Tue, 14 Mar 2000 16:22:04 +0800 From: jinglin X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls , ietf@ietf.org Subject: Problem about LDP Message type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I saw the following sentences in the draft(draft-ietf-mpls-ldp-06.txt): "" An LDP Message is malformed if: - The Message Type is unknown. If the Message Type is < 0x8000 (high order bit = 0) it is an error signaled by the Unknown Message Type Status Code. If the Message Type is >= 0x8000 (high order bit = 1) it is silently discarded. Any value of Message type(error for <0x8000,discard for >=0x8000) causes LDP message Type unknown, then which values are known for message type? From owner-mpls@UU.NET Wed Mar 15 08:51:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28304 for ; Wed, 15 Mar 2000 08:51:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigpz12484; Wed, 15 Mar 2000 13:51:50 GMT Received: by mail-control.mail.uu.net id QQigpz05767 for mpls-outgoing; Wed, 15 Mar 2000 13:51:28 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigpz05762 for ; Wed, 15 Mar 2000 13:51:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigpz08872 for ; Wed, 15 Mar 2000 08:51:04 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQigpz29706 for ; Wed, 15 Mar 2000 13:51:04 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id FAA16689 for ; Wed, 15 Mar 2000 05:51:02 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA23562 for mpls@uu.net; Wed, 15 Mar 2000 08:51:01 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigpq11879 for ; Wed, 15 Mar 2000 11:31:49 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigpq27805 for ; Wed, 15 Mar 2000 06:31:38 -0500 (EST) Received: from btm4r4.alcatel.be by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: btm4r4.alcatel.be [195.207.101.110]) id QQigpq27154 for ; Wed, 15 Mar 2000 11:31:33 GMT Received: from btmq9s.rc.bel.alcatel.be (root@btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id MAA28354 for ; Wed, 15 Mar 2000 12:31:30 +0100 (MET) Received: from alcatel.be (bt015i [138.203.66.150]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id MAA13838 for ; Wed, 15 Mar 2000 12:31:24 +0100 (MET) Message-ID: <38CF7483.F2C919D4@alcatel.be> Date: Wed, 15 Mar 2000 12:31:15 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: ascii archive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am looking for an up-to-date ascii archive of the mailing list. Anyone any idea (the cisco archive is not available anymore)? thanks, dirk -- Dirk Ooms Alcatel Research mailto:Dirk.Ooms@alcatel.be Francis Wellesplein 1 Phone: +32 3 240 4732 B-2018 Antwerp Fax: +32 3 240 9932 Belgium From owner-mpls@UU.NET Wed Mar 15 09:12:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06926 for ; Wed, 15 Mar 2000 09:12:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqa24801; Wed, 15 Mar 2000 14:12:39 GMT Received: by mail-control.mail.uu.net id QQigqa14347 for mpls-outgoing; Wed, 15 Mar 2000 14:12:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigqa14342 for ; Wed, 15 Mar 2000 14:11:59 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqa11450 for ; Wed, 15 Mar 2000 09:11:47 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigqa24170 for ; Wed, 15 Mar 2000 14:11:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA02081 for mpls@uu.net; Wed, 15 Mar 2000 09:11:45 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigqa14271 for ; Wed, 15 Mar 2000 14:11:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqa11418 for ; Wed, 15 Mar 2000 09:11:12 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQigqa23769 for ; Wed, 15 Mar 2000 14:11:12 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 09:09:31 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F85F@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'ashish'" , mpls@UU.NET Subject: RE: MIB for CR-LDP Date: Wed, 15 Mar 2000 09:09:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8E88.14C571E6" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8E88.14C571E6 Content-Type: text/plain; charset="iso-8859-1" Quite a while ago we (LDP MIB co-authors) asked one of the co-chairs of MPLS if we could combine the LDP MIB to encompass CR-LDP also. We were told that it would be best to either issue a separate draft specifically for CR-LDP and go through the proper channels of presenting to the working group, or to get the LDP MIB finished prior to encompassing CR-LDP in the same MIB. Then present how the LDP MIB could be added on for CR-LDP as a separate working group document. In other words, we were not allowed to take on the scope of another MPLS protocol without going through proper IETF channels. To date we have not done so because we wanted to get the LDP MIB advanced, and then consider CR-LDP. Currently, there is no MIB specific to CR-LDP in the standards track. -Joan -----Original Message----- From: ashish [mailto:ashish@daewoo.dti.daewoo.co.kr] Sent: Tuesday, March 14, 2000 11:15 PM To: mpls@UU.NET Subject: MIB for CR-LDP Hello is there any document relating to MIB support for CR-LDP? ashish ------_=_NextPart_001_01BF8E88.14C571E6 Content-Type: text/html; charset="iso-8859-1"
Quite a while ago we (LDP MIB co-authors) asked one of the 
co-chairs of MPLS if we could combine the LDP MIB to
encompass CR-LDP also.  We were told that it
would be best to either issue a separate draft specifically
for CR-LDP and go through the proper channels of presenting
to the working group, or to get the LDP MIB finished prior
to encompassing CR-LDP in the same MIB.  Then present how 
the LDP MIB could be added on for CR-LDP as a separate working
group document.
 
In other words, we were not allowed to take on the scope of another MPLS protocol
without going through proper IETF channels.  To date we have not done so because
we wanted to get the LDP MIB advanced, and then consider CR-LDP.
 
Currently, there is no MIB specific to CR-LDP in the standards track.
 
-Joan
 
-----Original Message-----
From: ashish [mailto:ashish@daewoo.dti.daewoo.co.kr]
Sent: Tuesday, March 14, 2000 11:15 PM
To: mpls@UU.NET
Subject: MIB for CR-LDP

Hello
is there any document relating to MIB support for CR-LDP?
ashish
------_=_NextPart_001_01BF8E88.14C571E6-- From owner-mpls@UU.NET Wed Mar 15 09:41:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18902 for ; Wed, 15 Mar 2000 09:41:47 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqc13321; Wed, 15 Mar 2000 14:41:42 GMT Received: by mail-control.mail.uu.net id QQigqc17084 for mpls-outgoing; Wed, 15 Mar 2000 14:41:08 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigqc16975 for ; Wed, 15 Mar 2000 14:40:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqc15617 for ; Wed, 15 Mar 2000 09:40:46 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigqc12186 for ; Wed, 15 Mar 2000 14:40:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA05396 for mpls@uu.net; Wed, 15 Mar 2000 09:40:44 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigqc16814 for ; Wed, 15 Mar 2000 14:40:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqc15332 for ; Wed, 15 Mar 2000 09:40:03 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQigqc11517 for ; Wed, 15 Mar 2000 14:40:03 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 09:38:22 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F860@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Thomas D. Nadeau'" , Adrian Farrel Cc: mpls@UU.NET, "'swallow@cisco.com'" , "'vsriniva@cosinecom.com'" Subject: RE: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 09:38:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8E8C.1C9C8A90" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8E8C.1C9C8A90 Content-Type: text/plain; charset="iso-8859-1" Gee, you are the first person I know of that is NOT a working group chair to issue a last call :) I believe Adrian is asking for an end date to the last call, as he may be under the impression that this is an official last call. Could you let us know when it is? And it might be good if you actually check with the co-chairs on this one :) Thanks, Joan -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, March 15, 2000 8:10 AM To: Adrian Farrel Cc: mpls@UU.NET Subject: RE: LSR MIB WG Last Call Please do give comments if there are any. The WG Last Call should not preclude that. The reason why we decided to go WGLC at this point was that even during the last round of reviewed comments (most were from you in fact), the comments were relatively minor. We feel that the MIB is pretty solid and mature at this point. --Tom Your latest version is dated 6th March. It is now 14th. I think it reasonable to give us all a little time to read your work after all of the effort you have put into it. Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Thomas D. Nadeau [ mailto:tnadeau@cisco.com ] >Sent: Tuesday, March 14, 2000 10:49 PM >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan >Cc: Cheenu Srinivasan; arun@force10networks.com >Subject: LSR MIB WG Last Call > > > > Since we have not received any additional comments >on the current version of the LSR MIB, we would like >to raise the document to WG Last Call. > > --Tom > > ------_=_NextPart_001_01BF8E8C.1C9C8A90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Gee,=20 you are the first person I know of that is NOT a working group chair to =
issue=20 a last call :)
 
I=20 believe Adrian is asking for an end date to the last call, as=20 he
may be=20 under the impression that this is an official last = call.
Could=20 you let us know when it is?  And it might be good if=20 you
actually check with the co-chairs on this = one=20 :)
 
Thanks, Joan
 
-----Original Message-----
From: Thomas D. Nadeau=20 [mailto:tnadeau@cisco.com]
Sent: Wednesday, March 15, 2000 = 8:10=20 AM
To: Adrian Farrel
Cc: = mpls@UU.NET
Subject:=20 RE: LSR MIB WG Last=20 = Call

        = ;
        Please=20 do give comments if there are any.
The WG Last Call should not = preclude=20 that. The
reason why we decided to go WGLC at this point
was = that even=20 during the last round of reviewed
comments (most were from you in = fact),=20 the comments
were relatively minor. We feel that the MIB is = pretty=20
solid and mature at this=20 = point.

        --Tom



Your latest version is dated 6th = March.
It=20 is now 14th.

I think it reasonable to give us all a little = time to=20 read your work after
all of the effort you have put into=20 it.

Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
ATM, MPLS and = Telecoms=20 Development Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) = 1244=20 313440  Fax: +44 (0) 1244 312422


>-----Original=20 Message-----
>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
>Sent: = Tuesday, March=20 14, 2000 10:49 PM
>To: mpls@UU.NET; swallow@cisco.com; Vijay=20 Srinivasan
>Cc: Cheenu Srinivasan;=20 arun@force10networks.com
>Subject: LSR MIB WG Last=20 = Call
>
>
>
>     = ;  Since=20 we have not received any additional comments
>on the current = version=20 of the LSR MIB, we would like
>to raise the document to WG = Last=20 = Call.
>
>       --Tom
>
>
------_=_NextPart_001_01BF8E8C.1C9C8A90-- From owner-mpls@UU.NET Wed Mar 15 09:55:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25058 for ; Wed, 15 Mar 2000 09:55:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqd21014; Wed, 15 Mar 2000 14:55:07 GMT Received: by mail-control.mail.uu.net id QQigqd18224 for mpls-outgoing; Wed, 15 Mar 2000 14:54:50 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigqd18214 for ; Wed, 15 Mar 2000 14:54:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqd17815 for ; Wed, 15 Mar 2000 09:54:39 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigqd24969 for ; Wed, 15 Mar 2000 14:54:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA07513 for mpls@uu.net; Wed, 15 Mar 2000 09:54:37 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigqd18181 for ; Wed, 15 Mar 2000 14:54:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqd17415 for ; Wed, 15 Mar 2000 09:53:48 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQigqd24311 for ; Wed, 15 Mar 2000 14:53:47 GMT Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id GAA14630; Wed, 15 Mar 2000 06:53:42 -0800 (PST) Message-Id: <4.2.2.20000315094257.00b21de0@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 09:44:51 -0800 To: CATANZARITI Sergio FTR&D/TI , "'ip-optical@lists.research.bell-labs.com'" From: Chip Sharp Subject: Re: Optical IP activities Cc: "'mpls@UU.NET'" In-Reply-To: <337055FBC675D311A85D00508B5A9C4F25420E@u-mail.rd.francetel ecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk FYI, It looks like the ITU (SG 13, SG15 and possibly SG11) may be getting into this area as well. At the SG13 meeting in Kyoto, there was some discussion of this topic. They are definitely working on next-gen optical networking issues. Chip At 05:23 PM 3/14/00 -0800, CATANZARITI Sergio FTR&D/TI wrote: >Today I was reading the MPLS revised charter sent by Vijay and I have >found optical IP related activities, like that: > >6. Specify extensions to the protocols and procedures used for >signaling explicit routes and to effect fast recovery of LSPs >for use in Optical Cross Connects. > >Now, reading from the IP over Optical BoF description, I find: > >- Modifying existing IP and MPLS routing and connection signaling > protocols > >I know that it is still pretty much immature to talk about results of the >upcoming IP over Optical BoF, but how will an eventual WG coming out from >this BoF reconcile with the MPLS WG activity in the Optical IP arena? > >By working on a generic control plane architecture and requirements >definition, and leaving out to the MPLS WG specific work on the generic >mechanisms and procedure for an MPLS implementation of an Optical IP >control plane? Is this a possible intra-IETF activity scenario? Which others? > >Looking for a brief and rough hint. > >Thanks, >Sergio >-------------------------------------------------------------------- >Sergio Catanzariti Senior Project Manager, Technology Integration France >Telecom R&D 1000 Marina Boulevard Suite 300 Brisbane CA 94005 Tel. >650-875-1526 Fax. >650-875-1505 email:sergio.catanzariti@rd.francetelecom.com >-------------------------------------------------------------------- Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-mpls@UU.NET Wed Mar 15 09:55:45 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25322 for ; Wed, 15 Mar 2000 09:55:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqd26100; Wed, 15 Mar 2000 14:55:44 GMT Received: by mail-control.mail.uu.net id QQigqd18258 for mpls-outgoing; Wed, 15 Mar 2000 14:55:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigqd18243 for ; Wed, 15 Mar 2000 14:55:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqd17847 for ; Wed, 15 Mar 2000 09:54:56 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigqd25283 for ; Wed, 15 Mar 2000 14:54:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA07601 for mpls@uu.net; Wed, 15 Mar 2000 09:54:54 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigqd18194 for ; Wed, 15 Mar 2000 14:54:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqd17785; Wed, 15 Mar 2000 09:54:21 -0500 (EST) Received: from qnsgs000.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qnsgs000.nortelnetworks.com [47.211.0.31] (may be forged)) id QQigqd24731; Wed, 15 Mar 2000 14:54:21 GMT Received: from zhard00d.europe.nortel.com (actually zhard00d) by qnsgs000.nortel.com; Wed, 15 Mar 2000 14:53:50 +0000 Received: from zvb1c004.corpemea.baynetworks.com (ZVB1C004 [141.251.160.84]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G9X0DY77; Wed, 15 Mar 2000 14:53:50 -0000 Received: from nortelnetworks.com (LANDERSS [141.251.192.234]) by zvb1c004.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GHQDYA4Q; Wed, 15 Mar 2000 15:53:45 +0100 Message-ID: <38CFA3D8.F8059CAC@nortelnetworks.com> Date: Wed, 15 Mar 2000 15:53:12 +0100 X-Sybari-Space: 00000000 00000000 00000000 From: "Loa Andersson" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Hummel Heinrich CC: mpls@UU.NET, te-wg@UU.NET Subject: Re: Internet Draft Submission: Orchestrally Conducted Traffic References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Heinrich, there is something that worries me very much about this. From the abstract: "This draft proposes to engineer traffic such that we can speak of an Orchestrally Conducted Traffic (OCT): Any traffic stream (given by its source and destination nodes and by a priority class) may use several differently routed LSPs. Each, traffic stream ingress reports, periodically, the currently measured traffic load (in bitrate) to a common TE Conductor (TEC) who evaluates them as to guess what traffic load change might occur in the immediate time ahead. Accordingly the TEC computes well synchronized likelihood values by which to take which route/LSP. These values will be such that any traffic stream will be served as good as possible, as often as possible, while equally ranked traffic streams are treated fair, higher ranked streams are prioritized and the network thruput is maximized. The TEC sends the likelihood values to the respective ingress node, who will distribute the received packets of the traffic stream to the pertaining LSPs accordingly." I might misread this, but the IP paradigm has been connection less from the start, and very much of the success of IP is because of its of this connection less nature. I do see that we "violate" this little bit by some of the proposals that has been discussed in the mpls and te working groups - for what I believe is good reasons. However we should take extreme care of keeping the connection less nature of IP networks. The Orchestrated Conducted Traffic draft seems to take an extreme connection oriented approach. We should take care not throw the baby, bath tub and bath water out at the same time. /Loa Hummel Heinrich wrote: > > Hi all, > > I emailed draft-hummel-te-oct-01.txt to internet-drafts@ietf.org. > I also applied for a time-slot in the TE-WG for presenting this traffic > balancing concept in Adelaide. > I appreciate any comment on this topic. > > Regards > > Heinrich Hummel > Siemens AG > heinrich.hummel@icn.siemens.de -- Loa Andersson Director Routing Architecture Lab, EMEA St Eriksgatan 115A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 e-mail: loa.andersson@nortelnetworks.com From owner-mpls@UU.NET Wed Mar 15 10:29:30 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08873 for ; Wed, 15 Mar 2000 10:29:29 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqf26200; Wed, 15 Mar 2000 15:29:30 GMT Received: by mail-control.mail.uu.net id QQigqf28222 for mpls-outgoing; Wed, 15 Mar 2000 15:29:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigqf28210 for ; Wed, 15 Mar 2000 15:28:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqf23243 for ; Wed, 15 Mar 2000 10:28:40 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigqf25346 for ; Wed, 15 Mar 2000 15:28:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA12679 for mpls@uu.net; Wed, 15 Mar 2000 10:28:38 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigqf28185 for ; Wed, 15 Mar 2000 15:27:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqf22656 for ; Wed, 15 Mar 2000 10:27:51 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQigqf11437 for ; Wed, 15 Mar 2000 15:27:50 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA13305; Wed, 15 Mar 2000 10:27:45 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA12896; Wed, 15 Mar 2000 10:27:44 -0500 (EST) Message-Id: <200003151527.KAA12896@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Joan Cucchiara cc: "'Thomas D. Nadeau'" , Adrian Farrel , mpls@UU.NET, "'swallow@cisco.com'" , "'vsriniva@cosinecom.com'" , swallow@cisco.com Subject: Re: LSR MIB WG Last Call In-reply-to: Your message of "Wed, 15 Mar 2000 09:38:21 EST." <07B0D4912B83D31188F300A0C9F62EBB15F860@brixcorp2.brixnet.com> Date: Wed, 15 Mar 2000 10:27:44 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Joan - I believe that Tom merely meant to suggest that the LSR mib was now ready for last call. Unless I hear objections I'll issue one before the day is out. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Mar 15 10:35:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11902 for ; Wed, 15 Mar 2000 10:35:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqg16607; Wed, 15 Mar 2000 15:35:53 GMT Received: by mail-control.mail.uu.net id QQigqg28723 for mpls-outgoing; Wed, 15 Mar 2000 15:35:36 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigqg28715 for ; Wed, 15 Mar 2000 15:35:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqg23845 for ; Wed, 15 Mar 2000 10:35:24 -0500 (EST) Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQigqg16170 for ; Wed, 15 Mar 2000 15:35:24 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id JAA02740; Wed, 15 Mar 2000 09:35:16 -0600 (CST) Received: from vsharma ([172.31.101.69] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA01122; Wed, 15 Mar 2000 09:35:16 -0600 (CST) Received: by localhost with Microsoft MAPI; Wed, 15 Mar 2000 10:38:52 -0500 Message-ID: <01BF8E6A.A8283C70.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'vsriniva@cosinecom.com'" , "mpls@UU.NET" Cc: "'swallow@cisco.com'" , "Ben Mack-Crane (E-mail)" , "Chang Huang (E-mail)" , "Ken Owens (E-mail)" , "Srinivas Makam (E-mail)" Subject: RE: revised charter for MPLS WG Date: Wed, 15 Mar 2000 10:38:51 -0500 Organization: Tellabs Research Center X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijay, Thanks for the updated charter, and for including the milestone I suggested. After looking at it carefully, I have a couple of comments on the revised charter. Specifically, it is unclear why item 4 in the problem statement, item 6 under Objectives, and the last milestone all have the qualifier "optical crossconnects." A look at the multitude of drafts submitted recently to the WG on this subject reveals that the mechanisms or procedures are not confined to optical crossconnects --- they talk of dealing with sub-lambda channels, which requires electronic intervention to pull the channels out from a wavelength. In fact, it is not even clear what the term "optical crossconnects," strictly speaking, refers to? An all-optical device, an OEO device, a digital cross-connect with optical interfaces? While the qualifier is certainly appealing, it is unclear to me that it has been made sufficiently precise for it to be part of the formal Charter of the MPLS WG, or that it should be used in the charter at all. Also, it seems to me that when talking about "control plane intergration" what we are really talking about is the integration of signalling functionality with a number of transport elements in the network, of which "optical crossconnects" are but one. For example, are we excluding intelligence on OADMs for dynamically adding/dropping "optical LSPs"? It appears that the last paragraph in the charter attempts to provide some definition of optical cross connects, but is not precise enough. The phrase "in this environment specific wavelengths or lambdas are used instead of labels," is confusing and unclear. What is used in this environment is simply an "optical label" if you will, that includes information on the wavelength, fiber, sub-channel, etc. If indeed "specific wavelengths" are the only ones used in this environment, then it would seem to exclude the case of OEO's (where you go to sub-wavelength channels), and, by extension, the many drafts that talk about them. All of this notwithstanding, for clarity, I'd like to suggest a rewording of Objective 6 as follows: "Specify extensions to the protocols and procedures that are used for signaling explicit routes and for effecting fast recovery so that they may be used in optical crossconnects." At this point, I am not sure of what alternative wording to suggest, since I need to think about it and make a suggestion later. However, I did want to raise the flag, and get people thinking about the issue. Thanks, -Vishal On Tuesday, March 14, 2000 4:33 PM, vsriniva@cosinecom.com [SMTP:vsriniva@cosinecom.com] wrote: > > Here is an update of the WG charter. There weren't many comments on the > list -- the main comments were: > > Item 1. Support for Aggregated QoS > > Andy Malis (amalis@lucent.com) > >8. Define the use of Differentiated and Integrated Services in an MPLS > >environment. > > I suggest the above objective be changed to "aggregated QoS", as > discussed > in November. > > There was not much discussion this subject matter. George Swallow felt such > a change would limit the charter, while Grenville Armitage felt the current > wording limits the charter to two specific QoS models. > > I have reworded the objective to read: > > 8. Define the support of Differentiated and Integrated Services, > including aggregated QoS, in an MPLS environment. > > Item 2. Liaison with other standards bodies > > Andy Malis (amalis@lucent.com) > On a different charter topic, I think the charter should specifically > mention that the WG plans to liaise with other standards bodies, > especially > in the optical area, such as OIF, ITU-T, ANSI, ODSI, etc.. > > There was no consensus on this issue. However, ODSI was added to the list > of standard bodies already mentioned in the charter. If a formal liaison > is required with a particular standards body, the IAB will be contacted > to set one up. > > Item 3. Division of work between TE-WG and MPLS WG > > Philip Matthews > Should the new charter contain some words about the > division of work between the MPLS WG and the TE WG? > > There was no further discussion on this subject. The charter currently > does not address this subject. > > Item 4. LSP Recovery > > Vishal Sharma (Vishal.Sharma@tellabs.com) > I would like to suggest adding the following as a milestone: > > Produce specifications for protocols and procedures that support > LSP recovery > > A milestone has been added for this. > > ---------------------------------------------------------------------------- > ---------- > > Multiprotocol Label Switching (mpls) Charter > > > Problem Statement: > > Label switching in conjunction with network layer routing has emerged > as an important new technology. It is actively being applied to > applications such as traffic engineering and virtual private networks. > Among the problems this technology is expected to address are the > following: > > 1. Greater flexibility in delivering routing services > > Using labels to identify particular traffic which are to receive > special services, e.g. QoS. > > Using labels to provide forwarding along an explicit path different > from the one constructed by destination-based forwarding. > > 2. Scalability of network layer routing > > Using labels as a means to aggregate forwarding information, while > working in the presence of routing hierarchies. > > 3. Simplify integration of routers with cell switching based > technologies > > a) making cell switches behave as peers to routers (thus reducing > the number of routing peers that a router has to maintain), > > b) by making information about physical topology available to > Network Layer routing procedures, and > > c) by employing common addressing, routing, and management > procedures. > > 4. Simplify integration of routers with optical cross-connect based > technologies > > a) making optical cross connects behave as peers to routers (thus > reducing the number of routing peers that a router has to maintain), > > b) by making information about physical topology available to > Network Layer routing procedures, and > > c) by employing common addressing, routing, and management > procedures. > > High Level Requirements > > 1. The solution should be general with respect to data link > technologies. Specific optimizations for particular media will be > considered. > > 2. The solution must be compatible with existing internetwork > technologies and routing protocols. > > 3. The solution should support a wide range of forwarding > granularities associated with a given label, from a single > application flow to a group of topologically related destinations. > > 4. The solution should support operations, administration, and > maintenance facilities at least as extensive as those supported in > IP networks. > > 5. The solution should provide stable routing. The protocols defined > by MPLS must provide protocol mechanism(s) to either prevent the > formation of loops and/or contain the amount of (networking) resources > that could be consumed due to the presence of such loops. > > 6. The solution should be very scalable. Scalability issues will be > considered and analyzed. > > > Charter Statement: > > The working group is responsible for standardizing a base technology > for using label switching in conjunction with network layer routing > and for the implementation of that technology over various link level > technologies, which may include Packet-over-Sonet, Frame Relay, ATM, > Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,... > > This includes procedures and protocols for the distribution of labels > between routers, encapsulations, multicast considerations, and the use > of labels to support higher layer resource reservation and QoS > mechanisms. > > The working group will also specify a control plane for optical cross > connects. In this environment specific wave lengths or Lambdas are > used instead of labels. > > > Objectives: > > 1. Specify standard protocol(s) for maintenance and distribution of > label binding information to support unicast destination-based > routing. > > 2. Specify standard protocol(s) for maintenance and distribution of > label binding information to support multicast routing. > > 3. Specify standard protocol(s) for maintenance and distribution of > label binding information to support hierarchy of routing knowledge > (e.g., complete segregation of intra and inter-domain routing). > > 4. Specify standard protocol(s) for maintenance and distribution of > label binding information to support explicit paths in support of > applications such as Traffic Engineering. > > 5. Specify standard protocols and procedures to support the fast > recovery of Label Switched Paths. > > 6. Specify extensions to the protocols and procedures used for > signaling explicit routes and to effect fast recovery of LSPs > for use in Optical Cross Connects. > > 7. Specify standard procedures of carrying label information over > various link level technologies including ATM. > > 8. Define the support of Differentiated and Integrated Services, > including aggregated QoS, in an MPLS environment. > > 9. Specify standard protocols and procedures to support operations, > administration, and maintenance facilities. > > > Coordination: > > The working group will coordinate its activities with other working > groups as appropriate. For specific technologies, the WG will > cooperate with the appropriate standards bodies such as OIF, ITU-T, > ANSI, ODSI etc. > > > Goals and Milestones: > > Mar 00 - Produce a document which defines support of Differentiated > Services (Diff-Serv) over Multi-Protocol Label Switching > (MPLS) networks (Standards Track). > > Aug 00 - Produce a document which defines operation with RSVP for > unicast destinations. (Standards Track). > > Aug 00 - Produce specifications for protocols and procedures that support > fault recovery in an MPLS environment > > Dec 00 - Produce specifications for a MPLS control plane for optical > cross-connects (Standards Track). > > > > > > > > > > > > > > > > > > << File: ATT00006.html >> From owner-mpls@UU.NET Wed Mar 15 10:49:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17155 for ; Wed, 15 Mar 2000 10:49:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqh28867; Wed, 15 Mar 2000 15:49:35 GMT Received: by mail-control.mail.uu.net id QQigqh00197 for mpls-outgoing; Wed, 15 Mar 2000 15:49:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigqh00191 for ; Wed, 15 Mar 2000 15:49:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqh26553 for ; Wed, 15 Mar 2000 10:48:34 -0500 (EST) Received: from qnsgs000.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qnsgs000.nortelnetworks.com [47.211.0.31] (may be forged)) id QQigqh10192 for ; Wed, 15 Mar 2000 15:48:34 GMT Received: from zhard00d.europe.nortel.com (actually zhard00d) by qnsgs000.nortel.com; Wed, 15 Mar 2000 15:47:52 +0000 Received: from zvb1c004.corpemea.baynetworks.com (ZVB1C004 [141.251.160.84]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G9X0D9S5; Wed, 15 Mar 2000 15:47:52 -0000 Received: from nortelnetworks.com (FIFFI [141.251.192.196]) by zvb1c004.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GHQDYAXA; Wed, 15 Mar 2000 16:47:47 +0100 Message-ID: <38CFB089.2C675B67@nortelnetworks.com> Date: Wed, 15 Mar 2000 16:47:21 +0100 X-Sybari-Space: 00000000 00000000 00000000 From: "Fiffi Hellstrand" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Srinivasan CC: "'mpls@uu.net'" Subject: Re: revised charter for MPLS WG References: Content-Type: multipart/mixed; boundary="------------11882EE5510C020F4FE3B26F" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------11882EE5510C020F4FE3B26F Content-Type: multipart/alternative; boundary="------------57F6551ECCE930B008AC3FF9" --------------57F6551ECCE930B008AC3FF9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, The recovery framework draft uses the term "MPLS-based recovery" instead of LSP recovery to reflect that more than just LSPs can be recovered using MPLS mechanisms. The recovery path is an LSP but may protect all types of paths, not only LSPs. Maybe it is a good idea to reflect that in the charter as well. Objective #5 could read "Specify standard protocols and procedures to support fast MPLS based recovery" and objective 6 may be changed as well. Any objections? Regards, Fiffi Vijay Srinivasan wrote: > Multiprotocol Label Switching (mpls) Charter > Objectives: > > 5. Specify standard protocols and procedures to support the fast > recovery of Label Switched Paths. > > 6. Specify extensions to the protocols and procedures used for > signaling explicit routes and to effect fast recovery of LSPs > for use in Optical Cross Connects. Fiffi Hellstrand Nortel Networks Routing Architecture Lab S:t Eriksgatan 115 A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 5088-3687, mobile +46 70 559-3687 e-mail: fiffi@nortelnetworks.com --------------57F6551ECCE930B008AC3FF9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

The recovery framework draft uses the term "MPLS-based recovery" instead of LSP recovery to reflect that more than just LSPs can be recovered using MPLS mechanisms. The recovery path is an LSP but  may protect all types of paths, not only LSPs. Maybe it is a good idea to reflect that in the charter as well.

Objective #5 could read
"Specify standard protocols and procedures to support fast MPLS based
recovery"

and objective 6 may be changed as well. Any objections?

Regards,

Fiffi

Vijay Srinivasan wrote:

Multiprotocol Label Switching (mpls) Charter
Objectives:

5.  Specify standard protocols and procedures to support the fast
recovery of Label Switched Paths.

6.  Specify extensions to the protocols and procedures used for
signaling explicit routes and to effect fast recovery of LSPs
for use in Optical Cross Connects.


Fiffi Hellstrand
Nortel Networks
Routing Architecture Lab
S:t Eriksgatan 115 A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 5088-3687, mobile +46 70 559-3687
e-mail: fiffi@nortelnetworks.com
 
  --------------57F6551ECCE930B008AC3FF9-- --------------11882EE5510C020F4FE3B26F Content-Type: text/x-vcard; charset=us-ascii; name="fiffi.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Fiffi Hellstrand Content-Disposition: attachment; filename="fiffi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Hellstrand;Fiffi tel;cell:+46 70 559 36 87 tel;fax:+46 8 5088 3501 tel;work:+46 8 50 88 36 87 x-mozilla-html:FALSE org:Nortel Networks;Routing Architecture Lab version:2.1 email;internet:fiffi@nortelnetworks.com title:Senior Systems Engineer adr;quoted-printable:;;P.O. Box 6701=0D=0ASt Eriksgatan 115A;Stockholm;;S-113 85;Sweden fn:Fiffi Hellstrand end:vcard --------------11882EE5510C020F4FE3B26F-- From owner-mpls@UU.NET Wed Mar 15 10:58:52 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20757 for ; Wed, 15 Mar 2000 10:58:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqh07344; Wed, 15 Mar 2000 15:58:49 GMT Received: by mail-control.mail.uu.net id QQigqh00854 for mpls-outgoing; Wed, 15 Mar 2000 15:58:07 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigqh00849 for ; Wed, 15 Mar 2000 15:58:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqh28197 for ; Wed, 15 Mar 2000 10:57:53 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigqh06391 for ; Wed, 15 Mar 2000 15:57:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA18386 for mpls@uu.net; Wed, 15 Mar 2000 10:57:51 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigqh00810 for ; Wed, 15 Mar 2000 15:57:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqh27199 for ; Wed, 15 Mar 2000 10:57:22 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQigqh05964 for ; Wed, 15 Mar 2000 15:57:21 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 10:55:40 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F866@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'George Swallow'" , Joan Cucchiara Cc: "'Thomas D. Nadeau'" , Adrian Farrel , mpls@UU.NET, "'vsriniva@cosinecom.com'" Subject: RE: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 10:55:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk George, I do raise an objection. It has been pointed out to me that the rev 02 of the LSR MIB now states that it intends to support LDP. When the (TE-MIB which contained the LSR-MIB) was proposed as a working group document in Minneapolis, Jim Luciani asked if there would be overlap with the LDP MIB, he (and the rest of the working group) were told, "no, not much". Now, they intend (apparently) to support LDP. As a working group, we do NOT need two mibs to support the same protocol. So I object on this basis. It does not seem fair to me that 3 revisions into the LSR MIB, the LSR MIB can expand its scope to support another protocol, namely LDP, especially when there is already an active LDP MIB. There has been NO working group consensus about including LDP in scope of the LSR MIB. Why does the working group need two MIBs for LDP? Thank you, Joan > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, March 15, 2000 10:28 AM > To: Joan Cucchiara > Cc: 'Thomas D. Nadeau'; Adrian Farrel; mpls@UU.NET; > 'swallow@cisco.com'; > 'vsriniva@cosinecom.com'; swallow@cisco.com > Subject: Re: LSR MIB WG Last Call > > > Joan - > > I believe that Tom merely meant to suggest that the LSR mib was now > ready for last call. Unless I hear objections I'll issue one before > the day is out. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Wed Mar 15 11:29:11 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03368 for ; Wed, 15 Mar 2000 11:29:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqj05967; Wed, 15 Mar 2000 16:29:11 GMT Received: by mail-control.mail.uu.net id QQigqj10818 for mpls-outgoing; Wed, 15 Mar 2000 16:28:49 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigqj10813 for ; Wed, 15 Mar 2000 16:28:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqj03361 for ; Wed, 15 Mar 2000 11:28:41 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQigqj05491 for ; Wed, 15 Mar 2000 16:28:40 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Wed, 15 Mar 2000 11:28:30 -0500 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GXRMJ53F; Wed, 15 Mar 2000 11:28:25 -0500 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G9NS2V26; Wed, 15 Mar 2000 11:28:24 -0500 Message-ID: <38CFB9C1.58366A72@americasm01.nt.com> Date: Wed, 15 Mar 2000 11:26:41 -0500 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Srinivasan CC: "'mpls@uu.net'" Subject: Re: revised charter for MPLS WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Given that you decided not to say anything explicit about coordination of work between the TE and MPLS WGs, how to you (as co-chair) plan to avoid the type of problems that occurred in Washington? - Philip From owner-mpls@UU.NET Wed Mar 15 11:29:41 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03553 for ; Wed, 15 Mar 2000 11:29:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqj04775; Wed, 15 Mar 2000 16:29:41 GMT Received: by mail-control.mail.uu.net id QQigqj10843 for mpls-outgoing; Wed, 15 Mar 2000 16:29:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigqj10832 for ; Wed, 15 Mar 2000 16:29:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqj02203 for ; Wed, 15 Mar 2000 11:28:47 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigqj03893 for ; Wed, 15 Mar 2000 16:28:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA23032 for mpls@uu.net; Wed, 15 Mar 2000 11:28:45 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigqj10798 for ; Wed, 15 Mar 2000 16:28:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqj02098 for ; Wed, 15 Mar 2000 11:27:51 -0500 (EST) Received: from qnsgs000.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qnsgs000.nortelnetworks.com [47.211.0.31] (may be forged)) id QQigqj04922 for ; Wed, 15 Mar 2000 16:27:51 GMT Received: from zhard00d.europe.nortel.com (actually zhard00d) by qnsgs000.nortel.com; Wed, 15 Mar 2000 16:25:26 +0000 Received: from zvb1c004.corpemea.baynetworks.com (ZVB1C004 [141.251.160.84]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G9X01C2H; Wed, 15 Mar 2000 16:25:25 -0000 Received: from nortelnetworks.com (LANDERSS [141.251.192.234]) by zvb1c004.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GHQDYAZA; Wed, 15 Mar 2000 17:25:23 +0100 Message-ID: <38CFB94B.48951986@nortelnetworks.com> Date: Wed, 15 Mar 2000 17:24:43 +0100 X-Sybari-Space: 00000000 00000000 00000000 From: "Loa Andersson" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "'vsriniva@cosinecom.com'" , "mpls@UU.NET" , "'swallow@cisco.com'" CC: "Vishal.Sharma@tellabs.com" , "Ben Mack-Crane (E-mail)" , "Chang Huang (E-mail)" , "Ken Owens (E-mail)" , "Srinivas Makam (E-mail)" Subject: Re: revised charter for MPLS WG References: <01BF8E6A.A8283C70.Vishal.Sharma@tellabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I've three smaller (I hope :-) comments on the charter. 1. The charter says that the WG should co-ordinate the work with other organizations "such as OIF, ITU-T, ANSI, ODSI etc." I've the feeling that the list is a bit random. There could be other organizations that should be on that list, what about MSF? This is minor. I'm more concerned about the "coordintion/cooperation", what mandated does it vest on who and on behalf of whom? I've a feeling that there might be legal (US legal :-) aspects here. 2. The milestone "Aug 00 - Produce a document which defines operation with RSVP for unicast destinations. (Standards Track)." It is the first time RSVP is mentioned in the charter and it is to say the least unclear what the intentions is. At least three different tasks could be what is intended: - tunneling of RSVP signaling through a LSP - making RSVP the only protocol for label distribution in the unicast case - using RSVP for resource reservation on established LSP's 3. The objective 7 says "7. Specify standard procedures of carrying label information over various link level technologies including ATM." I suggest that it is changed to "7. Specify standard procedures of carrying label information over various link level technologies." /Loa Vishal Sharma wrote: > > Vijay, > > Thanks for the updated charter, and for including the milestone I suggested. > > After looking at it carefully, I have a couple of comments on the revised > charter. > Specifically, it is unclear why item > 4 in the problem statement, item 6 under Objectives, and the last milestone all > have > the qualifier "optical crossconnects." A look at the multitude of drafts > submitted recently > to the WG on this subject reveals that the mechanisms or procedures are not > confined > to optical crossconnects --- they talk of dealing with sub-lambda channels, > which requires > electronic intervention to pull the channels out from a wavelength. > > In fact, it is not even clear what the term "optical crossconnects," strictly > speaking, refers to? > An all-optical device, an OEO device, a digital cross-connect with optical > interfaces? > > While the qualifier is certainly appealing, it is unclear to me that it has > been made sufficiently > precise for it to be part of the formal Charter of the MPLS WG, or that it > should be used in the > charter at all. > > Also, it seems to me that when talking about "control plane intergration" what > we are really talking > about is the integration of signalling functionality with a number of transport > elements in the network, > of which "optical crossconnects" are but one. For example, are we excluding > intelligence on OADMs > for dynamically adding/dropping "optical LSPs"? > > It appears that the last paragraph in the charter attempts to provide some > definition of optical cross connects, > but is not precise enough. The phrase "in this environment specific wavelengths > or lambdas are used instead of labels," is confusing and unclear. What is used > in this environment > is simply an "optical label" if you will, that includes information on the > wavelength, fiber, sub-channel, etc. > If indeed "specific wavelengths" are the only ones used in this environment, > then it would > seem to exclude the case of OEO's (where you go to sub-wavelength channels), > and, by extension, the > many drafts that talk about them. > > All of this notwithstanding, for clarity, I'd like to suggest a rewording of > Objective 6 as follows: > "Specify extensions to the protocols and procedures that are used for signaling > explicit routes and > for effecting fast recovery so that they may be used in optical crossconnects." > > At this point, I am not sure of what alternative wording to suggest, since I > need to think about > it and make a suggestion later. > However, I did want to raise the flag, and get people thinking about the issue. > > Thanks, > > -Vishal > > On Tuesday, March 14, 2000 4:33 PM, vsriniva@cosinecom.com > [SMTP:vsriniva@cosinecom.com] wrote: > > > > Here is an update of the WG charter. There weren't many comments on the > > list -- the main comments were: > > > > Item 1. Support for Aggregated QoS > > > > Andy Malis (amalis@lucent.com) > > >8. Define the use of Differentiated and Integrated Services in an MPLS > > >environment. > > > > I suggest the above objective be changed to "aggregated QoS", as > > discussed > > in November. > > > > There was not much discussion this subject matter. George Swallow felt such > > a change would limit the charter, while Grenville Armitage felt the current > > wording limits the charter to two specific QoS models. > > > > I have reworded the objective to read: > > > > 8. Define the support of Differentiated and Integrated Services, > > including aggregated QoS, in an MPLS environment. > > > > Item 2. Liaison with other standards bodies > > > > Andy Malis (amalis@lucent.com) > > On a different charter topic, I think the charter should specifically > > mention that the WG plans to liaise with other standards bodies, > > especially > > in the optical area, such as OIF, ITU-T, ANSI, ODSI, etc.. > > > > There was no consensus on this issue. However, ODSI was added to the list > > of standard bodies already mentioned in the charter. If a formal liaison > > is required with a particular standards body, the IAB will be contacted > > to set one up. > > > > Item 3. Division of work between TE-WG and MPLS WG > > > > Philip Matthews > > Should the new charter contain some words about the > > division of work between the MPLS WG and the TE WG? > > > > There was no further discussion on this subject. The charter currently > > does not address this subject. > > > > Item 4. LSP Recovery > > > > Vishal Sharma (Vishal.Sharma@tellabs.com) > > I would like to suggest adding the following as a milestone: > > > > Produce specifications for protocols and procedures that support > > LSP recovery > > > > A milestone has been added for this. > > > > ---------------------------------------------------------------------------- > > ---------- > > > > Multiprotocol Label Switching (mpls) Charter > > > > > > Problem Statement: > > > > Label switching in conjunction with network layer routing has emerged > > as an important new technology. It is actively being applied to > > applications such as traffic engineering and virtual private networks. > > Among the problems this technology is expected to address are the > > following: > > > > 1. Greater flexibility in delivering routing services > > > > Using labels to identify particular traffic which are to receive > > special services, e.g. QoS. > > > > Using labels to provide forwarding along an explicit path different > > from the one constructed by destination-based forwarding. > > > > 2. Scalability of network layer routing > > > > Using labels as a means to aggregate forwarding information, while > > working in the presence of routing hierarchies. > > > > 3. Simplify integration of routers with cell switching based > > technologies > > > > a) making cell switches behave as peers to routers (thus reducing > > the number of routing peers that a router has to maintain), > > > > b) by making information about physical topology available to > > Network Layer routing procedures, and > > > > c) by employing common addressing, routing, and management > > procedures. > > > > 4. Simplify integration of routers with optical cross-connect based > > technologies > > > > a) making optical cross connects behave as peers to routers (thus > > reducing the number of routing peers that a router has to maintain), > > > > b) by making information about physical topology available to > > Network Layer routing procedures, and > > > > c) by employing common addressing, routing, and management > > procedures. > > > > High Level Requirements > > > > 1. The solution should be general with respect to data link > > technologies. Specific optimizations for particular media will be > > considered. > > > > 2. The solution must be compatible with existing internetwork > > technologies and routing protocols. > > > > 3. The solution should support a wide range of forwarding > > granularities associated with a given label, from a single > > application flow to a group of topologically related destinations. > > > > 4. The solution should support operations, administration, and > > maintenance facilities at least as extensive as those supported in > > IP networks. > > > > 5. The solution should provide stable routing. The protocols defined > > by MPLS must provide protocol mechanism(s) to either prevent the > > formation of loops and/or contain the amount of (networking) resources > > that could be consumed due to the presence of such loops. > > > > 6. The solution should be very scalable. Scalability issues will be > > considered and analyzed. > > > > > > Charter Statement: > > > > The working group is responsible for standardizing a base technology > > for using label switching in conjunction with network layer routing > > and for the implementation of that technology over various link level > > technologies, which may include Packet-over-Sonet, Frame Relay, ATM, > > Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,... > > > > This includes procedures and protocols for the distribution of labels > > between routers, encapsulations, multicast considerations, and the use > > of labels to support higher layer resource reservation and QoS > > mechanisms. > > > > The working group will also specify a control plane for optical cross > > connects. In this environment specific wave lengths or Lambdas are > > used instead of labels. > > > > > > Objectives: > > > > 1. Specify standard protocol(s) for maintenance and distribution of > > label binding information to support unicast destination-based > > routing. > > > > 2. Specify standard protocol(s) for maintenance and distribution of > > label binding information to support multicast routing. > > > > 3. Specify standard protocol(s) for maintenance and distribution of > > label binding information to support hierarchy of routing knowledge > > (e.g., complete segregation of intra and inter-domain routing). > > > > 4. Specify standard protocol(s) for maintenance and distribution of > > label binding information to support explicit paths in support of > > applications such as Traffic Engineering. > > > > 5. Specify standard protocols and procedures to support the fast > > recovery of Label Switched Paths. > > > > 6. Specify extensions to the protocols and procedures used for > > signaling explicit routes and to effect fast recovery of LSPs > > for use in Optical Cross Connects. > > > > 7. Specify standard procedures of carrying label information over > > various link level technologies including ATM. > > > > 8. Define the support of Differentiated and Integrated Services, > > including aggregated QoS, in an MPLS environment. > > > > 9. Specify standard protocols and procedures to support operations, > > administration, and maintenance facilities. > > > > > > Coordination: > > > > The working group will coordinate its activities with other working > > groups as appropriate. For specific technologies, the WG will > > cooperate with the appropriate standards bodies such as OIF, ITU-T, > > ANSI, ODSI etc. > > > > > > Goals and Milestones: > > > > Mar 00 - Produce a document which defines support of Differentiated > > Services (Diff-Serv) over Multi-Protocol Label Switching > > (MPLS) networks (Standards Track). > > > > Aug 00 - Produce a document which defines operation with RSVP for > > unicast destinations. (Standards Track). > > > > Aug 00 - Produce specifications for protocols and procedures that support > > fault recovery in an MPLS environment > > > > Dec 00 - Produce specifications for a MPLS control plane for optical > > cross-connects (Standards Track). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > << File: ATT00006.html >> -- Loa Andersson Director Routing Architecture Lab, EMEA St Eriksgatan 115A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 e-mail: loa.andersson@nortelnetworks.com From owner-mpls@UU.NET Wed Mar 15 11:58:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15619 for ; Wed, 15 Mar 2000 11:58:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigql00143; Wed, 15 Mar 2000 16:58:27 GMT Received: by mail-control.mail.uu.net id QQigql12337 for mpls-outgoing; Wed, 15 Mar 2000 16:58:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigql12332 for ; Wed, 15 Mar 2000 16:57:54 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigql07922 for ; Wed, 15 Mar 2000 11:57:32 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigql29200 for ; Wed, 15 Mar 2000 16:57:32 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id LAA02207; Wed, 15 Mar 2000 11:52:31 -0500 Message-ID: <38CFC2AF.5E6A3364@tellium.com> Date: Wed, 15 Mar 2000 12:04:47 -0500 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Srinivasan CC: "'mpls@uu.net'" Subject: Re: revised charter for MPLS WG References: Content-Type: multipart/alternative; boundary="------------871B3377B96A97FC671A254F" Sender: owner-mpls@UU.NET Precedence: bulk --------------871B3377B96A97FC671A254F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vijay Srinivasan wrote: > > > > 3. Simplify integration of routers with cell switching based > technologies > > a) making cell switches behave as peers to routers (thus reducing > the number of routing peers that a router has to maintain), > > b) by making information about physical topology available to > Network Layer routing procedures, and > > c) by employing common addressing, routing, and management > procedures. > > 4. Simplify integration of routers with optical cross-connect based > technologies > > a) making optical cross connects behave as peers to routers (thus > reducing the number of routing peers that a router has to maintain), > > b) by making information about physical topology available to > Network Layer routing procedures, and > > c) by employing common addressing, routing, and management > procedures. I'm not sure what MPLS has got to do with all this. (3) and (4) seem to be routing problems that perhaps OSPF etc. can deal with. Could you clarify this? > > > > > Charter Statement: > > > > The working group will also specify a control plane for optical cross > connects. In this environment specific wave lengths or Lambdas are > used instead of labels. I believe you need specific requirements for this. From your other mail is it appropriate to assume that a WG like ip-over-optical (if formed) will supply this? -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com --------------871B3377B96A97FC671A254F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Vijay Srinivasan wrote:

 
 

3.  Simplify integration of routers with cell switching based
technologies

a) making cell switches behave as peers to routers (thus reducing
the number of routing peers that a  router has to maintain),

b) by making information about physical topology available to
Network Layer routing procedures, and

c) by employing common addressing, routing, and management
procedures.

4.  Simplify integration of routers with optical cross-connect based
technologies

a) making optical cross connects behave as peers to routers (thus
reducing the number of routing peers that a router has to maintain),

b) by making information about physical topology available to
Network Layer routing procedures, and

c) by employing common addressing, routing, and management
procedures.


I'm not sure what MPLS has got to do with all this. (3)  and (4) seem to be routing problems
that perhaps OSPF etc. can deal with. Could you clarify this?

 
 
 

Charter Statement:
 
 

The working group will also specify a control plane for optical cross
connects.  In this environment specific wave lengths or Lambdas are
used instead of labels.

I believe you need specific requirements for this. From your other mail is it appropriate to
assume that a WG like ip-over-optical (if formed) will supply this?

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com
  --------------871B3377B96A97FC671A254F-- From owner-mpls@UU.NET Wed Mar 15 12:15:43 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23273 for ; Wed, 15 Mar 2000 12:15:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqn04727; Wed, 15 Mar 2000 17:15:42 GMT Received: by mail-control.mail.uu.net id QQigqn21186 for mpls-outgoing; Wed, 15 Mar 2000 17:15:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigqm21035 for ; Wed, 15 Mar 2000 17:14:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqm08820 for ; Wed, 15 Mar 2000 12:14:43 -0500 (EST) Received: from tenornetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQigqm04029 for ; Wed, 15 Mar 2000 17:14:43 GMT Received: from mancour (mancour.tenornet.com [192.168.0.137]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id MAA29628; Wed, 15 Mar 2000 12:14:33 -0500 (EST) From: "Tim Mancour" To: "Thomas D. Nadeau" , , , "Vijay Srinivasan" Cc: "Cheenu Srinivasan" , Subject: RE: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 12:18:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.2.2.20000314174805.00d13f00@funnel.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom, I think it is a little premature for a last call on this MIB. I only had a chance to print-out the -02 version yesterday and have the following comments: 1. There is no mention in the MIB regarding the LSP type/style (e.g. E-LSP or L-LSP). Perhaps an object should be added to the cross-connect table? 2. I'm confused about the COS object in the XC table. Section 4 references the COS information in the [LblStk] I-D but there is no mention of COS in this I-D. From the mplsXCCOS description, I assume that this value should be used to overwrite the EXP bits. If this is true then there needs to be a way to disable overwriting the EXP bits. 3. Why is the syntax of all of the get next index objects (e.g. mplsXCIndexNext) read-only? Shouldn't the TestAndIncr textual convention be followed? 4. There are a number of typos regarding indexes. For example, mplsInSegmentXCIndex has a syntax of "Integer32 (1..2147483647)" but the description states that 0 is a valid value. It may be advisable to create textual conventions to avoid these problems; something like MplsIndex and MplsIndexOrZero. 5. There are also problems with bandwidth units and descriptions. As I understand it, all bandwidths should be in kilobits per second. In some places, the UNIT is "bits per second". In other places the description contains "kilobits per second (Kbps/sec)" which should be either "kilobits per second (Kbps)" or "kilobits per second (Kb/sec)". 6. Section 6.2 mentions a mplsInterfaceResTable but no table exists. 7. The syntax for the mplsInSegmentNPop is Integer32(1..2147483647). It should be Integer32(0..2147483647) or even INTEGER(0..255); since popping 255 labels is still a very large range. Best regards. TimM -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas D. Nadeau Sent: Tuesday, March 14, 2000 5:49 PM To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan Cc: Cheenu Srinivasan; arun@force10networks.com Subject: LSR MIB WG Last Call Since we have not received any additional comments on the current version of the LSR MIB, we would like to raise the document to WG Last Call. --Tom From owner-mpls@UU.NET Wed Mar 15 12:45:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05239 for ; Wed, 15 Mar 2000 12:45:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqp11876; Wed, 15 Mar 2000 17:45:51 GMT Received: by mail-control.mail.uu.net id QQigqp24481 for mpls-outgoing; Wed, 15 Mar 2000 17:45:25 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigqp24469 for ; Wed, 15 Mar 2000 17:45:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqp12584 for ; Wed, 15 Mar 2000 12:45:06 -0500 (EST) Received: from albatross.wise.edt.ericsson.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQigqp21226 for ; Wed, 15 Mar 2000 17:45:05 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id SAA13935 for ; Wed, 15 Mar 2000 18:35:40 +0100 (MET) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id SAA28180 for ; Wed, 15 Mar 2000 18:38:20 +0100 (MET) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FRH00E6H4ZVIE@mbb1.ericsson.se> for mpls@UU.NET; Wed, 15 Mar 2000 18:38:19 +0100 (MET) Date: Wed, 15 Mar 2000 18:37:53 +0100 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: LSR MIB WG Last Call To: "Thomas D. Nadeau" Cc: Adrian Farrel , mpls@UU.NET Message-id: <38CFCA71.DC20295E@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <4.2.2.20000315080814.00dedd00@funnel.cisco.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom, I would like to know why you have "issued a last call? You should ( and probably are) very familiar with WG last calls procedures. And those defenetly don't say that somebody whoever can issue a last call because he feels something. Also, I would assume that you are very aware that a mib that formally have been out in two days and have had a second revision within two weeks are not a "solid and mature" one. It almost ridiculous to say something like that when it doesn't even compile! The only thing you create is confusion, hopefully that isn't the goal of the exercise. But what was your purpuse? /// Hasse "Thomas D. Nadeau" wrote: > > > Please do give comments if there are any. > The WG Last Call should not preclude that. The > reason why we decided to go WGLC at this point > was that even during the last round of reviewed > comments (most were from you in fact), the comments > were relatively minor. We feel that the MIB is pretty > solid and mature at this point. > > --Tom > > > Your latest version is dated 6th March. > > It is now 14th. > > > > I think it reasonable to give us all a little time to read your work > > after > > all of the effort you have put into it. > > > > Adrian > > -- > > Adrian Farrel mailto:af@datcon.co.uk > > ATM, MPLS and Telecoms Development Group > > Data Connection Ltd., Chester, UK > > http://www.datcon.co.uk/ > > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > > > > >-----Original Message----- > > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > >Sent: Tuesday, March 14, 2000 10:49 PM > > >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan > > >Cc: Cheenu Srinivasan; arun@force10networks.com > > >Subject: LSR MIB WG Last Call > > > > > > > > > > > > Since we have not received any additional comments > > >on the current version of the LSR MIB, we would like > > >to raise the document to WG Last Call. > > > > > > --Tom > > > > > > > > From owner-mpls@UU.NET Wed Mar 15 13:04:19 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12659 for ; Wed, 15 Mar 2000 13:04:19 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqq27910; Wed, 15 Mar 2000 18:04:18 GMT Received: by mail-control.mail.uu.net id QQigqq29726 for mpls-outgoing; Wed, 15 Mar 2000 18:03:46 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigqq29641 for ; Wed, 15 Mar 2000 18:03:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqq16631 for ; Wed, 15 Mar 2000 13:03:29 -0500 (EST) Received: from smtp6.mindspring.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQigqq01640 for ; Wed, 15 Mar 2000 18:03:29 GMT Received: from jluciani (user-2ive0j3.dialup.mindspring.com [165.247.2.99]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id NAA01970; Wed, 15 Mar 2000 13:03:06 -0500 (EST) Message-ID: <015c01bf8ea8$b587f7a0$1270fea9@jluciani> Reply-To: "James V. Luciani" From: "James V. Luciani" To: "Tim Mancour" , "Thomas D. Nadeau" , , , "Vijay Srinivasan" Cc: "Cheenu Srinivasan" , References: Subject: Re: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 13:03:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tim, My $0.02 ($0.04 according to AMT :-)) I also find it premature to do a last call on this mib. You are not the only person to raise the objection that he/she has not had sufficient time to look at the LSR MIB and absorb the full impact of the changes which have been made. I know I have not. I certainly have not had sufficient time to comment. Further, I find it exceedingly disturbing that this MIB seems to have grown in scope by leaps and bounds without sufficient scrutiny by those who would instrument it; let alone without receiveing working group consensus (as fuzzy as the term 'working group conensus' may be in practice). It would seem prudent to wait atleast until after Adelaide to make a decision on whether to go to last call. The high bandwidth interactions that occur at face to face meetings may be the precise catalyst by which to advance this MIB which might otherwise languish for months without attention like it did after the first draft. And yes, I know that the progress in MPLS has not been at the rate that we all would like but we certainly don't want to be guilty of advancing a MIB which is either incorrect or irrelevant. Note, I am not suggesting that the MIB is either incorrect or irrelevant but rather I making the point that several others have made which is that "I simply don't know" because I have not had adequate time to do due dilligence after some major changes have occurred in the MIB. --JIm > I think it is a little premature for a last call on this MIB. > I only had a chance to print-out the -02 version yesterday > and have the following comments: > > 1. There is no mention in the MIB regarding the > LSP type/style (e.g. E-LSP or L-LSP). Perhaps > an object should be added to the cross-connect table? > > 2. I'm confused about the COS object in the XC table. > Section 4 references the COS information in the [LblStk] > I-D but there is no mention of COS in this I-D. From the > mplsXCCOS description, I assume that this value should be > used to overwrite the EXP bits. If this is true then there > needs to be a way to disable overwriting the EXP bits. > > 3. Why is the syntax of all of the get next index objects > (e.g. mplsXCIndexNext) read-only? Shouldn't the TestAndIncr > textual convention be followed? > > 4. There are a number of typos regarding indexes. For example, > mplsInSegmentXCIndex has a syntax of "Integer32 (1..2147483647)" > but the description states that 0 is a valid value. It may be > advisable to create textual conventions to avoid these problems; > something like MplsIndex and MplsIndexOrZero. > > 5. There are also problems with bandwidth units and descriptions. > As I understand it, all bandwidths should be in kilobits per > second. In some places, the UNIT is "bits per second". In other > places the description contains "kilobits per second (Kbps/sec)" > which should be either "kilobits per second (Kbps)" or "kilobits > per second (Kb/sec)". > > 6. Section 6.2 mentions a mplsInterfaceResTable but no table > exists. > > 7. The syntax for the mplsInSegmentNPop is Integer32(1..2147483647). > It should be Integer32(0..2147483647) or even INTEGER(0..255); > since popping 255 labels is still a very large range. > > Best regards. > TimM > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas D. > Nadeau > Sent: Tuesday, March 14, 2000 5:49 PM > To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan > Cc: Cheenu Srinivasan; arun@force10networks.com > Subject: LSR MIB WG Last Call > > > > Since we have not received any additional comments > on the current version of the LSR MIB, we would like > to raise the document to WG Last Call. > > --Tom > > From owner-mpls@UU.NET Wed Mar 15 13:16:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18076 for ; Wed, 15 Mar 2000 13:16:05 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqr08996; Wed, 15 Mar 2000 18:16:03 GMT Received: by mail-control.mail.uu.net id QQigqr04311 for mpls-outgoing; Wed, 15 Mar 2000 18:15:30 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigqr04295 for ; Wed, 15 Mar 2000 18:15:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqq16230 for ; Wed, 15 Mar 2000 13:14:10 -0500 (EST) Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQigqq07698 for ; Wed, 15 Mar 2000 18:14:09 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 10:14:06 -0800 Message-ID: From: Vijay Srinivasan To: "'Dirk Ooms'" Cc: "'mpls@uu.net'" Subject: RE: ascii archive Date: Wed, 15 Mar 2000 10:13:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8EAA.3FCA46CE" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8EAA.3FCA46CE Content-Type: text/plain; charset="iso-8859-1" Hi Dirk, The archive is maintained at: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html - Vijay -----Original Message----- From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] Sent: Wednesday, March 15, 2000 3:31 AM To: mpls@UU.NET Subject: ascii archive I am looking for an up-to-date ascii archive of the mailing list. Anyone any idea (the cisco archive is not available anymore)? thanks, dirk -- Dirk Ooms Alcatel Research mailto:Dirk.Ooms@alcatel.be Francis Wellesplein 1 Phone: +32 3 240 4732 B-2018 Antwerp Fax: +32 3 240 9932 Belgium ------_=_NextPart_001_01BF8EAA.3FCA46CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ascii archive

Hi Dirk,

The archive is maintained at:

http://cell.onecall.net/cell-relay/archives/mpls/mpls.= index.html

- Vijay

-----Original Message-----
From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be]
Sent: Wednesday, March 15, 2000 3:31 AM
To: mpls@UU.NET
Subject: ascii archive


I am looking for an up-to-date ascii archive of the = mailing list.
Anyone any idea (the cisco archive is not available = anymore)?

thanks,
dirk

--
Dirk = Ooms           &n= bsp;           &n= bsp;         Alcatel = Research
mailto:Dirk.Ooms@alcatel.be&nbs= p;         Francis Wellesplein = 1
Phone: +32 3 240 = 4732           &n= bsp;           B-2018 = Antwerp
Fax:   +32 3 240 = 9932           &n= bsp;           &n= bsp;      Belgium

------_=_NextPart_001_01BF8EAA.3FCA46CE-- From owner-mpls@UU.NET Wed Mar 15 13:19:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19434 for ; Wed, 15 Mar 2000 13:19:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqr10913; Wed, 15 Mar 2000 18:19:02 GMT Received: by mail-control.mail.uu.net id QQigqr04496 for mpls-outgoing; Wed, 15 Mar 2000 18:18:34 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigqr04490 for ; Wed, 15 Mar 2000 18:18:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqr16731 for ; Wed, 15 Mar 2000 13:18:22 -0500 (EST) Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63]) id QQigqr10436 for ; Wed, 15 Mar 2000 18:18:22 GMT Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Wed, 15 Mar 2000 10:17:42 -0800 Message-ID: <337055FBC675D311A85D00508B5A9C4F254211@u-mail.rd.francetelecom.com> From: CATANZARITI Sergio FTR&D/TI To: "'Chip Sharp'" Cc: "'mpls@UU.NET'" , "'ip-optical@lists.research.bell-labs.com'" Subject: RE: Optical IP activities Date: Wed, 15 Mar 2000 10:17:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8EAA.C0526CB8" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8EAA.C0526CB8 Content-Type: text/plain; charset="iso-8859-1" I was aware of that. Indeed, that makes me more confused and worried. The ITU-T (SG15?) seems to have concerns on working on a peer model for an IP over Optics networking architecture, leaning towards an overlay scenario. In other words, there are some concerns about making the OCh layer topology information revealed to the IP service client layer. On the contrary, the IETF seems to go in the other direction (although a recent IETF draft, I believe from Nortel and Lucent, endorses the same ITU-T concerns). From the MPLS revised charter: 4. Simplify integration of routers with optical cross-connect based technologies a) making optical cross connects behave as peers to routers (thus reducing the number of routing peers that a router has to maintain), b) by making information about physical topology available to Network Layer routing procedures, and c) by employing common addressing, routing, and management procedures. I guess that it is too early to debate model issues, in order to avoid IP over ATM model debate-like activities. Personally, I would first work on Optical IP networking architecture and control plane requirements definition, then choosing the right protocol machinery (MPLS, X/Y/Z protocol), and ultimately facing the multi-dimension model problem (topology complexity, service layer configuration, OA&M procedures, PMO status quo, commercial considerations, etc.) Sergio > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@cisco.com] > Sent: Wednesday, March 15, 2000 9:45 AM > To: CATANZARITI Sergio FTR&D/TI; > 'ip-optical@lists.research.bell-labs.com' > Cc: 'mpls@UU.NET' > Subject: Re: Optical IP activities > > FYI, > It looks like the ITU (SG 13, SG15 and possibly SG11) may be getting into > this area as well. At the SG13 meeting in Kyoto, there was some > discussion > of this topic. They are definitely working on next-gen optical networking > > issues. > > Chip > > At 05:23 PM 3/14/00 -0800, CATANZARITI Sergio FTR&D/TI wrote: > > >Today I was reading the MPLS revised charter sent by Vijay and I have > >found optical IP related activities, like that: > > > >6. Specify extensions to the protocols and procedures used for > >signaling explicit routes and to effect fast recovery of LSPs > >for use in Optical Cross Connects. > > > >Now, reading from the IP over Optical BoF description, I find: > > > >- Modifying existing IP and MPLS routing and connection signaling > > protocols > > > >I know that it is still pretty much immature to talk about results of the > > >upcoming IP over Optical BoF, but how will an eventual WG coming out from > > >this BoF reconcile with the MPLS WG activity in the Optical IP arena? > > > >By working on a generic control plane architecture and requirements > >definition, and leaving out to the MPLS WG specific work on the generic > >mechanisms and procedure for an MPLS implementation of an Optical IP > >control plane? Is this a possible intra-IETF activity scenario? Which > others? > > > >Looking for a brief and rough hint. > > > >Thanks, > >Sergio > >-------------------------------------------------------------------- > >Sergio Catanzariti Senior Project Manager, Technology Integration > France > >Telecom R&D 1000 Marina Boulevard Suite 300 Brisbane CA 94005 Tel. > >650-875-1526 Fax. > >650-875-1505 email:sergio.catanzariti@rd.francetelecom.com > >-------------------------------------------------------------------- > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > ------_=_NextPart_001_01BF8EAA.C0526CB8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical IP activities

I was aware of that. Indeed, that = makes me more confused and worried.
The ITU-T (SG15?) seems to have = concerns on working on a peer model for an IP over Optics networking = architecture, leaning towards an overlay scenario. In other words, = there are some concerns about making the OCh layer topology information = revealed to the IP service client layer.

On the contrary, the IETF seems to go = in the other direction (although a recent IETF draft, I believe from = Nortel and Lucent, endorses the same ITU-T concerns).

From the MPLS revised = charter:

4.  Simplify integration = of routers with optical cross-connect based
technologies

a) making optical cross = connects behave as peers to routers (thus
reducing the number of = routing peers that a router has to maintain),

b) by making information = about physical topology available to
Network Layer routing = procedures, and

c) by employing common = addressing, routing, and management
procedures.

I guess that it is too early to debate = model issues, in order to avoid IP over ATM model debate-like = activities.
Personally, I would first work on = Optical IP networking architecture and control plane requirements = definition, then choosing the right protocol machinery (MPLS, X/Y/Z = protocol), and ultimately facing the multi-dimension model problem = (topology complexity, service layer configuration, OA&M procedures, = PMO status quo, commercial considerations, etc.)

Sergio

    ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior Project = Manager, Technology Integration
    France Telecom = R&D
    1000 Marina = Boulevard Suite 300
    Brisbane CA = 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com =
    ---------------------------------------------------------= -----------


    -----Original Message-----
    From:   Chip Sharp [SMTP:chsharp@cisco.com]
    Sent:   Wednesday, March 15, 2000 9:45 AM
    To:     CATANZARITI Sergio FTR&D/TI; = 'ip-optical@lists.research.bell-labs.com'
    Cc:     'mpls@UU.NET'
    Subject:       = Re: Optical IP activities

    FYI,
    It looks like the ITU (SG 13, = SG15 and possibly SG11) may be getting into
    this area as well.  At the = SG13 meeting in Kyoto, there was some discussion
    of this topic.  They are = definitely working on next-gen optical networking
    issues.

    Chip

    At 05:23 PM 3/14/00 -0800, = CATANZARITI Sergio FTR&D/TI wrote:

    >Today I was reading the MPLS = revised charter sent by Vijay and I have
    >found optical IP related = activities, like that:
    >
    >6.  Specify extensions = to the protocols and procedures used for
    >signaling explicit routes = and to effect fast recovery of LSPs
    >for use in Optical Cross = Connects.
    >
    >Now, reading from the IP = over Optical BoF description, I find:
    >
    >- Modifying existing IP and = MPLS routing and connection signaling
    >   = protocols
    >
    >I know that it is still = pretty much immature to talk about results of the
    >upcoming IP over Optical = BoF, but how will an eventual WG coming out from
    >this BoF reconcile with the = MPLS WG activity in the Optical IP arena?
    >
    >By working on a generic = control plane architecture and requirements
    >definition, and leaving out = to the MPLS WG specific work on the generic
    >mechanisms and procedure = for an MPLS implementation of an Optical IP
    >control plane? Is this a = possible intra-IETF activity scenario? Which others?
    >
    >Looking for a brief and = rough hint.
    >
    >Thanks,
    >Sergio
    >---------------------------------------------------------------= -----
    >Sergio Catanzariti  = Senior Project Manager, Technology Integration  France
    >Telecom R&D  1000 = Marina Boulevard Suite 300  Brisbane CA 94005  Tel.
    >650-875-1526  Fax. =
    >650-875-1505  = email:sergio.catanzariti@rd.francetelecom.com
    >---------------------------------------------------------------= -----

    Support NetAid!  = http://www.netaid.org
    --------------------------------------------------
    Chip = Sharp           &= nbsp;     Consulting Engineering
    Cisco = Systems           = ;   Telco Bio-region
    Reality - Love it or Leave = it.          =        
    --------------------------------------------------

------_=_NextPart_001_01BF8EAA.C0526CB8-- From owner-mpls@UU.NET Wed Mar 15 13:30:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23729 for ; Wed, 15 Mar 2000 13:30:12 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqs19828; Wed, 15 Mar 2000 18:30:11 GMT Received: by mail-control.mail.uu.net id QQigqr05366 for mpls-outgoing; Wed, 15 Mar 2000 18:29:33 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigqr05358 for ; Wed, 15 Mar 2000 18:29:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqr18104 for ; Wed, 15 Mar 2000 13:29:12 -0500 (EST) Received: from lumen.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: magic03.kudonet.com [209.133.127.227]) id QQigqr18718 for ; Wed, 15 Mar 2000 18:29:11 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id ; Wed, 15 Mar 2000 10:31:37 -0800 Message-ID: From: John Drake To: "'mpls@uu.net'" Subject: FW: I-D ACTION:draft-lang-mpls-lmp-00.txt Date: Wed, 15 Mar 2000 10:31:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF8EAC.B2008B84" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF8EAC.B2008B84 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, March 15, 2000 3:24 AM Subject: I-D ACTION:draft-lang-mpls-lmp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Link Management Protocol (LMP) Author(s) : J. Lang, K. Mitra, Y. Rekhter, J. Drake et.al Filename : draft-lang-mpls-lmp-00.txt Pages : 11 Date : 14-Mar-00 Future optical networks will consist of optical crossconnects (OXCs) that may be configured with links consisting of a number of user bearer channels and an associated control channel. This document specifies a link management protocol (LMP) that runs between neighboring OXCs and will be used for both link provisioning and fault isolation. A unique feature of LMP is that it is able to isolate faults in both opaque and transparent networks, independent of the encoding scheme used for the bearer channels. LMP will be used to maintain control channel connectivity, verify bearer channel connectivity, and isolate link, fiber, or channel failures within the optical network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lang-mpls-lmp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lang-mpls-lmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lang-mpls-lmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01BF8EAC.B2008B84 Content-Type: message/rfc822 To: Subject: Date: Wed, 15 Mar 2000 10:31:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BF8EAC.B2008B84" ------_=_NextPart_002_01BF8EAC.B2008B84 Content-Type: text/plain ------_=_NextPart_002_01BF8EAC.B2008B84 Content-Type: application/octet-stream; name="ATT01932.txt" Content-Disposition: attachment; filename="ATT01932.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000314132723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lang-mpls-lmp-00.txt ------_=_NextPart_002_01BF8EAC.B2008B84 Content-Type: message/external-body; site="internet-drafts"; dir="draft-lang-mpls-lmp-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BF8EAC.B2008B84-- ------_=_NextPart_000_01BF8EAC.B2008B84-- From owner-mpls@UU.NET Wed Mar 15 13:32:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24733 for ; Wed, 15 Mar 2000 13:32:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqs22546; Wed, 15 Mar 2000 18:32:49 GMT Received: by mail-control.mail.uu.net id QQigqs05712 for mpls-outgoing; Wed, 15 Mar 2000 18:32:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigqs05696 for ; Wed, 15 Mar 2000 18:32:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqs20243; Wed, 15 Mar 2000 13:31:41 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQigqs21349; Wed, 15 Mar 2000 18:31:41 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id NAA10006; Wed, 15 Mar 2000 13:31:25 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id NAA36180; Wed, 15 Mar 2000 13:31:40 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003151831.NAA36180@curtis-lt.avici.com> To: "Loa Andersson" cc: Hummel Heinrich , mpls@UU.NET, te-wg@UU.NET Reply-To: curtis@avici.com Subject: Re: Internet Draft Submission: Orchestrally Conducted Traffic In-reply-to: Your message of "Wed, 15 Mar 2000 15:53:12 +0100." <38CFA3D8.F8059CAC@nortelnetworks.com> Date: Wed, 15 Mar 2000 13:31:39 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <38CFA3D8.F8059CAC@nortelnetworks.com>, "Loa Andersson" writes: > Heinrich, > > there is something that worries me very much about this. From the > abstract: > > "This draft proposes to engineer traffic such that we can speak of an > Orchestrally Conducted Traffic (OCT): Any traffic stream (given by > its source and destination nodes and by a priority class) may use > several differently routed LSPs. Each, traffic stream ingress > reports, periodically, the currently measured traffic load (in > bitrate) to a common TE Conductor (TEC) who evaluates them as to > guess what traffic load change might occur in the immediate time > ahead. Accordingly the TEC computes well synchronized likelihood > values by which to take which route/LSP. These values will be such > that any traffic stream will be served as good as possible, as often > as possible, while equally ranked traffic streams are treated fair, > higher ranked streams are prioritized and the network thruput is > maximized. The TEC sends the likelihood values to the respective > ingress node, who will distribute the received packets of the > traffic stream to the pertaining LSPs accordingly." > > I might misread this, but the IP paradigm has been connection less from > the start, and very much of the success of IP is because of its of this > connection less nature. I do see that we "violate" this little bit by > some of the proposals that has been discussed in the mpls and te > working groups - for what I believe is good reasons. However we should > take extreme care of keeping the connection less nature of IP > networks. > > The Orchestrated Conducted Traffic draft seems to take an extreme > connection oriented approach. We should take care not throw the > baby, bath tub and bath water out at the same time. > > /Loa I believe there was no comment because there was no interest. Generally people say nothing rather than expressing no interest but since Hummel has asked what happenned I'll acknowledge having read the draft and when it was sent to the mailing list and having reread it just now and having no interest in pursuing it. I must also admit that the intellectual property section is quite ominous for a draft with so little intellectual content. IMHO the WGs should not even consider a draft which appears to be so encumberred. The idea of basing traffic engineering on load is certainly not a new idea. The idea of collecting loading inforamtion at a central location for the purpose of offline analysis and traffic engineering is not a new idea. The idea of pushing date out to a centralized collection site rather than pulling the data is not new. I must admit that I don't see what new idea could possibly be considered for intellectual property protection. If there is a specific combination of these ideas that Seimens is trying to patent, then the IETF should avoid producing any standard utilizing that specific combination based on the combination being encumberred. Curtis From owner-mpls@UU.NET Wed Mar 15 13:36:57 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26380 for ; Wed, 15 Mar 2000 13:36:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqs22122; Wed, 15 Mar 2000 18:36:54 GMT Received: by mail-control.mail.uu.net id QQigqs06004 for mpls-outgoing; Wed, 15 Mar 2000 18:36:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigqs05999 for ; Wed, 15 Mar 2000 18:36:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqs20725 for ; Wed, 15 Mar 2000 13:34:57 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigqs20709 for ; Wed, 15 Mar 2000 18:34:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA14398 for mpls@uu.net; Wed, 15 Mar 2000 13:34:55 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigqs05835 for ; Wed, 15 Mar 2000 18:34:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqs18918 for ; Wed, 15 Mar 2000 13:34:16 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQigqs20258 for ; Wed, 15 Mar 2000 18:34:10 GMT Received: from tnadeau-pc02 (ch2-dhcp134-171.cisco.com [161.44.134.171]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA03761; Wed, 15 Mar 2000 13:33:31 -0500 (EST) Message-Id: <4.2.2.20000315132456.00df1de0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 13:25:16 -0500 To: "Tim Mancour" , , , "Vijay Srinivasan" From: "Thomas D. Nadeau" Subject: RE: LSR MIB WG Last Call Cc: "Cheenu Srinivasan" , In-Reply-To: References: <4.2.2.20000314174805.00d13f00@funnel.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11216172==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_11216172==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Tim, Thanks for your comments. We will look into them and get back to you. --Tom >I think it is a little premature for a last call on this MIB. >I only had a chance to print-out the -02 version yesterday >and have the following comments: > > 1. There is no mention in the MIB regarding the > LSP type/style (e.g. E-LSP or L-LSP). Perhaps > an object should be added to the cross-connect table? > > 2. I'm confused about the COS object in the XC table. > Section 4 references the COS information in the [LblStk] > I-D but there is no mention of COS in this I-D. From the > mplsXCCOS description, I assume that this value should be > used to overwrite the EXP bits. If this is true then there > needs to be a way to disable overwriting the EXP bits. > > 3. Why is the syntax of all of the get next index objects > (e.g. mplsXCIndexNext) read-only? Shouldn't the TestAndIncr > textual convention be followed? > > 4. There are a number of typos regarding indexes. For example, > mplsInSegmentXCIndex has a syntax of "Integer32 (1..2147483647)" > but the description states that 0 is a valid value. It may be > advisable to create textual conventions to avoid these problems; > something like MplsIndex and MplsIndexOrZero. > > 5. There are also problems with bandwidth units and descriptions. > As I understand it, all bandwidths should be in kilobits per > second. In some places, the UNIT is "bits per second". In other > places the description contains "kilobits per second (Kbps/sec)" > which should be either "kilobits per second (Kbps)" or "kilobits > per second (Kb/sec)". > > 6. Section 6.2 mentions a mplsInterfaceResTable but no table > exists. > > 7. The syntax for the mplsInSegmentNPop is Integer32(1..2147483647). > It should be Integer32(0..2147483647) or even INTEGER(0..255); > since popping 255 labels is still a very large range. > >Best regards. >TimM > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas D. >Nadeau >Sent: Tuesday, March 14, 2000 5:49 PM >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan >Cc: Cheenu Srinivasan; arun@force10networks.com >Subject: LSR MIB WG Last Call > > > > Since we have not received any additional comments >on the current version of the LSR MIB, we would like >to raise the document to WG Last Call. > > --Tom > > > --=====================_11216172==_.ALT Content-Type: text/html; charset="us-ascii"         
        Hi Tim,

        Thanks for your comments. We will look into them
and get back to you.

        --Tom


I think it is a little premature for a last call on this MIB.
I only had a chance to print-out the -02 version yesterday
and have the following comments:

        1. There is no mention in the MIB regarding the
        LSP type/style (e.g. E-LSP or L-LSP). Perhaps
      an object should be added to the cross-connect table?

        2. I'm confused about the COS object in the XC table.
        Section 4 references the COS information in the [LblStk]
        I-D but there is no mention of COS in this I-D. From the
        mplsXCCOS description, I assume that this value should be
        used to overwrite the EXP bits. If this is true then there
        needs to be a way to disable overwriting the EXP bits.

        3. Why is the syntax of all of the get next index objects
        (e.g. mplsXCIndexNext) read-only? Shouldn't the TestAndIncr
        textual convention be followed?

        4. There are a number of typos regarding indexes. For example,
        mplsInSegmentXCIndex has a syntax of "Integer32 (1..2147483647)"
        but the description states that 0 is a valid value. It may be
        advisable to create textual conventions to avoid these problems;
        something like MplsIndex and MplsIndexOrZero.

        5. There are also problems with bandwidth units and descriptions.
        As I understand it, all bandwidths should be in kilobits per
        second. In some places, the UNIT is "bits per second". In other
        places the description contains "kilobits per second (Kbps/sec)"
        which should be either "kilobits per second (Kbps)" or "kilobits
        per second (Kb/sec)".

        6. Section 6.2 mentions a mplsInterfaceResTable but no table
        exists.

        7. The syntax for the mplsInSegmentNPop is Integer32(1..2147483647).
        It should be Integer32(0..2147483647) or even INTEGER(0..255);
        since popping 255 labels is still a very large range.

Best regards.
TimM
        
-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas D.
Nadeau
Sent: Tuesday, March 14, 2000 5:49 PM
To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan
Cc: Cheenu Srinivasan; arun@force10networks.com
Subject: LSR MIB WG Last Call



        Since we have not received any additional comments
on the current version of the LSR MIB, we would like
to raise the document to WG Last Call.

        --Tom



--=====================_11216172==_.ALT-- From owner-mpls@UU.NET Wed Mar 15 13:42:10 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28745 for ; Wed, 15 Mar 2000 13:42:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqs29490; Wed, 15 Mar 2000 18:42:09 GMT Received: by mail-control.mail.uu.net id QQigqs06444 for mpls-outgoing; Wed, 15 Mar 2000 18:41:30 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigqs06439 for ; Wed, 15 Mar 2000 18:41:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqs19669 for ; Wed, 15 Mar 2000 13:41:23 -0500 (EST) Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63]) id QQigqs26177 for ; Wed, 15 Mar 2000 18:41:22 GMT Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Wed, 15 Mar 2000 10:40:42 -0800 Message-ID: <337055FBC675D311A85D00508B5A9C4F254212@u-mail.rd.francetelecom.com> From: CATANZARITI Sergio FTR&D/TI To: "'Gawlak, Charlie'" , "'Chip Sharp'" Cc: "'mpls@UU.NET'" , "'ip-optical@lists.research.bell-labs.com'" Subject: RE: Optical IP activities Date: Wed, 15 Mar 2000 10:40:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8EAD.F7253D44" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8EAD.F7253D44 Content-Type: text/plain; charset="iso-8859-1" I do not understand your question. Sergio > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Gawlak, Charlie [SMTP:CGawlak@soundview.com] > Sent: Wednesday, March 15, 2000 10:35 AM > To: 'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp' > Cc: 'mpls@UU.NET'; 'ip-optical@lists.research.bell-labs.com' > Subject: RE: Optical IP activities > > Hey guys, > > Am I supposed to be getting these emails? > > Charlie Gawlak > Wit SoundView > > -----Original Message----- > From: CATANZARITI Sergio FTR&D/TI > [mailto:sergio.catanzariti@rd.francetelecom.com] > Sent: Wednesday, March 15, 2000 1:18 PM > To: 'Chip Sharp' > Cc: 'mpls@UU.NET'; 'ip-optical@lists.research.bell-labs.com' > Subject: RE: Optical IP activities > > > > I was aware of that. Indeed, that makes me more confused and worried. > The ITU-T (SG15?) seems to have concerns on working on a peer model for an > IP over Optics networking architecture, leaning towards an overlay > scenario. > In other words, there are some concerns about making the OCh layer > topology > information revealed to the IP service client layer. > > On the contrary, the IETF seems to go in the other direction (although a > recent IETF draft, I believe from Nortel and Lucent, endorses the same > ITU-T > concerns). > > From the MPLS revised charter: > > 4. Simplify integration of routers with optical cross-connect based > technologies > > a) making optical cross connects behave as peers to routers (thus > reducing the number of routing peers that a router has to maintain), > > b) by making information about physical topology available to > Network Layer routing procedures, and > > c) by employing common addressing, routing, and management > procedures. > > I guess that it is too early to debate model issues, in order to avoid IP > over ATM model debate-like activities. > Personally, I would first work on Optical IP networking architecture and > control plane requirements definition, then choosing the right protocol > machinery (MPLS, X/Y/Z protocol), and ultimately facing the > multi-dimension > model problem (topology complexity, service layer configuration, OA&M > procedures, PMO status quo, commercial considerations, etc.) > > Sergio > > -------------------------------------------------------------------- > > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@cisco.com] > Sent: Wednesday, March 15, 2000 9:45 AM > To: CATANZARITI Sergio FTR&D/TI; > 'ip-optical@lists.research.bell-labs.com' > Cc: 'mpls@UU.NET' > Subject: Re: Optical IP activities > > FYI, > It looks like the ITU (SG 13, SG15 and possibly SG11) may be getting into > this area as well. At the SG13 meeting in Kyoto, there was some > discussion > of this topic. They are definitely working on next-gen optical networking > > issues. > > Chip > > At 05:23 PM 3/14/00 -0800, CATANZARITI Sergio FTR&D/TI wrote: > > >Today I was reading the MPLS revised charter sent by Vijay and I > have > >found optical IP related activities, like that: > > > >6. Specify extensions to the protocols and procedures used for > >signaling explicit routes and to effect fast recovery of LSPs > >for use in Optical Cross Connects. > > > >Now, reading from the IP over Optical BoF description, I find: > > > >- Modifying existing IP and MPLS routing and connection signaling > > protocols > > > >I know that it is still pretty much immature to talk about results of the > > >upcoming IP over Optical BoF, but how will an eventual WG coming out from > > >this BoF reconcile with the MPLS WG activity in the Optical IP arena? > > > >By working on a generic control plane architecture and requirements > >definition, and leaving out to the MPLS WG specific work on the generic > >mechanisms and procedure for an MPLS implementation of an Optical IP > >control plane? Is this a possible intra-IETF activity scenario? Which > others? > > > >Looking for a brief and rough hint. > > > >Thanks, > >Sergio > >-------------------------------------------------------------------- > >Sergio Catanzariti Senior Project Manager, Technology Integration > France > >Telecom R&D 1000 Marina Boulevard Suite 300 Brisbane CA 94005 Tel. > >650-875-1526 Fax. > >650-875-1505 email:sergio.catanzariti@rd.francetelecom.com > >-------------------------------------------------------------------- > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > ------_=_NextPart_001_01BF8EAD.F7253D44 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical IP activities

I do not understand your = question.

Sergio

    ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior Project = Manager, Technology Integration
    France Telecom = R&D
    1000 Marina = Boulevard Suite 300
    Brisbane CA = 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com =
    ---------------------------------------------------------= -----------


    -----Original Message-----
    From:   Gawlak, Charlie = [SMTP:CGawlak@soundview.com]
    Sent:   Wednesday, March 15, 2000 10:35 AM
    To:     'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp'
    Cc:     'mpls@UU.NET'; = 'ip-optical@lists.research.bell-labs.com'
    Subject:       = RE: Optical IP activities

    Hey guys,
     
    Am I supposed to be getting = these emails?
     
    Charlie Gawlak
    Wit SoundView

    -----Original = Message-----
    From: CATANZARITI Sergio = FTR&D/TI
    [mailto:sergio.ca= tanzariti@rd.francetelecom.com]
    Sent: Wednesday, March 15, 2000 = 1:18 PM
    To: 'Chip Sharp'
    Cc: 'mpls@UU.NET'; = 'ip-optical@lists.research.bell-labs.com'
    Subject: RE: Optical IP = activities



    I was aware of that. Indeed, = that makes me more confused and worried.
    The ITU-T (SG15?) seems to have = concerns on working on a peer model for an
    IP over Optics networking = architecture, leaning towards an overlay scenario.
    In other words, there are some = concerns about making the OCh layer topology
    information revealed to the IP = service client layer.

    On the contrary, the IETF seems = to go in the other direction (although a
    recent IETF draft, I believe = from Nortel and Lucent, endorses the same ITU-T
    concerns).

    From the MPLS revised charter: =

    4.  Simplify integration of = routers with optical cross-connect based
    technologies

    a) making optical cross connects = behave as peers to routers (thus
    reducing the number of routing = peers that a router has to maintain),

    b) by making information about = physical topology available to
    Network Layer routing = procedures, and

    c) by employing common = addressing, routing, and management
    procedures.

    I guess that it is too early to = debate model issues, in order to avoid IP
    over ATM model debate-like = activities.
    Personally, I would first work = on Optical IP networking architecture and
    control plane requirements = definition, then choosing the right protocol
    machinery (MPLS, X/Y/Z = protocol), and ultimately facing the multi-dimension
    model problem (topology = complexity, service layer configuration, OA&M
    procedures, PMO status quo, = commercial considerations, etc.)

    Sergio

            -------------------------------------------------------------------= -

    Sergio Catanzariti
    Senior Project Manager, = Technology Integration
    France Telecom R&D
    1000 Marina Boulevard Suite 300 =
    Brisbane CA 94005
    Tel. 650-875-1526
    Fax. 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com
    -------------------------------------------------------------------= -


            -----Original Message-----
    From:   Chip Sharp = [SMTP:chsharp@cisco.com]
    Sent:   Wednesday, = March 15, 2000 9:45 AM
    To:     = CATANZARITI Sergio FTR&D/TI;
    'ip-optical@lists.research.bell-labs.com'
    Cc:     = 'mpls@UU.NET'
    Subject:        Re: Optical IP = activities

            FYI,
    It looks like the ITU (SG 13, = SG15 and possibly SG11) may be getting into
    this area as well.  At the = SG13 meeting in Kyoto, there was some discussion
    of this topic.  They are = definitely working on next-gen optical networking
    issues.

            Chip

            At 05:23 PM 3/14/00 -0800, CATANZARITI Sergio = FTR&D/TI wrote:

            >Today I was reading the MPLS revised charter = sent by Vijay and I
    have
    >found optical IP related = activities, like that:
    >
    >6.  Specify extensions = to the protocols and procedures used for
    >signaling explicit routes = and to effect fast recovery of LSPs
    >for use in Optical Cross = Connects.
    >
    >Now, reading from the IP = over Optical BoF description, I find:
    >
    >- Modifying existing IP and = MPLS routing and connection signaling
    >   protocols =
    >
    >I know that it is still = pretty much immature to talk about results of the
    >upcoming IP over Optical = BoF, but how will an eventual WG coming out from
    >this BoF reconcile with the = MPLS WG activity in the Optical IP arena?
    >
    >By working on a generic = control plane architecture and requirements
    >definition, and leaving out = to the MPLS WG specific work on the generic
    >mechanisms and procedure = for an MPLS implementation of an Optical IP
    >control plane? Is this a = possible intra-IETF activity scenario? Which
    others?
    >
    >Looking for a brief and = rough hint.
    >
    >Thanks,
    >Sergio
    >---------------------------------------------------------------= -----
    >Sergio Catanzariti  = Senior Project Manager, Technology Integration  France
    >Telecom R&D  1000 = Marina Boulevard Suite 300  Brisbane CA 94005  Tel.
    >650-875-1526  Fax. =
    >650-875-1505  = email:sergio.catanzariti@rd.francetelecom.com
    >---------------------------------------------------------------= -----

            Support NetAid!  http://www.netaid.org <http://www.netaid.org> 
    --------------------------------------------------
    Chip = Sharp           &= nbsp;     Consulting Engineering
    Cisco = Systems           = ;   Telco Bio-region
    Reality - Love it or Leave = it.           &nb= sp;     
    --------------------------------------------------

------_=_NextPart_001_01BF8EAD.F7253D44-- From owner-mpls@UU.NET Wed Mar 15 13:45:08 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00081 for ; Wed, 15 Mar 2000 13:45:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqt29572; Wed, 15 Mar 2000 18:45:08 GMT Received: by mail-control.mail.uu.net id QQigqs06561 for mpls-outgoing; Wed, 15 Mar 2000 18:44:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigqs06552 for ; Wed, 15 Mar 2000 18:44:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqs22077 for ; Wed, 15 Mar 2000 13:43:14 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigqs27774 for ; Wed, 15 Mar 2000 18:43:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA16134 for mpls@uu.net; Wed, 15 Mar 2000 13:43:08 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigqs06456 for ; Wed, 15 Mar 2000 18:41:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqs19679 for ; Wed, 15 Mar 2000 13:41:29 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQigqs26251 for ; Wed, 15 Mar 2000 18:41:28 GMT Received: from tnadeau-pc02 (ch2-dhcp134-171.cisco.com [161.44.134.171]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04631; Wed, 15 Mar 2000 13:41:17 -0500 (EST) Message-Id: <4.2.2.20000315132533.00df9740@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 13:33:02 -0500 To: Hans =?iso-8859-1?Q?Sj=F6strand?= From: "Thomas D. Nadeau" Subject: Re: LSR MIB WG Last Call Cc: mpls@UU.NET, "Cheenu Srinivasan" , In-Reply-To: <38CFCA71.DC20295E@etx.ericsson.se> References: <4.2.2.20000315080814.00dedd00@funnel.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11682538==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_11682538==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Hans, >I would like to know why you have "issued a last call? I did not issue a last call, as I cannot, nor was it my intention to do so. The intent of my first message to George and Vijay was to ask for a WG Last Call on the MIB. My second message was referring to this request, not declare a last call. I apologize for the confusion. >It almost ridiculous to say >something like that when it doesn't even compile! We compiled the current version with SMIC prior to releasing it. What are you compiling it with? Please provide me with your compilation errors so that I can look into this ASAP. >The only thing you create is confusion, hopefully that >isn't the goal of the exercise. But what was your purpuse? Of course not. My purpose was to ask for a last call and nothing else. --Tom >/// Hasse > >"Thomas D. Nadeau" wrote: > > > > > > Please do give comments if there are any. > > The WG Last Call should not preclude that. The > > reason why we decided to go WGLC at this point > > was that even during the last round of reviewed > > comments (most were from you in fact), the comments > > were relatively minor. We feel that the MIB is pretty > > solid and mature at this point. > > > > --Tom > > > > > Your latest version is dated 6th March. > > > It is now 14th. > > > > > > I think it reasonable to give us all a little time to read your work > > > after > > > all of the effort you have put into it. > > > > > > Adrian > > > -- > > > Adrian Farrel mailto:af@datcon.co.uk > > > ATM, MPLS and Telecoms Development Group > > > Data Connection Ltd., Chester, UK > > > http://www.datcon.co.uk/ > > > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > > > > > > > >-----Original Message----- > > > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > >Sent: Tuesday, March 14, 2000 10:49 PM > > > >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan > > > >Cc: Cheenu Srinivasan; arun@force10networks.com > > > >Subject: LSR MIB WG Last Call > > > > > > > > > > > > > > > > Since we have not received any additional comments > > > >on the current version of the LSR MIB, we would like > > > >to raise the document to WG Last Call. > > > > > > > > --Tom > > > > > > > > > > > --=====================_11682538==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi Hans,

I would like to know why you have "issued a last call?

        I did not issue a last call, as I cannot, nor
was it my intention to do so. The intent of my first
message to George and Vijay was to ask for a WG Last Call
on the MIB. My second message was referring to this
request, not declare a last call. I apologize for the
confusion.

It almost ridiculous to say
something like that when it doesn't even compile!

        We compiled the current version with SMIC prior
to releasing it. What are you compiling it with?
Please provide me with your compilation errors
so that I can look into this ASAP.

The only thing you create is confusion, hopefully that
isn't the goal of the exercise. But what was your purpuse?

        Of course not. My purpose was to ask for a last call
and nothing else.

        --Tom




/// Hasse

"Thomas D. Nadeau" wrote:
>
>
>         Please do give comments if there are any.
> The WG Last Call should not preclude that. The
> reason why we decided to go WGLC at this point
> was that even during the last round of reviewed
> comments (most were from you in fact), the comments
> were relatively minor. We feel that the MIB is pretty
> solid and mature at this point.
>
>         --Tom
>
> > Your latest version is dated 6th March.
> > It is now 14th.
> >
> > I think it reasonable to give us all a little time to read your work
> > after
> > all of the effort you have put into it.
> >
> > Adrian
> > --
> > Adrian Farrel  mailto:af@datcon.co.uk
> > ATM, MPLS and Telecoms Development Group
> > Data Connection Ltd., Chester, UK
> > http://www.datcon.co.uk/
> > Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
> >
> >
> > >-----Original Message-----
> > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > >Sent: Tuesday, March 14, 2000 10:49 PM
> > >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan
> > >Cc: Cheenu Srinivasan; arun@force10networks.com
> > >Subject: LSR MIB WG Last Call
> > >
> > >
> > >
> > >       Since we have not received any additional comments
> > >on the current version of the LSR MIB, we would like
> > >to raise the document to WG Last Call.
> > >
> > >       --Tom
> > >
> > >
> >
--=====================_11682538==_.ALT-- From owner-mpls@UU.NET Wed Mar 15 14:05:02 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08882 for ; Wed, 15 Mar 2000 14:05:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqu13354; Wed, 15 Mar 2000 19:05:00 GMT Received: by mail-control.mail.uu.net id QQigqu12755 for mpls-outgoing; Wed, 15 Mar 2000 19:04:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigqu12599 for ; Wed, 15 Mar 2000 19:04:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqu24924 for ; Wed, 15 Mar 2000 14:03:35 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigqu15659 for ; Wed, 15 Mar 2000 19:03:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA20163 for mpls@uu.net; Wed, 15 Mar 2000 14:03:34 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigqu11935 for ; Wed, 15 Mar 2000 19:03:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqu24605 for ; Wed, 15 Mar 2000 14:01:13 -0500 (EST) Received: from 21cn.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [202.104.32.241]) id QQigqu10609 for ; Wed, 15 Mar 2000 19:00:24 GMT Received: from 21cn.com([10.1.0.105]) by 21cn.com(JetMail 2.3.2.5) with SMTP id /aimcque/jmail.rcv/5/jm438d02916; Wed, 15 Mar 2000 19:00:05 -0000 Received: from wodc7-1.corprelay.mail.uu.net([192.48.96.68]) by 21cn.com(JetMail 2.3.2.5) with SMTP id /aimcque/jmail.rcv/7/jm2c38cd70e0; Mon, 13 Mar 2000 18:57:12 -0000 Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigjj15165; Mon, 13 Mar 2000 18:56:43 GMT Received: by mail-control.mail.uu.net id QQigjj08912 for mpls-outgoing; Mon, 13 Mar 2000 18:56:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigjj08882 for ; Mon, 13 Mar 2000 18:56:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigjj22761 for ; Mon, 13 Mar 2000 13:55:55 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigjj20700 for ; Mon, 13 Mar 2000 18:55:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA17419 for mpls@uu.net; Mon, 13 Mar 2000 13:55:53 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigjj08804 for ; Mon, 13 Mar 2000 18:55:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigjj22639 for ; Mon, 13 Mar 2000 13:54:55 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQigjj19793 for ; Mon, 13 Mar 2000 18:54:45 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA29737; Mon, 13 Mar 2000 13:54:35 -0500 (EST) Message-Id: <4.2.2.20000313134730.00ddd100@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 13 Mar 2000 13:50:31 -0500 To: Joan Cucchiara , "'cheenu@tachion.com'" , "'arun@force10networks.com'" From: "Thomas D. Nadeau" Subject: Re: draft-nadeau-mpls-packet-classifier-mib-00.txt comments Cc: mpls@UU.NET In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F842@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_194064616==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_194064616==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Joan, Thanks for your very thorough comments. We will go over them and get back to you and the MPLS group shortly. Let me first say that many of your comments, although warranted, are the result of an initial design, but you probably know that already. ;) It was our intent to get something reasonable out for WG members to look at and comment on. We will be working hard in the future to adjust the MIB to meet the needs of the MPLS WG. --Tom >Tom, Arun and Cheenu, > >I have some questions and comments and concerns on: >draft-nadeau-mpls-packet-classier-mib-00.txt > >General comments >----------------- >* MIB doesn't compile with any of my mib compilers, can >you tell me which one you are using? >* In general, I find the MIB approach to be top-down >which leads to a gap in the logic between the MIB and what >is actually needed to set on the hardware-side in order to >provide for mpls packet classification. You have barely scratched >the surface for ALL MPLS protocols. (it is not clear >from the document that the intent is to provide a way >to support ALL MPLS protocols, but since this references >the LSR MIB, then I assumed this was the case: is that >a correct assumption?) > >It's as if the design was from picturing a GUI screen which has >something called interface and attaching >a bunch of classifier rules to try on the interface. >But this doesn't quite cut it as a MIB which can be >used to actually do this on hardware, at least not >as it is written now. > >For example, when an ifIndex goes away then all the >configuration that is done is GONE. This is NOT >a good design. It is a configuration nightmare. > >Do you really expect that a System Admin person would be >keeping track of all of this? That is paramount to having >a sys admin keep track of every route through an ISP. >And then CONFIGURE for it by knowing the ifIndex at any >point in time. Which is not possible when setting up >redundant LSPs. It is not realistic that a Sys Admin >would do this, do you agree? > >The way you are treating LSPs is as if they are ALL PVC-like, which >may be true in some, but certainly not ALL instances, it is not a >flexible design, and it is not scalable design. It >is a configuration nightmare. > >Furthermore, the use of a DISPLAY strings as indices is not viable >for timely execution on the agent-side. Modeling a >linked list which contains (Integer, DisplayString, >DisplayString) where the only other thing in the table >is RowStatus is also quite a poor design for the agent-side. > >What about redirection to a different LSP? The MIB >doesn't work unless redirection is to an LSP which >has been set up apriori, but what is this based on? >Where is the logic to determine when to redirect and >where to redirect to? Is the System Admin supposed to >know magically when to do this and where? Isn't this better >handled by allowing software algorithms to do redirect >versus a sys admin? Currently, the MIB only allows this >to be configured. Again, this is neither flexible, nor scalable. > >What about mapping back to Labels? (for easy clean up on in a teardown >scenario) > >What about load balancing? Seems like this is NOT supported in >the MIB. > >My greatest concern is that this MIB is completely useless unless >ifIndex a "static, persistent index". By definition, ifIndex doesn't >have to be persistent, especially not through reboots OR DISCONTINUTY >types of situations. > >How on earth can your MIB be done by an implementation >that does NOT make ifIndex persistent? Is your intention to >re-write how IfIndex is used? > >This MIB is not viable because what you are calling >interfaceIndex is not a true ifIndex, OR maybe the expectation is that >someone >will be continually configuring this MIB. Not a job I would want. > >Since the basis of the MIB is mapping packet classifier rule sets to >ifIndex, is this MIB going to allow for INTEROPERABILITY? Right now >it does not! In fact, I would like to see a new rev with a complete >explanation of HOW this MIB will be INTEROPERABLE before seeing >it as adopted as a working group document. It appears to me at least, >that very little thought was actually given to interoperability. > >If the basis of the packet classifier identifier is a DisplayString, then is >this going to be interoperable? Thus, the way you are identifying packet >classifiers has absolutely no meaning, even from devices by the same vendor. >For example, I could have the SAME exact classifier appear several times >under different names, what good is this? > >Section 4. Motivation > >* I was expecting a simply stated goal for >this MIB, which I couldn't find. Is this MIB >intended to be used for all MPLS protocols? > >If so, could you state it plainly? > >* The statement: "Conceptually, some of the >FTN table functionality could be implemented usig >the Forwarding Information Base(FIB) to map all packets >destined to a prefix to an LSP. However, this mapping is >course in nature." > >What is meant by "course in nature", certainly for LDP >this is fine. Again, if the intent of the MIB was >more clearly stated that would be helpful. > >* The last sentence: "...as well as new ones (i.e. classifier >rules?) such as those required by MPLS and Diff-Serv." may >lead the audience to believe that this somehow works with >diff-serv, I didn't see anything in this MIB which was diff-serv >specific, if so could you point this out? > >Also, Diff-serv MIBs are being developed in about 3 different >groups, is it your intention to work with any of these >other efforts? If so, could you elaborate on what the plans >are? > >I would like to see all of the above issues explained, >particularly, the issue of InterfaceIndex and interoperability. >BEFORE it is adopted as a working group document. > >The entire point of having a standard MIB is for interoperability, and >I do not see how this MIB will provide any sort of interoperability >due to the assumptions regarding InterfaceIndex which have been made >but are NOT at all discussed anywhere in the MIB. > >Thank you, > Joan > > --=====================_194064616==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi Joan,

        Thanks for your very thorough comments. We
will go over them and get back to you and the MPLS
group shortly. Let me first say that many of your
comments, although warranted, are the result of an
initial design, but you probably know that
already. ;) It was our intent to get something reasonable
out for WG members to look at and comment on. We
will be working hard in the future to adjust the MIB
to meet the needs of the MPLS WG.

        --Tom


Tom, Arun and Cheenu,

I have some questions and comments and concerns on:
draft-nadeau-mpls-packet-classier-mib-00.txt

General comments
-----------------
* MIB doesn't compile with any of my mib compilers, can
you tell me which one you are using?
* In general, I find the MIB approach to be top-down
which leads to a gap in the logic between the MIB and what
is actually needed to set on the hardware-side in order to
provide for mpls packet classification.  You have barely scratched
the surface for ALL MPLS protocols.  (it is not clear
from the document that the intent is to provide a way
to support ALL MPLS protocols, but since this references
the LSR MIB, then I assumed this was the case: is that
a correct assumption?) 

It's as if the design was from picturing a GUI screen which has
something called interface and attaching
a bunch of classifier rules to try on the interface.
But this doesn't quite cut it as a MIB which can be
used to actually do this on hardware, at least not
as it is written now. 

For example, when an ifIndex goes away then all the
configuration that is done is GONE.  This is NOT
a good design.  It is a configuration nightmare.

Do you really expect that a System Admin person would be
keeping track of all of this?  That is paramount to having
a sys admin keep track of every route through an ISP. 
And then CONFIGURE for it by knowing the ifIndex at any
point in time.  Which is not possible when setting up
redundant LSPs.  It is not realistic that a Sys Admin
would do this, do you agree?

The way you are treating LSPs is as if they are ALL PVC-like, which
may be true in some, but certainly not ALL instances, it is not a
flexible design, and it is  not scalable design.  It
is a configuration nightmare.

Furthermore, the use of a DISPLAY strings as indices is not viable
for timely execution on the agent-side.  Modeling a
linked list which contains (Integer, DisplayString,
DisplayString) where the only other thing in the table
is RowStatus is also quite a poor design for the agent-side.

What about redirection to a different LSP?  The MIB
doesn't work unless redirection is to an LSP which
has been set up apriori, but what is this based on?
Where is the logic to determine when to redirect and
where to redirect to?  Is the System Admin supposed to
know magically when to do this and where?  Isn't this better
handled by allowing software algorithms to do redirect
versus a sys admin?  Currently, the MIB only allows this
to be configured.  Again, this is neither flexible, nor scalable.

What about mapping back to Labels? (for easy clean up on in a teardown
scenario)

What about load balancing?  Seems like this is NOT supported in
the MIB.

My greatest concern is that this MIB is completely useless unless
ifIndex a "static, persistent index".  By definition, ifIndex doesn't
have to be persistent, especially not through reboots OR DISCONTINUTY
types of situations.
 
How on earth can your MIB be done by an implementation
that does NOT make ifIndex persistent?  Is your intention to
re-write how IfIndex is used?

This MIB is not viable because what you are calling
interfaceIndex is not a true ifIndex, OR maybe the expectation is that
someone 
will be continually configuring this MIB. Not a job I would want.

Since the basis of the MIB is mapping packet classifier rule sets to
ifIndex, is this MIB going to allow for INTEROPERABILITY?  Right now
it does not!  In fact, I would like to see a new rev with a complete
explanation of HOW this MIB will be INTEROPERABLE before seeing
it as adopted as a working group document.  It appears to me at least,
that very little thought was actually given to interoperability.

If the basis of the packet classifier identifier is a DisplayString, then is
this going to be interoperable?  Thus, the way you are identifying packet
classifiers has absolutely no meaning, even from devices by the same vendor.
For example, I could have the SAME exact classifier appear several times
under different names, what good is this?

Section 4. Motivation

* I was expecting a simply stated goal for
this MIB, which I couldn't find.  Is this MIB
intended to be used for all MPLS protocols?

If so, could you state it plainly?

* The statement: "Conceptually, some of the
FTN table functionality could be implemented usig
the Forwarding Information Base(FIB) to map all packets
destined to a prefix to an LSP.  However, this mapping is
course in nature."

What is meant by "course in nature", certainly for LDP
this is fine.   Again, if the intent of the MIB was
more clearly stated that would be helpful.

* The last sentence:  "...as well as new ones (i.e. classifier
rules?) such as those required by MPLS and Diff-Serv."  may
lead the audience to believe that this somehow works with
diff-serv, I didn't see anything in this MIB which was diff-serv
specific, if so could you point this out?

Also, Diff-serv MIBs are being developed in about 3 different
groups, is it your intention to work with any of these
other efforts?  If so, could you elaborate on what the plans
are?

I would like to see all of the above issues explained,
particularly, the issue of InterfaceIndex and interoperability.
BEFORE it is adopted as a working group document.

The entire point of having a standard MIB is for interoperability, and
I do not see how this MIB will provide any sort of interoperability
due to the assumptions regarding InterfaceIndex which have been made
but are NOT at all discussed anywhere in the MIB.

Thank you,
 Joan


--=====================_194064616==_.ALT-- From owner-mpls@UU.NET Wed Mar 15 14:12:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12100 for ; Wed, 15 Mar 2000 14:12:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqu24422; Wed, 15 Mar 2000 19:12:13 GMT Received: by mail-control.mail.uu.net id QQigqu16791 for mpls-outgoing; Wed, 15 Mar 2000 19:11:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigqu16783 for ; Wed, 15 Mar 2000 19:11:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqu24055 for ; Wed, 15 Mar 2000 14:11:05 -0500 (EST) Received: from hercules by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQigqu22995 for ; Wed, 15 Mar 2000 19:11:05 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id LAA23327; Wed, 15 Mar 2000 11:11:09 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 11:11:09 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A6346828@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Joan Cucchiara'" , "'George Swallow'" Cc: "'Thomas D. Nadeau'" , "'Adrian Farrel'" , "'mpls@UU.NET'" , "'vsriniva@cosinecom.com'" Subject: RE: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 11:11:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Joan, > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Joan > Cucchiara > Sent: Wednesday, March 15, 2000 7:56 AM > To: 'George Swallow'; Joan Cucchiara > Cc: 'Thomas D. Nadeau'; Adrian Farrel; mpls@UU.NET; > 'vsriniva@cosinecom.com' > Subject: RE: LSR MIB WG Last Call > > > > George, > > I do raise an objection. It has been pointed > out to me that the rev 02 of the LSR MIB > now states that it intends to support LDP. The LSR MIB supported LDP from day one. It is a mere cross-connect and is absolutely agnostic about which entity created the cross-connect. We introduced the owner field in this rev, based on some feedback, to enable tracking which entity actually created a cross-connect entry. > > When the (TE-MIB which contained the LSR-MIB) was > proposed as a working group document in Minneapolis, > Jim Luciani asked if there would be overlap with the > LDP MIB, he (and the rest of the working group) were > told, "no, not much". I don't recall anybody say "none". And at the same meeting it was decided by the WG to split the then TE document into two documents one for the TE alone and another as LSR MIB applicable to ALL MPLS protocols. > > Now, they intend (apparently) to support LDP. Can you explain how the LSR MIB didn't support LDP in the previous rev? The data model hasn't changed a bit since inception. A single LSR that provides connection capability with several clients (protocols) using the resources. > As a working group, we do NOT need two mibs to > support the same protocol. LDP doesn't constitute an LSR. The label and connection resources are common to every MPLS protocol and hence the LSR MIB. It is just seems absurd to me that LDP requires to manage its own label space and connections instead of a single entity that manages label and connection resources for ALL MPLS protocols. > So I object on this > basis. It does not seem fair to me that > 3 revisions into the LSR MIB, the LSR MIB can expand > its scope to support another protocol, namely LDP, especially > when there is already an active LDP MIB. Let me state this one more time. LSR MIB supported LDP (and every other MPLS protocol) from the day of its inception. > > There has been NO working group consensus about including LDP in > scope of the LSR MIB. The very reason the WG split the intial TE doc into two separate doc was to have a seperate LSR MIB common to all MPLS protocols. > > Why does the working group need two MIBs for LDP Because LDP is not LSR! Please see the above comments. -arun > > Thank you, Joan > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Wednesday, March 15, 2000 10:28 AM > > To: Joan Cucchiara > > Cc: 'Thomas D. Nadeau'; Adrian Farrel; mpls@UU.NET; > > 'swallow@cisco.com'; > > 'vsriniva@cosinecom.com'; swallow@cisco.com > > Subject: Re: LSR MIB WG Last Call > > > > > > Joan - > > > > I believe that Tom merely meant to suggest that the LSR mib was now > > ready for last call. Unless I hear objections I'll issue one before > > the day is out. > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > From owner-mpls@UU.NET Wed Mar 15 14:26:34 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18033 for ; Wed, 15 Mar 2000 14:26:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqv27455; Wed, 15 Mar 2000 19:26:32 GMT Received: by mail-control.mail.uu.net id QQigqv18443 for mpls-outgoing; Wed, 15 Mar 2000 19:25:49 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigqv18434 for ; Wed, 15 Mar 2000 19:25:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqv28640 for ; Wed, 15 Mar 2000 14:25:41 -0500 (EST) Received: from albatross.wise.edt.ericsson.se by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQigqv26860 for ; Wed, 15 Mar 2000 19:25:40 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id UAA14752 for ; Wed, 15 Mar 2000 20:16:15 +0100 (MET) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id UAA22223 for ; Wed, 15 Mar 2000 20:18:55 +0100 (MET) Received: from etx.ericsson.se (avc073.etxb.ericsson.se [130.100.180.231]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FRH00N5Y9NJ53@mbb1.ericsson.se> for mpls@UU.NET; Wed, 15 Mar 2000 20:18:55 +0100 (MET) Date: Wed, 15 Mar 2000 20:18:52 +0100 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: LSR MIB WG Last Call To: "Thomas D. Nadeau" Cc: mpls@UU.NET, Cheenu Srinivasan , arun@force10networks.com Message-id: <38CFE21C.3974CD3A@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.7 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <4.2.2.20000315080814.00dedd00@funnel.cisco.com> <4.2.2.20000315132533.00df9740@funnel.cisco.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Thomas D. Nadeau" wrote: > > Hi Hans, > > > I would like to know why you have "issued a last call? > > I did not issue a last call, as I cannot, nor > was it my intention to do so. The intent of my first > message to George and Vijay was to ask for a WG Last Call > on the MIB. My second message was referring to this > request, not declare a last call. I apologize for the > confusion. Thanks Tom for the clarification on your last call. You certanly fooled me and a lot of others I think. > > > It almost ridiculous to say > > something like that when it doesn't even compile! The main point wasn't that it didn't compile, but after finding several errors in it I draw the conclusion that it didn't go near a compiler. Maybe I was premature in my conclusion. For me it was just another indicator that there is some more work on this before it's mature. > > We compiled the current version with SMIC prior > to releasing it. What are you compiling it with? > Please provide me with your compilation errors > so that I can look into this ASAP. FYI, but as I said, those are editorials. MPLS-LSR-MIB.mib: 774: Error: syntax error before: mplsInSegmentOctets {error,compilation_failed} -- Then I fixed that to get further MPLS-LSR-MIB.mib: 813: Error: Types for mplsInSegmentHCOctets differs from the SEQUENCE definition. {error,compilation_failed} -- Then I fixed that to get further MPLS-LSR-MIB.mib: Error: 'mplsTSpecIndexNext' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsLabelStackRowStatus' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsLabelStackLabel' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsLabelStackIndex' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsLabelStackIndexNext' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsMaxLabelStackDepth' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsXCOwner' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsXCCOS' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsXCLspId' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsOutSegmentErrors' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsInSegmentErrors' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsInterfaceOutFragments' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsInterfaceFailedLabelLookup' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsInterfaceAvailableBuffer' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsInterfaceTotalBuffer' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsInterfaceAvailableBandwidth' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsInterfaceTotalBandwidth' missing in OBJECT-GROUP MPLS-LSR-MIB.mib: Error: 'mplsOutSegmentDown' missing in NOTIFICATION-GROUP {error,compilation_failed} -- then I gave up > > > The only thing you create is confusion, hopefully that > > isn't the goal of the exercise. But what was your purpuse? > > Of course not. My purpose was to ask for a last call > and nothing else. > > --Tom > > > /// Hasse > > > > "Thomas D. Nadeau" wrote: > > > > > > > > > Please do give comments if there are any. > > > The WG Last Call should not preclude that. The > > > reason why we decided to go WGLC at this point > > > was that even during the last round of reviewed > > > comments (most were from you in fact), the comments > > > were relatively minor. We feel that the MIB is pretty > > > solid and mature at this point. > > > > > > --Tom > > > > > > > Your latest version is dated 6th March. > > > > It is now 14th. > > > > > > > > I think it reasonable to give us all a little time to read your > > work > > > > after > > > > all of the effort you have put into it. > > > > > > > > Adrian > > > > -- > > > > Adrian Farrel mailto:af@datcon.co.uk > > > > ATM, MPLS and Telecoms Development Group > > > > Data Connection Ltd., Chester, UK > > > > http://www.datcon.co.uk/ > > > > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > > > > > > > > > > >-----Original Message----- > > > > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > >Sent: Tuesday, March 14, 2000 10:49 PM > > > > >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan > > > > >Cc: Cheenu Srinivasan; arun@force10networks.com > > > > >Subject: LSR MIB WG Last Call > > > > > > > > > > > > > > > > > > > > Since we have not received any additional comments > > > > >on the current version of the LSR MIB, we would like > > > > >to raise the document to WG Last Call. > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Wed Mar 15 14:28:05 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18682 for ; Wed, 15 Mar 2000 14:28:04 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqv08535; Wed, 15 Mar 2000 19:28:04 GMT Received: by mail-control.mail.uu.net id QQigqv18823 for mpls-outgoing; Wed, 15 Mar 2000 19:27:46 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigqv18787 for ; Wed, 15 Mar 2000 19:27:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigqv28858; Wed, 15 Mar 2000 14:27:22 -0500 (EST) From: neil.2.harrison@bt.com Received: from babelbrox.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: babelbrox.axion.bt.co.uk [132.146.16.6]) id QQigqv28119; Wed, 15 Mar 2000 19:27:21 GMT Received: from chqlubnt02.lon.bt.com by babelbrox.axion.bt.co.uk (local) with ESMTP; Wed, 15 Mar 2000 19:26:28 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Wed, 15 Mar 2000 19:26:12 -0000 Message-ID: To: landerss@nortelnetworks.com, Heinrich.Hummel@icn.siemens.de Cc: mpls@UU.NET, te-wg@UU.NET Subject: RE: Internet Draft Submission: Orchestrally Conducted Traffic Date: Wed, 15 Mar 2000 19:26:20 -0000 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk CNLS = Success? I am not sure the CNLS facet is is the only real 'success' criteria. If we are honest, IP has been about 30 years in gestation, but the real traffic take-off (=success??) of the Internet really only came about because of some other protocols developed by Tim Berners-Lee which defined the WWW (and, of course, the impact of Moore's law on silicon). A CNLS transfer mode is important, but then so is a CO one. Here are two examples why: 1 In a true CNLS mode if N sites all send to single egress, then if the end-system cannot handle the multiplexed streams (eg a human is on the end say) then one has little choice but to drop the pkts. Not good news if they have passed an input UPC type function at each of the N sites (ie valid/in-contract traffic), and this impacts congestion and network billing issues. Clearly we need some CAC-type function here.....at least wrt ingress/egress, even if we don't reserve resources at all nodes along the route. But is this CO or CNLS?......looks something in the middle to me, and indeed there is a wide range of grey between true CNLS and CO (see Radia Perlman, Chapter 5 of 'Interconnections'). 2 Anyone even cursorily familar with DiffServ knows it will not allow QoS service differentiation for the majority of operational time (and goodness knows how marketing people are going to sell this stuff). Indeed, DS only kicks in during congestion (maybe as a consequence of a network failure). Customers are very quickly going to work-out that an operator's 'bronze' service is effectively as good as the 'gold' service over the vast majority of operational time......and the differentiator is not QoS per se but more related to survivalbility. Aside......if one wanted to force QoS differentiation over the vast majority of operational time one would have to use dynamically changing (slowly) hard BW partitions between each DS class to maintain a given user/unit-BW density. These hard BW partitions are CO trail objects (in trad L2 speak)......but it looks a horrble control problem, and it may be easier to throw BW at the problem (at least in the core) so all we end up with is a scheduling issue at access points. A key concern here would be if all we could only ever do was to take different customer VPN traffic and aggregate this into like DS classes, ie one had lost sight of the VPN topology. So now, on failure, an operator may not be able to offer a solid perspective on overall VPN survivability. A further complication will arise when in one VPN (or even a work-group partition of one VPN) Voice is seen as mission critical but in another VPN (or partition) it is not. We may get some interesting comments from customers about this during periods of congestion (whatever their cause). So, whilst some VPN customers will be happy with mass aggreation and loss of sight of topology others will not......and I suspect availability SLAs will be a more important metric to many VPN customers that (up-state) QoS metrics. For the latter type of VPN customers we operators will probably want to offer an overall 'effective BW topology' against a given survivability index/SLA, and we would therefore let those type of VPN customers use their own DS classifications as they saw fit....our primary concern here would be to make sure the overall VPN survived. Thanks, Neil > -----Original Message----- > From: Loa Andersson [SMTP:landerss@nortelnetworks.com] > Sent: Wednesday, March 15, 2000 2:53 PM > To: Hummel Heinrich > Cc: mpls@UU.NET; te-wg@UU.NET > Subject: Re: Internet Draft Submission: Orchestrally Conducted > Traffic > > Heinrich, > > there is something that worries me very much about this. From the > abstract: > > "This draft proposes to engineer traffic such that we can speak of an > Orchestrally Conducted Traffic (OCT): Any traffic stream (given by > its source and destination nodes and by a priority class) may use > several differently routed LSPs. Each, traffic stream ingress > reports, periodically, the currently measured traffic load (in > bitrate) to a common TE Conductor (TEC) who evaluates them as to > guess what traffic load change might occur in the immediate time > ahead. Accordingly the TEC computes well synchronized likelihood > values by which to take which route/LSP. These values will be such > that any traffic stream will be served as good as possible, as often > as possible, while equally ranked traffic streams are treated fair, > higher ranked streams are prioritized and the network thruput is > maximized. The TEC sends the likelihood values to the respective > ingress node, who will distribute the received packets of the > traffic stream to the pertaining LSPs accordingly." > > I might misread this, but the IP paradigm has been connection less from > the start, and very much of the success of IP is because of its of this > connection less nature. I do see that we "violate" this little bit by > some of the proposals that has been discussed in the mpls and te > working groups - for what I believe is good reasons. However we should > take extreme care of keeping the connection less nature of IP > networks. > > The Orchestrated Conducted Traffic draft seems to take an extreme > connection oriented approach. We should take care not throw the > baby, bath tub and bath water out at the same time. > > /Loa > > Hummel Heinrich wrote: > > > > Hi all, > > > > I emailed draft-hummel-te-oct-01.txt to internet-drafts@ietf.org. > > I also applied for a time-slot in the TE-WG for presenting this traffic > > balancing concept in Adelaide. > > I appreciate any comment on this topic. > > > > Regards > > > > Heinrich Hummel > > Siemens AG > > heinrich.hummel@icn.siemens.de > > -- > > Loa Andersson > Director Routing Architecture Lab, EMEA > St Eriksgatan 115A, PO Box 6701 > 113 85 Stockholm, Sweden > phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 > e-mail: loa.andersson@nortelnetworks.com From owner-mpls@UU.NET Wed Mar 15 15:19:04 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09414 for ; Wed, 15 Mar 2000 15:19:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigqz23509; Wed, 15 Mar 2000 20:18:57 GMT Received: by mail-control.mail.uu.net id QQigqz01170 for mpls-outgoing; Wed, 15 Mar 2000 20:18:38 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigqz01162 for ; Wed, 15 Mar 2000 20:18:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigqz03597; Wed, 15 Mar 2000 15:18:17 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQigqz22825; Wed, 15 Mar 2000 20:18:16 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id PAA17677; Wed, 15 Mar 2000 15:18:15 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id PAA36689; Wed, 15 Mar 2000 15:18:29 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003152018.PAA36689@curtis-lt.avici.com> To: neil.2.harrison@bt.com cc: landerss@nortelnetworks.com, Heinrich.Hummel@icn.siemens.de, mpls@UU.NET, te-wg@UU.NET Reply-To: curtis@avici.com Subject: Re: Internet Draft Submission: Orchestrally Conducted Traffic In-reply-to: Your message of "Wed, 15 Mar 2000 19:26:20 GMT." Date: Wed, 15 Mar 2000 15:18:29 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , nei l.2.harrison@bt.com writes: > CNLS = Success? I am not sure the CNLS facet is is the only real 'success' > criteria. If we are honest, IP has been about 30 years in gestation, but > the real traffic take-off (=success??) of the Internet really only came > about because of some other protocols developed by Tim Berners-Lee which > defined the WWW (and, of course, the impact of Moore's law on silicon). > > A CNLS transfer mode is important, but then so is a CO one. > > Here are two examples why: > > 1 In a true CNLS mode if N sites all send to single egress, then if > the end-system cannot handle the multiplexed streams (eg a human is on the > end say) then one has little choice but to drop the pkts. Not good news if > they have passed an input UPC type function at each of the N sites (ie > valid/in-contract traffic), and this impacts congestion and network billing > issues. Clearly we need some CAC-type function here.....at least wrt > ingress/egress, even if we don't reserve resources at all nodes along the > route. But is this CO or CNLS?......looks something in the middle to me, > and indeed there is a wide range of grey between true CNLS and CO (see Radia > Perlman, Chapter 5 of 'Interconnections'). > > 2 Anyone even cursorily familar with DiffServ knows it will not allow > QoS service differentiation for the majority of operational time (and > goodness knows how marketing people are going to sell this stuff). Indeed, > DS only kicks in during congestion (maybe as a consequence of a network > failure). Customers are very quickly going to work-out that an operator's > 'bronze' service is effectively as good as the 'gold' service over the vast > majority of operational time......and the differentiator is not QoS per se > but more related to survivalbility. > Aside......if one wanted to force QoS differentiation over the vast majority > of operational time one would have to use dynamically changing (slowly) hard > BW partitions between each DS class to maintain a given user/unit-BW > density. These hard BW partitions are CO trail objects (in trad L2 > speak)......but it looks a horrble control problem, and it may be easier to > throw BW at the problem (at least in the core) so all we end up with is a > scheduling issue at access points. > > A key concern here would be if all we could only ever do was to take > different customer VPN traffic and aggregate this into like DS classes, ie > one had lost sight of the VPN topology. So now, on failure, an operator may > not be able to offer a solid perspective on overall VPN survivability. A > further complication will arise when in one VPN (or even a work-group > partition of one VPN) Voice is seen as mission critical but in another VPN > (or partition) it is not. We may get some interesting comments from > customers about this during periods of congestion (whatever their cause). > > So, whilst some VPN customers will be happy with mass aggreation and loss of > sight of topology others will not......and I suspect availability SLAs will > be a more important metric to many VPN customers that (up-state) QoS > metrics. For the latter type of VPN customers we operators will probably > want to offer an overall 'effective BW topology' against a given > survivability index/SLA, and we would therefore let those type of VPN > customers use their own DS classifications as they saw fit....our primary > concern here would be to make sure the overall VPN survived. > > Thanks, Neil Was this a religious commentary or was it somehow related to the draft being discussed? Curtis From owner-mpls@UU.NET Wed Mar 15 15:55:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24753 for ; Wed, 15 Mar 2000 15:55:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigrb26354; Wed, 15 Mar 2000 20:55:53 GMT Received: by mail-control.mail.uu.net id QQigrb03141 for mpls-outgoing; Wed, 15 Mar 2000 20:55:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigrb03134 for ; Wed, 15 Mar 2000 20:55:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigrb12597 for ; Wed, 15 Mar 2000 15:54:59 -0500 (EST) Received: from hercules by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQigrb25503 for ; Wed, 15 Mar 2000 20:54:59 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id MAA29300; Wed, 15 Mar 2000 12:55:03 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 12:55:03 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A6346829@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Tim Mancour'" , "'Thomas D. Nadeau'" , "'mpls@UU.NET'" , "'swallow@cisco.com'" , "'Vijay Srinivasan'" Cc: "'Cheenu Srinivasan'" , "'arun@force10networks.com'" Subject: RE: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 12:55:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tim, Thanks for the comments. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Tim > Mancour > Tom, > > I think it is a little premature for a last call on this MIB. > I only had a chance to print-out the -02 version yesterday > and have the following comments: > > 1. There is no mention in the MIB regarding the > LSP type/style (e.g. E-LSP or L-LSP). Perhaps > an object should be added to the cross-connect table? Why do you think we need this? The owner object was added to basically be able to track this. > > 2. I'm confused about the COS object in the XC table. > Section 4 references the COS information in the [LblStk] > I-D but there is no mention of COS in this I-D. From the > mplsXCCOS description, I assume that this value should be > used to overwrite the EXP bits. If this is true then there > needs to be a way to disable overwriting the EXP bits. The intent was to use any non-zero information in this object to indicate the action to overwrite as well. I guess having a separate object is better (can overwrite with zero). > > 3. Why is the syntax of all of the get next index objects > (e.g. mplsXCIndexNext) read-only? Shouldn't the TestAndIncr > textual convention be followed? Will check on this. > > 4. There are a number of typos regarding indexes. For example, > mplsInSegmentXCIndex has a syntax of "Integer32 (1..2147483647)" > but the description states that 0 is a valid value. It may be > advisable to create textual conventions to avoid these problems; > something like MplsIndex and MplsIndexOrZero. Okay. > > 5. There are also problems with bandwidth units and > descriptions. > As I understand it, all bandwidths should be in kilobits per > second. In some places, the UNIT is "bits per second". In other > places the description contains "kilobits per second > (Kbps/sec)" > which should be either "kilobits per second (Kbps)" or > "kilobits > per second (Kb/sec)". Will change the text to be consistent with the MplsBitRate definition. > > 6. Section 6.2 mentions a mplsInterfaceResTable but no table > exists. Vestige from some internal revisions. Will remove it. > > 7. The syntax for the mplsInSegmentNPop is > Integer32(1..2147483647). > It should be Integer32(0..2147483647) or even INTEGER(0..255); > since popping 255 labels is still a very large range. Agreed. -arun > > Best regards. > TimM > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Thomas D. > Nadeau > Sent: Tuesday, March 14, 2000 5:49 PM > To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan > Cc: Cheenu Srinivasan; arun@force10networks.com > Subject: LSR MIB WG Last Call > > > > Since we have not received any additional comments > on the current version of the LSR MIB, we would like > to raise the document to WG Last Call. > > --Tom > > > > From owner-mpls@UU.NET Wed Mar 15 16:22:11 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04960 for ; Wed, 15 Mar 2000 16:22:05 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigrd07189; Wed, 15 Mar 2000 21:21:59 GMT Received: by mail-control.mail.uu.net id QQigrd12774 for mpls-outgoing; Wed, 15 Mar 2000 21:21:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigrd12742 for ; Wed, 15 Mar 2000 21:21:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigrd16274 for ; Wed, 15 Mar 2000 16:20:53 -0500 (EST) Received: from hercules by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQigrd17840 for ; Wed, 15 Mar 2000 21:20:53 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id NAA00636; Wed, 15 Mar 2000 13:20:57 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 13:20:57 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A634682A@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'James V. Luciani'" , "'Tim Mancour'" , "'Thomas D. Nadeau'" , "'mpls@UU.NET'" , "'swallow@cisco.com'" , "'Vijay Srinivasan'" Cc: "'Cheenu Srinivasan'" , "'arun@force10networks.com'" Subject: RE: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 13:20:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jim, > > I also find it premature to do a last call on this mib. > You are not the > only person to raise the objection that he/she has not had > sufficient time > to look at the LSR MIB and absorb the full impact of the > changes which have > been made. I know I have not. I certainly have not had > sufficient time to > comment. Further, I find it exceedingly disturbing that this > MIB seems to > have grown in scope by leaps and bounds without sufficient > scrutiny by those > who would instrument it; let alone without receiveing working group > consensus (as fuzzy as the term 'working group conensus' may be in > practice). The only conclusion I can draw from this is that you haven't read the previous versions of this draft. Can you quantify what you mean by leap and bounds? And explicitly state what changes, in you opinion, we have made that has increased its scope. In my understanding the scope has remained the same since it became a WG document. > > It would seem prudent to wait atleast until after Adelaide > to make a > decision on whether to go to last call. The TE/LSR MIB was first adopted as a WG document in Dec of 98. At that time the LSR MIB was part of the TE MIB. Then with the permission of the WG (Minneapolis IETF) it was spawned off as a separate document in June 99 time frame so that a common LSR MIB is available to all protocols. The splitting didn't incur any major changes to the tables or objects. How much more time do you need? -arun From owner-mpls@UU.NET Wed Mar 15 17:44:26 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07826 for ; Wed, 15 Mar 2000 17:44:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigri13605; Wed, 15 Mar 2000 22:44:22 GMT Received: by mail-control.mail.uu.net id QQigri28116 for mpls-outgoing; Wed, 15 Mar 2000 22:43:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigri28109 for ; Wed, 15 Mar 2000 22:43:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigri23533 for ; Wed, 15 Mar 2000 17:42:03 -0500 (EST) Received: from tenornetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQigri11651 for ; Wed, 15 Mar 2000 22:42:03 GMT Received: from mancour (mancour.tenornet.com [192.168.0.137]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id RAA10142; Wed, 15 Mar 2000 17:41:55 -0500 (EST) From: "Tim Mancour" To: "Arun Viswanathan" , "'Thomas D. Nadeau'" , , , "'Vijay Srinivasan'" Cc: "'Cheenu Srinivasan'" Subject: RE: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 17:46:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <0F8929E5ED5FD311B892005004CED4A6346829@tonga.ncorenetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Arun, I don't see anyway to manually configure an E-LSP or L-LSP using the LSR MIB. Without knowing the LSP style, the incoming EXP bits cannot be properly interpreted and therefore cannot be processed. On a related note, a better name for the mplsXCCOS object might be mplsXCEXP. This would allow it to be used for both L-LSP and E-LSPs. I don't think two separate objects are necessary. Just an enumeration of values from 0 .. 7 and an ignore(255 ?). Thanks. TimM -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Arun Viswanathan Sent: Wednesday, March 15, 2000 3:55 PM To: 'Tim Mancour'; 'Thomas D. Nadeau'; 'mpls@UU.NET'; 'swallow@cisco.com'; 'Vijay Srinivasan' Cc: 'Cheenu Srinivasan'; 'arun@force10networks.com' Subject: RE: LSR MIB WG Last Call Tim, Thanks for the comments. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Tim > Mancour > Tom, > > I think it is a little premature for a last call on this MIB. > I only had a chance to print-out the -02 version yesterday > and have the following comments: > > 1. There is no mention in the MIB regarding the > LSP type/style (e.g. E-LSP or L-LSP). Perhaps > an object should be added to the cross-connect table? Why do you think we need this? The owner object was added to basically be able to track this. > > 2. I'm confused about the COS object in the XC table. > Section 4 references the COS information in the [LblStk] > I-D but there is no mention of COS in this I-D. From the > mplsXCCOS description, I assume that this value should be > used to overwrite the EXP bits. If this is true then there > needs to be a way to disable overwriting the EXP bits. The intent was to use any non-zero information in this object to indicate the action to overwrite as well. I guess having a separate object is better (can overwrite with zero). > > 3. Why is the syntax of all of the get next index objects > (e.g. mplsXCIndexNext) read-only? Shouldn't the TestAndIncr > textual convention be followed? Will check on this. > > 4. There are a number of typos regarding indexes. For example, > mplsInSegmentXCIndex has a syntax of "Integer32 (1..2147483647)" > but the description states that 0 is a valid value. It may be > advisable to create textual conventions to avoid these problems; > something like MplsIndex and MplsIndexOrZero. Okay. > > 5. There are also problems with bandwidth units and > descriptions. > As I understand it, all bandwidths should be in kilobits per > second. In some places, the UNIT is "bits per second". In other > places the description contains "kilobits per second > (Kbps/sec)" > which should be either "kilobits per second (Kbps)" or > "kilobits > per second (Kb/sec)". Will change the text to be consistent with the MplsBitRate definition. > > 6. Section 6.2 mentions a mplsInterfaceResTable but no table > exists. Vestige from some internal revisions. Will remove it. > > 7. The syntax for the mplsInSegmentNPop is > Integer32(1..2147483647). > It should be Integer32(0..2147483647) or even INTEGER(0..255); > since popping 255 labels is still a very large range. Agreed. -arun > > Best regards. > TimM > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Thomas D. > Nadeau > Sent: Tuesday, March 14, 2000 5:49 PM > To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan > Cc: Cheenu Srinivasan; arun@force10networks.com > Subject: LSR MIB WG Last Call > > > > Since we have not received any additional comments > on the current version of the LSR MIB, we would like > to raise the document to WG Last Call. > > --Tom > > > > From owner-mpls@UU.NET Wed Mar 15 18:07:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15446 for ; Wed, 15 Mar 2000 18:07:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigrk25348; Wed, 15 Mar 2000 23:07:45 GMT Received: by mail-control.mail.uu.net id QQigrk07314 for mpls-outgoing; Wed, 15 Mar 2000 23:07:13 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigrk07257 for ; Wed, 15 Mar 2000 23:07:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigrk00590 for ; Wed, 15 Mar 2000 18:06:51 -0500 (EST) Received: from tisch.mail.mindspring.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tisch.mail.mindspring.net [207.69.200.157]) id QQigrk02070 for ; Wed, 15 Mar 2000 23:06:51 GMT Received: from jluciani (user-2ive14c.dialup.mindspring.com [165.247.4.140]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA14854; Wed, 15 Mar 2000 18:06:37 -0500 (EST) Message-ID: <002a01bf8ed3$1c2825a0$eba9fea9@jluciani> Reply-To: "James V. Luciani" From: "James V. Luciani" To: "Arun Viswanathan" , "'Tim Mancour'" , "'Thomas D. Nadeau'" , , , "'Vijay Srinivasan'" Cc: "'Cheenu Srinivasan'" , References: <0F8929E5ED5FD311B892005004CED4A634682A@tonga.ncorenetworks.com> Subject: Re: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 18:06:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > It would seem prudent to wait atleast until after Adelaide > > to make a > > decision on whether to go to last call. > > The TE/LSR MIB was first adopted as a WG document in Dec of 98. > At that time the LSR MIB was part of the TE MIB. Then with the permission > of the WG (Minneapolis IETF) it was spawned off as a separate > document in June 99 time frame so that a common LSR MIB is > available to all protocols. The splitting didn't incur > any major changes to the tables or objects. > How much more time do you need? See the above. I thought I made it clear to anyone who read the email :-) --JIm From owner-mpls@UU.NET Wed Mar 15 18:08:36 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15738 for ; Wed, 15 Mar 2000 18:08:35 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigrk26083; Wed, 15 Mar 2000 23:08:37 GMT Received: by mail-control.mail.uu.net id QQigrk07419 for mpls-outgoing; Wed, 15 Mar 2000 23:07:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigrk07390 for ; Wed, 15 Mar 2000 23:07:49 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigrk26223 for ; Wed, 15 Mar 2000 18:07:25 -0500 (EST) Received: from luna.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: luna.host4u.net [216.71.64.45]) id QQigrk02501 for ; Wed, 15 Mar 2000 23:07:24 GMT Received: from toy (jgateadsl.cais.net [205.252.5.196]) by luna.host4u.net (8.8.5/8.8.5) with ESMTP id RAA15694; Wed, 15 Mar 2000 17:05:44 -0600 Message-Id: <4.2.2.20000315175908.00bd1310@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 18:06:11 -0500 To: mpls@UU.NET From: Lou Berger Subject: Fwd: Last Call: RSVP Refresh Overhead Reduction Extensions to Proposed Standard Cc: lberger@labn.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Thought this might interest some as it represents work started in this group... >To: IETF-Announce: ; >Cc: rsvp@isi.edu >From: The IESG >SUBJECT: Last Call: RSVP Refresh Overhead Reduction Extensions to > Proposed Standard >Reply-to: iesg@ietf.org >Date: Wed, 15 Mar 2000 13:08:21 -0500 >Sender: scoya@cnri.reston.va.us > > >The IESG has received a request from the Resource Reservation Setup >Protocol Working Group to consider RSVP Refresh Overhead Reduction >Extensions as a Proposed >Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by April 5, 2000. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-rsvp-refresh-reduct-03.txt From owner-mpls@UU.NET Wed Mar 15 18:27:48 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21788 for ; Wed, 15 Mar 2000 18:27:47 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigrl07053; Wed, 15 Mar 2000 23:27:48 GMT Received: by mail-control.mail.uu.net id QQigrl09120 for mpls-outgoing; Wed, 15 Mar 2000 23:27:28 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigrl09115 for ; Wed, 15 Mar 2000 23:27:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigrl28232 for ; Wed, 15 Mar 2000 18:27:24 -0500 (EST) Received: from hercules by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQigrl06723 for ; Wed, 15 Mar 2000 23:27:23 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id PAA07796; Wed, 15 Mar 2000 15:27:24 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 15:27:24 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A634682F@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'James V. Luciani'" , "'Arun Viswanathan'" , "'Tim Mancour'" , "'Thomas D. Nadeau'" , "'mpls@UU.NET'" , "'swallow@cisco.com'" , "'Vijay Srinivasan'" Cc: "'Cheenu Srinivasan'" Subject: RE: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 15:27:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: James V. Luciani [mailto:jluciani@tollbridgetech.com] > Sent: Wednesday, March 15, 2000 3:07 PM > To: Arun Viswanathan; 'Tim Mancour'; 'Thomas D. Nadeau'; mpls@UU.NET; > swallow@cisco.com; 'Vijay Srinivasan' > Cc: 'Cheenu Srinivasan'; arun@force10networks.com > Subject: Re: LSR MIB WG Last Call > > > > > It would seem prudent to wait atleast until after Adelaide > > > to make a > > > decision on whether to go to last call. > > > > The TE/LSR MIB was first adopted as a WG document in Dec of 98. > > At that time the LSR MIB was part of the TE MIB. Then with > the permission > > of the WG (Minneapolis IETF) it was spawned off as a separate > > document in June 99 time frame so that a common LSR MIB is > > available to all protocols. The splitting didn't incur > > any major changes to the tables or objects. > > How much more time do you need? > > See the above. I thought I made it clear to anyone who read > the email :-) > --JIm > > > I thought the import of the question was clear too. Sufficient time has elapsed since the draft's inception. The changes made to the draft are based on WG feedback only. Moreover, no significant changes were made as you claim (which you haven't quantified yet). This is a delta rev with minimal changes. -arun From owner-mpls@UU.NET Wed Mar 15 18:30:10 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22595 for ; Wed, 15 Mar 2000 18:30:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigrm11412; Wed, 15 Mar 2000 23:30:08 GMT Received: by mail-control.mail.uu.net id QQigrl09192 for mpls-outgoing; Wed, 15 Mar 2000 23:29:38 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigrl09185 for ; Wed, 15 Mar 2000 23:29:30 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigrl28859 for ; Wed, 15 Mar 2000 18:29:28 -0500 (EST) Received: from tisch.mail.mindspring.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tisch.mail.mindspring.net [207.69.200.157]) id QQigrl09406 for ; Wed, 15 Mar 2000 23:29:22 GMT Received: from jluciani (user-2ive14c.dialup.mindspring.com [165.247.4.140]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA31361; Wed, 15 Mar 2000 18:29:14 -0500 (EST) Message-ID: <005001bf8ed6$44eb9aa0$eba9fea9@jluciani> Reply-To: "James V. Luciani" From: "James V. Luciani" To: "Arun Viswanathan" , "'Tim Mancour'" , "'Thomas D. Nadeau'" , , , "'Vijay Srinivasan'" Cc: "'Cheenu Srinivasan'" References: <0F8929E5ED5FD311B892005004CED4A634682F@tonga.ncorenetworks.com> Subject: Re: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 18:29:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I thought the import of the question was clear too. Sufficient time > has elapsed since the draft's inception. The changes made to the > draft are based on WG feedback only. Moreover, no significant > changes were made as you claim (which you haven't quantified yet). > This is a delta rev with minimal changes. Clearly there is not consensus on this issue. --Jim From owner-mpls@UU.NET Wed Mar 15 23:51:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20404 for ; Wed, 15 Mar 2000 23:51:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigsh17969; Thu, 16 Mar 2000 04:51:41 GMT Received: by mail-control.mail.uu.net id QQigsh07467 for mpls-outgoing; Thu, 16 Mar 2000 04:51:19 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigsh07462 for ; Thu, 16 Mar 2000 04:51:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigsh29090 for ; Wed, 15 Mar 2000 23:51:14 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQigsh17298 for ; Thu, 16 Mar 2000 04:51:14 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 04:51:03 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E026389@monk.datcon.co.uk> From: Adrian Farrel To: Tim Mancour Cc: "'Cheenu Srinivasan'" , Arun Viswanathan , "'Thomas D. Nadeau'" , mpls@UU.NET, swallow@cisco.com, "'Vijay Srinivasan'" Subject: RE: LSR MIB WG Last Call Date: Thu, 16 Mar 2000 04:51:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Good catch Tim, I raised this with Tom some months ago in the context of the TE MIB. Tom, I think this is really important. As the MPLS Diff-Serv draft gets much more stable, more people will be implementing it and wanting to configure E-LSP and L-LSP tunnels. We need to - configure E-LSP and L-LSP tunnels - record the Diff-Serv information passing through an LSR - make information available for packet classification? Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Tim Mancour [mailto:timm@tenornetworks.com] >Sent: Wednesday, March 15, 2000 10:46 PM >To: Arun Viswanathan; 'Thomas D. Nadeau'; mpls@UU.NET; >swallow@cisco.com; 'Vijay Srinivasan' >Cc: 'Cheenu Srinivasan' >Subject: RE: LSR MIB WG Last Call > > >Arun, > >I don't see anyway to manually configure an E-LSP or L-LSP >using the LSR MIB. Without knowing the LSP style, the incoming >EXP bits cannot be properly interpreted and therefore cannot be >processed. From owner-mpls@UU.NET Thu Mar 16 02:12:09 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23116 for ; Thu, 16 Mar 2000 02:12:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigsq01097; Thu, 16 Mar 2000 07:12:10 GMT Received: by mail-control.mail.uu.net id QQigsq06837 for mpls-outgoing; Thu, 16 Mar 2000 07:11:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigsq06824 for ; Thu, 16 Mar 2000 07:11:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigsq11500 for ; Thu, 16 Mar 2000 02:10:27 -0500 (EST) Received: from hercules by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQigsq19571 for ; Thu, 16 Mar 2000 07:10:26 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id XAA28768; Wed, 15 Mar 2000 23:10:32 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 23:10:32 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A6346832@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'George Swallow'" , "'Joan Cucchiara'" Cc: "'Thomas D. Nadeau'" , "'Adrian Farrel'" , "'mpls@UU.NET'" , "'vsriniva@cosinecom.com'" Subject: RE: LSR MIB WG Last Call Date: Wed, 15 Mar 2000 23:10:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk George and Vijay, Here are the diffs between the last four versions of this draft. This should help in identifying what exactly changed in the LSR MIB through the revs. I have listed the diffs starting with the March 6, 2000 draft to Feb 16, 1999 draft. If anybody cared to notice we haven't made any substantial or structural changes since Feb 99. Almost all changes in the rev-02 are made based on comments from the list. I see no reason why we should not make last call on this draft. Diff between draft-ietf-mpls-lsr-mib-02.txt (Mar 6 '00) and draft-ietf-mpls-lsr-mib-01.txt (Feb 16, '00): 1. Add new MPLS ifType 166. 2. Removed mplsTSpecDirection from the MplsTSpecTable. 3. Changed MplsBitRate definition. 4. Added mplsInterfaceIsLocalLabelSpace to the MplsInterfaceConfEntry. 5. Changed 'crldp' to 'ldp' in mplsInSegmentOwner and mplsOutSegmentOwner. 6. mplsXCOwner object added to the MplsXCEntry. 7. Added notifications mplsInterfaceTrapEnable, mplsInSegmentTrapEnable, mplsOutSegmentTrapEnable, and mplsXCTrapEnable. 8. Changes to SYNTAX field of several objects. 9. Added text into description field of various objects for better clarity. 10. Some editorial changes in the 'Unit of Conformance' section. Diff between draft-ietf-mpls-lsr-mib-01.txt (Feb 16 '00) and draft-ietf-mpls-lsr-mib-00.txt (Jul 16 '99): 1. Changed formatting from right aligned to unaligned. 2. Added section 8.1. 'Support of the MPLS Layer by ifTable'. 3. Added MplsLSPId support. 4. Added textual conventions for BitRate, BurstSize, and BufferSize. 5. Added BW information in MplsInterfaceConfEntry. 6. Added mplsInterfaceIsGlobalLabelSpace object in mplsInterfaceConfEntry. 7. Removed few objects from the mplsInterfacePerfTable. 8. Added ownership object in MplsInSegmentTable and MplsOutSegmentTable. 9. Added ...IndexNext objects to various tables. 10. Added scaler mplsMaxLabelStackDepth. 11. Removed ifIndex from the TSpec table. Diff between draft-ietf-mpls-lsr-mib-00.txt (Jul 16 '99) and draft-ietf-mpls-te-mib-00.txt (Feb 16 '99): 1. Split LSR MIB into a seperate WG document from TE MIB on WG's recommendation. 2. No changes were made otherwise. -arun > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of George > Swallow > Sent: Wednesday, March 15, 2000 7:28 AM > To: Joan Cucchiara > Cc: 'Thomas D. Nadeau'; Adrian Farrel; mpls@UU.NET; > 'swallow@cisco.com'; > 'vsriniva@cosinecom.com'; swallow@cisco.com > Subject: Re: LSR MIB WG Last Call > > > Joan - > > I believe that Tom merely meant to suggest that the LSR mib was now > ready for last call. Unless I hear objections I'll issue one before > the day is out. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Thu Mar 16 04:05:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04957 for ; Thu, 16 Mar 2000 04:04:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigsy13546; Thu, 16 Mar 2000 09:04:36 GMT Received: by mail-control.mail.uu.net id QQigsy24584 for mpls-outgoing; Thu, 16 Mar 2000 09:04:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigsy24474 for ; Thu, 16 Mar 2000 09:04:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigsy19259 for ; Thu, 16 Mar 2000 04:04:01 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigsy13088 for ; Thu, 16 Mar 2000 09:03:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA03958 for mpls@uu.net; Thu, 16 Mar 2000 04:03:55 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigsy23795 for ; Thu, 16 Mar 2000 09:03:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigsy15348; Thu, 16 Mar 2000 04:03:15 -0500 (EST) Received: from beamer.mchh.siemens.de by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQigsy12682; Thu, 16 Mar 2000 09:03:14 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA05770; Thu, 16 Mar 2000 10:02:34 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA24426; Thu, 16 Mar 2000 10:03:04 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Mar 2000 10:04:07 +0100 Message-ID: From: Hummel Heinrich To: "'curtis@avici.com'" , Loa Andersson Cc: Hummel Heinrich , mpls@UU.NET, te-wg@UU.NET Subject: AW: Internet Draft Submission: Orchestrally Conducted Traffic Date: Thu, 16 Mar 2000 10:04:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis wrote: > I believe there was no comment because there was no interest. > Generally people say nothing rather than expressing no interest but > since Hummel has asked what happenned I'll acknowledge having read the > draft and when it was sent to the mailing list and having reread it > just now and having no interest in pursuing it. [Hummel Heinrich]: IMHO OCT entirely complies with the intentions of the TE-WG. OCT tries to statistical multiplex the entire traffic onto the entire network; will say: it does MACRO-multiplexing. A sentence from the TE framework document: "Likewise, we shall refer to the traffic engineering schemes that deal with network performance optimization at the systems level as macro-TE and the schemes that optimize at the individual resource level as micro-TE." Also, TE framework:"The traffic engineering mechanisms and tools can be implemented in a distributed or centralized fashion" . Yes,OCT represents the centralized fashion. Again from the TE-fw section 2.4:"(2) A collection of online and possibly off-line tools and mechanisms for measurement, characterization, modeling, and control of Internet traffic and control over the placement and allocation of network resources, as well as control over the mapping or distribution of traffic onto the infrastructure." OCT operates online, does measure (bitrates), does characterize (differentiate traffic streams by priorities), does model (the traffic not only as it is but even as to steer it according to TE-goals), does control the mapping or distribution of traffic onto the infrastructure. IMHO this is part of the interest of the TE-WG. Curtis wrote: If there is a specific combination of these ideas that Seimens is trying to patent, then the IETF should avoid producing any standard utilizing that specific combination based on the combination being encumberred. [Hummel Heinrich] In my draft I am mentioning that by establishing communication channels between all ingress nodes and the TEC all information exchange can be done completely in a proprietary fashion, which means only the ingress nodes and the TEC have to come from the same company. It is entirely up to the IETF-WGs whether or not to specify any message, TLV or codepoint with respect to OCT. BTW,the name of my company is Siemens, not Seimens. Regards, Heinrich Hummel Siemens AG heinrich.hummel@icn.siemens.de From owner-mpls@UU.NET Thu Mar 16 04:29:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11046 for ; Thu, 16 Mar 2000 04:29:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigsz25895; Thu, 16 Mar 2000 09:29:17 GMT Received: by mail-control.mail.uu.net id QQigsz28781 for mpls-outgoing; Thu, 16 Mar 2000 09:28:52 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigsz28776 for ; Thu, 16 Mar 2000 09:28:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigsz20792 for ; Thu, 16 Mar 2000 04:28:38 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigsz25459 for ; Thu, 16 Mar 2000 09:28:36 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA06851 for mpls@uu.net; Thu, 16 Mar 2000 04:28:36 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigsz28764 for ; Thu, 16 Mar 2000 09:28:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigsz20778 for ; Thu, 16 Mar 2000 04:28:14 -0500 (EST) Received: from ficon-tech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [12.10.198.190]) id QQigsz10701 for ; Thu, 16 Mar 2000 09:27:57 GMT Received: from ficon-tech.com (jkochar.india.ficon-tech.com [172.25.1.102]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id OAA85603; Thu, 16 Mar 2000 14:51:52 +0530 (IST) (envelope-from jkochar@ficon-tech.com) Message-ID: <38D0A77B.36844C5C@ficon-tech.com> Date: Thu, 16 Mar 2000 14:50:59 +0530 From: Jhilmil Kochar Organization: Ficon Technology X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Srinivasan CC: "'mpls@uu.net'" , jcucchiara@brixnet.com Subject: Re: LDP MIB last call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have certain comments and doubts on the LDP Mib draft -05. Some of these might have been discussed before or already known to authors. In such case please indicate the resolutions and the reasoning behind them. 1. MplsLabel : Textual-convention. The description says "For an ATM label the lower 16-bits represents the VCI, the next 8-bits represents the VPI and the remaining bits MUST be zero." The VPI should be represented by 12 bits rather than 8 bits. 2. mplsLdpEntityEntry: Some of the objects in this table should have a default value assigned as specified by LDP draft. Examples of such objects are mplsLdpEntityWellKnownDiscoveryPort, mplsLdpEntityMaxPduLength, mplsLdpEntityKeepAliveHoldtimer. 3. mplsLdpEntityEntry: The object mplsLdpEntityWellKnownDiscoveryPort is (I assume) for UDP Hello discovery only. What about TCP port for connections? That does not seem to be covered. Am I missing something? 4. mplsLdpEntityEntry: There are two objects mplsLdpEntityRowStatus and mplsLdpEntityAdminStatus in entity table and the requirement of both being present in the same table is not very clear. Probably mplsLdpEntityAdminStatus is redundant and can be removed. 5. mplsLdpEntityFrameRelayParmsEntry: object mplsLdpEntityFrLen has incorrect syntax. seventeenDlciBits is missing from the same. 6. mplsLdpEntityPeerEntry: It is not clear why the entries in this table should not be present in session table. As far as I can make out these parameters and also the parameters in session table are passed in init message between peers, hence the purpose for keeping them in separate tables is not clear. One possible reasoning I could come up with was that one gives peer information that is non-negotiable and other gives peer information that is negotiated. But then this rule does not hold true for all entries. Please clarify. 7.mplsLdpSessionEntry: This is indexed by 3 parameters INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId } What is the requirement of having mplsLDPEntityIndex here? There has been discussion on this topic before and I am not clear on the resolution. Please clarify my doubts. What I understood from the LDP draft was that one LDP session is uniquely identified by local and remote LDPId, hence a third index should not be required. Please explain the scenario in which this may be required. 8. mplsLdpFailedInitSessionThresholdExceeded NOTIFICATION-TYPE: has a typo in description. ""This notification is generated when the value of the 'mplsLdpEntityPVLimitMismatchTrapEnable' object.." 9. mplsLdpSessionUp and mplsLdpSessionDown two notification types are redundant. Only one is required. This notification gives the session state and 'operational' indicates session up and any other state indicates session down. Hence only one notification need be generated when the state moved to / from operational. Thanks and regards Jhilmil Vijay Srinivasan wrote: > > > We would like to commence the last call for: > > Definitions of Managed Objects for the Multiprotocol Label Switching, > Label Distribution Protocol (LDP) > draft-ietf-mpls-ldp-mib-05.txt > > Last call will end on Friday, March 17. Please send your comments to > the list. > > Regards, > - Vijay -- ------------------------------ Jhilmil Kochar Ficon Technology E-mail:jkochar@ficon-tech.com Web: www.ficon-tech.com From owner-mpls@UU.NET Thu Mar 16 05:18:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27424 for ; Thu, 16 Mar 2000 05:18:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigtd00178; Thu, 16 Mar 2000 10:18:03 GMT Received: by mail-control.mail.uu.net id QQigtd09137 for mpls-outgoing; Thu, 16 Mar 2000 10:17:48 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigtd09121 for ; Thu, 16 Mar 2000 10:17:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigtd19829 for ; Thu, 16 Mar 2000 05:17:23 -0500 (EST) From: pasi.vaananen@nokia.com Received: from mgw-x2.nokia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mgw-x2.nokia.com [131.228.20.22]) id QQigtd06424 for ; Thu, 16 Mar 2000 10:17:23 GMT Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id MAA13782; Thu, 16 Mar 2000 12:03:38 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id MAA28829; Thu, 16 Mar 2000 12:03:34 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RMJAPA1>; Thu, 16 Mar 2000 04:02:35 -0600 Message-ID: To: flefauch@cisco.com, curtis@avici.com Cc: Shahram_Davari@pmc-sierra.com, jh@lohi.eng.telia.fi, curtis@avici.com, mpls@UU.NET, bsd@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, ram@nexabit.com, Pierrick.Cheval@alcatel.fr Subject: RE: BANDWIDTH RESERVATION - RE: Announcing draft-ietf-mpls-diff-e xt-03.txt Date: Thu, 16 Mar 2000 04:01:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > So, all in all, I still think: > - you can do pretty good and label-efficient with Mode 1 > - you can do the ideal per-OA thing with Mode 2. > - Mode 3 does not have a strong application in between these 2. > - there are already quite a lot of options in our spec... > > Do you still see a strong application for Mode 3 which would justify > extensions in the MAP but also extensions in all the error codes and > procedures (today we rely on normal RSVP error handling to > signal rejection > because of admission control)? > > Opinions from others? > I don't think that the adding traffic parameters to individual codepoints in signalling warrants the complexity - this was my primary reason I was opposing whole concept of E-LSPs while back (you cannot route the classes independently if you bunch them together). You can do the "right thing" using L-LSPs with parameters and avoid the otherwise resulting mess. Pasi From owner-mpls@UU.NET Thu Mar 16 05:32:51 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02006 for ; Thu, 16 Mar 2000 05:32:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigte13851; Thu, 16 Mar 2000 10:32:49 GMT Received: by mail-control.mail.uu.net id QQigte09824 for mpls-outgoing; Thu, 16 Mar 2000 10:32:27 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigte09819 for ; Thu, 16 Mar 2000 10:32:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigte20878 for ; Thu, 16 Mar 2000 05:32:12 -0500 (EST) Received: from qnsgs000.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qnsgs000.nortelnetworks.com [47.211.0.31]) id QQigte11069 for ; Thu, 16 Mar 2000 10:32:12 GMT Received: from zhard00m.europe.nortel.com (actually zhard00m) by qnsgs000.nortel.com; Thu, 16 Mar 2000 10:31:26 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 10:31:24 -0000 Message-ID: <33E324D95F44D311AA3E00204840075B550353@zhard00e.europe.nortel.com> From: "Mark Gibson" To: "'mpls@uu.net'" Cc: "'sip@lists.research.bell-labs.com'" Subject: updated draft Date: Thu, 16 Mar 2000 10:31:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8F32.C7261804" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8F32.C7261804 Content-Type: text/plain All The updated version of the draft I presented in Washington is now available at: http://www.ietf.org/internet-drafts/draft-gibson-manage-mpls-qos-01.txt The draft has essentially been re-organised and the emphasis on the SIP solution is now downplayed. I do not intend to re-present this in Adelaide as there is some ongoing work to better define and generalise the control layer protocol initially described in draft-gibson-sip-qos-resv-00.txt. Naturally I'll only pursue a WG timeslot once this work is complete and whole. Mark ------_=_NextPart_001_01BF8F32.C7261804 Content-Type: text/html Content-Transfer-Encoding: quoted-printable updated draft

All

The updated version of the draft I = presented in Washington is now available at:

http://www.ietf.org/internet-drafts/draft-gibson-manage-m= pls-qos-01.txt

The draft has essentially been = re-organised and the emphasis on the SIP solution is now = downplayed.
I do not intend to re-present this in = Adelaide as there is some ongoing work to better define and generalise = the control layer protocol initially described in = draft-gibson-sip-qos-resv-00.txt.

Naturally I'll only pursue a WG = timeslot once this work is complete and whole.

Mark

------_=_NextPart_001_01BF8F32.C7261804-- From owner-mpls@UU.NET Thu Mar 16 08:55:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09421 for ; Thu, 16 Mar 2000 08:55:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigtr06415; Thu, 16 Mar 2000 13:55:40 GMT Received: by mail-control.mail.uu.net id QQigtr14756 for mpls-outgoing; Thu, 16 Mar 2000 13:55:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigtr14751 for ; Thu, 16 Mar 2000 13:55:15 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigtr09583 for ; Thu, 16 Mar 2000 08:55:10 -0500 (EST) Received: from albatross.wise.edt.ericsson.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQigtr11040 for ; Thu, 16 Mar 2000 13:55:09 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id OAA00309 for ; Thu, 16 Mar 2000 14:45:41 +0100 (MET) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id OAA05834 for ; Thu, 16 Mar 2000 14:48:21 +0100 (MET) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FRI002IIP0I74@mbb1.ericsson.se> for mpls@UU.NET; Thu, 16 Mar 2000 14:48:19 +0100 (MET) Date: Thu, 16 Mar 2000 14:47:43 +0100 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: LDP MIB last call To: Jhilmil Kochar Cc: "'mpls@uu.net'" , jcucchiara@brixnet.com Message-id: <38D0E5FF.F3E82E14@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <38D0A77B.36844C5C@ficon-tech.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jhilmil, Thanks for the help, some comments inline. Jhilmil Kochar wrote: > > Hi, > I have certain comments and doubts on the LDP Mib draft -05. Some of > these might have been discussed before or already known to authors. In > such case please indicate the resolutions and the reasoning behind them. > > 1. MplsLabel : Textual-convention. The description says > "For an ATM label the lower 16-bits represents the VCI, > the next 8-bits represents the VPI and the remaining > bits MUST be zero." > The VPI should be represented by 12 bits rather than 8 bits. Agree. and the reference 3 should be the LDP spec instead of the ATM. this comments applies to the LSR MIB aswell. > > 2. mplsLdpEntityEntry: Some of the objects in this table should have a > default value assigned as specified by LDP draft. Examples of such > objects are mplsLdpEntityWellKnownDiscoveryPort, > mplsLdpEntityMaxPduLength, mplsLdpEntityKeepAliveHoldtimer. Agree in principle. It however only DiscoveryPort that is specified in other specs. mplsLdpEntityWellKnownDiscoveryPort = 646 Max PDU lenth is really implementation specific. But I see no reason to have any other default value than maximum? mplsLdpEntityMaxPduLength = 65535 ? We could have one for the Keep alive also. But I couldn't find any reference in any other spec. I have a vague memory of seing 40 sec in a older version of specs (or maybe TDP). Could we use 40 sec? mplsLdpEntityKeepAliveHoldtimer = 40 ? > > 3. mplsLdpEntityEntry: The object mplsLdpEntityWellKnownDiscoveryPort is > (I assume) for UDP Hello discovery only. What about TCP port for > connections? That does not seem to be covered. Am I missing something? No, it seams resonable to add that. I see (maybe academic) need f having these possible to be set independantly. Could add mplsLdpEntityWellKnownTcpConnectionPort with 646 as default > > 4. mplsLdpEntityEntry: There are two objects mplsLdpEntityRowStatus and > mplsLdpEntityAdminStatus in entity table and the requirement of both > being present in the same table is not very clear. Probably > mplsLdpEntityAdminStatus is redundant and can be removed. This was discussed on the list, adn I'm not sure of the outcome. My private opinion is that fideling with rowStatus should be avoided to acheive a admState like behaivoir. I think the resolution was to clarify the description. correct Joan? > > 5. mplsLdpEntityFrameRelayParmsEntry: object mplsLdpEntityFrLen has > incorrect syntax. seventeenDlciBits is missing from the same. This wasa change in 05 due to comments, see the changes section: The following items were changed as a result of the Frame Relay Forum dropping support for 17-bit DLCIs: the MplsLabel TC description has been modified, and other Frame Relay Object descriptions were also modified (as specified in this section). > > 6. mplsLdpEntityPeerEntry: It is not clear why the entries in this table > should not be present in session table. As far as I can make out these > parameters and also the parameters in session table are passed in init > message between peers, hence the purpose for keeping them in separate > tables is not clear. One possible reasoning I could come up with was > that one gives peer information that is non-negotiable and other gives > peer information that is negotiated. But then this rule does not hold > true for all entries. Please clarify. > > 7.mplsLdpSessionEntry: This is indexed by 3 parameters > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId > } > What is the requirement of having mplsLDPEntityIndex here? There has > been discussion on this topic before and I am not clear on the > resolution. Please clarify my doubts. What I understood from the LDP > draft was that one LDP session is uniquely identified by local and > remote LDPId, hence a third index should not be required. Please explain > the scenario in which this may be required. This has been debated in length on the list and offline before. I have to revisit soem of the emails to find the conclusions to that. > > 8. mplsLdpFailedInitSessionThresholdExceeded NOTIFICATION-TYPE: has a > typo in description. > ""This notification is generated when the value of > the 'mplsLdpEntityPVLimitMismatchTrapEnable' object.." To be fixed > > 9. mplsLdpSessionUp and mplsLdpSessionDown two notification types are > redundant. Only one is required. This notification gives the session > state and 'operational' indicates session up and any other state > indicates session down. Hence only one notification need be generated > when the state moved to / from operational. A modelling choise simply. Some management systems like different traps for different events. Could be done either way. > > Thanks and regards > Jhilmil > > Vijay Srinivasan wrote: > > > > > > > We would like to commence the last call for: > > > > Definitions of Managed Objects for the Multiprotocol Label Switching, > > Label Distribution Protocol (LDP) > > draft-ietf-mpls-ldp-mib-05.txt > > > > Last call will end on Friday, March 17. Please send your comments to > > the list. > > > > Regards, > > - Vijay > > -- > > ------------------------------ > Jhilmil Kochar > Ficon Technology > E-mail:jkochar@ficon-tech.com > Web: www.ficon-tech.com regards /// Hasse From owner-mpls@UU.NET Thu Mar 16 10:17:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10701 for ; Thu, 16 Mar 2000 10:17:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigtx17277; Thu, 16 Mar 2000 15:17:04 GMT Received: by mail-control.mail.uu.net id QQigtx04964 for mpls-outgoing; Thu, 16 Mar 2000 15:16:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigtx04959 for ; Thu, 16 Mar 2000 15:16:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigtx16103 for ; Thu, 16 Mar 2000 10:16:24 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigtx16498 for ; Thu, 16 Mar 2000 15:16:23 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA08747 for mpls@uu.net; Thu, 16 Mar 2000 10:16:22 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigtx04832 for ; Thu, 16 Mar 2000 15:15:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigtx20564 for ; Thu, 16 Mar 2000 10:15:37 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQigtx28316 for ; Thu, 16 Mar 2000 15:15:36 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 10:13:55 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F86F@brixcorp2.brixnet.com> From: Joan Cucchiara To: =?iso-8859-1?Q?=27Hans_Sj=F6strand=27?= , Jhilmil Kochar Cc: "'mpls@uu.net'" , Joan Cucchiara Subject: RE: LDP MIB last call Date: Thu, 16 Mar 2000 10:13:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA10701 > -----Original Message----- > From: Hans Sjöstrand [mailto:hans.sjostrand@etx.ericsson.se] > Sent: Thursday, March 16, 2000 8:48 AM > To: Jhilmil Kochar > Cc: 'mpls@uu.net'; jcucchiara@brixnet.com > Subject: Re: LDP MIB last call > > > Hi Jhilmil, > > Thanks for the help, some comments inline. > > Jhilmil Kochar wrote: > > > > Hi, > > I have certain comments and doubts on the LDP Mib draft > -05. Some of > > these might have been discussed before or already known to > authors. In > > such case please indicate the resolutions and the reasoning > behind them. > > > > 1. MplsLabel : Textual-convention. The description says > > "For an ATM label the lower 16-bits represents the VCI, > > the next 8-bits represents the VPI and the remaining > > bits MUST be zero." > > The VPI should be represented by 12 bits rather than 8 bits. > > Agree. and the reference 3 should be the LDP spec instead of the ATM. > this comments applies to the LSR MIB aswell. > > > > > 2. mplsLdpEntityEntry: Some of the objects in this table > should have a > > default value assigned as specified by LDP draft. Examples of such > > objects are mplsLdpEntityWellKnownDiscoveryPort, > > mplsLdpEntityMaxPduLength, mplsLdpEntityKeepAliveHoldtimer. > > Agree in principle. It however only DiscoveryPort that is specified > in other specs. > mplsLdpEntityWellKnownDiscoveryPort = 646 > > Max PDU lenth is really implementation specific. But I see no > reason to > have any other default value than maximum? > > mplsLdpEntityMaxPduLength = 65535 ? > > We could have one for the Keep alive also. But I couldn't find any > reference in any other spec. I have a vague memory of seing 40 sec > in a older version of specs (or maybe TDP). Could we use 40 sec? > mplsLdpEntityKeepAliveHoldtimer = 40 ? > > > > > 3. mplsLdpEntityEntry: The object > mplsLdpEntityWellKnownDiscoveryPort is > > (I assume) for UDP Hello discovery only. What about TCP port for > > connections? That does not seem to be covered. Am I missing > something? > > No, it seams resonable to add that. I see (maybe academic) > need f having > these possible to be set independantly. Could add > mplsLdpEntityWellKnownTcpConnectionPort with 646 as default > > > > > 4. mplsLdpEntityEntry: There are two objects > mplsLdpEntityRowStatus and > > mplsLdpEntityAdminStatus in entity table and the requirement of both > > being present in the same table is not very clear. Probably > > mplsLdpEntityAdminStatus is redundant and can be removed. > > This was discussed on the list, adn I'm not sure of the outcome. My > private opinion is that fideling with rowStatus should be avoided to > acheive a > admState like behaivoir. I think the resolution was to clarify the > description. correct Joan? From my recollection the thinking was that there are different levels of user access which could be done if both objects were kept. For example, a user which is allowed to set RowStatus (and AdminStatus) versus a user that is allowed only to set AdminStatus. AdminStatus has a subset of the functionality which RowStatus does. We could add more text to describe this. > > > > > 5. mplsLdpEntityFrameRelayParmsEntry: object mplsLdpEntityFrLen has > > incorrect syntax. seventeenDlciBits is missing from the same. > > This wasa change in 05 due to comments, see the changes section: > The following items were changed as a result of the Frame > Relay Forum > dropping support for 17-bit DLCIs: the MplsLabel TC > description has > been modified, and other Frame Relay Object descriptions were also > modified (as specified in this section). > > > > 6. mplsLdpEntityPeerEntry: It is not clear why the entries > in this table > > should not be present in session table. As far as I can > make out these > > parameters and also the parameters in session table are > passed in init > > message between peers, hence the purpose for keeping them > in separate > > tables is not clear. One possible reasoning I could come up with was > > that one gives peer information that is non-negotiable and > other gives > > peer information that is negotiated. But then this rule > does not hold > > true for all entries. Please clarify. The split between the two tables were for values used in an active Session, versus values which were ignored by the session (although a session is still created). The objects in the EntityPeer Table are related to PathVectorLimit and are used to generate a trap if a mismatch occurs. The Session uses the PathVector value which is in the Entity Table if there is a mismatch between the two values. We probably should add more text here then, if this is not clear. > > > > 7.mplsLdpSessionEntry: This is indexed by 3 parameters > > INDEX { mplsLdpEntityLdpId, > > mplsLdpEntityIndex, > > mplsLdpPeerLdpId > > } > > What is the requirement of having mplsLDPEntityIndex here? There has > > been discussion on this topic before and I am not clear on the > > resolution. Please clarify my doubts. What I understood from the LDP > > draft was that one LDP session is uniquely identified by local and > > remote LDPId, hence a third index should not be required. > Please explain > > the scenario in which this may be required. > > This has been debated in length on the list and offline before. I have > to revisit soem of the emails to find the conclusions to that. We were asked to add this because some companies wanted it. Your implementation may not actually use this, but still it needs to be supported. This is a standard MIB afterall and so needs to accomodate as many folks as possible. Not having it would mean that others could not implement the LDP MIB, whereas if your implementation does not need it, supporting it does not limit your implementation other than the overhead. As Hans said this has been discussed on the list quite a bit in about the June/July/August time frame. Most notably the Minutes of the Oslo meeting. One company which is doing MPLS using PPP for example, expressed that they needed mplsLdpEntityIndex. Hope that helps, and thanks for the feedback. -Joan > > > > > 8. mplsLdpFailedInitSessionThresholdExceeded > NOTIFICATION-TYPE: has a > > typo in description. > > ""This notification is generated when the value of > > the 'mplsLdpEntityPVLimitMismatchTrapEnable' object.." > > To be fixed > > > > > 9. mplsLdpSessionUp and mplsLdpSessionDown two notification > types are > > redundant. Only one is required. This notification gives the session > > state and 'operational' indicates session up and any other state > > indicates session down. Hence only one notification need be > generated > > when the state moved to / from operational. > > A modelling choise simply. Some management systems like > different traps > for different events. Could be done either way. > > > > > Thanks and regards > > Jhilmil > > > > Vijay Srinivasan wrote: > > > > > > > > > > > We would like to commence the last call for: > > > > > > Definitions of Managed Objects for the Multiprotocol > Label Switching, > > > Label Distribution Protocol (LDP) > > > draft-ietf-mpls-ldp-mib-05.txt > > > > > > Last call will end on Friday, March 17. Please send your > comments to > > > the list. > > > > > > Regards, > > > - Vijay > > > > -- > > > > ------------------------------ > > Jhilmil Kochar > > Ficon Technology > > E-mail:jkochar@ficon-tech.com > > Web: www.ficon-tech.com > > regards > /// Hasse > From owner-mpls@UU.NET Thu Mar 16 10:21:29 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12199 for ; Thu, 16 Mar 2000 10:21:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigtx01965; Thu, 16 Mar 2000 15:21:27 GMT Received: by mail-control.mail.uu.net id QQigtx05158 for mpls-outgoing; Thu, 16 Mar 2000 15:21:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigtx05148 for ; Thu, 16 Mar 2000 15:20:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigtx16513 for ; Thu, 16 Mar 2000 10:19:47 -0500 (EST) Received: from mail-blue.research.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQigtx00715 for ; Thu, 16 Mar 2000 15:19:47 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 04CF44CE23; Thu, 16 Mar 2000 10:19:42 -0500 (EST) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id KAA23845; Thu, 16 Mar 2000 10:19:40 -0500 (EST) Reply-To: From: "John Strand" To: "'CATANZARITI Sergio FTR&D/TI'" , "'Chip Sharp'" Cc: Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 10:19:33 -0500 Message-ID: <00ce01bf8f5b$09490700$3e82cf87@pcstranded.research.att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01BF8F31.2072FF00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <337055FBC675D311A85D00508B5A9C4F254211@u-mail.rd.francetelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00CF_01BF8F31.2072FF00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSdkIGxpa2UgdG8gcmVpbmZvcmNlIHRoZXNlIGNvbmNlcm5zLiBJdCBzZWVtcyB0byBtZSB0aGF0 IGRlZmluaW5nIHRoZSBzY29wZSBvZiB0aGlzIHdvcmsgdG8gY292ZXIgb25seSBwZWVyLXRvLXBl ZXIgbW9kZWxzDQpvZiByb3V0ZXIvT1hDIGludGVyYWN0aW9ucyB3b3VsZCBkcmFzdGljYWxseSBs aW1pdCBpdHMgdmFsdWUgaW4gdGhlIHNob3J0LXRvLW1lZGl1bSB0ZXJtIGF0IGxlYXN0LiBTaW1p bGFybHkgd2l0aCBkaXNjbG9zdXJlDQpvZiBwaHlzaWNhbCB0b3BvbG9neSBpbmZvcm1hdGlvbi4g UmVjZW50IE9JRiBjb250cmlidXRpb25zIGZyb20gbWFueSBvZiB0aGUgcHJpbmNpcGFsIHBsYXll cnMgc3VnZ2VzdCB0aGF0IGZ1cnRoZXIgc3R1ZHkgDQpvZiB0aGVzZSBpc3N1ZXMgYmVmb3JlIGxp bWl0aW5nIHdvcmsgdG8gYSBzaW5nbGUgbW9kZWwgIGlzIG5lZWRlZCwgYXMgZG9lcyBkcmFmdC1y c3RiLW9wdGljYWwtc2lnbmFsaW5nLWZyYW1ld29yay0wMC50eHQuDQoNCkpvaG4NCkpvaG4gU3Ry YW5kDQpBVCZUDQpMaWdodHdhdmUgTmV0d29ya3MgUmVzZWFyY2ggRGVwdC4NCjEwMCBTY2h1bHog RHJpdmUsIFJvb20gNC0yMTINClJlZCBCYW5rLCBOLkouIDA3NzAxLTcwMzMNCig3MzIpMzQ1LTMy NTUNCmpsc0ByZXNlYXJjaC5hdHQuY29tIA0KDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCiAgICBGcm9tOiBvd25lci1tcGxzQFVVLk5FVCBbbWFpbHRvOm93bmVyLW1wbHNAVVUuTkVU XU9uIEJlaGFsZiBPZiBDQVRBTlpBUklUSSBTZXJnaW8gRlRSJkQvVEkNCiAgICBTZW50OiBXZWRu ZXNkYXksIE1hcmNoIDE1LCAyMDAwIDE6MTggUE0NCiAgICBUbzogJ0NoaXAgU2hhcnAnDQogICAg Q2M6ICdtcGxzQFVVLk5FVCc7ICdpcC1vcHRpY2FsQGxpc3RzLnJlc2VhcmNoLmJlbGwtbGFicy5j b20nDQogICAgU3ViamVjdDogUkU6IE9wdGljYWwgSVAgYWN0aXZpdGllcyANCiAgICANCiAgICAN CiAgICBJIHdhcyBhd2FyZSBvZiB0aGF0LiBJbmRlZWQsIHRoYXQgbWFrZXMgbWUgbW9yZSBjb25m dXNlZCBhbmQgd29ycmllZC4gDQogICAgVGhlIElUVS1UIChTRzE1Pykgc2VlbXMgdG8gaGF2ZSBj b25jZXJucyBvbiB3b3JraW5nIG9uIGEgcGVlciBtb2RlbCBmb3IgYW4gSVAgb3ZlciBPcHRpY3Mg bmV0d29ya2luZyBhcmNoaXRlY3R1cmUsIGxlYW5pbmcgdG93YXJkcyBhbiBvdmVybGF5IHNjZW5h cmlvLiBJbiBvdGhlciB3b3JkcywgdGhlcmUgYXJlIHNvbWUgY29uY2VybnMgYWJvdXQgbWFraW5n IHRoZSBPQ2ggbGF5ZXIgdG9wb2xvZ3kgaW5mb3JtYXRpb24gcmV2ZWFsZWQgdG8gdGhlIElQIHNl cnZpY2UgY2xpZW50IGxheWVyLiANCg0KICAgIE9uIHRoZSBjb250cmFyeSwgdGhlIElFVEYgc2Vl bXMgdG8gZ28gaW4gdGhlIG90aGVyIGRpcmVjdGlvbiAoYWx0aG91Z2ggYSByZWNlbnQgSUVURiBk cmFmdCwgSSBiZWxpZXZlIGZyb20gTm9ydGVsIGFuZCBMdWNlbnQsIGVuZG9yc2VzIHRoZSBzYW1l IElUVS1UIGNvbmNlcm5zKS4NCg0KICAgIEZyb20gdGhlIE1QTFMgcmV2aXNlZCBjaGFydGVyOiAN Cg0KICAgIDQuICBTaW1wbGlmeSBpbnRlZ3JhdGlvbiBvZiByb3V0ZXJzIHdpdGggb3B0aWNhbCBj cm9zcy1jb25uZWN0IGJhc2VkDQogICAgdGVjaG5vbG9naWVzIA0KDQogICAgYSkgbWFraW5nIG9w dGljYWwgY3Jvc3MgY29ubmVjdHMgYmVoYXZlIGFzIHBlZXJzIHRvIHJvdXRlcnMgKHRodXMNCiAg ICByZWR1Y2luZyB0aGUgbnVtYmVyIG9mIHJvdXRpbmcgcGVlcnMgdGhhdCBhIHJvdXRlciBoYXMg dG8gbWFpbnRhaW4pLCANCg0KICAgIGIpIGJ5IG1ha2luZyBpbmZvcm1hdGlvbiBhYm91dCBwaHlz aWNhbCB0b3BvbG9neSBhdmFpbGFibGUgdG8NCiAgICBOZXR3b3JrIExheWVyIHJvdXRpbmcgcHJv Y2VkdXJlcywgYW5kIA0KDQogICAgYykgYnkgZW1wbG95aW5nIGNvbW1vbiBhZGRyZXNzaW5nLCBy b3V0aW5nLCBhbmQgbWFuYWdlbWVudA0KICAgIHByb2NlZHVyZXMuIA0KDQogICAgSSBndWVzcyB0 aGF0IGl0IGlzIHRvbyBlYXJseSB0byBkZWJhdGUgbW9kZWwgaXNzdWVzLCBpbiBvcmRlciB0byBh dm9pZCBJUCBvdmVyIEFUTSBtb2RlbCBkZWJhdGUtbGlrZSBhY3Rpdml0aWVzLiANCiAgICBQZXJz b25hbGx5LCBJIHdvdWxkIGZpcnN0IHdvcmsgb24gT3B0aWNhbCBJUCBuZXR3b3JraW5nIGFyY2hp dGVjdHVyZSBhbmQgY29udHJvbCBwbGFuZSByZXF1aXJlbWVudHMgZGVmaW5pdGlvbiwgdGhlbiBj aG9vc2luZyB0aGUgcmlnaHQgcHJvdG9jb2wgbWFjaGluZXJ5IChNUExTLCBYL1kvWiBwcm90b2Nv bCksIGFuZCB1bHRpbWF0ZWx5IGZhY2luZyB0aGUgbXVsdGktZGltZW5zaW9uIG1vZGVsIHByb2Js ZW0gKHRvcG9sb2d5IGNvbXBsZXhpdHksIHNlcnZpY2UgbGF5ZXIgY29uZmlndXJhdGlvbiwgT0Em TSBwcm9jZWR1cmVzLCBQTU8gc3RhdHVzIHF1bywgY29tbWVyY2lhbCBjb25zaWRlcmF0aW9ucywg ZXRjLikNCg0KICAgIFNlcmdpbyANCg0KICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgICAgICAgU2Vy Z2lvIENhdGFuemFyaXRpIA0KICAgICAgICBTZW5pb3IgUHJvamVjdCBNYW5hZ2VyLCBUZWNobm9s b2d5IEludGVncmF0aW9uIA0KICAgICAgICBGcmFuY2UgVGVsZWNvbSBSJkQgDQogICAgICAgIDEw MDAgTWFyaW5hIEJvdWxldmFyZCBTdWl0ZSAzMDAgDQogICAgICAgIEJyaXNiYW5lIENBIDk0MDA1 IA0KICAgICAgICBUZWwuIDY1MC04NzUtMTUyNiANCiAgICAgICAgRmF4LiA2NTAtODc1LTE1MDUg DQogICAgICAgIGVtYWlsOnNlcmdpby5jYXRhbnphcml0aUByZC5mcmFuY2V0ZWxlY29tLmNvbSAN CiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoNCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCiAgICAgICAgRnJvbTogICBDaGlwIFNoYXJwIFtTTVRQ OmNoc2hhcnBAY2lzY28uY29tXSANCiAgICAgICAgU2VudDogICBXZWRuZXNkYXksIE1hcmNoIDE1 LCAyMDAwIDk6NDUgQU0gDQogICAgICAgIFRvOiAgICAgQ0FUQU5aQVJJVEkgU2VyZ2lvIEZUUiZE L1RJOyAnaXAtb3B0aWNhbEBsaXN0cy5yZXNlYXJjaC5iZWxsLWxhYnMuY29tJyANCiAgICAgICAg Q2M6ICAgICAnbXBsc0BVVS5ORVQnIA0KICAgICAgICBTdWJqZWN0OiAgICAgICAgUmU6IE9wdGlj YWwgSVAgYWN0aXZpdGllcyANCg0KICAgICAgICBGWUksIA0KICAgICAgICBJdCBsb29rcyBsaWtl IHRoZSBJVFUgKFNHIDEzLCBTRzE1IGFuZCBwb3NzaWJseSBTRzExKSBtYXkgYmUgZ2V0dGluZyBp bnRvIA0KICAgICAgICB0aGlzIGFyZWEgYXMgd2VsbC4gIEF0IHRoZSBTRzEzIG1lZXRpbmcgaW4g S3lvdG8sIHRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gDQogICAgICAgIG9mIHRoaXMgdG9waWMu ICBUaGV5IGFyZSBkZWZpbml0ZWx5IHdvcmtpbmcgb24gbmV4dC1nZW4gb3B0aWNhbCBuZXR3b3Jr aW5nIA0KICAgICAgICBpc3N1ZXMuIA0KDQogICAgICAgIENoaXAgDQoNCiAgICAgICAgQXQgMDU6 MjMgUE0gMy8xNC8wMCAtMDgwMCwgQ0FUQU5aQVJJVEkgU2VyZ2lvIEZUUiZEL1RJIHdyb3RlOiAN Cg0KICAgICAgICA+VG9kYXkgSSB3YXMgcmVhZGluZyB0aGUgTVBMUyByZXZpc2VkIGNoYXJ0ZXIg c2VudCBieSBWaWpheSBhbmQgSSBoYXZlIA0KICAgICAgICA+Zm91bmQgb3B0aWNhbCBJUCByZWxh dGVkIGFjdGl2aXRpZXMsIGxpa2UgdGhhdDogDQogICAgICAgID4gDQogICAgICAgID42LiAgU3Bl Y2lmeSBleHRlbnNpb25zIHRvIHRoZSBwcm90b2NvbHMgYW5kIHByb2NlZHVyZXMgdXNlZCBmb3Ig DQogICAgICAgID5zaWduYWxpbmcgZXhwbGljaXQgcm91dGVzIGFuZCB0byBlZmZlY3QgZmFzdCBy ZWNvdmVyeSBvZiBMU1BzIA0KICAgICAgICA+Zm9yIHVzZSBpbiBPcHRpY2FsIENyb3NzIENvbm5l Y3RzLiANCiAgICAgICAgPiANCiAgICAgICAgPk5vdywgcmVhZGluZyBmcm9tIHRoZSBJUCBvdmVy IE9wdGljYWwgQm9GIGRlc2NyaXB0aW9uLCBJIGZpbmQ6IA0KICAgICAgICA+IA0KICAgICAgICA+ LSBNb2RpZnlpbmcgZXhpc3RpbmcgSVAgYW5kIE1QTFMgcm91dGluZyBhbmQgY29ubmVjdGlvbiBz aWduYWxpbmcgDQogICAgICAgID4gICBwcm90b2NvbHMgDQogICAgICAgID4gDQogICAgICAgID5J IGtub3cgdGhhdCBpdCBpcyBzdGlsbCBwcmV0dHkgbXVjaCBpbW1hdHVyZSB0byB0YWxrIGFib3V0 IHJlc3VsdHMgb2YgdGhlIA0KICAgICAgICA+dXBjb21pbmcgSVAgb3ZlciBPcHRpY2FsIEJvRiwg YnV0IGhvdyB3aWxsIGFuIGV2ZW50dWFsIFdHIGNvbWluZyBvdXQgZnJvbSANCiAgICAgICAgPnRo aXMgQm9GIHJlY29uY2lsZSB3aXRoIHRoZSBNUExTIFdHIGFjdGl2aXR5IGluIHRoZSBPcHRpY2Fs IElQIGFyZW5hPyANCiAgICAgICAgPiANCiAgICAgICAgPkJ5IHdvcmtpbmcgb24gYSBnZW5lcmlj IGNvbnRyb2wgcGxhbmUgYXJjaGl0ZWN0dXJlIGFuZCByZXF1aXJlbWVudHMgDQogICAgICAgID5k ZWZpbml0aW9uLCBhbmQgbGVhdmluZyBvdXQgdG8gdGhlIE1QTFMgV0cgc3BlY2lmaWMgd29yayBv biB0aGUgZ2VuZXJpYyANCiAgICAgICAgPm1lY2hhbmlzbXMgYW5kIHByb2NlZHVyZSBmb3IgYW4g TVBMUyBpbXBsZW1lbnRhdGlvbiBvZiBhbiBPcHRpY2FsIElQIA0KICAgICAgICA+Y29udHJvbCBw bGFuZT8gSXMgdGhpcyBhIHBvc3NpYmxlIGludHJhLUlFVEYgYWN0aXZpdHkgc2NlbmFyaW8/IFdo aWNoIG90aGVycz8gDQogICAgICAgID4gDQogICAgICAgID5Mb29raW5nIGZvciBhIGJyaWVmIGFu ZCByb3VnaCBoaW50LiANCiAgICAgICAgPiANCiAgICAgICAgPlRoYW5rcywgDQogICAgICAgID5T ZXJnaW8gDQogICAgICAgID4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgICAgICAgPlNlcmdpbyBDYXRhbnphcml0 aSAgU2VuaW9yIFByb2plY3QgTWFuYWdlciwgVGVjaG5vbG9neSBJbnRlZ3JhdGlvbiAgRnJhbmNl IA0KICAgICAgICA+VGVsZWNvbSBSJkQgIDEwMDAgTWFyaW5hIEJvdWxldmFyZCBTdWl0ZSAzMDAg IEJyaXNiYW5lIENBIDk0MDA1ICBUZWwuIA0KICAgICAgICA+NjUwLTg3NS0xNTI2ICBGYXguIA0K ICAgICAgICA+NjUwLTg3NS0xNTA1ICBlbWFpbDpzZXJnaW8uY2F0YW56YXJpdGlAcmQuZnJhbmNl dGVsZWNvbS5jb20gDQogICAgICAgID4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCg0KICAgICAgICBTdXBwb3J0IE5l dEFpZCEgIGh0dHA6Ly93d3cubmV0YWlkLm9yZyANCiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgIENoaXAgU2hhcnAgICAg ICAgICAgICAgICAgIENvbnN1bHRpbmcgRW5naW5lZXJpbmcgDQogICAgICAgIENpc2NvIFN5c3Rl bXMgICAgICAgICAgICAgIFRlbGNvIEJpby1yZWdpb24gDQogICAgICAgIFJlYWxpdHkgLSBMb3Zl IGl0IG9yIExlYXZlIGl0LiAgICAgICAgICAgICAgICAgIA0KICAgICAgICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCg0K ------=_NextPart_000_00CF_01BF8F31.2072FF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0 bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQoNCg0KPFRJVExFPlJFOiBPcHRpY2FsIElQIGFjdGl2 aXRpZXM8L1RJVExFPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0LjcyLjIxMDYuNiInIG5hbWU9 R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFk+DQo8RElWPjxTUEFOIGNsYXNzPTM2ODMyNDgxNC0x NjAzMjAwMD48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPkknZCANCmxpa2Ug dG8gcmVpbmZvcmNlIHRoZXNlIGNvbmNlcm5zLiBJdCBzZWVtcyB0byBtZSB0aGF0IGRlZmluaW5n IHRoZSBzY29wZSBvZiB0aGlzIA0Kd29yayB0byBjb3ZlciBvbmx5IHBlZXItdG8tcGVlciBtb2Rl bHM8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zNjgzMjQ4MTQtMTYwMzIw MDA+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+ PFNQQU4gY2xhc3M9MzY4MzI0ODE0LTE2MDMyMDAwPjxGT05UIGNvbG9yPSMwMDAwZmYgDQpmYWNl PUFyaWFsIHNpemU9Mj5vZiByb3V0ZXIvT1hDIGludGVyYWN0aW9ucyB3b3VsZCBkcmFzdGljYWxs eSBsaW1pdCBpdHMgdmFsdWUgDQppbiB0aGUgc2hvcnQtdG8tbWVkaXVtIHRlcm0gYXQgbGVhc3Qu IFNpbWlsYXJseSB3aXRoIA0KZGlzY2xvc3VyZTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxT UEFOIGNsYXNzPTM2ODMyNDgxNC0xNjAzMjAwMD48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJp YWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj48U1BBTiBjbGFzcz0zNjgzMjQ4MTQtMTYwMzIwMDA+ PEZPTlQgY29sb3I9IzAwMDBmZiANCmZhY2U9QXJpYWwgc2l6ZT0yPm9mIHBoeXNpY2FsIHRvcG9s b2d5IGluZm9ybWF0aW9uLiBSZWNlbnQgT0lGIGNvbnRyaWJ1dGlvbnMgDQpmcm9tIG1hbnkgb2Yg dGhlIHByaW5jaXBhbCBwbGF5ZXJzIHN1Z2dlc3QgdGhhdCA8L0ZPTlQ+PC9TUEFOPjxTUEFOIA0K Y2xhc3M9MzY4MzI0ODE0LTE2MDMyMDAwPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBz aXplPTI+ZnVydGhlciBzdHVkeSANCjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNs YXNzPTM2ODMyNDgxNC0xNjAzMjAwMD48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6 ZT0yPm9mIA0KdGhlc2UgaXNzdWVzIGJlZm9yZSBsaW1pdGluZyB3b3JrIHRvIGEgc2luZ2xlIG1v ZGVsJm5ic3A7IGlzIG5lZWRlZCwgYXMgZG9lcyANCmRyYWZ0LXJzdGItb3B0aWNhbC1zaWduYWxp bmctZnJhbWV3b3JrLTAwLnR4dC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFz cz0zNjgzMjQ4MTQtMTYwMzIwMDA+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIA0Kc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTM2ODMyNDgx NC0xNjAzMjAwMD48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgDQpzaXplPTI+Sm9objwv Rk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPg0KPFA+PEZPTlQgc2l6ZT0yPkpvaG4gU3RyYW5kPEJS PkFUJmFtcDtUPEJSPkxpZ2h0d2F2ZSBOZXR3b3JrcyBSZXNlYXJjaCANCkRlcHQuPEJSPjEwMCBT Y2h1bHogRHJpdmUsIFJvb20gNC0yMTI8QlI+UmVkIEJhbmssIE4uSi4gDQowNzcwMS03MDMzPEJS Pig3MzIpMzQ1LTMyNTU8QlI+amxzQHJlc2VhcmNoLmF0dC5jb20gPC9GT05UPjwvUD48L0RJVj4N CjxCTE9DS1FVT1RFPg0KICAgIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXI+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiANCiAgICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08QlI+PEI+RnJvbTo8L0I+IG93bmVyLW1wbHNAVVUuTkVUIA0KICAgIFttYWlsdG86b3du ZXItbXBsc0BVVS5ORVRdPEI+T24gQmVoYWxmIE9mPC9CPiBDQVRBTlpBUklUSSBTZXJnaW8gDQog ICAgRlRSJmFtcDtEL1RJPEJSPjxCPlNlbnQ6PC9CPiBXZWRuZXNkYXksIE1hcmNoIDE1LCAyMDAw IDE6MTggUE08QlI+PEI+VG86PC9CPiANCiAgICAnQ2hpcCBTaGFycCc8QlI+PEI+Q2M6PC9CPiAn bXBsc0BVVS5ORVQnOyANCiAgICAnaXAtb3B0aWNhbEBsaXN0cy5yZXNlYXJjaC5iZWxsLWxhYnMu Y29tJzxCUj48Qj5TdWJqZWN0OjwvQj4gUkU6IE9wdGljYWwgSVAgDQogICAgYWN0aXZpdGllcyA8 QlI+PEJSPjwvRk9OVD48L0RJVj4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5JIHdh cyBhd2FyZSBvZiB0aGF0LiBJbmRlZWQsIHRoYXQgbWFrZXMgbWUgbW9yZSANCiAgICBjb25mdXNl ZCBhbmQgd29ycmllZC48L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGUgSVRV LVQgKFNHMTU/KSANCiAgICBzZWVtcyB0byBoYXZlIGNvbmNlcm5zIG9uIHdvcmtpbmcgb24gYSBw ZWVyIG1vZGVsIGZvciBhbiBJUCBvdmVyIE9wdGljcyANCiAgICBuZXR3b3JraW5nIGFyY2hpdGVj dHVyZSwgbGVhbmluZyB0b3dhcmRzIGFuIG92ZXJsYXkgc2NlbmFyaW8uIEluIG90aGVyIA0KICAg IHdvcmRzLCB0aGVyZSBhcmUgc29tZSBjb25jZXJucyBhYm91dCBtYWtpbmcgdGhlIE9DaCBsYXll ciB0b3BvbG9neSANCiAgICBpbmZvcm1hdGlvbiByZXZlYWxlZCB0byB0aGUgSVAgc2VydmljZSBj bGllbnQgbGF5ZXIuIDwvRk9OVD48L1A+DQogICAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ T24gdGhlIGNvbnRyYXJ5LCB0aGUgSUVURiBzZWVtcyB0byBnbyBpbiB0aGUgDQogICAgb3RoZXIg ZGlyZWN0aW9uIChhbHRob3VnaCBhIHJlY2VudCBJRVRGIGRyYWZ0LCBJIGJlbGlldmUgZnJvbSBO b3J0ZWwgYW5kIA0KICAgIEx1Y2VudCwgZW5kb3JzZXMgdGhlIHNhbWUgSVRVLVQgY29uY2VybnMp LjwvRk9OVD48L1A+DQogICAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+RnJvbSB0aGUgTVBM UyByZXZpc2VkIGNoYXJ0ZXI6PEk+PC9JPjwvRk9OVD4gPC9QPg0KICAgIDxQPjxJPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+NC4mbmJzcDsgU2ltcGxpZnkgaW50ZWdyYXRpb24gb2Yg DQogICAgcm91dGVycyB3aXRoIG9wdGljYWwgY3Jvc3MtY29ubmVjdCBiYXNlZDwvRk9OVD48Rk9O VCANCiAgICBmYWNlPUFyaWFsPjxCUj48L0ZPTlQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIA0K ICAgIHNpemU9Mj50ZWNobm9sb2dpZXM8L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbD4gPC9GT05UPjwv ST48L1A+DQogICAgPFA+PEk+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj5hKSBtYWtp bmcgb3B0aWNhbCBjcm9zcyBjb25uZWN0cyANCiAgICBiZWhhdmUgYXMgcGVlcnMgdG8gcm91dGVy cyAodGh1czwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsPjxCUj48L0ZPTlQ+PEZPTlQgDQogICAgZmFj ZT0iQ291cmllciBOZXciIHNpemU9Mj5yZWR1Y2luZyB0aGUgbnVtYmVyIG9mIHJvdXRpbmcgcGVl cnMgdGhhdCBhIHJvdXRlciANCiAgICBoYXMgdG8gbWFpbnRhaW4pLDwvRk9OVD48Rk9OVCBmYWNl PUFyaWFsPiA8L0ZPTlQ+PC9JPjwvUD4NCiAgICA8UD48ST48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyIgc2l6ZT0yPmIpIGJ5IG1ha2luZyBpbmZvcm1hdGlvbiBhYm91dCANCiAgICBwaHlzaWNhbCB0 b3BvbG9neSBhdmFpbGFibGUgdG88L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbD48QlI+PC9GT05UPjxG T05UIA0KICAgIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+TmV0d29yayBMYXllciByb3V0aW5n IHByb2NlZHVyZXMsIGFuZDwvRk9OVD48Rk9OVCANCiAgICBmYWNlPUFyaWFsPiA8L0ZPTlQ+PC9J PjwvUD4NCiAgICA8UD48ST48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPmMpIGJ5IGVt cGxveWluZyBjb21tb24gYWRkcmVzc2luZywgDQogICAgcm91dGluZywgYW5kIG1hbmFnZW1lbnQ8 L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbD48QlI+PC9GT05UPjxGT05UIA0KICAgIGZhY2U9IkNvdXJp ZXIgTmV3IiBzaXplPTI+cHJvY2VkdXJlcy48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbD4gDQo8L0ZP TlQ+PC9JPjwvUD4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5JIGd1ZXNzIHRoYXQg aXQgaXMgdG9vIGVhcmx5IHRvIGRlYmF0ZSBtb2RlbCANCiAgICBpc3N1ZXMsIGluIG9yZGVyIHRv IGF2b2lkIElQIG92ZXIgQVRNIG1vZGVsIGRlYmF0ZS1saWtlIGFjdGl2aXRpZXMuPC9GT05UPiAN CiAgICA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+UGVyc29uYWxseSwgSSB3b3VsZCBmaXJz dCB3b3JrIG9uIE9wdGljYWwgSVAgDQogICAgbmV0d29ya2luZyBhcmNoaXRlY3R1cmUgYW5kIGNv bnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzIGRlZmluaXRpb24sIHRoZW4gDQogICAgY2hvb3Npbmcg dGhlIHJpZ2h0IHByb3RvY29sIG1hY2hpbmVyeSAoTVBMUywgWC9ZL1ogcHJvdG9jb2wpLCBhbmQg dWx0aW1hdGVseSANCiAgICBmYWNpbmcgdGhlIG11bHRpLWRpbWVuc2lvbiBtb2RlbCBwcm9ibGVt ICh0b3BvbG9neSBjb21wbGV4aXR5LCBzZXJ2aWNlIGxheWVyIA0KICAgIGNvbmZpZ3VyYXRpb24s IE9BJmFtcDtNIHByb2NlZHVyZXMsIFBNTzwvRk9OVD48ST4gPEZPTlQgZmFjZT1BcmlhbCANCiAg ICBzaXplPTI+c3RhdHVzIHF1bzwvRk9OVD48L0k+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+LCBj b21tZXJjaWFsIA0KICAgIGNvbnNpZGVyYXRpb25zLCBldGMuKTwvRk9OVD48L1A+DQogICAgPFA+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+U2VyZ2lvPC9GT05UPiA8L1A+DQogICAgPFVMPg0KICAg ICAgICA8UD48ST48Rk9OVCBjb2xvcj0jMDAwMDAwIGZhY2U9QXJpYWwgDQogICAgICAgIHNpemU9 Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvRk9OVD48L0k+IA0KICAgICAgICA8QlI+PEk+PEZPTlQgY29sb3I9IzAw MDAwMCBmYWNlPUFyaWFsIHNpemU9Mj5TZXJnaW8gDQogICAgICAgIENhdGFuemFyaXRpPC9GT05U PjwvST4gPEJSPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAgZmFjZT1BcmlhbCANCiAgICAgICAgc2l6 ZT0yPlNlbmlvciBQcm9qZWN0IE1hbmFnZXIsIFRlY2hub2xvZ3kgSW50ZWdyYXRpb248L0ZPTlQ+ PC9JPiANCiAgICAgICAgPEJSPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAgZmFjZT1BcmlhbCBzaXpl PTI+RnJhbmNlIFRlbGVjb20gUiZhbXA7RCANCiAgICAgICAgPC9GT05UPjwvST48QlI+PEk+PEZP TlQgY29sb3I9IzAwMDAwMCBmYWNlPUFyaWFsIHNpemU9Mj4xMDAwIE1hcmluYSANCiAgICAgICAg Qm91bGV2YXJkIFN1aXRlIDMwMCA8L0ZPTlQ+PC9JPjxCUj48ST48Rk9OVCBjb2xvcj0jMDAwMDAw IGZhY2U9QXJpYWwgDQogICAgICAgIHNpemU9Mj5CcmlzYmFuZSBDQSA5NDAwNTwvRk9OVD48L0k+ IDxCUj48ST48Rk9OVCBjb2xvcj0jMDAwMDAwIA0KICAgICAgICBmYWNlPUFyaWFsIHNpemU9Mj5U ZWwuIDY1MC04NzUtMTUyNjwvRk9OVD48L0k+IDxCUj48ST48Rk9OVCANCiAgICAgICAgY29sb3I9 IzAwMDAwMCBmYWNlPUFyaWFsIHNpemU9Mj5GYXguIDY1MC04NzUtMTUwNTwvRk9OVD48L0k+IA0K ICAgICAgICA8QlI+PEk+PEZPTlQgY29sb3I9IzAwMDAwMCBmYWNlPUFyaWFsIA0KICAgICAgICBz aXplPTI+ZW1haWw6c2VyZ2lvLmNhdGFuemFyaXRpQHJkLmZyYW5jZXRlbGVjb20uY29tIA0KICAg ICAgICA8L0ZPTlQ+PC9JPjxCUj48ST48Rk9OVCBjb2xvcj0jMDAwMDAwIGZhY2U9QXJpYWwgDQog ICAgICAgIHNpemU9Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRk9OVD48L0k+IA0KICAgICAgICA8L1A+PEJSPg0K ICAgICAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9MT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTwvRk9OVD4gDQogICAgICAgIDxCUj48Qj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9MT5Gcm9t OiZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxGT05UIA0KICAgICAgICBmYWNlPUFyaWFsIHNpemU9 MT5DaGlwIFNoYXJwIFtTTVRQOmNoc2hhcnBAY2lzY28uY29tXTwvRk9OVD4gDQogICAgICAgIDxC Uj48Qj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9MT5TZW50OiZuYnNwOyZuYnNwOzwvRk9OVD48L0I+ IDxGT05UIA0KICAgICAgICBmYWNlPUFyaWFsIHNpemU9MT5XZWRuZXNkYXksIE1hcmNoIDE1LCAy MDAwIDk6NDUgQU08L0ZPTlQ+IDxCUj48Qj48Rk9OVCANCiAgICAgICAgZmFjZT1BcmlhbCBzaXpl PTE+VG86Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvQj4gPEZPTlQgDQogICAgICAg IGZhY2U9QXJpYWwgc2l6ZT0xPkNBVEFOWkFSSVRJIFNlcmdpbyBGVFImYW1wO0QvVEk7IA0KICAg ICAgICAnaXAtb3B0aWNhbEBsaXN0cy5yZXNlYXJjaC5iZWxsLWxhYnMuY29tJzwvRk9OVD4gPEJS PjxCPjxGT05UIGZhY2U9QXJpYWwgDQogICAgICAgIHNpemU9MT5DYzombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgICBzaXplPTE+J21w bHNAVVUuTkVUJzwvRk9OVD4gPEJSPjxCPjxGT05UIGZhY2U9QXJpYWwgDQogICAgICAgIHNpemU9 MT5TdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRk9O VD48L0I+IA0KICAgICAgICA8Rk9OVCBmYWNlPUFyaWFsIHNpemU9MT5SZTogT3B0aWNhbCBJUCBh Y3Rpdml0aWVzIDwvRk9OVD48L1A+DQogICAgICAgIDxQPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 IiBzaXplPTI+RllJLDwvRk9OVD4gPEJSPjxGT05UIA0KICAgICAgICBmYWNlPSJDb3VyaWVyIE5l dyIgc2l6ZT0yPkl0IGxvb2tzIGxpa2UgdGhlIElUVSAoU0cgMTMsIFNHMTUgYW5kIA0KICAgICAg ICBwb3NzaWJseSBTRzExKSBtYXkgYmUgZ2V0dGluZyBpbnRvIDwvRk9OVD48QlI+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciIA0KICAgICAgICBzaXplPTI+dGhpcyBhcmVhIGFzIHdlbGwuJm5ic3A7 IEF0IHRoZSBTRzEzIG1lZXRpbmcgaW4gS3lvdG8sIHRoZXJlIHdhcyANCiAgICAgICAgc29tZSBk aXNjdXNzaW9uIDwvRk9OVD48QlI+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj5vZiB0 aGlzIA0KICAgICAgICB0b3BpYy4mbmJzcDsgVGhleSBhcmUgZGVmaW5pdGVseSB3b3JraW5nIG9u IG5leHQtZ2VuIG9wdGljYWwgbmV0d29ya2luZyANCiAgICAgICAgPC9GT05UPjxCUj48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPmlzc3Vlcy48L0ZPTlQ+IDwvUD4NCiAgICAgICAgPFA+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj5DaGlwPC9GT05UPiA8L1A+DQogICAgICAg IDxQPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+QXQgMDU6MjMgUE0gMy8xNC8wMCAt MDgwMCwgDQogICAgICAgIENBVEFOWkFSSVRJIFNlcmdpbyBGVFImYW1wO0QvVEkgd3JvdGU6PC9G T05UPiA8L1A+DQogICAgICAgIDxQPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+Jmd0 O1RvZGF5IEkgd2FzIHJlYWRpbmcgdGhlIE1QTFMgDQogICAgICAgIHJldmlzZWQgY2hhcnRlciBz ZW50IGJ5IFZpamF5IGFuZCBJIGhhdmUgPC9GT05UPjxCUj48Rk9OVCANCiAgICAgICAgZmFjZT0i Q291cmllciBOZXciIHNpemU9Mj4mZ3Q7Zm91bmQgb3B0aWNhbCBJUCByZWxhdGVkIGFjdGl2aXRp ZXMsIGxpa2UgDQogICAgICAgIHRoYXQ6PC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciIHNpemU9Mj4mZ3Q7PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICAgIGZhY2U9IkNvdXJpZXIg TmV3IiBzaXplPTI+Jmd0OzYuJm5ic3A7IFNwZWNpZnkgZXh0ZW5zaW9ucyB0byB0aGUgDQogICAg ICAgIHByb3RvY29scyBhbmQgcHJvY2VkdXJlcyB1c2VkIGZvcjwvRk9OVD4gPEJSPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3IiANCiAgICAgICAgc2l6ZT0yPiZndDtzaWduYWxpbmcgZXhwbGljaXQg cm91dGVzIGFuZCB0byBlZmZlY3QgZmFzdCByZWNvdmVyeSBvZiANCiAgICAgICAgTFNQczwvRk9O VD4gPEJSPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+Jmd0O2ZvciB1c2UgaW4gT3B0 aWNhbCANCiAgICAgICAgQ3Jvc3MgQ29ubmVjdHMuPC9GT05UPiA8QlI+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciIHNpemU9Mj4mZ3Q7PC9GT05UPiANCiAgICAgICAgPEJSPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3IiBzaXplPTI+Jmd0O05vdywgcmVhZGluZyBmcm9tIHRoZSBJUCBvdmVyIA0KICAg ICAgICBPcHRpY2FsIEJvRiBkZXNjcmlwdGlvbiwgSSBmaW5kOjwvRk9OVD4gPEJSPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3IiANCiAgICAgICAgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPiZndDstIE1vZGlmeWluZyANCiAgICAgICAgZXhpc3Rp bmcgSVAgYW5kIE1QTFMgcm91dGluZyBhbmQgY29ubmVjdGlvbiBzaWduYWxpbmc8L0ZPTlQ+IDxC Uj48Rk9OVCANCiAgICAgICAgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj4mZ3Q7Jm5ic3A7Jm5i c3A7IHByb3RvY29sczwvRk9OVD4gPEJSPjxGT05UIA0KICAgICAgICBmYWNlPSJDb3VyaWVyIE5l dyIgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgDQogICAg ICAgIHNpemU9Mj4mZ3Q7SSBrbm93IHRoYXQgaXQgaXMgc3RpbGwgcHJldHR5IG11Y2ggaW1tYXR1 cmUgdG8gdGFsayBhYm91dCANCiAgICAgICAgcmVzdWx0cyBvZiB0aGUgPC9GT05UPjxCUj48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPiZndDt1cGNvbWluZyANCiAgICAgICAgSVAgb3Zl ciBPcHRpY2FsIEJvRiwgYnV0IGhvdyB3aWxsIGFuIGV2ZW50dWFsIFdHIGNvbWluZyBvdXQgZnJv bSANCiAgICAgICAgPC9GT05UPjxCUj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPiZn dDt0aGlzIEJvRiByZWNvbmNpbGUgd2l0aCANCiAgICAgICAgdGhlIE1QTFMgV0cgYWN0aXZpdHkg aW4gdGhlIE9wdGljYWwgSVAgYXJlbmE/PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICAgIGZhY2U9 IkNvdXJpZXIgTmV3IiBzaXplPTI+Jmd0OzwvRk9OVD4gPEJSPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3IiANCiAgICAgICAgc2l6ZT0yPiZndDtCeSB3b3JraW5nIG9uIGEgZ2VuZXJpYyBjb250cm9s IHBsYW5lIGFyY2hpdGVjdHVyZSBhbmQgDQogICAgICAgIHJlcXVpcmVtZW50cyA8L0ZPTlQ+PEJS PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+Jmd0O2RlZmluaXRpb24sIA0KICAgICAg ICBhbmQgbGVhdmluZyBvdXQgdG8gdGhlIE1QTFMgV0cgc3BlY2lmaWMgd29yayBvbiB0aGUgZ2Vu ZXJpYyANCiAgICAgICAgPC9GT05UPjxCUj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0y PiZndDttZWNoYW5pc21zIGFuZCBwcm9jZWR1cmUgDQogICAgICAgIGZvciBhbiBNUExTIGltcGxl bWVudGF0aW9uIG9mIGFuIE9wdGljYWwgSVAgPC9GT05UPjxCUj48Rk9OVCANCiAgICAgICAgZmFj ZT0iQ291cmllciBOZXciIHNpemU9Mj4mZ3Q7Y29udHJvbCBwbGFuZT8gSXMgdGhpcyBhIHBvc3Np YmxlIA0KICAgICAgICBpbnRyYS1JRVRGIGFjdGl2aXR5IHNjZW5hcmlvPyBXaGljaCBvdGhlcnM/ PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICAgIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+Jmd0 OzwvRk9OVD4gPEJSPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCiAgICAgICAgc2l6ZT0yPiZn dDtMb29raW5nIGZvciBhIGJyaWVmIGFuZCByb3VnaCBoaW50LjwvRk9OVD4gPEJSPjxGT05UIA0K ICAgICAgICBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyIgDQogICAgICAgIHNpemU9Mj4mZ3Q7VGhhbmtzLDwvRk9OVD4gPEJS PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCiAgICAgICAgc2l6ZT0yPiZndDtTZXJnaW88L0ZP TlQ+IDxCUj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgDQogICAgICAgIHNpemU9Mj4mZ3Q7LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gDQogICAgICAgIDwvRk9OVD48QlI+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNp emU9Mj4mZ3Q7U2VyZ2lvIENhdGFuemFyaXRpJm5ic3A7IA0KICAgICAgICBTZW5pb3IgUHJvamVj dCBNYW5hZ2VyLCBUZWNobm9sb2d5IEludGVncmF0aW9uJm5ic3A7IEZyYW5jZSANCiAgICAgICAg PC9GT05UPjxCUj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPiZndDtUZWxlY29tIFIm YW1wO0QmbmJzcDsgDQogICAgICAgIDEwMDAgTWFyaW5hIEJvdWxldmFyZCBTdWl0ZSAzMDAmbmJz cDsgQnJpc2JhbmUgQ0EgOTQwMDUmbmJzcDsgVGVsLiANCiAgICAgICAgPC9GT05UPjxCUj48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPiZndDs2NTAtODc1LTE1MjYmbmJzcDsgRmF4LiAN CiAgICAgICAgPC9GT05UPjxCUj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPiZndDs2 NTAtODc1LTE1MDUmbmJzcDsgDQogICAgICAgIGVtYWlsOnNlcmdpby5jYXRhbnphcml0aUByZC5m cmFuY2V0ZWxlY29tLmNvbSA8L0ZPTlQ+PEJSPjxGT05UIA0KICAgICAgICBmYWNlPSJDb3VyaWVy IE5ldyIgDQogICAgICAgIHNpemU9Mj4mZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0ZPTlQ+IA0KICAgICAgICA8 L1A+DQogICAgICAgIDxQPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+U3VwcG9ydCBO ZXRBaWQhJm5ic3A7PFU+IA0KICAgICAgICA8L1U+PC9GT05UPjxVPjxGT05UIGNvbG9yPSMwMDAw ZmYgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48QSANCiAgICAgICAgaHJlZj0iaHR0cDovL3d3 dy5uZXRhaWQub3JnIiANCiAgICAgICAgdGFyZ2V0PV9ibGFuaz5odHRwOi8vd3d3Lm5ldGFpZC5v cmc8L0E+PC9GT05UPjwvVT4gPEJSPjxGT05UIA0KICAgICAgICBmYWNlPSJDb3VyaWVyIE5ldyIg DQogICAgICAgIHNpemU9Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTwvRk9OVD4gDQogICAgICAgIDxCUj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIg c2l6ZT0yPkNoaXAgDQogICAgICAgIFNoYXJwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICAgICAgICBDb25zdWx0aW5nIEVuZ2luZWVyaW5nPC9GT05UPiA8QlI+PEZP TlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj5DaXNjbyANCiAgICAgICAgU3lzdGVtcyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICAgVGVsY28gQmlvLXJlZ2lvbjwvRk9OVD4gPEJSPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+UmVhbGl0eSAtIA0KICAgICAgICBMb3ZlIGl0 IG9yIExlYXZlIGl0LiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQogICAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L0ZPTlQ+PEJSPjxGT05UIA0KICAgICAgICBmYWNlPSJDb3VyaWVyIE5ldyIgDQogICAgICAg IHNpemU9Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTwvRk9OVD4gDQo8L1A+PC9VTD48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_00CF_01BF8F31.2072FF00-- From owner-mpls@UU.NET Thu Mar 16 10:41:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18462 for ; Thu, 16 Mar 2000 10:41:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigty15860; Thu, 16 Mar 2000 15:41:15 GMT Received: by mail-control.mail.uu.net id QQigty06150 for mpls-outgoing; Thu, 16 Mar 2000 15:40:41 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigty06143 for ; Thu, 16 Mar 2000 15:40:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigty26922 for ; Thu, 16 Mar 2000 10:38:40 -0500 (EST) Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQigty13210 for ; Thu, 16 Mar 2000 15:38:40 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id JAA16839; Thu, 16 Mar 2000 09:38:38 -0600 (CST) Received: from vsharma ([172.31.101.69] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA13702; Thu, 16 Mar 2000 09:38:38 -0600 (CST) Received: by localhost with Microsoft MAPI; Thu, 16 Mar 2000 10:42:15 -0500 Message-ID: <01BF8F34.4B5EAB30.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'jls@research.att.com'" , "sergio.catanzariti@rd.francetelecom.com" , "chsharp@cisco.com" Cc: "mpls@UU.NET" Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 10:42:13 -0500 Organization: Tellabs Research Center X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit John, I'd like to second this view. You might also want to check out some of the concerns I posted to the list that relate to the limitation in the charter/scope that you mention below, and that tries to argue for a more precise defition of "optical crossconnects" to begin with. Regards, -Vishal On Thursday, March 16, 2000 10:20 AM, jls@research.att.com [SMTP:jls@research.att.com] wrote: > I'd like to reinforce these concerns. It seems to me that defining the scope > of this work to cover only peer-to-peer models > of router/OXC interactions would drastically limit its value in the short-to- > medium term at least. Similarly with disclosure > of physical topology information. Recent OIF contributions from many of the > principal players suggest that further study > of these issues before limiting work to a single model is needed, as does > draft-rstb-optical-signaling-framework-00.txt. > > John > John Strand > AT&T > Lightwave Networks Research Dept. > 100 Schulz Drive, Room 4-212 > Red Bank, N.J. 07701-7033 > (732)345-3255 > jls@research.att.com > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of CATANZARITI > Sergio FTR&D/TI > Sent: Wednesday, March 15, 2000 1:18 PM > To: 'Chip Sharp' > Cc: 'mpls@UU.NET'; 'ip-optical@lists.research.bell-labs.com' > Subject: RE: Optical IP activities > > > I was aware of that. Indeed, that makes me more confused and worried. > The ITU-T (SG15?) seems to have concerns on working on a peer model for an > IP over Optics networking architecture, leaning towards an overlay scenario. > In other words, there are some concerns about making the OCh layer topology > information revealed to the IP service client layer. > > On the contrary, the IETF seems to go in the other direction (although a > recent IETF draft, I believe from Nortel and Lucent, endorses the same ITU-T > concerns). > > From the MPLS revised charter: > > 4. Simplify integration of routers with optical cross-connect based > technologies > > a) making optical cross connects behave as peers to routers (thus > reducing the number of routing peers that a router has to maintain), > > b) by making information about physical topology available to > Network Layer routing procedures, and > > c) by employing common addressing, routing, and management > procedures. > > I guess that it is too early to debate model issues, in order to avoid IP > over ATM model debate-like activities. > Personally, I would first work on Optical IP networking architecture and > control plane requirements definition, then choosing the right protocol > machinery (MPLS, X/Y/Z protocol), and ultimately facing the multi-dimension > model problem (topology complexity, service layer configuration, OA&M > procedures, PMO status quo, commercial considerations, etc.) > > Sergio > > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@cisco.com] > Sent: Wednesday, March 15, 2000 9:45 AM > To: CATANZARITI Sergio FTR&D/TI; 'ip-optical@lists.research.bell- > labs.com' > Cc: 'mpls@UU.NET' > Subject: Re: Optical IP activities > > FYI, > It looks like the ITU (SG 13, SG15 and possibly SG11) may be getting > into > this area as well. At the SG13 meeting in Kyoto, there was some > discussion > of this topic. They are definitely working on next-gen optical > networking > issues. > > Chip > > At 05:23 PM 3/14/00 -0800, CATANZARITI Sergio FTR&D/TI wrote: > > >Today I was reading the MPLS revised charter sent by Vijay and I have > > > >found optical IP related activities, like that: > > > >6. Specify extensions to the protocols and procedures used for > >signaling explicit routes and to effect fast recovery of LSPs > >for use in Optical Cross Connects. > > > >Now, reading from the IP over Optical BoF description, I find: > > > > >- Modifying existing IP and MPLS routing and connection signaling > > protocols > > > >I know that it is still pretty much immature to talk about results of > >the > >upcoming IP over Optical BoF, but how will an eventual WG coming out > >from > >this BoF reconcile with the MPLS WG activity in the Optical IP arena? > > > > > >By working on a generic control plane architecture and requirements > >definition, and leaving out to the MPLS WG specific work on the > >generic > >mechanisms and procedure for an MPLS implementation of an Optical IP > > > >control plane? Is this a possible intra-IETF activity scenario? Which > >others? > > > >Looking for a brief and rough hint. > > > >Thanks, > >Sergio > >-------------------------------------------------------------------- > > > >Sergio Catanzariti Senior Project Manager, Technology Integration > > France > >Telecom R&D 1000 Marina Boulevard Suite 300 Brisbane CA 94005 Tel. > > > >650-875-1526 Fax. > >650-875-1505 email:sergio.catanzariti@rd.francetelecom.com > >-------------------------------------------------------------------- > > > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > > << File: ATT00001.html >> From owner-mpls@UU.NET Thu Mar 16 10:47:36 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20684 for ; Thu, 16 Mar 2000 10:47:35 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigtz26087; Thu, 16 Mar 2000 15:47:34 GMT Received: by mail-control.mail.uu.net id QQigtz06828 for mpls-outgoing; Thu, 16 Mar 2000 15:47:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigtz06823 for ; Thu, 16 Mar 2000 15:47:02 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigtz23611 for ; Thu, 16 Mar 2000 10:46:26 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigtz21539 for ; Thu, 16 Mar 2000 15:46:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA13788 for mpls@uu.net; Thu, 16 Mar 2000 10:46:24 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigtz06701 for ; Thu, 16 Mar 2000 15:45:59 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigtz23418 for ; Thu, 16 Mar 2000 10:45:38 -0500 (EST) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQigtz20540 for ; Thu, 16 Mar 2000 15:45:37 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA10354; Thu, 16 Mar 2000 07:45:28 -0800 (PST) Message-Id: <200003161545.HAA10354@omega.cisco.com> To: jls@research.att.com cc: "'CATANZARITI Sergio FTR&D/TI'" , "'Chip Sharp'" , mpls@UU.NET Subject: Re: Optical IP activities In-reply-to: Your message of "Thu, 16 Mar 2000 10:19:33 EST." <00ce01bf8f5b$09490700$3e82cf87@pcstranded.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10349.953221528.1@cisco.com> Date: Thu, 16 Mar 2000 07:45:28 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk John, > I'd like to reinforce these concerns. It seems to me that defining the > scope of this work to cover only peer-to-peer models of router/OXC > interactions would drastically limit its value in the short-to-medium > term at least. Similarly with disclosure of physical topology > information. Recent OIF contributions from many of the principal > players suggest that further study of these issues before limiting work > to a single model is needed, as does draft > draft-rstb-optical-signaling-framework-00.txt. I would assume that the same control plane based on MPLS TE could be used to support both the peer and the overlay model (as well as a mixture of both). With this in mind I would suggest that the MPLS WG should focus on defining the extension to the current MPLS TE protocols (ISIS, OSPF, RSVP, CR-LDP) to handle Optical LSRs and SDH-LSRs. Yakov. From owner-mpls@UU.NET Thu Mar 16 11:10:49 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28890 for ; Thu, 16 Mar 2000 11:10:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigua19544; Thu, 16 Mar 2000 16:10:49 GMT Received: by mail-control.mail.uu.net id QQigua16155 for mpls-outgoing; Thu, 16 Mar 2000 16:10:07 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigua16111 for ; Thu, 16 Mar 2000 16:09:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigua02942 for ; Thu, 16 Mar 2000 11:09:49 -0500 (EST) Received: from albatross.wise.edt.ericsson.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQigua18539 for ; Thu, 16 Mar 2000 16:09:48 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id RAA03565 for ; Thu, 16 Mar 2000 17:00:20 +0100 (MET) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id RAA22622 for ; Thu, 16 Mar 2000 17:03:02 +0100 (MET) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FRI00H41V92TY@mbb1.ericsson.se> for mpls@UU.NET; Thu, 16 Mar 2000 17:03:02 +0100 (MET) Date: Thu, 16 Mar 2000 17:02:25 +0100 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: problems compiling LSR MIB v2 - NOT! To: Cheenu Srinivasan Cc: mpls@UU.NET, "'swallow@cisco.com'" , "Thomas D. Nadeau" , arun@force10networks.com Message-id: <38D10591.74DF447A@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en References: <633D356A20D0D311BBC1009027DC856C0260D5@TNNT3> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8BIT I provided the compile information for your information. You could of course treat that information in two ways. Either you throw it back and blame something else (in this case my compile environment), or you consider it and update the mib. My opinion (and my compilers) are that the LSR MIB got errors - Counter32 are different from counter64! The whole purpuse of mplsInSegmentHCOctets is to be counter64. An easy change. - All object needs to be part of a GROUP. The objects I listed aren't. I guess you should put them in the appropriate groups. For some reason a } disapered in my file, which rendered a third error. Thats entirely on me. My proposal is that you update according to the remarks, and maybe use a more stringent mode on MOSY then I guess the mib would pass a lot more compilers than previously. /// Hasse Cheenu Srinivasan wrote: > > I just pulled down the latest version of the LSR MIB from > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-02.txt > and compiled that (not my local copy), generated code etc. It > went through without a hitch; output trace is attached below. > > Of course, we went through this process _before_ we posted the > MIB, and made sure all was kosher. > > Perhaps there's a problem with your compiler/environment. > > Cheenu > > % premosy draft-ietf-mpls-lsr-mib-02.txt MPLS-LSR-MIB.my > % mosy MPLS-LSR-MIB.my > mosy 7.1 #1 (starship) of Sat Dec 13 18:23:09 EST 1997 > MPLS-LSR-MIB modules: mplsLsrMIB > > MPLS-LSR-MIB conventions: MplsLSPID MplsLsrIANAAddrFamily MplsLabel > Ipv6Address > MplsBitRate MplsBurstSize MplsBufferSize > > MPLS-LSR-MIB identifiers: mplsLsrObjects mplsLsrNotifications > mplsLsrConformance > > MPLS-LSR-MIB objects: mplsInterfaceConfTable mplsInterfaceConfEntry > > MPLS-LSR-MIB types: MplsInterfaceConfEntry > > MPLS-LSR-MIB objects: mplsInterfaceConfIndex mplsInterfaceLabelMinIn > mplsInterfaceLabelMaxIn mplsInterfaceLabelMinOut > mplsInterfaceLabelMaxOut mplsInterfaceTotalBandwidth > mplsInterfaceAvailableBandwidth mplsInterfaceTotalBuffer > mplsInterfaceAvailableBuffer mplsInterfaceIsGlobalLabelSpace > mplsInterfaceIsLocalLabelSpace mplsInterfaceAdminStatus > mplsInterfaceOperStatus mplsInterfacePerfTable > mplsInterfacePerfEntry > > MPLS-LSR-MIB types: MplsInterfacePerfEntry > > MPLS-LSR-MIB objects: mplsInterfaceInLabelsUsed mplsInterfaceInPackets > mplsInterfaceInDiscards mplsInterfaceFailedLabelLookup > mplsInterfaceOutLabelsUsed mplsInterfaceOutPackets > mplsInterfaceOutDiscards mplsInterfaceOutFragments > mplsInSegmentTable mplsInSegmentEntry > > MPLS-LSR-MIB types: MplsInSegmentEntry > > MPLS-LSR-MIB objects: mplsInSegmentIfIndex mplsInSegmentLabel > mplsInSegmentNPop > mplsInSegmentAddrFamily mplsInSegmentXCIndex > mplsInSegmentTSpecIndex mplsInSegmentOwner > mplsInSegmentAdminStatus mplsInSegmentOperStatus > mplsInSegmentRowStatus mplsInSegmentPerfTable > mplsInSegmentPerfEntry > > MPLS-LSR-MIB types: MplsInSegmentPerfEntry > > MPLS-LSR-MIB objects: mplsInSegmentOctets mplsInSegmentPackets > mplsInSegmentErrors mplsInSegmentDiscards mplsInSegmentHCOctets > mplsOutSegmentIndexNext mplsOutSegmentTable mplsOutSegmentEntry > > MPLS-LSR-MIB types: MplsOutSegmentEntry > > MPLS-LSR-MIB objects: mplsOutSegmentIndex mplsOutSegmentIfIndex > mplsOutSegmentPushTopLabel mplsOutSegmentTopLabel > mplsOutSegmentNextHopIpAddrType mplsOutSegmentNextHopIpv4Addr > mplsOutSegmentNextHopIpv6Addr mplsOutSegmentXCIndex > mplsOutSegmentTSpecIndex mplsOutSegmentOwner > mplsOutSegmentAdminStatus mplsOutSegmentOperStatus > mplsOutSegmentRowStatus mplsOutSegmentPerfTable > mplsOutSegmentPerfEntry > > MPLS-LSR-MIB types: MplsOutSegmentPerfEntry > > MPLS-LSR-MIB objects: mplsOutSegmentOctets mplsOutSegmentPackets > mplsOutSegmentErrors mplsOutSegmentDiscards > mplsOutSegmentHCOctets > mplsXCIndexNext mplsXCTable mplsXCEntry > > MPLS-LSR-MIB types: MplsXCEntry > > MPLS-LSR-MIB objects: mplsXCIndex mplsXCLspId mplsXCLabelStackIndex > mplsXCCOS > mplsXCIsPersistent mplsXCOwner mplsXCAdminStatus > mplsXCOperStatus > mplsXCRowStatus mplsMaxLabelStackDepth mplsLabelStackIndexNext > mplsLabelStackTable mplsLabelStackEntry > > MPLS-LSR-MIB types: MplsLabelStackEntry > > MPLS-LSR-MIB objects: mplsLabelStackIndex mplsLabelStackLabelIndex > mplsLabelStackLabel mplsLabelStackRowStatus mplsTSpecIndexNext > mplsTSpecTable mplsTSpecEntry > > MPLS-LSR-MIB types: MplsTSpecEntry > > MPLS-LSR-MIB objects: mplsTSpecIndex mplsTSpecMaxRate mplsTSpecMeanRate > mplsTSpecMaxBurstSize mplsTSpecRowStatus > mplsInterfaceTrapEnable > mplsInSegmentTrapEnable mplsOutSegmentTrapEnable > mplsXCTrapEnable > > MPLS-LSR-MIB traps: mplsInterfaceUp mplsInterfaceDown mplsInSegmentUp > mplsInSegmentDown mplsOutSegmentUp mplsOutSegmentDown mplsXCUp > mplsXCDown > > MPLS-LSR-MIB identifiers: mplsLsrGroups mplsLsrCompliances > > MPLS-LSR-MIB compliances: mplsLsrModuleCompliance > > MPLS-LSR-MIB groups: mplsInterfaceGroup mplsInSegmentGroup > mplsOutSegmentGroup > mplsXCGroup mplsPerfGroup mplsHCInSegmentPerfGroup > mplsHCOutSegmentPerfGroup mplsTSpecGroup > mplsXCIsPersistentGroup > mplsXCIsNotPersistentGroup mplsLsrNotificationGroup > % > > > -----Original Message----- > > From: Hans Sjöstrand [mailto:hans.sjostrand@etx.ericsson.se] > > Sent: Wednesday, March 15, 2000 2:19 PM > > To: Thomas D. Nadeau > > Cc: mpls@UU.NET; Cheenu Srinivasan; arun@force10networks.com > > Subject: Re: LSR MIB WG Last Call > > > > > > "Thomas D. Nadeau" wrote: > > > > > > Hi Hans, > > > > > > > I would like to know why you have "issued a last call? > > > > > > I did not issue a last call, as I cannot, nor > > > was it my intention to do so. The intent of my first > > > message to George and Vijay was to ask for a WG Last Call > > > on the MIB. My second message was referring to this > > > request, not declare a last call. I apologize for the > > > confusion. > > > > Thanks Tom for the clarification on your last call. You > > certanly fooled me and a lot of others I think. > > > > > > > > > It almost ridiculous to say > > > > something like that when it doesn't even compile! > > > > The main point wasn't that it didn't compile, but after > > finding several errors in it I draw the conclusion that it > > didn't go near a compiler. Maybe I was premature in > > my conclusion. For me it was just another > > indicator that there is some more work on this before it's > > mature. > > > > > > > > We compiled the current version with SMIC prior > > > to releasing it. What are you compiling it with? > > > Please provide me with your compilation errors > > > so that I can look into this ASAP. > > > > FYI, but as I said, those are editorials. > > > > MPLS-LSR-MIB.mib: 774: Error: syntax error before: mplsInSegmentOctets > > {error,compilation_failed} > > > > -- Then I fixed that to get further > > MPLS-LSR-MIB.mib: 813: Error: Types for mplsInSegmentHCOctets differs > > from the SEQUENCE definition. > > {error,compilation_failed} > > > > -- Then I fixed that to get further > > MPLS-LSR-MIB.mib: Error: 'mplsTSpecIndexNext' missing in OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackRowStatus' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackLabel' missing in OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackIndex' missing in OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackIndexNext' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsMaxLabelStackDepth' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsXCOwner' missing in OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsXCCOS' missing in OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsXCLspId' missing in OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsOutSegmentErrors' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInSegmentErrors' missing in OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceOutFragments' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceFailedLabelLookup' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceAvailableBuffer' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceTotalBuffer' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceAvailableBandwidth' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceTotalBandwidth' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsOutSegmentDown' missing in > > NOTIFICATION-GROUP > > {error,compilation_failed} > > > > -- then I gave up > > > > > > > > > The only thing you create is confusion, hopefully that > > > > isn't the goal of the exercise. But what was your purpuse? > > > > > > Of course not. My purpose was to ask for a last call > > > and nothing else. > > > > > > --Tom > > > > > > > /// Hasse > > > > > > > > "Thomas D. Nadeau" wrote: > > > > > > > > > > > > > > > Please do give comments if there are any. > > > > > The WG Last Call should not preclude that. The > > > > > reason why we decided to go WGLC at this point > > > > > was that even during the last round of reviewed > > > > > comments (most were from you in fact), the comments > > > > > were relatively minor. We feel that the MIB is pretty > > > > > solid and mature at this point. > > > > > > > > > > --Tom > > > > > > > > > > > Your latest version is dated 6th March. > > > > > > It is now 14th. > > > > > > > > > > > > I think it reasonable to give us all a little time to > > read your > > > > work > > > > > > after > > > > > > all of the effort you have put into it. > > > > > > > > > > > > Adrian > > > > > > -- > > > > > > Adrian Farrel mailto:af@datcon.co.uk > > > > > > ATM, MPLS and Telecoms Development Group > > > > > > Data Connection Ltd., Chester, UK > > > > > > http://www.datcon.co.uk/ > > > > > > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > > >Sent: Tuesday, March 14, 2000 10:49 PM > > > > > > >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan > > > > > > >Cc: Cheenu Srinivasan; arun@force10networks.com > > > > > > >Subject: LSR MIB WG Last Call > > > > > > > > > > > > > > > > > > > > > > > > > > > > Since we have not received any additional comments > > > > > > >on the current version of the LSR MIB, we would like > > > > > > >to raise the document to WG Last Call. > > > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Mar 16 11:14:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00514 for ; Thu, 16 Mar 2000 11:14:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigua25596; Thu, 16 Mar 2000 16:14:39 GMT Received: by mail-control.mail.uu.net id QQigua16421 for mpls-outgoing; Thu, 16 Mar 2000 16:14:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigua16411 for ; Thu, 16 Mar 2000 16:13:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigua28815 for ; Thu, 16 Mar 2000 11:13:39 -0500 (EST) Received: from lumen.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: magic03.kudonet.com [209.133.127.227]) id QQigua22130 for ; Thu, 16 Mar 2000 16:13:39 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Mar 2000 08:16:12 -0800 Message-ID: From: John Drake To: "'Yakov Rekhter'" , jls@research.att.com Cc: "'CATANZARITI Sergio FTR&D/TI'" , "'Chip Sharp'" , mpls@UU.NET Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 08:16:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The Awduche draft, which provided the impetus for the MPL(ambda)S work, specificaly states that both the overlay model, as well as the peer model, will be supported. Further, neither the ODSI nor the OIF are currently working to define the control plane for a network of OXCs (or PXCs), so it doesn't seem as though there are overlapping activities. John -----Original Message----- From: Yakov Rekhter [mailto:yakov@cisco.com] Sent: Thursday, March 16, 2000 7:45 AM To: jls@research.att.com Cc: 'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp'; mpls@UU.NET Subject: Re: Optical IP activities John, > I'd like to reinforce these concerns. It seems to me that defining the > scope of this work to cover only peer-to-peer models of router/OXC > interactions would drastically limit its value in the short-to-medium > term at least. Similarly with disclosure of physical topology > information. Recent OIF contributions from many of the principal > players suggest that further study of these issues before limiting work > to a single model is needed, as does draft > draft-rstb-optical-signaling-framework-00.txt. I would assume that the same control plane based on MPLS TE could be used to support both the peer and the overlay model (as well as a mixture of both). With this in mind I would suggest that the MPLS WG should focus on defining the extension to the current MPLS TE protocols (ISIS, OSPF, RSVP, CR-LDP) to handle Optical LSRs and SDH-LSRs. Yakov. From owner-mpls@UU.NET Thu Mar 16 11:16:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01272 for ; Thu, 16 Mar 2000 11:16:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigub28134; Thu, 16 Mar 2000 16:16:28 GMT Received: by mail-control.mail.uu.net id QQigub16648 for mpls-outgoing; Thu, 16 Mar 2000 16:15:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigub16643 for ; Thu, 16 Mar 2000 16:15:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigub29059 for ; Thu, 16 Mar 2000 11:15:11 -0500 (EST) Received: from kickme.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kickme.cisco.com [198.92.30.42]) id QQigub24086 for ; Thu, 16 Mar 2000 16:15:10 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA04124 for ; Thu, 16 Mar 2000 08:02:49 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA02332 for mpls@uu.net; Thu, 16 Mar 2000 11:14:58 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigtw04478 for ; Thu, 16 Mar 2000 15:12:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigtw15579 for ; Thu, 16 Mar 2000 10:12:13 -0500 (EST) Received: from tnnt3.tachion.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQigtw12831 for ; Thu, 16 Mar 2000 15:12:12 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 10:13:21 -0500 Message-ID: <633D356A20D0D311BBC1009027DC856C0260D5@TNNT3> From: Cheenu Srinivasan To: =?iso-8859-1?Q?=27Hans_Sj=F6strand=27?= , mpls@UU.NET, "'swallow@cisco.com'" Cc: "Thomas D. Nadeau" , arun@force10networks.com Subject: problems compiling LSR MIB v2 - NOT! Date: Thu, 16 Mar 2000 10:13:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I just pulled down the latest version of the LSR MIB from http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-02.txt and compiled that (not my local copy), generated code etc. It went through without a hitch; output trace is attached below. Of course, we went through this process _before_ we posted the MIB, and made sure all was kosher. Perhaps there's a problem with your compiler/environment. Cheenu % premosy draft-ietf-mpls-lsr-mib-02.txt MPLS-LSR-MIB.my % mosy MPLS-LSR-MIB.my mosy 7.1 #1 (starship) of Sat Dec 13 18:23:09 EST 1997 MPLS-LSR-MIB modules: mplsLsrMIB MPLS-LSR-MIB conventions: MplsLSPID MplsLsrIANAAddrFamily MplsLabel Ipv6Address MplsBitRate MplsBurstSize MplsBufferSize MPLS-LSR-MIB identifiers: mplsLsrObjects mplsLsrNotifications mplsLsrConformance MPLS-LSR-MIB objects: mplsInterfaceConfTable mplsInterfaceConfEntry MPLS-LSR-MIB types: MplsInterfaceConfEntry MPLS-LSR-MIB objects: mplsInterfaceConfIndex mplsInterfaceLabelMinIn mplsInterfaceLabelMaxIn mplsInterfaceLabelMinOut mplsInterfaceLabelMaxOut mplsInterfaceTotalBandwidth mplsInterfaceAvailableBandwidth mplsInterfaceTotalBuffer mplsInterfaceAvailableBuffer mplsInterfaceIsGlobalLabelSpace mplsInterfaceIsLocalLabelSpace mplsInterfaceAdminStatus mplsInterfaceOperStatus mplsInterfacePerfTable mplsInterfacePerfEntry MPLS-LSR-MIB types: MplsInterfacePerfEntry MPLS-LSR-MIB objects: mplsInterfaceInLabelsUsed mplsInterfaceInPackets mplsInterfaceInDiscards mplsInterfaceFailedLabelLookup mplsInterfaceOutLabelsUsed mplsInterfaceOutPackets mplsInterfaceOutDiscards mplsInterfaceOutFragments mplsInSegmentTable mplsInSegmentEntry MPLS-LSR-MIB types: MplsInSegmentEntry MPLS-LSR-MIB objects: mplsInSegmentIfIndex mplsInSegmentLabel mplsInSegmentNPop mplsInSegmentAddrFamily mplsInSegmentXCIndex mplsInSegmentTSpecIndex mplsInSegmentOwner mplsInSegmentAdminStatus mplsInSegmentOperStatus mplsInSegmentRowStatus mplsInSegmentPerfTable mplsInSegmentPerfEntry MPLS-LSR-MIB types: MplsInSegmentPerfEntry MPLS-LSR-MIB objects: mplsInSegmentOctets mplsInSegmentPackets mplsInSegmentErrors mplsInSegmentDiscards mplsInSegmentHCOctets mplsOutSegmentIndexNext mplsOutSegmentTable mplsOutSegmentEntry MPLS-LSR-MIB types: MplsOutSegmentEntry MPLS-LSR-MIB objects: mplsOutSegmentIndex mplsOutSegmentIfIndex mplsOutSegmentPushTopLabel mplsOutSegmentTopLabel mplsOutSegmentNextHopIpAddrType mplsOutSegmentNextHopIpv4Addr mplsOutSegmentNextHopIpv6Addr mplsOutSegmentXCIndex mplsOutSegmentTSpecIndex mplsOutSegmentOwner mplsOutSegmentAdminStatus mplsOutSegmentOperStatus mplsOutSegmentRowStatus mplsOutSegmentPerfTable mplsOutSegmentPerfEntry MPLS-LSR-MIB types: MplsOutSegmentPerfEntry MPLS-LSR-MIB objects: mplsOutSegmentOctets mplsOutSegmentPackets mplsOutSegmentErrors mplsOutSegmentDiscards mplsOutSegmentHCOctets mplsXCIndexNext mplsXCTable mplsXCEntry MPLS-LSR-MIB types: MplsXCEntry MPLS-LSR-MIB objects: mplsXCIndex mplsXCLspId mplsXCLabelStackIndex mplsXCCOS mplsXCIsPersistent mplsXCOwner mplsXCAdminStatus mplsXCOperStatus mplsXCRowStatus mplsMaxLabelStackDepth mplsLabelStackIndexNext mplsLabelStackTable mplsLabelStackEntry MPLS-LSR-MIB types: MplsLabelStackEntry MPLS-LSR-MIB objects: mplsLabelStackIndex mplsLabelStackLabelIndex mplsLabelStackLabel mplsLabelStackRowStatus mplsTSpecIndexNext mplsTSpecTable mplsTSpecEntry MPLS-LSR-MIB types: MplsTSpecEntry MPLS-LSR-MIB objects: mplsTSpecIndex mplsTSpecMaxRate mplsTSpecMeanRate mplsTSpecMaxBurstSize mplsTSpecRowStatus mplsInterfaceTrapEnable mplsInSegmentTrapEnable mplsOutSegmentTrapEnable mplsXCTrapEnable MPLS-LSR-MIB traps: mplsInterfaceUp mplsInterfaceDown mplsInSegmentUp mplsInSegmentDown mplsOutSegmentUp mplsOutSegmentDown mplsXCUp mplsXCDown MPLS-LSR-MIB identifiers: mplsLsrGroups mplsLsrCompliances MPLS-LSR-MIB compliances: mplsLsrModuleCompliance MPLS-LSR-MIB groups: mplsInterfaceGroup mplsInSegmentGroup mplsOutSegmentGroup mplsXCGroup mplsPerfGroup mplsHCInSegmentPerfGroup mplsHCOutSegmentPerfGroup mplsTSpecGroup mplsXCIsPersistentGroup mplsXCIsNotPersistentGroup mplsLsrNotificationGroup % > -----Original Message----- > From: Hans Sjöstrand [mailto:hans.sjostrand@etx.ericsson.se] > Sent: Wednesday, March 15, 2000 2:19 PM > To: Thomas D. Nadeau > Cc: mpls@UU.NET; Cheenu Srinivasan; arun@force10networks.com > Subject: Re: LSR MIB WG Last Call > > > "Thomas D. Nadeau" wrote: > > > > Hi Hans, > > > > > I would like to know why you have "issued a last call? > > > > I did not issue a last call, as I cannot, nor > > was it my intention to do so. The intent of my first > > message to George and Vijay was to ask for a WG Last Call > > on the MIB. My second message was referring to this > > request, not declare a last call. I apologize for the > > confusion. > > Thanks Tom for the clarification on your last call. You > certanly fooled me and a lot of others I think. > > > > > > It almost ridiculous to say > > > something like that when it doesn't even compile! > > The main point wasn't that it didn't compile, but after > finding several errors in it I draw the conclusion that it > didn't go near a compiler. Maybe I was premature in > my conclusion. For me it was just another > indicator that there is some more work on this before it's > mature. > > > > > We compiled the current version with SMIC prior > > to releasing it. What are you compiling it with? > > Please provide me with your compilation errors > > so that I can look into this ASAP. > > FYI, but as I said, those are editorials. > > MPLS-LSR-MIB.mib: 774: Error: syntax error before: mplsInSegmentOctets > {error,compilation_failed} > > -- Then I fixed that to get further > MPLS-LSR-MIB.mib: 813: Error: Types for mplsInSegmentHCOctets differs > from the SEQUENCE definition. > {error,compilation_failed} > > -- Then I fixed that to get further > MPLS-LSR-MIB.mib: Error: 'mplsTSpecIndexNext' missing in OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackRowStatus' missing in > OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackLabel' missing in OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackIndex' missing in OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackIndexNext' missing in > OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsMaxLabelStackDepth' missing in > OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsXCOwner' missing in OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsXCCOS' missing in OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsXCLspId' missing in OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsOutSegmentErrors' missing in > OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsInSegmentErrors' missing in OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceOutFragments' missing in > OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceFailedLabelLookup' missing in > OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceAvailableBuffer' missing in > OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceTotalBuffer' missing in > OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceAvailableBandwidth' missing in > OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceTotalBandwidth' missing in > OBJECT-GROUP > MPLS-LSR-MIB.mib: Error: 'mplsOutSegmentDown' missing in > NOTIFICATION-GROUP > {error,compilation_failed} > > -- then I gave up > > > > > > The only thing you create is confusion, hopefully that > > > isn't the goal of the exercise. But what was your purpuse? > > > > Of course not. My purpose was to ask for a last call > > and nothing else. > > > > --Tom > > > > > /// Hasse > > > > > > "Thomas D. Nadeau" wrote: > > > > > > > > > > > > Please do give comments if there are any. > > > > The WG Last Call should not preclude that. The > > > > reason why we decided to go WGLC at this point > > > > was that even during the last round of reviewed > > > > comments (most were from you in fact), the comments > > > > were relatively minor. We feel that the MIB is pretty > > > > solid and mature at this point. > > > > > > > > --Tom > > > > > > > > > Your latest version is dated 6th March. > > > > > It is now 14th. > > > > > > > > > > I think it reasonable to give us all a little time to > read your > > > work > > > > > after > > > > > all of the effort you have put into it. > > > > > > > > > > Adrian > > > > > -- > > > > > Adrian Farrel mailto:af@datcon.co.uk > > > > > ATM, MPLS and Telecoms Development Group > > > > > Data Connection Ltd., Chester, UK > > > > > http://www.datcon.co.uk/ > > > > > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > > > > > > > > > > > > > >-----Original Message----- > > > > > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > >Sent: Tuesday, March 14, 2000 10:49 PM > > > > > >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan > > > > > >Cc: Cheenu Srinivasan; arun@force10networks.com > > > > > >Subject: LSR MIB WG Last Call > > > > > > > > > > > > > > > > > > > > > > > > Since we have not received any additional comments > > > > > >on the current version of the LSR MIB, we would like > > > > > >to raise the document to WG Last Call. > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Mar 16 11:16:44 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01363 for ; Thu, 16 Mar 2000 11:16:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigub25690; Thu, 16 Mar 2000 16:16:43 GMT Received: by mail-control.mail.uu.net id QQigub16730 for mpls-outgoing; Thu, 16 Mar 2000 16:16:08 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigub16652 for ; Thu, 16 Mar 2000 16:15:49 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigub04139 for ; Thu, 16 Mar 2000 11:15:33 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigub26589 for ; Thu, 16 Mar 2000 16:15:32 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA18758 for mpls@uu.net; Thu, 16 Mar 2000 11:15:32 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigub16611 for ; Thu, 16 Mar 2000 16:15:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigub29040 for ; Thu, 16 Mar 2000 11:15:02 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQigub26062 for ; Thu, 16 Mar 2000 16:15:02 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 11:13:21 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F870@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Arun Viswanathan'" , Joan Cucchiara , "'George Swallow'" Cc: "'Thomas D. Nadeau'" , "'Adrian Farrel'" , "'mpls@UU.NET'" , "'vsriniva@cosinecom.com'" Subject: RE: LSR MIB WG Last Call Date: Thu, 16 Mar 2000 11:13:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Arun, It was not clear to me from reading the MIB. No where does it say, "for LPD this means ...." or "this object/table does not apply to LDP". For example, the XC table goes to great length to discuss p-to-mp and mp-to-p types of Cross Connects and I don't understand what this has to do with LDP which is next-hop peer. Especially, p-to-mp which seems to me to imply some sort of multicast when thinking about LDP, but maybe that's just me. Secondly, I thought configuration of LDP was a new addition because to the change under Feature Checklist: "The MIB should be able to support both manually configured LSPs as well as those configured via LDP and/or RSVP signalling". The prior rev said "CR-LDP and/or RSVP signalling". > > LDP doesn't constitute an LSR. The label and connection > resources are common to every MPLS protocol and hence the > LSR MIB. It is just seems absurd to me that LDP requires > to manage its own label space and connections instead > of a single entity that manages label and connection resources > for ALL MPLS protocols. Arun, again I am concerned about these statements. It is not absurd if you consider that there was not an alternative, nor is there an existing alternative. Separating these tables from the LDP MIB may or may not be adequate for all 3 MPLS protocols. I don't know at this point. If the LSR MIB would like to configure label ranges, then certainly the work for this in the LDP MIB could be used as a starting point. Feel free to copy it into the LSR MIB as a starting point. However, it is not appropriate for the LDP MIB to be held up waiting for the LSR MIB. MIBs often copy in Textual Conventional at the same time so they can advance without being held up by one another. It is just not accepted practice to hold up one MIB for another, especially when the other one is NOT necessary to support the first. The LSR MIB is not needed for the LDP MIB. If the LSR MIB intends to support configuring label ranges then I would like to raise a couple of issue: * I think that separate MIBs which for LDP, CR-LDP and RSVP-MPLS should be developed for the very simple reason that an LSR may only want to run one protocol. Thus, supporting the LSR MIB is not needed until there are two or more MPLS protocols on the same LSR. Certainly, if all 3 of these MIBs could point to some label range config tables in the LSR MIB (or elsewhere), then that is an alternative. Today this is NOT the case. * A few weeks ago there was quite a bit of discussion on what it meant to modify a label range for LDP. Modifying a Label Range could have potential ripple effects throughout most of the tables in the LDP MIB. Is the LSR MIB going to maintain state for all the different protocols? I would disagree for the reasons stated above: specifically, an LSR should be able to run only one MPLS protocol without the LSR MIB. It is not clear to me where the LSR MIB is drawing the lines, and I would like to understand this prior to the LSR MIB going to last call. I also would like to understand if this configuring of label ranges is going to be part of the LSR MIB, or yet another draft? In a way, I think that it is "too soon" for the LSR MIB. If all 3 protocols already had existing MIBs, then it would be much clearer to me where the likenesses were and what could be separated out into an LSR MIB. I am concerned that the LSR MIB is actually trying to support CR-LDP and MPLS-RSVP specific objects and is not maintaining the abstraction level which was the original goal. -Joan > > > So I object on this > > basis. It does not seem fair to me that > > 3 revisions into the LSR MIB, the LSR MIB can expand > > its scope to support another protocol, namely LDP, especially > > when there is already an active LDP MIB. > > Let me state this one more time. LSR MIB supported LDP (and > every other MPLS protocol) from the day of its inception. > > > > > There has been NO working group consensus about including LDP in > > scope of the LSR MIB. > > The very reason the WG split the intial TE doc into > two separate doc was to have a seperate LSR MIB common > to all MPLS protocols. > > > > > Why does the working group need two MIBs for LDP > > Because LDP is not LSR! Please see the above comments. > > -arun > > > > > Thank you, Joan > > > > > -----Original Message----- > > > From: George Swallow [mailto:swallow@cisco.com] > > > Sent: Wednesday, March 15, 2000 10:28 AM > > > To: Joan Cucchiara > > > Cc: 'Thomas D. Nadeau'; Adrian Farrel; mpls@UU.NET; > > > 'swallow@cisco.com'; > > > 'vsriniva@cosinecom.com'; swallow@cisco.com > > > Subject: Re: LSR MIB WG Last Call > > > > > > > > > Joan - > > > > > > I believe that Tom merely meant to suggest that the LSR > mib was now > > > ready for last call. Unless I hear objections I'll issue > one before > > > the day is out. > > > > > > ...George > > > > > > ================================================================== > > > George Swallow Cisco Systems > (978) 244-8143 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 > > > > > > > > From owner-mpls@UU.NET Thu Mar 16 11:23:09 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03874 for ; Thu, 16 Mar 2000 11:23:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigub02173; Thu, 16 Mar 2000 16:23:10 GMT Received: by mail-control.mail.uu.net id QQigub17266 for mpls-outgoing; Thu, 16 Mar 2000 16:22:41 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigub17255 for ; Thu, 16 Mar 2000 16:22:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigub05273; Thu, 16 Mar 2000 11:22:08 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQigub05942; Thu, 16 Mar 2000 16:22:08 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id LAA14103; Thu, 16 Mar 2000 11:22:07 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id LAA37999; Thu, 16 Mar 2000 11:22:22 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003161622.LAA37999@curtis-lt.avici.com> To: Hummel Heinrich cc: "'curtis@avici.com'" , Loa Andersson , mpls@UU.NET, te-wg@UU.NET Reply-To: curtis@avici.com Subject: Re: AW: Internet Draft Submission: Orchestrally Conducted Traffic In-reply-to: Your message of "Thu, 16 Mar 2000 10:04:05 +0100." Date: Thu, 16 Mar 2000 11:22:22 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Hummel Heinrich w rites: > > Curtis wrote: > > > I believe there was no comment because there was no interest. > > Generally people say nothing rather than expressing no interest but > > since Hummel has asked what happenned I'll acknowledge having read the > > draft and when it was sent to the mailing list and having reread it > > just now and having no interest in pursuing it. > [Hummel Heinrich]: > IMHO OCT entirely complies with the intentions of the TE-WG. > OCT tries to statistical multiplex the entire traffic onto the > entire network; will > say: it does MACRO-multiplexing. A sentence from the TE framework > document: > "Likewise, we shall refer to the traffic engineering > schemes that deal with network performance optimization at the > systems level as macro-TE and the schemes that optimize at the > individual resource level as micro-TE." Hummel, The wording in the charter indicates that the WG is interested in solving a specific problem. That does not mean that the WG has expressed any interest at all in the specific solution to that problem that you have proposed. Curtis From owner-mpls@UU.NET Thu Mar 16 11:47:56 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14419 for ; Thu, 16 Mar 2000 11:47:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigud02842; Thu, 16 Mar 2000 16:47:53 GMT Received: by mail-control.mail.uu.net id QQigud18445 for mpls-outgoing; Thu, 16 Mar 2000 16:47:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigud18440 for ; Thu, 16 Mar 2000 16:47:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigud04786 for ; Thu, 16 Mar 2000 11:47:00 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigud20306 for ; Thu, 16 Mar 2000 16:46:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA24647 for mpls@uu.net; Thu, 16 Mar 2000 11:46:58 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigud18398 for ; Thu, 16 Mar 2000 16:46:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigud09280; Thu, 16 Mar 2000 11:46:12 -0500 (EST) Received: from beamer.mchh.siemens.de by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQigud01713; Thu, 16 Mar 2000 16:46:11 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA00510; Thu, 16 Mar 2000 17:45:28 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA02054; Thu, 16 Mar 2000 17:45:58 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Mar 2000 17:47:01 +0100 Message-ID: From: Hummel Heinrich To: "'curtis@avici.com'" , Hummel Heinrich Cc: Loa Andersson , mpls@UU.NET, te-wg@UU.NET Subject: AW: AW: Internet Draft Submission: Orchestrally Conducted Traffic Date: Thu, 16 Mar 2000 17:47:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk IMHO, the solution which I proposed relates to a problem that has been clearly expressed in the TE-WG: "to balance the traffic load ,...to combat congestions, both preventively and reactively,..." Heinrich Hummel Siemens AG > In message , Hummel > Heinrich w > rites: > > > > Curtis wrote: > > > > > I believe there was no comment because there was no interest. > > > Generally people say nothing rather than expressing no interest but > > > since Hummel has asked what happenned I'll acknowledge having read the > > > draft and when it was sent to the mailing list and having reread it > > > just now and having no interest in pursuing it. > > [Hummel Heinrich]: > > IMHO OCT entirely complies with the intentions of the TE-WG. > > OCT tries to statistical multiplex the entire traffic onto the > > entire network; will > > say: it does MACRO-multiplexing. A sentence from the TE framework > > document: > > "Likewise, we shall refer to the traffic engineering > > schemes that deal with network performance optimization at the > > systems level as macro-TE and the schemes that optimize at the > > individual resource level as micro-TE." > > > Hummel, > > The wording in the charter indicates that the WG is interested in > solving a specific problem. That does not mean that the WG has > expressed any interest at all in the specific solution to that problem > that you have proposed. > > Curtis From owner-mpls@UU.NET Thu Mar 16 12:27:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29637 for ; Thu, 16 Mar 2000 12:27:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiguf27772; Thu, 16 Mar 2000 17:27:40 GMT Received: by mail-control.mail.uu.net id QQiguf29183 for mpls-outgoing; Thu, 16 Mar 2000 17:27:05 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiguf29178 for ; Thu, 16 Mar 2000 17:27:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiguf10500 for ; Thu, 16 Mar 2000 12:26:51 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQiguf25530 for ; Thu, 16 Mar 2000 17:26:51 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA09550 for ; Thu, 16 Mar 2000 09:51:46 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA02567 for mpls@uu.net; Thu, 16 Mar 2000 12:23:47 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigud19243 for ; Thu, 16 Mar 2000 16:58:41 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigud06605; Thu, 16 Mar 2000 11:58:40 -0500 (EST) Received: from slb-smtpout-01.boeing.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: slb-smtpout-01.boeing.com [12.13.237.21]) id QQigud00293; Thu, 16 Mar 2000 16:58:40 GMT Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA19050; Thu, 16 Mar 2000 08:57:57 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id IAA20495; Thu, 16 Mar 2000 08:54:29 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 16 Mar 2000 08:54:16 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 11:54:15 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EEC1@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Hummel Heinrich'" , "'curtis@avici.com'" Cc: mpls@UU.NET, te-wg@UU.NET Subject: RE: AW: Internet Draft Submission: Orchestrally Conducted Traffic Date: Thu, 16 Mar 2000 11:54:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hummel Heinrich wrote: > IMHO, > the solution which I proposed relates to a problem that has > been clearly > expressed in > the TE-WG: "to balance the traffic load ,...to combat > congestions, both > preventively and reactively,..." And Curtis Villamizar had previously written: > > The wording in the charter indicates that the WG is interested in > > solving a specific problem. That does not mean that the WG has > > expressed any interest at all in the specific solution to > that problem > > that you have proposed. Hummel, the two positions are not mutually exclusive. You can both be correct. The hope is that if the WG has decided _not_ to use Hummel's approach, or any aspect of it, that there is good rationale behind this decision. Heaven knows, people do get engrossed with their particular religious dogma. It would be helpful if such explanations, even if brief, were provided when a suggestion is rejected. But I suppose there is no mandate that every alternative approach be laboriously studied and its rejection fully documented. Bert albert.e.manfredi@boeing.com From owner-mpls@UU.NET Thu Mar 16 12:44:45 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05605 for ; Thu, 16 Mar 2000 12:44:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigug10286; Thu, 16 Mar 2000 17:44:45 GMT Received: by mail-control.mail.uu.net id QQigug00234 for mpls-outgoing; Thu, 16 Mar 2000 17:44:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigug00198 for ; Thu, 16 Mar 2000 17:44:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigug17362 for ; Thu, 16 Mar 2000 12:43:51 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigug08588 for ; Thu, 16 Mar 2000 17:43:50 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA03301 for mpls@uu.net; Thu, 16 Mar 2000 12:43:50 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigug29999 for ; Thu, 16 Mar 2000 17:41:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigug12318 for ; Thu, 16 Mar 2000 12:41:05 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQigug06855 for ; Thu, 16 Mar 2000 17:41:04 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 12:39:24 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F874@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Cheenu Srinivasan'" , =?iso-8859-1?Q?=27Ha?= =?iso-8859-1?Q?ns_Sj=F6strand=27?= , mpls@UU.NET, "'swallow@cisco.com'" Cc: "Thomas D. Nadeau" , arun@force10networks.com Subject: RE: problems compiling LSR MIB v2 - NOT! Date: Thu, 16 Mar 2000 12:39:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA05605 Cheenu, I had problems similar to those which Hans mentioned when compiling this with smicng (book version). I think (?) the MIB does need to be compiled by smicng somewhere along the way (later on in the IESG process maybe). Perhaps, someone with more info could comment on this. -Joan > -----Original Message----- > From: Cheenu Srinivasan [mailto:csrinivasan@tachion.com] > Sent: Thursday, March 16, 2000 10:13 AM > To: 'Hans Sjöstrand'; mpls@UU.NET; 'swallow@cisco.com' > Cc: Thomas D. Nadeau; arun@force10networks.com > Subject: problems compiling LSR MIB v2 - NOT! > > > I just pulled down the latest version of the LSR MIB from > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-02.txt > and compiled that (not my local copy), generated code etc. It > went through without a hitch; output trace is attached below. > > Of course, we went through this process _before_ we posted the > MIB, and made sure all was kosher. > > Perhaps there's a problem with your compiler/environment. > > Cheenu > > % premosy draft-ietf-mpls-lsr-mib-02.txt MPLS-LSR-MIB.my > % mosy MPLS-LSR-MIB.my > mosy 7.1 #1 (starship) of Sat Dec 13 18:23:09 EST 1997 > MPLS-LSR-MIB modules: mplsLsrMIB > > MPLS-LSR-MIB conventions: MplsLSPID MplsLsrIANAAddrFamily MplsLabel > Ipv6Address > MplsBitRate MplsBurstSize MplsBufferSize > > MPLS-LSR-MIB identifiers: mplsLsrObjects mplsLsrNotifications > mplsLsrConformance > > MPLS-LSR-MIB objects: mplsInterfaceConfTable mplsInterfaceConfEntry > > MPLS-LSR-MIB types: MplsInterfaceConfEntry > > MPLS-LSR-MIB objects: mplsInterfaceConfIndex mplsInterfaceLabelMinIn > mplsInterfaceLabelMaxIn mplsInterfaceLabelMinOut > mplsInterfaceLabelMaxOut mplsInterfaceTotalBandwidth > mplsInterfaceAvailableBandwidth mplsInterfaceTotalBuffer > mplsInterfaceAvailableBuffer > mplsInterfaceIsGlobalLabelSpace > mplsInterfaceIsLocalLabelSpace mplsInterfaceAdminStatus > mplsInterfaceOperStatus mplsInterfacePerfTable > mplsInterfacePerfEntry > > MPLS-LSR-MIB types: MplsInterfacePerfEntry > > MPLS-LSR-MIB objects: mplsInterfaceInLabelsUsed mplsInterfaceInPackets > mplsInterfaceInDiscards mplsInterfaceFailedLabelLookup > mplsInterfaceOutLabelsUsed mplsInterfaceOutPackets > mplsInterfaceOutDiscards mplsInterfaceOutFragments > mplsInSegmentTable mplsInSegmentEntry > > MPLS-LSR-MIB types: MplsInSegmentEntry > > MPLS-LSR-MIB objects: mplsInSegmentIfIndex mplsInSegmentLabel > mplsInSegmentNPop > mplsInSegmentAddrFamily mplsInSegmentXCIndex > mplsInSegmentTSpecIndex mplsInSegmentOwner > mplsInSegmentAdminStatus mplsInSegmentOperStatus > mplsInSegmentRowStatus mplsInSegmentPerfTable > mplsInSegmentPerfEntry > > MPLS-LSR-MIB types: MplsInSegmentPerfEntry > > MPLS-LSR-MIB objects: mplsInSegmentOctets mplsInSegmentPackets > mplsInSegmentErrors mplsInSegmentDiscards > mplsInSegmentHCOctets > mplsOutSegmentIndexNext mplsOutSegmentTable > mplsOutSegmentEntry > > MPLS-LSR-MIB types: MplsOutSegmentEntry > > MPLS-LSR-MIB objects: mplsOutSegmentIndex mplsOutSegmentIfIndex > mplsOutSegmentPushTopLabel mplsOutSegmentTopLabel > mplsOutSegmentNextHopIpAddrType > mplsOutSegmentNextHopIpv4Addr > mplsOutSegmentNextHopIpv6Addr mplsOutSegmentXCIndex > mplsOutSegmentTSpecIndex mplsOutSegmentOwner > mplsOutSegmentAdminStatus mplsOutSegmentOperStatus > mplsOutSegmentRowStatus mplsOutSegmentPerfTable > mplsOutSegmentPerfEntry > > MPLS-LSR-MIB types: MplsOutSegmentPerfEntry > > MPLS-LSR-MIB objects: mplsOutSegmentOctets mplsOutSegmentPackets > mplsOutSegmentErrors mplsOutSegmentDiscards > mplsOutSegmentHCOctets > mplsXCIndexNext mplsXCTable mplsXCEntry > > MPLS-LSR-MIB types: MplsXCEntry > > MPLS-LSR-MIB objects: mplsXCIndex mplsXCLspId mplsXCLabelStackIndex > mplsXCCOS > mplsXCIsPersistent mplsXCOwner mplsXCAdminStatus > mplsXCOperStatus > mplsXCRowStatus mplsMaxLabelStackDepth > mplsLabelStackIndexNext > mplsLabelStackTable mplsLabelStackEntry > > MPLS-LSR-MIB types: MplsLabelStackEntry > > MPLS-LSR-MIB objects: mplsLabelStackIndex mplsLabelStackLabelIndex > mplsLabelStackLabel mplsLabelStackRowStatus > mplsTSpecIndexNext > mplsTSpecTable mplsTSpecEntry > > MPLS-LSR-MIB types: MplsTSpecEntry > > MPLS-LSR-MIB objects: mplsTSpecIndex mplsTSpecMaxRate > mplsTSpecMeanRate > mplsTSpecMaxBurstSize mplsTSpecRowStatus > mplsInterfaceTrapEnable > mplsInSegmentTrapEnable mplsOutSegmentTrapEnable > mplsXCTrapEnable > > MPLS-LSR-MIB traps: mplsInterfaceUp mplsInterfaceDown mplsInSegmentUp > mplsInSegmentDown mplsOutSegmentUp > mplsOutSegmentDown mplsXCUp > mplsXCDown > > MPLS-LSR-MIB identifiers: mplsLsrGroups mplsLsrCompliances > > MPLS-LSR-MIB compliances: mplsLsrModuleCompliance > > MPLS-LSR-MIB groups: mplsInterfaceGroup mplsInSegmentGroup > mplsOutSegmentGroup > mplsXCGroup mplsPerfGroup mplsHCInSegmentPerfGroup > mplsHCOutSegmentPerfGroup mplsTSpecGroup > mplsXCIsPersistentGroup > mplsXCIsNotPersistentGroup mplsLsrNotificationGroup > % > > > > > > > > -----Original Message----- > > From: Hans Sjöstrand [mailto:hans.sjostrand@etx.ericsson.se] > > Sent: Wednesday, March 15, 2000 2:19 PM > > To: Thomas D. Nadeau > > Cc: mpls@UU.NET; Cheenu Srinivasan; arun@force10networks.com > > Subject: Re: LSR MIB WG Last Call > > > > > > "Thomas D. Nadeau" wrote: > > > > > > Hi Hans, > > > > > > > I would like to know why you have "issued a last call? > > > > > > I did not issue a last call, as I cannot, nor > > > was it my intention to do so. The intent of my first > > > message to George and Vijay was to ask for a WG Last Call > > > on the MIB. My second message was referring to this > > > request, not declare a last call. I apologize for the > > > confusion. > > > > Thanks Tom for the clarification on your last call. You > > certanly fooled me and a lot of others I think. > > > > > > > > > It almost ridiculous to say > > > > something like that when it doesn't even compile! > > > > The main point wasn't that it didn't compile, but after > > finding several errors in it I draw the conclusion that it > > didn't go near a compiler. Maybe I was premature in > > my conclusion. For me it was just another > > indicator that there is some more work on this before it's > > mature. > > > > > > > > We compiled the current version with SMIC prior > > > to releasing it. What are you compiling it with? > > > Please provide me with your compilation errors > > > so that I can look into this ASAP. > > > > FYI, but as I said, those are editorials. > > > > MPLS-LSR-MIB.mib: 774: Error: syntax error before: > mplsInSegmentOctets > > {error,compilation_failed} > > > > -- Then I fixed that to get further > > MPLS-LSR-MIB.mib: 813: Error: Types for > mplsInSegmentHCOctets differs > > from the SEQUENCE definition. > > {error,compilation_failed} > > > > -- Then I fixed that to get further > > MPLS-LSR-MIB.mib: Error: 'mplsTSpecIndexNext' missing in > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackRowStatus' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackLabel' missing in > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackIndex' missing in > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsLabelStackIndexNext' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsMaxLabelStackDepth' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsXCOwner' missing in OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsXCCOS' missing in OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsXCLspId' missing in OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsOutSegmentErrors' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInSegmentErrors' missing in > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceOutFragments' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceFailedLabelLookup' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceAvailableBuffer' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceTotalBuffer' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceAvailableBandwidth' > missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsInterfaceTotalBandwidth' missing in > > OBJECT-GROUP > > MPLS-LSR-MIB.mib: Error: 'mplsOutSegmentDown' missing in > > NOTIFICATION-GROUP > > {error,compilation_failed} > > > > -- then I gave up > > > > > > > > > The only thing you create is confusion, hopefully that > > > > isn't the goal of the exercise. But what was your purpuse? > > > > > > Of course not. My purpose was to ask for a last call > > > and nothing else. > > > > > > --Tom > > > > > > > /// Hasse > > > > > > > > "Thomas D. Nadeau" wrote: > > > > > > > > > > > > > > > Please do give comments if there are any. > > > > > The WG Last Call should not preclude that. The > > > > > reason why we decided to go WGLC at this point > > > > > was that even during the last round of reviewed > > > > > comments (most were from you in fact), the comments > > > > > were relatively minor. We feel that the MIB is pretty > > > > > solid and mature at this point. > > > > > > > > > > --Tom > > > > > > > > > > > Your latest version is dated 6th March. > > > > > > It is now 14th. > > > > > > > > > > > > I think it reasonable to give us all a little time to > > read your > > > > work > > > > > > after > > > > > > all of the effort you have put into it. > > > > > > > > > > > > Adrian > > > > > > -- > > > > > > Adrian Farrel mailto:af@datcon.co.uk > > > > > > ATM, MPLS and Telecoms Development Group > > > > > > Data Connection Ltd., Chester, UK > > > > > > http://www.datcon.co.uk/ > > > > > > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > > >Sent: Tuesday, March 14, 2000 10:49 PM > > > > > > >To: mpls@UU.NET; swallow@cisco.com; Vijay Srinivasan > > > > > > >Cc: Cheenu Srinivasan; arun@force10networks.com > > > > > > >Subject: LSR MIB WG Last Call > > > > > > > > > > > > > > > > > > > > > > > > > > > > Since we have not received any additional comments > > > > > > >on the current version of the LSR MIB, we would like > > > > > > >to raise the document to WG Last Call. > > > > > > > > > > > > > > --Tom > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Mar 16 14:04:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03076 for ; Thu, 16 Mar 2000 14:04:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigum10382; Thu, 16 Mar 2000 19:04:51 GMT Received: by mail-control.mail.uu.net id QQigum18462 for mpls-outgoing; Thu, 16 Mar 2000 19:04:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigum18339 for ; Thu, 16 Mar 2000 19:04:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigum27801 for ; Thu, 16 Mar 2000 14:04:04 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQigum03533 for ; Thu, 16 Mar 2000 19:04:04 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id OAA26345; Thu, 16 Mar 2000 14:04:02 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id OAA38235; Thu, 16 Mar 2000 14:04:18 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003161904.OAA38235@curtis-lt.avici.com> To: Yakov Rekhter cc: jls@research.att.com, "'CATANZARITI Sergio FTR&D/TI'" , "'Chip Sharp'" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Optical IP activities In-reply-to: Your message of "Thu, 16 Mar 2000 07:45:28 PST." <200003161545.HAA10354@omega.cisco.com> Date: Thu, 16 Mar 2000 14:04:18 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200003161545.HAA10354@omega.cisco.com>, Yakov Rekhter writes: > John, > > > I'd like to reinforce these concerns. It seems to me that defining the > > scope of this work to cover only peer-to-peer models of router/OXC > > interactions would drastically limit its value in the short-to-medium > > term at least. Similarly with disclosure of physical topology > > information. Recent OIF contributions from many of the principal > > players suggest that further study of these issues before limiting work > > to a single model is needed, as does draft > > draft-rstb-optical-signaling-framework-00.txt. > > I would assume that the same control plane based on MPLS TE could be > used to support both the peer and the overlay model (as well as a mixture > of both). With this in mind I would suggest that the MPLS WG should > focus on defining the extension to the current MPLS TE protocols (ISIS, > OSPF, RSVP, CR-LDP) to handle Optical LSRs and SDH-LSRs. > > Yakov. [Disclaimer: I'm guessing at other people's objections so apply a large grain of salt unless confirmed.] I'm guessing that some of the objections to using MPLS as a means to control the optical crossconnects come from the prolems of attenuation and signal degradation (dispersion, etc) that are cummulative. Determining whether an LSP path is feasible may not be a simple as checking the bandwidth constraints on the legs of the path if there are no OEO conversions at the hops. If that is what John was getting at, then John may be trying to tell us that it is premature to try to come up with means to quantify the restrictions imposed by attenuation and signal degradation such that the ingress can reliably predict LSP path feasibility. btw- Some vendors may also not be looking forward to sharing these characteristics (attenuation, dispersion, etc) openly as would be necessary if advertising them through a vendor independent control protocol, even if we knew how to express them and knew how to accumulate the effects. If this is the objection, its worth noting that the objection may not apply if OEO is done everywhere (but it may cost more to do that). Someone (John in particular, Chip, Sergio also) please correct me if I'm wrong about my assumption. If so, I appologize for incorrectly reading between the lines of your message(s). If I'm not wrong, then perhaps this clarifies the objections. Curtis From owner-mpls@UU.NET Thu Mar 16 14:11:25 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05202 for ; Thu, 16 Mar 2000 14:11:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigum10140; Thu, 16 Mar 2000 19:11:23 GMT Received: by mail-control.mail.uu.net id QQigum21054 for mpls-outgoing; Thu, 16 Mar 2000 19:10:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigum21048 for ; Thu, 16 Mar 2000 19:10:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigum23920 for ; Thu, 16 Mar 2000 14:10:15 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigum13949 for ; Thu, 16 Mar 2000 19:10:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA17755 for mpls@uu.net; Thu, 16 Mar 2000 14:10:13 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigum20831 for ; Thu, 16 Mar 2000 19:09:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigum28375 for ; Thu, 16 Mar 2000 14:08:49 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigum12692 for ; Thu, 16 Mar 2000 19:08:48 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA17488 for ; Thu, 16 Mar 2000 14:08:48 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA09358 for ; Thu, 16 Mar 2000 14:08:48 -0500 (EST) Message-Id: <200003161908.OAA09358@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: MPLS Agenda crowded Date: Thu, 16 Mar 2000 14:08:47 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Folks - I've got requests for 26 presentations. (And several more drafts for which I don't have specific requests). That doesn't leave much time per presentation. If any of you are planning on making the same presentation to both the Optical BoF and MPLS, I'd like to ask that you only present once. If you present at the Optical BoF that won't reduce the standing of your draft in MPLS. Please let me know if you can help out. Thanks, ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Mar 16 14:18:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07286 for ; Thu, 16 Mar 2000 14:18:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigun15964; Thu, 16 Mar 2000 19:18:00 GMT Received: by mail-control.mail.uu.net id QQigun21658 for mpls-outgoing; Thu, 16 Mar 2000 19:17:16 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigun21641 for ; Thu, 16 Mar 2000 19:17:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigun24967; Thu, 16 Mar 2000 14:16:52 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQigun14900; Thu, 16 Mar 2000 19:16:47 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id OAA27371; Thu, 16 Mar 2000 14:16:45 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id OAA38430; Thu, 16 Mar 2000 14:17:01 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003161917.OAA38430@curtis-lt.avici.com> To: "Manfredi, Albert E" cc: "'Hummel Heinrich'" , "'curtis@avici.com'" , mpls@UU.NET, te-wg@UU.NET Reply-To: curtis@avici.com Subject: Re: AW: Internet Draft Submission: Orchestrally Conducted Traffic In-reply-to: Your message of "Thu, 16 Mar 2000 11:54:14 EST." <4102273CEB77D211869200805FE6F59356EEC1@xch-phl-01.he.boeing.com> Date: Thu, 16 Mar 2000 14:17:01 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4102273CEB77D211869200805FE6F59356EEC1@xch-phl-01.he.boeing.com>, " Manfredi, Albert E" writes: > Hummel Heinrich wrote: > > > IMHO, > > the solution which I proposed relates to a problem that has > > been clearly > > expressed in > > the TE-WG: "to balance the traffic load ,...to combat > > congestions, both > > preventively and reactively,..." > > And Curtis Villamizar had previously written: > > > > The wording in the charter indicates that the WG is interested in > > > solving a specific problem. That does not mean that the WG has > > > expressed any interest at all in the specific solution to > > that problem > > > that you have proposed. > > Hummel, the two positions are not mutually exclusive. You can both be > correct. The hope is that if the WG has decided _not_ to use Hummel's > approach, or any aspect of it, that there is good rationale behind this > decision. Heaven knows, people do get engrossed with their particular > religious dogma. > > It would be helpful if such explanations, even if brief, were provided when > a suggestion is rejected. But I suppose there is no mandate that every > alternative approach be laboriously studied and its rejection fully > documented. > > Bert > albert.e.manfredi@boeing.com The requirement in the IETF is that there be rough consensus that a proposal be accepted as a WG document. Lask of rough consensus is sufficient reason to reject a proposal. If you are speaking in favor of making this a WG document, I think that would make you the first besides Hummel. There does not seem to have been an outpouring of support. No decision has been made but I suggest that 1) I shut up, 2) if anyone else has comments they voice them or express their disinterest through cotinued silence, 3) the WG chairs ask at the upcoming meeting if there is support for this draft if the author requests that it be considered as a WG doc. Curtis From owner-mpls@UU.NET Thu Mar 16 14:21:18 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08460 for ; Thu, 16 Mar 2000 14:21:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigun21038; Thu, 16 Mar 2000 19:21:08 GMT Received: by mail-control.mail.uu.net id QQigun21840 for mpls-outgoing; Thu, 16 Mar 2000 19:20:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigun21835 for ; Thu, 16 Mar 2000 19:20:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigun00004 for ; Thu, 16 Mar 2000 14:20:14 -0500 (EST) Received: from lumen.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: magic03.kudonet.com [209.133.127.227]) id QQigun20349 for ; Thu, 16 Mar 2000 19:20:14 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Mar 2000 11:22:44 -0800 Message-ID: From: John Drake To: "'curtis@avici.com'" , Yakov Rekhter Cc: jls@research.att.com, "'CATANZARITI Sergio FTR&D/TI'" , "'Chip Sharp'" , mpls@UU.NET Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 11:22:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Performance Monitoring in Photonic Networks in support of MPL(ambda)S Author(s) : L. Ceuppens, D. Blumenthal, J. Drake, J. Chrostowski, W. Edwards Filename : draft-ceuppens-mpls-optical-00.txt Pages : 11 Date : 10-Mar-00 Realizing the important role that photonic switches can play in data-centric networks, work has been going on within the IETF to combine the control plane of MPLS (more specifically traffic engineering) with the point-and-click provisioning capabilities of photonic switches [1]. This document outlines a proposal to expand this initiative to include DWDM, OADM and ATM systems. It also proposes to expand the work beyond simple establishment of optical paths and include optical performance monitoring and management. The combined path routing and performance information that will be carried and shared between these network elements will allow the elements or element management system (EMS) to adequately assess the 'health' of an optical path (which can be a wavelength or fiber strand). The routers and/or ATM switches at the edges of the photonic network will then use this information to dynamically manage the millions of wavelengths available in the photonic layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ceuppens-mpls-optical-00.txt -----Original Message----- From: Curtis Villamizar [mailto:curtis@avici.com] Sent: Thursday, March 16, 2000 11:04 AM To: Yakov Rekhter Cc: jls@research.att.com; 'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp'; mpls@UU.NET Subject: Re: Optical IP activities In message <200003161545.HAA10354@omega.cisco.com>, Yakov Rekhter writes: > John, > > > I'd like to reinforce these concerns. It seems to me that defining the > > scope of this work to cover only peer-to-peer models of router/OXC > > interactions would drastically limit its value in the short-to-medium > > term at least. Similarly with disclosure of physical topology > > information. Recent OIF contributions from many of the principal > > players suggest that further study of these issues before limiting work > > to a single model is needed, as does draft > > draft-rstb-optical-signaling-framework-00.txt. > > I would assume that the same control plane based on MPLS TE could be > used to support both the peer and the overlay model (as well as a mixture > of both). With this in mind I would suggest that the MPLS WG should > focus on defining the extension to the current MPLS TE protocols (ISIS, > OSPF, RSVP, CR-LDP) to handle Optical LSRs and SDH-LSRs. > > Yakov. [Disclaimer: I'm guessing at other people's objections so apply a large grain of salt unless confirmed.] I'm guessing that some of the objections to using MPLS as a means to control the optical crossconnects come from the prolems of attenuation and signal degradation (dispersion, etc) that are cummulative. Determining whether an LSP path is feasible may not be a simple as checking the bandwidth constraints on the legs of the path if there are no OEO conversions at the hops. If that is what John was getting at, then John may be trying to tell us that it is premature to try to come up with means to quantify the restrictions imposed by attenuation and signal degradation such that the ingress can reliably predict LSP path feasibility. btw- Some vendors may also not be looking forward to sharing these characteristics (attenuation, dispersion, etc) openly as would be necessary if advertising them through a vendor independent control protocol, even if we knew how to express them and knew how to accumulate the effects. If this is the objection, its worth noting that the objection may not apply if OEO is done everywhere (but it may cost more to do that). Someone (John in particular, Chip, Sergio also) please correct me if I'm wrong about my assumption. If so, I appologize for incorrectly reading between the lines of your message(s). If I'm not wrong, then perhaps this clarifies the objections. Curtis From owner-mpls@UU.NET Thu Mar 16 14:40:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15601 for ; Thu, 16 Mar 2000 14:40:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiguo02958; Thu, 16 Mar 2000 19:40:11 GMT Received: by mail-control.mail.uu.net id QQiguo22720 for mpls-outgoing; Thu, 16 Mar 2000 19:39:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiguo22711 for ; Thu, 16 Mar 2000 19:39:43 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiguo27862 for ; Thu, 16 Mar 2000 14:39:26 -0500 (EST) Received: from mail-green.research.att.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQiguo02383 for ; Thu, 16 Mar 2000 19:39:26 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 98DC41E03D; Thu, 16 Mar 2000 14:39:25 -0500 (EST) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id OAA11436; Thu, 16 Mar 2000 14:39:24 -0500 (EST) Reply-To: From: "John Strand" To: "'Yakov Rekhter'" Cc: Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 14:39:16 -0500 Message-ID: <00ea01bf8f7f$51c3fac0$3e82cf87@pcstranded.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200003161545.HAA10354@omega.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA15601 Yakov, I agree that an MPLS TE-based control plane ought to be able to support both models, and hope that the charter will be reworded accordingly. Likewise I'd hope that the clause about making physical topology information available to Network Layer working procedures will be reworded to indicate that this is an option to be supported. I'd also like to suggest that BGP be kept in-scope explicitly. I think that dealing with multi-domain issues will considerably increase the applicability of the new control plane. Section 3.1 of draft-rstb-optical-signaling-framework-00.txt gives one important driver for this; another will arise as optical networking pushes out to involve CLEC's and other access providers and also extends internationally. John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com ************************************************************************* Yakov Rekhter wrote: >John, >> I'd like to reinforce these concerns. It seems to me that defining the >> scope of this work to cover only peer-to-peer models of router/OXC >> interactions would drastically limit its value in the short-to-medium >> term at least. Similarly with disclosure of physical topology >> information. Recent OIF contributions from many of the principal >> players suggest that further study of these issues before limiting work >> to a single model is needed, as does draft >> draft-rstb-optical-signaling-framework-00.txt. >I would assume that the same control plane based on MPLS TE could be >used to support both the peer and the overlay model (as well as a mixture >of both). With this in mind I would suggest that the MPLS WG should >focus on defining the extension to the current MPLS TE protocols (ISIS, >OSPF, RSVP, CR-LDP) to handle Optical LSRs and SDH-LSRs. >Yakov. From owner-mpls@UU.NET Thu Mar 16 14:41:43 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16378 for ; Thu, 16 Mar 2000 14:41:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiguo07059; Thu, 16 Mar 2000 19:41:43 GMT Received: by mail-control.mail.uu.net id QQiguo22866 for mpls-outgoing; Thu, 16 Mar 2000 19:41:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiguo22824 for ; Thu, 16 Mar 2000 19:40:54 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiguo27913 for ; Thu, 16 Mar 2000 14:39:49 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiguo02578 for ; Thu, 16 Mar 2000 19:39:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA23378 for mpls@uu.net; Thu, 16 Mar 2000 14:39:47 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiguo22700 for ; Thu, 16 Mar 2000 19:39:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiguo02537 for ; Thu, 16 Mar 2000 14:39:07 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQiguo04452 for ; Thu, 16 Mar 2000 19:39:02 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA19323 for ; Thu, 16 Mar 2000 14:39:01 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA20665 for ; Thu, 16 Mar 2000 14:39:00 -0500 (EST) Message-Id: <200003161939.OAA20665@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Drafts without presentations Date: Thu, 16 Mar 2000 14:39:00 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk I don't believe I've received requests to present the following drafts. draft-wright-mpls-er-interwork-00.txt draft-muthukrishnan-mpls-corevpn-arch-00.txt draft-martini-l2circuit-trans-mpls-00.txt draft-haskin-mpls-fast-reroute-03.txt draft-rosen-mpls-profiles-00.txt draft-ietf-mpls-te-feed-00.txt draft-rosen-rfc2547bis-00.txt draft-basak-mpls-oxc-issues-01.txt If I've overlooked something please let me know. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Mar 16 14:45:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18012 for ; Thu, 16 Mar 2000 14:45:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigup06612; Thu, 16 Mar 2000 19:45:44 GMT Received: by mail-control.mail.uu.net id QQigup23306 for mpls-outgoing; Thu, 16 Mar 2000 19:45:04 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiguo23136 for ; Thu, 16 Mar 2000 19:44:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiguo03527 for ; Thu, 16 Mar 2000 14:44:51 -0500 (EST) Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63]) id QQiguo10012 for ; Thu, 16 Mar 2000 19:44:51 GMT Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Mar 2000 11:44:09 -0800 Message-ID: <337055FBC675D311A85D00508B5A9C4F254215@u-mail.rd.francetelecom.com> From: CATANZARITI Sergio FTR&D/TI To: "'John Drake'" , "'curtis@avici.com'" , Yakov Rekhter Cc: jls@research.att.com, CATANZARITI Sergio FTR&D/TI , "'Chip Sharp'" , mpls@UU.NET Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 11:44:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8F7F.FE581B0E" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8F7F.FE581B0E Content-Type: text/plain; charset="iso-8859-1" I do believe that the problem, raised by Curtis, of low grade of reliability of network state information in the optical case is an example on how it is still premature to choose a specific network model without having first understood all the issues around existing (and enhanced) protocol and mechanisms that would be necessary in the automatic optical switched networks vs. permanent/semi-permanent ones, source-routing vs. static routing, and so on. In a way, all that is orthogonal to the specific model. So, let us focus first on solving problems and adapting/enhancing protocol machinery (if possible), like draft-ceuppens-mpls-optical-00.txt draft tries to do it, and then focus on the model, not ignoring the fact that the operators PMO (present mode of operations), and other business/commercial issues, will have huge impact on the endorsement of the model (like it happened in the IP over ATM case). Sergio P.S. Why are you (and so do I accordingly) not CCing the IP over Optics BoF list? Any specific reason? > -------------------------------------------------------------------- > Sergio Catanzariti > Senior Project Manager, Technology Integration > France Telecom R&D > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------- > > > -----Original Message----- > From: John Drake [SMTP:jdrake@chromisys.com] > Sent: Thursday, March 16, 2000 11:23 AM > To: 'curtis@avici.com'; Yakov Rekhter > Cc: jls@research.att.com; 'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp'; > mpls@UU.NET > Subject: RE: Optical IP activities > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Performance Monitoring in Photonic Networks in > support > of MPL(ambda)S > Author(s) : L. Ceuppens, D. Blumenthal, J. Drake, > J. Chrostowski, W. Edwards > Filename : draft-ceuppens-mpls-optical-00.txt > Pages : 11 > Date : 10-Mar-00 > > Realizing the important role that photonic switches can play in > data-centric networks, work has been going on within the IETF to > combine the control plane of MPLS (more specifically traffic > engineering) with the point-and-click provisioning capabilities of > photonic switches [1]. This document outlines a proposal to expand > this initiative to include DWDM, OADM and ATM systems. It also > proposes to expand the work beyond simple establishment of optical > paths and include optical performance monitoring and management. The > combined path routing and performance information that will be > carried and shared between these network elements will allow the > elements or element management system (EMS) to adequately assess the > 'health' of an optical path (which can be a wavelength or fiber > strand). The routers and/or ATM switches at the edges of the > photonic network will then use this information to dynamically > manage the millions of wavelengths available in the photonic layer. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ceuppens-mpls-optical-00.txt > > > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@avici.com] > Sent: Thursday, March 16, 2000 11:04 AM > To: Yakov Rekhter > Cc: jls@research.att.com; 'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp'; > mpls@UU.NET > Subject: Re: Optical IP activities > > > > In message <200003161545.HAA10354@omega.cisco.com>, Yakov Rekhter writes: > > John, > > > > > I'd like to reinforce these concerns. It seems to me that defining the > > > scope of this work to cover only peer-to-peer models of router/OXC > > > interactions would drastically limit its value in the short-to-medium > > > term at least. Similarly with disclosure of physical topology > > > information. Recent OIF contributions from many of the principal > > > players suggest that further study of these issues before limiting > work > > > to a single model is needed, as does draft > > > draft-rstb-optical-signaling-framework-00.txt. > > > > I would assume that the same control plane based on MPLS TE could be > > used to support both the peer and the overlay model (as well as a > mixture > > of both). With this in mind I would suggest that the MPLS WG should > > focus on defining the extension to the current MPLS TE protocols (ISIS, > > OSPF, RSVP, CR-LDP) to handle Optical LSRs and SDH-LSRs. > > > > Yakov. > > > [Disclaimer: I'm guessing at other people's objections so apply a > large grain of salt unless confirmed.] > > I'm guessing that some of the objections to using MPLS as a means to > control the optical crossconnects come from the prolems of attenuation > and signal degradation (dispersion, etc) that are cummulative. > Determining whether an LSP path is feasible may not be a simple as > checking the bandwidth constraints on the legs of the path if there > are no OEO conversions at the hops. > > If that is what John was getting at, then John may be trying to tell > us that it is premature to try to come up with means to quantify the > restrictions imposed by attenuation and signal degradation such that > the ingress can reliably predict LSP path feasibility. > > btw- Some vendors may also not be looking forward to sharing these > characteristics (attenuation, dispersion, etc) openly as would be > necessary if advertising them through a vendor independent control > protocol, even if we knew how to express them and knew how to > accumulate the effects. > > If this is the objection, its worth noting that the objection may not > apply if OEO is done everywhere (but it may cost more to do that). > > Someone (John in particular, Chip, Sergio also) please correct me if > I'm wrong about my assumption. If so, I appologize for incorrectly > reading between the lines of your message(s). If I'm not wrong, then > perhaps this clarifies the objections. > > Curtis ------_=_NextPart_001_01BF8F7F.FE581B0E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical IP activities

    I do believe that the problem, raised = by Curtis, of low grade of reliability of network state information in = the optical case is an example on how it is still premature to choose a = specific network model without having first understood all the issues = around existing (and enhanced) protocol and mechanisms that would be = necessary in the automatic optical switched networks vs. = permanent/semi-permanent ones, source-routing vs. static routing, and = so on. In a way, all that is orthogonal to the specific model. So, let = us focus first on solving problems and adapting/enhancing protocol = machinery (if possible), like draft-ceuppens-mpls-optical-00.txt draft = tries to do it, and then focus on the model, not ignoring the fact that = the operators PMO (present mode of operations), and other = business/commercial issues, will have huge impact on the endorsement of = the model (like it happened in the IP over ATM case).

      = Sergio

     P.S. Why are = you (and so do I accordingly) not CCing the IP over Optics BoF list? = Any specific reason?


    ---------------------------------------------------------= -----------
    Sergio = Catanzariti
    Senior Project = Manager, Technology Integration
    France Telecom = R&D
    1000 Marina = Boulevard Suite 300
    Brisbane CA = 94005
    Tel. = 650-875-1526
    Fax. = 650-875-1505
    email:sergio.catanzariti@rd.francetelecom.com =
    ---------------------------------------------------------= -----------


    -----Original Message-----
    From:   John Drake [SMTP:jdrake@chromisys.com]
    Sent:   Thursday, March 16, 2000 11:23 AM
    To:     'curtis@avici.com'; Yakov Rekhter
    Cc:     jls@research.att.com; 'CATANZARITI Sergio FTR&D/TI'; = 'Chip Sharp'; mpls@UU.NET
    Subject:       = RE: Optical IP activities

    A New Internet-Draft is = available from the on-line Internet-Drafts
    directories.


            Title   =         : Performance Monitoring in = Photonic Networks in
    support
               &= nbsp;           &= nbsp;  of MPL(ambda)S
            Author(s)       : L. = Ceuppens, D. Blumenthal,  J. Drake,
               &= nbsp;           &= nbsp;  J. Chrostowski, W. Edwards
            Filename        = : draft-ceuppens-mpls-optical-00.txt
            Pages   =         : 11
            Date    =         : 10-Mar-00
           =20
    Realizing the important role = that photonic switches can play in
    data-centric networks, work has = been going on within the IETF to
    combine the control plane of = MPLS (more specifically traffic
    engineering) with the = point-and-click provisioning capabilities of
    photonic switches [1]. This = document outlines a proposal to expand
    this initiative to include = DWDM, OADM and ATM systems. It also
    proposes to expand the work = beyond simple establishment of optical
    paths and include optical = performance monitoring and management. The
    combined path routing and = performance information that will be
    carried and shared between = these network elements will allow the
    elements or element management = system (EMS) to adequately assess the
    'health' of an optical path = (which can be a wavelength or fiber
    strand). The routers and/or ATM = switches at the edges of the
    photonic network will then use = this information to dynamically
    manage the millions of = wavelengths available in the photonic layer.

    A URL for this Internet-Draft = is:
    http://www.ietf.org/internet-drafts/draft-ceuppens-mpl= s-optical-00.txt


    -----Original = Message-----
    From: Curtis Villamizar = [mailto:curtis@avici.com<= FONT SIZE=3D2 FACE=3D"Courier New">]
    Sent: Thursday, March 16, 2000 = 11:04 AM
    To: Yakov Rekhter
    Cc: jls@research.att.com; = 'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp';
    mpls@UU.NET
    Subject: Re: Optical IP = activities



    In message = <200003161545.HAA10354@omega.cisco.com>, Yakov Rekhter = writes:
    > John,
    >
    > > I'd like to reinforce = these concerns. It seems to me that defining the
    > > scope of this work to = cover only peer-to-peer models of router/OXC
    > > interactions would = drastically limit its value in the short-to-medium
    > > term at least. = Similarly with disclosure of physical topology
    > > information. Recent = OIF contributions from many of the principal
    > > players suggest that = further study of these issues before limiting work
    > > to a single = model  is needed, as does draft
    > > = draft-rstb-optical-signaling-framework-00.txt.
    >
    > I would assume that the = same control plane based on MPLS TE could be
    > used to support both the = peer and the overlay model (as well as a mixture
    > of both).  With this = in mind I would suggest that the MPLS WG should
    > focus on defining the = extension to the current MPLS TE protocols (ISIS,
    > OSPF, RSVP, CR-LDP) to = handle Optical LSRs and SDH-LSRs.
    >
    > Yakov.


    [Disclaimer: I'm guessing at = other people's objections so apply a
    large grain of salt unless = confirmed.]

    I'm guessing that some of the = objections to using MPLS as a means to
    control the optical = crossconnects come from the prolems of attenuation
    and signal degradation = (dispersion, etc) that are cummulative.
    Determining whether an LSP path = is feasible may not be a simple as
    checking the bandwidth = constraints on the legs of the path if there
    are no OEO conversions at the = hops.

    If that is what John was getting = at, then John may be trying to tell
    us that it is premature to try = to come up with means to quantify the
    restrictions imposed by = attenuation and signal degradation such that
    the ingress can reliably = predict LSP path feasibility.

    btw- Some vendors may also not = be looking forward to sharing these
    characteristics (attenuation, = dispersion, etc) openly as would be
    necessary if advertising them = through a vendor independent control
    protocol, even if we knew how = to express them and knew how to
    accumulate the effects.

    If this is the objection, its = worth noting that the objection may not
    apply if OEO is done everywhere = (but it may cost more to do that).

    Someone (John in particular, = Chip, Sergio also) please correct me if
    I'm wrong about my = assumption.  If so, I appologize for incorrectly
    reading between the lines of = your message(s).  If I'm not wrong, then
    perhaps this clarifies the = objections.

    Curtis

------_=_NextPart_001_01BF8F7F.FE581B0E-- From owner-mpls@UU.NET Thu Mar 16 14:57:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22094 for ; Thu, 16 Mar 2000 14:57:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigup23144; Thu, 16 Mar 2000 19:57:27 GMT Received: by mail-control.mail.uu.net id QQigup23847 for mpls-outgoing; Thu, 16 Mar 2000 19:56:59 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigup23840 for ; Thu, 16 Mar 2000 19:56:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigup00347 for ; Thu, 16 Mar 2000 14:56:20 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigup13774 for ; Thu, 16 Mar 2000 19:56:17 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id OAA18479; Thu, 16 Mar 2000 14:51:22 -0500 Message-ID: <38D13E21.98216D0E@tellium.com> Date: Thu, 16 Mar 2000 15:03:45 -0500 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jls@research.att.com CC: "'Yakov Rekhter'" , mpls@UU.NET Subject: Re: Optical IP activities References: <00ea01bf8f7f$51c3fac0$3e82cf87@pcstranded.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: John Strand wrote: > Yakov, > I agree that an MPLS TE-based control plane ought to be able to support > both models, and hope that the charter will be reworded accordingly. > Likewise I'd hope that the clause about making physical topology > information available to Network Layer working procedures will be > reworded to indicate that this is an option to be supported. I agree with this completely. In general, I find the MPLambdaS push is on IP transport over optical networks, but not necessarily addressing optical networking control needs (specifically, optical internetworking). It would be nice to consider the requirements from the optical side, and then look at solutions. Regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Mar 16 14:57:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22212 for ; Thu, 16 Mar 2000 14:57:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigup16010; Thu, 16 Mar 2000 19:57:41 GMT Received: by mail-control.mail.uu.net id QQigup23859 for mpls-outgoing; Thu, 16 Mar 2000 19:57:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigup23846 for ; Thu, 16 Mar 2000 19:56:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigup00413 for ; Thu, 16 Mar 2000 14:56:27 -0500 (EST) Received: from mail-green.research.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQigup21259 for ; Thu, 16 Mar 2000 19:56:26 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 4CAA91E03D; Thu, 16 Mar 2000 14:56:22 -0500 (EST) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id OAA12479; Thu, 16 Mar 2000 14:56:21 -0500 (EST) Reply-To: From: "John Strand" To: "'John Drake'" Cc: Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 14:56:13 -0500 Message-ID: <00f601bf8f81$aff90930$3e82cf87@pcstranded.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA22212 John, Thanks for the Awduche reference which also supports expanding the MPLS charter to cover both overlay and peer models. Your statement about the OIF isn't completely up to date. At their most recent meeting they started a signalling WG to produce specifications for service discovery, lightpath attributes, transporting signaling information, and NNI. They identified this work as being "..closely related to work at IETF ... Technical documents will be exchanged as appropriate." John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: John Drake [mailto:jdrake@chromisys.com] Sent: Thursday, March 16, 2000 11:16 AM To: 'Yakov Rekhter'; jls@research.att.com Cc: 'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp'; mpls@UU.NET Subject: RE: Optical IP activities The Awduche draft, which provided the impetus for the MPL(ambda)S work, specificaly states that both the overlay model, as well as the peer model, will be supported. Further, neither the ODSI nor the OIF are currently working to define the control plane for a network of OXCs (or PXCs), so it doesn't seem as though there are overlapping activities. John From owner-mpls@UU.NET Thu Mar 16 15:04:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24894 for ; Thu, 16 Mar 2000 15:04:12 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiguq25964; Thu, 16 Mar 2000 20:04:13 GMT Received: by mail-control.mail.uu.net id QQiguq28576 for mpls-outgoing; Thu, 16 Mar 2000 20:03:39 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiguq28567 for ; Thu, 16 Mar 2000 20:03:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigup07489 for ; Thu, 16 Mar 2000 14:59:49 -0500 (EST) Received: from hercules by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQigup20232 for ; Thu, 16 Mar 2000 19:59:49 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id LAA01023; Thu, 16 Mar 2000 11:59:56 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 11:59:56 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A6346834@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Joan Cucchiara'" , "'Arun Viswanathan'" , "'George Swallow'" Cc: "'Thomas D. Nadeau'" , "'Adrian Farrel'" , "'mpls@UU.NET'" , "'vsriniva@cosinecom.com'" Subject: RE: LSR MIB WG Last Call Date: Thu, 16 Mar 2000 11:59:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Joan, > Arun, > > It was not clear to me from reading the MIB. No where does > it say, "for LPD this means ...." or "this object/table does > not apply to LDP". For example, the XC table goes to > great length to discuss p-to-mp and mp-to-p types of Cross Connects > and I don't understand what this has to do with LDP which > is next-hop peer. Especially, p-to-mp which seems to me to > imply some sort of multicast when thinking about LDP, but > maybe that's just me. LSR MIB is modelling nothing but the LSR as described in the MPLS Arch. The goal has always been to provide a common entity that modelled an LSR for use by all MPLS protocols (LDP included). Therefore, the LSR MIB is agnostic about MPLS protocols. LSR is nothing but labels and connections, that is, models LSPs. > > Secondly, I thought configuration of LDP was a new addition > because to the > change under Feature Checklist: It is not a new addition. I am glad you pointed this out. See what it says in Rev 00. > > "The MIB should be able to support both manually configured LSPs > as well as those configured via LDP and/or RSVP signalling". > > The prior rev said "CR-LDP and/or RSVP signalling". In Rev 00 it said: - The MIB should be able to support both manually configured LSPs as well as via LDP and/or RSVP signaling. In Rev 01 it said: - The MIB should be able to support both manually configured LSPs as well as those configured via CR-LDP and/or RSVP signaling. In Rev 02 it says: - The MIB should be able to support both manually configured LSPs as well as those configured via LDP and/or RSVP signaling. I think it should read: - The MIB should be able to support both manually configured LSPs as well as those configured via any MPLS signaling protocol. It got inadvertently changed by one of the author while editing for rev 01 and it got corrected in rev 02. I think it should be changed to the last suggestion. > > > > > LDP doesn't constitute an LSR. The label and connection > > resources are common to every MPLS protocol and hence the > > LSR MIB. It is just seems absurd to me that LDP requires > > to manage its own label space and connections instead > > of a single entity that manages label and connection resources > > for ALL MPLS protocols. > > Arun, again I am concerned about these statements. It is > not absurd if you consider that there was not an alternative, > nor is there an existing alternative. Separating these > tables from the LDP MIB may or may not be adequate for > all 3 MPLS protocols. I don't know at this point. I don't know what you mean by 'these tables'. I was only referring to the LIB table in LDP MIB. Instead of the LIB table use the XC table in LSR MIB which provides the same capability (and more). That is, have the FEC table in LDP MIB have a row pointer to the XC table in the LSR MIB. This is the ONLY change that I am suggesting we make in the LDP MIB. The basic idea behind the LSR MIB is not to have every protocol model its own LSP. The way the LIB table is defined in the LDP MIB is under powered even by LDP requirements. For example: - there is no notion of a label stack - label performance objects - finding the next-hop for a outgoing label - being able to manipulate the EXP bits > > If the LSR MIB would like to configure label ranges, then > certainly the work for this in the LDP MIB could be used > as a starting point. Feel free to copy it into the LSR MIB > as a starting point. However, it is not appropriate for > the LDP MIB to be held up waiting for the LSR MIB. There's no need for the LSR MIB to support several ranges to support LDP MIB. The LDP MIB continues to have its own label ranges table. > > MIBs often copy in Textual Conventional at the same time > so they can advance without being held up by one another. > It is just not accepted practice to hold up one MIB > for another, especially when the other one is NOT necessary > to support the first. The LSR MIB is not needed for the LDP MIB. No the LDP MIB requires LSR MIB for modelling the LSPs. This precisely the reason why the WG choose to spin off the LSR MIB as a separate document. Besides, we are already requesting for a last call on the LSR MIB. I have seen objections from only two people (one of them being yourself) and either of them haven't quantified their objection yet. I have posted the diffs of all the versions for your reference. > > If the LSR MIB intends to support configuring label ranges > then I would like to raise a couple of issue: > > * I think that separate MIBs which for LDP, CR-LDP and RSVP-MPLS > should be developed for the very simple reason that an LSR may > only want to run one protocol. Thus, supporting the LSR MIB > is not needed until there are two or more MPLS protocols on the > same LSR. > > Certainly, if all 3 of these MIBs could point to some label range > config tables in the LSR MIB (or elsewhere), then that is an > alternative. > Today this is NOT the case. Wrong. See TE MIB. And again, there is no need for the LSR MIB to support multiple label ranges. If the protocol MIBs such as LDP MIB have such requirement then they maintain their own ranges. > > * A few weeks ago there was quite a bit of discussion on > what it meant to modify a label range for LDP. Modifying a > Label Range could have potential ripple effects throughout most > of the tables in the LDP MIB. > Is the LSR MIB going to maintain state for all the different > protocols? I would disagree for the reasons stated above: > specifically, > an LSR should be able to run only one MPLS protocol without > the LSR MIB. What if there is no protocol and LSPs need to be provisioned? > It is not clear to me where the LSR MIB is drawing the lines, > and I would like to understand this prior to the LSR MIB going to > last call. See the feature check (section 4) for the LSR MIB. Its been there ALL ALONG. Please don't make it look like a surprise expansion of scope for actually not having read it. > > I also would like to understand if this configuring of label ranges > is going to be part of the LSR MIB, or yet another draft? No. It is not required. See above. > > In a way, I think that it is "too soon" for the LSR MIB. Did you see the dates on the rev diffs I posted? What do you mean "too soon"? Would you care to share your rule of thumb in accessing this? Be specific. > If all > 3 protocols already had existing MIBs, then it would be much clearer > to me where the likenesses were and what could be separated out > into an LSR MIB. We need the MIB today. And it serves the purpose of all existing protocols. > > I am concerned that the LSR MIB is actually trying > to support CR-LDP and MPLS-RSVP specific objects and is not > maintaining the abstraction level which was the original goal. Can you explin to me how? Once again for your benefit, though LDP has multiple label ranges requirement, it fits in this model with the minimal change I suggested above. -arun > > -Joan > From owner-mpls@UU.NET Thu Mar 16 15:27:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02635 for ; Thu, 16 Mar 2000 15:27:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigur10109; Thu, 16 Mar 2000 20:26:59 GMT Received: by mail-control.mail.uu.net id QQigur03621 for mpls-outgoing; Thu, 16 Mar 2000 20:26:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigur03616 for ; Thu, 16 Mar 2000 20:26:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigur12743 for ; Thu, 16 Mar 2000 15:26:33 -0500 (EST) Received: from mail-green.research.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQigur23691 for ; Thu, 16 Mar 2000 20:26:33 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 243A21E02D; Thu, 16 Mar 2000 15:26:33 -0500 (EST) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id PAA14706; Thu, 16 Mar 2000 15:26:31 -0500 (EST) Reply-To: From: "John Strand" To: , "'Yakov Rekhter'" Cc: Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 15:26:24 -0500 Message-ID: <010501bf8f85$e73ed420$3e82cf87@pcstranded.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200003161904.OAA38235@curtis-lt.avici.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id PAA02635 Curtis, There definitely are technical issues that will need to be dealt with before MPLS TE can be applied to transparent (all-optical) optical networks, as you point out. However I'm assuming that we'll be able to work through these, particularly if transparent and opaque technologies are kept in separate routing domains. So I definitely support moving ahead on an MPLS-inspired control plane for the OL. I also see a definite role for the peer model, particularly when used as part of a "Virtual Optical Network" (the OL equivalent of a VPN). However my Email was triggered by a concern that overlay models and non-disclosure of physical topology information was going to be ruled out-of-scope by the proposed charter, which I think would drastically reduce interest in any proposals from this group. John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: Curtis Villamizar [mailto:curtis@avici.com] Sent: Thursday, March 16, 2000 2:04 PM To: Yakov Rekhter Cc: jls@research.att.com; 'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp'; mpls@UU.NET Subject: Re: Optical IP activities In message <200003161545.HAA10354@omega.cisco.com>, Yakov Rekhter writes: > John, > > > I'd like to reinforce these concerns. It seems to me that defining the > > scope of this work to cover only peer-to-peer models of router/OXC > > interactions would drastically limit its value in the short-to-medium > > term at least. Similarly with disclosure of physical topology > > information. Recent OIF contributions from many of the principal > > players suggest that further study of these issues before limiting work > > to a single model is needed, as does draft > > draft-rstb-optical-signaling-framework-00.txt. > > I would assume that the same control plane based on MPLS TE could be > used to support both the peer and the overlay model (as well as a mixture > of both). With this in mind I would suggest that the MPLS WG should > focus on defining the extension to the current MPLS TE protocols (ISIS, > OSPF, RSVP, CR-LDP) to handle Optical LSRs and SDH-LSRs. > > Yakov. [Disclaimer: I'm guessing at other people's objections so apply a large grain of salt unless confirmed.] I'm guessing that some of the objections to using MPLS as a means to control the optical crossconnects come from the prolems of attenuation and signal degradation (dispersion, etc) that are cummulative. Determining whether an LSP path is feasible may not be a simple as checking the bandwidth constraints on the legs of the path if there are no OEO conversions at the hops. If that is what John was getting at, then John may be trying to tell us that it is premature to try to come up with means to quantify the restrictions imposed by attenuation and signal degradation such that the ingress can reliably predict LSP path feasibility. btw- Some vendors may also not be looking forward to sharing these characteristics (attenuation, dispersion, etc) openly as would be necessary if advertising them through a vendor independent control protocol, even if we knew how to express them and knew how to accumulate the effects. If this is the objection, its worth noting that the objection may not apply if OEO is done everywhere (but it may cost more to do that). Someone (John in particular, Chip, Sergio also) please correct me if I'm wrong about my assumption. If so, I appologize for incorrectly reading between the lines of your message(s). If I'm not wrong, then perhaps this clarifies the objections. Curtis From owner-mpls@UU.NET Thu Mar 16 15:27:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02988 for ; Thu, 16 Mar 2000 15:27:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigur10945; Thu, 16 Mar 2000 20:27:49 GMT Received: by mail-control.mail.uu.net id QQigur03644 for mpls-outgoing; Thu, 16 Mar 2000 20:27:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigur03639 for ; Thu, 16 Mar 2000 20:27:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigur08136 for ; Thu, 16 Mar 2000 15:26:58 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQigur10059 for ; Thu, 16 Mar 2000 20:26:57 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Thu, 16 Mar 2000 15:26:49 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CF3F@email.quarrytech.com> From: "Abes, Andi" To: mpls@UU.NET Cc: lberger@labn.net, dhg@juniper.net, tony1@home.net, vijay@torrentnet.com, swallow@cisco.com Subject: RE: I-D ACTION:draft-ietf-mpls-rsvp-lsp-tunnel-05.txt Date: Thu, 16 Mar 2000 15:26:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I was reading it again, and still didn't understand it. Please help me understand what is the meaning of the "Merging permitted" flag in the Session Attributes. If the originator of the PATH message wants to prevent other routers from merging his session - it can set the extended tunnel ID to his IP address (as is specifically described in the draft). In any case, this type of merging only reduces the number of reservations - it will still generate the same amount of control traffic and state in the core routers. Could it be that this flag is meant to allow merging of PATH messages ? Is it meant to allow routers to stack sessions ? Such that if the flag is set, intermediate routers are allowed, and otherwise not ? In any case, a slightly longer explanation of this flag would be very beneficial (at least to me ;>). Andi Abes, Quarry Technologies From owner-mpls@UU.NET Thu Mar 16 15:36:54 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06102 for ; Thu, 16 Mar 2000 15:36:52 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigus03069; Thu, 16 Mar 2000 20:36:53 GMT Received: by mail-control.mail.uu.net id QQigus04138 for mpls-outgoing; Thu, 16 Mar 2000 20:36:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigus04133 for ; Thu, 16 Mar 2000 20:36:18 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigus09435 for ; Thu, 16 Mar 2000 15:36:10 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigus02297 for ; Thu, 16 Mar 2000 20:36:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA04125 for mpls@uu.net; Thu, 16 Mar 2000 15:36:08 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigus04038 for ; Thu, 16 Mar 2000 20:35:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigus09387 for ; Thu, 16 Mar 2000 15:35:47 -0500 (EST) Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQigus01950 for ; Thu, 16 Mar 2000 20:35:46 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA00225; Thu, 16 Mar 2000 12:35:44 -0800 (PST) Message-Id: <200003162035.MAA00225@omega.cisco.com> To: jls@research.att.com cc: mpls@UU.NET Subject: Re: Optical IP activities In-reply-to: Your message of "Thu, 16 Mar 2000 14:39:16 EST." <00ea01bf8f7f$51c3fac0$3e82cf87@pcstranded.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <221.953238943.1@cisco.com> Date: Thu, 16 Mar 2000 12:35:44 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk John, > I agree that an MPLS TE-based control plane ought to be able to support > both models, and hope that the charter will be reworded accordingly. > Likewise I'd hope that the clause about making physical topology > information available to Network Layer working procedures will be > reworded to indicate that this is an option to be supported. Agreed. And to address this I would suggest we'll add the following to the WG charter: Use of MPLS control plane with OXCs should allow two basic architectural options: - One option is to use different instances of the control plane in the OTN (OXC) and IP (LSR) domains. In this situation, each instance of the control plane will operate independent of the other. - Another option is to use a single instance of the control plane that subsumes and spans LSRs and OXCs. > I'd also like to suggest that BGP be kept in-scope explicitly. I think that > dealing with multi-domain issues will considerably increase the > applicability of the new control plane. Section 3.1 of > draft-rstb-optical-signaling-framework-00.txt gives one important > driver for this; another will arise as optical networking pushes > out to involve CLEC's and other access providers and also extends > internationally. May I suggest that we'll move "one step at a time". That is, we first settle on how to use MPLS Traffic Engineering to control OXCs (and/or SONET cross connects) within a single routing domain. The next step would be to extend this across domain's boundaries - that is where BGP may come into play. In the context of the MPLS WG charter that means that we could always extend it at some future point to include multi-domain operations. Yakov. From owner-mpls@UU.NET Thu Mar 16 15:42:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08564 for ; Thu, 16 Mar 2000 15:42:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigus21815; Thu, 16 Mar 2000 20:42:36 GMT Received: by mail-control.mail.uu.net id QQigus04384 for mpls-outgoing; Thu, 16 Mar 2000 20:42:04 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigus04379 for ; Thu, 16 Mar 2000 20:41:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigus15111 for ; Thu, 16 Mar 2000 15:41:37 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigus06206 for ; Thu, 16 Mar 2000 20:41:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA05192 for mpls@uu.net; Thu, 16 Mar 2000 15:41:36 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigus04255 for ; Thu, 16 Mar 2000 20:40:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigus14963 for ; Thu, 16 Mar 2000 15:40:45 -0500 (EST) Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQigus05651 for ; Thu, 16 Mar 2000 20:40:44 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA00928; Thu, 16 Mar 2000 12:40:43 -0800 (PST) Message-Id: <200003162040.MAA00928@omega.cisco.com> To: jls@research.att.com cc: mpls@UU.NET Subject: Re: Optical IP activities In-reply-to: Your message of "Thu, 16 Mar 2000 15:26:24 EST." <010501bf8f85$e73ed420$3e82cf87@pcstranded.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <923.953239242.1@cisco.com> Date: Thu, 16 Mar 2000 12:40:43 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk John, > Curtis, > There definitely are technical issues that will need to be dealt with > before MPLS TE can be applied to transparent (all-optical) optical networks, > as you > point out. However I'm assuming that we'll be able to work through > these, particularly if transparent and opaque technologies are kept in > separate routing domains. So I definitely support moving ahead on an > MPLS-inspired control plane for the OL. I also see a definite role > for the peer model, particularly when used as part of a "Virtual Optical > Network" (the OL equivalent of a VPN). However my Email was triggered > by a concern that overlay models and non-disclosure of physical topology > information was going to be ruled out-of-scope by the proposed charter, > which I think would drastically reduce interest in any proposals from > this group. Just to clarify, "non-disclosure of physical topology information" could occur in the peer model as well. One example of such "non-disclosure" is the "forwarding adjacency" construct (see draft-kompella-mpls-optical-00.txt). Another example is when you have multiple OSPF/ISIS areas (where an LSR sees only topology within its own area). Yakov. From owner-mpls@UU.NET Thu Mar 16 15:48:16 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10805 for ; Thu, 16 Mar 2000 15:48:16 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigut10551; Thu, 16 Mar 2000 20:48:18 GMT Received: by mail-control.mail.uu.net id QQigut04794 for mpls-outgoing; Thu, 16 Mar 2000 20:47:46 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigut04789 for ; Thu, 16 Mar 2000 20:47:37 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigut15995 for ; Thu, 16 Mar 2000 15:47:30 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigut09988 for ; Thu, 16 Mar 2000 20:47:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA06256 for mpls@uu.net; Thu, 16 Mar 2000 15:47:29 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigut04770 for ; Thu, 16 Mar 2000 20:47:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigut10813 for ; Thu, 16 Mar 2000 15:46:38 -0500 (EST) Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQigut09463 for ; Thu, 16 Mar 2000 20:46:37 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA01797; Thu, 16 Mar 2000 12:46:36 -0800 (PST) Message-Id: <200003162046.MAA01797@omega.cisco.com> To: CATANZARITI Sergio FTR&D/TI cc: mpls@UU.NET Subject: Re: Optical IP activities In-reply-to: Your message of "Thu, 16 Mar 2000 11:44:02 PST." <337055FBC675D311A85D00508B5A9C4F254215@u-mail.rd.francetelecom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1795.953239596.1@cisco.com> Date: Thu, 16 Mar 2000 12:46:36 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Sergio, > I do believe that the problem, raised by Curtis, of low grade of > reliability of network state information in the optical case is an example > on how it is still premature to choose a specific network model without > having first understood all the issues around existing (and enhanced) > protocol and mechanisms that would be necessary in the automatic optical > switched networks vs. permanent/semi-permanent ones, source-routing vs. > static routing, and so on. In a way, all that is orthogonal to the specific > model. So, let us focus first on solving problems and adapting/enhancing > protocol machinery (if possible), like draft-ceuppens-mpls-optical-00.txt > draft tries to do it, and then focus on the model, not ignoring the fact > that the operators PMO (present mode of operations), and other > business/commercial issues, will have huge impact on the endorsement of the > model (like it happened in the IP over ATM case). I agree with your suggestion that we should focus first on adapting/enhancing MPLS Traffic Engineering protocol machinery to handle OXCs. I think different customers may chose different models - the machinery should be able to support a wide range of choices from pure peer to pure overlay. Yakov. From owner-mpls@UU.NET Thu Mar 16 16:04:02 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17077 for ; Thu, 16 Mar 2000 16:04:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiguu11123; Thu, 16 Mar 2000 21:04:02 GMT Received: by mail-control.mail.uu.net id QQiguu09809 for mpls-outgoing; Thu, 16 Mar 2000 21:03:28 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiguu09798 for ; Thu, 16 Mar 2000 21:03:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiguu18490 for ; Thu, 16 Mar 2000 16:03:18 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiguu19859 for ; Thu, 16 Mar 2000 21:03:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA08572 for mpls@uu.net; Thu, 16 Mar 2000 16:03:16 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiguu08867 for ; Thu, 16 Mar 2000 21:02:40 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiguu18395 for ; Thu, 16 Mar 2000 16:02:33 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiguu19370 for ; Thu, 16 Mar 2000 21:02:33 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 16:00:52 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F878@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Adrian Farrel'" , "Thomas D. Nadeau" , dwilder@baynetworks.com Cc: mpls@UU.NET, "Arun Viswanathan (E-mail)" , Cheenu Srinivasan , Joan Cucchiara Subject: RE: LIB Table - LSR MIB v. LDP MIB Date: Thu, 16 Mar 2000 16:00:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Adrian has posed a good question, and I would also like to see the response. Thanks, Joan > -----Original Message----- > From: Adrian Farrel [mailto:AF@datcon.co.uk] > Sent: Wednesday, March 15, 2000 1:04 AM > To: Thomas D. Nadeau; dwilder@baynetworks.com > Cc: mpls@UU.NET; Arun Viswanathan (E-mail); Cheenu Srinivasan; > jcucchiara@brixnet.com > Subject: LIB Table - LSR MIB v. LDP MIB > > > Tom, you wrote in response to Dave in response to Arun... > > >>> I have the same objections to the current LDP MIB as Tom. The LIB > >>> and the FEC tables are not specific to LDP and do not belong here. > >>> The first one is part of the LSR MIB already and the second one > >>> should be in a separate packet classifier MIB. They > should be removed > >>> before the LDP MIB goes to last call. > > >>I'd rather a little redundancy than the to use the new proposed > >>MIB which hasn't had the scrutiny that the LDP MIB has had. > > >That may be true in terms of the new MPLS Packet > >Classifier MIB which deals most closely with the LDP > >FEC table. However, as Arun pointed out, the LIB Table > >contained in the LDP MIB is redundant with the LSR MIB. > >The LSR MIB has been out for quite a while now, and has been > >under as much scrutiny as the LDP MIB. > > It is true that some of the information contained in the LDP MIB's > LIB table is also contained in the LSR MIB, but consider > mplsLdpLibInLabelType, mplsLdpLibOutLabelType and > mplsLdpLibLspLastChange. > > Note also that to walk the 'LIB table' in the LSR MIB involves > walking the XC table and for each entry looking up the out > label and out interface in the Out Segment table. This is, > perhaps, less graceful. > > Did you consider putting a simple LIB table in the LSR MIB? > > Adrian > -- > Adrian Farrel mailto:af@datcon.co.uk > ATM, MPLS and Telecoms Development Group > Data Connection Ltd., Chester, UK > http://www.datcon.co.uk/ > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > From owner-mpls@UU.NET Thu Mar 16 16:44:40 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02473 for ; Thu, 16 Mar 2000 16:44:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiguw15678; Thu, 16 Mar 2000 21:44:41 GMT Received: by mail-control.mail.uu.net id QQiguw15893 for mpls-outgoing; Thu, 16 Mar 2000 21:44:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiguw15885 for ; Thu, 16 Mar 2000 21:44:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiguw24244 for ; Thu, 16 Mar 2000 16:43:51 -0500 (EST) Received: from lumen.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: magic03.kudonet.com [209.133.127.227]) id QQiguw14935 for ; Thu, 16 Mar 2000 21:43:50 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Mar 2000 13:46:26 -0800 Message-ID: From: John Drake To: "'jls@research.att.com'" , John Drake Cc: mpls@UU.NET Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 13:46:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk John, I was at the meeting and I think that my statement stands. Their first priority is a UNI interface, and their definition of NNI is network to network. Thanks, John -----Original Message----- From: John Strand [mailto:jls@research.att.com] Sent: Thursday, March 16, 2000 11:56 AM To: 'John Drake' Cc: mpls@UU.NET Subject: RE: Optical IP activities John, Thanks for the Awduche reference which also supports expanding the MPLS charter to cover both overlay and peer models. Your statement about the OIF isn't completely up to date. At their most recent meeting they started a signalling WG to produce specifications for service discovery, lightpath attributes, transporting signaling information, and NNI. They identified this work as being "..closely related to work at IETF ... Technical documents will be exchanged as appropriate." John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: John Drake [mailto:jdrake@chromisys.com] Sent: Thursday, March 16, 2000 11:16 AM To: 'Yakov Rekhter'; jls@research.att.com Cc: 'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp'; mpls@UU.NET Subject: RE: Optical IP activities The Awduche draft, which provided the impetus for the MPL(ambda)S work, specificaly states that both the overlay model, as well as the peer model, will be supported. Further, neither the ODSI nor the OIF are currently working to define the control plane for a network of OXCs (or PXCs), so it doesn't seem as though there are overlapping activities. John From owner-mpls@UU.NET Thu Mar 16 17:12:53 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13405 for ; Thu, 16 Mar 2000 17:12:52 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiguy09335; Thu, 16 Mar 2000 22:12:52 GMT Received: by mail-control.mail.uu.net id QQiguy25387 for mpls-outgoing; Thu, 16 Mar 2000 22:12:34 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiguy25375 for ; Thu, 16 Mar 2000 22:12:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiguy28002 for ; Thu, 16 Mar 2000 17:12:00 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiguy08426 for ; Thu, 16 Mar 2000 22:12:00 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id RAA23898; Thu, 16 Mar 2000 17:07:12 -0500 Message-ID: <38D15DF8.A7DD7E3F@tellium.com> Date: Thu, 16 Mar 2000 17:19:36 -0500 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: IP over Optical Framework Draft References: <200003162035.MAA00225@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: The following draft was submitted to internet-drafts last week, but I haven't seen an announcement yet. It is, however, available at http://www.ietf.org/internet-drafts/draft-ip-optical-framework-00.txt Regards, Bala ----------------------------------------------------------------------- IP over Optical Networks - A Framework J. Luciani, B. Rajagopalan, D. Awduche, B. Cain, and B. Jamoussi draft-ip-optical-framework-00.txt Abstract The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. A consensus is emerging in the industry on utilizing IP-centric protocols for the optical control plane [9, 10], as well as for dynamic bandwidth provisioning for IP services. Also, there has recently been significant activity in defining models for IP transport over optical networks, specifically, the routing and signaling aspects [2,6,7]. This draft attempts to define a framework for IP over Optical networks, considering both the IP control plane for optical networks as well as IP transport over optical networks (together referred to as "IP over optical networks"). Within this framework, we develop a common set of terms and concepts which allows to discuss these IP over optical technologies in a consistent fashion. Additionally, this draft surveys some architectural frameworks that might be useful and appropriate for the deployment of IP over hybrid optical networks that contain IP routers, WDM multiplexers, and optical cross-connects (OXCs). This document is complementary to the framework of Multiprotocol Lambda Switching proposed in [2]. -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Mar 16 17:20:43 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16526 for ; Thu, 16 Mar 2000 17:20:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiguz07366; Thu, 16 Mar 2000 22:20:42 GMT Received: by mail-control.mail.uu.net id QQiguz25928 for mpls-outgoing; Thu, 16 Mar 2000 22:20:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiguz25919 for ; Thu, 16 Mar 2000 22:20:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiguz28904 for ; Thu, 16 Mar 2000 17:20:06 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiguz06828 for ; Thu, 16 Mar 2000 22:20:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA19563 for mpls@uu.net; Thu, 16 Mar 2000 17:20:04 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiguz25895 for ; Thu, 16 Mar 2000 22:19:49 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiguz28860 for ; Thu, 16 Mar 2000 17:19:40 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQiguz06575 for ; Thu, 16 Mar 2000 22:19:39 GMT Received: from tnadeau-pc02 (ch2-dhcp134-171.cisco.com [161.44.134.171]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA06019; Thu, 16 Mar 2000 17:18:56 -0500 (EST) Message-Id: <4.2.2.20000316160059.00e01390@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 16 Mar 2000 17:10:26 -0500 To: Joan Cucchiara , "'Adrian Farrel'" , dwilder@baynetworks.com From: "Thomas D. Nadeau" Subject: RE: LIB Table - LSR MIB v. LDP MIB Cc: mpls@UU.NET, "Arun Viswanathan (E-mail)" , Cheenu Srinivasan , Joan Cucchiara In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F878@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_18262038==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_18262038==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, See Arun's answers to your other questions. > > Note also that to walk the 'LIB table' in the LSR MIB involves > > walking the XC table and for each entry looking up the out > > label and out interface in the Out Segment table. I would recommend gathering this information by walking the in/outSegment tables. The purpose of the XC tables is to tell you how the labels are swapped and which ones are currently in use (among other things). >This is, perhaps, less graceful. The MIB does provide the information you seek, and the NMS is then free to create a linear list of the labels it discovers later if it so desires. --Tom > > > > Adrian > > -- > > Adrian Farrel mailto:af@datcon.co.uk > > ATM, MPLS and Telecoms Development Group > > Data Connection Ltd., Chester, UK > > http://www.datcon.co.uk/ > > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > > > > --=====================_18262038==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

        See Arun's answers to your other questions.

> Note also that to walk the 'LIB table' in the LSR MIB involves
> walking the XC table and for each entry looking up the out
> label and out interface in the Out Segment table. 

        I would recommend gathering this information by walking
the in/outSegment tables. The purpose of the XC tables is to tell
you how the labels are swapped and which ones are currently in
use (among other things).

This is, perhaps, less graceful.

        The MIB does provide the information you seek,
and the NMS is then free to create a linear list of the
labels it discovers later if it so desires.

        --Tom


>
> Adrian
> --
> Adrian Farrel  mailto:af@datcon.co.uk
> ATM, MPLS and Telecoms Development Group
> Data Connection Ltd., Chester, UK
> http://www.datcon.co.uk/
> Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
>
> 
>
--=====================_18262038==_.ALT-- From owner-mpls@UU.NET Thu Mar 16 17:29:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20072 for ; Thu, 16 Mar 2000 17:29:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiguz23400; Thu, 16 Mar 2000 22:29:26 GMT Received: by mail-control.mail.uu.net id QQiguz26426 for mpls-outgoing; Thu, 16 Mar 2000 22:28:54 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiguz26417 for ; Thu, 16 Mar 2000 22:28:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiguz29805 for ; Thu, 16 Mar 2000 17:28:43 -0500 (EST) Received: from hercules by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQiguz11782 for ; Thu, 16 Mar 2000 22:28:42 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id OAA08605; Thu, 16 Mar 2000 14:28:38 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 14:28:38 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A6346835@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Joan Cucchiara'" , "'Adrian Farrel'" , "'Thomas D. Nadeau'" , "'dwilder@baynetworks.com'" Cc: "'mpls@UU.NET'" , "'Arun Viswanathan (E-mail)'" , "'Cheenu Srinivasan'" Subject: RE: LIB Table - LSR MIB v. LDP MIB Date: Thu, 16 Mar 2000 14:28:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Joan, > > Adrian has posed a good question, and I would > also like to see the response. > > Thanks, Joan > > > > -----Original Message----- > > From: Adrian Farrel [mailto:AF@datcon.co.uk] > > Sent: Wednesday, March 15, 2000 1:04 AM > > To: Thomas D. Nadeau; dwilder@baynetworks.com > > Cc: mpls@UU.NET; Arun Viswanathan (E-mail); Cheenu Srinivasan; > > jcucchiara@brixnet.com > > Subject: LIB Table - LSR MIB v. LDP MIB > > > > > > Tom, you wrote in response to Dave in response to Arun... > > > > >>> I have the same objections to the current LDP MIB as > Tom. The LIB > > >>> and the FEC tables are not specific to LDP and do not > belong here. > > >>> The first one is part of the LSR MIB already and the second one > > >>> should be in a separate packet classifier MIB. They > > should be removed > > >>> before the LDP MIB goes to last call. > > > > >>I'd rather a little redundancy than the to use the new proposed > > >>MIB which hasn't had the scrutiny that the LDP MIB has had. > > > > >That may be true in terms of the new MPLS Packet > > >Classifier MIB which deals most closely with the LDP > > >FEC table. However, as Arun pointed out, the LIB Table > > >contained in the LDP MIB is redundant with the LSR MIB. > > >The LSR MIB has been out for quite a while now, and has been > > >under as much scrutiny as the LDP MIB. > > > > It is true that some of the information contained in the LDP MIB's > > LIB table is also contained in the LSR MIB, but consider > > mplsLdpLibInLabelType, mplsLdpLibOutLabelType and > > mplsLdpLibLspLastChange. The LSR MIB supports all labels types but doesn't support an explicit object for the label type. This approach is more generic in terms of supporting currently existsing label type or others that may come up in future. A LastChange object was not added because not sufficient response was found from the list. I feel it is not a very useful information either because often when the label mapping changes it may be a new LSP. > > > > Note also that to walk the 'LIB table' in the LSR MIB involves > > walking the XC table and for each entry looking up the out > > label and out interface in the Out Segment table. This is, > > perhaps, less graceful. > > > > Did you consider putting a simple LIB table in the LSR MIB? First, what exists in the LSR MIB is the LIB. It supports all the Arch requirements. The 'simple LIB' that is being alluded here is simply inadequate. Do the excercise for yourself to see if the various features listed (section 4) in the LSR document can be supported. So making it look graceful should be the least of our concerns, moreover it is a subjective matter. -arun > > > > Adrian > > -- > > Adrian Farrel mailto:af@datcon.co.uk > > ATM, MPLS and Telecoms Development Group > > Data Connection Ltd., Chester, UK > > http://www.datcon.co.uk/ > > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > > > > > > From owner-mpls@UU.NET Thu Mar 16 17:48:33 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27756 for ; Thu, 16 Mar 2000 17:48:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigvb09801; Thu, 16 Mar 2000 22:48:34 GMT Received: by mail-control.mail.uu.net id QQigvb28025 for mpls-outgoing; Thu, 16 Mar 2000 22:47:54 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigvb28020 for ; Thu, 16 Mar 2000 22:47:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigvb26322 for ; Thu, 16 Mar 2000 17:47:23 -0500 (EST) Received: from mail-blue.research.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQigvb22136 for ; Thu, 16 Mar 2000 22:47:23 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 68D2B4CE34; Thu, 16 Mar 2000 17:47:14 -0500 (EST) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id RAA22938; Thu, 16 Mar 2000 17:47:12 -0500 (EST) Reply-To: From: "John Strand" To: "'Yakov Rekhter'" Cc: Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 17:47:05 -0500 Message-ID: <013901bf8f99$8e5c86e0$3e82cf87@pcstranded.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200003162035.MAA00225@omega.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id RAA27756 Yakov, Your reworking of the old (a) is fine as long as the peer-to-peer "Virtual Optical Network" option isn't ruled out of scope. I hope that the physical topology point ((b)) will also be made more inclusive in the same spirit. With regard to BGP: In terms of defining specific solutions "one step at a time" makes sense. I think things will go more smoothly in the long term, however, if this work proceeds in a framework that more explicitly captures Optical Layer reality than has been the case so far. To echo what Bala said: "It would be nice to consider the requirements from the optical side, and then look at solutions." Multi-domain is one example of this: The single domain routing problem seems much more complex if both opaque and transparent (all-optical) islands are intermixed than it will be if a provisional decision is made to keep them in separate domains. (This is an assertion that needs more discussion, of course.) Sec. 6.5 in draft-chaudhuri-ip-olxc-control-00 is a first stab at scoping this problem, where the islands are implicitly assumed to not be intermixed. So I guess the bottom line is that it's up to us OL people to try to suggest an appropriate framework and requirements set within which the single domain problem can be worked intelligently, as a first step to the needed solution. John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: Yakov Rekhter [mailto:yakov@cisco.com] Sent: Thursday, March 16, 2000 3:36 PM To: jls@research.att.com Cc: mpls@UU.NET Subject: Re: Optical IP activities John, > I agree that an MPLS TE-based control plane ought to be able to support > both models, and hope that the charter will be reworded accordingly. > Likewise I'd hope that the clause about making physical topology > information available to Network Layer working procedures will be > reworded to indicate that this is an option to be supported. Agreed. And to address this I would suggest we'll add the following to the WG charter: Use of MPLS control plane with OXCs should allow two basic architectural options: - One option is to use different instances of the control plane in the OTN (OXC) and IP (LSR) domains. In this situation, each instance of the control plane will operate independent of the other. - Another option is to use a single instance of the control plane that subsumes and spans LSRs and OXCs. > I'd also like to suggest that BGP be kept in-scope explicitly. I think that > dealing with multi-domain issues will considerably increase the > applicability of the new control plane. Section 3.1 of > draft-rstb-optical-signaling-framework-00.txt gives one important > driver for this; another will arise as optical networking pushes > out to involve CLEC's and other access providers and also extends > internationally. May I suggest that we'll move "one step at a time". That is, we first settle on how to use MPLS Traffic Engineering to control OXCs (and/or SONET cross connects) within a single routing domain. The next step would be to extend this across domain's boundaries - that is where BGP may come into play. In the context of the MPLS WG charter that means that we could always extend it at some future point to include multi-domain operations. Yakov. From owner-mpls@UU.NET Thu Mar 16 18:31:51 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12801 for ; Thu, 16 Mar 2000 18:31:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigve16576; Thu, 16 Mar 2000 23:31:49 GMT Received: by mail-control.mail.uu.net id QQigve08629 for mpls-outgoing; Thu, 16 Mar 2000 23:31:25 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigve08622 for ; Thu, 16 Mar 2000 23:31:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigve00666 for ; Thu, 16 Mar 2000 18:31:16 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigve14252 for ; Thu, 16 Mar 2000 23:31:16 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id SAA26345; Thu, 16 Mar 2000 18:25:39 -0500 Message-ID: <38D1705B.2E8B78FF@tellium.com> Date: Thu, 16 Mar 2000 18:38:03 -0500 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: jls@research.att.com, mpls@UU.NET Subject: Re: Optical IP activities References: <200003162035.MAA00225@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > Agreed. > > And to address this I would suggest we'll add the following to the > WG charter: > > Use of MPLS control plane with OXCs should allow two basic > architectural options: > > - One option is to use different instances of the control plane > in the OTN (OXC) and IP (LSR) domains. In this situation, each > instance of the control plane will operate independent of the > other. > > - Another option is to use a single instance of the control > plane that subsumes and spans LSRs and OXCs. Given the specific requirements in optical networks (leading to possibly a different flavor of signaling procedures), I'm not sure what the "single instance" model means. Regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Mar 16 18:36:18 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14721 for ; Thu, 16 Mar 2000 18:36:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigve18462; Thu, 16 Mar 2000 23:36:17 GMT Received: by mail-control.mail.uu.net id QQigve08799 for mpls-outgoing; Thu, 16 Mar 2000 23:36:00 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigve08794 for ; Thu, 16 Mar 2000 23:36:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigve06359 for ; Thu, 16 Mar 2000 18:35:45 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigve17906 for ; Thu, 16 Mar 2000 23:35:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA29267 for mpls@uu.net; Thu, 16 Mar 2000 18:35:43 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigve08768 for ; Thu, 16 Mar 2000 23:35:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigve01058 for ; Thu, 16 Mar 2000 18:35:20 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQigve18456 for ; Thu, 16 Mar 2000 23:35:19 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 18:33:38 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F87E@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Arun Viswanathan'" , Joan Cucchiara , "'Adrian Farrel'" , "'Thomas D. Nadeau'" , "'dwilder@baynetworks.com'" Cc: "'mpls@UU.NET'" , "'Cheenu Srinivasan'" Subject: RE: LIB Table - LSR MIB v. LDP MIB Date: Thu, 16 Mar 2000 18:33:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Arun, > > > > > > > Note also that to walk the 'LIB table' in the LSR MIB involves > > > walking the XC table and for each entry looking up the out > > > label and out interface in the Out Segment table. This is, > > > perhaps, less graceful. > > > > > > Did you consider putting a simple LIB table in the LSR MIB? > > First, what exists in the LSR MIB is the LIB. It supports all the > Arch requirements. The 'simple LIB' that is being alluded here is > simply inadequate. Do the excercise for yourself to see if the > various features listed (section 4) in the LSR document can be > supported. So making it look graceful should be the least of our > concerns, moreover it is a subjective matter. I think what was being asked was if there was a way to make the XC table more efficient not only for traversing but for easier clean up on teardown. Why is the indexing of the mplsOutSegmentTable mplsOutSegmentIndex, and not (mplsOutSegmentIfIndex, mplsOutSegmentTopLabel) (also would prefer to call this mplsOutSegmentLabel as the mplsOutSegmentPushTopLabel tells you that whether it was pushed or not)? Then the XC table could be mplsXCIndex, mplsInSegmentIfIndex, mplsInSegmentLabel and mplsOutSegmentLabel). It seems this would be possible to do, and also seems more efficient? There is also a discussion of Terminating LSPs, but not sure it belongs in an XC table...could you explain why this is here? Wouldn't it be better to just add something to the mplsInSegmentTable to indicate that the insegment was terminated? Thanks, Joan > > -arun > > > > > > > Adrian > > > -- > > > Adrian Farrel mailto:af@datcon.co.uk > > > ATM, MPLS and Telecoms Development Group > > > Data Connection Ltd., Chester, UK > > > http://www.datcon.co.uk/ > > > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Mar 16 18:59:20 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23515 for ; Thu, 16 Mar 2000 18:59:19 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigvf13097; Thu, 16 Mar 2000 23:59:22 GMT Received: by mail-control.mail.uu.net id QQigvf10050 for mpls-outgoing; Thu, 16 Mar 2000 23:58:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigvf10045 for ; Thu, 16 Mar 2000 23:58:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigvf06369 for ; Thu, 16 Mar 2000 18:58:23 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigvf07748 for ; Thu, 16 Mar 2000 23:58:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA01469 for mpls@uu.net; Thu, 16 Mar 2000 18:58:17 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigvf10005 for ; Thu, 16 Mar 2000 23:57:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigvf06311 for ; Thu, 16 Mar 2000 18:57:28 -0500 (EST) Received: from tnnt3.tachion.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQigvf07334 for ; Thu, 16 Mar 2000 23:57:27 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 18:58:36 -0500 Message-ID: <633D356A20D0D311BBC1009027DC856C0260DA@TNNT3> From: Cheenu Srinivasan To: "'Joan Cucchiara'" , "'Arun Viswanathan'" , "'Adrian Farrel'" , "'Thomas D. Nadeau'" , "'dwilder@baynetworks.com'" Cc: "'mpls@UU.NET'" Subject: RE: LIB Table - LSR MIB v. LDP MIB Date: Thu, 16 Mar 2000 18:58:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Joan, > Hi Arun, > > > > > > > > > > > Note also that to walk the 'LIB table' in the LSR MIB involves > > > > walking the XC table and for each entry looking up the out > > > > label and out interface in the Out Segment table. This is, > > > > perhaps, less graceful. > > > > > > > > Did you consider putting a simple LIB table in the LSR MIB? > > > > First, what exists in the LSR MIB is the LIB. It supports all the > > Arch requirements. The 'simple LIB' that is being alluded here is > > simply inadequate. Do the excercise for yourself to see if the > > various features listed (section 4) in the LSR document can be > > supported. So making it look graceful should be the least of our > > concerns, moreover it is a subjective matter. > > I think what was being asked was if there was a way to make the > XC table more efficient not only for traversing but for easier > clean up on teardown. > > Why is the indexing of the mplsOutSegmentTable mplsOutSegmentIndex, > and not (mplsOutSegmentIfIndex, mplsOutSegmentTopLabel) (also would > prefer to call this mplsOutSegmentLabel as the > mplsOutSegmentPushTopLabel > tells you that whether it was pushed or not)? If you had been following the discussions and the evolution of this MIB from the beginning, we addressed this specific proposal a couple of times before by us on this mailing list. This won't work for the case where we want to pop the top label and forward the packet with whatever label is underneath, without knowing or wanting to know the underlying labels. As Arun mentioned, please do the exercise of going through the list of features that MIB lists and ask whether there is a simpler way to satisfy them all before proposing new solutions. > There is also a discussion of Terminating LSPs, but not sure > it belongs > in an XC table...could you explain why this is here? > Wouldn't it be better > to just add something to the mplsInSegmentTable to indicate that the > insegment > was terminated? Again, the whole idea was to be able to represent originating, terminating and intermediate LSPs using the same cross-connect model. We have tried to design the simplest possible cross-connect model that is unified yet powerful enough to represent all the features listed in the draft. Cheenu From owner-mpls@UU.NET Thu Mar 16 19:45:43 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10143 for ; Thu, 16 Mar 2000 19:45:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigvj17661; Fri, 17 Mar 2000 00:45:44 GMT Received: by mail-control.mail.uu.net id QQigvj20378 for mpls-outgoing; Fri, 17 Mar 2000 00:45:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigvj20373 for ; Fri, 17 Mar 2000 00:45:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigvj10750 for ; Thu, 16 Mar 2000 19:45:04 -0500 (EST) Received: from lumen.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: magic03.kudonet.com [209.133.127.227]) id QQigvj04544 for ; Fri, 17 Mar 2000 00:45:03 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Mar 2000 16:47:39 -0800 Message-ID: From: John Drake To: "'Bala Rajagopalan'" , Yakov Rekhter Cc: jls@research.att.com, mpls@UU.NET, Luc Ceuppens Subject: RE: Optical IP activities Date: Thu, 16 Mar 2000 16:47:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Bala, In the network model proposed in draft-ceuppens-mpls-optical-00.txt, the DWDM equipment, with its associated line systems, would measure various optical performance parameters, some of which are suggested in the draft. There would then be a standardized protocol, perhaps based on LMP (draft-lang-mpls-lmp-00.txt), which would be used to transfer these measurements from the DWDM system to the PXC. The PXC then synthesize these measurements and report them in link state updates, encoded as new TLVs. Source nodes, either PXCs if the overlay model is used, or routers, if the peer model is used, could then take this information into account when computing routes. However, since the source has already computed the route, it doesn't seem as though signalling has to be modified. Thanks, John -----Original Message----- From: Bala Rajagopalan [mailto:braja@tellium.com] Sent: Thursday, March 16, 2000 3:38 PM To: Yakov Rekhter Cc: jls@research.att.com; mpls@UU.NET Subject: Re: Optical IP activities Yakov Rekhter wrote: > Agreed. > > And to address this I would suggest we'll add the following to the > WG charter: > > Use of MPLS control plane with OXCs should allow two basic > architectural options: > > - One option is to use different instances of the control plane > in the OTN (OXC) and IP (LSR) domains. In this situation, each > instance of the control plane will operate independent of the > other. > > - Another option is to use a single instance of the control > plane that subsumes and spans LSRs and OXCs. Given the specific requirements in optical networks (leading to possibly a different flavor of signaling procedures), I'm not sure what the "single instance" model means. Regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Mar 16 19:59:18 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15506 for ; Thu, 16 Mar 2000 19:59:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigvj24412; Fri, 17 Mar 2000 00:59:19 GMT Received: by mail-control.mail.uu.net id QQigvj20906 for mpls-outgoing; Fri, 17 Mar 2000 00:58:54 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigvj20901 for ; Fri, 17 Mar 2000 00:58:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigvj11663 for ; Thu, 16 Mar 2000 19:58:39 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigvj23951 for ; Fri, 17 Mar 2000 00:58:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA06497 for mpls@uu.net; Thu, 16 Mar 2000 19:58:37 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigvj20889 for ; Fri, 17 Mar 2000 00:58:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigvj11649 for ; Thu, 16 Mar 2000 19:58:18 -0500 (EST) Received: from tnnt3.tachion.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQigvj14611 for ; Fri, 17 Mar 2000 00:58:17 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 19:59:26 -0500 Message-ID: <633D356A20D0D311BBC1009027DC856C0260DC@TNNT3> From: Cheenu Srinivasan To: "'Joan Cucchiara'" , "'George Swallow'" Cc: "'Thomas D. Nadeau'" , Adrian Farrel , mpls@UU.NET, "'vsriniva@cosinecom.com'" Subject: RE: LSR MIB WG Last Call Date: Thu, 16 Mar 2000 19:59:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Joan, Reading your email below I think there is a serious misunderstanding here about the scope and purpose of the LSR MIB. I suggest a careful comparative reading of the current and previous versions of the LSR MIB to see for yourself that we have made no great or sudden changes in the scope or implementation of this MIB. Please alse see my comments below. > > George, > > I do raise an objection. It has been pointed > out to me that the rev 02 of the LSR MIB > now states that it intends to support LDP. It was always the intention of the MIB and the consensus of the WG from over a year back that the LSR MIB not be specific to a particular MPLS protocol. All protocol specific objects are to be supported by respective RSVP/LDP/... MIBs. The purpose of the LSR MIB was to provide a common model of the LSR/LSP for _all_ protocols. This also means that the individual protocol specific MIBs should not be reinventing an LSR/LSP model of their own. If you go back to the Orlando presentation on the LSR MIB you will see that the particular LSR model proposed (with nice powerpoint pictures, no less :-) and agreed upon is identical to the one in the the current as well as all preceding versions of the MIB. > > When the (TE-MIB which contained the LSR-MIB) was > proposed as a working group document in Minneapolis, > Jim Luciani asked if there would be overlap with the > LDP MIB, he (and the rest of the working group) were > told, "no, not much". From that very time and in Minneapolis we said that the LDP MIB should be pointing to the XC table of the LSR MIB. We have not introduced any new objects that change the original model we proposed or the fact that the FEC table of the LDP MIB should have a reference to the XC entry in the LSR MIB. Rather than continue talking in generalities, I think it will help all of us if you could please go through the diffs that Arun posted and point out which objects you think we have suddenly sneaked into the latest version of the MIB to precipidate this uproar. > Now, they intend (apparently) to support LDP. The agreement was always to make it as general as possible and no this was not some change that was introduced in the current version. > As a working group, we do NOT need two mibs to > support the same protocol. > So I object on this > basis. It does not seem fair to me that > 3 revisions into the LSR MIB, the LSR MIB can expand > its scope to support another protocol, namely LDP, especially > when there is already an active LDP MIB. The LSR MIB does not do protocol specific things. As I said before could you please point out these offending objects which you claim have suddenly cropped up to change the very structure of the MIB in this latest revision which were not there before? > There has been NO working group consensus about including LDP in > scope of the LSR MIB. Please see above. > > Why does the working group need two MIBs for LDP? There is only one LDP MIB as far as I know. At the same time there should not be two MIBs modelling an LSR. The LSR MIB should be the only one doing that and that has been the agreed upon consensus all along. Thanks, Cheenu > > Thank you, Joan > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Wednesday, March 15, 2000 10:28 AM > > To: Joan Cucchiara > > Cc: 'Thomas D. Nadeau'; Adrian Farrel; mpls@UU.NET; > > 'swallow@cisco.com'; > > 'vsriniva@cosinecom.com'; swallow@cisco.com > > Subject: Re: LSR MIB WG Last Call > > > > > > Joan - > > > > I believe that Tom merely meant to suggest that the LSR mib was now > > ready for last call. Unless I hear objections I'll issue one before > > the day is out. > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > From owner-mpls@UU.NET Thu Mar 16 20:28:00 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27632 for ; Thu, 16 Mar 2000 20:27:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigvl07211; Fri, 17 Mar 2000 01:28:01 GMT Received: by mail-control.mail.uu.net id QQigvl00415 for mpls-outgoing; Fri, 17 Mar 2000 01:27:35 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigvl00410 for ; Fri, 17 Mar 2000 01:27:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigvl13776 for ; Thu, 16 Mar 2000 20:27:15 -0500 (EST) Received: from lumen.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: magic03.kudonet.com [209.133.127.227]) id QQigvl08719 for ; Fri, 17 Mar 2000 01:27:14 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Mar 2000 17:29:50 -0800 Message-ID: From: John Drake To: "'mpls@UU.NET'" Subject: FW: I-D ACTION:draft-lang-mpls-rsvp-oxc-00.txt Date: Thu, 16 Mar 2000 17:29:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF8FB0.492F88B2" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF8FB0.492F88B2 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, March 16, 2000 1:14 PM Subject: I-D ACTION:draft-lang-mpls-rsvp-oxc-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to RSVP for optical networking Author(s) : J. Lang, K. Mitra, J. Drake Filename : draft-lang-mpls-rsvp-oxc-00.txt Pages : 8 Date : 15-Mar-00 Dynamically provisionable optical crossconnects (OXCs) will play an active role in future optical networks and the MPL(ambda)S control plane will be used to establish, teardown, and reroute optical trails through the network. This document specifies extensions to RSVP to address some of the unique requirements of such optical trails. Specifically, we propose extensions to RSVP that allow an upstream node to make a Label suggestion to a downstream node when establishing an optical trail and allow both directions of a bi- directional optical trail to be established simultaneously. A new message type is also defined so that an RSVP node can notify (possibly non-adjacent) RSVP nodes when network failures occur, without affecting the RSVP states of intermediate RSVP nodes. Finally, we propose a modification to allow bundle messages to be sent to non-adjacent RSVP nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lang-mpls-rsvp-oxc-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lang-mpls-rsvp-oxc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lang-mpls-rsvp-oxc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01BF8FB0.492F88B2 Content-Type: message/rfc822 To: Subject: Date: Thu, 16 Mar 2000 17:29:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BF8FB0.492F88B2" ------_=_NextPart_002_01BF8FB0.492F88B2 Content-Type: text/plain ------_=_NextPart_002_01BF8FB0.492F88B2 Content-Type: application/octet-stream; name="ATT02959.txt" Content-Disposition: attachment; filename="ATT02959.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lang-mpls-rsvp-oxc-00.txt ------_=_NextPart_002_01BF8FB0.492F88B2 Content-Type: message/external-body; site="internet-drafts"; dir="draft-lang-mpls-rsvp-oxc-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BF8FB0.492F88B2-- ------_=_NextPart_000_01BF8FB0.492F88B2-- From owner-mpls@UU.NET Thu Mar 16 23:33:30 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12191 for ; Thu, 16 Mar 2000 23:33:29 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigvy25876; Fri, 17 Mar 2000 04:33:26 GMT Received: by mail-control.mail.uu.net id QQigvy03514 for mpls-outgoing; Fri, 17 Mar 2000 04:33:12 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigvy03509 for ; Fri, 17 Mar 2000 04:32:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigvy25579 for ; Thu, 16 Mar 2000 23:32:56 -0500 (EST) Received: from hercules by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQigvy10575 for ; Fri, 17 Mar 2000 04:32:55 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id UAA25295; Thu, 16 Mar 2000 20:32:58 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 20:32:58 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A634683A@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Joan Cucchiara'" , "'Arun Viswanathan'" , "'Adrian Farrel'" , "'Thomas D. Nadeau'" , "'dwilder@baynetworks.com'" Cc: "'mpls@UU.NET'" , "'Cheenu Srinivasan'" Subject: RE: LIB Table - LSR MIB v. LDP MIB Date: Thu, 16 Mar 2000 20:32:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Joan > Cucchiara > Sent: Thursday, March 16, 2000 3:34 PM > To: 'Arun Viswanathan'; Joan Cucchiara; 'Adrian Farrel'; 'Thomas D. > Nadeau'; 'dwilder@baynetworks.com' > Cc: 'mpls@UU.NET'; 'Cheenu Srinivasan' > Subject: RE: LIB Table - LSR MIB v. LDP MIB > > > > > > > Hi Arun, > > > > > > > > > > > Note also that to walk the 'LIB table' in the LSR MIB involves > > > > walking the XC table and for each entry looking up the out > > > > label and out interface in the Out Segment table. This is, > > > > perhaps, less graceful. > > > > > > > > Did you consider putting a simple LIB table in the LSR MIB? > > > > First, what exists in the LSR MIB is the LIB. It supports all the > > Arch requirements. The 'simple LIB' that is being alluded here is > > simply inadequate. Do the excercise for yourself to see if the > > various features listed (section 4) in the LSR document can be > > supported. So making it look graceful should be the least of our > > concerns, moreover it is a subjective matter. > > I think what was being asked was if there was a way to make the > XC table more efficient not only for traversing but for easier > clean up on teardown. > > Why is the indexing of the mplsOutSegmentTable mplsOutSegmentIndex, > and not (mplsOutSegmentIfIndex, mplsOutSegmentTopLabel) (also would > prefer to call this mplsOutSegmentLabel as the > mplsOutSegmentPushTopLabel > tells you that whether it was pushed or not)? > > Then the XC table could be mplsXCIndex, mplsInSegmentIfIndex, > mplsInSegmentLabel > and mplsOutSegmentLabel). It seems this would be possible to do, > and also seems more efficient? > > There is also a discussion of Terminating LSPs, but not sure > it belongs > in an XC table...could you explain why this is here? > Wouldn't it be better > to just add something to the mplsInSegmentTable to indicate that the > insegment > was terminated? I am sure you will always find better ways of doing anything if you waited long enough. The MIB has been this away since Feb 1998! I think in all fairess to all the folks who have worked on this draft in this WG, its too late for this line of questioning at this time, IMHO. We are into the mode 'if its not broken why fix it'. -arun > > Thanks, Joan > > > > > -arun > > > > > > > > > > Adrian > > > > -- > > > > Adrian Farrel mailto:af@datcon.co.uk > > > > ATM, MPLS and Telecoms Development Group > > > > Data Connection Ltd., Chester, UK > > > > http://www.datcon.co.uk/ > > > > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Mar 17 05:33:34 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18208 for ; Fri, 17 Mar 2000 05:33:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigww18006; Fri, 17 Mar 2000 10:33:29 GMT Received: by mail-control.mail.uu.net id QQigww08005 for mpls-outgoing; Fri, 17 Mar 2000 10:33:12 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigww08000 for ; Fri, 17 Mar 2000 10:33:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigww17097 for ; Fri, 17 Mar 2000 05:32:43 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigww04871 for ; Fri, 17 Mar 2000 10:32:42 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA09431 for mpls@uu.net; Fri, 17 Mar 2000 05:32:41 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigww07987 for ; Fri, 17 Mar 2000 10:32:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigww24715 for ; Fri, 17 Mar 2000 05:32:14 -0500 (EST) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQigww04480 for ; Fri, 17 Mar 2000 10:32:13 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 8A09119C; Fri, 17 Mar 2000 11:32:10 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp7.cisco.com [144.254.60.29]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA17683; Fri, 17 Mar 2000 11:32:04 +0100 (MET) Message-Id: <200003171032.LAA17683@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 17 Mar 2000 11:29:52 +0100 To: pasi.vaananen@nokia.com From: Francois Le Faucheur Subject: RE: BANDWIDTH RESERVATION - RE: Announcing draft-ietf-mpls-diff-ext-03.txt Cc: flefauch@cisco.com, curtis@avici.com, Shahram_Davari@pmc-sierra.com, jh@lohi.eng.telia.fi, curtis@avici.com, mpls@UU.NET, bsd@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, ram@nexabit.com, Pierrick.Cheval@alcatel.fr In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Pasi and all, At 04:01 16/03/2000 -0600, pasi.vaananen@nokia.com wrote: >> So, all in all, I still think: >> - you can do pretty good and label-efficient with Mode 1 >> - you can do the ideal per-OA thing with Mode 2. >> - Mode 3 does not have a strong application in between these 2. >> - there are already quite a lot of options in our spec... >> >> Do you still see a strong application for Mode 3 which would justify >> extensions in the MAP but also extensions in all the error codes and >> procedures (today we rely on normal RSVP error handling to >> signal rejection >> because of admission control)? >> >> Opinions from others? >> >I don't think that the adding traffic parameters to individual >codepoints in signalling warrants the complexity - this was my >primary reason I was opposing whole concept of E-LSPs while >back (you cannot route the classes independently if you bunch >them together). You can do the "right thing" using L-LSPs with >parameters and avoid the otherwise resulting mess. > >Pasi > As you already know, I am 100% in line with Pasi's statement above. This is yet another little option which makes interoperability a little more difficult/unlikely. And we've only heard one voice requesting this (albeit nice and clear). So as you've noticed, the recently issued draft-ietf-mpls-diff-ext-04.txt does not contain the corresponding additional extensions. My proposal is to finalised that approach in Adelaide unless we hear more voices on the alias. Francois _________________________________________________________________ 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: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Fri Mar 17 07:05:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23386 for ; Fri, 17 Mar 2000 07:05:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigxc05699; Fri, 17 Mar 2000 12:04:56 GMT Received: by mail-control.mail.uu.net id QQigxc22674 for mpls-outgoing; Fri, 17 Mar 2000 12:04:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigxc22606 for ; Fri, 17 Mar 2000 12:04:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigxc22385 for ; Fri, 17 Mar 2000 07:03:57 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQigxc07455 for ; Fri, 17 Mar 2000 12:03:56 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Fri, 17 Mar 2000 06:02:23 -0600 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HCWJG79J; Fri, 17 Mar 2000 07:02:04 -0500 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G9NS272W; Fri, 17 Mar 2000 07:02:03 -0500 Message-ID: <38D21E53.EEB0B998@americasm01.nt.com> Date: Fri, 17 Mar 2000 07:00:19 -0500 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Message for ashish@daewoo.dti.daewoo.co.kr Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit [Sorry to bother the list for this. - Philip] To: ashish@daewoo.dti.daewoo.co.kr I tried to reply to your followup question about CR-LDP MIBs, but my reply bounced back. Please let me know what the correct e-mail address is for you. - Philip From owner-mpls@UU.NET Fri Mar 17 08:24:47 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22915 for ; Fri, 17 Mar 2000 08:24:47 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigxh15263; Fri, 17 Mar 2000 13:24:42 GMT Received: by mail-control.mail.uu.net id QQigxh11806 for mpls-outgoing; Fri, 17 Mar 2000 13:24:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigxh11801 for ; Fri, 17 Mar 2000 13:24:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigxh05720 for ; Fri, 17 Mar 2000 08:24:04 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigxh09618 for ; Fri, 17 Mar 2000 13:24:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA17959 for mpls@uu.net; Fri, 17 Mar 2000 08:24:03 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigxh11786 for ; Fri, 17 Mar 2000 13:23:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigxh28116 for ; Fri, 17 Mar 2000 08:23:31 -0500 (EST) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQigxh14593 for ; Fri, 17 Mar 2000 13:23:31 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22344; Fri, 17 Mar 2000 08:23:24 -0500 (EST) Message-Id: <200003171323.IAA22344@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-te-mib-03.txt Date: Fri, 17 Mar 2000 08:23:23 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Traffic Engineering Management Information Base Using SMIv2 Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-te-mib-03.txt Pages : 68 Date : 16-Mar-00 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multi-Protocol Label Switching (MPLS) [MPLSArch] [MPLSFW] based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-te-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-te-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000316144713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316144713.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Mar 17 08:49:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03376 for ; Fri, 17 Mar 2000 08:49:52 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigxj02160; Fri, 17 Mar 2000 13:49:31 GMT Received: by mail-control.mail.uu.net id QQigxj13173 for mpls-outgoing; Fri, 17 Mar 2000 13:48:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigxj13168 for ; Fri, 17 Mar 2000 13:48:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigxj00509 for ; Fri, 17 Mar 2000 08:48:27 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigxj26106 for ; Fri, 17 Mar 2000 13:48:27 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA20140 for mpls@uu.net; Fri, 17 Mar 2000 08:48:26 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigxj13141 for ; Fri, 17 Mar 2000 13:48:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigxj08028 for ; Fri, 17 Mar 2000 08:48:08 -0500 (EST) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQigxj00881 for ; Fri, 17 Mar 2000 13:48:08 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id EA57E142; Fri, 17 Mar 2000 14:48:06 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp7.cisco.com [144.254.60.29]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA12533; Fri, 17 Mar 2000 14:47:01 +0100 (MET) Message-Id: <200003171347.OAA12533@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 17 Mar 2000 14:46:16 +0100 To: "Ballou, Ken" From: Francois Le Faucheur Subject: Re: Very minor typos in draft-ietf-mpls-diff-ext-04.txt Cc: bsd@cisco.com, flefauch@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@ntc.nokia.com, ram@nexabit.com ('Ram Krishnan'), Shahram_Davari@pmc-sierra.com (Shahram Davari), Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi, mpls@UU.NET In-Reply-To: <496A8683261CD211BF6C0008C733261A48CF35@email.quarrytech.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03376 Ken, At 17:41 15/03/2000 -0500, Ballou, Ken wrote: >François, > >I think there are two minor typos in draft-ietf-mpls-diff-ext-04.txt, both >in section 6.1 (Diff-Serv TLV). On page 29, I believe the "Reserved" field >should be 27 bits. Likewise, on page 30, I believe the "Reserved" field >should be 15 bits. > You are correct. I forgot to adjust the length when we added the T field. it will be corrected. thank you. Francois >Thank you. > > - Ken > _________________________________________________________________ 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: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Fri Mar 17 08:49:57 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03417 for ; Fri, 17 Mar 2000 08:49:56 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigxj26787; Fri, 17 Mar 2000 13:49:31 GMT Received: by mail-control.mail.uu.net id QQigxj13180 for mpls-outgoing; Fri, 17 Mar 2000 13:48:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigxj13175 for ; Fri, 17 Mar 2000 13:48:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigxj08070 for ; Fri, 17 Mar 2000 08:48:44 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigxj26232 for ; Fri, 17 Mar 2000 13:48:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA20182 for mpls@uu.net; Fri, 17 Mar 2000 08:48:42 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigxj13150 for ; Fri, 17 Mar 2000 13:48:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigxj00497 for ; Fri, 17 Mar 2000 08:48:18 -0500 (EST) Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQigxj26028 for ; Fri, 17 Mar 2000 13:48:18 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 5309C253; Fri, 17 Mar 2000 14:48:16 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp7.cisco.com [144.254.60.29]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA12862; Fri, 17 Mar 2000 14:48:13 +0100 (MET) Message-Id: <4.0.2.20000317142418.012ac480@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 17 Mar 2000 14:45:24 +0100 To: mpls@UU.NET From: Francois Le Faucheur Subject: Announcing draft-ietf-mpls-diff-ext-04.txt and progressing to Last Call Cc: vsriniva@cosinecom.com, swallow@europe.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk 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: flefauch@europe.cisco.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 >Date: Fri, 25 Feb 2000 15:35:04 -0500 >To: Shahram Davari >From: Francois Le Faucheur >Subject: BANDWIDTH RESERVATION - RE: Announcing > draft-ietf-mpls-diff-ext-03.txt >Cc: "'Juha Heinanen'" , curtis@avici.com, > Francois Le Faucheur , mpls@UU.NET, bsd@cisco.com, > liwwu@europe.cisco.com, pasi.vaananen@ntc.nokia.com, ram@nexabit.com, > Pierrick.Cheval@alcatel.fr >Sender: owner-mpls@UU.NET >X-SMTP-HELO: wodc7-1.corprelay.mail.uu.net >X-SMTP-MAIL-FROM: owner-mpls@UU.NET >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:jh@lohi.eng.telia.fi] >>> Sent: Wednesday, February 23, 2000 2:09 AM >>> To: curtis@avici.com >>> Cc: Francois Le Faucheur; mpls@UU.NET; bsd@cisco.com; >>> liwwu@europe.cisco.com; pasi.vaananen@ntc.nokia.com; ram@nexabit.com; >>> Shahram_Davari@pmc-sierra.com; Pierrick.Cheval@alcatel.fr >>> 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: flefauch@cisco.com >_________________________________________________________________ >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: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Fri Mar 17 09:33:34 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19519 for ; Fri, 17 Mar 2000 09:33:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigxm22844; Fri, 17 Mar 2000 14:33:14 GMT Received: by mail-control.mail.uu.net id QQigxm23738 for mpls-outgoing; Fri, 17 Mar 2000 14:32:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigxm23731 for ; Fri, 17 Mar 2000 14:32:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigxm06129 for ; Fri, 17 Mar 2000 09:32:06 -0500 (EST) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQigxm09355 for ; Fri, 17 Mar 2000 14:32:05 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA19175 for ; Fri, 17 Mar 2000 06:32:04 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA05528 for mpls@uu.net; Fri, 17 Mar 2000 09:32:03 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiguo22675 for ; Thu, 16 Mar 2000 19:38:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiguo27712 for ; Thu, 16 Mar 2000 14:38:02 -0500 (EST) Received: from mx2out.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2out.umbc.edu [130.85.253.52]) id QQiguo01614 for ; Thu, 16 Mar 2000 19:38:01 GMT Received: from apollo.mctr.umbc.edu (apollo.mctr.umbc.edu [130.85.101.89]) by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id OAA09527 for ; Thu, 16 Mar 2000 14:38:00 -0500 (EST) Received: from gemini.mctr.umbc.edu (gemini.mctr.umbc.edu [130.85.101.90]) by apollo.mctr.umbc.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA29779 for ; Thu, 16 Mar 2000 14:37:33 -0500 (EST) Received: from localhost (gargi@localhost) by gemini.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id OAA18510 for ; Thu, 16 Mar 2000 14:35:24 -0500 (EST) X-Authentication-Warning: gemini.mctr.umbc.edu: gargi owned process doing -bs Date: Thu, 16 Mar 2000 14:35:23 -0500 (EST) From: Gargi Banerjee X-Sender: gargi@gemini.mctr.umbc.edu To: mpls@UU.NET Subject: lsp allocation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk hi, we are running some CR-LDP simulations for setting up explicitly routed LSPs via a "on demand" path computation mechanism i.e. when a request for some service comes in we try to dynamically accomadate the request. My question is that say a request comes in that requires 2 Mbps bandwidth on each hop. Assuming that there is no pre-established LSP and we currently not implementing LSP modification schemes, I am going to signal for a new LSP (via CR-LDP). However how much bandwidth should i allocate for the LSP. Common sense tells me that i should allocate more than 2 Mbps, so that other flows can be accomodated on this LSP. But how much more? Are there some well-known formulas for such assignment? Thanks in advance, Gargi ---------------------------------------------------------------------------------- Gargi Dasgupta (Banerjee) Phone:410-455-3063 Research Assistant, MCTR Email:gargi@apollo.mctr.umbc.edu Department of Computer Science http://apollo.mctr.umbc.edu/~gargi University of Maryland, Baltimore. ------------" Life does not need to be perfect to be beautiful." ------------------ From owner-mpls@UU.NET Fri Mar 17 11:40:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11969 for ; Fri, 17 Mar 2000 11:40:30 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigxu23469; Fri, 17 Mar 2000 16:40:23 GMT Received: by mail-control.mail.uu.net id QQigxu18996 for mpls-outgoing; Fri, 17 Mar 2000 16:39:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigxu18981 for ; Fri, 17 Mar 2000 16:39:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigxu26265 for ; Fri, 17 Mar 2000 11:39:24 -0500 (EST) Received: from fcs-nt1.futsoft.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: fcs-nt1.futsoft.com [38.242.189.2]) id QQigxu19019 for ; Fri, 17 Mar 2000 16:39:23 GMT Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id ; Fri, 17 Mar 2000 08:33:05 -0800 Received: from rajeshs ([38.242.189.59]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id IAA17481; Fri, 17 Mar 2000 08:34:23 -0800 Received: by localhost with Microsoft MAPI; Sun, 19 Mar 2000 08:49:20 -0800 Message-Id: <01BF9180.0493CDE0.rajeshs@futsoft.com> From: Rajesh Kumar Reply-To: "rajeshs@futsoft.com" To: "'Gargi Banerjee'" , "mpls@uu.net" Subject: RE: lsp allocation Date: Sun, 19 Mar 2000 08:49:20 -0800 Organization: Future Communications Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I would think you need to assign only 2 mbps. If you need to accomodate more flows on the same lsp later, you would then need to then change the parameters associated with the lsp or re-establish it. Rajesh -----Original Message----- From: Gargi Banerjee [SMTP:gargi@apollo.mctr.umbc.edu] Sent: Thursday, March 16, 2000 11:35 AM To: mpls@uu.net Subject: lsp allocation hi, we are running some CR-LDP simulations for setting up explicitly routed LSPs via a "on demand" path computation mechanism i.e. when a request for some service comes in we try to dynamically accomadate the request. My question is that say a request comes in that requires 2 Mbps bandwidth on each hop. Assuming that there is no pre-established LSP and we currently not implementing LSP modification schemes, I am going to signal for a new LSP (via CR-LDP). However how much bandwidth should i allocate for the LSP. Common sense tells me that i should allocate more than 2 Mbps, so that other flows can be accomodated on this LSP. But how much more? Are there some well-known formulas for such assignment? Thanks in advance, Gargi ------------------------------------------------------------------------ ---------- Gargi Dasgupta (Banerjee) Phone:410-455-3063 Research Assistant, MCTR Email:gargi@apollo.mctr.umbc.edu Department of Computer Science http://apollo.mctr.umbc.edu/~gargi University of Maryland, Baltimore. ------------" Life does not need to be perfect to be beautiful." ------------------ From owner-mpls@UU.NET Fri Mar 17 11:46:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14618 for ; Fri, 17 Mar 2000 11:46:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigxv24150; Fri, 17 Mar 2000 16:46:33 GMT Received: by mail-control.mail.uu.net id QQigxv19539 for mpls-outgoing; Fri, 17 Mar 2000 16:46:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigxv19488 for ; Fri, 17 Mar 2000 16:45:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigxv27319 for ; Fri, 17 Mar 2000 11:45:40 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigxv23441 for ; Fri, 17 Mar 2000 16:45:40 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id LAA21246; Fri, 17 Mar 2000 11:40:17 -0500 Message-ID: <38D262DD.33A024DE@tellium.com> Date: Fri, 17 Mar 2000 11:52:45 -0500 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Drake CC: Yakov Rekhter , jls@research.att.com, mpls@UU.NET, Luc Ceuppens Subject: Re: Optical IP activities References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: Looking at all the drafts on RSVP and CRLDP "extensions" for optical networks, and the issues outlined in draft-rstb-optical-signaling- framework-00.txt, we already have sufficient reason to believe that optical networking signaling has many features which are different from signaling within an IP network. Which is why the "single instance" model is not very clear to me. Also, it is possible to export any sort of information from within an optical cloud to outside, but whether this makes life easier in any manner is not clear. In fact, my personal preference is a clean interface between IP and optical networks while isolating the idiosynchracies of each. This can still be a peer model with limited information exchange. Regards, Bala John Drake wrote: > Bala, > > In the network model proposed in draft-ceuppens-mpls-optical-00.txt, the > DWDM equipment, with its associated line systems, would measure various > optical performance parameters, some of which are suggested in the draft. > There would then be a standardized protocol, perhaps based on LMP > (draft-lang-mpls-lmp-00.txt), which would be used to transfer these > measurements from the DWDM system to the PXC. > > The PXC then synthesize these measurements and report them in link state > updates, encoded as new TLVs. Source nodes, either PXCs if the overlay > model is used, or routers, if the peer model is used, could then take this > information into account when computing routes. > > However, since the source has already computed the route, it doesn't seem as > though signalling has to be modified. > > Thanks, > > John > -----Original Message----- > From: Bala Rajagopalan [mailto:braja@tellium.com] > Sent: Thursday, March 16, 2000 3:38 PM > To: Yakov Rekhter > Cc: jls@research.att.com; mpls@UU.NET > Subject: Re: Optical IP activities > > Yakov Rekhter wrote: > > > Agreed. > > > > And to address this I would suggest we'll add the following to the > > WG charter: > > > > Use of MPLS control plane with OXCs should allow two basic > > architectural options: > > > > - One option is to use different instances of the control plane > > in the OTN (OXC) and IP (LSR) domains. In this situation, each > > instance of the control plane will operate independent of the > > other. > > > > - Another option is to use a single instance of the control > > plane that subsumes and spans LSRs and OXCs. > > Given the specific requirements in optical networks (leading to possibly a > different > flavor of signaling procedures), I'm not sure what the "single instance" > model > means. > > Regards, > -- > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Fri Mar 17 12:04:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21888 for ; Fri, 17 Mar 2000 12:04:23 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigxw05637; Fri, 17 Mar 2000 17:04:21 GMT Received: by mail-control.mail.uu.net id QQigxw25687 for mpls-outgoing; Fri, 17 Mar 2000 17:03:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigxw25563 for ; Fri, 17 Mar 2000 17:03:41 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigxw29741 for ; Fri, 17 Mar 2000 12:03:26 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigxw15894 for ; Fri, 17 Mar 2000 17:03:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA16351 for mpls@uu.net; Fri, 17 Mar 2000 12:03:25 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigxw24921 for ; Fri, 17 Mar 2000 17:02:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigxw29601 for ; Fri, 17 Mar 2000 12:02:17 -0500 (EST) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQigxw04312 for ; Fri, 17 Mar 2000 17:02:16 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA23310; Fri, 17 Mar 2000 09:02:13 -0800 (PST) Message-Id: <200003171702.JAA23310@omega.cisco.com> To: Bala Rajagopalan cc: mpls@UU.NET, Luc Ceuppens Subject: Re: Optical IP activities In-reply-to: Your message of "Fri, 17 Mar 2000 11:52:45 EST." <38D262DD.33A024DE@tellium.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23308.953312533.1@cisco.com> Date: Fri, 17 Mar 2000 09:02:13 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Bala, > Looking at all the drafts on RSVP and CRLDP "extensions" for > optical networks, and the issues outlined in draft-rstb-optical-signaling- > framework-00.txt, we already have sufficient reason > to believe that optical networking signaling has many features which > are different from signaling within an IP network. Which is why > the "single instance" model is not very clear to me. I have no doubts that if one wants, one could make the signalling different enough. It is not clear to me why this would be beneficial to the service providers. > Also, it is possible to export any sort of information from within an > optical cloud to outside, but whether this makes life easier in any > manner is not clear. We clearly have a difference of opinions on this. Yakov. From owner-mpls@UU.NET Fri Mar 17 12:36:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04179 for ; Fri, 17 Mar 2000 12:36:47 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigxy25058; Fri, 17 Mar 2000 17:36:40 GMT Received: by mail-control.mail.uu.net id QQigxy02779 for mpls-outgoing; Fri, 17 Mar 2000 17:36:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigxy02774 for ; Fri, 17 Mar 2000 17:36:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigxy03875 for ; Fri, 17 Mar 2000 12:35:58 -0500 (EST) Received: from lumen.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: magic03.kudonet.com [209.133.127.227]) id QQigxy24545 for ; Fri, 17 Mar 2000 17:35:57 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id ; Fri, 17 Mar 2000 09:38:33 -0800 Message-ID: From: John Drake To: "'Bala Rajagopalan'" , John Drake Cc: Yakov Rekhter , jls@research.att.com, mpls@UU.NET, Luc Ceuppens Subject: RE: Optical IP activities Date: Fri, 17 Mar 2000 09:38:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Bala, I think that the extensions outlined in draft-kompella-mpls-optical-00.txt and draft-lang-mpls-rsvp-oxc-00.txt are either straightforward generalizations (e.g., additional label types) or of general utility (e.g., bi-directional LSPs). Clearly, there are requirements to support the peer model, so I don't think we should continue to debate whether it is a good idea or not. What you're describing as your personal preference is the overlay model, and we've seen the limitations of it in the context of ATM. Thanks, John -----Original Message----- From: Bala Rajagopalan [mailto:braja@tellium.com] Sent: Friday, March 17, 2000 8:53 AM To: John Drake Cc: Yakov Rekhter; jls@research.att.com; mpls@UU.NET; Luc Ceuppens Subject: Re: Optical IP activities Hello: Looking at all the drafts on RSVP and CRLDP "extensions" for optical networks, and the issues outlined in draft-rstb-optical-signaling- framework-00.txt, we already have sufficient reason to believe that optical networking signaling has many features which are different from signaling within an IP network. Which is why the "single instance" model is not very clear to me. Also, it is possible to export any sort of information from within an optical cloud to outside, but whether this makes life easier in any manner is not clear. In fact, my personal preference is a clean interface between IP and optical networks while isolating the idiosynchracies of each. This can still be a peer model with limited information exchange. Regards, Bala John Drake wrote: > Bala, > > In the network model proposed in draft-ceuppens-mpls-optical-00.txt, the > DWDM equipment, with its associated line systems, would measure various > optical performance parameters, some of which are suggested in the draft. > There would then be a standardized protocol, perhaps based on LMP > (draft-lang-mpls-lmp-00.txt), which would be used to transfer these > measurements from the DWDM system to the PXC. > > The PXC then synthesize these measurements and report them in link state > updates, encoded as new TLVs. Source nodes, either PXCs if the overlay > model is used, or routers, if the peer model is used, could then take this > information into account when computing routes. > > However, since the source has already computed the route, it doesn't seem as > though signalling has to be modified. > > Thanks, > > John > -----Original Message----- > From: Bala Rajagopalan [mailto:braja@tellium.com] > Sent: Thursday, March 16, 2000 3:38 PM > To: Yakov Rekhter > Cc: jls@research.att.com; mpls@UU.NET > Subject: Re: Optical IP activities > > Yakov Rekhter wrote: > > > Agreed. > > > > And to address this I would suggest we'll add the following to the > > WG charter: > > > > Use of MPLS control plane with OXCs should allow two basic > > architectural options: > > > > - One option is to use different instances of the control plane > > in the OTN (OXC) and IP (LSR) domains. In this situation, each > > instance of the control plane will operate independent of the > > other. > > > > - Another option is to use a single instance of the control > > plane that subsumes and spans LSRs and OXCs. > > Given the specific requirements in optical networks (leading to possibly a > different > flavor of signaling procedures), I'm not sure what the "single instance" > model > means. > > Regards, > -- > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Fri Mar 17 12:59:17 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14017 for ; Fri, 17 Mar 2000 12:59:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigxz13212; Fri, 17 Mar 2000 17:58:49 GMT Received: by mail-control.mail.uu.net id QQigxz04430 for mpls-outgoing; Fri, 17 Mar 2000 17:58:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigxz04423 for ; Fri, 17 Mar 2000 17:58:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigxz06453 for ; Fri, 17 Mar 2000 12:57:53 -0500 (EST) Received: from hercules by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQigxz12321 for ; Fri, 17 Mar 2000 17:57:53 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id JAA00005; Fri, 17 Mar 2000 09:56:37 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Mar 2000 09:56:37 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A634683C@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Arun Viswanathan'" , "'Joan Cucchiara'" , "'Adrian Farrel'" , "'Thomas D. Nadeau'" , "'dwilder@baynetworks.com'" Cc: "'mpls@UU.NET'" , "'Cheenu Srinivasan'" Subject: RE: LIB Table - LSR MIB v. LDP MIB Date: Fri, 17 Mar 2000 09:56:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > > I am sure you will always find better ways of doing anything > if you waited long enough. The MIB has been this away since Feb 1998! Oops. That should have read 1999. But, almost the same MIB existed in Dec 1998. -arun From owner-mpls@UU.NET Fri Mar 17 13:53:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06285 for ; Fri, 17 Mar 2000 13:53:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyd27717; Fri, 17 Mar 2000 18:53:26 GMT Received: by mail-control.mail.uu.net id QQigyd16105 for mpls-outgoing; Fri, 17 Mar 2000 18:53:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigyd16100 for ; Fri, 17 Mar 2000 18:52:59 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyd13256 for ; Fri, 17 Mar 2000 13:52:54 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigyd27276 for ; Fri, 17 Mar 2000 18:52:54 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id NAA25934; Fri, 17 Mar 2000 13:48:00 -0500 Message-ID: <38D280CE.EBCD849D@tellium.com> Date: Fri, 17 Mar 2000 14:00:30 -0500 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Drake CC: jls@research.att.com, mpls@UU.NET Subject: Re: Optical IP activities References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: John Drake wrote: > Bala, > > I think that the extensions outlined in draft-kompella-mpls-optical-00.txt > and draft-lang-mpls-rsvp-oxc-00.txt are either straightforward > generalizations (e.g., additional label types) or of general utility (e.g., > bi-directional LSPs). Sorry to prolong the agony, but all extensions proposed so far are straightforward. But taken together, we have established a different signaling environment. Here, labels are interpreted differently, bi-directionality is introduced (which was not there at all previously), reliability is a big deal, new restoration-related features introduced, and we're not even sure this is the end of it. Indeed, now that we have a number of "extensions", I'd like to see an enumeration of what can be thrown out the basic RSVP or CR-LDP in the optical network setting (of course, I'm too wimpy to say in open that RSVP soft state model is no good for optical networks). To summarize, I think "the single instance" model is a bit of a stretch. > > > Clearly, there are requirements to support the peer model, so I don't think > we should continue to debate whether it is a good idea or not. What you're > describing as your personal preference is the overlay model, and we've seen > the limitations of it in the context of ATM. Just curious, I'm not sure whether any "requirements" for peer model have been articulated anywhere. I've seen desires or opinions expressed. (Of course, under the rough consensus model, strong opinions become working group requirements), but are there any real requirements? If so, where are they coming from? Also, I didn't advocate an overlay model, but only a preference to limit the amount of information exchange between the IP and optical sides. Regards, Bala > -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Fri Mar 17 14:34:05 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23630 for ; Fri, 17 Mar 2000 14:34:04 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyg09084; Fri, 17 Mar 2000 19:33:52 GMT Received: by mail-control.mail.uu.net id QQigyg26636 for mpls-outgoing; Fri, 17 Mar 2000 19:33:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigyg26630 for ; Fri, 17 Mar 2000 19:33:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyg18691 for ; Fri, 17 Mar 2000 14:33:08 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigyg22131 for ; Fri, 17 Mar 2000 19:33:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA07684 for mpls@uu.net; Fri, 17 Mar 2000 14:33:07 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigyg26610 for ; Fri, 17 Mar 2000 19:32:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyg27360 for ; Fri, 17 Mar 2000 14:32:30 -0500 (EST) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQigyg21773 for ; Fri, 17 Mar 2000 19:32:29 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA22129; Fri, 17 Mar 2000 11:32:22 -0800 (PST) Message-Id: <200003171932.LAA22129@omega.cisco.com> To: Bala Rajagopalan cc: mpls@UU.NET Subject: Re: Optical IP activities In-reply-to: Your message of "Fri, 17 Mar 2000 14:00:30 EST." <38D280CE.EBCD849D@tellium.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22118.953321541.1@cisco.com> Date: Fri, 17 Mar 2000 11:32:22 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Bala, > > I think that the extensions outlined in draft-kompella-mpls-optical-00.txt > > and draft-lang-mpls-rsvp-oxc-00.txt are either straightforward > > generalizations (e.g., additional label types) or of general utility (e.g., > > bi-directional LSPs). > > Sorry to prolong the agony, but all extensions proposed so far are > straightforward. > But taken together, we have established a different signaling environment. > Here, labels are interpreted differently, bi-directionality is introduced > which was not there at all previously), reliability is a big deal, new > restoration-related > features introduced, and we're not even sure this is the end of it. As John suggested, let's look at the extensions described in draft-kompella-mpls-optical-00.txt and draft-lang-mpls-rsvp-oxc-00.txt, and examine some facts (rather than claims): 1. Link Type sub-TLV - this is useful in non-optical domain as well 2. Link Media Type sub-TLV - this is optical-domain specific 3. Path sub-TLV - this is useful in non-optical domain as well 4. Share Risk Link Group TLV - this is useful in non-optical domain as well 5. The concept of forwarding adjacency - this is useful in non-optical domain as well 6. Link Media Type in the Label Request object - this is optical domain specific 7. Failure notification/Notify message - this is useful in non-optical domain as well 8. Bi-directional LSP - this is useful in non-optical domain as well 9. Label suggestion - this is optical domain specific. So, out of 9 items we have 3 items that are specific to optical domain. > Indeed, now that we have a number of "extensions", I'd like to see an > enumeration > of what can be thrown out the basic RSVP or CR-LDP in the optical > network setting (of course, I'm too wimpy to say in open that RSVP > soft state model is no good for optical networks). Please spare the rest of us the "soft vs hard" religious debate. Yakov. From owner-mpls@UU.NET Fri Mar 17 14:40:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25982 for ; Fri, 17 Mar 2000 14:39:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyg26262; Fri, 17 Mar 2000 19:39:53 GMT Received: by mail-control.mail.uu.net id QQigyg27084 for mpls-outgoing; Fri, 17 Mar 2000 19:39:21 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigyg27077 for ; Fri, 17 Mar 2000 19:39:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyg28106 for ; Fri, 17 Mar 2000 14:38:59 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQigyg25613 for ; Fri, 17 Mar 2000 19:38:59 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id OAA09838; Fri, 17 Mar 2000 14:23:11 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id OAA39846; Fri, 17 Mar 2000 14:23:28 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003171923.OAA39846@curtis-lt.avici.com> To: Francois Le Faucheur cc: pasi.vaananen@nokia.com, curtis@avici.com, Shahram_Davari@pmc-sierra.com, jh@lohi.eng.telia.fi, mpls@UU.NET, bsd@cisco.com, liwwu@europe.cisco.com, ram@nexabit.com, Pierrick.Cheval@alcatel.fr Reply-To: curtis@avici.com Subject: Re: BANDWIDTH RESERVATION - RE: Announcing draft-ietf-mpls-diff-ext-03.txt In-reply-to: Your message of "Fri, 17 Mar 2000 11:29:52 +0100." <200003171032.LAA17683@europe.cisco.com> Date: Fri, 17 Mar 2000 14:23:28 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200003171032.LAA17683@europe.cisco.com>, Francois Le Faucheur write s: > Pasi and all, > > At 04:01 16/03/2000 -0600, pasi.vaananen@nokia.com wrote: > >> So, all in all, I still think: > >> - you can do pretty good and label-efficient with Mode 1 > >> - you can do the ideal per-OA thing with Mode 2. > >> - Mode 3 does not have a strong application in between these 2. > >> - there are already quite a lot of options in our spec... > >> > >> Do you still see a strong application for Mode 3 which would justify > >> extensions in the MAP but also extensions in all the error codes and > >> procedures (today we rely on normal RSVP error handling to > >> signal rejection > >> because of admission control)? > >> > >> Opinions from others? > >> > >I don't think that the adding traffic parameters to individual > >codepoints in signalling warrants the complexity - this was my > >primary reason I was opposing whole concept of E-LSPs while > >back (you cannot route the classes independently if you bunch > >them together). You can do the "right thing" using L-LSPs with > >parameters and avoid the otherwise resulting mess. > > >Pasi > > > > As you already know, I am 100% in line with Pasi's statement above. > This is yet another little option which makes interoperability a little > more difficult/unlikely. And we've only heard one voice requesting this > (albeit nice and clear). > So as you've noticed, the recently issued draft-ietf-mpls-diff-ext-04.txt > does not contain the corresponding additional extensions. My proposal is to > finalised that approach in Adelaide unless we hear more voices on the alias. > > Francois Francois, Even if you don't go in the direction of adding the individual traffic parameters and making them optional as I had requested, thank you for giving the request serious consideration. I suspect that if we don't allow this as an option we may have to revisit this later. Ultimately the decision to allow an optional parameter such as this goes with the consensus of the WG. Best Regards, Curtis From owner-mpls@UU.NET Fri Mar 17 14:41:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26689 for ; Fri, 17 Mar 2000 14:41:31 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyg16050; Fri, 17 Mar 2000 19:41:25 GMT Received: by mail-control.mail.uu.net id QQigyg27288 for mpls-outgoing; Fri, 17 Mar 2000 19:40:45 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigyg27279 for ; Fri, 17 Mar 2000 19:40:40 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigyg28300 for ; Fri, 17 Mar 2000 14:40:14 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQigyg14811 for ; Fri, 17 Mar 2000 19:40:14 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Fri, 17 Mar 2000 13:40:06 -0600 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HAZSK035; Fri, 17 Mar 2000 14:39:48 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GWMNTZDB; Fri, 17 Mar 2000 14:39:48 -0500 Message-ID: <38D28A03.33E028C7@americasm01.nt.com> Date: Fri, 17 Mar 2000 14:39:47 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Optical IP activities References: <38D280CE.EBCD849D@tellium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > of what can be thrown out the basic RSVP or CR-LDP in the optical > network setting (of course, I'm too wimpy to say in open that RSVP > soft state model is no good for optical networks). As somebody with a strong opinion on this, let me be the first to propose that we try to keep optical stuff above the RSVP/CR-LDP debates. Clearly we want to signal optical cross connections for fibers, wavebands, wavelengths and timeslots and these requirements can be functionally met by either protocol. We will make more progress if we can concentrate on WHAT we are shipping about and WHAT it means rather than how it gets there. > To summarize, I think "the single instance" model is a bit of a stretch. > > > > > > > Clearly, there are requirements to support the peer model, so I don't think > > we should continue to debate whether it is a good idea or not. What you're > > describing as your personal preference is the overlay model, and we've seen > > the limitations of it in the context of ATM. > > Just curious, I'm not sure whether any "requirements" for peer model > have been articulated anywhere. I've seen desires or opinions expressed. > (Of course, under the rough consensus model, > strong opinions become working group requirements), but > are there any real requirements? If so, where are they coming from? > > Also, I didn't advocate an overlay model, but only a preference to limit > the amount of information exchange between the IP and optical sides. I can't resist. That's a bit like saying "we want to limit the amount of information exchange between IP and the electrical sides". Everytime you catch yourself talking about optical in a "special" sense, turn the phrase around and replace "optical/light" with "electrical/electricity" and see if it makes sense. For example "IP on light" becomes "IP on electricity" ;) As far as topology abstraction is concerned, we abstract topology because we have to, not because we want to. We may need to abstract because the size is simply too large and N^2 unmanagable. We may need to abstract because the other domain administration simply won't exchange information with us, or, with ATM, we need to abstract because the two formats are incompatible. We will almost certainly treat optical LSRs the same way. We will abstract them and their links for size / scalability reasons, for administrative reasons and possibly (if we evolve many protocols that can talk optical MPLS) for incompatibility reasons ;) Abstraction in general is not good for traffice engineering. The further you get from knowing exactly how much bandwidth you have and where it is the worse the job of computing, establishing and laying down routes you can do. The more accurately the topology database reflects exactly the resources you have to allocate, the more accurate a job you can do of engineering your network. Cheers, Peter From owner-mpls@UU.NET Fri Mar 17 14:44:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28062 for ; Fri, 17 Mar 2000 14:44:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyg19212; Fri, 17 Mar 2000 19:44:33 GMT Received: by mail-control.mail.uu.net id QQigyg27596 for mpls-outgoing; Fri, 17 Mar 2000 19:44:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigyg27587 for ; Fri, 17 Mar 2000 19:43:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyg20165 for ; Fri, 17 Mar 2000 14:43:48 -0500 (EST) Received: from hoemail2.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQigyg28841 for ; Fri, 17 Mar 2000 19:43:48 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA12783 for ; Fri, 17 Mar 2000 14:43:47 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA12773; Fri, 17 Mar 2000 14:43:47 -0500 (EST) Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA03462; Fri, 17 Mar 2000 14:43:44 -0500 (EST) Message-ID: <38D28AB6.A4E3C3E8@lucent.com> Date: Fri, 17 Mar 2000 14:42:46 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: Bala Rajagopalan , mpls@UU.NET, Luc Ceuppens Subject: Re: Optical IP activities References: <200003171702.JAA23310@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Peer and overlay model are not necessarily two different and non-interoperable approaches. In the pure functional point of view, peer model seems to be better. However, starting with it may actually make life harder (the old optimal vs. sub optimal story). In a network as chaotic as what we have today, overlay model is a good starting point. Meanwhile, with help of gateway functions, it can migrate into peer model later. Yangguang Yakov Rekhter wrote: > > Bala, > > > Looking at all the drafts on RSVP and CRLDP "extensions" for > > optical networks, and the issues outlined in draft-rstb-optical-signaling- > > framework-00.txt, we already have sufficient reason > > to believe that optical networking signaling has many features which > > are different from signaling within an IP network. Which is why > > the "single instance" model is not very clear to me. > > I have no doubts that if one wants, one could make the signalling > different enough. It is not clear to me why this would be > beneficial to the service providers. > > > Also, it is possible to export any sort of information from within an > > optical cloud to outside, but whether this makes life easier in any > > manner is not clear. > > We clearly have a difference of opinions on this. > > Yakov. From owner-mpls@UU.NET Fri Mar 17 15:00:02 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03702 for ; Fri, 17 Mar 2000 15:00:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyh08916; Fri, 17 Mar 2000 19:59:55 GMT Received: by mail-control.mail.uu.net id QQigyh28643 for mpls-outgoing; Fri, 17 Mar 2000 19:59:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigyh28636 for ; Fri, 17 Mar 2000 19:59:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyh22138 for ; Fri, 17 Mar 2000 14:59:05 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigyh08261 for ; Fri, 17 Mar 2000 19:59:04 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id OAA28675; Fri, 17 Mar 2000 14:54:04 -0500 Message-ID: <38D29049.F88C6190@tellium.com> Date: Fri, 17 Mar 2000 15:06:33 -0500 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: mpls@UU.NET Subject: Re: Optical IP activities References: <200003171932.LAA22129@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: Yakov Rekhter wrote: > Bala, > > As John suggested, let's look at the extensions described in > draft-kompella-mpls-optical-00.txt and draft-lang-mpls-rsvp-oxc-00.txt, > and examine some facts (rather than claims): > > 1. Link Type sub-TLV - this is useful in non-optical domain as well > 2. Link Media Type sub-TLV - this is optical-domain specific > 3. Path sub-TLV - this is useful in non-optical domain as well > 4. Share Risk Link Group TLV - this is useful in non-optical domain as well > 5. The concept of forwarding adjacency - this is useful in non-optical domain > as well > 6. Link Media Type in the Label Request object - this is optical domain > specific > 7. Failure notification/Notify message - this is useful in non-optical domain > as well > 8. Bi-directional LSP - this is useful in non-optical domain as well > 9. Label suggestion - this is optical domain specific. > > So, out of 9 items we have 3 items that are specific to optical domain. What does this really say? That 6 items were invented suddenly to cater to non-optical needs? All 9 were motivated by optical needs, and presumably will be used only in optical networks in the near future. Or, are you suggesting that RSVP implementations outside optical networks will be changed to put to use the 6 items that have general use? Now, let us look beyond draft-kompella and see what we have in draft-rstb-signalling... and draft-saha-rsvp-... These cover specific objects for restoration, protection and the soft state model. And, these are specific to optical network needs. > > > > Indeed, now that we have a number of "extensions", I'd like to see an > > enumeration > > of what can be thrown out the basic RSVP or CR-LDP in the optical > > network setting (of course, I'm too wimpy to say in open that RSVP > > soft state model is no good for optical networks). > Please spare the rest of us the "soft vs hard" religious debate. I'm not surprised by this knee-jerk reaction. I expected that it would be hard to talk about this issue objectively even within the limited scope of optical signaling needs. Perhaps I should say "refresh-reduced" instead of "hard state"? Regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Fri Mar 17 15:13:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09518 for ; Fri, 17 Mar 2000 15:13:23 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyi17214; Fri, 17 Mar 2000 20:13:18 GMT Received: by mail-control.mail.uu.net id QQigyi07831 for mpls-outgoing; Fri, 17 Mar 2000 20:12:56 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigyi07819 for ; Fri, 17 Mar 2000 20:12:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyi03032 for ; Fri, 17 Mar 2000 15:12:32 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigyi16649 for ; Fri, 17 Mar 2000 20:12:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA14888 for mpls@uu.net; Fri, 17 Mar 2000 15:12:31 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigyi07735 for ; Fri, 17 Mar 2000 20:11:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyi02751 for ; Fri, 17 Mar 2000 15:11:26 -0500 (EST) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQigyi15963 for ; Fri, 17 Mar 2000 20:11:25 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA29114; Fri, 17 Mar 2000 12:11:22 -0800 (PST) Message-Id: <200003172011.MAA29114@omega.cisco.com> To: "Peter Ashwood-Smith" cc: mpls@UU.NET Subject: Re: Optical IP activities In-reply-to: Your message of "Fri, 17 Mar 2000 14:39:47 EST." <38D28A03.33E028C7@americasm01.nt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29111.953323882.1@cisco.com> Date: Fri, 17 Mar 2000 12:11:22 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Peter, > > of what can be thrown out the basic RSVP or CR-LDP in the optical > > network setting (of course, I'm too wimpy to say in open that RSVP > > soft state model is no good for optical networks). > > As somebody with a strong opinion on this, let me be the first to > propose that we try to keep optical stuff above the RSVP/CR-LDP > debates. Clearly we want to signal optical cross connections for > fibers, wavebands, wavelengths and timeslots and these requirements > can be functionally met by either protocol. We will make more progress > if we can concentrate on WHAT we are shipping about and WHAT it means > rather than how it gets there. Agreed. > > To summarize, I think "the single instance" model is a bit of a stretch. > > > > > > > > > > > Clearly, there are requirements to support the peer model, so I don't thi nk > > > we should continue to debate whether it is a good idea or not. What you' re > > > describing as your personal preference is the overlay model, and we've se en > > > the limitations of it in the context of ATM. > > > > Just curious, I'm not sure whether any "requirements" for peer model > > have been articulated anywhere. I've seen desires or opinions expressed. > > (Of course, under the rough consensus model, > > strong opinions become working group requirements), but > > are there any real requirements? If so, where are they coming from? > > > > Also, I didn't advocate an overlay model, but only a preference to limit > > the amount of information exchange between the IP and optical sides. > > I can't resist. That's a bit like saying "we want to limit the amount of > information exchange between IP and the electrical sides". Everytime you > catch yourself talking about optical in a "special" sense, turn the > phrase around and replace "optical/light" with "electrical/electricity" and > see if it makes sense. For example "IP on light" becomes > "IP on electricity" ;) > > As far as topology abstraction is concerned, we abstract topology > because we have to, not because we want to. We may need to abstract > because the size is simply too large and N^2 unmanagable. We may need to > abstract because the other domain administration simply won't exchange > information with us, or, with ATM, we need to abstract because the > two formats are incompatible. > > We will almost certainly treat optical LSRs the same way. We will > abstract them and their links for size / scalability reasons, for > administrative reasons and possibly (if we evolve many protocols that > can talk optical MPLS) for incompatibility reasons ;) > > Abstraction in general is not good for traffice engineering. The further > you get from knowing exactly how much bandwidth you have and where it is > the worse the job of computing, establishing and laying down routes you > can do. The more accurately the topology database reflects exactly the > resources you have to allocate, the more accurate a job you can do of > engineering your network. Well said. Yakov. From owner-mpls@UU.NET Fri Mar 17 15:20:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12936 for ; Fri, 17 Mar 2000 15:20:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyj21911; Fri, 17 Mar 2000 20:20:47 GMT Received: by mail-control.mail.uu.net id QQigyj08520 for mpls-outgoing; Fri, 17 Mar 2000 20:20:16 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigyj08515 for ; Fri, 17 Mar 2000 20:20:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyj24978 for ; Fri, 17 Mar 2000 15:20:10 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigyj21362 for ; Fri, 17 Mar 2000 20:20:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA16183 for mpls@uu.net; Fri, 17 Mar 2000 15:20:09 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigyj08478 for ; Fri, 17 Mar 2000 20:19:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyj24856 for ; Fri, 17 Mar 2000 15:19:02 -0500 (EST) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQigyj20635 for ; Fri, 17 Mar 2000 20:19:01 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA00585; Fri, 17 Mar 2000 12:18:57 -0800 (PST) Message-Id: <200003172018.MAA00585@omega.cisco.com> To: Bala Rajagopalan cc: mpls@UU.NET Subject: Re: Optical IP activities In-reply-to: Your message of "Fri, 17 Mar 2000 15:06:33 EST." <38D29049.F88C6190@tellium.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <581.953324336.1@cisco.com> Date: Fri, 17 Mar 2000 12:18:57 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Bala, > > As John suggested, let's look at the extensions described in > > draft-kompella-mpls-optical-00.txt and draft-lang-mpls-rsvp-oxc-00.txt, > > and examine some facts (rather than claims): > > > > 1. Link Type sub-TLV - this is useful in non-optical domain as well > > 2. Link Media Type sub-TLV - this is optical-domain specific > > 3. Path sub-TLV - this is useful in non-optical domain as well > > 4. Share Risk Link Group TLV - this is useful in non-optical domain as well > > 5. The concept of forwarding adjacency - this is useful in non-optical doma in > > as well > > 6. Link Media Type in the Label Request object - this is optical domain > > specific > > 7. Failure notification/Notify message - this is useful in non-optical doma in > > as well > > 8. Bi-directional LSP - this is useful in non-optical domain as well > > 9. Label suggestion - this is optical domain specific. > > > > So, out of 9 items we have 3 items that are specific to optical domain. > > What does this really say? That 6 items were invented suddenly to cater to > non-optical needs? All 9 were motivated by optical needs, and presumably > will be used only in optical networks in the near future. Or, are you > suggesting that RSVP implementations outside optical networks will be changed > to put to use the 6 items that have general use? That will be determined by customers. > Now, let us look beyond draft-kompella and see what we have in > draft-rstb-signalling... > and draft-saha-rsvp-... These cover specific objects for restoration, > protection and the soft state model. And, these are specific to optical > network needs. As I said before, one could make this as different as one want from MPLS. The Internet Drafts you mentioned certainly seems like trying to accomplish this. Yakov. From owner-mpls@UU.NET Fri Mar 17 15:24:33 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14543 for ; Fri, 17 Mar 2000 15:24:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyj24435; Fri, 17 Mar 2000 20:24:29 GMT Received: by mail-control.mail.uu.net id QQigyj08826 for mpls-outgoing; Fri, 17 Mar 2000 20:23:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigyj08821 for ; Fri, 17 Mar 2000 20:23:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyj25468 for ; Fri, 17 Mar 2000 15:23:50 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigyj23926 for ; Fri, 17 Mar 2000 20:23:49 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id PAA29782; Fri, 17 Mar 2000 15:18:56 -0500 Message-ID: <38D2961D.1063C59B@tellium.com> Date: Fri, 17 Mar 2000 15:31:25 -0500 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ashwood-Smith CC: mpls@UU.NET Subject: Re: Optical IP activities References: <38D280CE.EBCD849D@tellium.com> <38D28A03.33E028C7@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: Peter Ashwood-Smith wrote: > > of what can be thrown out the basic RSVP or CR-LDP in the optical > > network setting (of course, I'm too wimpy to say in open that RSVP > > soft state model is no good for optical networks). > > As somebody with a strong opinion on this, let me be the first to > propose that we try to keep optical stuff above the RSVP/CR-LDP > debates. Clearly we want to signal optical cross connections for > fibers, wavebands, wavelengths and timeslots and these requirements > can be functionally met by either protocol. We will make more progress > if we can concentrate on WHAT we are shipping about and WHAT it means > rather than how it gets there. I believe the point was different. Whatever you do (a version of RSVP or CRLDP), whether you are essentially catering to a different set of requirements inside an optical network. In that regard, you may not only want to add "extensions", but may also find that you're either not using "standard" features or finding out some features to be inappropriate. > > > > > > > > Also, I didn't advocate an overlay model, but only a preference to limit > > the amount of information exchange between the IP and optical sides. > > I can't resist. That's a bit like saying "we want to limit the amount of > information exchange between IP and the electrical sides". Everytime you > catch yourself talking about optical in a "special" sense, turn the > phrase around and replace "optical/light" with "electrical/electricity" and > see if it makes sense. For example "IP on light" becomes > "IP on electricity" ;) Not quite. There are specific operational procedures inside an optical network and the question is how much of this must be characterised to the outside world. For example, should a router know about wavelength conversion limitations? > > > As far as topology abstraction is concerned, we abstract topology > because we have to, not because we want to. We may need to abstract > because the size is simply too large and N^2 unmanagable. We may need to > abstract because the other domain administration simply won't exchange > information with us, or, with ATM, we need to abstract because the > two formats are incompatible. > > We will almost certainly treat optical LSRs the same way. We will > abstract them and their links for size / scalability reasons, for > administrative reasons and possibly (if we evolve many protocols that > can talk optical MPLS) for incompatibility reasons ;) Precisely. > > > Abstraction in general is not good for traffice engineering. The further > you get from knowing exactly how much bandwidth you have and where it is > the worse the job of computing, establishing and laying down routes you > can do. The more accurately the topology database reflects exactly the > resources you have to allocate, the more accurate a job you can do of > engineering your network. The question is, whether in practice you would engineer paths across two different networks (IP and optical) or do the engineering (and capacity planning) in each network. Regards. -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Fri Mar 17 15:27:58 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15783 for ; Fri, 17 Mar 2000 15:27:57 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyj26743; Fri, 17 Mar 2000 20:27:52 GMT Received: by mail-control.mail.uu.net id QQigyj09133 for mpls-outgoing; Fri, 17 Mar 2000 20:27:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigyj09106 for ; Fri, 17 Mar 2000 20:27:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyj04960 for ; Fri, 17 Mar 2000 15:26:44 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigyj25920 for ; Fri, 17 Mar 2000 20:26:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA17455 for mpls@uu.net; Fri, 17 Mar 2000 15:26:42 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigyj08997 for ; Fri, 17 Mar 2000 20:26:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyj25746 for ; Fri, 17 Mar 2000 15:25:53 -0500 (EST) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQigyj25420 for ; Fri, 17 Mar 2000 20:25:53 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA01538; Fri, 17 Mar 2000 12:25:51 -0800 (PST) Message-Id: <200003172025.MAA01538@omega.cisco.com> To: Yangguang Xu cc: mpls@UU.NET Subject: Re: Optical IP activities In-reply-to: Your message of "Fri, 17 Mar 2000 14:42:46 EST." <38D28AB6.A4E3C3E8@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1532.953324751.1@cisco.com> Date: Fri, 17 Mar 2000 12:25:51 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Yangguang, > Peer and overlay model are not necessarily two different and > non-interoperable approaches. Yes, indeed. > In the pure functional point of view, peer model seems to be better. There are numerous tradeoffs between the peer and the overlay models. The choice between the two is likely to differ from one service provider to another and will depend on a variety of issues. > However, starting with it may actually make life harder (the old optimal vs. > suboptimal story). In a network as chaotic as what we have today, overlay > model is a good starting point. Meanwhile, with help of gateway functions, > it can migrate into peer model later. For some service providers overlay model may be a good starting point. For other service providers peer model may be a good starting point. Yakov. From owner-mpls@UU.NET Fri Mar 17 15:49:30 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24290 for ; Fri, 17 Mar 2000 15:49:30 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyl13341; Fri, 17 Mar 2000 20:49:16 GMT Received: by mail-control.mail.uu.net id QQigyl11236 for mpls-outgoing; Fri, 17 Mar 2000 20:49:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigyl11224 for ; Fri, 17 Mar 2000 20:48:51 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyl28617 for ; Fri, 17 Mar 2000 15:48:49 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigyl13059 for ; Fri, 17 Mar 2000 20:48:48 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id PAA00891; Fri, 17 Mar 2000 15:43:58 -0500 Message-ID: <38D29BFB.72BD3CA0@tellium.com> Date: Fri, 17 Mar 2000 15:56:27 -0500 From: Bala Rajagopalan X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: mpls@UU.NET Subject: Re: Optical IP activities References: <200003172018.MAA00585@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: > As I said before, one could make this as different as one want > from MPLS. The Internet Drafts you mentioned certainly seems like > trying to accomplish this. In all earnestness, there is no intent or desire to do something deliberately "different". As an optical vendor, we're trying to solve specific problems and raising real issues. These may not match abstract views, ideologies, or opinions expressed in other drafts. Too bad. > > > Yakov. Regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Fri Mar 17 16:18:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06019 for ; Fri, 17 Mar 2000 16:18:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyn09602; Fri, 17 Mar 2000 21:18:37 GMT Received: by mail-control.mail.uu.net id QQigyn21230 for mpls-outgoing; Fri, 17 Mar 2000 21:18:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigyn21223 for ; Fri, 17 Mar 2000 21:18:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigyn11295 for ; Fri, 17 Mar 2000 16:18:00 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQigyn00431 for ; Fri, 17 Mar 2000 21:17:59 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Fri, 17 Mar 2000 15:15:21 -0600 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HCWJ2RN9; Fri, 17 Mar 2000 16:15:04 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GWMNTZQ2; Fri, 17 Mar 2000 16:15:04 -0500 Message-ID: <38D2A056.365E797@americasm01.nt.com> Date: Fri, 17 Mar 2000 16:15:02 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Optical IP activities References: <38D280CE.EBCD849D@tellium.com> <38D28A03.33E028C7@americasm01.nt.com> <38D2961D.1063C59B@tellium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I believe the point was different. Whatever you do (a version of RSVP > or CRLDP), whether you are essentially catering to a different set of > requirements inside an optical network. In that regard, you may not > only want to add "extensions", but may also find that you're either not > using "standard" features or finding out some features to be > inappropriate. What has happened is a general realization that no matter what we switch on, be it spacecial (fiber), time (TDM), frequency(lambda) or shim (statistical), the requirements on the signalling and routing protocols are VERY similar with variations caused by certain physical properties of each switching mechanism. These variations are probably not sufficient to warrant completely independent protocols. About the most serious of these differences is the merge/non merge ability and even that existed in the statistical (ATM) domain. As a result we are in the process of rationalizing and distilling out what the common properties are of all of these mechanisms and trying to build a common mechanism to deal with them all. We may or may not succeed however since we rarely all agree on anything. > Not quite. There are specific operational procedures inside an optical > network and the question is how much of this must be characterised > to the outside world. For example, should a router know about wavelength > conversion limitations? Wavelength conversion limitations can be abstracted into constraints we already deal with in existing constraint based routing systems like ATM/PORS. For example, maximum reach is similar to maximum acceptable delay. If we can find generic ways to express the constraints that optics imposes a generic constraint based routing system should be able to deal with the problems. Besides, the constraints imposed by current optical technologies are being stretched every day. Reach, for example, gets longer and longer every year and may one day be a non issue. Even constraints like the desire to limit the number of wavelength conversions to a minimum to reduce distortion/chirp, or even to reduce to a single wavelength for equipement that cannot do a conversion, can be expressed in abstract forms such as a label set, as in the draft-yanhe or a suggested label as in the lang draft. Are these specific to the optical domain? Probably, although one can see the immediate benefits of a fixed shim label for a span of hops since it reduces read/write operations and hence would improve forwarding performance in the statistically multiplexed domain. > > > > Abstraction in general is not good for traffice engineering. The further > > you get from knowing exactly how much bandwidth you have and where it is > > the worse the job of computing, establishing and laying down routes you > > can do. The more accurately the topology database reflects exactly the > > resources you have to allocate, the more accurate a job you can do of > > engineering your network. > > The question is, whether in practice you would engineer paths across > two different networks (IP and optical) or do the engineering (and > capacity planning) in each network. I argue that given the choice you would pick one network since a single level global/distributed optimal placement problem is "easier" to solve than a two level global/optimal placement problem. Actually I think the two level problem is unsolvable because it lacks exact data at the second level. A fact I'm sure many operators of existing overlay networks will attest to. Cheers, Peter From owner-mpls@UU.NET Fri Mar 17 17:20:22 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00847 for ; Fri, 17 Mar 2000 17:20:22 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyr02425; Fri, 17 Mar 2000 22:20:14 GMT Received: by mail-control.mail.uu.net id QQigyr03133 for mpls-outgoing; Fri, 17 Mar 2000 22:19:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigyr03124 for ; Fri, 17 Mar 2000 22:19:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyr10030 for ; Fri, 17 Mar 2000 17:19:38 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigyr01727 for ; Fri, 17 Mar 2000 22:19:38 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id RAA04281; Fri, 17 Mar 2000 17:14:47 -0500 Message-ID: <38D2BDA7.B73057D3@tellium.com> Date: Fri, 17 Mar 2000 17:20:07 -0600 From: Debanjan X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ashwood-Smith CC: mpls@UU.NET Subject: Re: Optical IP activities References: <38D280CE.EBCD849D@tellium.com> <38D28A03.33E028C7@americasm01.nt.com> <38D2961D.1063C59B@tellium.com> <38D2A056.365E797@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Peter, > Wavelength conversion limitations can be abstracted into constraints > we already deal with in existing constraint based routing systems like > ATM/PORS. For example, maximum reach is similar to maximum acceptable delay. > If we can find generic ways to express the constraints that optics imposes > a generic constraint based routing system should be able to deal with > the problems. Besides, the constraints imposed by current optical > technologies are being stretched every day. Reach, for example, gets > longer and longer every year and may one day be a non issue. > > Even constraints like the desire to limit the number of wavelength > conversions to a minimum to reduce distortion/chirp, or even to reduce to > a single wavelength for equipement that cannot do a conversion, can > be expressed in abstract forms such as a label set, as in the draft-yanhe > or a suggested label as in the lang draft. Are these specific to the > optical domain? Probably, although one can see the immediate benefits > of a fixed shim label for a span of hops since it reduces read/write > operations and hence would improve forwarding performance in the > statistically multiplexed domain. I am sure you can abstract physical limitations/properties and use them as constraints in routing algorithms. The real issue here is whether you want all the routers to know about these "optical constraints" (distortion/chirp, wavelength conversion capability). The other option would be to keep these two domains separate and use an abstraction where the routers view the optical network as a cloud (overlay model). I'm not sure which one is the better approach and think that we need a better understanding of the optical networks and their specific requirements to make that determination. Debanjan From owner-mpls@UU.NET Fri Mar 17 17:26:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03344 for ; Fri, 17 Mar 2000 17:26:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyr15453; Fri, 17 Mar 2000 22:26:43 GMT Received: by mail-control.mail.uu.net id QQigyr03447 for mpls-outgoing; Fri, 17 Mar 2000 22:26:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigyr03439 for ; Fri, 17 Mar 2000 22:25:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigyr10688 for ; Fri, 17 Mar 2000 17:25:57 -0500 (EST) Received: from web4004.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web4004.mail.yahoo.com [216.115.104.38]) id QQigyr14931 for ; Fri, 17 Mar 2000 22:25:57 GMT Message-ID: <20000317222505.20798.qmail@web4004.mail.yahoo.com> Received: from [169.226.2.211] by web4004.mail.yahoo.com; Fri, 17 Mar 2000 14:25:05 PST Date: Fri, 17 Mar 2000 14:25:05 -0800 (PST) From: jesse zx Subject: questions To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk i have two questions about benefits of MPLS relative to tradition ip routers: 1)about traffic balancing. in traditional router-based ip network, load balancing is still available through metrics. the following is excerpted from mpls drafts "Some degree of load balancing can be obtained by adjusting the metrics associated with network links. However, there is a limit to how much can be accomplished in this way, ...." can you tell me what the limitation is ? and why mpls doesn't have the limitation? 2)about scaling. when in ip over atm. because router in the boundary ,ATM only provides links and act as cloud, so there are o(N square)complexity. But i remembered that in traditional ip network, we could designate one router as virtual central router, and another as backup. so based on the above information, some description in the mpls-framework-draft is not exactly right. How about your opinion? thanks!!! jesse March/17 __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-mpls@UU.NET Fri Mar 17 18:14:15 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20468 for ; Fri, 17 Mar 2000 18:14:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyu15440; Fri, 17 Mar 2000 23:14:07 GMT Received: by mail-control.mail.uu.net id QQigyu13866 for mpls-outgoing; Fri, 17 Mar 2000 23:13:52 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigyu13861 for ; Fri, 17 Mar 2000 23:13:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigyu24662 for ; Fri, 17 Mar 2000 18:13:07 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQigyu21011 for ; Fri, 17 Mar 2000 23:13:07 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Fri, 17 Mar 2000 18:12:48 -0500 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HAZSL7M9; Fri, 17 Mar 2000 18:12:47 -0500 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G9NS200A; Fri, 17 Mar 2000 18:12:46 -0500 Message-ID: <38D2BB85.D1747825@americasm01.nt.com> Date: Fri, 17 Mar 2000 18:11:01 -0500 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jesse zx CC: mpls@UU.NET Subject: Re: questions References: <20000317222505.20798.qmail@web4004.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jesse zx wrote: > in traditional router-based ip network, load > balancing is still available through metrics. > the following is excerpted from mpls drafts > "Some degree of load balancing can be obtained by > adjusting the metrics associated with network links. > However, there is a limit to how much can be > accomplished in this way, ...." > can you tell me what the limitation is ? > and why mpls doesn't have the limitation? If one has many flows crossing a network at different "angles", then adjusting a metric on a link will adjust not only the flow one want to move, but other flows as well. MPLS does not have this limitation, because one can assign flows to LSPs, and then route each LSP using an explicit route or a set of constraints. - Philip From owner-mpls@UU.NET Fri Mar 17 18:18:52 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22015 for ; Fri, 17 Mar 2000 18:18:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyv19050; Fri, 17 Mar 2000 23:18:49 GMT Received: by mail-control.mail.uu.net id QQigyv14282 for mpls-outgoing; Fri, 17 Mar 2000 23:18:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigyv14275 for ; Fri, 17 Mar 2000 23:18:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyv25221 for ; Fri, 17 Mar 2000 18:18:06 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQigyv18436 for ; Fri, 17 Mar 2000 23:18:05 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Fri, 17 Mar 2000 18:17:48 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Mar 2000 18:17:48 -0500 Message-ID: <03E3E0690542D211A1490000F80836F4CD06C3@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'Debanjan'" Cc: mpls@UU.NET Subject: RE: Optical IP activities Date: Fri, 17 Mar 2000 18:17:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9067.021C8D00" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9067.021C8D00 Content-Type: text/plain > I am sure you can abstract physical limitations/properties and use the as > constraints in routing algorithms. The real issue here is whether you > want > all the routers to know about these "optical constraints" > (distortion/chirp, > wavelength conversion capability). The other option would be to keep > these > two domains separate and use an abstraction where the routers view the > optical > network as a cloud (overlay model). I'm not sure which one is the better > approach > and think that we need a better understanding of the optical networks > and their > specific requirements to make that determination. The argument you are making applies equally well to all forms of Path Oriented Routing regardless of the switching technology they employ to form a path. Therefor, by your logic, Path Oriented and Connectionless routing systems should not be mixed but isolated and overlayed. The above argument goes contrary to what MPLS is all about (bringing Path Oriented Routing capabilities into IP) and against the operational experience of many existing proprietary networking protocol systems. MPLS is just a standards based expression of the lessons that have been learned over the last 5-10 years in non standard systems. Optics is not really special, its just really fast with a few new interesting constraints many of which will disappear within a few years. Cheers, Peter ------_=_NextPart_001_01BF9067.021C8D00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Optical IP activities

    > I am = sure you can abstract physical limitations/properties and use = the as
    > constraints in routing algorithms. The real issue here = is whether you
    > want
    > all the routers to know about these "optical = constraints"
    > (distortion/chirp,
    > wavelength conversion capability). The other option = would be to keep
    > these
    > two domains separate and use an abstraction where the = routers view the
    > optical
    > network as a cloud (overlay model). I'm not sure which = one is the better
    > approach
    > and think that we need a better understanding of the = optical networks
    > and their
    > specific requirements to make that determination.

The argument you are making applies = equally well to all forms of Path Oriented Routing regardless of the = switching technology they employ to form a path. Therefor, by your = logic, Path Oriented and Connectionless routing systems should not be = mixed but isolated and = overlayed.

The above argument goes contrary to = what MPLS is all about (bringing Path Oriented Routing capabilities = into IP) and against the operational experience = of many existing proprietary networking protocol systems. = MPLS is just a standards based expression = of the lessons that have been learned over the last 5-10 years in non = standard systems. Optics is = not really special, its just really fast with a few new interesting = constraints many of which = will disappear within a few years.

Cheers,

Peter

------_=_NextPart_001_01BF9067.021C8D00-- From owner-mpls@UU.NET Fri Mar 17 18:36:26 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29145 for ; Fri, 17 Mar 2000 18:36:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyw13057; Fri, 17 Mar 2000 23:36:23 GMT Received: by mail-control.mail.uu.net id QQigyw15059 for mpls-outgoing; Fri, 17 Mar 2000 23:36:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigyw15049 for ; Fri, 17 Mar 2000 23:35:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyw17974 for ; Fri, 17 Mar 2000 18:35:45 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQigyw28093 for ; Fri, 17 Mar 2000 23:35:45 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id SAA06316; Fri, 17 Mar 2000 18:30:56 -0500 Message-ID: <38D2CF7F.D826F33B@tellium.com> Date: Fri, 17 Mar 2000 18:36:15 -0600 From: Debanjan X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ashwood-Smith CC: mpls@UU.NET Subject: Re: Optical IP activities References: <03E3E0690542D211A1490000F80836F4CD06C3@zcard00f.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Peter Ashwood-Smith wrote: > >> I am sure you can abstract physical limitations/properties >> and use the as constraints in routing algorithms. The real >> issue here is whether you want all the routers to know about >> these "optical constraints" (distortion/chirp, wavelength >> conversion capability). The other option would be to keep >> these two domains separate and use an abstraction where the >> routers view the optical network as a cloud (overlay model). >> I'm not sure which one is the better approach and think that >> we need a better understanding of the optical networks and their >> specific requirements to make that determination. > The argument you are making applies equally well to all forms > of Pat Oriented Routing regardless of the switching technology > they employ to form a path. Therefor, by your logic, Path Oriented > and Connectionless routing systems should not be mixed but isolated > and overlayed. I am not making that argument at all. All I'm saying is that optical networks have special requirements and we need to understand them better before deciding if we should use peer model or overlay model. May be we should have both. > Optics is not really special, its just really fast > with a few new interesting constraints many of which > will disappear within a few years. Why do you think that the constraints will disappear within a few years? Regards, Debanjan From owner-mpls@UU.NET Fri Mar 17 18:42:58 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01638 for ; Fri, 17 Mar 2000 18:42:57 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigyw19718; Fri, 17 Mar 2000 23:42:55 GMT Received: by mail-control.mail.uu.net id QQigyw15504 for mpls-outgoing; Fri, 17 Mar 2000 23:42:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigyw15499 for ; Fri, 17 Mar 2000 23:42:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigyw27205 for ; Fri, 17 Mar 2000 18:42:03 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQigyw18760 for ; Fri, 17 Mar 2000 23:42:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA10257 for mpls@uu.net; Fri, 17 Mar 2000 18:42:01 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQigyw15475 for ; Fri, 17 Mar 2000 23:41:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigyw27055 for ; Fri, 17 Mar 2000 18:41:37 -0500 (EST) Received: from malone.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: malone.cisco.com [171.68.225.99]) id QQigyw01060 for ; Fri, 17 Mar 2000 23:41:36 GMT Received: from glmartin-pc (dhcp-j21-143.cisco.com [171.68.214.143]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA19861 for ; Fri, 17 Mar 2000 15:41:35 -0800 (PST) Message-Id: <4.0.2.20000317154226.0100e390@malone.cisco.com> X-Sender: glmartin@malone.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 17 Mar 2000 15:42:42 -0800 To: mpls@UU.NET From: Glenn Martin Subject: unsubscribe glmartin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk ______________________________ | Glenn Martin | | Serviceability Design Engineer | | Cisco Systems Inc. | / ) 170 West Tasman Drive ( \ / /| San Jose, CA 95134-1706 |\ \ _( ( | Phone: 408-526-6173 | ) )_ (((\ \| /-) Fax: 408 526-6173 (-\ |/ /))) (\\\\ \_/ / glenn@cisco.com \ \_/ ////) \ /_________________________\ / \ / \ / \ _/ Pager: 1-800-365-4578 \_ / /___/ \___\ From owner-mpls@UU.NET Sat Mar 18 01:18:09 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25583 for ; Sat, 18 Mar 2000 01:18:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigzx11175; Sat, 18 Mar 2000 06:18:03 GMT Received: by mail-control.mail.uu.net id QQigzx28244 for mpls-outgoing; Sat, 18 Mar 2000 06:17:33 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigzx28237 for ; Sat, 18 Mar 2000 06:17:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQigzx21886 for ; Sat, 18 Mar 2000 01:17:25 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQigzx10565 for ; Sat, 18 Mar 2000 06:17:25 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Sat, 18 Mar 2000 01:17:23 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Sat, 18 Mar 2000 01:17:24 -0500 Message-ID: <03E3E0690542D211A1490000F80836F4029F9760@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'Debanjan'" Cc: mpls@UU.NET Subject: RE: Optical IP activities Date: Sat, 18 Mar 2000 01:17:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF90A1.A036D268" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF90A1.A036D268 Content-Type: text/plain; charset="iso-8859-1" > All I'm saying is that optical >networks >have special requirements and we need to understand them better before >deciding if we should use peer model or overlay model. May be we should >have both. I don't think anything we have done so far has decided on one model v.s. the other. It is perfectly possible to use MPLS traffic engineered paths as part of a flat (peer) model or an overlay model regardless of the transport mechanisms used. The point I'm trying to make are that all of these overlay v.s. peer arguments are orthogonal to the transport mechanism in use and that one should not abstract along transport domain boundaries .. if you have an alternative. >> Optics is not really special, its just really fast >> with a few new interesting constraints many of which >> will disappear within a few years. >Why do you think that the constraints will disappear within a >few years? Just taking three constraints as examples. There are many others but consider these as illustrations... - reach - the distance a pulse can travel before it either spreads into other pulses or is too weak to be detected. Bounding it requires a route computation that knows the length (delay) of the individual links probably taking into account the presence of amplifiers. This is not a particularly difficult constraint to take into account but I'll admit the amplifiers are tricky to incorporate into an OSPF type model. Fortunately reach has increased steadily over the last 10 years and will almost certainly continue to do so as tighter modulation and detection devices are built. Solitons for example, promise near unlimited reach. - distortion caused by wavelength conversion. The devices used to do wavelength conversion produce the difference between the input wavelength and a reference wavelength. They also produce other undesirable products above and below the output peak. One way to deal with this is to switch entire bands of wavelengths or wavebands instead of individual wavelengths. This actually introduces another level of logical label to the label hierarchy, one that nobody has really talked about yet. This is one area where logical abstraction has a direct physical advantage since it allows much tighter lambda spacing. I was planning to bring this up in the optical BOF. - wavelength conversion incapable devices, can be handled by establishing paths with the same label, over CI segments as shown in draft-fan and others. This constraint can be dealt with locally by the signaling protocol without requiring flooding of the available wavelengths at the expense of a bit of trial and error from time to time. It is clear thought that as wavelength difference devices get cheaper and tighter this will be the preferred switching mechanism although we will still want to reduce the number of wavelength changes end to end for distortion reduction purposes. I guess the ultimate perhaps cynical reason why constraints disappear is simply greed! Although I guess we will be stuck with C for quite some time despite work by some of our marketing departments to address it. Cheers, Peter ------_=_NextPart_001_01BF90A1.A036D268 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical IP activities

    > All I'm saying is that optical
    >networks
    >have special requirements and we need to understand them = better before
    >deciding if we should use peer model or overlay model. = May be we should
    >have both.

    I don't think anything we have done = so far has decided on one model v.s. the other. It is perfectly possible to use MPLS traffic = engineered paths as part of a flat (peer) model or an overlay model = regardless of the transport = mechanisms used. The point = I'm trying to make are that all = of these overlay v.s. peer arguments are orthogonal to the transport = mechanism in use and that = one should not abstract along transport domain boundaries .. if you = have an alternative.

    >> Optics is not really special, its just really = fast
    >> with a few new interesting constraints many of = which
    >> will disappear within a few years.

    >Why do you think that the constraints will disappear = within a
    >few years?

    Just taking three constraints as = examples. There are many others but consider these as = illustrations...

  • reach - the distance a = pulse can travel before it = either spreads into other pulses or is too weak to be = detected. Bounding = it requires a route = computation that knows the length (delay) of the individual = links probably taking into = account the presence of amplifiers. This is not a particularly difficult = constraint to take into account but I'll admit the amplifiers are tricky to incorporate into = an OSPF type model. Fortunately reach has increased steadily over the = last  10 years and will almost certainly continue to do so as tighter modulation and = detection devices are built. Solitons for example, promise near unlimited reach.

      •  - distortion caused by wavelength conversion. The = devices used to do wavelength conversion produce the      difference between the input wavelength and a reference = wavelength. They also produce other undesirable products above and below the output = peak. One way to deal with = this is to switch entire bands of wavelengths or wavebands instead of = individual wavelengths. This actually introduces another level of logical label to the label hierarchy, one that nobody has really talked about = yet. This is one area where = logical abstraction has a direct physical advantage since it allows much tighter lambda = spacing. I was planning to bring this up in the optical = BOF.

  • wavelength conversion = incapable devices, can be = handled by establishing = paths with the same label, over = CI segments as shown in = draft-fan and others. This = constraint can be dealt with locally by the signaling protocol = without requiring flooding = of the available wavelengths at the expense of a bit of trial and error = from time to time. It is = clear thought that as = wavelength difference devices get cheaper and tighter this will be the = preferred switching mechanism although we will still want to reduce = the number of wavelength changes end to end for = distortion reduction purposes.

I guess the ultimate perhaps = cynical reason why constraints disappear is simply greed! = Although I guess we will be stuck with C = for quite some time despite = work by  some of our = marketing departments to address = it.

Cheers,

Peter

------_=_NextPart_001_01BF90A1.A036D268-- From owner-mpls@UU.NET Sat Mar 18 01:19:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26228 for ; Sat, 18 Mar 2000 01:19:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigzx12691; Sat, 18 Mar 2000 06:19:44 GMT Received: by mail-control.mail.uu.net id QQigzx28331 for mpls-outgoing; Sat, 18 Mar 2000 06:19:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQigzx28317 for ; Sat, 18 Mar 2000 06:19:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigzx14871 for ; Sat, 18 Mar 2000 01:18:59 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQigzx10472 for ; Sat, 18 Mar 2000 06:18:59 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id BAA06456; Sat, 18 Mar 2000 01:18:58 -0500 Date: Sat, 18 Mar 2000 01:18:58 -0500 From: "J. Noel Chiappa" Message-Id: <200003180618.BAA06456@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: Optical IP activities Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Debanjan > The real issue here is whether you want all the routers to know about > these "optical constraints" (distortion/chirp, wavelength conversion > capability). The other option would be to keep these two domains > separate and use an abstraction where the routers view the optical > network as a cloud (overlay model). Hmmm. A very interesting point; attributes for topology elements which are rather arcane, but understanding of which is vital for generating useful paths. After pondering for a bit, my take is that in the long run you'd still want to use a single routing system (for routing at the optical layer, and at the internetwork layer); the reason being that that will make it easier to export data which *is* useful to other entities about that part of the network. However, you'd probably want to hide some of the actual detail, and only advertise (to entities on the outside) longer "virtual" links, ones which are actually paths across the optical fabric, paths which have been preconstructed to meet the special optical constraints. Yes, I know we don't have a routing system that can do anything like that today. :-( Some day... Noel From owner-mpls@UU.NET Sat Mar 18 01:31:52 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01509 for ; Sat, 18 Mar 2000 01:31:52 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQigzy19513; Sat, 18 Mar 2000 06:31:46 GMT Received: by mail-control.mail.uu.net id QQigzy28930 for mpls-outgoing; Sat, 18 Mar 2000 06:31:13 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQigzy28907 for ; Sat, 18 Mar 2000 06:31:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigzy22547 for ; Sat, 18 Mar 2000 01:31:08 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQigzy18715 for ; Sat, 18 Mar 2000 06:31:07 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Sat, 18 Mar 2000 00:31:20 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Sat, 18 Mar 2000 00:31:01 -0600 Message-ID: <03E3E0690542D211A1490000F80836F4029F9761@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'mpls@UU.NET'" Subject: RE: questions Date: Sat, 18 Mar 2000 00:30:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF90A3.86F8410E" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF90A3.86F8410E Content-Type: text/plain; charset="iso-8859-1" > in traditional router-based ip network, load > balancing is still available through metrics. > the following is excerpted from mpls drafts > "Some degree of load balancing can be obtained by > adjusting the metrics associated with network links. > However, there is a limit to how much can be > accomplished in this way, ...." > can you tell me what the limitation is ? > and why mpls doesn't have the limitation? Since I use driving analogies to explain routing behavior, here is one that may help. Imagine you are driving along and a see a sign post that says "Adelaide 10 miles" on a right turn off your current route. Now imagine another sign that says "Adelaide 5 miles" on a left turn off your current route. You will turn left because its faster ... problem is, everybody else will make the same decision and the 10 mile route will never get used. Now, if you as a traffic engineer look at this problem and try to get people onto the right turn by changing the sign to say 4 miles... well everybody will now take It and nobody will take the previous turn. Traffic engineered MPLS (i.e. CR-LDP or RSVP-TE) does not have this limitation because the path for a set of related packets is predetermined and does not have to follow the routes picked by intermediate nodes to its destination. You may find our Tutorial on MPLS available on the www.nanog.org web site of some help as it explains this in quite some detail. Cheers, Peter ------_=_NextPart_001_01BF90A3.86F8410E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: questions

    >   = in traditional router-based ip network, load
    > balancing is still available = through metrics.
    >  the following is excerpted = from mpls drafts
    > "Some degree of load = balancing can be obtained by
    > adjusting the metrics associated = with network links.
    > However,  there is a limit = to how much can be
    > accomplished in this way, = ...."
    >  can you tell me what the = limitation is ?
    >  and why mpls doesn't have = the limitation?

    Since I use driving analogies to = explain routing behavior, here is one that may help.

    Imagine you are driving along and a = see a sign post that says "Adelaide 10 miles" on a right turn off your = current route. Now imagine another sign that says "Adelaide 5 miles" on a left turn off your = current route. You will turn left because its faster = ... problem is, everybody else will make = the same decision and the 10 = mile route will never get used. Now, if you as a traffic = engineer look at this = problem and try to get people onto the right turn by changing the sign = to say 4 miles... well everybody will now take It and nobody will take = the previous turn.

    Traffic engineered MPLS (i.e. = CR-LDP or RSVP-TE) does not have this limitation because the path for a = set of related packets is predetermined and does not have to follow the = routes picked by intermediate nodes to its destination. =

    You may find our = Tutorial on MPLS available on the www.nanog.org web site of some help as it explains this in quite some = detail.

    Cheers,

    Peter

------_=_NextPart_001_01BF90A3.86F8410E-- From owner-mpls@UU.NET Sat Mar 18 04:48:13 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22876 for ; Sat, 18 Mar 2000 04:48:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihal14502; Sat, 18 Mar 2000 09:48:05 GMT Received: by mail-control.mail.uu.net id QQihal01221 for mpls-outgoing; Sat, 18 Mar 2000 09:47:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihal01216 for ; Sat, 18 Mar 2000 09:47:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihal03346 for ; Sat, 18 Mar 2000 04:47:10 -0500 (EST) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQihal13691 for ; Sat, 18 Mar 2000 09:47:09 GMT Received: from fuinar.juniper.net (fuinar.juniper.net [207.79.80.140]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id BAA07741; Sat, 18 Mar 2000 01:47:09 -0800 (PST) Received: (from qv@localhost) by fuinar.juniper.net (8.8.8/8.7.3) id BAA04570; Sat, 18 Mar 2000 01:47:05 -0800 (PST) From: Quaizar Vohra MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 18 Mar 2000 01:47:05 -0800 (PST) To: "J. Noel Chiappa" Cc: mpls@UU.NET Subject: Re: Optical IP activities In-Reply-To: <200003180618.BAA06456@ginger.lcs.mit.edu> References: <200003180618.BAA06456@ginger.lcs.mit.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14547.20313.435562.192788@fuinar.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps, the notion of forwarding adjacency in draft-kompella-mpls-optical-00.txt might be something similar ? > > From: Debanjan > > > The real issue here is whether you want all the routers to know about > > these "optical constraints" (distortion/chirp, wavelength conversion > > capability). The other option would be to keep these two domains > > separate and use an abstraction where the routers view the optical > > network as a cloud (overlay model). > > Hmmm. A very interesting point; attributes for topology elements which are > rather arcane, but understanding of which is vital for generating useful > paths. > > After pondering for a bit, my take is that in the long run you'd still want > to use a single routing system (for routing at the optical layer, and at the > internetwork layer); the reason being that that will make it easier to export > data which *is* useful to other entities about that part of the network. > However, you'd probably want to hide some of the actual detail, and only > advertise (to entities on the outside) longer "virtual" links, ones which are > actually paths across the optical fabric, paths which have been > preconstructed to meet the special optical constraints. > > Yes, I know we don't have a routing system that can do anything like that > today. :-( Some day... > > Noel From owner-mpls@UU.NET Sat Mar 18 23:15:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08319 for ; Sat, 18 Mar 2000 23:15:03 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihdg26970; Sun, 19 Mar 2000 04:14:34 GMT Received: by mail-control.mail.uu.net id QQihdg20527 for mpls-outgoing; Sun, 19 Mar 2000 04:13:58 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihdg20519 for ; Sun, 19 Mar 2000 04:13:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihdg04069 for ; Sat, 18 Mar 2000 23:13:46 -0500 (EST) Received: from smtp6.mindspring.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQihdg29770 for ; Sun, 19 Mar 2000 04:13:46 GMT Received: from jluciani (ip114.cambridge2.ma.pub-ip.psi.net [38.32.112.114]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id XAA17011; Sat, 18 Mar 2000 23:13:41 -0500 (EST) Message-ID: <009f01bf9159$81a2a4e0$8fd5fea9@jluciani> Reply-To: "James V. Luciani" From: "James V. Luciani" To: "Peter Ashwood-Smith" , "'Debanjan'" Cc: References: <03E3E0690542D211A1490000F80836F4029F9760@zcard00f.ca.nortel.com> Subject: Re: Optical IP activities Date: Sat, 18 Mar 2000 23:13:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit RE: Optical IP activities>reach - the distance a pulse can travel before it either spreads into other pulses or is too weak to be detected. Bounding it requires a >route computation that knows the length (delay) of the individual links probably taking into account the presence of amplifiers. This is You may find quite a few people who are doing amplifier placement analysis who might disagree with you especially when you talk about doing dynamic optical bypass/cut-through with no OEO. So for example, if you cascade several amplifiers for a single segment, the nonlinear characteristics of one amplifier can be offset by a subsequent amplifier. Today this balancing act is done by hand. Now lets introduce highly dynamic optical bypass (i.e., non OEO passthrough) capabilities via lamda switching. You may find that delicate balance is not so easy to maintain. Another example would be amplified spontaneous emission in EDFAs which are cascaded in optical bypass systems with a large number of amplifiers. We caould also talk about polization effects in cascaded EDFAs. So the point is that, when you are talking about optical bypass systems the equation gets a lot uglier than a simple shortes path first calculation because of inherent issues with the optics which are different from electrical issues. >not a particularly difficult constraint to take into account but I'll admit the amplifiers are tricky to incorporate into an OSPF type model. >Fortunately reach has increased steadily over the last 10 years and will almost certainly continue to do so as tighter modulation and Well... solitons do have the benefit of reduced or no chromatic dispersion but they are still subject to attenuation and need amplifiers. There is the nasty reality that there is a lot of dispersion shifted fiber out there (not to mention the stuff optimized for 1310). The point again being that it is not merely a matter of query-replace-reg-expr between "optical" and "electrical" as was previously suggested when talking about route calculations. >detection devices are built. Solitons for example, promise near unlimited reach. > - distortion caused by wavelength conversion. The devices used to do wavelength conversion produce the difference between the >input wavelength and a reference wavelength. They also produce other undesirable products above and below the output peak. One >way to deal with this is to switch entire bands of wavelengths or wavebands instead of individual wavelengths. This actually introduces draft-ip-optical-framework-00.txt talka about this a bit under the term multi-link trunking. >another level of logical label to the label hierarchy, one that nobody has really talked about yet. This is one area where logical >abstraction has a direct physical advantage since it allows much tighter lambda spacing. I was planning to bring this up in the optical >BOF. >wavelength conversion incapable devices, can be handled by establishing paths with the same label, over CI segments as shown in >draft-fan and others. This constraint can be dealt with locally by the signaling protocol without requiring flooding of the available >wavelengths at the expense of a bit of trial and error from time to time. It is clear thought that as wavelength difference devices get >cheaper and tighter this will be the preferred switching mechanism although we will still want to reduce the number of wavelength >changes end to end for distortion reduction purposes. From owner-mpls@UU.NET Sun Mar 19 12:19:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13075 for ; Sun, 19 Mar 2000 12:19:20 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihfh18998; Sun, 19 Mar 2000 17:19:15 GMT Received: by mail-control.mail.uu.net id QQihfh08456 for mpls-outgoing; Sun, 19 Mar 2000 17:19:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihfh08446 for ; Sun, 19 Mar 2000 17:18:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihfh20215 for ; Sun, 19 Mar 2000 12:18:40 -0500 (EST) Received: from smtprich.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprich.nortel.com [192.135.215.8]) id QQihfh15385 for ; Sun, 19 Mar 2000 17:18:40 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Sun, 19 Mar 2000 11:16:01 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Sun, 19 Mar 2000 11:15:05 -0600 Message-ID: <03E3E0690542D211A1490000F80836F4029F9765@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'James V. Luciani'" , "'Debanjan'" Cc: mpls Subject: RE: Optical IP activities Date: Sun, 19 Mar 2000 11:15:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF91C6.AAFE6898" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF91C6.AAFE6898 Content-Type: text/plain; charset="iso-8859-1" >You may find quite a few people who are doing amplifier placement analysis >who might disagree with you especially when you talk about doing dynamic >optical bypass/cut-through with no OEO. So for example, if you cascade >several amplifiers for a single segment, the nonlinear characteristics of >one amplifier can be offset by a subsequent amplifier. Today this balancing >act is done by hand. Clearly it is going to be hard if not impossible to deal with hand placement of amplifiers in a dynamic routing algorithm. (Unless we can have dynamic control over the amplifiers' gain!) I imagine that a dynamic system will have to be more conservative in terms of wavelength spacing, amplifier placement and reach so that solutions computed dynamically actually work. Where these tradeoff's are in the cost performance curve today, I have no idea. Analogy on: It's a bit like making a super high performance motor, lots of hand tweaking, costs a fortune, no interchangeable parts etc. The alternative is a lower power one, cheap to make, easy to maintain, interchangeable parts etc. We see this trend in high technology all the time, we always eventually end up picking a point on the price performance curve to suite use by ordinary folks. A modem is a good example, we could probably hand tweak many connections to reduce noise, cross talk etc. and up the speed of that PARTICULAR link, but its just not cost effective so we make "good-enough-works-almost-anywhere" equipment. > Now lets introduce highly dynamic optical bypass >(i.e., non OEO passthrough) capabilities via lamda switching. You may find >that delicate balance is not so easy to maintain. Another example would be >amplified spontaneous emission in EDFAs which are cascaded in optical bypass >systems with a large number of amplifiers. We caould also talk about >polization effects in cascaded EDFAs. So the point is that, when you are >talking about optical bypass systems the equation gets a lot uglier than a >simple shortes path first calculation because of inherent issues with the >optics which are different from electrical issues. Agreed, but these are not I believe justification for forcing an overlay model. Just because there are more constraints that need to be considered to compute an effective end to end optical path and that this computation may initially be N^3 or N^4, does not mean that we should hide behind an overlay. The only justification I can think of would be for optical switching technology that is still so fragile that it cannot be dynamically controlled....yet. One could deal with such technology by having these hand tuned, highly optimal paths known to the topology as a link or FA. So you are in a sense overlaying because you have no choice, but for other dynamically controllable paths you stay flat. What would be extremely useful would be a taxonomy of the different constraints, what algorithms are known to deal with them, what's the cost of relaxing the constraint etc. Any volunteers? Any good references? Cheers, Peter ------_=_NextPart_001_01BF91C6.AAFE6898 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Optical IP activities


    >You may find quite a few people who are doing amplifier = placement analysis
    >who might disagree with you especially when you talk = about doing dynamic
    >optical bypass/cut-through with no OEO.  So for = example, if you cascade
    >several amplifiers for a single segment, the nonlinear = characteristics of
    >one amplifier can be offset by a subsequent = amplifier.  Today this balancing
    >act is done by hand.

         Clearly it = is going to be hard if not impossible to deal with hand placement of = amplifiers in a dynamic routing algorithm. (Unless = we can have dynamic control = over the amplifiers' = gain!) I imagine that a dynamic system will have to be more conservative in = terms of wavelength = spacing, amplifier placement and reach so that solutions computed dynamically actually = work.  Where = these tradeoff's are in the cost performance = curve = today, I have no = idea.

        Analogy on: It's = a bit like making a super high performance motor, lots of hand = tweaking, costs a fortune, no interchangeable parts etc. = The alternative is a lower power one, = cheap to make, easy to = maintain, interchangeable parts etc. We see this trend in high = technology all the time, we = always eventually end up picking a point on the price performance curve = to suite use = by ordinary folks. A modem is = a good example, we could probably hand tweak many connections to reduce = noise, cross talk etc. and up the speed of that PARTICULAR link, but = its just not cost effective so we make "good-enough-works-almost-anywhere" = equipment.

    > Now lets introduce highly dynamic optical bypass
    >(i.e., non OEO passthrough) capabilities via lamda = switching.  You may find
    >that delicate balance is not so easy to maintain.  = Another example would be
    >amplified spontaneous emission in EDFAs which are = cascaded in optical bypass
    >systems with a large number of amplifiers.  We = caould also talk about
    >polization effects in cascaded EDFAs.  So the point = is that, when you are
    >talking about optical bypass systems the equation gets a = lot uglier than a
    >simple shortes path first calculation because of = inherent issues with the
    >optics which are different from electrical = issues.

        Agreed, but = these are not I believe justification for forcing = an overlay model. Just = because there are more constraints that need to be considered to = compute an effective end to end optical path and that = this computation may initially = be N^3 or N^4, does not = mean that we should = hide behind an = overlay. = The only justification I can think of = would be = for  = optical switching = technology that is = still so fragile that it = cannot be dynamically controlled....yet. One = could deal with such technology by having these hand tuned, highly = optimal paths known to the = topology as a link or FA. So you are in a sense overlaying because you = have no choice, but for other dynamically controllable paths you stay = flat.

        What would be = extremely useful would be a taxonomy of the different = constraints, what = algorithms are known to deal with them, what's the cost of relaxing the constraint = etc.  = Any volunteers? Any good references?

        = Cheers,

        = Peter

     
      =20

------_=_NextPart_001_01BF91C6.AAFE6898-- From owner-mpls@UU.NET Sun Mar 19 19:50:28 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07643 for ; Sun, 19 Mar 2000 19:50:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihgl09912; Mon, 20 Mar 2000 00:49:58 GMT Received: by mail-control.mail.uu.net id QQihgl23527 for mpls-outgoing; Mon, 20 Mar 2000 00:49:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihgl23522 for ; Mon, 20 Mar 2000 00:49:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihgl16977 for ; Sun, 19 Mar 2000 19:49:27 -0500 (EST) Received: from hercules by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQihgl09311 for ; Mon, 20 Mar 2000 00:49:27 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id QAA08614; Sun, 19 Mar 2000 16:49:30 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Sun, 19 Mar 2000 16:49:32 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A634683E@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'George Swallow'" , "'vsriniva@cosinecom.com'" Cc: "'Thomas D. Nadeau'" , "'cheenu@tachion.con'" , "'mpls@UU.NET'" Subject: Request for LSR MIB WG Last Call Date: Sun, 19 Mar 2000 16:49:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk George and Vijay, We haven't seen any further responses from the people who were objecting about issuing a last call on the LSR MIB. We believe we have mitigated their unfounded concerns about the LSR MIB having changed significantly since last rev of Feb 16 '00. Besides, the changes made in the last rev are mostly based on comments made on the mailing list. Can we have a WG last call issued on the LSR MIB? Thanks, -arun (cheenu and tom) > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of George > Swallow > Sent: Wednesday, March 15, 2000 7:28 AM > To: Joan Cucchiara > Cc: 'Thomas D. Nadeau'; Adrian Farrel; mpls@UU.NET; > 'swallow@cisco.com'; > 'vsriniva@cosinecom.com'; swallow@cisco.com > Subject: Re: LSR MIB WG Last Call > > > Joan - > > I believe that Tom merely meant to suggest that the LSR mib was now > ready for last call. Unless I hear objections I'll issue one before > the day is out. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Sun Mar 19 20:27:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21947 for ; Sun, 19 Mar 2000 20:27:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihgn14696; Mon, 20 Mar 2000 01:27:03 GMT Received: by mail-control.mail.uu.net id QQihgn03342 for mpls-outgoing; Mon, 20 Mar 2000 01:26:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihgn03337 for ; Mon, 20 Mar 2000 01:26:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihgn19238 for ; Sun, 19 Mar 2000 20:26:30 -0500 (EST) Received: from tisch.mail.mindspring.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tisch.mail.mindspring.net [207.69.200.157]) id QQihgn09615 for ; Mon, 20 Mar 2000 01:26:30 GMT Received: from jluciani (ip4.cambridge2.ma.pub-ip.psi.net [38.32.112.4]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA15449; Sun, 19 Mar 2000 20:26:26 -0500 (EST) Message-ID: <002701bf920b$4f26c660$293efea9@jluciani> Reply-To: "James V. Luciani" From: "James V. Luciani" To: "Peter Ashwood-Smith" , "'Debanjan'" Cc: "mpls" References: <03E3E0690542D211A1490000F80836F4029F9765@zcard00f.ca.nortel.com> Subject: Re: Optical IP activities Date: Sun, 19 Mar 2000 20:26:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit RE: Optical IP activitiesYou got to love these analogies. :-) > Analogy on: It's a bit like making a super high performance motor, lots of hand tweaking, costs a fortune, no interchangeable parts >etc. The alternative is a lower power one, cheap to make, easy to maintain, interchangeable parts etc. We see this trend in high >technology all the time, we always eventually end up picking a point on the price performance curve to suite use by ordinary folks. A >modem is a good example, we could probably hand tweak many connections to reduce noise, cross talk etc. and up the speed of that I agree with what you are saying for the most part. I suppose what I am also trying to say is that it is not clear to me that we know how to find out what is "good enough" for every possible optical path, apriori, in a complex network with a large diameter. We might need to design a path integrity protocol to make sure that a given path is usable end to end (drop to drop I suppose). At the risk of making folks sick, it might be useful to see if there is a way to make this part of the setup processing. I certainly don't want all possible parameters to be part of the path calculation lest we get O(n^k) for large k as result of number of constraints. And you are correct, it might not be a problem but I get a little nervous when folks say something like this is simple. >PARTICULAR link, but its just not cost effective so we make "good-enough-works-almost-anywhere" equipment. >> Now lets introduce highly dynamic optical bypass >>(i.e., non OEO passthrough) capabilities via lamda switching. You may find >>that delicate balance is not so easy to maintain. Another example would be >>amplified spontaneous emission in EDFAs which are cascaded in optical bypass >>systems with a large number of amplifiers. We caould also talk about >>polization effects in cascaded EDFAs. So the point is that, when you are >>talking about optical bypass systems the equation gets a lot uglier than a >>simple shortes path first calculation because of inherent issues with the >>optics which are different from electrical issues. I actually did not mean to suggest that we have to force only an overlay model. I did strongly intend to suggest that it might be the right choice though and that suggesting that the peer model is a simple bit of engineering might be inaccurate. > Agreed, but these are not I believe justification for forcing an overlay model. Just because there are more constraints that need to >be considered to compute an effective end to end optical path and that this computation may initially be N^3 or N^4, does not mean >that we should hide behind an overlay. The only justification I can think of would be for optical switching technology that is still so >fragile that it cannot be dynamically controlled....yet. One could deal with such technology by having these hand tuned, highly optimal >paths known to the topology as a link or FA. So you are in a sense overlaying because you have no choice, but for other dynamically >controllable paths you stay flat. Good point. And I volunteer to read whatever you write on the subject. OK.. I will even do my part if you want to start. > What would be extremely useful would be a taxonomy of the different constraints, what algorithms are known to deal with them, >what's the cost of relaxing the constraint etc. Any volunteers? Any good references? --JIm From owner-mpls@UU.NET Mon Mar 20 06:03:08 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03247 for ; Mon, 20 Mar 2000 06:03:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihia03463; Mon, 20 Mar 2000 11:03:04 GMT Received: by mail-control.mail.uu.net id QQihia12678 for mpls-outgoing; Mon, 20 Mar 2000 11:02:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihia12620 for ; Mon, 20 Mar 2000 11:02:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihia18892 for ; Mon, 20 Mar 2000 06:02:04 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQihia20130 for ; Mon, 20 Mar 2000 11:02:04 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 11:01:49 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1404B9@monk.datcon.co.uk> From: Adrian Farrel To: mpls@UU.NET Cc: cheenu@tachion.com, arun@force10networks.com, tnadeau@cisco.com Subject: Comments on draft-ietf-mpls-te-mib-03.txt Date: Mon, 20 Mar 2000 11:01:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom, Arun, Cheenu. I've now had a chance to read the latest draft of the TE MIB (the benefits of long-haul flights!). Good work, the MIB is definitely stabilizing. As usual I have a bunch of comments which I have classified. I hope these are of use to you. Major Omissions 1. Control of Notifications I regard it as important to allow a facility for the Management Tool to disable notifications to save resources. In an email to Tom on 5th Jan I suggested some ASN.1 for two top level objects to achieve this. Do you have any objections to adding this function? Would you like me to resend you the ASN.1? 2. Support for configuring DiffServ LSPs draft-ietf-mpls-diff-ext is well progressed. I think it would be sensible to offer support for configuring E-LSPs and L-LSPs at the ingress. Do you agree? In the above-mentioned email to Tom, I suggested some ASN.1 to achieve this. Would you like me to resend it? I suspect that the ASN.1 should be run past the authors of the diff-ext draft to check that it is in line with their requirements. 3. LSPId explicit hop type Is there any reason to prevent configuration of an explicit hop of type LSPId? I suggested some ASN.1 for this in an email to Tom on 7th Jan. 4. Non-use of ERO This is a bit philosophical :-Z If I know my egress but I have no requirement to specify an ER, I can set up just one hop showing a loose hop to the egress. How can the protocol code tell the difference between a request to use an ER object/TLV with a single hop, and a request to use no ER object/TLV? Things that influence this are - is the route pinned? - do all of the LSRs on the route support ER? Clearly the protocol code can make a local policy decision on whether to include the ER object/TLV based on this information. Without appropriate configuration, it may be necessary (e.g. in RSVP) to experiment by sending an ER and finding out if the LSRs on the path reject it. Would it be worth adding mplsTunnelEgress to the main TunnelTable thereby allowing the ER to be omitted? Questions/Clarifications 5. Make before break I think that the TunnelInstance object gives the facility for controlling make before break, but I believe it would enhance the draft to add some explanation of how this field can be used. 6. MPLS Tunnel Resource Table This table is a welcome addition. I believe you need to be very careful because of the differences between forward and reverse resource reservation. For example, for an RSVP tunnel, what is configured here must be the TSpec. Clearly, sharing TSpecs is useful from a configuration point of view, but says nothing about sharing of resources which is determined elsewhere in the network. Is it your intention that this table is updated on the reverse path? 7. MplsTunnelIndex Although current MPLS tunnels signaling protocols only support 16 bits to identify a tunnel from a specific ingress, it may be that some future protocol will allow a greater number of tunnels. Would it be wise to prepare for this by allowing MplsTunnelIndex to have a greater range? 8. Cookies These are defined as read-only. Do we need write access to configure them for bi-directional tunnels? 9. mplsTunnelHopTable This is currently indexed by mplsTunnelIndex. Does this mean that different instances of a tunnel as defined by mplsTunnelInstance cannot have different routes? If you add mplsTunnelInstance as an index to the HopTable, it means that each instance must have its own ER defined and cannot share the definition for all instances of the same LSP. 10. mplsTunnelHopTable The description says that you can specify the outgoing interface at the tunnel ingress through the first hop of the ER. Is this done using the IP address for the interface? Editorial 11. Example The example in section 7 needs updating in line with the changes to the tables. - IsMergeable, IsPersistent and LocalProtectInUse are no longer objects in the table. - TunnelIfIndex, LocalCookie and RemoteCookie are read-only so shouldn't be modified here. - The example values for some of the objects are, perhaps, a little unusual for some of the objects (e.g. TunnelDirection, RemoteCookie) - Would you expect to set the In and Out resource values for an 'in' tunnel. 12. References The version numbers of the referenced drafts in DESCRIPTION fields in the MIB tables need updating. I believe that any drafts referenced in this way need to be flagged as "work in progress". 13. Terminology In a couple of places you have used ERLSP. It's a bit pedantic, but I think we should refer to CRLSP (or perhaps just LSP) since explicit routes don't have to be used. 14. Textual Convention for IP Addresses I believe that there is a move to define a single textual convention to cover IPv4 and IPv6 addresses. The aim is to avoid the need for each new MIB to define its own textual convention. It might be worth looking into this. 15. mplsTunnelXCIndex It would be good to expand on the Description. Explain that this object is only writeable in conjunction with pre-existing entries in the LSR MIB. Say that in normal signaled operation this object will be set by the LSR. Explain the meaning of zero. 16. mplsTunnelSignallingProto Assuming future protocols will come along, would it be tidier to set the value of 'other' higher to allow space for future extension? 17. BITS I'm uneasy about the use of BITS for mplsTunnelSessionAttributes. Asides from whether this is standard in MIBs, I don't see the need. Why not keep the bit fields as separate objects? 18. Defaults for mplsTunnelSessionAttributes, mplsTunnelInstancePriority and mplsTunnelAdminStatus 19. MplsTunnelResourceEntry. Most of the objects describe mappings to the objects in the mplsTSpecTable of the LSR MIB in terms of "copying". I think you should relax your text a bit and just say that the values correspond to the values of the objects in the mplsTSpecTable. 20. MplsTunnelARHopEntry I can see that mplsTunnelARHopAsNumber would be useful or interesting to ISPs (perhaps they would edit the RRO on exit from their AS, but this is currently not supported by the signaling protocols. 21. Notifications Add mplsTunnelInstance. Typographic Section 7, paragraph 1, line two. Insert "a" to read "create a loosely routed" Formatting needs a little tidying up in places - section 7, mplsTunnelIsPersistent - section 8, Imports - MplsTunnelEntry - mplsTunnelOperStatus - mplsTunnelResourceEntry - mplsTunnelGroup Integer options It is usual to list these with each entry on a new line (e.g. mplsTunnelDirection). mplsSessionAttributes. - The Description refers to fastReroute, the bit is called ingressMayReroute - localProtectionAvailable "det4ected" - isPinned "Indicates" read "indicates" mplsTunnelOwner. Value 2 is called 'ldp'. Risking the dangerous political field, can I suggest that this should be 'crldp'. mplsTunnelInstancePriority first line for "which" read "the" mplsTunnelInstancePriority line 8 for "particular a" read "a particular" mplsTunnelResourceIndexNext/mplsTunnelResourceIndex Decide on common syntax. Zero should not be a valid value for mplsTunnelResourceIndex mplsTunnelResourceInMaxRate etc. MplsBitRate is defined in the LSR MIB in 1,000 bits per second. The descriptions for these fields need updating. Additionally, the UNITS tag is ood. mplsTunnelHopStrictOrLoose Delete "is" to read "this tunnel hop" mplsTunnelARHopEntry "represents an currently" -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Mon Mar 20 06:06:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04754 for ; Mon, 20 Mar 2000 06:06:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihia24580; Mon, 20 Mar 2000 11:06:50 GMT Received: by mail-control.mail.uu.net id QQihia15178 for mpls-outgoing; Mon, 20 Mar 2000 11:06:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihia15131 for ; Mon, 20 Mar 2000 11:06:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihia19046 for ; Mon, 20 Mar 2000 06:06:11 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQihia23856 for ; Mon, 20 Mar 2000 11:06:10 GMT Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 11:06:00 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1404BA@monk.datcon.co.uk> From: Adrian Farrel To: mpls@UU.NET Cc: cheenu@tachion.com, arun@force10networks.com, tnadeau@cisco.com, jcucchiara@brixnet.com Subject: Further thoughts on the location of the LIB Date: Mon, 20 Mar 2000 11:05:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk All, Having thought about this further, I quite like the access to the LIB in the LSR MIB. In particular, it is relatively easy to determine the output interface and label from the input interface and label. On the other hand, the LIB is firmly established in the LDP MIB which needs to move forward. There are two options here which don't force any immediate changes. Firstly, there is good precedent for duplicating information in different MIBs especially where those MIBs are likely to be implemented in separate components of the system. (For example the TSpec which is present in the TE MIB and LSR MIB). Secondly, if after both MIBs have been developed and implemented, it is decided that the LIB is no longer appropriate in the LDP MIB it can be obsoleted. This is something that has happened in many MIBs in the past. Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Mon Mar 20 06:52:57 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19832 for ; Mon, 20 Mar 2000 06:52:57 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihid04356; Mon, 20 Mar 2000 11:52:52 GMT Received: by mail-control.mail.uu.net id QQihid21747 for mpls-outgoing; Mon, 20 Mar 2000 11:52:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihid21742 for ; Mon, 20 Mar 2000 11:52:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihid00483 for ; Mon, 20 Mar 2000 06:51:53 -0500 (EST) Received: from marvin.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQihid29536 for ; Mon, 20 Mar 2000 11:51:53 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Mon, 20 Mar 2000 11:26:17 +0000 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Mon, 20 Mar 2000 11:26:17 -0000 Message-ID: From: "Nakarmi,U,Utthan,NZD9 R" To: mpls@UU.NET Subject: MPLS support of Diff-Serv( OA and PSC) Date: Mon, 20 Mar 2000 11:26:02 -0000 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Dear all, I will be grateful if someone can clarify the term OA(ordered aggregate) and PSC(PHB Scheduling class) with some good and clear examples. These terms are taken from MPLS support of Diff-serv and definations in it just won't get into my head. With this draft paper I am also begining to get confused with BA and PHB. Please do also inform me how this terms are related with E-LSP and L-LSP. cheers utthan From owner-mpls@UU.NET Mon Mar 20 07:33:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03745 for ; Mon, 20 Mar 2000 07:33:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihig06514; Mon, 20 Mar 2000 12:33:19 GMT Received: by mail-control.mail.uu.net id QQihig02371 for mpls-outgoing; Mon, 20 Mar 2000 12:32:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihig02362 for ; Mon, 20 Mar 2000 12:32:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihig03126 for ; Mon, 20 Mar 2000 07:32:14 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQihig05582 for ; Mon, 20 Mar 2000 12:32:14 GMT Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 12:32:07 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1404C1@monk.datcon.co.uk> From: Adrian Farrel To: rsvp@ISI.EDU, mpls@UU.NET Subject: Sender TSpec on PathTear Date: Mon, 20 Mar 2000 12:32:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk All, RFC 2205 states that Sender TSpec is mandatory on a PathTear if a Sender Descriptor is included. ::= [ ] [ ] ::= (see earlier definition) Where the earlier definition of sender Descriptor is found in the definition of Path Message and is... ::= [ ] draft-ietf-mpls-rsvp-lsp-tunnel-05 does not make any change to this requirement, but does add [RECORD_ROUTE] as an optional field in Sender Descriptor. It seems to me that SENDER_TSPEC, ADSPEC and RECORD_ROUTE do not add anything to PathTear. Can anyone comment on whether or not it would be better to define PathTear as ::= [ ] [] Of course the effect of this can be mitigated by applying the usual rules of conservative on send, liberal on receive. Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Mon Mar 20 08:30:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27478 for ; Mon, 20 Mar 2000 08:30:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihik15359; Mon, 20 Mar 2000 13:30:21 GMT Received: by mail-control.mail.uu.net id QQihik13082 for mpls-outgoing; Mon, 20 Mar 2000 13:30:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihij13041 for ; Mon, 20 Mar 2000 13:29:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihij07710 for ; Mon, 20 Mar 2000 08:29:54 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihij10762 for ; Mon, 20 Mar 2000 13:29:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA28475 for mpls@uu.net; Mon, 20 Mar 2000 08:29:52 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihij13032 for ; Mon, 20 Mar 2000 13:29:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihij07683 for ; Mon, 20 Mar 2000 08:29:37 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQihij14506 for ; Mon, 20 Mar 2000 13:29:36 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA29829; Mon, 20 Mar 2000 08:29:29 -0500 (EST) Message-Id: <4.2.2.20000320081904.04353410@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 20 Mar 2000 08:20:18 -0500 To: Adrian Farrel , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Comments on draft-ietf-mpls-te-mib-03.txt Cc: cheenu@tachion.com, arun@force10networks.com In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E1404B9@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_64883761==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_64883761==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Adrian, As Cheenu, Arun and I will reply to your questions/ comments shortly. Arun is out of town for the next day or so, so we may not get back to you until later in the week. --Tom >I've now had a chance to read the latest draft of the TE MIB >(the benefits of long-haul flights!). > >Good work, the MIB is definitely stabilizing. > >As usual I have a bunch of comments which I have classified. I >hope these are of use to you. > >Major Omissions > >1. Control of Notifications > I regard it as important to allow a facility for the > Management Tool to disable notifications to save resources. > In an email to Tom on 5th Jan I suggested some ASN.1 for two > top level objects to achieve this. > Do you have any objections to adding this function? > Would you like me to resend you the ASN.1? > >2. Support for configuring DiffServ LSPs > draft-ietf-mpls-diff-ext is well progressed. I think it would > be sensible to offer support for configuring E-LSPs and L-LSPs > at the ingress. Do you agree? > In the above-mentioned email to Tom, I suggested some ASN.1 to > achieve this. Would you like me to resend it? > I suspect that the ASN.1 should be run past the authors of the > diff-ext draft to check that it is in line with their > requirements. > >3. LSPId explicit hop type > Is there any reason to prevent configuration of an explicit hop > of type LSPId? I suggested some ASN.1 for this in an email to > Tom on 7th Jan. > >4. Non-use of ERO > This is a bit philosophical :-Z > If I know my egress but I have no requirement to specify an ER, I > can set up just one hop showing a loose hop to the egress. > How can the protocol code tell the difference between a request to > use an ER object/TLV with a single hop, and a request to use no > ER object/TLV? > > Things that influence this are > - is the route pinned? > - do all of the LSRs on the route support ER? > Clearly the protocol code can make a local policy decision on > whether to include the ER object/TLV based on this information. > Without appropriate configuration, it may be necessary (e.g. in > RSVP) to experiment by sending an ER and finding out if the LSRs > on the path reject it. > > Would it be worth adding mplsTunnelEgress to the main TunnelTable > thereby allowing the ER to be omitted? > >Questions/Clarifications > >5. Make before break > I think that the TunnelInstance object gives the facility for > controlling make before break, but I believe it would enhance the > draft to add some explanation of how this field can be used. > >6. MPLS Tunnel Resource Table > This table is a welcome addition. > I believe you need to be very careful because of the differences > between forward and reverse resource reservation. For example, > for an RSVP tunnel, what is configured here must be the TSpec. > Clearly, sharing TSpecs is useful from a configuration point of > view, but says nothing about sharing of resources which is > determined elsewhere in the network. Is it your intention that > this table is updated on the reverse path? > >7. MplsTunnelIndex > Although current MPLS tunnels signaling protocols only support > 16 bits to identify a tunnel from a specific ingress, it may be > that some future protocol will allow a greater number of tunnels. > Would it be wise to prepare for this by allowing MplsTunnelIndex > to have a greater range? > >8. Cookies > These are defined as read-only. Do we need write access to > configure them for bi-directional tunnels? > >9. mplsTunnelHopTable > This is currently indexed by mplsTunnelIndex. Does this mean that > different instances of a tunnel as defined by mplsTunnelInstance > cannot have different routes? > If you add mplsTunnelInstance as an index to the HopTable, it means > that each instance must have its own ER defined and cannot share the > definition for all instances of the same LSP. > >10. mplsTunnelHopTable > The description says that you can specify the outgoing interface at > the tunnel ingress through the first hop of the ER. Is this done > using the IP address for the interface? > >Editorial > >11. Example > The example in section 7 needs updating in line with the changes > to the tables. > - IsMergeable, IsPersistent and LocalProtectInUse are no longer > objects in the table. > - TunnelIfIndex, LocalCookie and RemoteCookie are read-only so > shouldn't be modified here. > - The example values for some of the objects are, perhaps, a > little unusual for some of the objects (e.g. TunnelDirection, > RemoteCookie) > - Would you expect to set the In and Out resource values for an > 'in' tunnel. > >12. References > The version numbers of the referenced drafts in DESCRIPTION fields > in the MIB tables need updating. I believe that any drafts > referenced in this way need to be flagged as "work in progress". > >13. Terminology > In a couple of places you have used ERLSP. It's a bit pedantic, > but I think we should refer to CRLSP (or perhaps just LSP) since > explicit routes don't have to be used. > >14. Textual Convention for IP Addresses > I believe that there is a move to define a single textual convention > to cover IPv4 and IPv6 addresses. The aim is to avoid the need for > each new MIB to define its own textual convention. It might be worth > looking into this. > >15. mplsTunnelXCIndex > It would be good to expand on the Description. Explain that this > object is only writeable in conjunction with pre-existing entries > in the LSR MIB. Say that in normal signaled operation this object > will be set by the LSR. Explain the meaning of zero. > >16. mplsTunnelSignallingProto > Assuming future protocols will come along, would it be tidier to > set the value of 'other' higher to allow space for future extension? > >17. BITS > I'm uneasy about the use of BITS for mplsTunnelSessionAttributes. > Asides from whether this is standard in MIBs, I don't see the need. > Why not keep the bit fields as separate objects? > >18. Defaults for mplsTunnelSessionAttributes, > mplsTunnelInstancePriority and mplsTunnelAdminStatus > >19. MplsTunnelResourceEntry. > Most of the objects describe mappings to the objects in the > mplsTSpecTable of the LSR MIB in terms of "copying". I think you > should relax your text a bit and just say that the values correspond > to the values of the objects in the mplsTSpecTable. > >20. MplsTunnelARHopEntry > I can see that mplsTunnelARHopAsNumber would be useful or > interesting to ISPs (perhaps they would edit the RRO on exit from > their AS, but this is currently not supported by the signaling > protocols. > >21. Notifications > Add mplsTunnelInstance. > >Typographic > >Section 7, paragraph 1, line two. >Insert "a" to read "create a loosely routed" > >Formatting needs a little tidying up in places >- section 7, mplsTunnelIsPersistent >- section 8, Imports >- MplsTunnelEntry >- mplsTunnelOperStatus >- mplsTunnelResourceEntry >- mplsTunnelGroup > >Integer options >It is usual to list these with each entry on a new line (e.g. >mplsTunnelDirection). > >mplsSessionAttributes. >- The Description refers to fastReroute, the bit is called > ingressMayReroute >- localProtectionAvailable "det4ected" >- isPinned "Indicates" read "indicates" > >mplsTunnelOwner. Value 2 is called 'ldp'. Risking the dangerous >political field, can I suggest that this should be 'crldp'. > >mplsTunnelInstancePriority first line for "which" read "the" > >mplsTunnelInstancePriority line 8 for "particular a" read "a >particular" > >mplsTunnelResourceIndexNext/mplsTunnelResourceIndex >Decide on common syntax. Zero should not be a valid value for >mplsTunnelResourceIndex > >mplsTunnelResourceInMaxRate etc. >MplsBitRate is defined in the LSR MIB in 1,000 bits per second. >The descriptions for these fields need updating. Additionally, >the UNITS tag is ood. > >mplsTunnelHopStrictOrLoose Delete "is" to read "this tunnel hop" > >mplsTunnelARHopEntry "represents an currently" > >-- >Adrian Farrel mailto:af@datcon.co.uk >Network Convergence Group >Data Connection Ltd., Chester, UK >http://www.datcon.co.uk/ >Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 --=====================_64883761==_.ALT Content-Type: text/html; charset="us-ascii"         
        Hi Adrian,

        As Cheenu, Arun and I will reply to your questions/
comments shortly. Arun is out of town for the next day
or so, so we may not get back to you until later in the
week.

        --Tom


I've now had a chance to read the latest draft of the TE MIB
(the benefits of long-haul flights!).

Good work, the MIB is definitely stabilizing.

As usual I have a bunch of comments which I have classified.  I
hope these are of use to you.

Major Omissions

1. Control of Notifications
   I regard it as important to allow a facility for the
   Management Tool to disable notifications to save resources.
   In an email to Tom on 5th Jan I suggested some ASN.1 for two
   top level objects to achieve this.
   Do you have any objections to adding this function?
   Would you like me to resend you the ASN.1?

2. Support for configuring DiffServ LSPs
   draft-ietf-mpls-diff-ext is well progressed. I think it would
   be sensible to offer support for configuring E-LSPs and L-LSPs
   at the ingress. Do you agree?
   In the above-mentioned email to Tom, I suggested some ASN.1 to
   achieve this.  Would you like me to resend it?
   I suspect that the ASN.1 should be run past the authors of the
   diff-ext draft to check that it is in line with their
   requirements.

3. LSPId explicit hop type
   Is there any reason to prevent configuration of an explicit hop
   of type LSPId?  I suggested some ASN.1 for this in an email to
   Tom on 7th Jan.

4. Non-use of ERO
   This is a bit philosophical :-Z
   If I know my egress but I have no requirement to specify an ER, I
   can set up just one hop showing a loose hop to the egress.
   How can the protocol code tell the difference between a request to
   use an ER object/TLV with a single hop, and a request to use no
   ER object/TLV?

   Things that influence this are
   - is the route pinned?
   - do all of the LSRs on the route support ER?
   Clearly the protocol code can make a local policy decision on
   whether to include the ER object/TLV based on this information.
   Without appropriate configuration, it may be necessary (e.g. in
   RSVP) to experiment by sending an ER and finding out if the LSRs
   on the path reject it.

   Would it be worth adding mplsTunnelEgress to the main TunnelTable
   thereby allowing the ER to be omitted?

Questions/Clarifications

5. Make before break
   I think that the TunnelInstance object gives the facility for
   controlling make before break, but I believe it would enhance the
   draft to add some explanation of how this field can be used.

6. MPLS Tunnel Resource Table
   This table is a welcome addition.
   I believe you need to be very careful because of the differences
   between forward and reverse resource reservation.  For example,
   for an RSVP tunnel, what is configured here must be the TSpec. 
   Clearly, sharing TSpecs is useful from a configuration point of
   view, but says nothing about sharing of resources which is
   determined elsewhere in the network.  Is it your intention that
   this table is updated on the reverse path?
  
7. MplsTunnelIndex
   Although current MPLS tunnels signaling protocols only support
   16 bits to identify a tunnel from a specific ingress, it may be
   that some future protocol will allow a greater number of tunnels.
   Would it be wise to prepare for this by allowing MplsTunnelIndex
   to have a greater range?

8. Cookies
   These are defined as read-only. Do we need write access to
   configure them for bi-directional tunnels?

9. mplsTunnelHopTable
   This is currently indexed by mplsTunnelIndex.  Does this mean that
   different instances of a tunnel as defined by mplsTunnelInstance
   cannot have different routes? 
   If you add mplsTunnelInstance as an index to the HopTable, it means
   that each instance must have its own ER defined and cannot share the
   definition for all instances of the same LSP.

10. mplsTunnelHopTable
   The description says that you can specify the outgoing interface at
   the tunnel ingress through the first hop of the ER.  Is this done
   using the IP address for the interface?

Editorial

11. Example
   The example in section 7 needs updating in line with the changes
   to the tables.
   - IsMergeable, IsPersistent and LocalProtectInUse are no longer
     objects in the table.
   - TunnelIfIndex, LocalCookie and RemoteCookie are read-only so
     shouldn't be modified here.
   - The example values for some of the objects are, perhaps, a
     little unusual for some of the objects (e.g. TunnelDirection,
     RemoteCookie)
   - Would you expect to set the In and Out resource values for an
     'in' tunnel.

12. References
   The version numbers of the referenced drafts in DESCRIPTION fields
   in the MIB tables need updating.  I believe that any drafts
   referenced in this way need to be flagged as "work in progress".

13. Terminology
   In a couple of places you have used ERLSP.  It's a bit pedantic,
   but I think we should refer to CRLSP (or perhaps just LSP) since
   explicit routes don't have to be used.

14. Textual Convention for IP Addresses
   I believe that there is a move to define a single textual convention
   to cover IPv4 and IPv6 addresses.  The aim is to avoid the need for
   each new MIB to define its own textual convention.  It might be worth
   looking into this.

15. mplsTunnelXCIndex
   It would be good to expand on the Description.  Explain that this
   object is only writeable in conjunction with pre-existing entries
   in the LSR MIB.  Say that in normal signaled operation this object
   will be set by the LSR.  Explain the meaning of zero.

16. mplsTunnelSignallingProto
   Assuming future protocols will come along, would it be tidier to
   set the value of 'other' higher to allow space for future extension?

17. BITS
   I'm uneasy about the use of BITS for mplsTunnelSessionAttributes.
   Asides from whether this is standard in MIBs, I don't see the need.
   Why not keep the bit fields as separate objects?

18. Defaults for mplsTunnelSessionAttributes,
   mplsTunnelInstancePriority and mplsTunnelAdminStatus

19. MplsTunnelResourceEntry.
   Most of the objects describe mappings to the objects in the
   mplsTSpecTable of the LSR MIB in terms of "copying".  I think you
   should relax your text a bit and just say that the values correspond
   to the values of the objects in the mplsTSpecTable.

20. MplsTunnelARHopEntry
   I can see that mplsTunnelARHopAsNumber would be useful or
   interesting to ISPs (perhaps they would edit the RRO on exit from
   their AS, but this is currently not supported by the signaling
   protocols.

21. Notifications
   Add mplsTunnelInstance.

Typographic

Section 7, paragraph 1, line two.
Insert "a" to read "create a loosely routed"

Formatting needs a little tidying up in places
- section 7, mplsTunnelIsPersistent
- section 8, Imports
- MplsTunnelEntry
- mplsTunnelOperStatus
- mplsTunnelResourceEntry
- mplsTunnelGroup

Integer options
It is usual to list these with each entry on a new line (e.g.
mplsTunnelDirection).

mplsSessionAttributes.
- The Description refers to fastReroute, the bit is called
  ingressMayReroute
- localProtectionAvailable "det4ected"
- isPinned "Indicates" read "indicates"

mplsTunnelOwner.  Value 2 is called 'ldp'.  Risking the dangerous
political field, can I suggest that this should be 'crldp'.

mplsTunnelInstancePriority first line for "which" read "the"

mplsTunnelInstancePriority line 8 for "particular a" read "a
particular"

mplsTunnelResourceIndexNext/mplsTunnelResourceIndex
Decide on common syntax.  Zero should not be a valid value for
mplsTunnelResourceIndex

mplsTunnelResourceInMaxRate etc.
MplsBitRate is defined in the LSR MIB in 1,000 bits per second.
The descriptions for these fields need updating.  Additionally,
the UNITS tag is ood.

mplsTunnelHopStrictOrLoose  Delete "is" to read "this tunnel hop"

mplsTunnelARHopEntry "represents an currently"

--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
--=====================_64883761==_.ALT-- From owner-mpls@UU.NET Mon Mar 20 09:37:58 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27617 for ; Mon, 20 Mar 2000 09:37:58 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihio25741; Mon, 20 Mar 2000 14:37:44 GMT Received: by mail-control.mail.uu.net id QQihio24430 for mpls-outgoing; Mon, 20 Mar 2000 14:37:13 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihio24425 for ; Mon, 20 Mar 2000 14:37:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihio07382 for ; Mon, 20 Mar 2000 09:37:10 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQihio25113 for ; Mon, 20 Mar 2000 14:37:09 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id JAA23141; Mon, 20 Mar 2000 09:32:16 -0500 Message-ID: <38D645B4.26A9BCD9@tellium.com> Date: Mon, 20 Mar 2000 09:37:24 -0600 From: Debanjan Saha Reply-To: Tellium@UU.NET, Optical@UU.NET, Systems@tellium.com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ashwood-Smith CC: "'James V. Luciani'" , mpls Subject: Re: Optical IP activities References: <03E3E0690542D211A1490000F80836F4029F9765@zcard00f.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > Agreed, but these are not I believe justification for forcing > an overlay model. Just because there are more constraints that > need to be considered to compute an effective end to end optical > path and that this computation may initially be N^3 or N^4, does > not mean that we should hide behind an overlay. No one is forcing an overlay model. However, I believe that an overlay model is useful in containing the complexities/idiosyncrasies of an optical network within the the optical domain, at least in the short term. Mean while, we can debate how much of this information should be abstracted and disseminated to the routers; and what do we gain from that and at what cost. > The only > justification I can think of would be for optical switching > technology that is still so fragile that it cannot be dynamically > controlled.... I am not sure if I agree with this "fragility" argument. Different physical layers have different constraints and they may be inherent and permanent. > > What would be extremely useful would be a taxonomy of the > different constraints, what algorithms are known to deal with > them, what's the cost of relaxing the constraint etc. Any > volunteers? Any good references? I agree! I can give it a shot, but I need help/input from people in the list. Debanjan From owner-mpls@UU.NET Mon Mar 20 09:43:29 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00461 for ; Mon, 20 Mar 2000 09:43:29 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihio01041; Mon, 20 Mar 2000 14:43:25 GMT Received: by mail-control.mail.uu.net id QQihio24667 for mpls-outgoing; Mon, 20 Mar 2000 14:42:53 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihio24661 for ; Mon, 20 Mar 2000 14:42:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihio16597 for ; Mon, 20 Mar 2000 09:42:37 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQihio22138 for ; Mon, 20 Mar 2000 14:42:37 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 14:42:25 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1404D0@monk.datcon.co.uk> From: Adrian Farrel To: mpls@UU.NET Cc: tnadeau@cisco.com, arun@force10networks.com, cheenu@tachion.com Subject: draft-ietf-mpls-lsr-mib-02.txt nits Date: Mon, 20 Mar 2000 14:42:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Just a couple of nits. Apologies for not coming back with these sooner. I have been at UNH doing interop. 1. LSPID In previous mail exchanges I asked why the LSPID Textual Convention needed to allow 63 bytes. You answered that this was to allow space for IPv6 addresses. There are three points here. - Why would you put an address in the LSPID? The address is a separate part of the cookie - IPv6 addresses don't need 63 bytes - The current protocols only allow exchange of a 2 byte LSPID. 2. Performance Tables Discontinuity Timestamps We discussed this at some length before, but left the issue when I ran out of bandwidth. I was asking for a discontinuity timer for each performance table so that it is possible to understand the scope of the reported values. You responded that the discontinuity timer in the interfaceTable provides sufficient information. This may be the case for the mplsInterfacePerfTable but I don't see how this applies to mplsInSegmentPerfTable and mplsOutSegmentPerfTable. Perhaps you could explain, or reconsider adding these timestamps. 3. DiffServ I believe the question of storing DiffServ information was raised on the list recently. Do you have plans to add such information to the LSR MIB? 4. mplsOutSegmentTSpecIndex You've fixed the InSegmentTSPecIndex to be Integer32, but you also need to fix the Outsegment syntax which is currently Unsigned32. Hope this helps. Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Mon Mar 20 09:58:18 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07385 for ; Mon, 20 Mar 2000 09:58:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihip16662; Mon, 20 Mar 2000 14:58:11 GMT Received: by mail-control.mail.uu.net id QQihip25444 for mpls-outgoing; Mon, 20 Mar 2000 14:57:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihip25439 for ; Mon, 20 Mar 2000 14:57:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihip10264 for ; Mon, 20 Mar 2000 09:57:18 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihip01071 for ; Mon, 20 Mar 2000 14:57:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA08569 for mpls@uu.net; Mon, 20 Mar 2000 09:57:17 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihip25377 for ; Mon, 20 Mar 2000 14:56:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihip18585 for ; Mon, 20 Mar 2000 09:56:48 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQihip00751 for ; Mon, 20 Mar 2000 14:56:48 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07562; Mon, 20 Mar 2000 09:56:43 -0500 (EST) Message-Id: <4.2.2.20000320093612.043471e0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 20 Mar 2000 09:47:06 -0500 To: Adrian Farrel , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: draft-ietf-mpls-lsr-mib-02.txt nits Cc: arun@force10networks.com, cheenu@tachion.com In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E1404D0@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_70092982==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_70092982==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, >1. LSPID > > In previous mail exchanges I asked why the LSPID Textual > Convention needed to allow 63 bytes. You answered that > this was to allow space for IPv6 addresses. > > There are three points here. > - Why would you put an address in the LSPID? The address > is a separate part of the cookie > - IPv6 addresses don't need 63 bytes > - The current protocols only allow exchange of a 2 byte > LSPID. I believe that we were looking to be flexible enough to accommodate any possible label. All of the implementations I know of use much shorter labels. However, we did not wish to preclude any longer ones. The MPLS framework does not specify a size, it just states that, "A label is a short, fixed length, locally significant identifier which is used to identify a FEC." Depending on what you define as "short", you could have 1 byte, or 64 bytes, but probably closer to the lower number. We have not heard from anyone else pro/con on the size which we had chosen, so we left it as is. >2. Performance Tables Discontinuity Timestamps > > We discussed this at some length before, but left the issue > when I ran out of bandwidth. > > I was asking for a discontinuity timer for each performance > table so that it is possible to understand the scope of the > reported values. You responded that the discontinuity timer > in the interfaceTable provides sufficient information. > > This may be the case for the mplsInterfacePerfTable but I > don't see how this applies to mplsInSegmentPerfTable and > mplsOutSegmentPerfTable. Perhaps you could explain, or > reconsider adding these timestamps. There is such a discontinuity timer available from the ifTable which can be used for all tables related to an MPLS interface. >3. DiffServ > > I believe the question of storing DiffServ information was > raised on the list recently. Do you have plans to add such > information to the LSR MIB? If you are referring to the EXP Bits discussion, I think that we are currently of the position that they should be left as is in the MIB. >4. mplsOutSegmentTSpecIndex > > You've fixed the InSegmentTSPecIndex to be Integer32, but you > also need to fix the Outsegment syntax which is currently > Unsigned32. Thanks. I caught this while running the MIB through SMIC and fixing various other things. It will be corrected in the next version. --Tom > >Hope this helps. >Regards, >Adrian >-- >Adrian Farrel mailto:af@datcon.co.uk >Network Convergence Group >Data Connection Ltd., Chester, UK >http://www.datcon.co.uk/ >Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 --=====================_70092982==_.ALT Content-Type: text/html; charset="us-ascii"         
        Hi,

1. LSPID
  
   In previous mail exchanges I asked why the LSPID Textual
   Convention needed to allow 63 bytes.  You answered that
   this was to allow space for IPv6 addresses.

   There are three points here.
   - Why would you put an address in the LSPID?  The address
     is a separate part of the cookie
   - IPv6 addresses don't need 63 bytes
   - The current protocols only allow exchange of a 2 byte
     LSPID.

        I believe that we were looking to be flexible enough to
accommodate any possible label. All of the implementations I
know of use much shorter labels. However, we did not wish to
preclude any longer ones. The MPLS framework does not specify a
size, it just states that, "A label is a short, fixed length,
locally significant identifier which is used to identify a FEC."
Depending on what you define as "short", you could have 1 byte,
or 64 bytes, but probably closer to the lower number. We have
not heard from anyone else pro/con on the size which we had
chosen, so we left it as is.

2. Performance Tables Discontinuity Timestamps
  
   We discussed this at some length before, but left the issue
   when I ran out of bandwidth.
  
   I was asking for a discontinuity timer for each performance
   table so that it is possible to understand the scope of the
   reported values.  You responded that the discontinuity timer
   in the interfaceTable provides sufficient information.
  
   This may be the case for the mplsInterfacePerfTable but I
   don't see how this applies to mplsInSegmentPerfTable and
   mplsOutSegmentPerfTable.  Perhaps you could explain, or
   reconsider adding these timestamps.

        There is such a discontinuity timer available from the
ifTable which can be used for all tables related to an
MPLS interface.
        
3. DiffServ
  
   I believe the question of storing DiffServ information was
   raised on the list recently.  Do you have plans to add such
   information to the LSR MIB?

        If you are referring to the EXP Bits discussion,
I think that we are currently of the position that they
should be left as is in the MIB.

4. mplsOutSegmentTSpecIndex

   You've fixed the InSegmentTSPecIndex to be Integer32, but you
   also need to fix the Outsegment syntax which is currently
   Unsigned32.

        Thanks. I caught this while running the MIB through
SMIC and fixing various other things. It will be corrected
in the next version.

        --Tom




  
Hope this helps.
Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
--=====================_70092982==_.ALT-- From owner-mpls@UU.NET Mon Mar 20 09:58:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07642 for ; Mon, 20 Mar 2000 09:58:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihip17525; Mon, 20 Mar 2000 14:58:47 GMT Received: by mail-control.mail.uu.net id QQihip25460 for mpls-outgoing; Mon, 20 Mar 2000 14:58:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihip25455 for ; Mon, 20 Mar 2000 14:58:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihip18725 for ; Mon, 20 Mar 2000 09:58:04 -0500 (EST) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQihip01469 for ; Mon, 20 Mar 2000 14:58:03 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA22982 for ; Mon, 20 Mar 2000 06:58:01 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA15861 for mpls@uu.net; Mon, 20 Mar 2000 09:58:01 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQigyq02449 for ; Fri, 17 Mar 2000 22:10:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQigyq08943 for ; Fri, 17 Mar 2000 17:10:26 -0500 (EST) Received: from web4002.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web4002.mail.yahoo.com [216.115.104.36]) id QQigyq04446 for ; Fri, 17 Mar 2000 22:10:26 GMT Message-ID: <20000317221025.20090.qmail@web4002.mail.yahoo.com> Received: from [169.226.2.211] by web4002.mail.yahoo.com; Fri, 17 Mar 2000 14:10:25 PST Date: Fri, 17 Mar 2000 14:10:25 -0800 (PST) From: jesse zx Subject: questions To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk I have two questions about benefits of MPLS relative to tradition ip routers: 1)about traffic balancing. in traditional router-based ip network, load balancing is still available through metrics. the following is excerpted from mpls drafts "Some degree of load balancing can be obtained by adjusting the metrics associated with network links. However, there is a limit to how much can be accomplished in this way, ...." can you tell me what the limitation is ? and why mpls doesn't have the limitation? 2)about scaling. when in ip over atm. because router in the boundary ,ATM only provides links and act as cloud, so there are o(N square)complexity. But i remembered that in traditional ip network, we could designate one router as virtual central router, and another as backup. so based on the above information, some description in the mpls-framework-draft is not exactly right. How about your opinion? thanks!!! jesse March/17 __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-mpls@UU.NET Mon Mar 20 09:59:30 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07938 for ; Mon, 20 Mar 2000 09:59:30 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihip02438; Mon, 20 Mar 2000 14:59:24 GMT Received: by mail-control.mail.uu.net id QQihip25479 for mpls-outgoing; Mon, 20 Mar 2000 14:58:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihip25472 for ; Mon, 20 Mar 2000 14:58:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihip18781 for ; Mon, 20 Mar 2000 09:58:27 -0500 (EST) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQihip01750 for ; Mon, 20 Mar 2000 14:58:27 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA23029 for ; Mon, 20 Mar 2000 06:58:25 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA15867 for mpls@uu.net; Mon, 20 Mar 2000 09:58:25 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihfq00392 for ; Sun, 19 Mar 2000 19:38:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihfq23897 for ; Sun, 19 Mar 2000 14:38:27 -0500 (EST) Received: from web125.yahoomail.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web125.yahoomail.com [205.180.60.193]) id QQihfq13251 for ; Sun, 19 Mar 2000 19:38:26 GMT Received: (qmail 7409 invoked by uid 60001); 19 Mar 2000 19:38:25 -0000 Message-ID: <20000319193825.7408.qmail@web125.yahoomail.com> Received: from [63.253.79.60] by web125.yahoomail.com; Sun, 19 Mar 2000 11:38:25 PST Date: Sun, 19 Mar 2000 11:38:25 -0800 (PST) From: Bala Rajagopalan To: petera@nortelnetworks.com Cc: mpls@UU.NET, braja@tellium.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello: From Peter Ashwood-Smith > > What has happened is a general realization that no matter what we >switch on, be it spacecial (fiber), time (TDM), frequency(lambda) or >shim (statistical), the requirements on the signalling and routing >protocols are VERY similar with variations caused by certain physical >properties of each switching mechanism. These variations are probably >not sufficient to warrant completely independent protocols. About the >most serious of these differences is the merge/non merge ability and >even that existed in the statistical (ATM) domain. As a result we are >in the process of rationalizing and distilling out what the common >properties are of all of these mechanisms and trying to build a common >mechanism to deal with them all. We may or may not succeed however >since we rarely all agree on anything. In this particular case, the similarity at a high level is the tenuous (abstract) relationship to label switching. This is where it ends, actually. Whether you should design a new protocol or not is an academic issue; once you're done with all the extensions (and deletions which haven't been discussed much), you essentially have a new protocol (or at least, new functionality). It is very practical to use an existing wrapper (e.g., CRLDP or RSVP) to do the messaging and this is obvious to everyone. But the resulting protocol itself has meaning only in the domain (optical) for which it is designed (please see draft-tang-crldp... for semantic differences, etc). As for your comment about distilling out common properties, etc., it could very well be the case that the basic messaging wrapper is common. Even here, fundamental properties like RSVP soft state may not make sense in environments that are different from IP networks. In the end, it's perhaps practical to look at interactions at the edges of domains and come up with a standard protocol (e.g., wrapped up in RSVP or CRLDP) based on agreed upon requirements. >The single level global/distributed optimal placement problem is "easier" >to >solve than a two level global/optimal placement problem. Actually I >think the two level problem is unsolvable because it lacks exact >data at the second level. A fact I'm sure many operators of existing >overlay networks will attest to. > I'm not contending this at all. The real issue is a practical one, which is whether the entire IP/optical system can be treated as a single network in which routers compute internal paths through the optical network at will. I very much doubt this, since optical mesh networks are being designed for efficient capacity utilization and high responsiveness, with appropriate provisioning and restoration algorithms. How do you tightly integrate routers with this network as suggested by some peer models? It's more pragmatic, IMO, to think about a model where dynamic bandwidth provisioning between routers around an optical cloud is facilitated through limited exchange of routing information and standard signaling at the edge. Regards, Bala ===== Bala Rajagopalan 85 Ketcham Rd. Belle Mead, NJ 08502 Ph: +1-908-904-4302 Email: braja@yahoo.com __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-mpls@UU.NET Mon Mar 20 10:01:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08686 for ; Mon, 20 Mar 2000 10:01:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihiq20364; Mon, 20 Mar 2000 15:01:01 GMT Received: by mail-control.mail.uu.net id QQihiq26410 for mpls-outgoing; Mon, 20 Mar 2000 15:00:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihiq26037 for ; Mon, 20 Mar 2000 15:00:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihip10595 for ; Mon, 20 Mar 2000 09:59:48 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQihip02872 for ; Mon, 20 Mar 2000 14:59:48 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA17412 for ; Mon, 20 Mar 2000 07:25:59 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA15873 for mpls@uu.net; Mon, 20 Mar 2000 09:59:38 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihin23603 for ; Mon, 20 Mar 2000 14:18:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihin04929 for ; Mon, 20 Mar 2000 09:18:39 -0500 (EST) Received: from wayout.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [163.121.142.3]) id QQihin01492 for ; Mon, 20 Mar 2000 14:18:37 GMT Received: from ieee.org ([209.58.43.170]) by wayout.net (8.8.5/8.7.3) with ESMTP id QAA06578 for ; Mon, 20 Mar 2000 16:38:26 +0200 (EET) Message-ID: <38D63434.B2D5CEFA@ieee.org> Date: Mon, 20 Mar 2000 16:22:44 +0200 From: Khaled Elsayed X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Comments on draft-ip-optical-framework-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In draft-ip-optical-framework-00.txt, the following is quoted: > The network model considered in this draft consists of of IP routers > attached to an optical core network, and connected to their peers > over dynamically established switched optical paths. The optical core > itself is assumed to be incapable of processing individual IP packets. > The interaction between the IP routers and the optical core is over a > well-defined signaling and routing interface. and > It is not necessary to have a wavelength converter at every switching > element. A number of studies have attempted to address the issue of > the value of wavelength conversion in an optical network. Such studies > typically use the blocking probability (the probability that a > lightpath cannot be established because the requisite wavelengths > are not available) as a metric to adjudicate the effectiveness of > wavelength conversion. The IP over optical architecture must take > into account hybrid networks with some OXCs capable of wavelength > conversion and others incapable of this. I have a question/comment regarding blocking probability in the optical domain (in general, not specific to this draft). Is it foreseeable that in an all-optical network a connection from say point A to point B within the optical network will be subject to blocking?? I am speaking about connections at OC-48 and OC-192 speeds which are likely to be backbone connections and aggregation of traffic from various routers or ingress points. Is it practical to consider blocking as a possible event in such very high speeds? Maybe connections can be blocked in the ingress points, but those provisioned connections in the core are usually ON all the time. (Similar to most carrier backbone networks today?) Also, many studies have considered dynamic traffic models and subsequently made all these wonderful calculations/simulation for blocking probability. Is dynamic traffic and dynamic optical path a suitable model for an all-optical network? I can foresee a traffic matrix that will take weeks or months to change in the backbone, and such traffic should be handled well in advance with proper Traffic Engineering. So, what does dynamic traffic and dynamic path mean in such contexts? Thanks, Khaled Elsayed From owner-mpls@UU.NET Mon Mar 20 10:17:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15776 for ; Mon, 20 Mar 2000 10:17:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihir14693; Mon, 20 Mar 2000 15:16:57 GMT Received: by mail-control.mail.uu.net id QQihir04741 for mpls-outgoing; Mon, 20 Mar 2000 15:16:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihir04726 for ; Mon, 20 Mar 2000 15:16:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihir21652 for ; Mon, 20 Mar 2000 10:15:58 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQihir13930 for ; Mon, 20 Mar 2000 15:15:57 GMT Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 15:15:47 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1404D3@monk.datcon.co.uk> From: Adrian Farrel To: "Thomas D. Nadeau" , mpls@UU.NET Cc: arun@force10networks.com, cheenu@tachion.com Subject: RE: draft-ietf-mpls-lsr-mib-02.txt nits Date: Mon, 20 Mar 2000 15:15:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tom, >> 1. LSPID >> >> In previous mail exchanges I asked why the LSPID Textual >> Convention needed to allow 63 bytes. You answered that >> this was to allow space for IPv6 addresses. >> >> There are three points here. >> - Why would you put an address in the LSPID? The address >> is a separate part of the cookie >> - IPv6 addresses don't need 63 bytes >> - The current protocols only allow exchange of a 2 byte >> LSPID. > I believe that we were looking to be flexible enough to >accommodate any possible label. All of the implementations I >know of use much shorter labels. However, we did not wish to >preclude any longer ones. The MPLS framework does not specify a >size, it just states that, "A label is a short, fixed length, >locally significant identifier which is used to identify a FEC." >Depending on what you define as "short", you could have 1 byte, >or 64 bytes, but probably closer to the lower number. We have >not heard from anyone else pro/con on the size which we had >chosen, so we left it as is. The LSPID is not the label. I don't think the framework mentions LSPID at all. This is something in the protocols where 2 bytes is the currently defined maximum. I don't suppose this is a big issue - just pushing you to try to understand why 63 bytes. >> 2. Performance Tables Discontinuity Timestamps >> >> We discussed this at some length before, but left the issue >> when I ran out of bandwidth. >> >> I was asking for a discontinuity timer for each performance >> table so that it is possible to understand the scope of the >> reported values. You responded that the discontinuity timer >> in the interfaceTable provides sufficient information. >> >> This may be the case for the mplsInterfacePerfTable but I >> don't see how this applies to mplsInSegmentPerfTable and >> mplsOutSegmentPerfTable. Perhaps you could explain, or >> reconsider adding these timestamps. > > There is such a discontinuity timer available from the >ifTable which can be used for all tables related to an >MPLS interface. And that discontinuity timer will clearly only apply at the level of the entire interface. How do I tell when the counters for a segment have been reset? >>3. DiffServ >> >> I believe the question of storing DiffServ information was >> raised on the list recently. Do you have plans to add such >> information to the LSR MIB? > If you are referring to the EXP Bits discussion, >I think that we are currently of the position that they >should be left as is in the MIB. I am referring to the EXP bits and the signaling extensions to support draft-ietf-mpls-diff-ext-04. This draft is on the verge of last call and it is entirely appropriate that support be added to the TE MIB and LSR MIB. By left "as is" I take it that you mean "not supported". Please be aware that if you don't add this support, implementers will either add their own extensions (breaking compatibility) or will be forced through the pain of a new draft to extend yours. Is it so much pain to add this support? I have already provided ASN.1 for the TE MIB. Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Mon Mar 20 10:27:45 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19543 for ; Mon, 20 Mar 2000 10:27:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihir17000; Mon, 20 Mar 2000 15:27:05 GMT Received: by mail-control.mail.uu.net id QQihir05309 for mpls-outgoing; Mon, 20 Mar 2000 15:26:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihir05287 for ; Mon, 20 Mar 2000 15:26:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihir14829 for ; Mon, 20 Mar 2000 10:26:13 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihir21027 for ; Mon, 20 Mar 2000 15:26:12 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA14337 for mpls@uu.net; Mon, 20 Mar 2000 10:26:12 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihir05181 for ; Mon, 20 Mar 2000 15:25:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihir23112 for ; Mon, 20 Mar 2000 10:25:30 -0500 (EST) Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQihir15586 for ; Mon, 20 Mar 2000 15:25:29 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id B8DB5171; Mon, 20 Mar 2000 16:25:28 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp6.cisco.com [144.254.60.28]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA19128; Mon, 20 Mar 2000 16:25:26 +0100 (MET) Message-Id: <200003201525.QAA19128@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 20 Mar 2000 16:22:49 +0100 To: "Nakarmi,U,Utthan,NZD9 R" From: Francois Le Faucheur Subject: Re: MPLS support of Diff-Serv( OA and PSC) Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Utthan, OA and PSC are now generic (ie non-MPLS-specific) concepts defined by the Diff-SErv working group. See draft-ietf-diffserv-new-terms-02.txt for definition. They are useful for MPLS, but they are also useful in other environments (eg ATM Forum work on Diff-SErv support). AF11 is an example of PHB, AF12 is another PHB. AF13 is another PHB. The AF1x Class (which is a set of three PHBs comprising AF11, AF12 and AF13) is an example of PSC. See draft-ietf-mpls-diff-ext-04.txt for details of how OA and PSC relate to E-LSPs and L-LSPs. Hope this helps Francois At 11:26 20/03/2000 +0000, Nakarmi,U,Utthan,NZD9 R wrote: > >Dear all, >I will be grateful if someone can clarify the term OA(ordered aggregate) and >PSC(PHB Scheduling class) with some good and clear examples. These terms are >taken from MPLS support of Diff-serv and definations in it just won't get >into my head. With this draft paper I am also begining to get confused with >BA and PHB. Please do also inform me how this terms are related with E-LSP >and L-LSP. >cheers >utthan > _________________________________________________________________ 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: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Mon Mar 20 10:51:29 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27963 for ; Mon, 20 Mar 2000 10:51:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihit06086; Mon, 20 Mar 2000 15:51:19 GMT Received: by mail-control.mail.uu.net id QQihit06720 for mpls-outgoing; Mon, 20 Mar 2000 15:50:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihit06715 for ; Mon, 20 Mar 2000 15:50:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihit18990 for ; Mon, 20 Mar 2000 10:50:29 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQihit10985 for ; Mon, 20 Mar 2000 15:50:29 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 20 Mar 2000 09:42:38 -0600 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HGK87R71; Mon, 20 Mar 2000 10:42:19 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GWMNT6T2; Mon, 20 Mar 2000 10:42:18 -0500 Message-ID: <38D646D9.FEBDCA86@americasm01.nt.com> Date: Mon, 20 Mar 2000 10:42:17 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: Khaled Elsayed CC: mpls@UU.NET Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <38D63434.B2D5CEFA@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > I have a question/comment regarding blocking probability in the > optical domain (in general, not specific to this draft). Is it > foreseeable that in an all-optical network a connection from say > point A to point B within the optical network will be subject to > blocking?? I am speaking about connections at OC-48 and OC-192 > speeds which are likely to be backbone connections and > aggregation of traffic from various routers or ingress points. Is > it practical to consider blocking as a possible event in such > very high speeds? Maybe connections can be blocked in the ingress > points, but those provisioned connections in the core are usually > ON all the time. (Similar to most carrier backbone networks > today?) You may waste enormous amounts of bandwidth if you cannot do wavelength conversion. Convert the question to the ATM domain and imagine how an ATM network would operate if you had to use the same VCC from end to end. Basically, if you do not have the ability to change "labels" then you need one label for EVERY unique path through the network. Given that the number of paths through a network grows what .. N factorial? You run out of labels very quickly. This is especially true with DWDM equipement which may only support 50-100 "labels". This means that a tiny network would exhaust all the labels/paths AND you have many links that you can only use a small percentage of the available "labels" ie bandwidth. So its a very unsatisfactory solution. Also, to do a good job of it, you need a global view of each path and label it will use. The flip side is full blown wavelength conversion at every hop. This makes the routing/signalling problem much simpler since you only have to know if A label is free, not which one. This is the same as knowing that bandwidth is free so all our exisiting ATM/MPLS-TE style traffic engineering solutions can compute routes. Ideally though you want to do wavelength conversion only where you have to .. to "skip" past a link that is using the wavelength you want. In this manner you can reduce the distortions created by the conversions. This is kind of a hybrid approach that the signalling protocols can take into account by trying where possible to reuse the same "label". Anyway, just because bandwidth is "huge" by todays standards and "up times" are long, does not change the fundamental problem of blocking of paths. Remember, long "up times" means looooong blocking times and "huge" bandwidth means long blocking times with huge amounts of bandwidth that are unusable. Not a pretty picture. > Also, many studies have considered dynamic traffic models and > subsequently made all these wonderful calculations/simulation for > blocking probability. Is dynamic traffic and dynamic optical path > a suitable model for an all-optical network? I can foresee a > traffic matrix that will take weeks or months to change in the > backbone, and such traffic should be handled well in advance with > proper Traffic Engineering. So, what does dynamic traffic and > dynamic path mean in such contexts? Optical networks do not introduce anything all that new with respect to traffic flows. The key points are that the bandwidth is no longer statistically usable accross all the wavelengths and there is of course no QOS ... all photons are created equal .. at least as far as we know ;) These aspects of optical networking make statistical multiplexing and different per hop behaviours impossible and in many ways simplify the engineering job in the core of the network. Actually in many ways its back to the behaviour of the TDM circuit switched devices ... i.e. everybody is equal and everybody gets the same chunk of bandwidth ... just a MUCH bigger slice. Anyway, I know I'm not answering your question, more rambling around the edge of it .... Cheers, Peter From owner-mpls@UU.NET Mon Mar 20 10:58:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00225 for ; Mon, 20 Mar 2000 10:58:56 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihit18789; Mon, 20 Mar 2000 15:58:40 GMT Received: by mail-control.mail.uu.net id QQihit07097 for mpls-outgoing; Mon, 20 Mar 2000 15:58:08 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihit07092 for ; Mon, 20 Mar 2000 15:58:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihit20128 for ; Mon, 20 Mar 2000 10:57:06 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQihit17204 for ; Mon, 20 Mar 2000 15:57:06 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Mon, 20 Mar 2000 10:56:53 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CF53@email.quarrytech.com> From: "Abes, Andi" To: mpls@UU.NET Cc: lberger@labn.net, dhg@juniper.net, tony1@home.net, vijay@torrentnet.com, swallow@cisco.com Subject: Merging permitted in RSVP-05 Date: Mon, 20 Mar 2000 10:56:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk In section 4.7 of rsvp-tunnel-05 0x02 Merging permitted This flag permits transit routers to merge this session with other RSVP sessions for the purpose of reducing resource overhead on downstream transit routers, thereby providing better network scalability. Later in that section: The support of merging is OPTIONAL. A node may recognize the Merge Flag but may be unable to perform the requested operation. In this case, the node SHOULD pass the information downstream unchanged. These are the only 2 mentioning of this "session merge". What merge are we talking about ? How are the processing rules effected by the setting of the flag ? TIA, Andi. From owner-mpls@UU.NET Mon Mar 20 11:00:18 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00871 for ; Mon, 20 Mar 2000 11:00:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihiu12031; Mon, 20 Mar 2000 16:00:08 GMT Received: by mail-control.mail.uu.net id QQihit07133 for mpls-outgoing; Mon, 20 Mar 2000 15:59:28 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihit07128 for ; Mon, 20 Mar 2000 15:59:24 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihit28272 for ; Mon, 20 Mar 2000 10:59:13 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQihit11175 for ; Mon, 20 Mar 2000 15:59:13 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Mon, 20 Mar 2000 10:57:48 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HAZSQGYW; Mon, 20 Mar 2000 10:57:46 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GWMNT6XK; Mon, 20 Mar 2000 10:57:46 -0500 Message-ID: <38D64A7A.CBF580AC@americasm01.nt.com> Date: Mon, 20 Mar 2000 10:57:46 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Optical IP activities References: <03E3E0690542D211A1490000F80836F4029F9765@zcard00f.ca.nortel.com> <38D645B4.26A9BCD9@tellium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > The only > > justification I can think of would be for optical switching > > technology that is still so fragile that it cannot be dynamically > > controlled.... > > I am not sure if I agree with this "fragility" argument. Different > physical > layers have different constraints and they may be inherent and > permanent. For example: If we have to adjust amplifier gain as a function of the set of wavelengths traversing that amplifier or we have to adjust gain for some other reason that is affected by the end to end establishment of new optical trails then we have a problem controlling this dynamically. Currently the amplifiers are hand placed and hand tuned. If we have to dynamically control the gain then you need a control path to the amplifier. In this case, overlay or not, its not really suitable for dynamic path establishment. If this is the case then you have to be a bit less ambitious and either drop the speed, space the wavlenghts out a bit, or up the power levels at the edges if you want generic dynamic routing/switching to be able to control it. > > What would be extremely useful would be a taxonomy of the > > different constraints, what algorithms are known to deal with > > them, what's the cost of relaxing the constraint etc. Any > > volunteers? Any good references? > > I agree! I can give it a shot, but I need help/input from people in the > list. Count me in. Perhaps we can suggest this at the optical BOF. I think many of us have a rough idea what some of the constraints are but where they stand "today" and are likely to stand in a few years time is hard to get a handle on and affects how/what we decide to signal and to constrain against. Cheers, Peter From owner-mpls@UU.NET Mon Mar 20 11:16:01 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08809 for ; Mon, 20 Mar 2000 11:16:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihiv21437; Mon, 20 Mar 2000 16:15:09 GMT Received: by mail-control.mail.uu.net id QQihiu16375 for mpls-outgoing; Mon, 20 Mar 2000 16:14:36 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihiu16370 for ; Mon, 20 Mar 2000 16:14:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihiu22999 for ; Mon, 20 Mar 2000 11:13:38 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQihiu03203 for ; Mon, 20 Mar 2000 16:13:37 GMT Received: from mjork-pc (mjork-pc.avici.com [10.1.2.168]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id LAA29791; Mon, 20 Mar 2000 11:12:58 -0500 (EST) Received: by localhost with Microsoft MAPI; Mon, 20 Mar 2000 11:12:59 -0500 Message-ID: <01BF925D.3FE04760.mjork@avici.com> From: Markus Jork To: "'Adrian Farrel'" , "rsvp@ISI.EDU" , "mpls@UU.NET" Subject: RE: Sender TSpec on PathTear Date: Mon, 20 Mar 2000 11:12:58 -0500 Organization: Avici X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Adrian, On Monday, March 20, 2000 7:32 AM, Adrian Farrel wrote: > All, > > RFC 2205 states that Sender TSpec is mandatory on a PathTear > if a Sender Descriptor is included. > > ::= [ ] > > [ ] > > ::= (see earlier definition) > > Where the earlier definition of sender Descriptor is found in > the definition of Path Message and is... > > ::= > [ ] > > > draft-ietf-mpls-rsvp-lsp-tunnel-05 does not make any change to > this requirement, but does add [RECORD_ROUTE] as an optional > field in Sender Descriptor. > > It seems to me that SENDER_TSPEC, ADSPEC and RECORD_ROUTE do > not add anything to PathTear. Note that you cannot have a RECORD_ROUTE object in a PathTear message. draft-ietf-mpls-rsvp-lsp-tunnel-05 does say that RECORD_ROUTE is an optional part of a Sender Descriptor. But it also states that a RECORD_ROUTE object may only be present in Path or Resv messages (at the beginning of section 3 in the draft). > Can anyone comment on whether or not it would be better to > define PathTear as > > ::= [ ] > > [] > I also don't see a use for the tspec object (or adspec) in a PathTear message. But it won't do any harm, either. If RFC 2205 ever gets updated, this is something to keep in mind. But for now we are just stuck with it, I guess. And while we are on the topic of message formats: there seems to be a minor inconsistency between RFC 2205 and draft-ietf-mpls-rsvp-lsp-tunnel-05. My interpretation of RFC 2205 is that duplicate objects (e.g. two SESSION objects) in a single message are to be treated as an error which in turn means such messages should/could be discarded. This is not spelled out directly but it's my reading of the spec. On the other hand, the new objects introduced for MPLS have some explicit language that says: this object should appear only once, but if not just look at the first occurence and ignore the others. Not a big deal but it makes you wonder why to introduce these subtleties that a parser needs to deal with. Markus From owner-mpls@UU.NET Mon Mar 20 11:21:11 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11152 for ; Mon, 20 Mar 2000 11:21:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihiv24838; Mon, 20 Mar 2000 16:20:11 GMT Received: by mail-control.mail.uu.net id QQihiv16819 for mpls-outgoing; Mon, 20 Mar 2000 16:19:36 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihiv16814 for ; Mon, 20 Mar 2000 16:19:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihiv23838 for ; Mon, 20 Mar 2000 11:19:12 -0500 (EST) Received: from smtp10.atl.mindspring.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp10.atl.mindspring.net [207.69.200.246]) id QQihiv24103 for ; Mon, 20 Mar 2000 16:19:12 GMT Received: from jluciani (ip57.cambridge2.ma.pub-ip.psi.net [38.32.112.57]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA03616; Mon, 20 Mar 2000 11:19:08 -0500 (EST) Message-ID: <007201bf9288$0489a3c0$6b44fea9@jluciani> Reply-To: "James V. Luciani" From: "James V. Luciani" To: "Peter Ashwood-Smith" , Cc: , "Andrew G. Malis" References: <03E3E0690542D211A1490000F80836F4029F9765@zcard00f.ca.nortel.com> <38D645B4.26A9BCD9@tellium.com> <38D64A7A.CBF580AC@americasm01.nt.com> Subject: Re: Optical IP activities Date: Mon, 20 Mar 2000 11:19:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Peter, Hope you do not mind me cc'ing the ip-optical list on this. Good suggestion. I think this is an excellent work item for ip-optical if it were to become a WG. Not to mention a service to folks who are actually developing this stuff. > > > What would be extremely useful would be a taxonomy of the > > > different constraints, what algorithms are known to deal with > > > them, what's the cost of relaxing the constraint etc. Any > > > volunteers? Any good references? > > > > I agree! I can give it a shot, but I need help/input from people in the > > list. > > Count me in. Perhaps we can suggest this at the optical BOF. I think many of > us have a rough idea what some of the constraints are but where they stand "today" > and are likely to stand in a few years time is hard to get a handle on and > affects how/what we decide to signal and to constrain against. --jim From owner-mpls@UU.NET Mon Mar 20 11:31:05 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15074 for ; Mon, 20 Mar 2000 11:31:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihiw01853; Mon, 20 Mar 2000 16:30:11 GMT Received: by mail-control.mail.uu.net id QQihiv18489 for mpls-outgoing; Mon, 20 Mar 2000 16:29:36 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihiv18477 for ; Mon, 20 Mar 2000 16:29:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihiv25046 for ; Mon, 20 Mar 2000 11:27:19 -0500 (EST) Received: from smtp10.atl.mindspring.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp10.atl.mindspring.net [207.69.200.246]) id QQihiv16560 for ; Mon, 20 Mar 2000 16:27:19 GMT Received: from jluciani (ip57.cambridge2.ma.pub-ip.psi.net [38.32.112.57]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA27988; Mon, 20 Mar 2000 11:27:16 -0500 (EST) Message-ID: <008c01bf9289$27487ca0$6b44fea9@jluciani> Reply-To: "James V. Luciani" From: "James V. Luciani" To: "Peter Ashwood-Smith" , Cc: Subject: Re: Optical IP activities Date: Mon, 20 Mar 2000 11:27:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ter, Hope you do not mind me cc'ing the ip-optical list on this. Good suggestion. I think this is an excellent work item for ip-optical if it were to become a WG. Not to mention a service to folks who are actually developing this stuff. > > > What would be extremely useful would be a taxonomy of the > > > different constraints, what algorithms are known to deal with > > > them, what's the cost of relaxing the constraint etc. Any > > > volunteers? Any good references? > > > > I agree! I can give it a shot, but I need help/input from people in the > > list. > > Count me in. Perhaps we can suggest this at the optical BOF. I think many of > us have a rough idea what some of the constraints are but where they stand "today" > and are likely to stand in a few years time is hard to get a handle on and > affects how/what we decide to signal and to constrain against. --jim From owner-mpls@UU.NET Mon Mar 20 11:34:02 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16411 for ; Mon, 20 Mar 2000 11:34:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihiw22223; Mon, 20 Mar 2000 16:33:18 GMT Received: by mail-control.mail.uu.net id QQihiw18714 for mpls-outgoing; Mon, 20 Mar 2000 16:32:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihiw18709 for ; Mon, 20 Mar 2000 16:32:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihiw25703 for ; Mon, 20 Mar 2000 11:31:11 -0500 (EST) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQihiw02721 for ; Mon, 20 Mar 2000 16:31:10 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA27687 for ; Mon, 20 Mar 2000 08:31:08 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA16267 for mpls@uu.net; Mon, 20 Mar 2000 11:31:08 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihiv18434 for ; Mon, 20 Mar 2000 16:28:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihiv03083 for ; Mon, 20 Mar 2000 11:28:02 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQihiv00067 for ; Mon, 20 Mar 2000 16:28:02 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Mar 20 11:27:26 EST 2000 Received: from dnrc.bell-labs.com (pingpanpc [135.180.130.92]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA27437; Mon, 20 Mar 2000 11:27:24 -0500 (EST) Message-ID: <38D650FE.F4F2EE74@dnrc.bell-labs.com> Date: Mon, 20 Mar 2000 11:25:34 -0500 From: Ping Pan Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Markus Jork CC: "'Adrian Farrel'" , "rsvp@ISI.EDU" , "mpls@UU.NET" Subject: Re: Sender TSpec on PathTear References: <01BF925D.3FE04760.mjork@avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Markus Jork wrote: > > > It seems to me that SENDER_TSPEC, ADSPEC and RECORD_ROUTE do > > not add anything to PathTear. > > ... > > Can anyone comment on whether or not it would be better to > > define PathTear as > > > > ::= [ ] > > > > [] > > > > I also don't see a use for the tspec object (or adspec) in a PathTear > message. But it won't do any harm, either. If RFC 2205 ever gets > updated, this is something to keep in mind. But for now we are just > stuck with it, I guess. > I don't think that tspec is harmful. Actually, tspec may be useful in case of merged reservations (SE and WF). In some implementation, if the routers only keep the final merged bandwidth allocation, then they'd better rely on the tspec in PATHTEAR to update their resources after teardown. - Ping From owner-mpls@UU.NET Mon Mar 20 12:59:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18929 for ; Mon, 20 Mar 2000 12:59:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihjb28450; Mon, 20 Mar 2000 17:59:27 GMT Received: by mail-control.mail.uu.net id QQihjb09369 for mpls-outgoing; Mon, 20 Mar 2000 17:59:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihjb09364 for ; Mon, 20 Mar 2000 17:58:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihjb15866 for ; Mon, 20 Mar 2000 12:58:50 -0500 (EST) Received: from blsmsgims02.bls.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: iocfirewall2ext.bls.com [139.76.64.4]) id QQihjb03404 for ; Mon, 20 Mar 2000 17:58:50 GMT Received: from SMTP (blsmsgims02.bls.com [139.76.86.32]) by blsmsgims02.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HGH99KHN; Mon, 20 Mar 2000 12:58:50 -0500 Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 20 Mar 2000 17:58:50 0000 (GMT) Received: from gf5142_gxsmlg (g0214070 [90.30.214.70]) by snt.bellsouth.com (8.9.1b+Sun/8.9.1) with SMTP id MAA23063; Mon, 20 Mar 2000 12:58:38 -0500 (EST) From: "Steven Wright" To: "'Andrew Smith'" , "'rap (E-mail)'" , "'Diffserv (E-mail)'" , Subject: RE: DiffServ policy-related work Date: Mon, 20 Mar 2000 12:57:52 -0500 Message-ID: <001801bf9295$d0fac120$46d61e5a@gf5142_gxsmlg.bst.bls.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC68D@SOL> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit You may also be interested in: draft-wright-policy-mpls-00.txt which seeks to start aligned policy work in the MPLS context. A presentation slot has been requested for the MPLS WG in Adelaide. > -----Original Message----- > From: owner-rap@majordomo.iphighway.com > [mailto:owner-rap@majordomo.iphighway.com]On Behalf Of Andrew Smith > Sent: Friday, March 17, 2000 2:49 PM > To: rap (E-mail); Diffserv (E-mail) > Subject: DiffServ policy-related work > > > > You may be interested in the following summary of current > Internet Drafts > related to DiffServ policy management, configuration and > monitoring that is > proceeding in assorted IETF WGs: > > DiffServ WG: > > "A Conceptual Model for Diffserv Routers" > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-02.txt > "Management Information Base for the Differentiated Services > Architecture" > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-02.txt > "Differentiated Services Quality of Service Policy Information Base" > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-00.txt > > Policy WG: > > "QoS Policy Framework Information Model" > http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info -model-00.txt "QoS Policy Schema" http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-schema-00.txt Snmpconf WG: "The DiffServ Policy MIB" http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-00.txt RMON WG: Remote Monitoring MIB Extensions for Differentiated Services Enabled Networks http://www.ietf.org/internet-drafts/draft-bierman-dsmon-mib-02.txt Andrew Smith RAP WG co-chair From owner-mpls@UU.NET Mon Mar 20 13:55:57 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12475 for ; Mon, 20 Mar 2000 13:55:57 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihjf01944; Mon, 20 Mar 2000 18:55:24 GMT Received: by mail-control.mail.uu.net id QQihjf21078 for mpls-outgoing; Mon, 20 Mar 2000 18:54:58 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihjf21073 for ; Mon, 20 Mar 2000 18:54:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihjf23310 for ; Mon, 20 Mar 2000 13:54:42 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQihjf21923 for ; Mon, 20 Mar 2000 18:54:42 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Mon, 20 Mar 2000 13:53:13 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HKFVYN0P; Mon, 20 Mar 2000 13:53:12 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GWMNT7Y4; Mon, 20 Mar 2000 13:53:07 -0500 Message-ID: <38D67393.823FE250@americasm01.nt.com> Date: Mon, 20 Mar 2000 13:53:07 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls@UU.NET, mpls@UU.NET Subject: Re: Merging permitted in RSVP-05 References: <496A8683261CD211BF6C0008C733261A48CF53@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Abes, Andi wrote: > > In section 4.7 of rsvp-tunnel-05 > > 0x02 Merging permitted > > This flag permits transit routers to merge this session > with other RSVP sessions for the purpose of reducing > resource overhead on downstream transit routers, thereby > providing better network scalability. > > Later in that section: > > The support of merging is OPTIONAL. A node may recognize the Merge > Flag but may be unable to perform the requested operation. In this > case, the node SHOULD pass the information downstream unchanged. > > These are the only 2 mentioning of this "session merge". > > What merge are we talking about ? > How are the processing rules effected by the setting of the flag ? > > TIA, > Andi. I think this bit also had implications in one of the RSVP fast reroute drafts can't remember the details right now... Cheers, Peter From owner-mpls@UU.NET Mon Mar 20 14:25:23 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24480 for ; Mon, 20 Mar 2000 14:25:23 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihjh19240; Mon, 20 Mar 2000 19:24:51 GMT Received: by mail-control.mail.uu.net id QQihjh01153 for mpls-outgoing; Mon, 20 Mar 2000 19:24:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihjh01136 for ; Mon, 20 Mar 2000 19:24:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihjh27623 for ; Mon, 20 Mar 2000 14:24:07 -0500 (EST) Received: from mail-green.research.att.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQihjh19129 for ; Mon, 20 Mar 2000 19:24:06 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id A33D01E018; Mon, 20 Mar 2000 14:24:06 -0500 (EST) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id OAA06891; Mon, 20 Mar 2000 14:24:01 -0500 (EST) Reply-To: From: "John Strand" To: "'John Drake'" Cc: Subject: RE: Optical IP activities Date: Mon, 20 Mar 2000 14:23:51 -0500 Message-ID: <018901bf92a1$d3901b90$3e82cf87@pcstranded.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA24480 I checked with several people who actually attended the OIF meeting and they confirmed John Drake's statement of OIF priorities. John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: John Drake [mailto:jdrake@chromisys.com] Sent: Thursday, March 16, 2000 4:46 PM To: 'jls@research.att.com'; John Drake Cc: mpls@UU.NET Subject: RE: Optical IP activities John, I was at the meeting and I think that my statement stands. Their first priority is a UNI interface, and their definition of NNI is network to network. Thanks, John -----Original Message----- From: John Strand [mailto:jls@research.att.com] Sent: Thursday, March 16, 2000 11:56 AM To: 'John Drake' Cc: mpls@UU.NET Subject: RE: Optical IP activities John, Thanks for the Awduche reference which also supports expanding the MPLS charter to cover both overlay and peer models. Your statement about the OIF isn't completely up to date. At their most recent meeting they started a signalling WG to produce specifications for service discovery, lightpath attributes, transporting signaling information, and NNI. They identified this work as being "..closely related to work at IETF ... Technical documents will be exchanged as appropriate." John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: John Drake [mailto:jdrake@chromisys.com] Sent: Thursday, March 16, 2000 11:16 AM To: 'Yakov Rekhter'; jls@research.att.com Cc: 'CATANZARITI Sergio FTR&D/TI'; 'Chip Sharp'; mpls@UU.NET Subject: RE: Optical IP activities The Awduche draft, which provided the impetus for the MPL(ambda)S work, specificaly states that both the overlay model, as well as the peer model, will be supported. Further, neither the ODSI nor the OIF are currently working to define the control plane for a network of OXCs (or PXCs), so it doesn't seem as though there are overlapping activities. John From owner-mpls@UU.NET Mon Mar 20 15:52:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27306 for ; Mon, 20 Mar 2000 15:52:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihjn01473; Mon, 20 Mar 2000 20:50:46 GMT Received: by mail-control.mail.uu.net id QQihjn13732 for mpls-outgoing; Mon, 20 Mar 2000 20:50:19 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihjn13727 for ; Mon, 20 Mar 2000 20:50:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihjn09898 for ; Mon, 20 Mar 2000 15:50:03 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQihjn13990 for ; Mon, 20 Mar 2000 20:50:03 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Mar 20 15:49:45 EST 2000 Received: from dnrc.bell-labs.com (redbank [135.180.130.127]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA09257 for ; Mon, 20 Mar 2000 15:49:44 -0500 (EST) Message-ID: <38D68EE5.B50DD546@dnrc.bell-labs.com> Date: Mon, 20 Mar 2000 15:49:41 -0500 From: Zheng Wang Organization: Bell Labs Lucent Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: question on draft-ietf-mpls-label-encaps-07.txt References: <018901bf92a1$d3901b90$3e82cf87@pcstranded.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I dont know if someone has raised this question or not. The label value 3 is reserved for Implicit NULL Label. The draft says: iv. A value of 3 represents the "Implicit NULL Label". This is a label that an LSR may assign and distribute, but which never actually appears in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with a new label, but the new label is "Implicit NULL", the LSR will pop the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the Label Distribution Protocol, so a value is reserved. My question is which label is used to determine the next hop in this case, the imcoming label or the new top label after the popping of the stack? Thanks in advance Cheers Zheng From owner-mpls@UU.NET Mon Mar 20 16:25:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10692 for ; Mon, 20 Mar 2000 16:25:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihjp22764; Mon, 20 Mar 2000 21:24:53 GMT Received: by mail-control.mail.uu.net id QQihjp23602 for mpls-outgoing; Mon, 20 Mar 2000 21:24:39 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihjp23595 for ; Mon, 20 Mar 2000 21:24:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihjp06355 for ; Mon, 20 Mar 2000 16:24:13 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihjp06812 for ; Mon, 20 Mar 2000 21:24:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA09629 for mpls@uu.net; Mon, 20 Mar 2000 16:24:10 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihjp23560 for ; Mon, 20 Mar 2000 21:23:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihjp06168 for ; Mon, 20 Mar 2000 16:23:16 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQihjp06014 for ; Mon, 20 Mar 2000 21:23:15 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA19754; Mon, 20 Mar 2000 16:22:57 -0500 (EST) Message-Id: <4.2.2.20000320160604.04349320@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 20 Mar 2000 16:11:57 -0500 To: Adrian Farrel , mpls@UU.NET From: "Thomas D. Nadeau" Subject: RE: draft-ietf-mpls-lsr-mib-02.txt nits Cc: arun@force10networks.com, cheenu@tachion.com In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E1404D3@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8194724==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_8194724==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Adrian, My comments are in blue. > >> 1. LSPID > >> > >> In previous mail exchanges I asked why the LSPID Textual > >> Convention needed to allow 63 bytes. You answered that > >> this was to allow space for IPv6 addresses. > >> [snip] >The LSPID is not the label. >I don't think the framework mentions LSPID at all. This is >something in the protocols where 2 bytes is the currently defined >maximum. >I don't suppose this is a big issue - just pushing you to try to >understand why 63 bytes. Agreed. We will make it 4 bytes. > >> 2. Performance Tables Discontinuity Timestamps > >> > >> We discussed this at some length before, but left the issue > >> when I ran out of bandwidth. > >> > >> I was asking for a discontinuity timer for each performance > >> table so that it is possible to understand the scope of the > >> reported values. You responded that the discontinuity timer > >> in the interfaceTable provides sufficient information. > >> > >> This may be the case for the mplsInterfacePerfTable but I > >> don't see how this applies to mplsInSegmentPerfTable and > >> mplsOutSegmentPerfTable. Perhaps you could explain, or > >> reconsider adding these timestamps. > > > > There is such a discontinuity timer available from the > >ifTable which can be used for all tables related to an > >MPLS interface. > >And that discontinuity timer will clearly only apply at the level >of the entire interface. How do I tell when the counters for a >segment have been reset? Agreed. We will add a discontinuity timer to the different tables. > >>3. DiffServ > >> > >> I believe the question of storing DiffServ information was > >> raised on the list recently. Do you have plans to add such > >> information to the LSR MIB? > > > If you are referring to the EXP Bits discussion, > >I think that we are currently of the position that they > >should be left as is in the MIB. > >I am referring to the EXP bits and the signaling extensions to >support draft-ietf-mpls-diff-ext-04. This draft is on the verge of >last call and it is entirely appropriate that support be added to the >TE MIB and LSR MIB. > >By left "as is" I take it that you mean "not supported". > >Please be aware that if you don't add this support, implementers >will either add their own extensions (breaking compatibility) or >will be forced through the pain of a new draft to extend yours. >Is it so much pain to add this support? I have already provided >ASN.1 for the TE MIB. We cannot reference it due to the fact that it is not in last call right now. We have asked for last call on our document at this point, which would stall this process. Besides, this change can be added in a later revision of the MIB. As Arun mentioned last week, the currently incarnation of the MIB is nearly 2 years old at this point and needs to be advanced. We feel that if we wait for everything to get in, then it will never be finished. --Tom (Arun and Cheenu) >Adrian >-- >Adrian Farrel mailto:af@datcon.co.uk >Network Convergence Group >Data Connection Ltd., Chester, UK >http://www.datcon.co.uk/ >Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 --=====================_8194724==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi Adrian,

        My comments are in blue.

>> 1. LSPID
>>  
>>   In previous mail exchanges I asked why the LSPID Textual
>>   Convention needed to allow 63 bytes.  You answered that
>>   this was to allow space for IPv6 addresses.
>>
[snip]
The LSPID is not the label.
I  don't  think the framework mentions LSPID at all.  This is
something in the protocols where 2 bytes is the currently defined
maximum. 
I don't suppose this is a big issue - just pushing you to try to
understand why 63 bytes.

        Agreed. We will make it 4 bytes.

>> 2. Performance Tables Discontinuity Timestamps
>>  
>>   We discussed this at some length before, but left the issue
>>   when I ran out of bandwidth.
>>  
>>   I was asking for a discontinuity timer for each performance
>>   table so that it is possible to understand the scope of the
>>   reported values.  You responded that the discontinuity timer
>>   in the interfaceTable provides sufficient information.
>>  
>>   This may be the case for the mplsInterfacePerfTable but I
>>   don't see how this applies to mplsInSegmentPerfTable and
>>   mplsOutSegmentPerfTable.  Perhaps you could explain, or
>>   reconsider adding these timestamps.
>
>   There is such a discontinuity timer available from the
>ifTable which can be used for all tables related to an
>MPLS interface.

And that discontinuity timer will clearly only apply at the level
of the entire interface.  How do I tell when the counters for a
segment have been reset?

        Agreed. We will add a discontinuity timer to the
different tables.

>>3. DiffServ
>>  
>>   I believe the question of storing DiffServ information was
>>   raised on the list recently.  Do you have plans to add such
>>   information to the LSR MIB?

>     If you are referring to the EXP Bits discussion,
>I think that we are currently of the position that they
>should be left as is in the MIB.

I am referring to the EXP bits and the signaling extensions to
support draft-ietf-mpls-diff-ext-04.  This draft is on the verge of
last call and it is entirely appropriate that support be added to the
TE MIB and LSR MIB.

By left "as is" I take it that you mean "not supported".

Please be aware that if you don't add this support, implementers
will either add their own extensions (breaking compatibility) or
will be forced through the pain of a new draft to extend yours.
Is it so much pain to add this support? I have already provided
ASN.1 for the TE MIB.

        We cannot reference it due to the fact that it is not in
last call right now. We have asked for last call on our document
at this point, which would stall this process. Besides, this change
can be added in a later revision of the MIB. As Arun mentioned last
week, the currently incarnation of the MIB is nearly 2 years
old at this point and needs to be advanced. We feel that if we
wait for everything to get in, then it will never be finished.

        --Tom (Arun and Cheenu)




Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
--=====================_8194724==_.ALT-- From owner-mpls@UU.NET Mon Mar 20 16:43:08 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17083 for ; Mon, 20 Mar 2000 16:43:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihjq04046; Mon, 20 Mar 2000 21:42:37 GMT Received: by mail-control.mail.uu.net id QQihjq24594 for mpls-outgoing; Mon, 20 Mar 2000 21:42:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihjq24550 for ; Mon, 20 Mar 2000 21:42:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihjq08766 for ; Mon, 20 Mar 2000 16:41:57 -0500 (EST) Received: from mail10.vwh1.net by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [209.238.9.57]) id QQihjq03519 for ; Mon, 20 Mar 2000 21:41:57 GMT Received: from 208.55.74.250 (208.55.74.250) by mail10.vwh1.net (RS ver 1.0.53) with SMTP id 09262608; Mon, 20 Mar 2000 16:41:48 -0500 (EST) Message-Id: <3.0.6.32.20000320164430.00c3d240@photonex.com> X-Sender: jagan@photonex.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 20 Mar 2000 16:44:30 -0500 To: Khaled Elsayed , mpls@UU.NET From: Jagan Shantigram Subject: Re: Comments on draft-ip-optical-framework-00.txt Cc: ip-optical@lists.research.bell-labs.com In-Reply-To: <38D63434.B2D5CEFA@ieee.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop-Detect: 1 Sender: owner-mpls@UU.NET Precedence: bulk At 04:22 PM 3/20/00 +0200, Khaled Elsayed wrote: >In draft-ip-optical-framework-00.txt, the following is quoted: > >> The network model considered in this draft consists of of IP routers >> attached to an optical core network, and connected to their peers >> over dynamically established switched optical paths. The optical core >> itself is assumed to be incapable of processing individual IP packets. >> The interaction between the IP routers and the optical core is over a >> well-defined signaling and routing interface. > >and > >> It is not necessary to have a wavelength converter at every switching >> element. A number of studies have attempted to address the issue of >> the value of wavelength conversion in an optical network. Such studies >> typically use the blocking probability (the probability that a >> lightpath cannot be established because the requisite wavelengths >> are not available) as a metric to adjudicate the effectiveness of >> wavelength conversion. The IP over optical architecture must take >> into account hybrid networks with some OXCs capable of wavelength >> conversion and others incapable of this. > >I have a question/comment regarding blocking probability in the >optical domain (in general, not specific to this draft). Is it >foreseeable that in an all-optical network a connection from say >point A to point B within the optical network will be subject to >blocking?? I am speaking about connections at OC-48 and OC-192 >speeds which are likely to be backbone connections and >aggregation of traffic from various routers or ingress points. Is >it practical to consider blocking as a possible event in such >very high speeds? Maybe connections can be blocked in the ingress >points, but those provisioned connections in the core are usually >ON all the time. (Similar to most carrier backbone networks >today?) This is a good reality check question. While we do not forsee WDM networks to be as dynamic as ATM or even traffic engineered MPLS, it will probably have a topology that is subject to change by periods of day. This variation too, in the near to mid-term, should be a well studied and caliberated variance - in the sense that the provider will know what the three or four different traffic patterns are that need to be supported. In the long term, however, we do expect more dynamic nature to creep in to WDM provisioning which, along with lowering costs of devices, will make the conversion more and more compelling. When we have lambda conversion and given a set of traffic patterns that need to be supported, the number of wavelengths channels that have to be provisioned can be easily determined. Given the maximum channels needed on each link, the number of fibers and the wavelengths per fiber can be determined. Considering that we may have a good solution for routing the traffic we can efficiently use the fibers that are in the ground. When we do not have lambda conversion however, this problem cannot be solved optimally.. it is akin to the graph coloring problem - which ofcourse has heuristics that can get us to a factor (?) of the optimal solution. So, connections may be blocked even though there is capacity on the fiber to support it, just because the wavelength is already used up. > >Also, many studies have considered dynamic traffic models and >subsequently made all these wonderful calculations/simulation for >blocking probability. Is dynamic traffic and dynamic optical path >a suitable model for an all-optical network? I can foresee a >traffic matrix that will take weeks or months to change in the >backbone, and such traffic should be handled well in advance with >proper Traffic Engineering. So, what does dynamic traffic and >dynamic path mean in such contexts? I suspect this is a provisioning issue. Currently it is a nightmare to provision for the expanding needs of customers.. with advanced intelligent optical systems, fatter pipes can be provisioned as easy as ordering a pizza? I will however humbly defer to those who know more about the need for dynamic optical path setup and traffic mgmt. -jagan. > >Thanks, > >Khaled Elsayed > > > Shantigram Jagannath Photonex Corporation From owner-mpls@UU.NET Mon Mar 20 23:13:52 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11319 for ; Mon, 20 Mar 2000 23:13:47 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihkq04904; Tue, 21 Mar 2000 04:13:01 GMT Received: by mail-control.mail.uu.net id QQihkq11259 for mpls-outgoing; Tue, 21 Mar 2000 04:12:41 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihkq11250 for ; Tue, 21 Mar 2000 04:12:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihkq13729 for ; Mon, 20 Mar 2000 23:12:32 -0500 (EST) Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQihkq15398 for ; Tue, 21 Mar 2000 04:11:55 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 21 Mar 2000 09:50:44 +0530 Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id JAA14208; Tue, 21 Mar 2000 09:29:01 +0530 Received: by localhost with Microsoft MAPI; Tue, 21 Mar 2000 09:40:54 +0530 Message-Id: <01BF9319.8D4F1960.manis@future.futsoft.com> From: manikantan To: "'Zheng Wang'" , "mpls@uu.net" Subject: RE: question on draft-ietf-mpls-label-encaps-07.txt Date: Tue, 21 Mar 2000 09:40:53 +0530 Importance: high X-Priority: 1 (Highest) X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Zheng #I dont know if someone has raised this question or not. #The label value 3 is reserved for Implicit NULL Label. #The draft says: # # iv. A value of 3 represents the "Implicit NULL Label". # This is a label that an LSR may assign and distribute, # but which never actually appears in the encapsulation. # When an LSR would otherwise replace the label at the # top of the stack with a new label, but the new label is # "Implicit NULL", the LSR will pop the stack instead of # doing the replacement. Although this value may never # appear in the encapsulation, it needs to be specified # in the Label Distribution Protocol, so a value is # reserved. # #My question is which label is used to determine the next hop in this #case, the imcoming label or the new top label after the popping of the #stack? My understanding is that the first label in the received stack is to be used for forwarding decisions. I have a few examples below hope this will clarify your question. LSRC ----------- LSRA ---------- LSRB --- Router/Host. -------- ------ L1|DATA| --> |DATA| --> -------- ------ Fig 1 1) Let us assume LSRB ( Downstream Peer ) has assigned Implicit null for an FEC - F and indicated it to LSRA. When LSRA receives a labeled packet from LSRC (the packet belongs to FEC - F, and the label stack is of depth 1, i.e. only one label in the received packet) and forwards it to LSRB, in this case after pooping the label on the received packet, instead of pushing the implicit label, LSR A will not push any label, and the packet will be forwarded as an unlabeled packet. In this case the forwarding further at LSRB will be done as is done for a normal IP packet. LSRC --------------- LSRA ---------------- LSRB ---------- LSRD. -------------- ----------- L1|L2|L3|DATA| --> L2|L3|DATA| --> -------------- ----------- Fig 2 2) Let us assume LSRB ( Downstream Peer ) has assigned Implicit null for an FEC - F and indicated it to LSRA. When LSRA receives a labeled packet from LSRC (the packet belongs to FEC - F, and the label stack is of depth (> 1) - say n, i.e. more than one label in the received packet) and forwards it to LSRB, in this case after pooping the label on the received packet, instead of pushing the implicit label, LSR A will not push any label, and the packet will be forwarded with a label stack of depth n-1. In this case the forwarding further at LSRB will be done based on the top most label in the received packet. an unlabeled packet. As shown in Figure 2, the forwarding at B will be based on L2. regards mani P.S The figures will look good if the font type is set to courier 10. /*-------------------------------------------------------------------*/ S.Manikantan Future Software Private Limited 480-481, Anna salai, Nandanam, Chennai, Tamil Nadu, 600 035, India. Phone : +91-44-4330550 Fax : +91-44-4344157. Email : manis@future.futsoft.com http://www.futsoft.com /*--------------------------------------------------------------------*/ From owner-mpls@UU.NET Tue Mar 21 02:42:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10143 for ; Tue, 21 Mar 2000 02:42:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihle13769; Tue, 21 Mar 2000 07:42:00 GMT Received: by mail-control.mail.uu.net id QQihle14021 for mpls-outgoing; Tue, 21 Mar 2000 07:41:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihle14018 for ; Tue, 21 Mar 2000 07:41:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihle27652 for ; Tue, 21 Mar 2000 02:41:26 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihle04567 for ; Tue, 21 Mar 2000 07:41:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA25041 for mpls@uu.net; Tue, 21 Mar 2000 02:41:24 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihle13996 for ; Tue, 21 Mar 2000 07:41:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihle27603 for ; Tue, 21 Mar 2000 02:40:52 -0500 (EST) Received: from ficon-tech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [12.10.198.190]) id QQihle12488 for ; Tue, 21 Mar 2000 07:40:30 GMT Received: from ficon-tech.com (jkochar.india.ficon-tech.com [172.25.1.102]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id NAA22562; Tue, 21 Mar 2000 13:04:03 +0530 (IST) (envelope-from jkochar@ficon-tech.com) Message-ID: <38D725A6.2E00408E@ficon-tech.com> Date: Tue, 21 Mar 2000 13:02:55 +0530 From: Jhilmil Kochar Organization: Ficon Technology X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Hans =?iso-8859-1?Q?Sj=F6strand?= CC: "'mpls@uu.net'" , jcucchiara@brixnet.com Subject: Re: LDP MIB last call References: <38D0A77B.36844C5C@ficon-tech.com> <38D0E5FF.F3E82E14@etx.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Hans, > > > 2. mplsLdpEntityEntry: Some of the objects in this table should have a > > default value assigned as specified by LDP draft. Examples of such > > objects are mplsLdpEntityWellKnownDiscoveryPort, > > mplsLdpEntityMaxPduLength, mplsLdpEntityKeepAliveHoldtimer. > > Agree in principle. It however only DiscoveryPort that is specified > in other specs. > mplsLdpEntityWellKnownDiscoveryPort = 646 > > Max PDU lenth is really implementation specific. But I see no reason to > have any other default value than maximum? > > mplsLdpEntityMaxPduLength = 65535 ? LDP draft sec 3.1 "Prior to completion of the negotiation the maximum allowable length is 4096 bytes." and sec 3.5.3 "A value of 255 or less specifies the default maximum length of 4096 octets." Shouldn't the default value by 4096? > > regards Jhilmil -- ------------------------------ Jhilmil Kochar Ficon Technology E-mail:jkochar@ficon-tech.com Web: www.ficon-tech.com From owner-mpls@UU.NET Tue Mar 21 02:56:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15493 for ; Tue, 21 Mar 2000 02:56:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihlf14252; Tue, 21 Mar 2000 07:55:52 GMT Received: by mail-control.mail.uu.net id QQihlf14801 for mpls-outgoing; Tue, 21 Mar 2000 07:55:12 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihlf14796 for ; Tue, 21 Mar 2000 07:55:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihlf09637 for ; Tue, 21 Mar 2000 02:54:58 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihlf13514 for ; Tue, 21 Mar 2000 07:54:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA25827 for mpls@uu.net; Tue, 21 Mar 2000 02:54:57 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihlf14780 for ; Tue, 21 Mar 2000 07:54:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihlf09621 for ; Tue, 21 Mar 2000 02:54:26 -0500 (EST) Received: from ficon-tech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [12.10.198.190]) id QQihlf13038 for ; Tue, 21 Mar 2000 07:54:12 GMT Received: from ficon-tech.com (jkochar.india.ficon-tech.com [172.25.1.102]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id NAA23491; Tue, 21 Mar 2000 13:17:17 +0530 (IST) (envelope-from jkochar@ficon-tech.com) Message-ID: <38D728BE.A215C7E7@ficon-tech.com> Date: Tue, 21 Mar 2000 13:16:07 +0530 From: Jhilmil Kochar Organization: Ficon Technology X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Joan Cucchiara CC: "'Hans =?iso-8859-1?Q?Sj=F6strand=27?=" , "'mpls@uu.net'" Subject: Re: LDP MIB last call References: <07B0D4912B83D31188F300A0C9F62EBB15F86F@brixcorp2.brixnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Joan, > > > > 6. mplsLdpEntityPeerEntry: It is not clear why the entries > > in this table > > > should not be present in session table. As far as I can > > make out these > > > parameters and also the parameters in session table are > > passed in init > > > message between peers, hence the purpose for keeping them > > in separate > > > tables is not clear. One possible reasoning I could come up with was > > > that one gives peer information that is non-negotiable and > > other gives > > > peer information that is negotiated. But then this rule > > does not hold > > > true for all entries. Please clarify. > > The split between the two tables were for values used in > an active Session, versus values which were ignored by the > session (although a session is still created). > > The objects in the EntityPeer Table are related > to PathVectorLimit and are used to generate a trap if a > mismatch occurs. The Session uses the PathVector value which > is in the Entity Table if there is a mismatch between the > two values. > > We probably should add more text here then, if this is > not clear. More text would be helpful. Does this mean there there will always be a one-one mapping beween a Peer entry and a session entry? ie one LDP Peer can have only one session with the entity? The indexing for both is the same, but the draft does not explicitly mention this. Thanks and regards Jhilmil -- ------------------------------ Jhilmil Kochar Ficon Technology E-mail:jkochar@ficon-tech.com Web: www.ficon-tech.com From owner-mpls@UU.NET Tue Mar 21 05:05:41 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04069 for ; Tue, 21 Mar 2000 05:05:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihlo28176; Tue, 21 Mar 2000 10:04:36 GMT Received: by mail-control.mail.uu.net id QQihlo10094 for mpls-outgoing; Tue, 21 Mar 2000 10:04:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihlo10039 for ; Tue, 21 Mar 2000 10:04:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihlo19206 for ; Tue, 21 Mar 2000 05:03:59 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihlo27720 for ; Tue, 21 Mar 2000 10:03:58 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA01160 for mpls@uu.net; Tue, 21 Mar 2000 05:03:57 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihlo09436 for ; Tue, 21 Mar 2000 10:03:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihlo07216 for ; Tue, 21 Mar 2000 05:03:09 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQihlo12953 for ; Tue, 21 Mar 2000 10:03:08 GMT Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 10:02:57 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1404ED@monk.datcon.co.uk> From: Paul Brittain To: mpls@UU.NET Cc: Philip Matthews , Adrian Farrel , ewgray@mindspring.com Subject: LDP/CR-LDP Fault Tolerance - progress report Date: Tue, 21 Mar 2000 10:02:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk As you may have noticed, there have been two proposals submitted to the WG recently on the provision of Fault Tolerance for LDP and CR-LDP: - draft-farrel-mpls-ldp-ft-00.txt - draft-matthews-mpls-lsp-ibb-00.txt The authors of these drafts (Paul Brittain, Adrian Farrel and Philip Matthews) plus Eric Gray have had considerable discussion over the past 2 weeks on how to merge the two drafts and present a single draft back to the WG. A SUMMARY of our deliberations is as follows: - Both proposals use similar overall approaches to avoid full resynchronization of state after TCP failure/reconnection. - We will combine the drafts and issue a merged draft to the WG. - The ACK scheme will be based on [MATTHEWS], modified to use a new FT sequence number in place of Message ID - FT/non-FT labels from [FARREL] will be included in the merged draft. - Address messages need to be protected by the FT ACK scheme, as well as Label Request/Mapping etc.. - The procedural detail from [FARREL] should help interoperability and will be included in the draft, but with changes for the [MATTHEWS] ACKs - Philip Matthews will be presenting our plans for merging the proposals at Adelaide. - I am currently working on the merged draft and will issue it as soon as possible. READ ON if you want more detail on our deliberations. STOP HERE if you just need to know what we plan to do. This rest of this note provides more detail on our discussions, including the logic behind the main decisions we made, in order to keep the WG informed of our progress. For clarity, the notes below refer to the two drafts as [MATTHEWS] or [FARREL] where I need to make a distinction between the two approaches. These notes appear as a record for the WG on the offline deliberations between the authors. To fully understand these notes you will need at least a passing familiarity with both proposals. Alternatively, you can wait for Philip's presentation in Adelaide :-) Thanks, Paul Brittain. ---------------------------------------- _WHAT WE MEAN BY FT_ FT is the ability to preserve inbound and outbound segments plus X-connects for some labels (known as FT labels) at an individual LSR when that LSR experiences some form of h/w or s/w interruption. In particular, FT should enable an LDP implementation to handle upgrade to the hardware on which LDP or TCP is running, or upgrades to the LDP or TCP software, without interrupting the forwarding service on the FT labels. We discussed the fact that some scenarios could be handled using redundant link hardware and asuming that the TCP connection will re-route to the available link. However, this does not cover all cases. In particular, it can be very expensive to provide such redundant links, so 1:1 redundancy may not be available in all cases. This also does not handle the case where the TCP software is itself upgraded, causing an interruption to the TCP session. SCTP was also discussed as being one way to improve on the fault tolerance achieved using TCP, but we believe it is also unable to handle the software upgrade or stack failure scenarios without hitting the same issues that plague FT TCP implementations (duplication of data awaiting retransmission, reconneciton of "sockets" or similar) - though this is an area we are investigating further. It should be possible for two FT transit switches to handle, say, an upgrade to one of the LDP stacks without any of the end points for LSPs transiting these switches being aware of the change, and without the need for expensive, fully redundant hardware in both switches. In order to achieve this we need to introduce some level of co-operation between LSR peers to allow them to recover from any interruption to the TCP connection. Protection Switching is distinct from FT. PS handles the use of redundant links to preserve data forwarding across link failure. FT is targetted at preserving data forwarding across failure in the control plane, which would currently bring down data forwarding un-necessarily. _FUNCTION NEEDED FOR LDP FT_ We see this as breaking down into four main pieces: 1) Means of determining which LSR peers support and/or use the FT extensions 2) Means of identifying which LDP exchanges with these peers are FT-protected 3) Means of synchronizing state for the protected LDP exchanges on a per-hop basis 4) Some degree of trust in FT LSR peers. Looking at each of these in more detail to clarify why it is needed: 1) is obviously needed to allow interop with peers that do not support these extensions. It is (relatively) easily achieved by adding options to the LDP Initialization message. 2) is mainly a matter for policy. As such, we cannot dictate that the only option is that all labels are FT or none is. For example, consider the case where TE is used to pre-program load-balanced "label trunks" across an FT core network based on, say, traffic stats recorded over some interval, but without reserving bandwidth for those labels. LSRs at the edge of this core would distribute labels to (potentially) non-FT CPE routers on request, possibly using a label stack to tunnel across the core to the appropriate destination CPE router. In this case, the labels used in the core are FT, but the labels assigned at the edge need not be. Similarly, the edge switches in this example may use FT hardware, but they need no be running the FT extensions on all LDP sessions (e.g. to the CPE routers). We need to have the flexibility to distinguish FT and non-FT labels, and to allow each LSR to choose whether to run the FT enhancements one any given LDP session according to the nature of the services it is providing. 3) is obviously required to achieve any form of FT! If you're wondering why the requirements said "per-hop", see the previous paragraph. In this case, the edge routers will want to preserve the FT behavior of the core labels even if they drop any LSPs initiated/terminated by a CPE router when the CPE router dies. Besides, per-hop behavior can be used to build end-to-end behavior depending on policy choice. In practice, this synchronization will have to involve some form of acknowledgement of LDP exchanges so that the LSR peers can recover after TCP reconnection without re-exchanging _FULL_ state information (which doesn't scale), and some form of ACK reduction mechanism to ensure the ACKs don't slow down normal operation too much. 4) is a consequence of (3). If we allow FT for LDP, implicitly we have to trust adjacent LSRs to have preserved the information they claim to have kept from the previous TCP session. _HOW THIS FUNCTION IS ADDRESSED BY BOTH PROPOSALS_ 1) Identifying peers that use the FT extensions. Both proposals have essentially similar means of doing this - an option that says "I can do FT" and a separate option that says "I want to use preserved state". We will merge the proposals, incorporating the use of U-bit from [MATTHEWS] and the procedural detail from [FARREL]. 2) Identification of FT LDP Exchanges We will use a variant on the scheme in [FARREL] to identify FT labels. 3) Synchronizing state Both proposals use acknowledgements to determine when a state change has been handed over to the LSR peer, though the philosophy is a bit different. [MATTHEWS] adds an explicit ACK to every message (bad), but then uses piggybacking and a sequence number to reduce the number of ACKs flying about (good). [FARREL] exploits the implicit "acks" already in the LDP protocol (good), but has to add explicit acks to cover the cases where the base LDP protocol is insufficient (bad). [MATTHEWS] uses ACKs based on the LDP message ID. We decided this was unacceptable becaue of the constraints it placed on the use of the message ID, but that a variant using a new FT sequeunce number is workable. This is, in fact, then very reminiscent of the Nr handling in LLC2. One possible implementation would be to always include the last received (& secured) FT sequence number (assuming we use seq# not msg ID) in each LDP PDU sent by an FT peer. This gives timely acks to all messages if the LDP session is busy, with a fall-back of ACKing at least at every keepalive interval. This would lead to a degenerate case where the protocol introduces an 8-byte overhead on every message (if only one message is sent in each PDU), but does avoid building up lots of unacknowledged state. The actual overhead should be less than that in most cases. In comparison, [FARREL] has a fixed overhead of one additional Notification message sent per down-stream unsolicited Label Mapping and per Address message (assuming we add that - see (4) below) plus a variable overhead of one Notification message per Label Release/Label Abort in a couple of X-over cases. [FARREL] also does not allow for "early" acking of, say, a Label Request message before the Label Mapping is sent back upstream, which [MATTHEWS] does permit. Extendability is an issue for both proposals. Although [MATTHEWS] has the edge here in that should provide a mechanic that works for new message flows, both proposals potentially suffer from future interop problems if the authors of future MPLS drafts don't give some consideration to how their enhancements interact with FT. In particular, the procedures that a LSR should use to recover a new message flow are not necessarily as simple as just reissuing the "lost" messages. There's not much we can do about this, though, other than put some text into our draft encouraging future MPLS authors to consider how their proposals interact with FT. We did also discuss some concerns about whether the [MATTHEWS] ACK scheme would complicate multi-threading of LDP message handling, but came to the conclusion that as long as the FT sequence number is a per-label space entiry, [MATTHEWS] presents no greater MP issues than the base LDP protocol. On balance, we agreed to adope the [MATTHEWS] ACK scheme, modified to use a new FT sequence number. 4) Trusting the peer LSRs Both proposals place a high degree of trust on the peer LSRs. In particular, there is no resynchronization of the preserved label state. This is not a trivial assumption to make, though it is an important one if we are to end up with a scalable FT solution. This makes it very important that the FT draft includes sufficient detail on procedures to give us better confidence that trusted LSR peers will behave in an interoperable manner. One particular focus of our discussions was the Address messages. It is relatively easy to make this exchange secure using the mechanics from either proposal, but if this information ever gets out of sync, it could affect the operation of many labels. In contrast, failure to synchronize state on one label affects only that label. On balance, though, we think it is better to avoid any ambiguity over the validity of Address ranges exchanged on a previous instantiation of a recovered LDP session and require that both FT LSRs treat such exchanges having continued validity after recovery until an address range is explicitly withdrawn. From owner-mpls@UU.NET Tue Mar 21 08:54:51 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17008 for ; Tue, 21 Mar 2000 08:54:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmd01546; Tue, 21 Mar 2000 13:53:27 GMT Received: by mail-control.mail.uu.net id QQihmd21001 for mpls-outgoing; Tue, 21 Mar 2000 13:53:06 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihmd20996 for ; Tue, 21 Mar 2000 13:52:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmd23540 for ; Tue, 21 Mar 2000 08:52:43 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQihmd00981 for ; Tue, 21 Mar 2000 13:52:43 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id FAA19181 for ; Tue, 21 Mar 2000 05:52:42 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA17454 for mpls@uu.net; Tue, 21 Mar 2000 08:52:40 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihkd29593 for ; Tue, 21 Mar 2000 00:52:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihkd08749 for ; Mon, 20 Mar 2000 19:52:14 -0500 (EST) Received: from tnt.isi.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tnt.isi.edu [128.9.128.128]) id QQihkd07194 for ; Tue, 21 Mar 2000 00:52:13 GMT Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA03252; Mon, 20 Mar 2000 16:52:08 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id AAA09079; Tue, 21 Mar 2000 00:52:07 GMT Date: Tue, 21 Mar 2000 00:52:07 GMT Message-Id: <200003210052.AAA09079@gra.isi.edu> To: rsvp@ISI.EDU, mpls@UU.NET, AF@datcon.co.uk Subject: Re: Sender TSpec on PathTear X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> From rsvp-owner@ISI.EDU Mon Mar 20 04:45:27 2000 *> From: Adrian Farrel *> To: rsvp@ISI.EDU, mpls@uu.net *> Subject: Sender TSpec on PathTear *> Date: Mon, 20 Mar 2000 12:32:03 -0000 *> MIME-Version: 1.0 *> X-Mailer: Internet Mail Service (5.5.2650.21) *> Sender: owner-rsvp@ISI.EDU *> Precedence: bulk *> X-Lines: 44 *> *> All, *> *> RFC 2205 states that Sender TSpec is mandatory on a PathTear *> if a Sender Descriptor is included. *> *> ::= [ ] *> *> [ ] *> *> ::= (see earlier definition) *> And the very next sentence says, "A PathTear message may include a SENDER_TSPEC or ADSPEC object in its sender descriptor, but these must be ignored". There are several places where the text modulates the BNF, and this is one of them. This presentation was chosen for simplicity and (we thought) clarity, but apparently it failed for you. Bob Braden From owner-mpls@UU.NET Tue Mar 21 08:54:56 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17054 for ; Tue, 21 Mar 2000 08:54:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmd14676; Tue, 21 Mar 2000 13:53:55 GMT Received: by mail-control.mail.uu.net id QQihmd21010 for mpls-outgoing; Tue, 21 Mar 2000 13:53:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihmd21005 for ; Tue, 21 Mar 2000 13:53:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihmd23578 for ; Tue, 21 Mar 2000 08:53:13 -0500 (EST) Received: from kickme.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kickme.cisco.com [198.92.30.42]) id QQihmd13805 for ; Tue, 21 Mar 2000 13:53:12 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA07547 for ; Tue, 21 Mar 2000 05:40:26 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA17458 for mpls@uu.net; Tue, 21 Mar 2000 08:53:07 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihlu26776 for ; Tue, 21 Mar 2000 11:39:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihlu25100 for ; Tue, 21 Mar 2000 06:39:04 -0500 (EST) Received: from wayout.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [163.121.142.3]) id QQihlu22589 for ; Tue, 21 Mar 2000 11:38:58 GMT Received: from ieee.org ([209.58.43.170]) by wayout.net (8.8.5/8.7.3) with ESMTP id NAA10266; Tue, 21 Mar 2000 13:58:21 +0200 (EET) Message-ID: <38D75E81.82ED9102@ieee.org> Date: Tue, 21 Mar 2000 13:35:29 +0200 From: Khaled Elsayed X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ashwood-Smith CC: mpls@UU.NET Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <38D63434.B2D5CEFA@ieee.org> <38D646D9.FEBDCA86@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Peter, Peter Ashwood-Smith wrote: > You may waste enormous amounts of bandwidth if you cannot do > wavelength conversion. Convert the question to the ATM domain and > imagine how an ATM network would operate if you had to use the > same VCC from end to end. Basically, if you do not have the ability > to change "labels" then you need one label for EVERY unique path > through the network. Given that the number of paths through a network > grows what .. N factorial? You run out of labels very quickly. This is > especially true with DWDM equipement which may only support 50-100 "labels". > This means that a tiny network would exhaust all the labels/paths > AND you have many links that you can only use a small percentage of > the available "labels" ie bandwidth. So its a very unsatisfactory > solution. Also, to do a good job of it, you need a global view of > each path and label it will use. > I am not questioning the usefulness of wavelength conversion. It is definitely a good mechansim. (Although I have seen some research work that claims that wavelenght conversion may not be worthwhile in some scenarios). > The flip side is full blown wavelength conversion at every hop. > This makes the routing/signalling problem much simpler since you > only have to know if A label is free, not which one. This is the same > as knowing that bandwidth is free so all our exisiting ATM/MPLS-TE style > traffic engineering solutions can compute routes. Ideally though > you want to do wavelength conversion only where you have to .. to > "skip" past a link that is using the wavelength you want. In this > manner you can reduce the distortions created by the conversions. > This is kind of a hybrid approach that the signalling protocols can > take into account by trying where possible to reuse the same "label". I agree again. > Anyway, just because bandwidth is "huge" by todays standards and > "up times" are long, does not change the fundamental problem of > blocking of paths. Remember, long "up times" means looooong blocking > times and "huge" bandwidth means long blocking times with huge > amounts of bandwidth that are unusable. Not a pretty picture. This is what my question is about: will carriers or service providers afford to block those optically switched connections??? > Optical networks do not introduce anything all that new with > respect to traffic flows. The key points are that the bandwidth is > no longer statistically usable accross all the wavelengths and > there is of course no QOS ... all photons are created equal .. > at least as far as we know ;) These aspects of optical networking > make statistical multiplexing and different per hop behaviours > impossible and in many ways simplify the engineering job in the > core of the network. Actually in many ways its back to the behaviour > of the TDM circuit switched devices ... i.e. everybody is equal and > everybody gets the same chunk of bandwidth ... just a MUCH bigger This is what I was trying to say/discuss. But again, coming up with a well-engineered network design for WDM/DWDM with the constraints on wavelength conversion for whatever traffic model (dynamic or static) is still a challenging problem. Khaled Elsayed > slice. Anyway, I know I'm not answering your question, more > rambling around the edge of it .... > > Cheers, > > Peter From owner-mpls@UU.NET Tue Mar 21 09:05:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20544 for ; Tue, 21 Mar 2000 09:05:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihme08214; Tue, 21 Mar 2000 14:03:39 GMT Received: by mail-control.mail.uu.net id QQihme24625 for mpls-outgoing; Tue, 21 Mar 2000 14:03:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihme24587 for ; Tue, 21 Mar 2000 14:03:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihme24740 for ; Tue, 21 Mar 2000 09:02:13 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQihme23691 for ; Tue, 21 Mar 2000 14:02:12 GMT Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 14:02:01 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1404FB@monk.datcon.co.uk> From: Adrian Farrel To: mpls@UU.NET Subject: FW: draft-ietf-mpls-lsr-mib-02.txt nits Date: Tue, 21 Mar 2000 14:01:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF933E.0773B664" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF933E.0773B664 Content-Type: text/plain; charset="iso-8859-1" Thanks, Tom. That just about wraps it up from me. I would have liked DiffServ to be there, but we can't expect you to wait for every addition to the protocols. Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 ------_=_NextPart_001_01BF933E.0773B664 Content-Type: text/html; charset="iso-8859-1"
Thanks, Tom.
 
That just about wraps it up from me.
 
I would have liked DiffServ to be there, but we can't expect you to wait for every addition to the protocols.
 
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
------_=_NextPart_001_01BF933E.0773B664-- From owner-mpls@UU.NET Tue Mar 21 09:06:33 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21159 for ; Tue, 21 Mar 2000 09:06:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmd15685; Tue, 21 Mar 2000 13:54:42 GMT Received: by mail-control.mail.uu.net id QQihmd21044 for mpls-outgoing; Tue, 21 Mar 2000 13:54:05 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihmd21032 for ; Tue, 21 Mar 2000 13:53:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmd23639 for ; Tue, 21 Mar 2000 08:53:36 -0500 (EST) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQihmd01757 for ; Tue, 21 Mar 2000 13:53:36 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA01611 for ; Tue, 21 Mar 2000 05:53:35 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA17463 for mpls@uu.net; Tue, 21 Mar 2000 08:53:34 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihlv28101 for ; Tue, 21 Mar 2000 11:59:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihlv13839 for ; Tue, 21 Mar 2000 06:59:25 -0500 (EST) Received: from wayout.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [163.121.142.3]) id QQihlv17229 for ; Tue, 21 Mar 2000 11:59:22 GMT Received: from ieee.org ([209.58.43.170]) by wayout.net (8.8.5/8.7.3) with ESMTP id OAA10367; Tue, 21 Mar 2000 14:18:28 +0200 (EET) Message-ID: <38D76337.478CA5FC@ieee.org> Date: Tue, 21 Mar 2000 13:55:35 +0200 From: Khaled Elsayed X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jagan Shantigram CC: mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <3.0.6.32.20000320164430.00c3d240@photonex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Jagan, > When we do not have lambda conversion however, this problem cannot > be solved optimally.. it is akin to the graph coloring > problem - which ofcourse has heuristics that can get us to > a factor (?) of the optimal solution. So, connections may > be blocked even though there is capacity on the fiber to > support it, just because the wavelength is already used up. > Connections can be blocked when?? At service provisioning time or at the time the connection is requested?? My point is a connection of 2.48 Gbps is not likely to be a random event or an ATM-like SVC. If a customer would require such huge bandwidth, it would need that BW to go through or it would better look for another carrier that will provide a TDM/leased line?? Of course wavelength conversion can help build a better-utilized network, no question about that. Khaled > I suspect this is a provisioning issue. Currently it is a nightmare > to provision for the expanding needs of customers.. with advanced > intelligent optical systems, fatter pipes can be provisioned as easy > as ordering a pizza? I will however humbly defer to those who know > more about the need for dynamic optical path setup and traffic > mgmt. > From owner-mpls@UU.NET Tue Mar 21 09:32:46 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01961 for ; Tue, 21 Mar 2000 09:32:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmg23127; Tue, 21 Mar 2000 14:30:33 GMT Received: by mail-control.mail.uu.net id QQihmg01958 for mpls-outgoing; Tue, 21 Mar 2000 14:30:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihmg01891 for ; Tue, 21 Mar 2000 14:30:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmf28212 for ; Tue, 21 Mar 2000 09:29:53 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihmf23824 for ; Tue, 21 Mar 2000 14:29:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA18948 for mpls@uu.net; Tue, 21 Mar 2000 09:29:52 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihmf01660 for ; Tue, 21 Mar 2000 14:29:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmf11268 for ; Tue, 21 Mar 2000 09:29:09 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQihmf23381 for ; Tue, 21 Mar 2000 14:29:09 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 09:27:29 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F895@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Jhilmil Kochar'" , Joan Cucchiara Cc: =?iso-8859-1?Q?=27Hans_Sj=F6strand=27?= , "'mpls@uu.net'" Subject: RE: LDP MIB last call Date: Tue, 21 Mar 2000 09:27:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA01961 > -----Original Message----- > From: Jhilmil Kochar [mailto:jkochar@ficon-tech.com] > Sent: Tuesday, March 21, 2000 2:46 AM > To: Joan Cucchiara > Cc: 'Hans Sjöstrand'; 'mpls@uu.net' > Subject: Re: LDP MIB last call > > > Hi Joan, > > > > > > > > 6. mplsLdpEntityPeerEntry: It is not clear why the entries > > > in this table > > > > should not be present in session table. As far as I can > > > make out these > > > > parameters and also the parameters in session table are > > > passed in init > > > > message between peers, hence the purpose for keeping them > > > in separate > > > > tables is not clear. One possible reasoning I could > come up with was > > > > that one gives peer information that is non-negotiable and > > > other gives > > > > peer information that is negotiated. But then this rule > > > does not hold > > > > true for all entries. Please clarify. > > > > The split between the two tables were for values used in > > an active Session, versus values which were ignored by the > > session (although a session is still created). > > > > The objects in the EntityPeer Table are related > > to PathVectorLimit and are used to generate a trap if a > > mismatch occurs. The Session uses the PathVector value which > > is in the Entity Table if there is a mismatch between the > > two values. > > > > We probably should add more text here then, if this is > > not clear. Hi Jhilmil, > > More text would be helpful. Does this mean there there will > always be a > one-one mapping beween a Peer entry and a session entry? ie > one LDP Peer can > have only one session with the entity? The indexing for both > is the same, > but the draft does not explicitly mention this. The mplsEntityPeerEntry (above called Peer entry) is information related to a session (i.e. information which is obtained during the session initialization process) which is why the indexing is the same as the session's. This information is the Peer's PathVector information which is exchanged during session init time. The Entity's PathVector info is in the Entity Table. The session will always use the Entity's PathVector Info. The only reason to keep track of the Peer's PathVector Info is to send a trap in the event that the PathVector Limit's for a specific session is not the same as the Entity's (in other words, the Peer has a different Limit than the Entity). This is about the only case where a session will still be established without having to negotiate (i.e. change values). We will add more text and perhaps a name change to this table as it seems to continues to be a point of confusion. For your answer about the relationship to the mplsEntityPeer entry and the Session Entry, they are one-to-one because the information is related to a specific session establishment. Perhaps an Augment's relationship would be more clear... Thanks, Joan > > > Thanks and regards > Jhilmil > > -- > > ------------------------------ > Jhilmil Kochar > Ficon Technology > E-mail:jkochar@ficon-tech.com > Web: www.ficon-tech.com > > > From owner-mpls@UU.NET Tue Mar 21 09:42:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05820 for ; Tue, 21 Mar 2000 09:42:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmg04475; Tue, 21 Mar 2000 14:40:56 GMT Received: by mail-control.mail.uu.net id QQihmg02825 for mpls-outgoing; Tue, 21 Mar 2000 14:40:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihmg02803 for ; Tue, 21 Mar 2000 14:40:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmg29814 for ; Tue, 21 Mar 2000 09:40:14 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihmg00274 for ; Tue, 21 Mar 2000 14:40:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA20670 for mpls@uu.net; Tue, 21 Mar 2000 09:40:12 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihmg02734 for ; Tue, 21 Mar 2000 14:39:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihmg12778 for ; Tue, 21 Mar 2000 09:39:49 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQihmg03021 for ; Tue, 21 Mar 2000 14:39:49 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 09:38:10 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F896@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'tnadeau@cisco.com'" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" Subject: LSR MIB comments and questions Date: Tue, 21 Mar 2000 09:38:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom, Arun and Cheenu, I have read over most of the LSR MIB as you requested and as you probably expect, have some comments and questions. -Joan Editorial --------- * needs a table of contents * would be nice to have a revisions section to track changes between versions, since this has already been done on the email list, adding it to the document should be trivial. * It seems that many tables in this MIB were gleaned from the ATM MIB, specifically the mplsInterfaceConfTable and the Cross Connect Tables. Could you add a reference to the ATM MIB in the Reference Section? General MIB Comments -------------------- * InterfaceIndex: understanding which InterfaceIndex is being used is sometimes unclear. Since this MIB handles all MPLS protocols, the use of which InterfaceIndex and its corresponding ifType and thus an indication of where it would appear in the ifStackTable should be clear, especially because many objects such as InPacket, InDiscards, AdminStatus, OperStatus, etc seem to me to potentially overlap with what is in the ifTable and ifXTable for ifType mpls. More description upfront would help with this. * StorageType objects need to be added throughout various tables. FRONT SECTION ------------- * Sections 8.0 'Application of the Interface Group to MPLS' and 8.1 'Suport of the MPLS Layer by ifTable' "...Thus, the MPLS layer interface is represented as an entry in the ifTable. This entry is concerned with the MPLS layer as a whole, and not with individual LSPs/tunnels which are managed via the MPLS-specific managed objects specified in this memo and in [TEMIB]." I am confused by these statements. There is as of yet, no concept of an MPLS Layer other than as outlined in the architecture specification which talks about a shim layer. Is this the mpls shim layer (i.e. the layer where label stacking takes place) or something else? MIB --- * Revision history is incorrect. The initial revision in June 1999. * ifIndex is not a textual convention * Last Updated clause is incorrect. The last update should match the latest revision date and these do not match. * MplsLsrIANAAddrFamily needs to be removed. The AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB should be imported. See RFC2677 or LDP MIB. * MplsLabel needs to be updated to reflect the FRF decision to drop 17-bit DLCI support. Also, missing REFERENCE for 'MPLS using LDP and ATM VC Switching', draft-ietf-mpls-atm-02.txt. (the LDP MIB has updated this and it would be good if we could agree on a single definition for this TC.) * IpV6Address -- ref. draft-ops-endpoint-mib-07.txt Could you use similar IPv6 TCs as defined in the draft-ops-endpoint-mib-07.txt MIB? e.g. InetAddressIPv6 OCTET STRING (SIZE(16|20)) * In the MplsInterfaceConfTable a zero index for mplsInterfaceConfIndex indicates that this entry represents a global label space. There can also be only one entry in the table which contains a zero value for this index, correct? * Does the 'mplsInterfaceIsLocalLabelSpace' indicate per interface label space only? I am confused why you need this object, it would seem that if the value of mplsInterfaceConfIndex is non-zero then this means that it is a per Interface label space, and that the 'mplsInterfaceIsGlobalLabelSpace' would indicate if it is participating in a global Label Space also. Could a REFERENCE clause labels which are considered both per interface and per platform be added to the LocalLabelSpace Object? * Not sure that I understand the use of the MIN and MAX IN/OUT labels. How does this relate to LDP which uses an ATM-type interface (and thus has a bunch of label ranges)? Are these MIN/MAX values a proper superset of label ranges on a per interface label space? * Total and Available Buffer. What is it that is supposed to be learned from these values? * mplsInterfaceAdminStatus and mplsInterfaceOperStatus why are these necessary? It seems like ifAdminStatus and ifOperStatus should be used for this. * mplsInterfacePerfEntry is said to Augment the mplsInterfaceConfEntry, what happens for the situation when 'mplsInterfaceConfIndex' is zero? How are the values in this table counted when a label participates in both the global and local label spaces? Also, it seems that some of these overlap with ifTable (specifically, mplsInterfaceInPackets, mplsInterfaceInDiscards, mplsInterfaceOutPackets, mplsInterfaceOutDiscards), maybe I am missing something here, but on an mplsInterface, I would assume that the ifTable and ifXTable would be counting Octets and Packets which are in essence MPLS Octets and Packets. Could you add in the description something which would differentiate these from the ifTable and ifXTable at the mpls layer? (Aside: because the front section of the document includes how to interpret the ifTable and ifXTable objects, I am under the assumption that these things are being counted in those tables and not here....) * mplsInSegmentTable has no "IndexNext" object. Could one be added? * mplsInSegmentIfIndex type in Sequence doesn't match Object's type. Also this should be not-accessible. Currently, it is read-create. What is the ifType of this index? Is this the same as the index used in the mplsInterfaceConfEntry for the label related to this entry? Could more description be added to this index? * mplsInSegmentAddrFamily needs to use the IANA-ADDRESS-FAMILY-NUMBER-MIB's AddressFamilyNumbers TC. Reference is incorrect on this also. * mplsInSegmentXCIndex description is incorrect. A value of zero could certainly indicates a valid cross connect. The XC table does model XCs even for terminating InSegments and Originating OutSegments. The syntax clause should be changed in either this table or in the XC table since the syntax should be the same in both places. * mplsInSegmentTSpecIndex -- this object needs to be made optional for LDP. * mplsInSegmentOwner -- could this be removed from the table. These object are of little value in my opinion because who really cares how the row got created? Also, if you have snmp and policyAgent, then you should add cli, config file, web, etc.... Just seems to be a big rat hole in my opinion. * mplsOutSegmentIndexNext object range should start at 0 (zero). * mplsOutSegmentEntry is incorrect and should say 'outgoing' in place of incoming which I think someone else mentioned already. Also REF clause should be updated * mplsOutSegmentIfIndex should be not-accessible * mplsOutSegmentPushTopLabel's description is somewhat misleading with regard to the current version of LDP. In the case of LDP using ATM, the idea of a label popping does not apply. So it's misleading to say, it does not support pop-and-go. It does not support label popping at all. Could you rephrase this section to specifically call out that for Version 1 of LDP using ATM or FR this should be set to true and Reference Section 5. of the LDP Spec? * mplsOutSegmentTopLabel Could this object be changed to contain the value of the top label on egress? I think it would be much more interesting to point to the egress label especially since the prior object (mplsOutSegmentPushTopLabel) tells whether or not this was pushed. * mplsOutSegmentNextHopIpAddrType should use similar TC's as defined in draft-ops-endpoint-mib-07.txt Also, I have a question on this description: What is meant by the outgoing interface being point-to-point in the case of LDP using ATM? * mplsOutSegmentNextHopIpv4Addr and mplsOutSegmentNextHopIpv6Addr these should be combined, and should also use the relevant TC in draft-ops-endpoint-mib-07.txt * mplsXCIndexNext object's range should start at 0. * INDEX clause and description of the entry: The description redefines what a values of zero means for the mplsInSegmentIfIndex and mplsInSegmentLabel; in the mplsInSegmentTable they mean one thing, and yet, they mean something else in the XC table. Could this be clarified? * mplsXCIndex should be not-accessible * mplsXCCOS, should this object be made optional for LDP? * mplsXCIsPersistent should have SYNTAX of StorageType * mplsXCOwner same comment as before, big rat hole, could we get rid of this object? * What do the AdminStatus and OperStatus objects mean when the LSP is terminating or Originating for this entry? -- From owner-mpls@UU.NET Tue Mar 21 10:13:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17368 for ; Tue, 21 Mar 2000 10:13:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmi21454; Tue, 21 Mar 2000 15:13:01 GMT Received: by mail-control.mail.uu.net id QQihmi13634 for mpls-outgoing; Tue, 21 Mar 2000 15:12:31 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihmi13586 for ; Tue, 21 Mar 2000 15:12:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihmi04759 for ; Tue, 21 Mar 2000 10:12:19 -0500 (EST) Received: from albatross.wise.edt.ericsson.se by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQihmi07709 for ; Tue, 21 Mar 2000 15:12:18 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA08501 for ; Tue, 21 Mar 2000 16:02:36 +0100 (MET) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA25638 for ; Tue, 21 Mar 2000 16:05:33 +0100 (MET) Received: from etx.ericsson.se (avpc66.etxb.ericsson.se [130.100.27.66]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FRS00JI81X7T4@mbb1.ericsson.se> for mpls@UU.NET; Tue, 21 Mar 2000 16:05:32 +0100 (MET) Date: Tue, 21 Mar 2000 16:05:16 +0100 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: LDP MIB last call To: Jhilmil Kochar Cc: "'mpls@uu.net'" , jcucchiara@brixnet.com Message-id: <38D78FAC.2B03DCBE@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <38D0A77B.36844C5C@ficon-tech.com> <38D0E5FF.F3E82E14@etx.ericsson.se> <38D725A6.2E00408E@ficon-tech.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jhilmil Kochar wrote: > > Hi Hans, > > > > > > 2. mplsLdpEntityEntry: Some of the objects in this table should have a > > > default value assigned as specified by LDP draft. Examples of such > > > objects are mplsLdpEntityWellKnownDiscoveryPort, > > > mplsLdpEntityMaxPduLength, mplsLdpEntityKeepAliveHoldtimer. > > > > Agree in principle. It however only DiscoveryPort that is specified > > in other specs. > > mplsLdpEntityWellKnownDiscoveryPort = 646 > > > > Max PDU lenth is really implementation specific. But I see no reason to > > have any other default value than maximum? > > > > mplsLdpEntityMaxPduLength = 65535 ? > > LDP draft sec 3.1 > "Prior to completion of the negotiation the maximum > allowable length is 4096 bytes." > and sec 3.5.3 > "A value of 255 or less > specifies the default maximum length of 4096 octets." > Shouldn't the default value by 4096? That is the value mentioned if you study the LDP spec. That is a value that should be considered safe for all implementations, i.e low value. The value that is set to default in the mib is going to be the initial value for the negotiation. And that negotiation can only take the value down, so it should be a high value. thats the reasoning behind > > Max PDU lenth is really implementation specific. But I see no reason to > > have any other default value than maximum? On the other hand, what LDP PDU is bigger than 4096? Not many. And TCP will handle the fragmentation. So I could go for 4096 if you could give a reason? regards /// Hasse > > > > > > > regards > Jhilmil > -- > > ------------------------------ > Jhilmil Kochar > Ficon Technology > E-mail:jkochar@ficon-tech.com > Web: www.ficon-tech.com From owner-mpls@UU.NET Tue Mar 21 10:19:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19379 for ; Tue, 21 Mar 2000 10:19:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmj24631; Tue, 21 Mar 2000 15:17:48 GMT Received: by mail-control.mail.uu.net id QQihmj14575 for mpls-outgoing; Tue, 21 Mar 2000 15:17:29 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihmj14567 for ; Tue, 21 Mar 2000 15:17:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmj18444 for ; Tue, 21 Mar 2000 10:17:18 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihmj24183 for ; Tue, 21 Mar 2000 15:17:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA26342 for mpls@uu.net; Tue, 21 Mar 2000 10:17:16 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihmj14523 for ; Tue, 21 Mar 2000 15:16:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmj05464 for ; Tue, 21 Mar 2000 10:16:44 -0500 (EST) Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQihmj23880 for ; Tue, 21 Mar 2000 15:16:43 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 10:15:41 -0500 Message-ID: From: "Atkinson, Stephen" To: "'Thomas D. Nadeau'" , Adrian Farrel , mpls@UU.NET Cc: arun@force10networks.com, cheenu@tachion.com Subject: RE: draft-ietf-mpls-lsr-mib-02.txt nits Date: Tue, 21 Mar 2000 10:15:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom, Just one comment below on the LSPID. Regards, steve atkinson >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Monday, March 20, 2000 4:12 PM >To: Adrian Farrel; mpls@UU.NET >Cc: arun@force10networks.com; cheenu@tachion.com >Subject: RE: draft-ietf-mpls-lsr-mib-02.txt nits > > > > Hi Adrian, > > My comments are in blue. > > >>> 1. LSPID >>> >>> In previous mail exchanges I asked why the LSPID Textual >>> Convention needed to allow 63 bytes. You answered that >>> this was to allow space for IPv6 addresses. >>> >[snip] > >The LSPID is not the label. >I don't think the framework mentions LSPID at all. This is >something in the protocols where 2 bytes is the currently defined >maximum. >I don't suppose this is a big issue - just pushing you to try to >understand why 63 bytes. > > Agreed. We will make it 4 bytes. The LSPID needs to be 6 bytes to handle CR-LDP using IPV4. Refer to section 4.5 "LSPID TLV" of draft-ietf_mpls-cr-ldp-03.txt. I believe the same is true for TE-RSVP. > > [snip] From owner-mpls@UU.NET Tue Mar 21 10:47:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00880 for ; Tue, 21 Mar 2000 10:47:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihml15851; Tue, 21 Mar 2000 15:45:29 GMT Received: by mail-control.mail.uu.net id QQihml17259 for mpls-outgoing; Tue, 21 Mar 2000 15:45:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihmk17234 for ; Tue, 21 Mar 2000 15:44:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihmk09734 for ; Tue, 21 Mar 2000 10:44:34 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihmk09307 for ; Tue, 21 Mar 2000 15:44:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA01024 for mpls@uu.net; Tue, 21 Mar 2000 10:44:32 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihmk17185 for ; Tue, 21 Mar 2000 15:44:03 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihmk22717 for ; Tue, 21 Mar 2000 10:43:55 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihmk08847 for ; Tue, 21 Mar 2000 15:43:54 GMT Received: from rschmitt-nt (ch2-dhcp134-243.cisco.com [161.44.134.243]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA00888; Tue, 21 Mar 2000 10:43:43 -0500 (EST) Message-Id: <4.2.0.58.20000321104637.00a3b6e0@pilgrim.cisco.com> X-Sender: rschmitt@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 21 Mar 2000 10:47:03 -0800 To: Joan Cucchiara From: Rob Schmitt Subject: RE: LDP MIB last call Cc: "'Jhilmil Kochar'" , Joan Cucchiara , "'Hans =?iso-8859-1?Q?Sjöstrand=27?=" , "'mpls@uu.net'" In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F895@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA00880 The mplsEntityPeerEntry (above called Peer entry) is information ...... ...... We will add more text and perhaps a name change to this table as it seems to continues to be a point of confusion. Hi Joan.. We could have seen the confusion coming..as I said before, a peer is a peer is a peer, so making it 'entitypeer' says -WHAT-?? I have an idea, maybe we could call it 'mplsPeerEntry'. :) /rs At 09:27 AM 3/21/00 -0500, Joan Cucchiara wrote: > > -----Original Message----- > > From: Jhilmil Kochar [mailto:jkochar@ficon-tech.com] > > Sent: Tuesday, March 21, 2000 2:46 AM > > To: Joan Cucchiara > > Cc: 'Hans Sjöstrand'; 'mpls@uu.net' > > Subject: Re: LDP MIB last call > > > > > > Hi Joan, > > > > > > > > > > > > 6. mplsLdpEntityPeerEntry: It is not clear why the entries > > > > in this table > > > > > should not be present in session table. As far as I can > > > > make out these > > > > > parameters and also the parameters in session table are > > > > passed in init > > > > > message between peers, hence the purpose for keeping them > > > > in separate > > > > > tables is not clear. One possible reasoning I could > > come up with was > > > > > that one gives peer information that is non-negotiable and > > > > other gives > > > > > peer information that is negotiated. But then this rule > > > > does not hold > > > > > true for all entries. Please clarify. > > > > > > The split between the two tables were for values used in > > > an active Session, versus values which were ignored by the > > > session (although a session is still created). > > > > > > The objects in the EntityPeer Table are related > > > to PathVectorLimit and are used to generate a trap if a > > > mismatch occurs. The Session uses the PathVector value which > > > is in the Entity Table if there is a mismatch between the > > > two values. > > > > > > We probably should add more text here then, if this is > > > not clear. > >Hi Jhilmil, > > > > > More text would be helpful. Does this mean there there will > > always be a > > one-one mapping beween a Peer entry and a session entry? ie > > one LDP Peer can > > have only one session with the entity? The indexing for both > > is the same, > > but the draft does not explicitly mention this. > >The mplsEntityPeerEntry (above called Peer entry) is information >related to a session (i.e. information which is obtained during >the session initialization process) which is why the indexing is >the same as the session's. This information is the Peer's >PathVector information which is exchanged during session init >time. The Entity's PathVector info is in the Entity Table. >The session will always use the Entity's PathVector Info. >The only reason to keep track of the Peer's PathVector Info >is to send a trap in the event that the PathVector Limit's >for a specific session is not the same as the Entity's (in other words, the >Peer has a different Limit than the Entity). This is about >the only case where a session will still be established without >having to negotiate (i.e. change values). > >We will add more text and perhaps a name change to this >table as it seems to continues to be a point of confusion. > >For your answer about the relationship to the mplsEntityPeer >entry and the Session Entry, they are one-to-one because >the information is related to a specific session establishment. >Perhaps an Augment's relationship would be more clear... > >Thanks, Joan > > > > > > > > Thanks and regards > > Jhilmil > > > > -- > > > > ------------------------------ > > Jhilmil Kochar > > Ficon Technology > > E-mail:jkochar@ficon-tech.com > > Web: www.ficon-tech.com > > > > > > > From owner-mpls@UU.NET Tue Mar 21 11:02:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06172 for ; Tue, 21 Mar 2000 11:02:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmm21601; Tue, 21 Mar 2000 16:01:42 GMT Received: by mail-control.mail.uu.net id QQihmm19922 for mpls-outgoing; Tue, 21 Mar 2000 16:01:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihmm19780 for ; Tue, 21 Mar 2000 16:00:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmm25439 for ; Tue, 21 Mar 2000 11:00:44 -0500 (EST) Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQihmm03747 for ; Tue, 21 Mar 2000 16:00:43 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 08:00:35 -0800 Message-ID: From: Vijay Srinivasan To: "'Joan Cucchiara'" , "'tnadeau@cisco.com'" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" Subject: LSR MIB last call Date: Tue, 21 Mar 2000 08:00:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF934E.97E63C66" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF934E.97E63C66 Content-Type: text/plain; charset="iso-8859-1" The authors of the LSR MIB have requested that we progress the document to WG last call. I would like to commence the last call, ending in two weeks (due to the IETF in between). Joan's comments to the list will be considered as part of the last call. - Vijay -----Original Message----- From: Joan Cucchiara [mailto:JCucchiara@Brixnet.com] Sent: Tuesday, March 21, 2000 6:38 AM To: 'tnadeau@cisco.com'; 'arun@force10networks.com'; 'cheenu@tachion.com' Cc: 'mpls@uu.net' Subject: LSR MIB comments and questions Hi Tom, Arun and Cheenu, I have read over most of the LSR MIB as you requested and as you probably expect, have some comments and questions. -Joan Editorial --------- * needs a table of contents * would be nice to have a revisions section to track changes between versions, since this has already been done on the email list, adding it to the document should be trivial. * It seems that many tables in this MIB were gleaned from the ATM MIB, specifically the mplsInterfaceConfTable and the Cross Connect Tables. Could you add a reference to the ATM MIB in the Reference Section? General MIB Comments -------------------- * InterfaceIndex: understanding which InterfaceIndex is being used is sometimes unclear. Since this MIB handles all MPLS protocols, the use of which InterfaceIndex and its corresponding ifType and thus an indication of where it would appear in the ifStackTable should be clear, especially because many objects such as InPacket, InDiscards, AdminStatus, OperStatus, etc seem to me to potentially overlap with what is in the ifTable and ifXTable for ifType mpls. More description upfront would help with this. * StorageType objects need to be added throughout various tables. FRONT SECTION ------------- * Sections 8.0 'Application of the Interface Group to MPLS' and 8.1 'Suport of the MPLS Layer by ifTable' "...Thus, the MPLS layer interface is represented as an entry in the ifTable. This entry is concerned with the MPLS layer as a whole, and not with individual LSPs/tunnels which are managed via the MPLS-specific managed objects specified in this memo and in [TEMIB]." I am confused by these statements. There is as of yet, no concept of an MPLS Layer other than as outlined in the architecture specification which talks about a shim layer. Is this the mpls shim layer (i.e. the layer where label stacking takes place) or something else? MIB --- * Revision history is incorrect. The initial revision in June 1999. * ifIndex is not a textual convention * Last Updated clause is incorrect. The last update should match the latest revision date and these do not match. * MplsLsrIANAAddrFamily needs to be removed. The AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB should be imported. See RFC2677 or LDP MIB. * MplsLabel needs to be updated to reflect the FRF decision to drop 17-bit DLCI support. Also, missing REFERENCE for 'MPLS using LDP and ATM VC Switching', draft-ietf-mpls-atm-02.txt. (the LDP MIB has updated this and it would be good if we could agree on a single definition for this TC.) * IpV6Address -- ref. draft-ops-endpoint-mib-07.txt Could you use similar IPv6 TCs as defined in the draft-ops-endpoint-mib-07.txt MIB? e.g. InetAddressIPv6 OCTET STRING (SIZE(16|20)) * In the MplsInterfaceConfTable a zero index for mplsInterfaceConfIndex indicates that this entry represents a global label space. There can also be only one entry in the table which contains a zero value for this index, correct? * Does the 'mplsInterfaceIsLocalLabelSpace' indicate per interface label space only? I am confused why you need this object, it would seem that if the value of mplsInterfaceConfIndex is non-zero then this means that it is a per Interface label space, and that the 'mplsInterfaceIsGlobalLabelSpace' would indicate if it is participating in a global Label Space also. Could a REFERENCE clause labels which are considered both per interface and per platform be added to the LocalLabelSpace Object? * Not sure that I understand the use of the MIN and MAX IN/OUT labels. How does this relate to LDP which uses an ATM-type interface (and thus has a bunch of label ranges)? Are these MIN/MAX values a proper superset of label ranges on a per interface label space? * Total and Available Buffer. What is it that is supposed to be learned from these values? * mplsInterfaceAdminStatus and mplsInterfaceOperStatus why are these necessary? It seems like ifAdminStatus and ifOperStatus should be used for this. * mplsInterfacePerfEntry is said to Augment the mplsInterfaceConfEntry, what happens for the situation when 'mplsInterfaceConfIndex' is zero? How are the values in this table counted when a label participates in both the global and local label spaces? Also, it seems that some of these overlap with ifTable (specifically, mplsInterfaceInPackets, mplsInterfaceInDiscards, mplsInterfaceOutPackets, mplsInterfaceOutDiscards), maybe I am missing something here, but on an mplsInterface, I would assume that the ifTable and ifXTable would be counting Octets and Packets which are in essence MPLS Octets and Packets. Could you add in the description something which would differentiate these from the ifTable and ifXTable at the mpls layer? (Aside: because the front section of the document includes how to interpret the ifTable and ifXTable objects, I am under the assumption that these things are being counted in those tables and not here....) * mplsInSegmentTable has no "IndexNext" object. Could one be added? * mplsInSegmentIfIndex type in Sequence doesn't match Object's type. Also this should be not-accessible. Currently, it is read-create. What is the ifType of this index? Is this the same as the index used in the mplsInterfaceConfEntry for the label related to this entry? Could more description be added to this index? * mplsInSegmentAddrFamily needs to use the IANA-ADDRESS-FAMILY-NUMBER-MIB's AddressFamilyNumbers TC. Reference is incorrect on this also. * mplsInSegmentXCIndex description is incorrect. A value of zero could certainly indicates a valid cross connect. The XC table does model XCs even for terminating InSegments and Originating OutSegments. The syntax clause should be changed in either this table or in the XC table since the syntax should be the same in both places. * mplsInSegmentTSpecIndex -- this object needs to be made optional for LDP. * mplsInSegmentOwner -- could this be removed from the table. These object are of little value in my opinion because who really cares how the row got created? Also, if you have snmp and policyAgent, then you should add cli, config file, web, etc.... Just seems to be a big rat hole in my opinion. * mplsOutSegmentIndexNext object range should start at 0 (zero). * mplsOutSegmentEntry is incorrect and should say 'outgoing' in place of incoming which I think someone else mentioned already. Also REF clause should be updated * mplsOutSegmentIfIndex should be not-accessible * mplsOutSegmentPushTopLabel's description is somewhat misleading with regard to the current version of LDP. In the case of LDP using ATM, the idea of a label popping does not apply. So it's misleading to say, it does not support pop-and-go. It does not support label popping at all. Could you rephrase this section to specifically call out that for Version 1 of LDP using ATM or FR this should be set to true and Reference Section 5. of the LDP Spec? * mplsOutSegmentTopLabel Could this object be changed to contain the value of the top label on egress? I think it would be much more interesting to point to the egress label especially since the prior object (mplsOutSegmentPushTopLabel) tells whether or not this was pushed. * mplsOutSegmentNextHopIpAddrType should use similar TC's as defined in draft-ops-endpoint-mib-07.txt Also, I have a question on this description: What is meant by the outgoing interface being point-to-point in the case of LDP using ATM? * mplsOutSegmentNextHopIpv4Addr and mplsOutSegmentNextHopIpv6Addr these should be combined, and should also use the relevant TC in draft-ops-endpoint-mib-07.txt * mplsXCIndexNext object's range should start at 0. * INDEX clause and description of the entry: The description redefines what a values of zero means for the mplsInSegmentIfIndex and mplsInSegmentLabel; in the mplsInSegmentTable they mean one thing, and yet, they mean something else in the XC table. Could this be clarified? * mplsXCIndex should be not-accessible * mplsXCCOS, should this object be made optional for LDP? * mplsXCIsPersistent should have SYNTAX of StorageType * mplsXCOwner same comment as before, big rat hole, could we get rid of this object? * What do the AdminStatus and OperStatus objects mean when the LSP is terminating or Originating for this entry? -- ------_=_NextPart_001_01BF934E.97E63C66 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LSR MIB last call

The authors of the LSR MIB have requested that we = progress the document to WG last call.  I would like to commence = the last call, ending in two weeks (due to the IETF in between).  = Joan's comments to the list will be considered as part of the last = call.

- Vijay

-----Original Message-----
From: Joan Cucchiara [mailto:JCucchiara@Brixnet.com= ]
Sent: Tuesday, March 21, 2000 6:38 AM
To: 'tnadeau@cisco.com'; = 'arun@force10networks.com';
'cheenu@tachion.com'
Cc: 'mpls@uu.net'
Subject: LSR MIB comments and questions



Hi Tom, Arun and Cheenu,

I have read over most of the LSR MIB as you requested =
and as you probably expect, have some comments and = questions. 

-Joan


Editorial
---------

* needs a table of contents

* would be nice to have a revisions section to
  track changes between versions, since this =
  has already been done on the email list, = adding
  it to the document should be trivial.

* It seems that many tables in this MIB were = gleaned
  from the ATM MIB, specifically the = mplsInterfaceConfTable
  and the Cross Connect Tables.  Could you = add a
  reference to the ATM MIB in the Reference = Section?



General MIB Comments
--------------------

*  InterfaceIndex: understanding which = InterfaceIndex
   is being used is sometimes = unclear.  Since
   this MIB handles all MPLS = protocols,
   the use of which InterfaceIndex and = its
   corresponding ifType and thus an = indication of
   where it would appear in the = ifStackTable should
   be clear, especially because many = objects such
   as InPacket, InDiscards, AdminStatus, = OperStatus, etc
   seem to me to potentially overlap with = what is
   in the ifTable and ifXTable for ifType = mpls.
   More description upfront would help = with this.

* StorageType objects need to be added = throughout
  various tables.



FRONT SECTION
-------------

* Sections 8.0 'Application of the Interface Group to = MPLS'
  and 8.1 'Suport of the MPLS Layer by = ifTable'

  "...Thus, the MPLS layer interface is = represented as an entry in
   the ifTable.  This entry is = concerned with the MPLS layer
   as a whole, and not with individual = LSPs/tunnels which are
   managed via the MPLS-specific managed = objects specified in this
   memo and in [TEMIB]."  =

   I am confused by these statements.  = There is as of yet, no
   concept of an MPLS Layer other than as = outlined in the
   architecture specification which talks = about a shim layer.

   Is this the mpls shim layer (i.e. the = layer where label
   stacking takes place) or something = else?

MIB
---
* Revision history is incorrect.  The
  initial revision in June 1999.

* ifIndex is not a textual convention

* Last Updated clause is incorrect.  The = last
  update should match the latest revision = date
  and these do not match.

* MplsLsrIANAAddrFamily needs to be removed.
  The AddressFamilyNumbers FROM = IANA-ADDRESS-FAMILY-NUMBERS-MIB
  should be imported.  See RFC2677 or LDP = MIB.

* MplsLabel needs to be updated to reflect the FRF = decision
  to drop 17-bit DLCI support.  Also, = missing REFERENCE for
  'MPLS using LDP and ATM VC Switching', = draft-ietf-mpls-atm-02.txt.
   (the LDP MIB has updated this and it = would be good if we
   could agree on a single definition for = this TC.)

* IpV6Address -- ref.  = draft-ops-endpoint-mib-07.txt
  Could you use similar IPv6 TCs as = defined
  in the draft-ops-endpoint-mib-07.txt = MIB? 
  e.g. InetAddressIPv6 OCTET STRING = (SIZE(16|20))

*  In the MplsInterfaceConfTable a zero index = for
   mplsInterfaceConfIndex indicates that = this entry
   represents a global label space.  = There can also
   be only one entry in the table which =
   contains a zero value for this index, = correct?

*  Does the 'mplsInterfaceIsLocalLabelSpace' = indicate
   per interface label space only?

   I am confused why you need this object, = it would
   seem that if the value of = mplsInterfaceConfIndex is
   non-zero then this means that it is a = per Interface
   label space, and that the = 'mplsInterfaceIsGlobalLabelSpace'
   would indicate if it is participating = in a global Label Space
   also.

   Could a REFERENCE clause labels which = are considered
   both per interface and per platform be = added to the
   LocalLabelSpace Object?

*  Not sure that I understand the use of the MIN = and MAX
   IN/OUT labels.  How does this = relate to LDP which uses
   an ATM-type interface (and thus has a = bunch of label ranges)?
 
   Are these MIN/MAX values a proper = superset of label ranges
   on a per interface label space?

*  Total and Available Buffer.  What is it = that is supposed
   to be learned from these values? =


* mplsInterfaceAdminStatus and = mplsInterfaceOperStatus
  why are these necessary?  It seems like = ifAdminStatus
  and ifOperStatus should be used for = this.


*  mplsInterfacePerfEntry is said to Augment the =
   mplsInterfaceConfEntry, what happens = for the
   situation when 'mplsInterfaceConfIndex' = is zero?
  
   How are the values in this table = counted when a label
   participates in both the global and = local label spaces?

   Also, it seems that some of these = overlap with
   ifTable (specifically, = mplsInterfaceInPackets,
   mplsInterfaceInDiscards, = mplsInterfaceOutPackets,
   mplsInterfaceOutDiscards), maybe I am = missing something
   here, but on an mplsInterface, I would = assume that the
   ifTable and ifXTable would be counting = Octets and Packets
   which are in essence MPLS Octets and = Packets.

   Could you add in the description = something
   which would differentiate these from = the ifTable and
   ifXTable at the mpls layer?   =

   (Aside:  because the front section = of the document
    includes how to interpret the = ifTable and ifXTable
    objects, I am under the = assumption that these things
    are being counted in those tables = and not here....)

* mplsInSegmentTable has no "IndexNext" = object.
  Could one be added?

* mplsInSegmentIfIndex  type in Sequence doesn't = match
  Object's type.

  Also this should be not-accessible.  = Currently, it is
  read-create.  What is the ifType of this = index? 
  Is this the same as the index used in the = mplsInterfaceConfEntry
  for the label related to this entry?

  Could more description be added to this = index?

* mplsInSegmentAddrFamily needs to use the
  IANA-ADDRESS-FAMILY-NUMBER-MIB's = AddressFamilyNumbers TC.
  Reference is incorrect on this also.

* mplsInSegmentXCIndex description is = incorrect.  A value
  of zero could certainly indicates a valid = cross connect.
  The XC table does model XCs even for = terminating InSegments
  and Originating OutSegments.

  The syntax clause should be changed in either = this
  table or in the XC table since the syntax = should be
  the same in both places.

* mplsInSegmentTSpecIndex -- this object needs to be = made
  optional for LDP.

* mplsInSegmentOwner -- could this be removed from = the
  table. 

  These object are of little value in my opinion = because
  who really cares how the row got = created?

  Also, if you have snmp and policyAgent, then = you should
  add cli, config file, web, etc....

  Just seems to be a big rat hole in my = opinion.

* mplsOutSegmentIndexNext object range should start = at 0 (zero).

* mplsOutSegmentEntry is incorrect and should say = 'outgoing'
  in place of incoming which I think someone = else mentioned
  already.

  Also REF clause should be updated

* mplsOutSegmentIfIndex should be = not-accessible

* mplsOutSegmentPushTopLabel's description is
  somewhat misleading with regard to the = current
  version of LDP.  In the case of LDP = using ATM, the
  idea of a label popping does not apply.  = So it's
  misleading to say, it does not support = pop-and-go.
  It does not support label popping at = all.

  Could you rephrase this section to = specifically
  call out that for Version 1 of LDP using ATM = or FR this should
  be set to true and Reference Section 5. of = the LDP Spec?

* mplsOutSegmentTopLabel
 
  Could this object be changed to contain the = value of
  the top label on egress?  I think it = would be
  much more interesting to point to the egress = label
  especially since the prior object = (mplsOutSegmentPushTopLabel)
  tells whether or not this was pushed.

* mplsOutSegmentNextHopIpAddrType should use = similar
  TC's as defined in = draft-ops-endpoint-mib-07.txt

  Also, I have a question on this = description:  What is
  meant by the outgoing interface being = point-to-point in
  the case of LDP using ATM?

* mplsOutSegmentNextHopIpv4Addr and = mplsOutSegmentNextHopIpv6Addr
  these should be combined, and should also use = the relevant
  TC in draft-ops-endpoint-mib-07.txt

* mplsXCIndexNext object's range should start at = 0.

* INDEX clause and description of the entry:

  The description redefines what a values of = zero means
  for the mplsInSegmentIfIndex and = mplsInSegmentLabel;
  in the mplsInSegmentTable they mean one = thing,
  and yet, they mean something  else in = the XC table. 

  Could this be clarified? 

* mplsXCIndex should be not-accessible

* mplsXCCOS, should this object be made optional = for
  LDP?

* mplsXCIsPersistent should have SYNTAX of = StorageType

* mplsXCOwner same comment as before, big rat hole, = could
  we get rid of this object?

*  What do the AdminStatus and OperStatus = objects mean when
   the LSP is terminating or Originating = for this entry?

--
  
 




------_=_NextPart_001_01BF934E.97E63C66-- From owner-mpls@UU.NET Tue Mar 21 11:21:01 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12503 for ; Tue, 21 Mar 2000 11:21:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmm00096; Tue, 21 Mar 2000 16:13:35 GMT Received: by mail-control.mail.uu.net id QQihmm27757 for mpls-outgoing; Tue, 21 Mar 2000 16:12:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihmm27735 for ; Tue, 21 Mar 2000 16:12:49 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihmm14654 for ; Tue, 21 Mar 2000 11:12:39 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihmm29454 for ; Tue, 21 Mar 2000 16:12:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA05928 for mpls@uu.net; Tue, 21 Mar 2000 11:12:38 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihmm27075 for ; Tue, 21 Mar 2000 16:11:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmm14199 for ; Tue, 21 Mar 2000 11:11:01 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQihmm15528 for ; Tue, 21 Mar 2000 16:11:01 GMT Received: from tnadeau-pc02 (ch2-dhcp134-173.cisco.com [161.44.134.173]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20379; Tue, 21 Mar 2000 11:10:45 -0500 (EST) Message-Id: <4.2.2.20000321105539.06afc510@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 21 Mar 2000 10:59:51 -0500 To: "Atkinson, Stephen" , Adrian Farrel , mpls@UU.NET From: "Thomas D. Nadeau" Subject: RE: draft-ietf-mpls-lsr-mib-02.txt nits Cc: arun@force10networks.com, cheenu@tachion.com, Joan Cucchiara In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2262472==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_2262472==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Stephen, >The LSPID needs to be 6 bytes to handle CR-LDP using IPV4. >Refer to section 4.5 "LSPID TLV" of draft-ietf_mpls-cr-ldp-03.txt. >I believe the same is true for TE-RSVP. Okay. We will make this change, and probably make it 8 bytes just to be safe. I knew that the original, larger value for the octet string albeit big, would have sufficed for all cases. ;) BTW, Joan, should you make this change in the LDP MIB as well to be consistent? You currently have LSP ID defined as: mplsLdpLibLspId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) --Tom > > > > > >[snip] --=====================_2262472==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi Stephen,

        
The LSPID needs to be 6 bytes to handle CR-LDP using IPV4.
Refer to section 4.5 "LSPID TLV" of draft-ietf_mpls-cr-ldp-03.txt.
I believe the same is true for TE-RSVP.

        Okay. We will make this change, and probably make it
8 bytes just to be safe. I knew that the original, larger value
for the octet string albeit big, would have sufficed for
all cases. ;)

        BTW, Joan, should you make this change in the LDP
MIB as well to be consistent? You currently have LSP ID
defined as:

mplsLdpLibLspId  OBJECT-TYPE
         SYNTAX       Unsigned32 (1..4294967295)

        --Tom




>
>

[snip]
--=====================_2262472==_.ALT-- From owner-mpls@UU.NET Tue Mar 21 11:38:55 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19302 for ; Tue, 21 Mar 2000 11:38:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmo16244; Tue, 21 Mar 2000 16:37:49 GMT Received: by mail-control.mail.uu.net id QQihmo00513 for mpls-outgoing; Tue, 21 Mar 2000 16:37:24 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihmo00503 for ; Tue, 21 Mar 2000 16:37:15 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmo18934 for ; Tue, 21 Mar 2000 11:37:03 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQihmo15247 for ; Tue, 21 Mar 2000 16:37:02 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 16:36:42 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E140506@monk.datcon.co.uk> From: Adrian Farrel To: "Thomas D. Nadeau" , "Atkinson, Stephen" , mpls@UU.NET Cc: arun@force10networks.com, cheenu@tachion.com, Joan Cucchiara Subject: RE: draft-ietf-mpls-lsr-mib-02.txt nits Date: Tue, 21 Mar 2000 16:36:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk All, There is some confusion about what an LSPID is. This can be addressed with some suitable text in the MIB definitions. I had assumed that the MIB fields for the LSR MIB and the LDP MIB were referring to the two byte LSPID that can be combined with the source LSRID to uniquely identify the LSP. So, in CR-LDP, the LSP-ID TLV is +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| LSPID-TLV (0x0821) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |ActFlg | Local CR-LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress LSR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and the field we are talking about is CR-LSP ID In RSVP, the Sender Template Object is +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and the field we are talking about is LSP ID In LDP, there is no concept of an LSPID. The value in the MIB is an arbitrary index. This is your call, Tom. If you are trying to include the full identifier of the LSP to give it full uniqueness at this point then you need space for the LSPID (two bytes) and one of - Ingress LSR Router ID (for CR-LDP) 4 bytes - tunnel sender address (for RSVP) sizeof(IP_address) Since RSVP technically has to handle IPv6, the largest size required is 2 + 16 = 18 (even I can do simple math!) I guess this is what you were trying to cover when you set the max to 63 (and told me it allowed scope for an IPv6 address). Sorry, I seem to have led you astray. Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Tue Mar 21 11:51:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23622 for ; Tue, 21 Mar 2000 11:51:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmp28748; Tue, 21 Mar 2000 16:50:59 GMT Received: by mail-control.mail.uu.net id QQihmp01497 for mpls-outgoing; Tue, 21 Mar 2000 16:50:40 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihmp01487 for ; Tue, 21 Mar 2000 16:50:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihmp03616 for ; Tue, 21 Mar 2000 11:50:06 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQihmp27866 for ; Tue, 21 Mar 2000 16:50:05 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Tue, 21 Mar 2000 11:49:52 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CF63@email.quarrytech.com> From: "Abes, Andi" To: Vijay Srinivasan , mpls@UU.NET Subject: RE: LSR MIB last call Date: Tue, 21 Mar 2000 11:49:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I think this has been mentioned before, but what support, if any is there for configuring and representing Diff Serv capable LSP's ? The only mention I found is the XCCos, which doesn't seem to be enough. I would expect the MIB to be capable of the following: - Connect an InSegment to (eventually) an Output Segment based both on Input IF, input Label and incoming EXP (COS) bits Preferably the inSegment would select the XC based on label, and then the XC would select a specific output segment based on EXP. ( this is meant to allow conversion between incoming E-LSP's to outgoing L-LSP's as would be needed in an LSR with both Ethernet and LC-ATM interfaces for example) - Allow a mapping between incoming EXP to outgoing EXP, not just a global replacement (as is provided by XCCos). This could be accomplished together with the previous point by indexing the XC table with EXP as well. For LSP's created by LDP, a single value of 0 could be used. - For output segments, specify their type (E/L-LSP's), and PHBID of the OA carried over them. This is my understanding of some of the requirements for supporting Diff Serv LSP's. The Diff Serv over MPLS authors could have better/greater/finer comments to add to this. Have they been consulted on the issue ? I remeber Adrian mentioning this before Andi. -----Original Message----- From: Vijay Srinivasan [mailto:vsriniva@cosinecom.com] Sent: Tuesday, March 21, 2000 11:01 AM To: 'Joan Cucchiara'; 'tnadeau@cisco.com'; 'arun@force10networks.com'; 'cheenu@tachion.com' Cc: 'mpls@uu.net' Subject: LSR MIB last call The authors of the LSR MIB have requested that we progress the document to WG last call. I would like to commence the last call, ending in two weeks (due to the IETF in between). Joan's comments to the list will be considered as part of the last call. - Vijay -----Original Message----- From: Joan Cucchiara [ mailto:JCucchiara@Brixnet.com ] Sent: Tuesday, March 21, 2000 6:38 AM To: 'tnadeau@cisco.com'; 'arun@force10networks.com'; 'cheenu@tachion.com' Cc: 'mpls@uu.net' Subject: LSR MIB comments and questions Hi Tom, Arun and Cheenu, I have read over most of the LSR MIB as you requested and as you probably expect, have some comments and questions. -Joan Editorial --------- * needs a table of contents * would be nice to have a revisions section to track changes between versions, since this has already been done on the email list, adding it to the document should be trivial. * It seems that many tables in this MIB were gleaned from the ATM MIB, specifically the mplsInterfaceConfTable and the Cross Connect Tables. Could you add a reference to the ATM MIB in the Reference Section? General MIB Comments -------------------- * InterfaceIndex: understanding which InterfaceIndex is being used is sometimes unclear. Since this MIB handles all MPLS protocols, the use of which InterfaceIndex and its corresponding ifType and thus an indication of where it would appear in the ifStackTable should be clear, especially because many objects such as InPacket, InDiscards, AdminStatus, OperStatus, etc seem to me to potentially overlap with what is in the ifTable and ifXTable for ifType mpls. More description upfront would help with this. * StorageType objects need to be added throughout various tables. FRONT SECTION ------------- * Sections 8.0 'Application of the Interface Group to MPLS' and 8.1 'Suport of the MPLS Layer by ifTable' "...Thus, the MPLS layer interface is represented as an entry in the ifTable. This entry is concerned with the MPLS layer as a whole, and not with individual LSPs/tunnels which are managed via the MPLS-specific managed objects specified in this memo and in [TEMIB]." I am confused by these statements. There is as of yet, no concept of an MPLS Layer other than as outlined in the architecture specification which talks about a shim layer. Is this the mpls shim layer (i.e. the layer where label stacking takes place) or something else? MIB --- * Revision history is incorrect. The initial revision in June 1999. * ifIndex is not a textual convention * Last Updated clause is incorrect. The last update should match the latest revision date and these do not match. * MplsLsrIANAAddrFamily needs to be removed. The AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB should be imported. See RFC2677 or LDP MIB. * MplsLabel needs to be updated to reflect the FRF decision to drop 17-bit DLCI support. Also, missing REFERENCE for 'MPLS using LDP and ATM VC Switching', draft-ietf-mpls-atm-02.txt. (the LDP MIB has updated this and it would be good if we could agree on a single definition for this TC.) * IpV6Address -- ref. draft-ops-endpoint-mib-07.txt Could you use similar IPv6 TCs as defined in the draft-ops-endpoint-mib-07.txt MIB? e.g. InetAddressIPv6 OCTET STRING (SIZE(16|20)) * In the MplsInterfaceConfTable a zero index for mplsInterfaceConfIndex indicates that this entry represents a global label space. There can also be only one entry in the table which contains a zero value for this index, correct? * Does the 'mplsInterfaceIsLocalLabelSpace' indicate per interface label space only? I am confused why you need this object, it would seem that if the value of mplsInterfaceConfIndex is non-zero then this means that it is a per Interface label space, and that the 'mplsInterfaceIsGlobalLabelSpace' would indicate if it is participating in a global Label Space also. Could a REFERENCE clause labels which are considered both per interface and per platform be added to the LocalLabelSpace Object? * Not sure that I understand the use of the MIN and MAX IN/OUT labels. How does this relate to LDP which uses an ATM-type interface (and thus has a bunch of label ranges)? Are these MIN/MAX values a proper superset of label ranges on a per interface label space? * Total and Available Buffer. What is it that is supposed to be learned from these values? * mplsInterfaceAdminStatus and mplsInterfaceOperStatus why are these necessary? It seems like ifAdminStatus and ifOperStatus should be used for this. * mplsInterfacePerfEntry is said to Augment the mplsInterfaceConfEntry, what happens for the situation when 'mplsInterfaceConfIndex' is zero? How are the values in this table counted when a label participates in both the global and local label spaces? Also, it seems that some of these overlap with ifTable (specifically, mplsInterfaceInPackets, mplsInterfaceInDiscards, mplsInterfaceOutPackets, mplsInterfaceOutDiscards), maybe I am missing something here, but on an mplsInterface, I would assume that the ifTable and ifXTable would be counting Octets and Packets which are in essence MPLS Octets and Packets. Could you add in the description something which would differentiate these from the ifTable and ifXTable at the mpls layer? (Aside: because the front section of the document includes how to interpret the ifTable and ifXTable objects, I am under the assumption that these things are being counted in those tables and not here....) * mplsInSegmentTable has no "IndexNext" object. Could one be added? * mplsInSegmentIfIndex type in Sequence doesn't match Object's type. Also this should be not-accessible. Currently, it is read-create. What is the ifType of this index? Is this the same as the index used in the mplsInterfaceConfEntry for the label related to this entry? Could more description be added to this index? * mplsInSegmentAddrFamily needs to use the IANA-ADDRESS-FAMILY-NUMBER-MIB's AddressFamilyNumbers TC. Reference is incorrect on this also. * mplsInSegmentXCIndex description is incorrect. A value of zero could certainly indicates a valid cross connect. The XC table does model XCs even for terminating InSegments and Originating OutSegments. The syntax clause should be changed in either this table or in the XC table since the syntax should be the same in both places. * mplsInSegmentTSpecIndex -- this object needs to be made optional for LDP. * mplsInSegmentOwner -- could this be removed from the table. These object are of little value in my opinion because who really cares how the row got created? Also, if you have snmp and policyAgent, then you should add cli, config file, web, etc.... Just seems to be a big rat hole in my opinion. * mplsOutSegmentIndexNext object range should start at 0 (zero). * mplsOutSegmentEntry is incorrect and should say 'outgoing' in place of incoming which I think someone else mentioned already. Also REF clause should be updated * mplsOutSegmentIfIndex should be not-accessible * mplsOutSegmentPushTopLabel's description is somewhat misleading with regard to the current version of LDP. In the case of LDP using ATM, the idea of a label popping does not apply. So it's misleading to say, it does not support pop-and-go. It does not support label popping at all. Could you rephrase this section to specifically call out that for Version 1 of LDP using ATM or FR this should be set to true and Reference Section 5. of the LDP Spec? * mplsOutSegmentTopLabel Could this object be changed to contain the value of the top label on egress? I think it would be much more interesting to point to the egress label especially since the prior object (mplsOutSegmentPushTopLabel) tells whether or not this was pushed. * mplsOutSegmentNextHopIpAddrType should use similar TC's as defined in draft-ops-endpoint-mib-07.txt Also, I have a question on this description: What is meant by the outgoing interface being point-to-point in the case of LDP using ATM? * mplsOutSegmentNextHopIpv4Addr and mplsOutSegmentNextHopIpv6Addr these should be combined, and should also use the relevant TC in draft-ops-endpoint-mib-07.txt * mplsXCIndexNext object's range should start at 0. * INDEX clause and description of the entry: The description redefines what a values of zero means for the mplsInSegmentIfIndex and mplsInSegmentLabel; in the mplsInSegmentTable they mean one thing, and yet, they mean something else in the XC table. Could this be clarified? * mplsXCIndex should be not-accessible * mplsXCCOS, should this object be made optional for LDP? * mplsXCIsPersistent should have SYNTAX of StorageType * mplsXCOwner same comment as before, big rat hole, could we get rid of this object? * What do the AdminStatus and OperStatus objects mean when the LSP is terminating or Originating for this entry? -- From owner-mpls@UU.NET Tue Mar 21 12:50:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15280 for ; Tue, 21 Mar 2000 12:50:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihmt23270; Tue, 21 Mar 2000 17:48:05 GMT Received: by mail-control.mail.uu.net id QQihmt14658 for mpls-outgoing; Tue, 21 Mar 2000 17:47:40 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihmt14653 for ; Tue, 21 Mar 2000 17:47:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihmt29402 for ; Tue, 21 Mar 2000 12:47:38 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQihmt22609 for ; Tue, 21 Mar 2000 17:47:37 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Tue, 21 Mar 2000 12:47:24 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CF64@email.quarrytech.com> From: "Abes, Andi" To: Vijay Srinivasan , mpls@UU.NET Subject: RE: LSR MIB last call Date: Tue, 21 Mar 2000 12:47:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Opps... I didn't notice Adrian's mail, and the response from Tom. In any case, if Diff Serv is to be added later, can we rid of the XCCos, which is not enough for Diff Serv support and might generate (or has already done so) confusion ? Andi. > -----Original Message----- > From: Abes, Andi [mailto:aabes@quarrytech.com] > Sent: Tuesday, March 21, 2000 11:50 AM > To: Vijay Srinivasan; mpls@UU.NET > Subject: RE: LSR MIB last call > > > I think this has been mentioned before, > but what support, if any is there for configuring and > representing Diff Serv capable LSP's ? > > The only mention I found is the XCCos, which > doesn't seem to be enough. > > I would expect the MIB to be capable of the following: > - Connect an InSegment to (eventually) an Output Segment > based both on Input IF, input Label and incoming EXP (COS) bits > > Preferably the inSegment would select the XC based on > label, and then > the XC would select a specific output segment based on EXP. > ( this is meant to allow conversion between incoming > E-LSP's to outgoing > L-LSP's as would be needed in an LSR with both Ethernet and LC-ATM > interfaces > for example) > > - Allow a mapping between incoming EXP to outgoing EXP, not > just a global > replacement (as is provided by XCCos). This could be > accomplished together > with > the previous point by indexing the XC table with EXP as > well. For LSP's > created by LDP, > a single value of 0 could be used. > > - For output segments, specify their type (E/L-LSP's), and > PHBID of the OA > carried over them. > > > This is my understanding of some of the requirements for > supporting Diff > Serv LSP's. > The Diff Serv over MPLS authors could have > better/greater/finer comments to > add to > this. > Have they been consulted on the issue ? I remeber Adrian > mentioning this > before > > Andi. > > > > > > > > > -----Original Message----- > From: Vijay Srinivasan [mailto:vsriniva@cosinecom.com] > Sent: Tuesday, March 21, 2000 11:01 AM > To: 'Joan Cucchiara'; 'tnadeau@cisco.com'; 'arun@force10networks.com'; > 'cheenu@tachion.com' > Cc: 'mpls@uu.net' > Subject: LSR MIB last call > > > > > The authors of the LSR MIB have requested that we progress > the document to > WG last call. I would like to commence the last call, ending > in two weeks > (due to the IETF in between). Joan's comments to the list will be > considered as part of the last call. > > - Vijay > From owner-mpls@UU.NET Tue Mar 21 15:28:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17319 for ; Tue, 21 Mar 2000 15:28:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihnd08296; Tue, 21 Mar 2000 20:27:16 GMT Received: by mail-control.mail.uu.net id QQihnd19082 for mpls-outgoing; Tue, 21 Mar 2000 20:26:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihnd19077 for ; Tue, 21 Mar 2000 20:26:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihnd23009 for ; Tue, 21 Mar 2000 15:26:23 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihnd07590 for ; Tue, 21 Mar 2000 20:26:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA16217 for mpls@uu.net; Tue, 21 Mar 2000 15:26:21 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihnd18972 for ; Tue, 21 Mar 2000 20:25:51 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihnd06032 for ; Tue, 21 Mar 2000 15:25:31 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQihnd25651 for ; Tue, 21 Mar 2000 20:25:31 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA07217; Tue, 21 Mar 2000 12:25:26 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 12:25:27 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4045C@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Zheng Wang'" , mpls@UU.NET Subject: RE: question on draft-ietf-mpls-label-encaps-07.txt Date: Tue, 21 Mar 2000 12:22:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, The incoming label is used to determine the next hop. This is called Penultimate Hop Popping (PHP). -Shahram >-----Original Message----- >From: Zheng Wang [mailto:zhwang@dnrc.bell-labs.com] >Sent: Monday, March 20, 2000 3:50 PM >To: mpls@UU.NET >Subject: question on draft-ietf-mpls-label-encaps-07.txt > > >I dont know if someone has raised this question or not. >The label value 3 is reserved for Implicit NULL Label. >The draft says: > > iv. A value of 3 represents the "Implicit NULL Label". > This is a label that an LSR may assign and distribute, > but which never actually appears in the encapsulation. > When an LSR would otherwise replace the label at the > top of the stack with a new label, but the >new label is > "Implicit NULL", the LSR will pop the stack instead of > doing the replacement. Although this value may never > appear in the encapsulation, it needs to be specified > in the Label Distribution Protocol, so a value is > reserved. > >My question is which label is used to determine the next hop in this >case, the imcoming label or the new top label after the popping of the >stack? > >Thanks in advance >Cheers >Zheng > From owner-mpls@UU.NET Tue Mar 21 15:36:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19877 for ; Tue, 21 Mar 2000 15:36:04 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihne04912; Tue, 21 Mar 2000 20:35:29 GMT Received: by mail-control.mail.uu.net id QQihne19561 for mpls-outgoing; Tue, 21 Mar 2000 20:35:07 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihne19554 for ; Tue, 21 Mar 2000 20:35:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihne24316 for ; Tue, 21 Mar 2000 15:34:48 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihne13324 for ; Tue, 21 Mar 2000 20:34:42 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA17611 for mpls@uu.net; Tue, 21 Mar 2000 15:34:42 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihne19512 for ; Tue, 21 Mar 2000 20:34:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihne07364 for ; Tue, 21 Mar 2000 15:34:05 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQihne03509 for ; Tue, 21 Mar 2000 20:34:05 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA20120 for ; Tue, 21 Mar 2000 15:34:03 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA19833 for ; Tue, 21 Mar 2000 15:34:02 -0500 (EST) Message-Id: <200003212034.PAA19833@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Draft MPLS Agenda Date: Tue, 21 Mar 2000 15:34:02 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Folks - We got some relief due to the fact that IPO will be meeting before us and a number of drafts will be presented there. The agenda remains crowded. Most talks at 13 minutes. Please plan a 10 minute talk and 3 mins for discussion. There's no fluff in the agenda so the chairs will be enforcing time strictly. Presenter Topic Time Monday 7:30 - 10:00 Agenda & WG Status 5 Kompella draft-kompella-mpls-optical-00.txt 13 Lang draft-lang-mpls-rsvp-oxc-00.txt 13 Saha draft-saha-rsvp-optical-signaling-00.txt 13 Fan draft-fan-mpls-lambda-signaling-00.txt 13 Rajagopalan draft-tang-crldp-optical-00.txt 13 Bernstein draft-bernstein-mpls-sonet-00.txt 13 Mannie draft-mannie-mpls-sdh-control-00.txt 13 Kompella draft-kompella-mpls-bundle-00.txt 13 Lang draft-lang-mpls-lmp-00.txt 13 Discussion of organizing optical work 15 Ravikanth draft-vaananen-mpls-svc-diff-framework- 13 Wednesday 9:00 - 11:30 Davari draft-ietf-mpls-diff-ext-05.txt 13 Makam draft-makam-mpls-recovery-frmwrk-00.txt 13 Huang draft-chang-mpls-path-protection-00.txt 13 Matthews draft-farrel-mpls-ldp-ft-00.txt 10 draft-matthews-mpls-ldp-ibb-00.txt Kankkunen draft-kankkunen-vompls-fw-00.txt 2 Berger draft-berger-mpls-hdr-comp-00.txt 13 Swallow draft-swallow-mpls-simple-hdr-compress- 13 Heinanen draft-heinanen-mpls-splsp-00.txt 13 Iwata draft-fujita-mpls-crldp-crankback-00.txt 13 Wright draft-wright-policy-mpls-00.txt 13 Schrijver draft-schrijvp-mpls-ldp-end-to-end-auth- 13 Sumimoto draft-sumimoto-mpls-vpn-interworking- 13 Last calls, charter discussion 8 ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Mar 21 17:01:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20940 for ; Tue, 21 Mar 2000 17:01:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihnk02580; Tue, 21 Mar 2000 22:01:14 GMT Received: by mail-control.mail.uu.net id QQihnk05572 for mpls-outgoing; Tue, 21 Mar 2000 22:00:49 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihnk05406 for ; Tue, 21 Mar 2000 22:00:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihnk07616 for ; Tue, 21 Mar 2000 17:00:15 -0500 (EST) Received: from mailgate.fore.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQihnk06893 for ; Tue, 21 Mar 2000 22:00:15 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA28617; Tue, 21 Mar 2000 17:00:12 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA29259; Tue, 21 Mar 2000 17:00:14 -0500 (EST) Message-ID: <38D7F0F0.26E46FA4@fore.com> Date: Tue, 21 Mar 2000 17:00:16 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@isi.edu, mpls@UU.NET Subject: Semantics of shared reservations (with RSVP) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I've got a question about how shared (SE) style reservations get propagated in the RSVP/MPLS world. In a simple multipoint-to-point scenario with shared resources: H1 ---- R1 \ R3 ---- R4 --- H3 / H2 ---- R2 H3 should will send out a Resv mesage to R4. The flow descriptor of this Resv will look like: FLOWSPEC FILTERSPEC (for H1) FILTERSHEC (for H2) R3, when sending out its Resv messages, will break up this flow descriptor, and will send out FLOWSPEC FILTERSPEC (for H1) to R1, and FLOWSPEC FILTERSPEC (for H2) to R2. Right? OK. The problem shows up when H1 and H2 are two different tunnel endpoints on the same physical box. This can happen in the MPLS world if an ingress router is signalling multiple redundant (failover) paths to a single destination. For instance: R2 ---- R3 / \ H1 ---- R1 R6 ---- R7 ---- H2 \ / R4 ---- R5 H1 sends out two Path messages (with different explicit route objects) to H2. H2 sends out a Resv message indicating that the two "senders" (indicated by different tunnel IDs) are to use shared resources. The flow descriptor looks something like: FLOWSPEC FILTERSPEC (for tunnel 1) FILTERSPEC (for tunnel 2) R6, when receiving this, breaks the flow descriptor up for the two paths, sending out FLOWSPEC FILTERSPEC (for tunnel 1) to R3, and FLOWSPEC FILTERSPEC (for tunnel 2) to R5. This works great until those two Resv messages both arrive at R1. How does R1 know that these two tunnels are supposed to be sharing resources. Normally, a router would know this from the multiple filterspecs in a single flow-descriptor, but R1 doesn't see this. It receives two separate Resv messages from two different next-hop nodes. I suppose R6 could send both filterspecs to both PHOPs, but R3 and R5 could (probably would) reject those Resv messages, wouldn't they? After all, those two routers each only processed one of the two Path messages - they don't know about the other one. For that matter, how does H1 tell H2 that these two paths are supposed to be sharing resources? Must it be configured across the network? So, am I missing something here? Is this an as-yet-unsolved problem with RSVP and MPLS? -- David From owner-mpls@UU.NET Tue Mar 21 17:07:36 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22786 for ; Tue, 21 Mar 2000 17:07:35 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihnk12678; Tue, 21 Mar 2000 22:07:01 GMT Received: by mail-control.mail.uu.net id QQihnk11473 for mpls-outgoing; Tue, 21 Mar 2000 22:06:29 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihnk11407 for ; Tue, 21 Mar 2000 22:06:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihnk21714 for ; Tue, 21 Mar 2000 17:05:57 -0500 (EST) Received: from angateway.acceleratednetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: angateway.acceleratednetworks.com [199.107.109.10]) id QQihnk07151 for ; Tue, 21 Mar 2000 22:05:56 GMT Received: from calvin.acceleratednetworks.com (calvin.acceleratednetworks.com [199.107.109.14]) by angateway.acceleratednetworks.com (8.8.8/8.8.8) with ESMTP id OAA00466 for ; Tue, 21 Mar 2000 14:04:49 -0800 (PST) Received: from SWINDIA1 ([10.5.0.160]) by calvin.acceleratednetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HA3Z7D2S; Tue, 21 Mar 2000 14:02:09 -0800 From: "Sumit Garg" To: Subject: RE: LDP MIB last call Date: Tue, 21 Mar 2000 14:02:07 -0800 Message-ID: <3F8D04F09827D311BCE800508B2C4C2D8285A4@calvin.acceleratednetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <38D78FAC.2B03DCBE@etx.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Hans, > That is the value mentioned if you study the LDP spec. That is a value > that should be considered safe for all implementations, i.e > low value. > > The value that is set to default in the mib is going to be the initial > value for the negotiation. And that negotiation can only take > the value > down, so it should be a high value. > > thats the reasoning behind > > > Max PDU lenth is really implementation specific. But I > see no reason to > > > have any other default value than maximum? > > On the other hand, what LDP PDU is bigger than 4096? Not many. And TCP > will handle the fragmentation. So I could go for 4096 if you > could give > a reason? Well, if I recall the draft correctly - one LDP PDU can be multiple LDP messages; so I see the 4096 limit being hit easily ... Regards Sumit From owner-mpls@UU.NET Tue Mar 21 17:32:11 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01515 for ; Tue, 21 Mar 2000 17:32:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihnm00503; Tue, 21 Mar 2000 22:31:46 GMT Received: by mail-control.mail.uu.net id QQihnm13653 for mpls-outgoing; Tue, 21 Mar 2000 22:31:28 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihnm13648 for ; Tue, 21 Mar 2000 22:31:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihnm25250 for ; Tue, 21 Mar 2000 17:31:03 -0500 (EST) Received: from lumen.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: magic03.kudonet.com [209.133.127.227]) id QQihnm02568 for ; Tue, 21 Mar 2000 22:31:03 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id ; Tue, 21 Mar 2000 14:33:41 -0800 Message-ID: From: John Drake To: "'Peter Ashwood-Smith'" , mpls@UU.NET Subject: RE: Optical IP activities Date: Tue, 21 Mar 2000 14:33:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Peter, I'm just going through my e-mail and I thought you note was very good. What we are proposing in draft-ceuppens-mpls-optical-00.txt is a different approach to information hiding. Rather than taking the overlay model approach and hiding all of the optical specific stuff (a non-pejorative term) inside a network cloud, we would hide the optical stuff within the representation of an individual IP links. This would still allow you to support the overlay model, but it also allows you to support the peer model. Thanks, John -----Original Message----- From: Peter Ashwood-Smith [mailto:petera@nortelnetworks.com] Sent: Friday, March 17, 2000 1:15 PM To: mpls@UU.NET Subject: Re: Optical IP activities > I believe the point was different. Whatever you do (a version of RSVP > or CRLDP), whether you are essentially catering to a different set of > requirements inside an optical network. In that regard, you may not > only want to add "extensions", but may also find that you're either not > using "standard" features or finding out some features to be > inappropriate. What has happened is a general realization that no matter what we switch on, be it spacecial (fiber), time (TDM), frequency(lambda) or shim (statistical), the requirements on the signalling and routing protocols are VERY similar with variations caused by certain physical properties of each switching mechanism. These variations are probably not sufficient to warrant completely independent protocols. About the most serious of these differences is the merge/non merge ability and even that existed in the statistical (ATM) domain. As a result we are in the process of rationalizing and distilling out what the common properties are of all of these mechanisms and trying to build a common mechanism to deal with them all. We may or may not succeed however since we rarely all agree on anything. > Not quite. There are specific operational procedures inside an optical > network and the question is how much of this must be characterised > to the outside world. For example, should a router know about wavelength > conversion limitations? Wavelength conversion limitations can be abstracted into constraints we already deal with in existing constraint based routing systems like ATM/PORS. For example, maximum reach is similar to maximum acceptable delay. If we can find generic ways to express the constraints that optics imposes a generic constraint based routing system should be able to deal with the problems. Besides, the constraints imposed by current optical technologies are being stretched every day. Reach, for example, gets longer and longer every year and may one day be a non issue. Even constraints like the desire to limit the number of wavelength conversions to a minimum to reduce distortion/chirp, or even to reduce to a single wavelength for equipement that cannot do a conversion, can be expressed in abstract forms such as a label set, as in the draft-yanhe or a suggested label as in the lang draft. Are these specific to the optical domain? Probably, although one can see the immediate benefits of a fixed shim label for a span of hops since it reduces read/write operations and hence would improve forwarding performance in the statistically multiplexed domain. > > > > Abstraction in general is not good for traffice engineering. The further > > you get from knowing exactly how much bandwidth you have and where it is > > the worse the job of computing, establishing and laying down routes you > > can do. The more accurately the topology database reflects exactly the > > resources you have to allocate, the more accurate a job you can do of > > engineering your network. > > The question is, whether in practice you would engineer paths across > two different networks (IP and optical) or do the engineering (and > capacity planning) in each network. I argue that given the choice you would pick one network since a single level global/distributed optimal placement problem is "easier" to solve than a two level global/optimal placement problem. Actually I think the two level problem is unsolvable because it lacks exact data at the second level. A fact I'm sure many operators of existing overlay networks will attest to. Cheers, Peter From owner-mpls@UU.NET Tue Mar 21 17:51:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08681 for ; Tue, 21 Mar 2000 17:51:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihnn20954; Tue, 21 Mar 2000 22:50:49 GMT Received: by mail-control.mail.uu.net id QQihnn14513 for mpls-outgoing; Tue, 21 Mar 2000 22:50:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihnn14507 for ; Tue, 21 Mar 2000 22:50:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihnn14340 for ; Tue, 21 Mar 2000 17:50:03 -0500 (EST) Received: from mailgate.fore.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQihnn19826 for ; Tue, 21 Mar 2000 22:49:58 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA03339; Tue, 21 Mar 2000 17:49:55 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA08639; Tue, 21 Mar 2000 17:49:57 -0500 (EST) Message-ID: <38D7FC97.3572C0B6@fore.com> Date: Tue, 21 Mar 2000 17:49:59 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Jayesh V Shah CC: rsvp@isi.edu, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <38D7F0F0.26E46FA4@fore.com> <38D7F9E9.EB386B21@globespan.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jayesh V Shah wrote: >> >> I've got a question about how shared (SE) style reservations get >> propagated in the RSVP/MPLS world. >> >> In a simple multipoint-to-point scenario with shared resources: >> >> H1 ---- R1 >> \ >> R3 ---- R4 --- H3 >> / >> H2 ---- R2 >> >> H3 should will send out a Resv mesage to R4. The flow descriptor of >> this Resv will look like: >> >> FLOWSPEC >> FILTERSPEC (for H1) >> FILTERSHEC (for H2) >> >> R3, when sending out its Resv messages, will break up this flow >> descriptor, and will send out >> >> FLOWSPEC >> FILTERSPEC (for H1) >> >> to R1, and >> >> FLOWSPEC >> FILTERSPEC (for H2) >> >> to R2. >> >> Right? >> >> OK. The problem shows up when H1 and H2 are two different tunnel >> endpoints on the same physical box. This can happen in the MPLS >> world if an ingress router is signalling multiple redundant >> (failover) paths to a single destination. For instance: >> >> R2 ---- R3 >> / \ >> H1 ---- R1 R6 ---- R7 ---- H2 >> \ / >> R4 ---- R5 >> >> H1 sends out two Path messages (with different explicit route >> objects) to H2. >> >> H2 sends out a Resv message indicating that the two "senders" >> (indicated by different tunnel IDs) are to use shared resources. The >> flow descriptor looks something like: >> >> FLOWSPEC >> FILTERSPEC (for tunnel 1) >> FILTERSPEC (for tunnel 2) > > The senders will be distinguished by different Sender Address and/or > LSP Id in the Sender Template, and not the tunnel Id, which by virtue > of being a part of session, has to be same for both the flows, to > allow the shared explicit reservation, we are talking about here. Yes. But if H2 is going to issue a shared reservation for the two, it must specify filterspecs for both senders in the same Resv object. If it doesn't then it is signalling two separate resource-sharing groups. >> R6, when receiving this, breaks the flow descriptor up for the two >> paths, sending out >> >> FLOWSPEC >> FILTERSPEC (for tunnel 1) >> >> to R3, and >> >> FLOWSPEC >> FILTERSPEC (for tunnel 2) >> >> to R5. >> >> This works great until those two Resv messages both arrive at R1. >> >> How does R1 know that these two tunnels are supposed to be sharing >> resources. Normally, a router would know this from the multiple >> filterspecs in a single flow-descriptor, but R1 doesn't see this. It >> receives two separate Resv messages from two different next-hop >> nodes. > > R1 knows that it needs to share resources among the two flows, because > they belong to the same session (the session object is the same). No. This is SE style, not WF. In WF style, all senders in a single session share the same resources. In SE, the senders that share resources must be explicitly specified. If a switch assumes sharing when this specification is not present, it is in error. The recipient (H2) knows this and will explicitly state the sharing in its flow-descriptor list (one flow descriptor containing two flowspecs and two labels.) The problem is that this information is lost after the flow descriptors are broken up at R6. >> I suppose R6 could send both filterspecs to both PHOPs, but R3 and R5 >> could (probably would) reject those Resv messages, wouldn't they? >> After all, those two routers each only processed one of the two Path >> messages - they don't know about the other one. >> >> For that matter, how does H1 tell H2 that these two paths are >> supposed to be sharing resources? Must it be configured across the >> network? >> >> So, am I missing something here? Is this an as-yet-unsolved problem >> with RSVP and MPLS? > > I hope it is clear. > > Regards, > Jayesh From owner-mpls@UU.NET Tue Mar 21 18:23:35 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19952 for ; Tue, 21 Mar 2000 18:23:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihnp06090; Tue, 21 Mar 2000 23:22:20 GMT Received: by mail-control.mail.uu.net id QQihnp24398 for mpls-outgoing; Tue, 21 Mar 2000 23:22:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihnp24391 for ; Tue, 21 Mar 2000 23:21:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihnp01906 for ; Tue, 21 Mar 2000 18:21:52 -0500 (EST) Received: from PMESMTP01.wcom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pmesmtp01.wcom.com [199.249.20.1]) id QQihnp23990 for ; Tue, 21 Mar 2000 23:21:52 GMT Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FRS00MACOWG0Z@firewall.mcit.com> for mpls@UU.NET; Tue, 21 Mar 2000 23:21:52 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FRS00301OWFX5@dgismtp02.wcomnet.com>; Tue, 21 Mar 2000 23:21:51 +0000 (GMT) Received: from omta4.mcit.com ([166.37.204.6]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FRS001GPOWFHY@dgismtp02.wcomnet.com>; Tue, 21 Mar 2000 23:21:51 +0000 (GMT) Received: from pc9910023938 ([166.35.117.136]) by omta4.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000321232409.DYYW26739@pc9910023938>; Tue, 21 Mar 2000 23:24:09 +0000 Date: Tue, 21 Mar 2000 17:20:56 -0600 From: Lee Thomas Subject: RE: Comments on draft-ip-optical-framework-00.txt In-reply-to: <38D75E81.82ED9102@ieee.org> To: "'Khaled Elsayed'" Cc: mpls@UU.NET Reply-to: lee.thomas@wcom.com Message-id: <002201bf938c$1d2790e0$887523a6@pc9910023938.wcom.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Peter Ashwood-Smith wrote: > You may waste enormous amounts of bandwidth if you cannot do > wavelength conversion. Convert the question to the ATM domain and > imagine how an ATM network would operate if you had to use the > same VCC from end to end. Basically, if you do not have the ability > to change "labels" then you need one label for EVERY unique path > through the network. Given that the number of paths through a network > grows what .. N factorial? You run out of labels very quickly. This is > especially true with DWDM equipement which may only support 50-100 "labels". > This means that a tiny network would exhaust all the labels/paths > AND you have many links that you can only use a small percentage of > the available "labels" ie bandwidth. So its a very unsatisfactory > solution. Also, to do a good job of it, you need a global view of > each path and label it will use. > I am not questioning the usefulness of wavelength conversion. It is definitely a good mechansim. (Although I have seen some research work that claims that wavelenght conversion may not be worthwhile in some scenarios). Khaled, Could you provide links to some of this research or describe some scenarios where wavelength conversion may not be worthwhile? Thanks, Lee From owner-mpls@UU.NET Tue Mar 21 18:31:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23563 for ; Tue, 21 Mar 2000 18:31:56 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihnq12048; Tue, 21 Mar 2000 23:31:36 GMT Received: by mail-control.mail.uu.net id QQihnq24899 for mpls-outgoing; Tue, 21 Mar 2000 23:31:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihnq24850 for ; Tue, 21 Mar 2000 23:31:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihnq19405 for ; Tue, 21 Mar 2000 18:30:48 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQihnq11400 for ; Tue, 21 Mar 2000 23:30:48 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Tue, 21 Mar 2000 18:30:35 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CF68@email.quarrytech.com> From: "Abes, Andi" To: David Charlap , Jayesh V Shah Cc: mpls@UU.NET Subject: RE: Semantics of shared reservations (with RSVP) Date: Tue, 21 Mar 2000 18:30:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The following is quoted from RFC2209 - processing rules, Page 10. (I'll first paraphrase for the short of breath - when a resv message arrives, you scan the list of all the Path State blocks for a matching FilterSpec. If any is found, that's not in error, you add the PHop for that Path state to the list of PHop's that need to be updated with the new Resv). Process the flow descriptor list to make reservations, as follows, depending upon the style. The following uses a filter spec list struct Filtss of type FILTER_SPEC* (defined earlier). For FF style: execute the following steps independently for each flow descriptor in the message, i.e., for each (FLOWSPEC, Filtss) pair. Here the structure Filtss consists of the FILTER_SPEC from the flow descriptor. For SE style, execute the following steps once for (FLOWSPEC, Filtss), with Filtss consisting of the list of FILTER_SPEC objects from the flow descriptor. For WF style, execute the following steps once for (FLOWSPEC, Filtss), with Filtss an empty list. o Check the path state, as follows. 1. Locate the set of PSBs (senders) that route to OI and whose SENDER_TEMPLATEs match a FILTER_SPEC in Filtss. If this set is empty, build and send an error message specifying "No sender information", and continue with the next flow descriptor in the RESV message. 2. If the style has explicit sender selection (e.g., FF or SE) and if any FILTER_SPEC included in Filtss matches more than one PSB, build and send a RERR message specifying "Ambiguous filter spec" and continue with the next flow descriptor in the RESV message. 3. If the style is SE and if some FILTER_SPEC included in Filtss matches no PSB, delete that FILTER_SPEC from Filtss. 4. Add the PHOP from the PSB to Refresh_PHOP_list, if the PHOP is not already on the list. (end of qoute) Thus what will happened with both Resv messages (as split by R6) is almost the same - one will match the first LSP and the other the second. Such that both Resv messages will end up being sent upstream (Most likely, after the initial RSB has been setup, it will only be updated periodically, and the 2 might end up being combined). At R1, by your diagram, this however is meaningless, since the 2 LSP's do not share the same outgoing interface, and can not share the same reservation (at least on the output side). H1 will have to have the smarts. > -----Original Message----- > From: David Charlap [mailto:dcharlap@fore.com] > Sent: Tuesday, March 21, 2000 5:50 PM > To: Jayesh V Shah > Cc: rsvp@isi.edu; mpls@UU.NET > Subject: Re: Semantics of shared reservations (with RSVP) > > > Jayesh V Shah wrote: > >> > >> I've got a question about how shared (SE) style reservations get > >> propagated in the RSVP/MPLS world. > >> > >> In a simple multipoint-to-point scenario with shared resources: > >> > >> H1 ---- R1 > >> \ > >> R3 ---- R4 --- H3 > >> / > >> H2 ---- R2 > >> > >> H3 should will send out a Resv mesage to R4. The flow > descriptor of > >> this Resv will look like: > >> > >> FLOWSPEC > >> FILTERSPEC (for H1) > >> FILTERSHEC (for H2) > >> > >> R3, when sending out its Resv messages, will break up this flow > >> descriptor, and will send out > >> > >> FLOWSPEC > >> FILTERSPEC (for H1) > >> > >> to R1, and > >> > >> FLOWSPEC > >> FILTERSPEC (for H2) > >> > >> to R2. > >> > >> Right? > >> > >> OK. The problem shows up when H1 and H2 are two different tunnel > >> endpoints on the same physical box. This can happen in the MPLS > >> world if an ingress router is signalling multiple redundant > >> (failover) paths to a single destination. For instance: > >> > >> R2 ---- R3 > >> / \ > >> H1 ---- R1 R6 ---- R7 ---- H2 > >> \ / > >> R4 ---- R5 > >> > >> H1 sends out two Path messages (with different explicit route > >> objects) to H2. > >> > >> H2 sends out a Resv message indicating that the two "senders" > >> (indicated by different tunnel IDs) are to use shared > resources. The > >> flow descriptor looks something like: > >> > >> FLOWSPEC > >> FILTERSPEC (for tunnel 1) > >> FILTERSPEC (for tunnel 2) > > > > The senders will be distinguished by different Sender Address and/or > > LSP Id in the Sender Template, and not the tunnel Id, which > by virtue > > of being a part of session, has to be same for both the flows, to > > allow the shared explicit reservation, we are talking about here. > > Yes. But if H2 is going to issue a shared reservation for the two, it > must specify filterspecs for both senders in the same Resv object. If > it doesn't then it is signalling two separate resource-sharing groups. > > >> R6, when receiving this, breaks the flow descriptor up for the two > >> paths, sending out > >> > >> FLOWSPEC > >> FILTERSPEC (for tunnel 1) > >> > >> to R3, and > >> > >> FLOWSPEC > >> FILTERSPEC (for tunnel 2) > >> > >> to R5. > >> > >> This works great until those two Resv messages both arrive at R1. > >> > >> How does R1 know that these two tunnels are supposed to be sharing > >> resources. Normally, a router would know this from the multiple > >> filterspecs in a single flow-descriptor, but R1 doesn't > see this. It > >> receives two separate Resv messages from two different next-hop > >> nodes. > > > > R1 knows that it needs to share resources among the two > flows, because > > they belong to the same session (the session object is the same). > > No. This is SE style, not WF. > > In WF style, all senders in a single session share the same resources. > > In SE, the senders that share resources must be explicitly specified. > If a switch assumes sharing when this specification is not present, it > is in error. > > The recipient (H2) knows this and will explicitly state the sharing in > its flow-descriptor list (one flow descriptor containing two flowspecs > and two labels.) The problem is that this information is > lost after the > flow descriptors are broken up at R6. > > >> I suppose R6 could send both filterspecs to both PHOPs, > but R3 and R5 > >> could (probably would) reject those Resv messages, wouldn't they? > >> After all, those two routers each only processed one of > the two Path > >> messages - they don't know about the other one. > >> > >> For that matter, how does H1 tell H2 that these two paths are > >> supposed to be sharing resources? Must it be configured across the > >> network? > >> > >> So, am I missing something here? Is this an > as-yet-unsolved problem > >> with RSVP and MPLS? > > > > I hope it is clear. > > > > Regards, > > Jayesh > From owner-mpls@UU.NET Tue Mar 21 18:41:28 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27464 for ; Tue, 21 Mar 2000 18:41:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihnq12630; Tue, 21 Mar 2000 23:40:32 GMT Received: by mail-control.mail.uu.net id QQihnq25275 for mpls-outgoing; Tue, 21 Mar 2000 23:39:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihnq25266 for ; Tue, 21 Mar 2000 23:39:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihnq03782 for ; Tue, 21 Mar 2000 18:39:27 -0500 (EST) Received: from lumen.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: magic03.kudonet.com [209.133.127.227]) id QQihnq16980 for ; Tue, 21 Mar 2000 23:39:27 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id ; Tue, 21 Mar 2000 15:42:05 -0800 Message-ID: From: John Drake To: "'lee.thomas@wcom.com'" , "'Khaled Elsayed'" Cc: mpls@UU.NET Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Tue, 21 Mar 2000 15:42:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk In the Awduche draft, what is termed an OXC is actually a composite node consisting of of an optical or photonic cross-connect surrounded by DWDM systems. This is a very likely deployment scenario and this composite node does have wavelength conversion acability. Thanks, John -----Original Message----- From: Lee Thomas [mailto:lee.thomas@wcom.com] Sent: Tuesday, March 21, 2000 3:21 PM To: 'Khaled Elsayed' Cc: mpls@UU.NET Subject: RE: Comments on draft-ip-optical-framework-00.txt Peter Ashwood-Smith wrote: > You may waste enormous amounts of bandwidth if you cannot do > wavelength conversion. Convert the question to the ATM domain and > imagine how an ATM network would operate if you had to use the > same VCC from end to end. Basically, if you do not have the ability > to change "labels" then you need one label for EVERY unique path > through the network. Given that the number of paths through a network > grows what .. N factorial? You run out of labels very quickly. This is > especially true with DWDM equipement which may only support 50-100 "labels". > This means that a tiny network would exhaust all the labels/paths > AND you have many links that you can only use a small percentage of > the available "labels" ie bandwidth. So its a very unsatisfactory > solution. Also, to do a good job of it, you need a global view of > each path and label it will use. > I am not questioning the usefulness of wavelength conversion. It is definitely a good mechansim. (Although I have seen some research work that claims that wavelenght conversion may not be worthwhile in some scenarios). Khaled, Could you provide links to some of this research or describe some scenarios where wavelength conversion may not be worthwhile? Thanks, Lee From owner-mpls@UU.NET Tue Mar 21 18:46:24 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28962 for ; Tue, 21 Mar 2000 18:46:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihnr22388; Tue, 21 Mar 2000 23:45:53 GMT Received: by mail-control.mail.uu.net id QQihnr25845 for mpls-outgoing; Tue, 21 Mar 2000 23:45:10 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihnq25667 for ; Tue, 21 Mar 2000 23:44:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihnq04397 for ; Tue, 21 Mar 2000 18:44:52 -0500 (EST) Received: from mail10.vwh1.net by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [209.238.9.57]) id QQihnq16367 for ; Tue, 21 Mar 2000 23:44:52 GMT Received: from 208.55.74.250 (208.55.74.250) by mail10.vwh1.net (RS ver 1.0.53) with SMTP id 09591110; Tue, 21 Mar 2000 18:44:45 -0500 (EST) Message-Id: <3.0.6.32.20000321184729.00b2ade0@photonex.com> X-Sender: jagan@photonex.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 21 Mar 2000 18:47:29 -0500 To: Khaled Elsayed From: Jagan Shantigram Subject: Re: Comments on draft-ip-optical-framework-00.txt Cc: mpls@UU.NET, ip-optical@lists.research.bell-labs.com In-Reply-To: <38D76337.478CA5FC@ieee.org> References: <3.0.6.32.20000320164430.00c3d240@photonex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop-Detect: 1 Sender: owner-mpls@UU.NET Precedence: bulk Khaled, > >My point is a >connection of 2.48 Gbps is not likely to be a random event or an >ATM-like SVC. Agreed - atleast not for some time (2 years? 5??) >Of course >wavelength conversion can help build a better-utilized network, >no question about that. Agreed again. Service providers will ofcourse do their own cost-benefit to see if it makes sense. -jagan. > >Khaled > >> I suspect this is a provisioning issue. Currently it is a nightmare >> to provision for the expanding needs of customers.. with advanced >> intelligent optical systems, fatter pipes can be provisioned as easy >> as ordering a pizza? I will however humbly defer to those who know >> more about the need for dynamic optical path setup and traffic >> mgmt. >> > > > Jagannath Shantigram Photonex Corporation From owner-mpls@UU.NET Tue Mar 21 18:59:18 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03392 for ; Tue, 21 Mar 2000 18:59:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihnr03044; Tue, 21 Mar 2000 23:58:51 GMT Received: by mail-control.mail.uu.net id QQihnr26306 for mpls-outgoing; Tue, 21 Mar 2000 23:58:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihnr26301 for ; Tue, 21 Mar 2000 23:58:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihnr22095 for ; Tue, 21 Mar 2000 18:57:55 -0500 (EST) Received: from lux.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [207.71.195.18]) id QQihnr27093 for ; Tue, 21 Mar 2000 23:57:55 GMT Received: by LUX with Internet Mail Service (5.5.2448.0) id ; Tue, 21 Mar 2000 16:04:38 -0800 Message-ID: <51DA0AB3D747D311832F005004827CC013E278@LUX> From: Jonathan Lang To: "'lee.thomas@wcom.com'" , "'Khaled Elsayed'" Cc: mpls@UU.NET Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Tue, 21 Mar 2000 16:04:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Lee, There may be situations where if you have say 80 wavelengths, for performance reasons you may want to restrict the wavelength conversion to bands of say 8 wavelengths, where full-wavelength conversion is allowed only within the 8 wavelengths of a band (as opposed to over all 80 wavelengths). Furthermore, by adding flexibility to the routing algorithms, you can obtain performance gains close to those obtained by increasing the degree of wavelength translation. We currently have a paper analyzing the above under review at the IEEE/ATM Transactions on Networking, however, parts of it can be found in my thesis. The thesis can be found online at http://spetses.ece.ucsb.edu/~jonathan/thesis.html, but the chapter related to this issue is Chapter 4 (also can be found at the above http site). Regards, Jonathan -----Original Message----- From: Lee Thomas [mailto:lee.thomas@wcom.com] Sent: Tuesday, March 21, 2000 3:21 PM To: 'Khaled Elsayed' Cc: mpls@UU.NET Subject: RE: Comments on draft-ip-optical-framework-00.txt Peter Ashwood-Smith wrote: > You may waste enormous amounts of bandwidth if you cannot do > wavelength conversion. Convert the question to the ATM domain and > imagine how an ATM network would operate if you had to use the > same VCC from end to end. Basically, if you do not have the ability > to change "labels" then you need one label for EVERY unique path > through the network. Given that the number of paths through a network > grows what .. N factorial? You run out of labels very quickly. This is > especially true with DWDM equipement which may only support 50-100 "labels". > This means that a tiny network would exhaust all the labels/paths > AND you have many links that you can only use a small percentage of > the available "labels" ie bandwidth. So its a very unsatisfactory > solution. Also, to do a good job of it, you need a global view of > each path and label it will use. > I am not questioning the usefulness of wavelength conversion. It is definitely a good mechansim. (Although I have seen some research work that claims that wavelenght conversion may not be worthwhile in some scenarios). Khaled, Could you provide links to some of this research or describe some scenarios where wavelength conversion may not be worthwhile? Thanks, Lee From owner-mpls@UU.NET Tue Mar 21 19:09:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07201 for ; Tue, 21 Mar 2000 19:09:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihns06102; Wed, 22 Mar 2000 00:08:34 GMT Received: by mail-control.mail.uu.net id QQihns04355 for mpls-outgoing; Wed, 22 Mar 2000 00:07:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihns04346 for ; Wed, 22 Mar 2000 00:07:28 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihns06937 for ; Tue, 21 Mar 2000 19:07:21 -0500 (EST) Received: from mailgate.fore.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQihns09603 for ; Wed, 22 Mar 2000 00:07:17 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id TAA09491; Tue, 21 Mar 2000 19:07:15 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id TAA18906; Tue, 21 Mar 2000 19:07:17 -0500 (EST) Message-ID: <38D80EB7.12AFE0B4@fore.com> Date: Tue, 21 Mar 2000 19:07:19 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Jayesh V Shah CC: rsvp@isi.edu, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <38D7F0F0.26E46FA4@fore.com> <38D7F9E9.EB386B21@globespan.net> <38D7FC97.3572C0B6@fore.com> <38D80C39.AC653864@globespan.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jayesh V Shah wrote: >>>> >>>> I've got a question about how shared (SE) style reservations get >>>> propagated in the RSVP/MPLS world. >>>> >>>> In a simple multipoint-to-point scenario with shared resources: >>>> >>>> H1 ---- R1 >>>> \ >>>> R3 ---- R4 --- H3 >>>> / >>>> H2 ---- R2 >>>> >>>> H3 should will send out a Resv mesage to R4. The flow descriptor >>>> of this Resv will look like: >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for H1) >>>> FILTERSHEC (for H2) >>>> >>>> R3, when sending out its Resv messages, will break up this flow >>>> descriptor, and will send out >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for H1) >>>> >>>> to R1, and >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for H2) >>>> >>>> to R2. >>>> >>>> Right? >>>> >>>> OK. The problem shows up when H1 and H2 are two different tunnel >>>> endpoints on the same physical box. This can happen in the MPLS >>>> world if an ingress router is signalling multiple redundant >>>> (failover) paths to a single destination. For instance: >>>> >>>> R2 ---- R3 >>>> / \ >>>> H1 ---- R1 R6 ---- R7 ---- H2 >>>> \ / >>>> R4 ---- R5 >>>> >>>> H1 sends out two Path messages (with different explicit route >>>> objects) to H2. >>>> >>>> H2 sends out a Resv message indicating that the two "senders" >>>> (indicated by different tunnel IDs) are to use shared resources. >>>> The flow descriptor looks something like: >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for tunnel 1) >>>> FILTERSPEC (for tunnel 2) >>> >>> The senders will be distinguished by different Sender Address and/or >>> LSP Id in the Sender Template, and not the tunnel Id, which by >>> virtue of being a part of session, has to be same for both the >>> flows, to allow the shared explicit reservation, we are talking >>> about here. >> >> Yes. But if H2 is going to issue a shared reservation for the two, >> it must specify filterspecs for both senders in the same Resv object. >> If it doesn't then it is signalling two separate resource-sharing >> groups. > > What do we mean by multiple resource sharing groups within the same > session ? Two flows (as defined by session-filterspec pairs) that share resources together. Either the two flows share resources, or they do not. If they share resources, the flows are described by a single flow descriptor. If they do not, they are described by two separate flow descriptors. >>>> R6, when receiving this, breaks the flow descriptor up for the two >>>> paths, sending out >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for tunnel 1) >>>> >>>> to R3, and >>>> >>>> FLOWSPEC >>>> FILTERSPEC (for tunnel 2) >>>> >>>> to R5. >>>> >>>> This works great until those two Resv messages both arrive at R1. >>>> >>>> How does R1 know that these two tunnels are supposed to be sharing >>>> resources. Normally, a router would know this from the multiple >>>> filterspecs in a single flow-descriptor, but R1 doesn't see this. >>>> It receives two separate Resv messages from two different next-hop >>>> nodes. >>> >>> R1 knows that it needs to share resources among the two flows, >>> because they belong to the same session (the session object is the >>> same). >> >> No. This is SE style, not WF. >> >> In WF style, all senders in a single session share the same >> resources. >> >> In SE, the senders that share resources must be explicitly specified. >> If a switch assumes sharing when this specification is not present, >> it is in error. > > R1 would get two different Resv, both with SE style with individual > filter specs. R1 would make reservations accordingly, as the outgoing > interfaces for the two flows are different. However, when forwarding > the Resv to H1, the Resv Merge would result in a single SE style Resv, > with two filter specs, one corresponding to each sender. But these two filterspecs should be in one flow descriptor. If they are placed in separate flow descriptors, then resources are no longer shared along the common link from H1 to R1. Regardless, I got my answer from Andi's post. The answer is that the flow descriptors are not broken up in the first place, so R1 doesn't lose the resource-sharing information. > As a matter of fact, R1 can as well forward two different Resv., one > for each filter spec, without changing the interpretation for H1, > because the style is SE. Only if the two filterspecs are in separate flow descriptors. If they are sharing resources, then you can not reserve them in two separate Resv messages - to do so would create two distinct reservations. > The senders should be explicitly specified for the switch to share > reservation in the case of SE, but they need not belong to the same > Resv message. No. If two filterspecs are specified in two separate Resv messages, then they can not share resources unless the style is WF. >> The recipient (H2) knows this and will explicitly state the sharing >> in its flow-descriptor list (one flow descriptor containing two >> flowspecs and two labels.) The problem is that this information is >> lost after the flow descriptors are broken up at R6. This was my incorrect assumption. R6 doesn't break up the flow descriptor. Both Resv messages contain the flow descriptor that specifies both senders. R1 receieves two Resv messages, each of which describes both senders. And that maintains the resource sharing. -- David From owner-mpls@UU.NET Tue Mar 21 20:43:30 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11889 for ; Tue, 21 Mar 2000 20:43:29 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihny08129; Wed, 22 Mar 2000 01:42:51 GMT Received: by mail-control.mail.uu.net id QQihny15901 for mpls-outgoing; Wed, 22 Mar 2000 01:42:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihny15888 for ; Wed, 22 Mar 2000 01:42:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihny01113 for ; Tue, 21 Mar 2000 20:41:53 -0500 (EST) From: YickBeng.Gan@tellabs.com Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQihny07494 for ; Wed, 22 Mar 2000 01:41:53 GMT Received: from sgmail.tellabs.fi ([172.19.205.101]) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id TAA14707 for ; Tue, 21 Mar 2000 19:41:46 -0600 (CST) Received: from localhost (root@localhost) by sgmail.tellabs.fi (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA06593 for ; Wed, 22 Mar 2000 08:41:24 +0700 (SST) X-OpenMail-Hops: 1 Date: Wed, 22 Mar 2000 08:41:22 +0700 Message-Id: Subject: RE: LDP/CR-LDP MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: multipart/alternative; boundary=openmail-part-005df281-00000002 Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-005df281-00000002 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Wed, 22 Mar 2000 08:41:22 +0700" Content-Transfer-Encoding: 8bit Hi All I'm quite new to this. Does anybody know the answers to the below questions. a) Can CR-LDP support VPN and QoS ? How can this be done ? b) Will both protocols (i.e. BGP and OSPF) affect VPN and QoS using LDP/CR-LDP ? If yes, can I have the technical details. Thanks Regards Gan --openmail-part-005df281-00000002 Content-Type: application/rtf Content-Disposition: attachment; filename="BDY.RTF" ;Creation-Date="Wed, 22 Mar 2000 08:41:22 +0700" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcdWMxIFxkZWZmMFxkZWZsYW5nMTAzM1xkZWZsYW5n ZmUxMDMze1xmb250dGJse1xmMFxmcm9tYW5cZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAw MjAyMDYwMzA1MDQwNTAyMDMwNH1UaW1lcyBOZXcgUm9tYW47fXtcZjFcZnN3aXNzXGZjaGFy c2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwYjA2MDQwMjAyMDIwMjAyMDR9QXJpYWw7fXtcZjE2 XGZyb21hblxmY2hhcnNldDIzOFxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gQ0U7fXtcZjE3XGZy b21hblxmY2hhcnNldDIwNFxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gQ3lyO317XGYxOVxmcm9t YW5cZmNoYXJzZXQxNjFcZnBycTIgVGltZXMgTmV3IFJvbWFuIEdyZWVrO317XGYyMFxmcm9t YW5cZmNoYXJzZXQxNjJcZnBycTIgVGltZXMgTmV3IFJvbWFuIFR1cjt9e1xmMjFcZnJvbWFu XGZjaGFyc2V0MTg2XGZwcnEyIFRpbWVzIE5ldyBSb21hbiBCYWx0aWM7fXtcZjIyXGZzd2lz c1xmY2hhcnNldDIzOFxmcHJxMiBBcmlhbCBDRTt9e1xmMjNcZnN3aXNzXGZjaGFyc2V0MjA0 XGZwcnEyIEFyaWFsIEN5cjt9e1xmMjVcZnN3aXNzXGZjaGFyc2V0MTYxXGZwcnEyIEFyaWFs IEdyZWVrO317XGYyNlxmc3dpc3NcZmNoYXJzZXQxNjJcZnBycTIgQXJpYWwgVHVyO317XGYy N1xmc3dpc3NcZmNoYXJzZXQxODZcZnBycTIgQXJpYWwgQmFsdGljO319e1xjb2xvcnRibDtc cmVkMFxncmVlbjBcYmx1ZTA7XHJlZDBcZ3JlZW4wXGJsdWUyNTU7XHJlZDBcZ3JlZW4yNTVc Ymx1ZTI1NTtccmVkMFxncmVlbjI1NVxibHVlMDtccmVkMjU1XGdyZWVuMFxibHVlMjU1O1xy ZWQyNTVcZ3JlZW4wXGJsdWUwO1xyZWQyNTVcZ3JlZW4yNTVcYmx1ZTA7XHJlZDI1NVxncmVl bjI1NVxibHVlMjU1O1xyZWQwXGdyZWVuMFxibHVlMTI4O1xyZWQwXGdyZWVuMTI4XGJsdWUx Mjg7XHJlZDBcZ3JlZW4xMjhcYmx1ZTA7XHJlZDEyOFxncmVlbjBcYmx1ZTEyODtccmVkMTI4 XGdyZWVuMFxibHVlMDtccmVkMTI4XGdyZWVuMTI4XGJsdWUwO1xyZWQxMjhcZ3JlZW4xMjhc Ymx1ZTEyODtccmVkMTkyXGdyZWVuMTkyXGJsdWUxOTI7fXtcc3R5bGVzaGVldHtcd2lkY3Rs cGFyXGFkanVzdHJpZ2h0IFxmMVxmczIwXGNncmlkIFxzbmV4dDAgTm9ybWFsO317XHMxXHNi MjQwXHNhNjBca2VlcG5cd2lkY3RscGFyXG91dGxpbmVsZXZlbDBcYWRqdXN0cmlnaHQgXGJc ZjFcZnMyOFxrZXJuaW5nMjhcY2dyaWQgXHNiYXNlZG9uMCBcc25leHQwIGhlYWRpbmcgMTt9 e1xzMlxzYjI0MFxzYTYwXGtlZXBuXHdpZGN0bHBhclxvdXRsaW5lbGV2ZWwxXGFkanVzdHJp Z2h0IFxiXGlcZjFcZnMyMFxjZ3JpZCBcc2Jhc2Vkb24wIFxzbmV4dDAgaGVhZGluZyAyO317 XHMzXHNiMjQwXHNhNjBca2VlcG5cd2lkY3RscGFyXG91dGxpbmVsZXZlbDJcYWRqdXN0cmln aHQgXGJcZjFcZnMyMFxjZ3JpZCBcc2Jhc2Vkb24wIFxzbmV4dDAgaGVhZGluZyAzO317XCpc Y3MxMCBcYWRkaXRpdmUgRGVmYXVsdCBQYXJhZ3JhcGggRm9udDt9e1xzMTVcZmktMTA4MFxs aTEwODBcd2lkY3RscGFyXGJyZHJsXGJyZHJzXGJyZHJ3NDVcYnJzcDIwIFxhZGp1c3RyaWdo dCBcZjFcZnMyMFxjZ3JpZCBcc2Jhc2Vkb24wIFxzbmV4dDE1IFByaW50LSBGcm9tOiBUbzog U3ViamVjdDogRGF0ZTo7fXtcczE2XGZpLTEwODBcbGkxMDgwXHdpZGN0bHBhclxicmRybFxi cmRyc1xicmRydzQ1XGJyc3AyMCBcYWRqdXN0cmlnaHQgXHNoYWRpbmcxMjUwIFxiXGYxXGZz MjJcY2dyaWQgXHNiYXNlZG9uMCBcc25leHQxNSBQcmludC0gUmV2ZXJzZSBIZWFkZXI7fXtc czE3XGZpLTEwODBcbGkxMDgwXHdpZGN0bHBhclxicmRybFxicmRyc1xicmRydzQ1XGJyc3Ay MCBcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBcc2hhZGluZzEwMDBcY2JwYXQ4IFxiXGYx XGZzMjBcbGFuZzEwMjRcY2dyaWQgXHNiYXNlZG9uMCBcc25leHQxOCBSZXBseS9Gb3J3YXJk IEhlYWRlcnM7fXtcczE4XGZpLTEwODBcbGkxMDgwXHdpZGN0bHBhclxicmRybFxicmRyc1xi cmRydzQ1XGJyc3AyMCBcYWRqdXN0cmlnaHQgXGYxXGZzMjBcY2dyaWQgXHNiYXNlZG9uMCBc c25leHQxOCBSZXBseS9Gb3J3YXJkIFRvOiBGcm9tOiBEYXRlOjt9e1xzMTlcd2lkY3RscGFy XGFkanVzdHJpZ2h0IFxjYnBhdDkgXGYxXGZzMjBcY2dyaWQgXHNiYXNlZG9uMCBcc25leHQx OSBEb2N1bWVudCBNYXA7fXtcczIwXHNhMTIwXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjFc ZnMyMFxjZ3JpZCBcc2Jhc2Vkb24wIFxzbmV4dDIwIEJvZHkgVGV4dDt9fXtcKlxsaXN0dGFi bGV7XGxpc3RcbGlzdHRlbXBsYXRlaWQ2NzY5ODcxMVxsaXN0c2ltcGxle1xsaXN0bGV2ZWxc bGV2ZWxuZmM0XGxldmVsamMwXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQxXGxldmVsc3Bh Y2UwXGxldmVsaW5kZW50MHtcbGV2ZWx0ZXh0XCcwMlwnMDApO317XGxldmVsbnVtYmVyc1wn MDE7fVxmYmlhczAgXGZpLTM2MFxsaTM2MFxqY2xpc3R0YWJcdHgzNjAgfXtcbGlzdG5hbWUg O31cbGlzdGlkMjAwMDExNjk4Nn19e1wqXGxpc3RvdmVycmlkZXRhYmxle1xsaXN0b3ZlcnJp ZGVcbGlzdGlkMjAwMDExNjk4NlxsaXN0b3ZlcnJpZGVjb3VudDBcbHMxfX1cd2lkb3djdHJs XGZ0bmJqXGFlbmRkb2NcZm9ybXNoYWRlXGRvY3R5cGUyXHZpZXdraW5kNFx2aWV3c2NhbGUx MDBccGdicmRyaGVhZFxwZ2JyZHJmb290IFxmZXQwe1wqXHRlbXBsYXRlIEM6XFxQcm9ncmFt IEZpbGVzXFxNaWNyb3NvZnQgT2ZmaWNlXFxPZmZpY2VcXEVNQUlMLmRvdH1cc2VjdGQgXGxp bmV4MFxoZWFkZXJ5NzA5XGZvb3Rlcnk3MDlcY29sc3g3MDlcZW5kbmhlcmVcc2VjdGRlZmF1 bHRjbCB7XCpccG5zZWNsdmwxXHBudWNybVxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7 XHBudHh0YSAufX17XCpccG5zZWNsdmwyXHBudWNsdHJccG5zdGFydDFccG5pbmRlbnQ3MjBc cG5oYW5ne1xwbnR4dGEgLn19e1wqXHBuc2VjbHZsM1xwbmRlY1xwbnN0YXJ0MVxwbmluZGVu dDcyMFxwbmhhbmd7XHBudHh0YSAufX17XCpccG5zZWNsdmw0XHBubGNsdHJccG5zdGFydDFc cG5pbmRlbnQ3MjBccG5oYW5ne1xwbnR4dGEgKX19e1wqXHBuc2VjbHZsNVxwbmRlY1xwbnN0 YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0YiAofXtccG50eHRhICl9fXtcKlxwbnNl Y2x2bDZccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0YiAofXtc cG50eHRhICl9fXtcKlxwbnNlY2x2bDdccG5sY3JtXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBu aGFuZ3tccG50eHRiICh9e1xwbnR4dGEgKX19e1wqXHBuc2VjbHZsOFxwbmxjbHRyXHBuc3Rh cnQxXHBuaW5kZW50NzIwXHBuaGFuZ3tccG50eHRiICh9e1xwbnR4dGEgKX19e1wqXHBuc2Vj bHZsOVxwbmxjcm1ccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5ne1xwbnR4dGIgKH17XHBu dHh0YSApfX1ccGFyZFxwbGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmMVxmczIwXGNn cmlkIHtIaSBBbGwNClxwYXIgDQpccGFyIElccnF1b3RlIG0gcXVpdGUgbmV3IHRvIHRoaXMu IERvZXMgYW55Ym9keSBrbm93IHRoZSBhbnN3ZXJzIHRvIHRoZSBiZWxvdyBxdWVzdGlvbnMu IA0KXHBhciANClxwYXIge1xwbnRleHRccGFyZFxwbGFpblxzMjAgXGYxXGZzMjAgXGhpY2hc YWYxXGRiY2hcYWYwXGxvY2hcZjEgYSlcdGFifX1ccGFyZFxwbGFpbiBcczIwXGZpLTM2MFxs aTM2MFxzYTEyMFx3aWRjdGxwYXJcamNsaXN0dGFiXHR4MzYwe1wqXHBuIFxwbmx2bGJvZHlc aWx2bDBcbHMxXHBucm5vdDBccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDM2MFxwbmhhbmd7 XHBudHh0YSApfX1cbHMxXGFkanVzdHJpZ2h0IFxmMVxmczIwXGNncmlkIHtcY2dyaWQwIENh biBDUi1MRFAgc3VwcG9ydCBWUE4gYW5kIFFvUyA/IEhvdyBjYW4gdGhpcyBiZSBkb25lID8N ClxwYXIge1xwbnRleHRccGFyZFxwbGFpblxzMjAgXGYxXGZzMjAgXGhpY2hcYWYxXGRiY2hc YWYwXGxvY2hcZjEgYilcdGFifX1ccGFyZCBcczIwXGZpLTM2MFxsaTM2MFxzYTEyMFx3aWRj dGxwYXJcamNsaXN0dGFiXHR4MzYwe1wqXHBuIFxwbmx2bGJvZHlcaWx2bDBcbHMxXHBucm5v dDBccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDM2MFxwbmhhbmd7XHBudHh0YSApfX1cbHMx XGFkanVzdHJpZ2h0IHtcY2dyaWQwIFdpbGwgfXtcY2dyaWQwIGJvdGggcHJvdG9jb2xzIH17 XGNncmlkMCAoaS5lLiBCR1AgYW5kIE9TUEYpIH17XGNncmlkMCBhZmZlY3QgVlBOIGFuZCBR b1MgdXNpbmcgTERQL0NSLUxEUCB9e1xjZ3JpZDAgPyBJZiB5ZXMsIGNhbiBJIGhhdmUgdGhl IH17XGNncmlkMCB0ZWNobmljYWwgZGV0YWlsc317XGNncmlkMCAuDQpccGFyIH1ccGFyZCBc czIwXHNhMTIwXHdpZGN0bHBhclxhZGp1c3RyaWdodCB7XGNncmlkMCANClxwYXIgVGhhbmtz DQpccGFyIH1ccGFyZFxwbGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmMVxmczIwXGNn cmlkIHsNClxwYXIgUmVnYXJkcw0KXHBhciB9XHBhcmQgXHdpZGN0bHBhclxhZGp1c3RyaWdo dCB7R2FuDQpccGFyIH19AA== --openmail-part-005df281-00000002-- From owner-mpls@UU.NET Tue Mar 21 23:57:49 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28474 for ; Tue, 21 Mar 2000 23:57:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihol16158; Wed, 22 Mar 2000 04:56:54 GMT Received: by mail-control.mail.uu.net id QQihol16353 for mpls-outgoing; Wed, 22 Mar 2000 04:56:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihol16348 for ; Wed, 22 Mar 2000 04:56:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihol29218 for ; Tue, 21 Mar 2000 23:56:26 -0500 (EST) Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQihol15688 for ; Wed, 22 Mar 2000 04:56:26 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id WAA20142; Tue, 21 Mar 2000 22:56:23 -0600 (CST) Received: from vsharma ([172.31.101.69] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id WAA27785; Tue, 21 Mar 2000 22:56:24 -0600 (CST) Received: by localhost with Microsoft MAPI; Wed, 22 Mar 2000 00:00:11 -0500 Message-ID: <01BF9391.97EA5100.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'lee.thomas@wcom.com'" , "khaled@ieee.org" Cc: "mpls@UU.NET" Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Wed, 22 Mar 2000 00:00:09 -0500 Organization: Tellabs Research Center X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lee, A partial response to your question below. There are situations where some form of "limited" wavelength conversion might be sufficient to give good performance and full wavelength conversion may not be needed or be worthwhile. (Strictly speaking, there is still wavelength conversion in this scheme, just not as much of it as you would need for full wavelength conversion, and this could be a significant cost and/or implementation advantage.) There are some research papers on this subject. Some relevant references are: Yates, J.; Lacey, J.; Everitt, D.; Summerfield, M. Limited-range wavelength translation in all-optical networks. IN: Proceedings of IEEE INFOCOM '96. Conference on Computer Communications, San Francisco, CA, USA, 24-28 March 1996. p. 954-61 vol.3. Sharma, V.; Varvarigos, E.A. Limited wavelength translation in all-optical WDM mesh networks. IN: Proceedings IEEE INFOCOM'98, San Francisco, CA, USA, 29 March-2 April 1998. p. 893-901 vol.2. Ramaswami, R.; Sasaki, G. Multiwavelength optical networks with limited wavelength conversion. IEEE/ACM Transactions on Networking, Dec. 1998, vol.6, (no.6):744-54. Venugopal, K.R.; Shivakumar, M.; Kumar, P.S. A heuristic for placement of limited range wavelength converters in all-optical networks. IN: Proceedings of INFOCOM'99: Conference on Computer Communications, New York, NY, USA, 21-25 March 1999, p. 908-15 vol.2. Tripathi, T.; Sivarajan, K.N. Computing approximate blocking probabilities in wavelength routed all-optical networks with limited-range wavelength conversion. IN: Proceedings of INFOCOM'99: Conference on Computer Communications, New York, NY, USA, 21-25 March 1999. p. 329-36 vol.1. Regards, -Vishal On Tuesday, March 21, 2000 6:21 PM, lee.thomas@wcom.com [SMTP:lee.thomas@wcom.com] wrote: > > > Peter Ashwood-Smith wrote: > > You may waste enormous amounts of bandwidth if you cannot do > > wavelength conversion. Convert the question to the ATM domain and > > imagine how an ATM network would operate if you had to use the > > same VCC from end to end. Basically, if you do not have the ability > > to change "labels" then you need one label for EVERY unique path > > through the network. Given that the number of paths through a network > > grows what .. N factorial? You run out of labels very quickly. This is > > especially true with DWDM equipement which may only support 50-100 > "labels". > > This means that a tiny network would exhaust all the labels/paths > > AND you have many links that you can only use a small percentage of > > the available "labels" ie bandwidth. So its a very unsatisfactory > > solution. Also, to do a good job of it, you need a global view of > > each path and label it will use. > > > > I am not questioning the usefulness of wavelength conversion. It > is definitely a good mechansim. (Although I have seen some > research work that claims that wavelenght conversion may not be > worthwhile in some scenarios). > > Khaled, > > Could you provide links to some of this research or describe some scenarios > where wavelength conversion may not be worthwhile? > > Thanks, > > Lee > From owner-mpls@UU.NET Wed Mar 22 09:50:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14213 for ; Wed, 22 Mar 2000 09:50:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihpz29864; Wed, 22 Mar 2000 14:48:45 GMT Received: by mail-control.mail.uu.net id QQihpz05464 for mpls-outgoing; Wed, 22 Mar 2000 14:48:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihpz05456 for ; Wed, 22 Mar 2000 14:48:15 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihpz01528 for ; Wed, 22 Mar 2000 09:47:57 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihpz28849 for ; Wed, 22 Mar 2000 14:47:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA10722 for mpls@uu.net; Wed, 22 Mar 2000 09:47:55 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihpz05433 for ; Wed, 22 Mar 2000 14:47:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihpz18267 for ; Wed, 22 Mar 2000 09:47:24 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQihpz28332 for ; Wed, 22 Mar 2000 14:47:24 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Mar 2000 09:47:19 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F8A3@brixcorp2.brixnet.com> From: Joan Cucchiara To: "'Abes, Andi'" , Vijay Srinivasan , mpls@UU.NET Subject: RE: LSR MIB last call Date: Wed, 22 Mar 2000 09:47:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Abes, Andi [mailto:aabes@quarrytech.com] > Sent: Tuesday, March 21, 2000 12:47 PM > To: Vijay Srinivasan; mpls@UU.NET > Subject: RE: LSR MIB last call > > > Opps... > > I didn't notice Adrian's mail, and the response from Tom. > > In any case, if Diff Serv is to be added later, can we > rid of the XCCos, which is not enough for Diff Serv support > and might generate (or has already done so) confusion ? I would be in favor of taking this object out of the LSR MIB also for the reasons stated above It would also be my preference to remove the TSpec table and put this into the TE MIB for the similar reasons. The LSR MIB, should be able to support ALL MPLS protocols, and the TSpec table is not relevant to LDP. Certainly, it would be easy enough to Augment/extend tables in the LSR MIB in the TE MIB (or any other MIB), so there is really no need to have objects in the LSR MIB which are not supported all of the MPLS protocols. It would be "cleaner" to have related functionality in the same MIBs, instead of having chunks in the LSR MIB and chunks in another MIB. -Joan > > > Andi. > > > > > -----Original Message----- > > From: Abes, Andi [mailto:aabes@quarrytech.com] > > Sent: Tuesday, March 21, 2000 11:50 AM > > To: Vijay Srinivasan; mpls@UU.NET > > Subject: RE: LSR MIB last call > > > > > > I think this has been mentioned before, > > but what support, if any is there for configuring and > > representing Diff Serv capable LSP's ? > > > > The only mention I found is the XCCos, which > > doesn't seem to be enough. > > > > I would expect the MIB to be capable of the following: > > - Connect an InSegment to (eventually) an Output Segment > > based both on Input IF, input Label and incoming EXP (COS) bits > > > > Preferably the inSegment would select the XC based on > > label, and then > > the XC would select a specific output segment based on EXP. > > ( this is meant to allow conversion between incoming > > E-LSP's to outgoing > > L-LSP's as would be needed in an LSR with both Ethernet > and LC-ATM > > interfaces > > for example) > > > > - Allow a mapping between incoming EXP to outgoing EXP, not > > just a global > > replacement (as is provided by XCCos). This could be > > accomplished together > > with > > the previous point by indexing the XC table with EXP as > > well. For LSP's > > created by LDP, > > a single value of 0 could be used. > > > > - For output segments, specify their type (E/L-LSP's), and > > PHBID of the OA > > carried over them. > > > > > > This is my understanding of some of the requirements for > > supporting Diff > > Serv LSP's. > > The Diff Serv over MPLS authors could have > > better/greater/finer comments to > > add to > > this. > > Have they been consulted on the issue ? I remeber Adrian > > mentioning this > > before > > > > Andi. > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: Vijay Srinivasan [mailto:vsriniva@cosinecom.com] > > Sent: Tuesday, March 21, 2000 11:01 AM > > To: 'Joan Cucchiara'; 'tnadeau@cisco.com'; > 'arun@force10networks.com'; > > 'cheenu@tachion.com' > > Cc: 'mpls@uu.net' > > Subject: LSR MIB last call > > > > > > > > > > The authors of the LSR MIB have requested that we progress > > the document to > > WG last call. I would like to commence the last call, ending > > in two weeks > > (due to the IETF in between). Joan's comments to the list will be > > considered as part of the last call. > > > > - Vijay > > > From owner-mpls@UU.NET Wed Mar 22 10:20:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25151 for ; Wed, 22 Mar 2000 10:20:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqb19112; Wed, 22 Mar 2000 15:18:39 GMT Received: by mail-control.mail.uu.net id QQihqb15067 for mpls-outgoing; Wed, 22 Mar 2000 15:18:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihqb15057 for ; Wed, 22 Mar 2000 15:18:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqb07008 for ; Wed, 22 Mar 2000 10:17:57 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQihqb18354 for ; Wed, 22 Mar 2000 15:17:56 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA12384 for ; Wed, 22 Mar 2000 07:44:28 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA18756 for mpls@uu.net; Wed, 22 Mar 2000 10:17:50 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihnc14489 for ; Tue, 21 Mar 2000 20:03:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihnc02855 for ; Tue, 21 Mar 2000 15:03:45 -0500 (EST) Received: from howler.tri.sbc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: howler.tri.sbc.com [205.173.58.4]) id QQihnc05996 for ; Tue, 21 Mar 2000 20:03:44 GMT Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id OAA09552 for ; Tue, 21 Mar 2000 14:05:17 -0600 (CST) Received: from trimail.tri.sbc.com (trimail [144.60.55.189]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id OAA09165 for ; Tue, 21 Mar 2000 14:03:13 -0600 (CST) Received: by trimail.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 21 Mar 2000 14:03:12 -0600 Message-ID: <8391FE2580A1D11198CB00A0C99845D4B356E6@tripacific.ttl.pactel.com> From: "Girish, Muckai" To: mpls@UU.NET Subject: FW: I-D ACTION:draft-vaananen-mpls-svc-diff-framework-00.txt Date: Tue, 21 Mar 2000 14:03:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF9370.7C19E8DA" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF9370.7C19E8DA Content-Type: text/plain; charset="iso-8859-1" Looks like this was not announced in the MPLS mailing list. Anyways, here it is. Girish -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, March 09, 2000 3:29 AM Subject: I-D ACTION:draft-vaananen-mpls-svc-diff-framework-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Framework for Service Differentiation in MPLS Networks Author(s) : M. Girish, R. Ravikanth, P. Vaananen Filename : draft-vaananen-mpls-svc-diff-framework-00.txt Pages : 42 Date : 08-Mar-00 It has been recognized that the success of the MPLS depends on the ability to better support the multiservice traffic integration with some levels of service guarantees, which are not feasible to implement with the current destination prefix only based packet forwarding paradigms. The efficient support for these services throughout the network is expected to be possible using label based forwarding paradigm in the network. Through the use of either RSVP based or LDP/CR-LDP based signaling, MPLS can also provide certain QoS guarantees using the LSPs. The goal of this document is to define a framework for service differentiation in MPLS networks. We discuss a set of services that have been identified so far for IP, and describe the traffic management mechanisms in various network elements that are needed for enabling the implementation of these more advanced services in MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vaananen-mpls-svc-diff-framework-0 0.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vaananen-mpls-svc-diff-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vaananen-mpls-svc-diff-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01BF9370.7C19E8DA Content-Type: message/rfc822 To: Subject: Date: Tue, 21 Mar 2000 14:03:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BF9370.7C19E8DA" ------_=_NextPart_002_01BF9370.7C19E8DA Content-Type: text/plain ------_=_NextPart_002_01BF9370.7C19E8DA Content-Type: application/octet-stream; name="ATT04441.txt" Content-Disposition: attachment; filename="ATT04441.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000308131707.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vaananen-mpls-svc-diff-framework-00.txt ------_=_NextPart_002_01BF9370.7C19E8DA Content-Type: message/external-body; site="internet-drafts"; dir="draft-vaananen-mpls-svc-diff-framework-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BF9370.7C19E8DA-- ------_=_NextPart_000_01BF9370.7C19E8DA-- From owner-mpls@UU.NET Wed Mar 22 10:21:19 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25513 for ; Wed, 22 Mar 2000 10:21:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqb04920; Wed, 22 Mar 2000 15:19:57 GMT Received: by mail-control.mail.uu.net id QQihqb15118 for mpls-outgoing; Wed, 22 Mar 2000 15:19:16 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihqb15103 for ; Wed, 22 Mar 2000 15:19:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihqb23535 for ; Wed, 22 Mar 2000 10:18:14 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQihqb03229 for ; Wed, 22 Mar 2000 15:18:13 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA27261 for ; Wed, 22 Mar 2000 07:18:13 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA18760 for mpls@uu.net; Wed, 22 Mar 2000 10:18:11 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihnm13752 for ; Tue, 21 Mar 2000 22:34:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihnm25733 for ; Tue, 21 Mar 2000 17:34:27 -0500 (EST) Received: from rambo.globespan.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: p1.globespan.net [209.191.59.250]) id QQihnm05542 for ; Tue, 21 Mar 2000 22:34:27 GMT Received: from globespan.net (phoenix.ficon-tech.com [209.125.90.2]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HM230LPZ; Tue, 21 Mar 2000 17:32:16 -0500 Message-ID: <38D7F9E9.EB386B21@globespan.net> Date: Tue, 21 Mar 2000 17:38:33 -0500 From: Jayesh V Shah Organization: GlobeSpan, Inc. X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: rsvp@isi.edu, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <38D7F0F0.26E46FA4@fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, > I've got a question about how shared (SE) style reservations get > propagated in the RSVP/MPLS world. > > In a simple multipoint-to-point scenario with shared resources: > > H1 ---- R1 > \ > R3 ---- R4 --- H3 > / > H2 ---- R2 > > H3 should will send out a Resv mesage to R4. The flow descriptor of > this Resv will look like: > > FLOWSPEC > FILTERSPEC (for H1) > FILTERSHEC (for H2) > > R3, when sending out its Resv messages, will break up this flow > descriptor, and will send out > > FLOWSPEC > FILTERSPEC (for H1) > > to R1, and > > FLOWSPEC > FILTERSPEC (for H2) > > to R2. > > Right? > > OK. The problem shows up when H1 and H2 are two different tunnel > endpoints on the same physical box. This can happen in the MPLS world > if an ingress router is signalling multiple redundant (failover) paths > to a single destination. For instance: > > R2 ---- R3 > / \ > H1 ---- R1 R6 ---- R7 ---- H2 > \ / > R4 ---- R5 > > H1 sends out two Path messages (with different explicit route objects) > to H2. > > H2 sends out a Resv message indicating that the two "senders" (indicated > by different tunnel IDs) are to use shared resources. The flow > descriptor looks something like: > > FLOWSPEC > FILTERSPEC (for tunnel 1) > FILTERSPEC (for tunnel 2) The senders will be distinguished by different Sender Address and/or LSP Id in the Sender Template, and not the tunnel Id, which by virtue of being a part of session, has to be same for both the flows, to allow the shared explicit reservation, we are talking about here. > R6, when receiving this, breaks the flow descriptor up for the two > paths, sending out > > FLOWSPEC > FILTERSPEC (for tunnel 1) > > to R3, and > > FLOWSPEC > FILTERSPEC (for tunnel 2) > > to R5. > > This works great until those two Resv messages both arrive at R1. > > How does R1 know that these two tunnels are supposed to be sharing > resources. Normally, a router would know this from the multiple > filterspecs in a single flow-descriptor, but R1 doesn't see this. It > receives two separate Resv messages from two different next-hop nodes. R1 knows that it needs to share resources among the two flows, because they belong to the same session (the session object is the same). > > I suppose R6 could send both filterspecs to both PHOPs, but R3 and R5 > could (probably would) reject those Resv messages, wouldn't they? After > all, those two routers each only processed one of the two Path messages > - they don't know about the other one. > > For that matter, how does H1 tell H2 that these two paths are supposed > to be sharing resources? Must it be configured across the network? > > So, am I missing something here? Is this an as-yet-unsolved problem > with RSVP and MPLS? > > -- David I hope it is clear. Regards, Jayesh -- __________________________________________ Jayesh V. Shah GlobeSpan, Inc. Tel: (732) 283-2770 x321 Fax: (732) 283-2848 E-mail: jshah@globespan.net Web: http://www.ficon-tech.com/home.htm From owner-mpls@UU.NET Wed Mar 22 10:21:49 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25679 for ; Wed, 22 Mar 2000 10:21:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqb05728; Wed, 22 Mar 2000 15:20:27 GMT Received: by mail-control.mail.uu.net id QQihqb15154 for mpls-outgoing; Wed, 22 Mar 2000 15:19:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihqb15148 for ; Wed, 22 Mar 2000 15:19:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihqb23782 for ; Wed, 22 Mar 2000 10:19:38 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQihqb04465 for ; Wed, 22 Mar 2000 15:19:37 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA27772 for ; Wed, 22 Mar 2000 07:19:36 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA18798 for mpls@uu.net; Wed, 22 Mar 2000 10:19:35 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihnu05924 for ; Wed, 22 Mar 2000 00:39:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihnu10191 for ; Tue, 21 Mar 2000 19:39:20 -0500 (EST) Received: from acsys.anu.edu.au by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: acsys.anu.edu.au [150.203.20.41]) id QQihnu00682 for ; Wed, 22 Mar 2000 00:39:18 GMT Received: from accordion (accordion.anu.edu.au [150.203.20.58]) by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id LAA05325; Wed, 22 Mar 2000 11:38:50 +1100 (EST) Message-Id: <3.0.32.20000322113747.01571ec0@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Mar 2000 11:37:48 +1100 To: Jagan Shantigram , Khaled Elsayed From: Markus Buchhorn Subject: Re: Comments on draft-ip-optical-framework-00.txt Cc: mpls@UU.NET, ip-optical@lists.research.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk >>My point is a >>connection of 2.48 Gbps is not likely to be a random event or an >>ATM-like SVC. > >Agreed - atleast not for some time (2 years? 5??) I'm not sure that I'd agree it would be out that far. Think of things like fail-over circuits (back-hoe avoidance algorithms...), bandwidth balancing in the core of the networks, etc. In these cases a 2Gb/s (or whatever) circuit could be required with a quick set up, and eventual tear-down - like an ATM SVC. No reason to leave a dim lambda sitting round for that... Cheers, Markus >>Of course >>wavelength conversion can help build a better-utilized network, >>no question about that. > >Agreed again. Service providers will ofcourse do their own >cost-benefit to see if it makes sense. > >-jagan. > >> >>Khaled >> >>> I suspect this is a provisioning issue. Currently it is a nightmare >>> to provision for the expanding needs of customers.. with advanced >>> intelligent optical systems, fatter pipes can be provisioned as easy >>> as ordering a pizza? I will however humbly defer to those who know >>> more about the need for dynamic optical path setup and traffic >>> mgmt. >>> >> >> >> > >Jagannath Shantigram >Photonex Corporation > > Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From owner-mpls@UU.NET Wed Mar 22 10:25:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26682 for ; Wed, 22 Mar 2000 10:25:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqb23705; Wed, 22 Mar 2000 15:23:30 GMT Received: by mail-control.mail.uu.net id QQihqb15512 for mpls-outgoing; Wed, 22 Mar 2000 15:22:58 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihqb15507 for ; Wed, 22 Mar 2000 15:22:54 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqb24171 for ; Wed, 22 Mar 2000 10:21:23 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQihqb21641 for ; Wed, 22 Mar 2000 15:21:22 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA14529 for ; Wed, 22 Mar 2000 07:47:56 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA18809 for mpls@uu.net; Wed, 22 Mar 2000 10:21:19 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihnx15315 for ; Wed, 22 Mar 2000 01:20:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihnx29516 for ; Tue, 21 Mar 2000 20:19:52 -0500 (EST) Received: from rambo.globespan.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: p1.globespan.net [209.191.59.250]) id QQihnx25492 for ; Wed, 22 Mar 2000 01:19:52 GMT Received: from globespan.net (phoenix.ficon-tech.com [209.125.90.2]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HM230M1D; Tue, 21 Mar 2000 20:17:42 -0500 Message-ID: <38D820AF.8F848703@globespan.net> Date: Tue, 21 Mar 2000 20:23:59 -0500 From: Jayesh V Shah Organization: GlobeSpan, Inc. X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: rsvp@isi.edu, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <38D7F0F0.26E46FA4@fore.com> <38D7F9E9.EB386B21@globespan.net> <38D7FC97.3572C0B6@fore.com> <38D80C39.AC653864@globespan.net> <38D80EB7.12AFE0B4@fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > What do we mean by multiple resource sharing groups within the same > > session ? > > Two flows (as defined by session-filterspec pairs) that share resources > together. > > Either the two flows share resources, or they do not. > > If they share resources, the flows are described by a single flow > descriptor. If they do not, they are described by two separate flow > descriptors. But SE style doesn't allow multiple flow descriptors. You can only have a single FlowSpec, followed by a list of filter specs. Look at the BNF notation for SE style Resv message If you follow the steps for RESV REFRESH sequence in RFC 2209 (Message Processing), specifically step # 5, regardless of the fact whether you receive all the filter specs in a single or multiple Resvs, it will result in a single resv refresh to the PHOP, with a merged FlowSpec and a list of FilterSpecs, which is the union of all the Filter Specs, across all the Resvs you have received for this session, sharing the same PHOP. > > As a matter of fact, R1 can as well forward two different Resv., one > > for each filter spec, without changing the interpretation for H1, > > because the style is SE. > > Only if the two filterspecs are in separate flow descriptors. If they > are sharing resources, then you can not reserve them in two separate > Resv messages - to do so would create two distinct reservations. I don't agree with you here. Going by the message processing rule, I don't think it would result in two distinct reservations. Assuming the case that you receive two different SE style reservations, for the same session, encompassing different filter specs, coming from the same NHOP, it would result in just a single RSB, with a single FlowSpec, and a list of FilterSpecs equal to the union of those in the two Resvs. Look at Page 11 of RFC2209. My question still remains, is it possible to have multiple resource sharing groups within the same session for SE style reservations ? > Regardless, I got my answer from Andi's post. The answer is that the > flow descriptors are not broken up in the first place, so R1 doesn't > lose the resource-sharing information. > >> The recipient (H2) knows this and will explicitly state the sharing > >> in its flow-descriptor list (one flow descriptor containing two > >> flowspecs and two labels.) The problem is that this information is > >> lost after the flow descriptors are broken up at R6. > > This was my incorrect assumption. R6 doesn't break up the flow > descriptor. Both Resv messages contain the flow descriptor that > specifies both senders. R1 receieves two Resv messages, each of which > describes both senders. And that maintains the resource sharing. No. The flow descriptor list is broken. Refer to examples given at the beginning of RFC 2205. However, Andi's post makes it clear that even if they are not, there is no harm, because extra filter specs will get ignored at the PHOP. And even if R6 does not split the filter Spec list, the Resv coming out of R3 will contain just a single filter spec, according to step 3 in Andi's post. Regards, Jayesh -- __________________________________________ Jayesh V. Shah GlobeSpan, Inc. Tel: (732) 283-2770 x321 Fax: (732) 283-2848 E-mail: jshah@globespan.net Web: http://www.ficon-tech.com/home.htm From owner-mpls@UU.NET Wed Mar 22 10:26:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27274 for ; Wed, 22 Mar 2000 10:26:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqb24405; Wed, 22 Mar 2000 15:24:01 GMT Received: by mail-control.mail.uu.net id QQihqb15556 for mpls-outgoing; Wed, 22 Mar 2000 15:23:36 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihqb15551 for ; Wed, 22 Mar 2000 15:23:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihqb24281 for ; Wed, 22 Mar 2000 10:21:48 -0500 (EST) Received: from kickme.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kickme.cisco.com [198.92.30.42]) id QQihqb07188 for ; Wed, 22 Mar 2000 15:21:47 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA27694 for ; Wed, 22 Mar 2000 07:08:56 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA18814 for mpls@uu.net; Wed, 22 Mar 2000 10:21:42 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihpu22486 for ; Wed, 22 Mar 2000 13:34:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihpu18467 for ; Wed, 22 Mar 2000 08:33:56 -0500 (EST) Received: from pooh.aist-nara.ac.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [163.221.130.162]) id QQihpu16452 for ; Wed, 22 Mar 2000 13:33:55 GMT Received: from localhost by pooh.aist-nara.ac.jp (8.8.7/2.8Wb) id NAA25046; Wed, 22 Mar 2000 13:35:05 GMT From: Noritoshi Demizu To: mpls@UU.NET Subject: Re: Draft MPLS Agendan In-Reply-To: Your message of "Tue, 21 Mar 2000 15:34:02 -0500" References: <200003212034.PAA19833@lir.cisco.com> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 X-URL: http://infonet.aist-nara.ac.jp/member/nori-d/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000322223504X.demizu@dd.iij4u.or.jp> Date: Wed, 22 Mar 2000 22:35:04 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 13 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I made an HTML version of draft MPLS agenda at http://infonet.aist-nara.ac.jp/member/nori-d/mlr/article/MPLS-agenda-0003.html Of course, there are links to I-Ds. I did my best, but I am sorry if there are errors. By the way, I could not find the following I-D. Where can I find it? I temporary made a link to revision 04 in the current page above. > Davari draft-ietf-mpls-diff-ext-05.txt 13 Thank you very much. Best Regards, Noritoshi Demizu, NAIST From owner-mpls@UU.NET Wed Mar 22 11:02:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10689 for ; Wed, 22 Mar 2000 11:02:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqd27908; Wed, 22 Mar 2000 15:59:38 GMT Received: by mail-control.mail.uu.net id QQihqd18307 for mpls-outgoing; Wed, 22 Mar 2000 15:58:58 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihqd18297 for ; Wed, 22 Mar 2000 15:58:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqd14558 for ; Wed, 22 Mar 2000 10:58:09 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQihqd26331 for ; Wed, 22 Mar 2000 15:58:09 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id KAA26789; Wed, 22 Mar 2000 10:53:13 -0500 Message-ID: <38D8FBA3.A6568BA9@tellium.com> Date: Wed, 22 Mar 2000 10:58:11 -0600 From: Debanjan Saha Organization: Tellium Optical Systems X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John Drake CC: mpls@UU.NET Subject: Re: Optical IP activities References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit John, John Drake wrote: > > What we are proposing in draft-ceuppens-mpls-optical-00.txt is a different > approach to information hiding. Rather than taking the overlay model > approach and hiding all of the optical specific stuff (a non-pejorative > term) inside a network cloud, we would hide the optical stuff within the > representation of an individual IP links. This would still allow you to > support the overlay model, but it also allows you to support the peer model. I was going through the draft-ceuppens-mpls-optical-00.txt and could not find any details regarding "we would hide the optical stuff within the representation of an individual IP links". Where in the draft do you deal with this issue. Regards, Debanjan -- Debanjan Saha Phone: 732-923-4264 Tellium Optical Systems http://www.tellium.com From owner-mpls@UU.NET Wed Mar 22 12:07:44 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05343 for ; Wed, 22 Mar 2000 12:07:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqi26786; Wed, 22 Mar 2000 17:06:27 GMT Received: by mail-control.mail.uu.net id QQihqi07657 for mpls-outgoing; Wed, 22 Mar 2000 17:06:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihqi07586 for ; Wed, 22 Mar 2000 17:05:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqi11359 for ; Wed, 22 Mar 2000 12:05:21 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihqi27062 for ; Wed, 22 Mar 2000 17:05:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA05656 for mpls@uu.net; Wed, 22 Mar 2000 12:05:19 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihqi06280 for ; Wed, 22 Mar 2000 17:04:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqi11217 for ; Wed, 22 Mar 2000 12:04:23 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQihqi26285 for ; Wed, 22 Mar 2000 17:04:22 GMT Received: from tnadeau-pc02 (ch2-dhcp134-173.cisco.com [161.44.134.173]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA06173; Wed, 22 Mar 2000 12:04:14 -0500 (EST) Message-Id: <4.2.2.20000322114815.06c8d160@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 22 Mar 2000 11:53:24 -0500 To: Joan Cucchiara , "'Abes, Andi'" , Vijay Srinivasan , mpls@UU.NET From: "Thomas D. Nadeau" Subject: RE: LSR MIB last call In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F8A3@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_7070454==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_7070454==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, > > I didn't notice Adrian's mail, and the response from Tom. > > > > In any case, if Diff Serv is to be added later, can we > > rid of the XCCos, which is not enough for Diff Serv support > > and might generate (or has already done so) confusion ? > >I would be in favor of taking this object out of the LSR >MIB also for the reasons stated above It seems that there is a consensus building here to remove this object from the table. At this point three different folks have requested that it be removed. Unless we hear otherwise from other list members, we will remove this object in the next update. >It would also be my preference to remove the TSpec table and >put this into the TE MIB for the similar reasons. The LSR MIB, >should be able to support ALL MPLS protocols, and the TSpec >table is not relevant to LDP. Certainly, it would be easy enough >to Augment/extend tables in the LSR MIB in the TE MIB (or any other >MIB), so there is really no need to have objects in the LSR MIB >which are not supported all of the MPLS protocols. It would >be "cleaner" to have related functionality in the same MIBs, instead >of having chunks in the LSR MIB and chunks in another MIB. The purpose of the Tspec tables in the TE and the LSR MIBs are different. In the LSR MIB, the Tspec indicates the actual resource allocation for the LSP/LSPs in question. In the TE MIB, the Tspec indicates the desired Tspec for the tunnel. For these reasons, we feel that both tables are necessary. --Tom > -Joan > > > > > > > Andi. > > > > > > > > > -----Original Message----- > > > From: Abes, Andi [mailto:aabes@quarrytech.com] > > > Sent: Tuesday, March 21, 2000 11:50 AM > > > To: Vijay Srinivasan; mpls@UU.NET > > > Subject: RE: LSR MIB last call > > > > > > > > > I think this has been mentioned before, > > > but what support, if any is there for configuring and > > > representing Diff Serv capable LSP's ? > > > > > > The only mention I found is the XCCos, which > > > doesn't seem to be enough. > > > > > > I would expect the MIB to be capable of the following: > > > - Connect an InSegment to (eventually) an Output Segment > > > based both on Input IF, input Label and incoming EXP (COS) bits > > > > > > Preferably the inSegment would select the XC based on > > > label, and then > > > the XC would select a specific output segment based on EXP. > > > ( this is meant to allow conversion between incoming > > > E-LSP's to outgoing > > > L-LSP's as would be needed in an LSR with both Ethernet > > and LC-ATM > > > interfaces > > > for example) > > > > > > - Allow a mapping between incoming EXP to outgoing EXP, not > > > just a global > > > replacement (as is provided by XCCos). This could be > > > accomplished together > > > with > > > the previous point by indexing the XC table with EXP as > > > well. For LSP's > > > created by LDP, > > > a single value of 0 could be used. > > > > > > - For output segments, specify their type (E/L-LSP's), and > > > PHBID of the OA > > > carried over them. > > > > > > > > > This is my understanding of some of the requirements for > > > supporting Diff > > > Serv LSP's. > > > The Diff Serv over MPLS authors could have > > > better/greater/finer comments to > > > add to > > > this. > > > Have they been consulted on the issue ? I remeber Adrian > > > mentioning this > > > before > > > > > > Andi. > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Vijay Srinivasan [mailto:vsriniva@cosinecom.com] > > > Sent: Tuesday, March 21, 2000 11:01 AM > > > To: 'Joan Cucchiara'; 'tnadeau@cisco.com'; > > 'arun@force10networks.com'; > > > 'cheenu@tachion.com' > > > Cc: 'mpls@uu.net' > > > Subject: LSR MIB last call > > > > > > > > > > > > > > > The authors of the LSR MIB have requested that we progress > > > the document to > > > WG last call. I would like to commence the last call, ending > > > in two weeks > > > (due to the IETF in between). Joan's comments to the list will be > > > considered as part of the last call. > > > > > > - Vijay > > > > > > --=====================_7070454==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

> I didn't notice Adrian's mail, and the response from Tom.
>
> In any case, if Diff Serv is to be added later, can we
> rid of the XCCos, which is not enough for Diff Serv support
> and might generate (or has already done so) confusion ?

I would be in favor of taking this object out of the LSR
MIB also for the reasons stated above

        It seems that there is a consensus building here
to remove this object from the table. At this point three
different folks have requested that it be removed. Unless
we hear otherwise from other list members, we will remove
this object in the next update.

It would also be my preference to remove the TSpec table and
put this into the TE MIB for the similar reasons.  The LSR MIB,
should be able to support ALL MPLS protocols, and the TSpec
table is not relevant to LDP.  Certainly, it would be easy enough
to Augment/extend tables in the LSR MIB in the TE MIB (or any other
MIB), so there is really no need to have objects in the LSR MIB
which are not supported all of the MPLS protocols.   It would
be "cleaner" to have related functionality in the same MIBs, instead
of having chunks in the LSR MIB and chunks in another MIB. 

        The purpose of the Tspec tables in the TE and the LSR
MIBs are different. In the LSR MIB, the Tspec indicates
the actual resource allocation for the LSP/LSPs in question.
In the TE MIB, the Tspec indicates the desired Tspec for
the tunnel. For these reasons, we feel that both tables
are necessary.

        --Tom







   -Joan

>
>
> Andi.
>
>
>
> > -----Original Message-----
> > From: Abes, Andi [mailto:aabes@quarrytech.com]
> > Sent: Tuesday, March 21, 2000 11:50 AM
> > To: Vijay Srinivasan; mpls@UU.NET
> > Subject: RE: LSR MIB last call
> >
> >
> > I think this has been mentioned before,
> > but what support, if any is there for configuring and
> > representing Diff Serv capable LSP's ?
> > 
> > The only mention I found is the XCCos, which
> > doesn't seem to be enough.
> > 
> > I would expect the MIB to be capable of the following:
> > - Connect an InSegment to (eventually) an Output Segment
> >   based both on Input IF, input Label and incoming EXP (COS) bits
> > 
> >   Preferably the inSegment would select the XC based on
> > label, and then
> >   the XC would select a specific output segment based on EXP.
> >   ( this is meant to allow conversion between incoming
> > E-LSP's to outgoing
> >    L-LSP's as would be needed in an LSR with both Ethernet
> and LC-ATM
> > interfaces
> >    for example)
> > 
> > - Allow a mapping between incoming EXP to outgoing EXP, not
> > just a global
> >   replacement (as is provided by XCCos). This could be
> > accomplished together
> > with
> >   the previous point by indexing the XC table with EXP as
> > well. For LSP's
> > created by LDP,
> >   a single value of 0 could be used.
> > 
> > - For output segments, specify their type (E/L-LSP's), and
> > PHBID of the OA
> > carried over them.
> > 
> > 
> > This is my understanding of some of the requirements for
> > supporting Diff
> > Serv LSP's.
> > The Diff Serv over MPLS authors could have
> > better/greater/finer comments to
> > add to
> > this.
> > Have they been consulted on the issue ? I remeber Adrian
> > mentioning this
> > before
> > 
> > Andi.
> > 
> > 
> >  
> > 
> >  
> > 
> > 
> >
> > -----Original Message-----
> > From: Vijay Srinivasan [mailto:vsriniva@cosinecom.com]
> > Sent: Tuesday, March 21, 2000 11:01 AM
> > To: 'Joan Cucchiara'; 'tnadeau@cisco.com';
> 'arun@force10networks.com';
> > 'cheenu@tachion.com'
> > Cc: 'mpls@uu.net'
> > Subject: LSR MIB last call
> >
> >
> >
> >
> > The authors of the LSR MIB have requested that we progress
> > the document to
> > WG last call.  I would like to commence the last call, ending
> > in two weeks
> > (due to the IETF in between).  Joan's comments to the list will be
> > considered as part of the last call.
> >
> > - Vijay
> >
>

--=====================_7070454==_.ALT-- From owner-mpls@UU.NET Wed Mar 22 12:16:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08392 for ; Wed, 22 Mar 2000 12:16:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqj06681; Wed, 22 Mar 2000 17:15:51 GMT Received: by mail-control.mail.uu.net id QQihqj09084 for mpls-outgoing; Wed, 22 Mar 2000 17:15:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihqj09079 for ; Wed, 22 Mar 2000 17:15:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqi27158 for ; Wed, 22 Mar 2000 12:14:17 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihqi05151 for ; Wed, 22 Mar 2000 17:14:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA07253 for mpls@uu.net; Wed, 22 Mar 2000 12:14:15 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihqi08845 for ; Wed, 22 Mar 2000 17:13:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqi26671 for ; Wed, 22 Mar 2000 12:11:13 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQihqi02384 for ; Wed, 22 Mar 2000 17:11:12 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA23341; Wed, 22 Mar 2000 09:11:04 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Mar 2000 09:11:05 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4045E@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Noritoshi Demizu'" , mpls@UU.NET Subject: RE: Draft MPLS Agendan Date: Wed, 22 Mar 2000 09:08:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Version 05 will be available soon. Regards, -Shahram Davari >-----Original Message----- >From: Noritoshi Demizu [mailto:nori-d@is.aist-nara.ac.jp] >Sent: Wednesday, March 22, 2000 8:35 AM >To: mpls@UU.NET >Subject: Re: Draft MPLS Agendan > > >I made an HTML version of draft MPLS agenda at > >http://infonet.aist-nara.ac.jp/member/nori-d/mlr/article/MPLS-a >genda-0003.html >Of course, there are links to I-Ds. I did my best, but I am sorry if >there are errors. > >By the way, I could not find the following I-D. Where can I find it? >I temporary made a link to revision 04 in the current page above. > > Davari draft-ietf-mpls-diff-ext-05.txt 13 > >Thank you very much. > >Best Regards, >Noritoshi Demizu, NAIST > From owner-mpls@UU.NET Wed Mar 22 12:46:20 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19297 for ; Wed, 22 Mar 2000 12:46:20 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihql24450; Wed, 22 Mar 2000 17:45:35 GMT Received: by mail-control.mail.uu.net id QQihql10952 for mpls-outgoing; Wed, 22 Mar 2000 17:45:00 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihqk10930 for ; Wed, 22 Mar 2000 17:44:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihqk01646 for ; Wed, 22 Mar 2000 12:44:29 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQihqk23201 for ; Wed, 22 Mar 2000 17:44:28 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA23341 for ; Wed, 22 Mar 2000 09:44:28 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA19475 for mpls@uu.net; Wed, 22 Mar 2000 12:44:26 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihqg28466 for ; Wed, 22 Mar 2000 16:39:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqg21526 for ; Wed, 22 Mar 2000 11:39:04 -0500 (EST) Received: from pooh.aist-nara.ac.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [163.221.130.162]) id QQihqg03738 for ; Wed, 22 Mar 2000 16:39:03 GMT Received: from localhost by pooh.aist-nara.ac.jp (8.8.7/2.8Wb) id QAA28928; Wed, 22 Mar 2000 16:40:19 GMT From: Noritoshi Demizu To: mpls@UU.NET Subject: Re: Draft MPLS Agendan In-Reply-To: Your message of "Wed, 22 Mar 2000 22:35:04 +0900" References: <20000322223504X.demizu@dd.iij4u.or.jp> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 X-URL: http://infonet.aist-nara.ac.jp/member/nori-d/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000323014018U.demizu@dd.iij4u.or.jp> Date: Thu, 23 Mar 2000 01:40:18 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 10 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am very sorry that some of you got an error message when you access to the URL which I wrote in my previous mail. The problem was our file server went down just after I sent my previous mail. Now, the URL becomes accessible again. I am sorry for the inconvenience. >I made an HTML version of draft MPLS agenda at >http://infonet.aist-nara.ac.jp/member/nori-d/mlr/article/MPLS-agenda-0003.html Best Regards, Noritoshi Demizu, NAIST From owner-mpls@UU.NET Wed Mar 22 12:54:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22282 for ; Wed, 22 Mar 2000 12:54:35 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihql08987; Wed, 22 Mar 2000 17:53:42 GMT Received: by mail-control.mail.uu.net id QQihql11516 for mpls-outgoing; Wed, 22 Mar 2000 17:53:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihql11511 for ; Wed, 22 Mar 2000 17:52:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihql18555 for ; Wed, 22 Mar 2000 12:52:05 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQihql00927 for ; Wed, 22 Mar 2000 17:52:05 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id MAA01235; Wed, 22 Mar 2000 12:51:57 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id MAA42145; Wed, 22 Mar 2000 12:52:17 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003221752.MAA42145@curtis-lt.avici.com> To: Khaled Elsayed cc: Jagan Shantigram , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Reply-To: curtis@avici.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Tue, 21 Mar 2000 13:55:35 +0200." <38D76337.478CA5FC@ieee.org> Date: Wed, 22 Mar 2000 12:52:17 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > > > Hello Jagan, > > > When we do not have lambda conversion however, this problem cannot > > be solved optimally.. it is akin to the graph coloring > > problem - which ofcourse has heuristics that can get us to > > a factor (?) of the optimal solution. So, connections may > > be blocked even though there is capacity on the fiber to > > support it, just because the wavelength is already used up. > > > > Connections can be blocked when?? At service provisioning time or > at the time the connection is requested?? My point is a > connection of 2.48 Gbps is not likely to be a random event or an > ATM-like SVC. If a customer would require such huge bandwidth, it > would need that BW to go through or it would better look for > another carrier that will provide a TDM/leased line?? Of course > wavelength conversion can help build a better-utilized network, > no question about that. > > Khaled The exception to the rule that "a connection of 2.48 Gbps is not likely to be a random event" is where a very major event, possilble external to one's own network results in a shift in traffic patterns that is significant enough to require that additional lambdas be added to existing paths. The real world example in the ISP world is a failure of a peering point of some sort, a provider interconnect, a NAP or NAP connectivity of some party. Since all major ISPs are connected to each other at more than one geographically diverse peering point, the traffic will still flow, but the path will have changed. This may mean that a path that previously required 3 lambdas (for example), now requires 4 lambdas. There are at least 3 ways to accommodate this requirement: 1. An external management system adds a lambda to both the routers at either end and the optical switches (demonstrated at OFC). 2. The router signals the requirement/desire for an additional lambda to the adjacent optical switch which sets up a path. This is the overlay model. It can be trivially implemented with MPLS by having the router send a loose source hop in the ERO allowing the switch to create the path or reject the request. 3. The router has enough information about the characteristics of the optical devices to compute the path and so it does so. This is the peer model. The way this might manifest itself is LSPs that might take an optical path from A to C are going from A to B to C because A to C lambdas are too full. If so, then A could in principle request an additional lambda, but in practice the means to signal this has not been defined. Curtis From owner-mpls@UU.NET Wed Mar 22 14:51:00 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03863 for ; Wed, 22 Mar 2000 14:51:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqt08926; Wed, 22 Mar 2000 19:48:56 GMT Received: by mail-control.mail.uu.net id QQihqt04875 for mpls-outgoing; Wed, 22 Mar 2000 19:48:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihqt04870 for ; Wed, 22 Mar 2000 19:48:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqt23684 for ; Wed, 22 Mar 2000 14:47:55 -0500 (EST) Received: from exchsrv1.cosinecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQihqt16795 for ; Wed, 22 Mar 2000 19:47:55 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Mar 2000 11:47:46 -0800 Message-ID: From: Vijay Srinivasan To: "'mpls@uu.net'" Cc: "'swallow@cisco.com'" Subject: RE: LDP MIB last call Date: Wed, 22 Mar 2000 11:47:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9437.7F03238C" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9437.7F03238C Content-Type: text/plain; charset="iso-8859-1" The last call for the LDP MIB has closed. Could the authors please make changes based on comments during the last call and issue a new version? - Vijay > -----Original Message----- > From: Vijay Srinivasan > Sent: Thursday, March 09, 2000 10:30 AM > To: 'mpls@uu.net' > Cc: 'swallow@cisco.com' > Subject: LDP MIB last call > > > We would like to commence the last call for: > > Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) > draft-ietf-mpls-ldp-mib-05.txt > > Last call will end on Friday, March 17. Please send your comments to the list. > > Regards, > - Vijay > ------_=_NextPart_001_01BF9437.7F03238C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: LDP MIB last call

The last call for the LDP MIB has closed.  Could = the authors please make changes based on comments during the last call = and issue a new version?

- Vijay


>  -----Original Message-----
> From: =         Vijay Srinivasan  =
> Sent: Thursday, March 09, 2000 10:30 AM
> To:   'mpls@uu.net'
> Cc:   'swallow@cisco.com'
> Subject:      LDP MIB = last call
>
>
> We would like to commence the last call = for:
>
> Definitions of Managed Objects for the = Multiprotocol Label Switching, Label Distribution Protocol (LDP)
> draft-ietf-mpls-ldp-mib-05.txt
>
> Last call will end on Friday, March 17.  = Please send your comments to the list.
>
> Regards,
> - Vijay
>

------_=_NextPart_001_01BF9437.7F03238C-- From owner-mpls@UU.NET Wed Mar 22 16:09:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02341 for ; Wed, 22 Mar 2000 16:09:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqy24536; Wed, 22 Mar 2000 21:08:15 GMT Received: by mail-control.mail.uu.net id QQihqy26785 for mpls-outgoing; Wed, 22 Mar 2000 21:07:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihqy26753 for ; Wed, 22 Mar 2000 21:07:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqy23598 for ; Wed, 22 Mar 2000 16:07:22 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihqy13834 for ; Wed, 22 Mar 2000 21:07:21 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA12884 for mpls@uu.net; Wed, 22 Mar 2000 16:07:20 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihqy26468 for ; Wed, 22 Mar 2000 21:06:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihqy09075 for ; Wed, 22 Mar 2000 16:04:24 -0500 (EST) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQihqy21070 for ; Wed, 22 Mar 2000 21:04:24 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 1A846DD; Wed, 22 Mar 2000 22:04:20 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (flefauch-isdn-home.cisco.com [10.49.89.146]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id WAA17745; Wed, 22 Mar 2000 22:04:18 +0100 (MET) Message-Id: <200003222104.WAA17745@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 22 Mar 2000 22:02:54 +0100 To: vompls@lists.integralaccess.com From: Francois Le Faucheur Subject: Announcing draft-lefaucheur-vompls-bearer-cont-00.txt Cc: brucet@europe.cisco.com, alchiu@att.com, anttik@integralaccess.com, mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello, This is to announce that "Bearer Control for VoIP and VoMPLS Control Plane" is now available from : ftpeng.cisco.com/ftp/flefauch/ This draft will be presented during the VoMPLS BOF at the Adelaide meeting. Thanks Francois From owner-mpls@UU.NET Wed Mar 22 16:24:58 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08670 for ; Wed, 22 Mar 2000 16:24:58 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihqz09912; Wed, 22 Mar 2000 21:24:06 GMT Received: by mail-control.mail.uu.net id QQihqz28475 for mpls-outgoing; Wed, 22 Mar 2000 21:23:46 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihqz28454 for ; Wed, 22 Mar 2000 21:23:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqz12159 for ; Wed, 22 Mar 2000 16:21:56 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihqz23767 for ; Wed, 22 Mar 2000 21:21:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA15323 for mpls@uu.net; Wed, 22 Mar 2000 16:21:55 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihqz28380 for ; Wed, 22 Mar 2000 21:21:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihqy11085 for ; Wed, 22 Mar 2000 16:14:35 -0500 (EST) Received: from tnt.isi.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tnt.isi.edu [128.9.128.128]) id QQihqy18774 for ; Wed, 22 Mar 2000 21:14:34 GMT Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA22174; Wed, 22 Mar 2000 13:14:31 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id VAA09916; Wed, 22 Mar 2000 21:14:31 GMT Date: Wed, 22 Mar 2000 21:14:31 GMT Message-Id: <200003222114.VAA09916@gra.isi.edu> To: rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com Subject: Re: Semantics of shared reservations (with RSVP) X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> *> R2 ---- R3 *> / \ *> H1 ---- R1 R6 ---- R7 ---- H2 *> \ / *> R4 ---- R5 *> *> H1 sends out two Path messages (with different explicit route objects) *> to H2. *> This seems a little strange. How/why would an end host H1 know about the failover path in the middle of the network?? It seems to me more likely that R1 knows about this magic for Path messages, and can also do magic for Resv messages. Note that Explicit Route objects were pasted onto RSVP by someone other than the RSVP WG, and I don't know that anyone has thoroughly investigated the consequences. Bob Braden From owner-mpls@UU.NET Wed Mar 22 17:14:51 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27133 for ; Wed, 22 Mar 2000 17:14:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihrc11079; Wed, 22 Mar 2000 22:13:59 GMT Received: by mail-control.mail.uu.net id QQihrc09694 for mpls-outgoing; Wed, 22 Mar 2000 22:13:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihrc09689 for ; Wed, 22 Mar 2000 22:13:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihrc05250 for ; Wed, 22 Mar 2000 17:13:21 -0500 (EST) Received: from mailgate.fore.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQihrc19058 for ; Wed, 22 Mar 2000 22:13:21 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA12586; Wed, 22 Mar 2000 17:13:13 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA27614; Wed, 22 Mar 2000 17:13:15 -0500 (EST) Message-ID: <38D94582.6A9CC68D@fore.com> Date: Wed, 22 Mar 2000 17:13:22 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@ISI.EDU, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <200003222114.VAA09916@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bob Braden wrote: >> >> R2 ---- R3 >> / \ >> H1 ---- R1 R6 ---- R7 ---- H2 >> \ / >> R4 ---- R5 >> >> H1 sends out two Path messages (with different explicit route >> objects) to H2. > > This seems a little strange. How/why would an end host H1 know about > the failover path in the middle of the network?? It seems to me more > likely that R1 knows about this magic for Path messages, and can also > do magic for Resv messages. Sorry for the confusion here (I've been saying that a lot recently - I must start using terminology that everybody else understands). I chose to call the ends "H" because they perform the role that hosts do in a straight-RSVP environment - initiating and terminating RSVP messages. In the scenario I was thinking of, H1 and H2 are actually MPLS edge routers (LERs). They know about the full topology (and therefore know about the failover path). They are differentiated from the "R" routers in that they initiate the RSVP signalling when establishing LSPs between each other. > Note that Explicit Route objects were pasted onto RSVP by someone > other than the RSVP WG, and I don't know that anyone has thoroughly > investigated the consequences. Understood. This is the reason I posted my question to both the RSVP and MPLS lists. I figure that what one group doesn't know, the other may be able to answer. After reading replies messages by others, it appears that my understanding of how SE works was flawed, and the perceived problem does not actually exist. The one problem remaining, which doesn't appear to be covered by RSVP-TE or MPLS is how the ingress node (host or router) can tell the egress node that two paths are meant to share resources. I suppose this is a more generic RSVP issue as well. If it is desired that the sender choose the reservation style, this choice can not be signalled through any standard object in the Path message. It must be signalled out-of-band, or through a non-standard extension - in either case, something beyond the RSVP spec must be supported by both ends for this. It seems to me that it would be a good idea to have a mechanism for the sender to request a style of the recipient. (Of course, the recipient would still be free to ignore this request - to do otherwise would break existing implementations.) Perhaps via a new service type in the ADSPEC or something similar. -- David From owner-mpls@UU.NET Wed Mar 22 17:25:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00538 for ; Wed, 22 Mar 2000 17:25:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihrd27250; Wed, 22 Mar 2000 22:24:56 GMT Received: by mail-control.mail.uu.net id QQihrd10441 for mpls-outgoing; Wed, 22 Mar 2000 22:24:34 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihrd10436 for ; Wed, 22 Mar 2000 22:24:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihrd07150 for ; Wed, 22 Mar 2000 17:24:25 -0500 (EST) Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQihrd26777 for ; Wed, 22 Mar 2000 22:24:24 GMT Received: from ganeshpc (ganesh-pc.laurelnetworks.com [192.168.0.30]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id RAA21592; Wed, 22 Mar 2000 17:24:20 -0500 From: "Ganesh Murugesan" To: "David Charlap" , , Subject: RE: Semantics of shared reservations (with RSVP) Date: Wed, 22 Mar 2000 17:26:43 -0800 Message-ID: <002401bf9466$d8c49480$8ac6fea9@laurelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <38D94582.6A9CC68D@fore.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > The one problem remaining, which doesn't appear to be covered by RSVP-TE > or MPLS is how the ingress node (host or router) can tell the egress > node that two paths are meant to share resources. > > I suppose this is a more generic RSVP issue as well. If it is desired > that the sender choose the reservation style, this choice can not be > signalled through any standard object in the Path message. It must be > signalled out-of-band, or through a non-standard extension - in either > case, something beyond the RSVP spec must be supported by both ends for > this. > > It seems to me that it would be a good idea to have a mechanism for the > sender to request a style of the recipient. (Of course, the recipient > would still be free to ignore this request - to do otherwise would break > existing implementations.) Perhaps via a new service type in the ADSPEC > or something similar. > > -- David > I am not sure if this is what you are asking for. The RSVP Extension for LSP tunnels draft has this section about the Session Attributes Object: 0x04 = Ingress node may reroute This flag indicates that the tunnel ingress node may choose to reroute this tunnel without tearing it down. A tunnel egress node SHOULD use the SE Style when responding with a Resv message. The above sentence seems to indicate that the Ingress can indeed signal to the egress as to whether it should choose SE style or not. thanks ganesh From owner-mpls@UU.NET Wed Mar 22 17:35:22 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03595 for ; Wed, 22 Mar 2000 17:35:22 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihre03905; Wed, 22 Mar 2000 22:34:26 GMT Received: by mail-control.mail.uu.net id QQihre10758 for mpls-outgoing; Wed, 22 Mar 2000 22:34:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihre10751 for ; Wed, 22 Mar 2000 22:33:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihre08651 for ; Wed, 22 Mar 2000 17:33:39 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihre03185 for ; Wed, 22 Mar 2000 22:33:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA26069 for mpls@uu.net; Wed, 22 Mar 2000 17:33:38 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihre10712 for ; Wed, 22 Mar 2000 22:32:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihre08415 for ; Wed, 22 Mar 2000 17:32:11 -0500 (EST) Received: from tnt.isi.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tnt.isi.edu [128.9.128.128]) id QQihre02161 for ; Wed, 22 Mar 2000 22:32:11 GMT Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA03869; Wed, 22 Mar 2000 14:32:09 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA09985; Wed, 22 Mar 2000 22:32:08 GMT Date: Wed, 22 Mar 2000 22:32:08 GMT Message-Id: <200003222232.WAA09985@gra.isi.edu> To: rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com Subject: Re: Semantics of shared reservations (with RSVP) X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> *> The one problem remaining, which doesn't appear to be covered by RSVP-TE *> or MPLS is how the ingress node (host or router) can tell the egress *> node that two paths are meant to share resources. *> *> I suppose this is a more generic RSVP issue as well. If it is desired *> that the sender choose the reservation style, this choice can not be *> signalled through any standard object in the Path message. It must be *> signalled out-of-band, or through a non-standard extension - in either *> case, something beyond the RSVP spec must be supported by both ends for *> this. If I understand your problem, it is not really the reservation style you want to signal -- both ends KNOW that SE is to be used -- but some resource-sharing identifier tag. Is this correct? Bob From owner-mpls@UU.NET Wed Mar 22 18:05:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13081 for ; Wed, 22 Mar 2000 18:05:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihrg28883; Wed, 22 Mar 2000 23:04:05 GMT Received: by mail-control.mail.uu.net id QQihrg16754 for mpls-outgoing; Wed, 22 Mar 2000 23:03:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihrg16745 for ; Wed, 22 Mar 2000 23:03:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihrg00025 for ; Wed, 22 Mar 2000 18:03:12 -0500 (EST) Received: from mailgate.fore.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQihrg27907 for ; Wed, 22 Mar 2000 23:03:11 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id SAA17042; Wed, 22 Mar 2000 18:03:09 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id SAA06418; Wed, 22 Mar 2000 18:03:11 -0500 (EST) Message-ID: <38D95135.30A0046D@fore.com> Date: Wed, 22 Mar 2000 18:03:17 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@isi.edu, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <200003222232.WAA09985@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bob Braden wrote: >> >> The one problem remaining, which doesn't appear to be covered by >> RSVP-TE or MPLS is how the ingress node (host or router) can tell the >> egress node that two paths are meant to share resources. >> >> I suppose this is a more generic RSVP issue as well. If it is >> desired that the sender choose the reservation style, this choice can >> not be signalled through any standard object in the Path message. It >> must be signalled out-of-band, or through a non-standard extension - >> in either case, something beyond the RSVP spec must be supported by >> both ends for this. > > If I understand your problem, it is not really the reservation style > you want to signal -- both ends KNOW that SE is to be used -- but some > resource-sharing identifier tag. Is this correct? OK. Let me see if I can explain my assumptions and my question more clearly. Based on what others here have written, I understand that all paths in a single session that are reseved with SE style must share resources, right? This means that if a tunnel-ingress node sets up two different paths in the same session (differing only by their ERO), the decision on whether these two tunnels will share resources will be made by the egress node when it chooses a style for the reservation - SE for sharing, FF for no sharing. Sharing makes sense if the two paths are to be used for a primary/backup fail-over scenario. Where one carries all data until it fails, then the ingress node immediately starts sending data over the backup path. This way, it doesn't have to wait for a new path to be signalled. (Note that this is not the make-before-break scenario of the MPLS-RSVP draft. That scenario doesn't set up the backup tunnel until it is time move traffic to it.) In other situations, not sharing makes sense. For instance, if the two paths are to be used for a load-balancing scenario. Where the ingress node sends packets over both tunnels. (Hopefully, with enough intelligence so that TCP doesn't end up breaking.) In this scenario, FF would be the preferred style. (Of course, this effect could also be created by using two sessions and either style.) In short, I can see reasons why it would make sense for two tunnels in the same session from a single sender node to use FF or SE style. But the ingress node has no standard way of indicating in its Path message that it wants to use one style or another. The decision depends on something else (probably administrative configuration of the egress nodes.) I hope this is clearer. -- David From owner-mpls@UU.NET Wed Mar 22 18:28:56 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22539 for ; Wed, 22 Mar 2000 18:28:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihrh20015; Wed, 22 Mar 2000 23:27:48 GMT Received: by mail-control.mail.uu.net id QQihrh21767 for mpls-outgoing; Wed, 22 Mar 2000 23:27:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihrh21762 for ; Wed, 22 Mar 2000 23:27:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihrh04221 for ; Wed, 22 Mar 2000 18:27:06 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihrh20664 for ; Wed, 22 Mar 2000 23:27:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA04598 for mpls@uu.net; Wed, 22 Mar 2000 18:27:05 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihrh21746 for ; Wed, 22 Mar 2000 23:26:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihrh04119 for ; Wed, 22 Mar 2000 18:26:20 -0500 (EST) Received: from tnt.isi.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tnt.isi.edu [128.9.128.128]) id QQihrh19937 for ; Wed, 22 Mar 2000 23:26:20 GMT Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA11791; Wed, 22 Mar 2000 15:26:18 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA10069; Wed, 22 Mar 2000 23:26:17 GMT Date: Wed, 22 Mar 2000 23:26:17 GMT Message-Id: <200003222326.XAA10069@gra.isi.edu> To: rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com Subject: Re: Semantics of shared reservations (with RSVP) X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk David, Thanks for taking the trouble to explain to me. But I must admit I am still unconvinced. There are two "scenarios" at issue: failover vs. load balancing, which have completely different semantics. I would expect that all the nodes (at least the ingress and egress) must be solidly configured for one or the other of these "scenarios", and the scenario will imply the correct reservation style. But then, I am just an academic, what do I know? As far the original issue is concerned, I had trouble following the discussion, but here is what seems like a simple way to think about it. In sending out two paths, H1 is serving as two logical senders, distinguished by ERO. I don't know if this is the way it DOES work, but it OUGHT to work just fine if H2 sends a Resv(SE, Q, (ERO1, ERO2)), which R6 splits into Resv(SE, Q, (ERO1)) and Resv(SE, Q, (ERO2)) along the two paths. These get merged again by R1 into Resv(SE, Q, (ERO1, ERO2)). This creates one shared reservation at H1, as desired. Bob Braden From owner-mpls@UU.NET Wed Mar 22 18:47:48 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28478 for ; Wed, 22 Mar 2000 18:47:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihrj11826; Wed, 22 Mar 2000 23:46:58 GMT Received: by mail-control.mail.uu.net id QQihrj22937 for mpls-outgoing; Wed, 22 Mar 2000 23:46:21 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihrj22869 for ; Wed, 22 Mar 2000 23:46:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihrj07323 for ; Wed, 22 Mar 2000 18:45:52 -0500 (EST) Received: from mailgate.fore.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQihrj05680 for ; Wed, 22 Mar 2000 23:45:52 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id SAA20225; Wed, 22 Mar 2000 18:45:44 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id SAA11867; Wed, 22 Mar 2000 18:45:47 -0500 (EST) Message-ID: <38D95B31.F3D3F2C0@fore.com> Date: Wed, 22 Mar 2000 18:45:53 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: rsvp@ISI.EDU, mpls@UU.NET Subject: Re: Semantics of shared reservations (with RSVP) References: <200003222326.XAA10069@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bob Braden wrote: > > Thanks for taking the trouble to explain to me. But I must admit I am > still unconvinced. There are two "scenarios" at issue: failover vs. > load balancing, which have completely different semantics. I would > expect that all the nodes (at least the ingress and egress) must be > solidly configured for one or the other of these "scenarios", and > the scenario will imply the correct reservation style. Perhps, but it seems to me that only the ingress node (which classifies the packets into one tunnel or the other) really needs to know anything special, if the correct reservation style is chosen at the other end. > As far the original issue is concerned, I had trouble following the > discussion, but here is what seems like a simple way to think about > it. In sending out two paths, H1 is serving as two logical senders, > distinguished by ERO. I don't know if this is the way it DOES work, > but it OUGHT to work just fine if H2 sends a Resv(SE, Q, (ERO1, > ERO2)), which R6 splits into Resv(SE, Q, (ERO1)) and Resv(SE, Q, > (ERO2)) along the two paths. These get merged again by R1 into > Resv(SE, Q, (ERO1, ERO2)). This creates one shared reservation at H1, > as desired. Correct. My original question was based on a gross misunderstanding of SE. I was under the impression that a single session under SE could have multiple flow descriptors - that is, multiple groups of senders that share resources within the group but not with other groups. Based on other posts here, which encouraged me to look more closely at the RFCs, I now believe that I was wrong in that assumption. So the original problem (of how R1 can properly re-merge the two single-sender reservations back into a single shared reservation) no longer exists. I can go into the details of my original misunderstanding if you're interested, but I'll take that off the list, since it really isn't relevant. -- David From owner-mpls@UU.NET Wed Mar 22 19:56:52 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24090 for ; Wed, 22 Mar 2000 19:56:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihrn20702; Thu, 23 Mar 2000 00:55:53 GMT Received: by mail-control.mail.uu.net id QQihrn04791 for mpls-outgoing; Thu, 23 Mar 2000 00:55:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihrn04786 for ; Thu, 23 Mar 2000 00:55:30 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihrn16265 for ; Wed, 22 Mar 2000 19:55:25 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQihrn21237 for ; Thu, 23 Mar 2000 00:55:24 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id TAA00146; Wed, 22 Mar 2000 19:55:17 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id TAA43297; Wed, 22 Mar 2000 19:55:33 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003230055.TAA43297@curtis-lt.avici.com> To: David Charlap cc: rsvp@isi.edu, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Semantics of shared reservations (with RSVP) In-reply-to: Your message of "Wed, 22 Mar 2000 18:03:17 EST." <38D95135.30A0046D@fore.com> Date: Wed, 22 Mar 2000 19:55:33 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <38D95135.30A0046D@fore.com>, David Charlap writes: > Bob Braden wrote: > >> > >> The one problem remaining, which doesn't appear to be covered by > >> RSVP-TE or MPLS is how the ingress node (host or router) can tell the > >> egress node that two paths are meant to share resources. > >> > >> I suppose this is a more generic RSVP issue as well. If it is > >> desired that the sender choose the reservation style, this choice can > >> not be signalled through any standard object in the Path message. It > >> must be signalled out-of-band, or through a non-standard extension - > >> in either case, something beyond the RSVP spec must be supported by > >> both ends for this. > > > > If I understand your problem, it is not really the reservation style > > you want to signal -- both ends KNOW that SE is to be used -- but some > > resource-sharing identifier tag. Is this correct? > > OK. Let me see if I can explain my assumptions and my question more > clearly. > > Based on what others here have written, I understand that all paths in a > single session that are reseved with SE style must share resources, > right? > > This means that if a tunnel-ingress node sets up two different paths in > the same session (differing only by their ERO), the decision on whether > these two tunnels will share resources will be made by the egress node > when it chooses a style for the reservation - SE for sharing, FF for no > sharing. > > Sharing makes sense if the two paths are to be used for a primary/backup > fail-over scenario. Where one carries all data until it fails, then the > ingress node immediately starts sending data over the backup path. This > way, it doesn't have to wait for a new path to be signalled. (Note that > this is not the make-before-break scenario of the MPLS-RSVP draft. That > scenario doesn't set up the backup tunnel until it is time move traffic > to it.) > > In other situations, not sharing makes sense. For instance, if the two > paths are to be used for a load-balancing scenario. Where the ingress > node sends packets over both tunnels. (Hopefully, with enough > intelligence so that TCP doesn't end up breaking.) In this scenario, FF > would be the preferred style. (Of course, this effect could also be > created by using two sessions and either style.) > > In short, I can see reasons why it would make sense for two tunnels in > the same session from a single sender node to use FF or SE style. But > the ingress node has no standard way of indicating in its Path message > that it wants to use one style or another. The decision depends on > something else (probably administrative configuration of the egress > nodes.) > > I hope this is clearer. > > -- David > David, Bob, Hope this helps: Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-05.txt February 2000 ... 2.4.3. Shared Explicit (SE) Style The Shared Explicit (SE) style allows a receiver to explicitly specify the senders to be included in a reservation. There is a single reservation on a link for all the senders listed. Because each sender is explicitly listed in the Resv message, different labels may be assigned to different senders, thereby creating separate LSPs. SE style reservations can be provided using multipoint-to-point label-switched-path or LSP per sender. Multipoint-to-point LSPs may be used when path messages do not carry the EXPLICIT_ROUTE object, or when Path messages have identical EXPLICIT_ROUTE objects. In either of these cases a common label may be assigned. Path messages from different senders can each carry their own ERO, and the paths taken by the senders can converge and diverge at any point in the network topology. When Path messages have differing EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object must be established. The next section explains how to use this to reroute tunnels. It explains when reservation amounts can be shared when doing make-before-break rerouting. A further restriction is found in another draft. Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-05.txt February 2000 3.6 E-LSP Merging In an MPLS domain, two or more LSPs can be merged into one LSP at one LSR. E-LSPs are compatible with LSP Merging under the following condition: E-LSPs can only be merged into one LSP if they support the exact same set of BAs. ... 4.6 L-LSP Merging In an MPLS domain, two or more LSPs can be merged into one LSP at one LSR. The proposed support of Diff-Serv in MPLS is compatible with LSP Merging under the following condition: L-LSPs can only be merged into one L-LSP if they support the same PSC. This seems clear enough once you find it. Curtis From owner-mpls@UU.NET Thu Mar 23 07:53:31 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19853 for ; Thu, 23 Mar 2000 07:53:30 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihtj22731; Thu, 23 Mar 2000 12:50:33 GMT Received: by mail-control.mail.uu.net id QQihtj18843 for mpls-outgoing; Thu, 23 Mar 2000 12:50:07 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihtj18829 for ; Thu, 23 Mar 2000 12:49:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihtj12133; Thu, 23 Mar 2000 07:49:55 -0500 (EST) Received: from ckmso1.proxy.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ckmso1.att.com [12.20.58.69]) id QQihtj21997; Thu, 23 Mar 2000 12:49:55 GMT Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id HAA07358; Thu, 23 Mar 2000 07:49:54 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id HAA11230; Thu, 23 Mar 2000 07:49:08 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 07:49:57 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA01BBD79C@njc240po03.ho.att.com> From: "Ash, Gerald R (Jerry), ALARC" To: te-wg@UU.NET Cc: "Ash, Gerald R (Jerry), ALARC" , mpls@UU.NET Subject: TE & QoS Methods for IP-,ATM-,& TDM-Based Multiservice Networks Date: Thu, 23 Mar 2000 07:49:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk PDF files (with figures, 01 version), for can be located at: http://www.research.att.com/~dgallo/jerryash/ The draft will be presented at the Monday, March 22 TEWG meeting. Comments welcome. Thanks, Jerry Ash ------------------------------------------------------------ Gerald R. (Jerry) Ash AT&T Labs Middletown, NJ, USA gash@att.com ------------------------------------------------------------ To: IETF-Announce: ; Subject: I-D ACTION:draft-ash-te-qos-routing-00.txt From: Internet-Drafts@ietf.org Date: Wed, 15 Mar 2000 06:24:29 -0500 Reply-to: Internet-Drafts@ietf.org Sender: nsyracus@cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Traffic Engineering & QoS Methods for IP-,ATM-,& TDM-Based Multiservice Networks Author(s) : G. Ash Filename : draft-ash-te-qos-routing-00.txt Pages : 12 Date : 14-Mar-00 This contribution proposes initial text for a new recommendation on traffic engineering (TE) and QoS methods for IP-, ATM-. & TDM-based multiservice networks. This contribution describes and recommends TE methods which control a network's response to traffic demands and other stimuli, such as link failures or node failures. These TE methods include: (a) traffic management through control of routing functions, which include call routing (number/name translation to routing address), connection routing, QoS resource management, and routing table management. (b)capacity management through control of network design. (c)TE operational requirements for traffic management and capacity management, including forecasting, performance monitoring, and short-term network adjustment. These TE methods are recommended for application across network types based on established practice and experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-te-qos-routing-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ash-te-qos-routing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ash-te-qos-routing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. From owner-mpls@UU.NET Thu Mar 23 09:18:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19757 for ; Thu, 23 Mar 2000 09:18:03 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihtp14084; Thu, 23 Mar 2000 14:16:46 GMT Received: by mail-control.mail.uu.net id QQihtp09995 for mpls-outgoing; Thu, 23 Mar 2000 14:16:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihtp09957 for ; Thu, 23 Mar 2000 14:16:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihtp24912 for ; Thu, 23 Mar 2000 09:15:56 -0500 (EST) Received: from mail-green.research.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQihtp02676 for ; Thu, 23 Mar 2000 14:15:56 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 8032B1E02A; Thu, 23 Mar 2000 09:15:55 -0500 (EST) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id JAA29829; Thu, 23 Mar 2000 09:15:51 -0500 (EST) Reply-To: From: "John Strand" To: , , Cc: Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Thu, 23 Mar 2000 09:15:41 -0500 Message-ID: <021a01bf94d2$46149420$3e82cf87@pcstranded.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <01BF9391.97EA5100.Vishal.Sharma@tellabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA19757 Another good reference is the online IEEE survey article "Wavelength Converters in Dynamically Reconfigurable Networks" by Jennifer Yates et al. URL=http://www.comsoc.org/pubs/surveys/ (in the 2nd quarter 1999 edition). John -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vishal Sharma Sent: Wednesday, March 22, 2000 12:00 AM To: 'lee.thomas@wcom.com'; khaled@ieee.org Cc: mpls@UU.NET Subject: RE: Comments on draft-ip-optical-framework-00.txt Lee, A partial response to your question below. There are situations where some form of "limited" wavelength conversion might be sufficient to give good performance and full wavelength conversion may not be needed or be worthwhile. (Strictly speaking, there is still wavelength conversion in this scheme, just not as much of it as you would need for full wavelength conversion, and this could be a significant cost and/or implementation advantage.) There are some research papers on this subject. Some relevant references are: Yates, J.; Lacey, J.; Everitt, D.; Summerfield, M. Limited-range wavelength translation in all-optical networks. IN: Proceedings of IEEE INFOCOM '96. Conference on Computer Communications, San Francisco, CA, USA, 24-28 March 1996. p. 954-61 vol.3. Sharma, V.; Varvarigos, E.A. Limited wavelength translation in all-optical WDM mesh networks. IN: Proceedings IEEE INFOCOM'98, San Francisco, CA, USA, 29 March-2 April 1998. p. 893-901 vol.2. Ramaswami, R.; Sasaki, G. Multiwavelength optical networks with limited wavelength conversion. IEEE/ACM Transactions on Networking, Dec. 1998, vol.6, (no.6):744-54. Venugopal, K.R.; Shivakumar, M.; Kumar, P.S. A heuristic for placement of limited range wavelength converters in all-optical networks. IN: Proceedings of INFOCOM'99: Conference on Computer Communications, New York, NY, USA, 21-25 March 1999, p. 908-15 vol.2. Tripathi, T.; Sivarajan, K.N. Computing approximate blocking probabilities in wavelength routed all-optical networks with limited-range wavelength conversion. IN: Proceedings of INFOCOM'99: Conference on Computer Communications, New York, NY, USA, 21-25 March 1999. p. 329-36 vol.1. Regards, -Vishal On Tuesday, March 21, 2000 6:21 PM, lee.thomas@wcom.com [SMTP:lee.thomas@wcom.com] wrote: > > > Peter Ashwood-Smith wrote: > > You may waste enormous amounts of bandwidth if you cannot do > > wavelength conversion. Convert the question to the ATM domain and > > imagine how an ATM network would operate if you had to use the > > same VCC from end to end. Basically, if you do not have the ability > > to change "labels" then you need one label for EVERY unique path > > through the network. Given that the number of paths through a network > > grows what .. N factorial? You run out of labels very quickly. This is > > especially true with DWDM equipement which may only support 50-100 > "labels". > > This means that a tiny network would exhaust all the labels/paths > > AND you have many links that you can only use a small percentage of > > the available "labels" ie bandwidth. So its a very unsatisfactory > > solution. Also, to do a good job of it, you need a global view of > > each path and label it will use. > > > > I am not questioning the usefulness of wavelength conversion. It > is definitely a good mechansim. (Although I have seen some > research work that claims that wavelenght conversion may not be > worthwhile in some scenarios). > > Khaled, > > Could you provide links to some of this research or describe some scenarios > where wavelength conversion may not be worthwhile? > > Thanks, > > Lee > From owner-mpls@UU.NET Thu Mar 23 09:42:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27627 for ; Thu, 23 Mar 2000 09:42:56 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihtq26318; Thu, 23 Mar 2000 14:41:16 GMT Received: by mail-control.mail.uu.net id QQihtq12209 for mpls-outgoing; Thu, 23 Mar 2000 14:40:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihtq12198 for ; Thu, 23 Mar 2000 14:40:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihtq12675 for ; Thu, 23 Mar 2000 09:40:28 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQihtq04647 for ; Thu, 23 Mar 2000 14:40:27 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA20227 for ; Thu, 23 Mar 2000 06:40:27 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA22485 for mpls@uu.net; Thu, 23 Mar 2000 09:40:25 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihsu03950 for ; Thu, 23 Mar 2000 09:00:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihsu03701 for ; Thu, 23 Mar 2000 04:00:13 -0500 (EST) Received: from wayout.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [163.121.142.3]) id QQihsu27075 for ; Thu, 23 Mar 2000 09:00:08 GMT Received: from ieee.org ([209.58.43.170]) by wayout.net (8.8.5/8.7.3) with ESMTP id LAA18420; Thu, 23 Mar 2000 11:17:39 +0200 (EET) Message-ID: <38D9DBCB.B3116142@ieee.org> Date: Thu, 23 Mar 2000 10:54:35 +0200 From: Khaled Elsayed X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Vishal.Sharma@tellabs.com" CC: "'lee.thomas@wcom.com'" , "mpls@UU.NET" , ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <01BF9391.97EA5100.Vishal.Sharma@tellabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lee, In addition to what Vishal listed, you can refer to IEEE JSAC vol. 14 no 5 (1996) and IEEE JSAC vol. 16 no 7 (1998) for some good articles. Khaled Vishal Sharma wrote: > > Lee, > > A partial response to your question below. > > There are situations where some form of "limited" wavelength conversion > might be sufficient to give good performance > and full wavelength conversion may not be needed or be worthwhile. > (Strictly speaking, there is still wavelength conversion in this scheme, > just not as much of it as you would need for full wavelength conversion, > and this could be a significant cost and/or implementation advantage.) > > There are some research papers on this subject. Some relevant references are: > > Yates, J.; Lacey, J.; Everitt, D.; Summerfield, M. > Limited-range wavelength translation in all-optical networks. > IN: Proceedings of IEEE INFOCOM '96. Conference on > Computer Communications, San Francisco, CA, USA, 24-28 March 1996. p. 954-61 vol.3. > > Sharma, V.; Varvarigos, E.A. > Limited wavelength translation in all-optical WDM mesh networks. > IN: Proceedings IEEE > INFOCOM'98, San Francisco, CA, USA, 29 March-2 April 1998. p. 893-901 vol.2. > > Ramaswami, R.; Sasaki, G. > Multiwavelength optical networks with limited wavelength conversion. > IEEE/ACM Transactions on Networking, Dec. 1998, vol.6, (no.6):744-54. > > Venugopal, K.R.; Shivakumar, M.; Kumar, P.S. > A heuristic for placement of limited range wavelength converters in > all-optical networks. > IN: Proceedings of INFOCOM'99: Conference on Computer > Communications, New York, NY, USA, 21-25 March 1999, p. 908-15 vol.2. > > Tripathi, T.; Sivarajan, K.N. > Computing approximate blocking probabilities in wavelength routed > all-optical networks with limited-range wavelength conversion. > IN: Proceedings of INFOCOM'99: Conference on Computer > Communications, New York, NY, USA, 21-25 March 1999. p. 329-36 vol.1. > > > Regards, > > -Vishal > > On Tuesday, March 21, 2000 6:21 PM, lee.thomas@wcom.com [SMTP:lee.thomas@wcom.com] wrote: > > > > > > Peter Ashwood-Smith wrote: > > > You may waste enormous amounts of bandwidth if you cannot do > > > wavelength conversion. Convert the question to the ATM domain and > > > imagine how an ATM network would operate if you had to use the > > > same VCC from end to end. Basically, if you do not have the ability > > > to change "labels" then you need one label for EVERY unique path > > > through the network. Given that the number of paths through a network > > > grows what .. N factorial? You run out of labels very quickly. This is > > > especially true with DWDM equipement which may only support 50-100 > > "labels". > > > This means that a tiny network would exhaust all the labels/paths > > > AND you have many links that you can only use a small percentage of > > > the available "labels" ie bandwidth. So its a very unsatisfactory > > > solution. Also, to do a good job of it, you need a global view of > > > each path and label it will use. > > > > > > > I am not questioning the usefulness of wavelength conversion. It > > is definitely a good mechansim. (Although I have seen some > > research work that claims that wavelenght conversion may not be > > worthwhile in some scenarios). > > > > Khaled, > > > > Could you provide links to some of this research or describe some scenarios > > where wavelength conversion may not be worthwhile? > > > > Thanks, > > > > Lee > > From owner-mpls@UU.NET Thu Mar 23 09:45:04 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28333 for ; Thu, 23 Mar 2000 09:45:04 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihtq29921; Thu, 23 Mar 2000 14:44:03 GMT Received: by mail-control.mail.uu.net id QQihtq12444 for mpls-outgoing; Thu, 23 Mar 2000 14:43:28 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihtq12421 for ; Thu, 23 Mar 2000 14:43:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihtq13254 for ; Thu, 23 Mar 2000 09:42:50 -0500 (EST) From: John.Shaw@tellabs.com Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQihtq07091 for ; Thu, 23 Mar 2000 14:42:50 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id IAA29708 for ; Thu, 23 Mar 2000 08:42:47 -0600 (CST) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA25710 for ; Thu, 23 Mar 2000 08:42:49 -0600 (CST) X-OpenMail-Hops: 1 Date: Thu, 23 Mar 2000 08:42:49 -0600 Message-Id: Subject: RE: RE: LDP/CR-LDP MIME-Version: 1.0 TO: YickBeng.Gan@tellabs.com, mpls@UU.NET Content-Type: multipart/alternative; boundary=openmail-part-0df8d2b4-00000002 Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-0df8d2b4-00000002 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Thu, 23 Mar 2000 08:42:49 -0600" Content-Transfer-Encoding: 8bit VPNs and QoS are created by edge routers and can be done in many ways, some discusssed openly in IETF and others more vendor-specific. Cisco uses BGP-based RFC-2457 as a means to distribute VPN membership information among the edge routers. everst intent was to establish virtual routers at the time IP interfaces are provisioned. Cisco uses RSVP to signal L2 paths to create specifc LSPs for the VPNs. Everest was planning to use ATM-SVCs, then evolve to LSPs and would be indifferent to RSVP vs. CR-LDP. QoS has many more options, most that say to have a different LSP to the same edge-edge path for each QoS class. These can be set up using RSVP or CR-LDP. Different vendors have different approaches to QoS. Our approach is the triggfers and treatments model. We will initially map into different ATM SVCs with travel p rofiles. As we implement MPLS with LER, we would map different classes into LSPs that have traffic profiles created using CR-LDP or RSVP. AS a transit LSR, we only woiuld need to support whatever scheme the LERs implement, assuming they are compatible. I would not suppose that different vendors like Cisco or Nortel would have similar apporaches to QoS or VPNs, where they can't even agree on simpler things. -----Original Message----- From: Gan, YickBeng /sg,its Sent: Tuesday, March 21, 2000 8:41 PM To: mpls@UU.NET Cc: Gan, YickBeng /sg,its Subject: FW: RE: LDP/CR-LDP Hi All I'm quite new to this. Does anybody know the answers to the below questions. a) Can CR-LDP support VPN and QoS ? How can this be done ? b) Will both protocols (i.e. BGP and OSPF) affect VPN and QoS using LDP/CR-LDP ? If yes, can I have the technical details. Thanks Regards Gan --openmail-part-0df8d2b4-00000002 Content-Type: application/rtf Content-Disposition: attachment; filename="BDY.RTF" ;Creation-Date="Thu, 23 Mar 2000 08:42:49 -0600" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzNcZGVmbGFuZ2ZlMTAz M3tcZm9udHRibHtcZjBcZnN3aXNzXGZjaGFyc2V0MCBBcmlhbDt9e1xmMVxmc3dpc3NcZnBy cTJcZmNoYXJzZXQwIEFyaWFsO317XGYyXGZzd2lzc1xmcHJxMlxmY2hhcnNldDAgVGFob21h O319DQp7XGNvbG9ydGJsIDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdmlld2tpbmQ0XHVj MVxwYXJkXGNmMVxmMFxmczIwIFZQTnMgYW5kIFFvUyBhcmUgY3JlYXRlZCBieSBlZGdlIHJv dXRlcnMgYW5kIGNhbiBiZSBkb25lIGluIG1hbnkgd2F5cywgc29tZSBkaXNjdXNzc2VkIG9w ZW5seSBpbiBJRVRGIGFuZCBvdGhlcnMgbW9yZSB2ZW5kb3Itc3BlY2lmaWMuICAgQ2lzY28g dXNlcyBCR1AtYmFzZWQgUkZDLTI0NTcgYXMgYSBtZWFucyB0byBkaXN0cmlidXRlIFZQTiBt ZW1iZXJzaGlwIGluZm9ybWF0aW9uIGFtb25nIHRoZSBlZGdlIHJvdXRlcnMuICBldmVyc3Qg aW50ZW50IHdhcyB0byBlc3RhYmxpc2ggdmlydHVhbCByb3V0ZXJzIGF0IHRoZSB0aW1lIElQ IGludGVyZmFjZXMgYXJlIHByb3Zpc2lvbmVkLiAgIENpc2NvIHVzZXMgUlNWUCB0byBzaWdu YWwgTDIgcGF0aHMgdG8gY3JlYXRlIHNwZWNpZmMgTFNQcyBmb3IgdGhlIFZQTnMuICBFdmVy ZXN0IHdhcyBwbGFubmluZyB0byB1c2UgQVRNLVNWQ3MsIHRoZW4gZXZvbHZlIHRvIExTUHMg YW5kIHdvdWxkIGJlIGluZGlmZmVyZW50IHRvIFJTVlAgdnMuIENSLUxEUC4gICBRb1MgaGFz IG1hbnkgbW9yZSBvcHRpb25zLCBtb3N0IHRoYXQgc2F5IHRvIGhhdmUgYSBkaWZmZXJlbnQg TFNQIHRvIHRoZSBzYW1lIGVkZ2UtZWRnZSBwYXRoIGZvciBlYWNoIFFvUyBjbGFzcy4gIFRo ZXNlIGNhbiBiZSBzZXQgdXAgdXNpbmcgUlNWUCBvciBDUi1MRFAuICBEaWZmZXJlbnQgdmVu ZG9ycyBoYXZlIGRpZmZlcmVudCBhcHByb2FjaGVzIHRvIFFvUy4gIE91ciBhcHByb2FjaCBp cyB0aGUgdHJpZ2dmZXJzIGFuZCB0cmVhdG1lbnRzIG1vZGVsLiBXZSB3aWxsIGluaXRpYWxs eSBtYXAgaW50byBkaWZmZXJlbnQgQVRNIFNWQ3Mgd2l0aCB0cmF2ZWwgcCByb2ZpbGVzLiAg IEFzIHdlIGltcGxlbWVudCBNUExTIHdpdGggTEVSLCB3ZSB3b3VsZCBtYXAgZGlmZmVyZW50 IGNsYXNzZXMgaW50byBMU1BzIHRoYXQgaGF2ZSB0cmFmZmljIHByb2ZpbGVzIGNyZWF0ZWQg dXNpbmcgQ1ItTERQIG9yIFJTVlAuICAgQVMgYSB0cmFuc2l0IExTUiwgd2Ugb25seSB3b2l1 bGQgbmVlZCB0byBzdXBwb3J0IHdoYXRldmVyIHNjaGVtZSB0aGUgTEVScyBpbXBsZW1lbnQs IGFzc3VtaW5nIHRoZXkgYXJlIGNvbXBhdGlibGUuICAgSSB3b3VsZCBub3Qgc3VwcG9zZSB0 aGF0IGRpZmZlcmVudCB2ZW5kb3JzIGxpa2UgQ2lzY28gb3IgTm9ydGVsIHdvdWxkIGhhdmUg c2ltaWxhciBhcHBvcmFjaGVzIHRvIFFvUyBvciBWUE5zLCB3aGVyZSB0aGV5IGNhbid0IGV2 ZW4gYWdyZWUgb24gc2ltcGxlciB0aGluZ3MuXHBhcg0KXHBhcg0KXHBhcmRcbGkzNjBcY2Yw XHByb3RlY3RcZjFcZnMyNCAgXGxhbmcxMDI0XGYyXGZzMTYgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS1ccGFyDQpccHJvdGVjdDBccGFyZFxwcm90ZWN0XGZpLTE0NDBcbGkxODAwXHR4 MTQ0MFxiIEZyb206IFx0YWJcYjAgR2FuLCBZaWNrQmVuZyAvc2csaXRzICBccGFyDQpcYiBT ZW50Olx0YWJcYjAgVHVlc2RheSwgTWFyY2ggMjEsIDIwMDAgODo0MSBQTVxwYXINClxiIFRv Olx0YWJcYjAgbXBsc0BVVS5ORVRccGFyDQpcYiBDYzpcdGFiXGIwIEdhbiwgWWlja0Jlbmcg L3NnLGl0c1xwYXINClxiIFN1YmplY3Q6XHRhYlxiMCBGVzogUkU6IExEUC9DUi1MRFBccGFy DQpccGFyDQpccHJvdGVjdDBccGFyZFxwcm90ZWN0XGxpMzYwXGxhbmcxMDMzXGYxXGZzMjAg SGkgQWxsXHBhcg0KXHBhcg0KSVxycXVvdGUgbSBxdWl0ZSBuZXcgdG8gdGhpcy4gRG9lcyBh bnlib2R5IGtub3cgdGhlIGFuc3dlcnMgdG8gdGhlIGJlbG93IHF1ZXN0aW9ucy4gXHBhcg0K XHBhcg0KXHByb3RlY3QwXHBhcmRccHJvdGVjdHtccG50ZXh0XGYxIGEpXHRhYn17XCpccG5c cG5sdmxib2R5XHBuZjFccG5pbmRlbnQzNjBccG5zdGFydDFccG5sY2x0cntccG50eHRhKX19 DQpcZmktMzYwXGxpNzIwXHNhMTIwXHR4MzYwIENhbiBDUi1MRFAgc3VwcG9ydCBWUE4gYW5k IFFvUyA/IEhvdyBjYW4gdGhpcyBiZSBkb25lID9ccGFyDQp7XHBudGV4dFxmMSBiKVx0YWJ9 V2lsbCBib3RoIHByb3RvY29scyAoaS5lLiBCR1AgYW5kIE9TUEYpIGFmZmVjdCBWUE4gYW5k IFFvUyB1c2luZyBMRFAvQ1ItTERQID8gSWYgeWVzLCBjYW4gSSBoYXZlIHRoZSB0ZWNobmlj YWwgZGV0YWlscy5ccGFyDQpccHJvdGVjdDBccGFyZFxwcm90ZWN0XGxpMzYwXHNhMTIwXHBh cg0KVGhhbmtzXHBhcg0KXHByb3RlY3QwXHBhcmRccHJvdGVjdFxsaTM2MFxwYXINClJlZ2Fy ZHNccGFyDQpHYW5ccGFyDQp9DQoA --openmail-part-0df8d2b4-00000002-- From owner-mpls@UU.NET Thu Mar 23 10:12:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09840 for ; Thu, 23 Mar 2000 10:12:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihts27029; Thu, 23 Mar 2000 15:11:30 GMT Received: by mail-control.mail.uu.net id QQihts22291 for mpls-outgoing; Thu, 23 Mar 2000 15:11:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihts22274 for ; Thu, 23 Mar 2000 15:11:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihts18335 for ; Thu, 23 Mar 2000 10:10:49 -0500 (EST) Received: from redbaron.nexabit.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQihts26480 for ; Thu, 23 Mar 2000 15:10:49 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id KAA16627; Thu, 23 Mar 2000 10:10:16 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 10:10:16 -0500 Message-ID: From: Dimitry Haskin To: Bob Braden , rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com Subject: RE: Semantics of shared reservations (with RSVP) Date: Thu, 23 Mar 2000 10:10:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > David, > > Thanks for taking the trouble to explain to me. But I must admit I am > still unconvinced. There are two "scenarios" at issue: failover vs. > load balancing, which have completely different semantics. I would > expect that all the nodes (at least the ingress and egress) must be > solidly configured for one or the other of these "scenarios", and > the scenario will imply the correct reservation style. > A small but important correction: it is not necessary "one or the other" -- a load balancing reservation may be protected by a failover path. Dimitry From owner-mpls@UU.NET Thu Mar 23 10:35:00 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19201 for ; Thu, 23 Mar 2000 10:35:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihtu26775; Thu, 23 Mar 2000 15:33:03 GMT Received: by mail-control.mail.uu.net id QQihtu24078 for mpls-outgoing; Thu, 23 Mar 2000 15:32:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihtu24073 for ; Thu, 23 Mar 2000 15:32:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihtu09386 for ; Thu, 23 Mar 2000 10:32:28 -0500 (EST) Received: from ihemlsrv.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQihtu25930 for ; Thu, 23 Mar 2000 15:32:28 GMT Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA00669 for ; Thu, 23 Mar 2000 10:32:27 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA00646 for ; Thu, 23 Mar 2000 10:32:27 -0500 (EST) Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA13228; Thu, 23 Mar 2000 10:32:26 -0500 (EST) Message-ID: <38DA38D3.B8149BE6@lucent.com> Date: Thu, 23 Mar 2000 10:31:31 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <38D63434.B2D5CEFA@ieee.org> <38D646D9.FEBDCA86@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit There have been many discussions about wavelength conversion. And we all agree it is good. Can anyone tell me which OXC product (commercially announced) doesn't support wavelength conversion? Yangguang From owner-mpls@UU.NET Thu Mar 23 11:38:29 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13697 for ; Thu, 23 Mar 2000 11:38:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihty14244; Thu, 23 Mar 2000 16:38:30 GMT Received: by mail-control.mail.uu.net id QQihty06778 for mpls-outgoing; Thu, 23 Mar 2000 16:38:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihty06770 for ; Thu, 23 Mar 2000 16:37:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihty21456 for ; Thu, 23 Mar 2000 11:37:47 -0500 (EST) Received: from mail16.vwh1.net by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [209.238.9.59]) id QQihty18118 for ; Thu, 23 Mar 2000 16:37:47 GMT Received: from 208.55.74.250 (208.55.74.250) by mail16.vwh1.net (RS ver 1.0.53) with SMTP id 015105518; Thu, 23 Mar 2000 11:36:51 -0500 (EST) Message-Id: <3.0.6.32.20000323114004.00b74c60@photonex.com> X-Sender: jagan@photonex.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 23 Mar 2000 11:40:04 -0500 To: curtis@avici.com, Khaled Elsayed From: Jagan Shantigram Subject: Re: Comments on draft-ip-optical-framework-00.txt Cc: mpls@UU.NET, ip-optical@lists.research.bell-labs.com In-Reply-To: <200003221752.MAA42145@curtis-lt.avici.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop-Detect: 1 Sender: owner-mpls@UU.NET Precedence: bulk At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: >> >> >> Hello Jagan, >> >> > When we do not have lambda conversion however, this problem cannot >> > be solved optimally.. it is akin to the graph coloring >> > problem - which ofcourse has heuristics that can get us to >> > a factor (?) of the optimal solution. So, connections may >> > be blocked even though there is capacity on the fiber to >> > support it, just because the wavelength is already used up. >> > >> >> Connections can be blocked when?? At service provisioning time or >> at the time the connection is requested?? My point is a >> connection of 2.48 Gbps is not likely to be a random event or an >> ATM-like SVC. If a customer would require such huge bandwidth, it >> would need that BW to go through or it would better look for >> another carrier that will provide a TDM/leased line?? Of course >> wavelength conversion can help build a better-utilized network, >> no question about that. >> >> Khaled > > >The exception to the rule that "a connection of 2.48 Gbps is not >likely to be a random event" is where a very major event, possilble >external to one's own network results in a shift in traffic patterns >that is significant enough to require that additional lambdas be added >to existing paths. > >The real world example in the ISP world is a failure of a peering >point of some sort, a provider interconnect, a NAP or NAP connectivity >of some party. Since all major ISPs are connected to each other at >more than one geographically diverse peering point, the traffic will >still flow, but the path will have changed. > >This may mean that a path that previously required 3 lambdas (for >example), now requires 4 lambdas. There are at least 3 ways to >accommodate this requirement: > > 1. An external management system adds a lambda to both the routers > at either end and the optical switches (demonstrated at OFC). > > 2. The router signals the requirement/desire for an additional > lambda to the adjacent optical switch which sets up a path. > This is the overlay model. It can be trivially implemented with > MPLS by having the router send a loose source hop in the ERO > allowing the switch to create the path or reject the request. Curtis, Am trying to understand the model here. Does the overlay model as you put above imply that the optical devices need to be mini-routers in their own right? They have to be able to set up end-to-end optical paths.. perhaps some kind of binding between the end-host IP address and an addressing scheme for Optical devices.. ala ATM? What does the overlay model entail? > > 3. The router has enough information about the characteristics of > the optical devices to compute the path and so it does so. This > is the peer model. > What does this model need.. a protocol for exchanging information between the router and the optical device? -jagan. >The way this might manifest itself is LSPs that might take an optical >path from A to C are going from A to B to C because A to C lambdas are >too full. If so, then A could in principle request an additional >lambda, but in practice the means to signal this has not been defined. > >Curtis > > > Jagannath Shantigram Photonex Corporation From owner-mpls@UU.NET Thu Mar 23 11:38:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13722 for ; Thu, 23 Mar 2000 11:38:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihty18628; Thu, 23 Mar 2000 16:38:34 GMT Received: by mail-control.mail.uu.net id QQihty06785 for mpls-outgoing; Thu, 23 Mar 2000 16:38:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihty06780 for ; Thu, 23 Mar 2000 16:38:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihty21438 for ; Thu, 23 Mar 2000 11:37:43 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihty13447 for ; Thu, 23 Mar 2000 16:37:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA18538 for mpls@uu.net; Thu, 23 Mar 2000 11:37:42 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihty06731 for ; Thu, 23 Mar 2000 16:36:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihty04734 for ; Thu, 23 Mar 2000 11:36:05 -0500 (EST) Received: from tnt.isi.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tnt.isi.edu [128.9.128.128]) id QQihty17177 for ; Thu, 23 Mar 2000 16:36:05 GMT Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA05971; Thu, 23 Mar 2000 08:35:57 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA10407; Thu, 23 Mar 2000 16:35:57 GMT Date: Thu, 23 Mar 2000 16:35:57 GMT Message-Id: <200003231635.QAA10407@gra.isi.edu> To: braden@ISI.EDU, rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com, dhaskin@nexabit.com Subject: RE: Semantics of shared reservations (with RSVP) X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> From dhaskin@nexabit.com Thu Mar 23 07:10:49 2000 *> From: Dimitry Haskin *> To: Bob Braden , rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com *> Subject: RE: Semantics of shared reservations (with RSVP) *> Date: Thu, 23 Mar 2000 10:10:15 -0500 *> MIME-Version: 1.0 *> X-Mailer: Internet Mail Service (5.5.2650.21) *> X-Lines: 13 *> *> > David, *> > *> > Thanks for taking the trouble to explain to me. But I must admit I am *> > still unconvinced. There are two "scenarios" at issue: failover vs. *> > load balancing, which have completely different semantics. I would *> > expect that all the nodes (at least the ingress and egress) must be *> > solidly configured for one or the other of these "scenarios", and *> > the scenario will imply the correct reservation style. *> > *> A small but important correction: it is not necessary "one or the other" -- *> a load balancing reservation may be protected by a failover path. *> *> Dimitry *> I which case you use reservation style (SE+FF)/2, I suppose. Your comments seems orthogonal to my point. Bob From owner-mpls@UU.NET Thu Mar 23 12:11:59 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23327 for ; Thu, 23 Mar 2000 12:11:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihua13946; Thu, 23 Mar 2000 17:12:00 GMT Received: by mail-control.mail.uu.net id QQihua17458 for mpls-outgoing; Thu, 23 Mar 2000 17:11:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihua17449 for ; Thu, 23 Mar 2000 17:11:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihua10932 for ; Thu, 23 Mar 2000 12:11:07 -0500 (EST) Received: from redbaron.nexabit.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQihua15648 for ; Thu, 23 Mar 2000 17:11:07 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id MAA17750; Thu, 23 Mar 2000 12:10:35 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 12:10:35 -0500 Message-ID: From: Dimitry Haskin To: Bob Braden , rsvp@ISI.EDU, mpls@UU.NET, dcharlap@fore.com, Dimitry Haskin Subject: RE: Semantics of shared reservations (with RSVP) Date: Thu, 23 Mar 2000 12:10:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Bob, I just tried to point out that configuring the nodes for one or the other scenarios may not be a solution and when RSVP is used for MPLS some kind of additional RSVP signaling may be needed to insure that the working and failover paths are set correctly. However I might have diverted from the subject of the thread. Dimitry > *> > > *> > Thanks for taking the trouble to explain to me. But I > must admit I am > *> > still unconvinced. There are two "scenarios" at > issue: failover vs. > *> > load balancing, which have completely different > semantics. I would > *> > expect that all the nodes (at least the ingress and > egress) must be > *> > solidly configured for one or the other of these > "scenarios", and > *> > the scenario will imply the correct reservation style. > *> > > *> A small but important correction: it is not necessary > "one or the other" -- > *> a load balancing reservation may be protected by a failover path. > *> > *> Dimitry > *> > I which case you use reservation style (SE+FF)/2, I suppose. > > Your comments seems orthogonal to my point. > > Bob > From owner-mpls@UU.NET Thu Mar 23 13:11:36 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14238 for ; Thu, 23 Mar 2000 13:11:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihue04991; Thu, 23 Mar 2000 18:11:32 GMT Received: by mail-control.mail.uu.net id QQihue29348 for mpls-outgoing; Thu, 23 Mar 2000 18:11:11 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihue29290 for ; Thu, 23 Mar 2000 18:11:02 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihue07924 for ; Thu, 23 Mar 2000 13:10:36 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihue04195 for ; Thu, 23 Mar 2000 18:10:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA02694 for mpls@uu.net; Thu, 23 Mar 2000 13:10:31 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihue29166 for ; Thu, 23 Mar 2000 18:09:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihue07736 for ; Thu, 23 Mar 2000 13:09:42 -0500 (EST) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQihue00127 for ; Thu, 23 Mar 2000 18:09:42 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 8E520D7; Thu, 23 Mar 2000 19:09:41 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (nice-dhcp1.cisco.com [144.254.60.23]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id TAA20457; Thu, 23 Mar 2000 19:09:36 +0100 (MET) Message-Id: <200003231809.TAA20457@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 23 Mar 2000 19:10:14 +0100 To: mpls@UU.NET From: Francois Le Faucheur Subject: Proposal for last open issue re draft-ietf-mpls-diff-ext-04.txt Cc: flefauch@europe.cisco.com, bsd@cisco.com, flefauch@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@ntc.nokia.com, ram@nexabit.com ('Ram Krishnan'), Shahram_Davari@pmc-sierra.com (Shahram Davari), Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello, A single issue from the Informal Last Call on draft-ietf-mpls-diff-ext-03.txt had not been closed as of draft-ietf-mpls-diff-ext-04.txt. This is the detailed ingress and egress Diff-Serv behavior when pushing and popping labels. Here is a high level proposal for resolution of this issue. The proposal borrows heavily from draft-ietf-diffserv-tunnels-00.txt, 'Differentiated Services and Tunnels' from D Black. Most of the characteristics of the problem statement addressed by this draft are common with the issue we need to address in draft-ietf-mpls-diff-ext-04.txt: - intermediate nodes only see and operate on the "outer" Diff-Serv information - IP tunnels/LSPs Tunnels are unidirectionnal - the outer Diff-SErv information may get modified somewhere on the span of the IP Tunnel/LSP Tunnel There is a few notable differences between an LSP Tunnel and an IP Tunnel though: - Penultimate Hop Popping (PHP) results in the LSP Tunnel Diff-SErv information not being transmitted to the LSP Tunnel Egress. - two level LSP Tunnels from same ingress to same egress are expected to be common occurence in MPLS-land for MPLS VPN so we need to address this case. I have only covered below the case of unlabelled packets going into a two level LSP tunnel because MPLS VPN is the only case I can think of for this two level LSP tunnels. Based on this, I would propose that: - like with draft-ietf-mpls-diff-ext-04.txt, we recognise that there are two meaningful conceptual models which are "Uniform" model and "Tunnel" model. - like with draft-ietf-mpls-diff-ext-04.txt, we recognise that they are both useful. - unlike with draft-ietf-mpls-diff-ext-04.txt, we can play with PHP to simplify operations of the egress in case of single level LSP Tunnel - for single level LSP Tunnel, to achieve "tunnel" mode: * Ingress: Egress PHB is reflected in pushed label. Egress PHB is NOT reflected in swapped label or encapsulated IP DSCP. * Egress: requests PHP and therefore use "outer" Diff-Serv info for incoming PHB determination (ie outer label for received labelled packet or DSCP for received unlabelled packet). - for single level LSP Tunnel, to achieve "uniform" mode: * Ingress: Egress PHB is reflected in pushed label. It does not matter if Egress PHB is also reflected in swapped label or encapsulated IP DSCP since this will be rewritten at egress ayway. * Egress: requests No-PHP and use "outer" Diff-Serv info for incoming PHB determination (ie outer label before POP for received labelled packet, or DSCP for received unlabelled packet). - for two level LSP Tunnel (MPLS VPN), to achieve "tunnel" mode: * Ingress: Egress PHB is reflected in both pushed labels. Egress PHB is NOT reflected in encapsulated IP DSCP. * Egress: requests PHP but still can NOT use "outer" label for incoming PHB determination. Egress must be able to use the DSCP of the packet (as exposed after the POP) to do PHB determination. In other words, Egress must be able to (logically) do the PHB determination after the POP. - for two level LSP Tunnel (MPLS VPN), to achieve "uniform" mode: * Ingress: Egress PHB is reflected in both pushed labels. It does not matter if it is also reflected in encapsulated IP DSCP since this will be rewritten at egress ayway. * Egress: requests PHP anyway (because with MPLS VPNs both labels are expected to reflect the same PHB) and use "outer" label/or DSCP for incoming PHB determination (before doing POP).In other words, Egress must be able to (logically) do the PHB determination before the POP. Thanks for comments. As soon as we've reached agreement I will proposed detailed text for the next rev of the draft. Francois _________________________________________________________________ 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: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Thu Mar 23 13:26:25 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20721 for ; Thu, 23 Mar 2000 13:26:23 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihuf17207; Thu, 23 Mar 2000 18:26:22 GMT Received: by mail-control.mail.uu.net id QQihuf00285 for mpls-outgoing; Thu, 23 Mar 2000 18:25:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihuf00280 for ; Thu, 23 Mar 2000 18:25:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihuf23164 for ; Thu, 23 Mar 2000 13:25:40 -0500 (EST) Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQihuf16465 for ; Thu, 23 Mar 2000 18:25:40 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id MAA16427; Thu, 23 Mar 2000 12:25:37 -0600 (CST) Received: from vsharma ([172.31.101.69] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA19900; Thu, 23 Mar 2000 12:25:38 -0600 (CST) Received: by localhost with Microsoft MAPI; Thu, 23 Mar 2000 13:29:21 -0500 Message-ID: <01BF94CB.CC564120.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'xuyg@lucent.com'" , "mpls@UU.NET" Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Thu, 23 Mar 2000 13:29:16 -0500 Organization: Tellabs Research Center X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yangguang, I don't think any product that claims to do purely optical cross-connecting supports wavelength conversion. The OEO based devices might do so. -Vishal On Thursday, March 23, 2000 10:32 AM, xuyg@lucent.com [SMTP:xuyg@lucent.com] wrote: > > There have been many discussions about wavelength conversion. And we all agree > it is good. Can anyone tell me which OXC product (commercially announced) > doesn't support wavelength conversion? > > Yangguang From owner-mpls@UU.NET Thu Mar 23 13:55:23 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02537 for ; Thu, 23 Mar 2000 13:55:22 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihuh06997; Thu, 23 Mar 2000 18:55:23 GMT Received: by mail-control.mail.uu.net id QQihuh03464 for mpls-outgoing; Thu, 23 Mar 2000 18:54:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihuh03452 for ; Thu, 23 Mar 2000 18:54:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihuh27701 for ; Thu, 23 Mar 2000 13:54:39 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQihuh06266 for ; Thu, 23 Mar 2000 18:54:39 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id NAA25887; Thu, 23 Mar 2000 13:54:36 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id NAA47083; Thu, 23 Mar 2000 13:54:55 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003231854.NAA47083@curtis-lt.avici.com> To: Jagan Shantigram cc: curtis@avici.com, Khaled Elsayed , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Reply-To: curtis@avici.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Thu, 23 Mar 2000 11:40:04 EST." <3.0.6.32.20000323114004.00b74c60@photonex.com> Date: Thu, 23 Mar 2000 13:54:55 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan Shantigram wr ites: > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > >> > >> > >> Hello Jagan, > >> > >> > When we do not have lambda conversion however, this problem cannot > >> > be solved optimally.. it is akin to the graph coloring > >> > problem - which ofcourse has heuristics that can get us to > >> > a factor (?) of the optimal solution. So, connections may > >> > be blocked even though there is capacity on the fiber to > >> > support it, just because the wavelength is already used up. > >> > > >> > >> Connections can be blocked when?? At service provisioning time or > >> at the time the connection is requested?? My point is a > >> connection of 2.48 Gbps is not likely to be a random event or an > >> ATM-like SVC. If a customer would require such huge bandwidth, it > >> would need that BW to go through or it would better look for > >> another carrier that will provide a TDM/leased line?? Of course > >> wavelength conversion can help build a better-utilized network, > >> no question about that. > >> > >> Khaled > > > > > >The exception to the rule that "a connection of 2.48 Gbps is not > >likely to be a random event" is where a very major event, possilble > >external to one's own network results in a shift in traffic patterns > >that is significant enough to require that additional lambdas be added > >to existing paths. > > > >The real world example in the ISP world is a failure of a peering > >point of some sort, a provider interconnect, a NAP or NAP connectivity > >of some party. Since all major ISPs are connected to each other at > >more than one geographically diverse peering point, the traffic will > >still flow, but the path will have changed. > > > >This may mean that a path that previously required 3 lambdas (for > >example), now requires 4 lambdas. There are at least 3 ways to > >accommodate this requirement: > > > > 1. An external management system adds a lambda to both the routers > > at either end and the optical switches (demonstrated at OFC). > > > > 2. The router signals the requirement/desire for an additional > > lambda to the adjacent optical switch which sets up a path. > > This is the overlay model. It can be trivially implemented with > > MPLS by having the router send a loose source hop in the ERO > > allowing the switch to create the path or reject the request. > > Curtis, > > Am trying to understand the model here. Does the overlay model > as you put above imply that the optical devices need to be mini-routers > in their own right? They have to be able to set up end-to-end optical > paths.. perhaps some kind of binding between the end-host IP address > and an addressing scheme for Optical devices.. ala ATM? > What does the overlay model entail? The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or CRLDP) in a manner similar to the ATM UNI setting up an SVC. Alternately, the lambdas can be set statically and the edge router simple advertises a Lambda-Switch Capable link ala draft-kompella-mpls-optical-00.txt (if I understand their intent wrt accommodating the overlay model). I don't think draft-kompella-mpls-optical-00.txt has all the details sufficiently ironed out for the case where the optical switch advertises the availability of an optical link. If it does, then the details ar just not clear to me. (Could be my careless reading). > > 3. The router has enough information about the characteristics of > > the optical devices to compute the path and so it does so. This > > is the peer model. > > > > What does this model need.. a protocol for exchanging information > between the router and the optical device? It needs a means to communicate OOB wrt the primary lightpath. That means would again be running the IGP and RSVP. Based on reading the draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the optical switch exchanges this information OOB although I would imagine that it would be quite easy to maintian another interface (perhaps even an electrical, though gig-E would do fine) between the router and optical device in which the optical device advertises the optical links. The router on either end of an optical link, seeing or having set up a Packet-Switch Capable link would then have to bring up an RSVP adjacency over it, though I think it would not need an IGP adjacency. (I'm not clear on this last point.) The availability of certain types of links (Packet-Switch Capable, Lambda-Switch Capable, Fiber-Switch Capable) as defined in draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm not clear on whether the adjacent LSR should advertise a Forwarding Adjacency PSC after RSVP comes up over a set of optical links (it seems to be the intent) but maybe the authors can clarify the usage. The ongoing discussion and the topic of the (way too numerous) framework documents floating around has been what additional information would be needed in order to provide adequate constraints to set up optical paths, a particularly difficult problem for transparent paths. > -jagan. > > >The way this might manifest itself is LSPs that might take an optical > >path from A to C are going from A to B to C because A to C lambdas are > >too full. If so, then A could in principle request an additional > >lambda, but in practice the means to signal this has not been defined. > > > >Curtis > > Jagannath Shantigram > Photonex Corporation btw- I exchanged some private email with one of the authors of draft-kompella-mpls-optical.txt and owe them some detailed comments (appologies to them for the delay, busy). After some brief discussion and after a second reading, the intent seems a lot more clear. The usage material is at the end so when reading the document from front to back the intent is not clear until the end and then a second reading is required. Curtis From owner-mpls@UU.NET Thu Mar 23 14:38:28 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18568 for ; Thu, 23 Mar 2000 14:38:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihuk11577; Thu, 23 Mar 2000 19:38:27 GMT Received: by mail-control.mail.uu.net id QQihuk14445 for mpls-outgoing; Thu, 23 Mar 2000 19:37:54 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihuk14438 for ; Thu, 23 Mar 2000 19:37:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihuk23098 for ; Thu, 23 Mar 2000 14:37:26 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQihuk17422 for ; Thu, 23 Mar 2000 19:37:26 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id OAA27920; Thu, 23 Mar 2000 14:20:12 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id OAA47318; Thu, 23 Mar 2000 14:20:31 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003231920.OAA47318@curtis-lt.avici.com> To: Francois Le Faucheur cc: mpls@UU.NET, flefauch@europe.cisco.com, bsd@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@ntc.nokia.com, ram@nexabit.com ('Ram Krishnan'), Shahram_Davari@pmc-sierra.com (Shahram Davari), Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi Reply-To: curtis@avici.com Subject: Re: Proposal for last open issue re draft-ietf-mpls-diff-ext-04.txt In-reply-to: Your message of "Thu, 23 Mar 2000 19:10:14 +0100." <200003231809.TAA20457@europe.cisco.com> Date: Thu, 23 Mar 2000 14:20:31 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200003231809.TAA20457@europe.cisco.com>, Francois Le Faucheur write s: > > Based on this, I would propose that: > > - like with draft-ietf-mpls-diff-ext-04.txt, we recognise that there > are two meaningful conceptual models which are "Uniform" model and "Tunnel" > model. Please explain what "Uniform" model and "Tunnel" model are attempting to accomplish. Maybe then the rule set below will be clear. Also, please state that the egress MAY request PHP, since not requesting PHP and doing the right thing is also a viable and perhaps a preferable option. Curtis From owner-mpls@UU.NET Thu Mar 23 14:48:47 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22465 for ; Thu, 23 Mar 2000 14:48:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihul29769; Thu, 23 Mar 2000 19:48:47 GMT Received: by mail-control.mail.uu.net id QQihul15200 for mpls-outgoing; Thu, 23 Mar 2000 19:48:15 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihul15195 for ; Thu, 23 Mar 2000 19:48:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihul25524 for ; Thu, 23 Mar 2000 14:48:05 -0500 (EST) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQihul18358 for ; Thu, 23 Mar 2000 19:48:04 GMT Received: from kbalalap by alpha.tellium.com (SMI-8.6/SMI-SVR4) id OAA22319; Thu, 23 Mar 2000 14:43:09 -0500 From: "Krishna Bala" To: "Yangguang Xu" , Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Thu, 23 Mar 2000 14:48:34 -0500 Message-ID: <002301bf9500$c5f04620$425cc697@tempest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <38DA38D3.B8149BE6@lucent.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yangguang, The optical switch from Corvis does not support wavelength conversion. Krishna Bala Tellium > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yangguang > Xu > Sent: Thursday, March 23, 2000 10:32 AM > To: mpls@UU.NET > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > There have been many discussions about wavelength conversion. And > we all agree > it is good. Can anyone tell me which OXC product (commercially announced) > doesn't support wavelength conversion? > > Yangguang > From owner-mpls@UU.NET Thu Mar 23 15:00:16 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26822 for ; Thu, 23 Mar 2000 15:00:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihum26761; Thu, 23 Mar 2000 20:00:17 GMT Received: by mail-control.mail.uu.net id QQihul15688 for mpls-outgoing; Thu, 23 Mar 2000 19:59:38 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihul15681 for ; Thu, 23 Mar 2000 19:59:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihul27478 for ; Thu, 23 Mar 2000 14:58:40 -0500 (EST) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQihul25542 for ; Thu, 23 Mar 2000 19:58:38 GMT Received: from kbalalap by alpha.tellium.com (SMI-8.6/SMI-SVR4) id OAA22747; Thu, 23 Mar 2000 14:53:13 -0500 From: "Krishna Bala" To: , "Jagan Shantigram" Cc: "Khaled Elsayed" , , Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Thu, 23 Mar 2000 14:58:38 -0500 Message-ID: <002801bf9502$2e1c67f0$425cc697@tempest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200003231854.NAA47083@curtis-lt.avici.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jagan, There are several architectural models for IP over Optical Networks that are emerging: 1. Peer Model In this model the IP router is entirely aware of the details on the underlying optical network (topology information, wavelength and port usage and lamda assignment). It is able to control and manage entire end to end paths. In this model the OXC is "agile but fat & dumb". 2. Overlay Model The optical layer is "fat & dumb". The lamda connections between the IP routers behave as if they were dedicated fibers between them. The IP routes provision logical optical circuits over a fixed or at best a quasi-fixed optical layer. 3. Open Model In this scenario the optical layer comprises of several "vendor/network operator clouds" that have well defined interfaces. For example, an Optical UNI can be used to interconnect the IP router to the OXC and the Optical NNI can be used to connect two optical network domains together. Here the optical layer is "fat, smart and agile". It is unclear at this time which of these models will prevail. Krishna Bala Tellium > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis > Villamizar > Sent: Thursday, March 23, 2000 1:55 PM > To: Jagan Shantigram > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > ip-optical@lists.research.bell-labs.com > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > Shantigram wr > ites: > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > > > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > > >> > > >> > > >> Hello Jagan, > > >> > > >> > When we do not have lambda conversion however, this problem cannot > > >> > be solved optimally.. it is akin to the graph coloring > > >> > problem - which ofcourse has heuristics that can get us to > > >> > a factor (?) of the optimal solution. So, connections may > > >> > be blocked even though there is capacity on the fiber to > > >> > support it, just because the wavelength is already used up. > > >> > > > >> > > >> Connections can be blocked when?? At service provisioning time or > > >> at the time the connection is requested?? My point is a > > >> connection of 2.48 Gbps is not likely to be a random event or an > > >> ATM-like SVC. If a customer would require such huge bandwidth, it > > >> would need that BW to go through or it would better look for > > >> another carrier that will provide a TDM/leased line?? Of course > > >> wavelength conversion can help build a better-utilized network, > > >> no question about that. > > >> > > >> Khaled > > > > > > > > >The exception to the rule that "a connection of 2.48 Gbps is not > > >likely to be a random event" is where a very major event, possilble > > >external to one's own network results in a shift in traffic patterns > > >that is significant enough to require that additional lambdas be added > > >to existing paths. > > > > > >The real world example in the ISP world is a failure of a peering > > >point of some sort, a provider interconnect, a NAP or NAP connectivity > > >of some party. Since all major ISPs are connected to each other at > > >more than one geographically diverse peering point, the traffic will > > >still flow, but the path will have changed. > > > > > >This may mean that a path that previously required 3 lambdas (for > > >example), now requires 4 lambdas. There are at least 3 ways to > > >accommodate this requirement: > > > > > > 1. An external management system adds a lambda to both the routers > > > at either end and the optical switches (demonstrated at OFC). > > > > > > 2. The router signals the requirement/desire for an additional > > > lambda to the adjacent optical switch which sets up a path. > > > This is the overlay model. It can be trivially implemented with > > > MPLS by having the router send a loose source hop in the ERO > > > allowing the switch to create the path or reject the request. > > > > Curtis, > > > > Am trying to understand the model here. Does the overlay model > > as you put above imply that the optical devices need to be mini-routers > > in their own right? They have to be able to set up end-to-end optical > > paths.. perhaps some kind of binding between the end-host IP address > > and an addressing scheme for Optical devices.. ala ATM? > > What does the overlay model entail? > > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > > Alternately, the lambdas can be set statically and the edge router > simple advertises a Lambda-Switch Capable link ala > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt > accommodating the overlay model). > > I don't think draft-kompella-mpls-optical-00.txt has all the details > sufficiently ironed out for the case where the optical switch > advertises the availability of an optical link. If it does, then the > details ar just not clear to me. (Could be my careless reading). > > > > 3. The router has enough information about the characteristics of > > > the optical devices to compute the path and so it does so. This > > > is the peer model. > > > > > > > What does this model need.. a protocol for exchanging information > > between the router and the optical device? > > It needs a means to communicate OOB wrt the primary lightpath. That > means would again be running the IGP and RSVP. Based on reading the > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the > optical switch exchanges this information OOB although I would imagine > that it would be quite easy to maintian another interface (perhaps > even an electrical, though gig-E would do fine) between the router and > optical device in which the optical device advertises the optical > links. The router on either end of an optical link, seeing or having > set up a Packet-Switch Capable link would then have to bring up an > RSVP adjacency over it, though I think it would not need an IGP > adjacency. (I'm not clear on this last point.) > > The availability of certain types of links (Packet-Switch Capable, > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm > not clear on whether the adjacent LSR should advertise a Forwarding > Adjacency PSC after RSVP comes up over a set of optical links (it > seems to be the intent) but maybe the authors can clarify the usage. > > The ongoing discussion and the topic of the (way too numerous) > framework documents floating around has been what additional > information would be needed in order to provide adequate constraints > to set up optical paths, a particularly difficult problem for > transparent paths. > > > -jagan. > > > > >The way this might manifest itself is LSPs that might take an optical > > >path from A to C are going from A to B to C because A to C lambdas are > > >too full. If so, then A could in principle request an additional > > >lambda, but in practice the means to signal this has not been defined. > > > > > >Curtis > > > > Jagannath Shantigram > > Photonex Corporation > > btw- I exchanged some private email with one of the authors of > draft-kompella-mpls-optical.txt and owe them some detailed comments > (appologies to them for the delay, busy). After some brief discussion > and after a second reading, the intent seems a lot more clear. The > usage material is at the end so when reading the document from front > to back the intent is not clear until the end and then a second > reading is required. > > Curtis > From owner-mpls@UU.NET Thu Mar 23 15:04:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28316 for ; Thu, 23 Mar 2000 15:04:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihum17024; Thu, 23 Mar 2000 20:04:51 GMT Received: by mail-control.mail.uu.net id QQihum21764 for mpls-outgoing; Thu, 23 Mar 2000 20:04:32 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihum21736 for ; Thu, 23 Mar 2000 20:04:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihum10733 for ; Thu, 23 Mar 2000 15:04:18 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihum29909 for ; Thu, 23 Mar 2000 20:04:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA21666 for mpls@uu.net; Thu, 23 Mar 2000 15:04:17 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihum20662 for ; Thu, 23 Mar 2000 20:03:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihum10553 for ; Thu, 23 Mar 2000 15:03:33 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQihum29427 for ; Thu, 23 Mar 2000 20:03:32 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA00870; Thu, 23 Mar 2000 12:03:26 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 12:03:28 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40467@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'curtis@avici.com'" , Francois Le Faucheur Cc: mpls@UU.NET, flefauch@europe.cisco.com, bsd@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@ntc.nokia.com, ram@nexabit.com, Shahram Davari , Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi Subject: RE: Proposal for last open issue re draft-ietf-mpls-diff-ext-04.t xt Date: Thu, 23 Mar 2000 12:00:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Curtis, "uniform" model means that the LSP tunnel will treat the packets consistent with the treatment that the packet would get if there was no LSP tunnel. this is useful when both the tunnel and the network on its ingress/egress belong to the same administrative domain. "Tunnel" mode means that the packets may be treated differently (under another PHB) when they are passing through the LSP, but as soon as they emerge from the other side of the Tunnel, they will continue with their original PHB (the PHB before entering the Tunnel). This may be useful when a service provider wants to Tunnel its traffic through another administrative domain. For example a service provider A may need to pass AF-PHB traffic through domain B (which is not under his control and offers only EF-PHB). Regards, -Shahram >-----Original Message----- >From: Curtis Villamizar [mailto:curtis@avici.com] >Sent: Thursday, March 23, 2000 2:21 PM >To: Francois Le Faucheur >Cc: mpls@UU.NET; flefauch@europe.cisco.com; bsd@cisco.com; >liwwu@europe.cisco.com; pasi.vaananen@ntc.nokia.com; ram@nexabit.com; >Shahram_Davari@pmc-sierra.com; Pierrick.Cheval@alcatel.fr; >jh@lohi.eng.telia.fi >Subject: Re: Proposal for last open issue re >draft-ietf-mpls-diff-ext-04.txt > > > >In message <200003231809.TAA20457@europe.cisco.com>, Francois >Le Faucheur write >s: >> >> Based on this, I would propose that: >> >> - like with draft-ietf-mpls-diff-ext-04.txt, we >recognise that there >> are two meaningful conceptual models which are "Uniform" >model and "Tunnel" >> model. > > >Please explain what "Uniform" model and "Tunnel" model are attempting >to accomplish. Maybe then the rule set below will be clear. > >Also, please state that the egress MAY request PHP, since not >requesting PHP and doing the right thing is also a viable and perhaps >a preferable option. > >Curtis > From owner-mpls@UU.NET Thu Mar 23 15:12:36 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01267 for ; Thu, 23 Mar 2000 15:12:35 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihum06423; Thu, 23 Mar 2000 20:12:36 GMT Received: by mail-control.mail.uu.net id QQihum24991 for mpls-outgoing; Thu, 23 Mar 2000 20:12:13 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihum24983 for ; Thu, 23 Mar 2000 20:12:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihum29913 for ; Thu, 23 Mar 2000 15:11:45 -0500 (EST) Received: from alemail1.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQihum05648 for ; Thu, 23 Mar 2000 20:11:44 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA09902 for ; Thu, 23 Mar 2000 15:11:44 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA09884; Thu, 23 Mar 2000 15:11:43 -0500 (EST) Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA24216; Thu, 23 Mar 2000 15:11:42 -0500 (EST) Message-ID: <38DA796F.B4F2C2AA@lucent.com> Date: Thu, 23 Mar 2000 15:07:11 -0500 From: Yang Cao Organization: Lucent Technologies X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Krishna Bala CC: mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <002801bf9502$2e1c67f0$425cc697@tempest> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I try to clarify your definition, especially the difference between your Overlay Model and Open Model. So in your definition, there is no O-UNI or O-NNI in the Overlay Model, and in this Overlay Model, optical layer is only manual provisioning based? Thanks, Yang > Krishna Bala wrote: > > Jagan, > There are several architectural models for IP over Optical Networks that > are emerging: > > 1. Peer Model > In this model the IP router is entirely aware of the details on the > underlying > optical network (topology information, wavelength and port usage and lamda > assignment). > It is able to control and manage entire end to end paths. In this model the > OXC is "agile but fat & dumb". > 2. Overlay Model > The optical layer is "fat & dumb". The lamda connections between the IP > routers behave as if they were dedicated fibers between them. The IP routes > provision logical optical circuits over a fixed or at best a quasi-fixed > optical > layer. > 3. Open Model > In this scenario the optical layer comprises of several "vendor/network > operator clouds" > that have well defined interfaces. For example, an Optical UNI can be used > to > interconnect the IP router to the OXC and the Optical NNI can be used to > connect > two optical network domains together. Here the optical layer is "fat, smart > and agile". > > It is unclear at this time which of these models will prevail. > > Krishna Bala > Tellium > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis > > Villamizar > > Sent: Thursday, March 23, 2000 1:55 PM > > To: Jagan Shantigram > > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > > ip-optical@lists.research.bell-labs.com > > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > > > > > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > > Shantigram wr > > ites: > > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > > > > > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > > > >> > > > >> > > > >> Hello Jagan, > > > >> > > > >> > When we do not have lambda conversion however, this problem cannot > > > >> > be solved optimally.. it is akin to the graph coloring > > > >> > problem - which ofcourse has heuristics that can get us to > > > >> > a factor (?) of the optimal solution. So, connections may > > > >> > be blocked even though there is capacity on the fiber to > > > >> > support it, just because the wavelength is already used up. > > > >> > > > > >> > > > >> Connections can be blocked when?? At service provisioning time or > > > >> at the time the connection is requested?? My point is a > > > >> connection of 2.48 Gbps is not likely to be a random event or an > > > >> ATM-like SVC. If a customer would require such huge bandwidth, it > > > >> would need that BW to go through or it would better look for > > > >> another carrier that will provide a TDM/leased line?? Of course > > > >> wavelength conversion can help build a better-utilized network, > > > >> no question about that. > > > >> > > > >> Khaled > > > > > > > > > > > >The exception to the rule that "a connection of 2.48 Gbps is not > > > >likely to be a random event" is where a very major event, possilble > > > >external to one's own network results in a shift in traffic patterns > > > >that is significant enough to require that additional lambdas be added > > > >to existing paths. > > > > > > > >The real world example in the ISP world is a failure of a peering > > > >point of some sort, a provider interconnect, a NAP or NAP connectivity > > > >of some party. Since all major ISPs are connected to each other at > > > >more than one geographically diverse peering point, the traffic will > > > >still flow, but the path will have changed. > > > > > > > >This may mean that a path that previously required 3 lambdas (for > > > >example), now requires 4 lambdas. There are at least 3 ways to > > > >accommodate this requirement: > > > > > > > > 1. An external management system adds a lambda to both the routers > > > > at either end and the optical switches (demonstrated at OFC). > > > > > > > > 2. The router signals the requirement/desire for an additional > > > > lambda to the adjacent optical switch which sets up a path. > > > > This is the overlay model. It can be trivially implemented with > > > > MPLS by having the router send a loose source hop in the ERO > > > > allowing the switch to create the path or reject the request. > > > > > > Curtis, > > > > > > Am trying to understand the model here. Does the overlay model > > > as you put above imply that the optical devices need to be mini-routers > > > in their own right? They have to be able to set up end-to-end optical > > > paths.. perhaps some kind of binding between the end-host IP address > > > and an addressing scheme for Optical devices.. ala ATM? > > > What does the overlay model entail? > > > > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or > > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > > > > Alternately, the lambdas can be set statically and the edge router > > simple advertises a Lambda-Switch Capable link ala > > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt > > accommodating the overlay model). > > > > I don't think draft-kompella-mpls-optical-00.txt has all the details > > sufficiently ironed out for the case where the optical switch > > advertises the availability of an optical link. If it does, then the > > details ar just not clear to me. (Could be my careless reading). > > > > > > 3. The router has enough information about the characteristics of > > > > the optical devices to compute the path and so it does so. This > > > > is the peer model. > > > > > > > > > > What does this model need.. a protocol for exchanging information > > > between the router and the optical device? > > > > It needs a means to communicate OOB wrt the primary lightpath. That > > means would again be running the IGP and RSVP. Based on reading the > > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the > > optical switch exchanges this information OOB although I would imagine > > that it would be quite easy to maintian another interface (perhaps > > even an electrical, though gig-E would do fine) between the router and > > optical device in which the optical device advertises the optical > > links. The router on either end of an optical link, seeing or having > > set up a Packet-Switch Capable link would then have to bring up an > > RSVP adjacency over it, though I think it would not need an IGP > > adjacency. (I'm not clear on this last point.) > > > > The availability of certain types of links (Packet-Switch Capable, > > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm > > not clear on whether the adjacent LSR should advertise a Forwarding > > Adjacency PSC after RSVP comes up over a set of optical links (it > > seems to be the intent) but maybe the authors can clarify the usage. > > > > The ongoing discussion and the topic of the (way too numerous) > > framework documents floating around has been what additional > > information would be needed in order to provide adequate constraints > > to set up optical paths, a particularly difficult problem for > > transparent paths. > > > > > -jagan. > > > > > > >The way this might manifest itself is LSPs that might take an optical > > > >path from A to C are going from A to B to C because A to C lambdas are > > > >too full. If so, then A could in principle request an additional > > > >lambda, but in practice the means to signal this has not been defined. > > > > > > > >Curtis > > > > > > Jagannath Shantigram > > > Photonex Corporation > > > > btw- I exchanged some private email with one of the authors of > > draft-kompella-mpls-optical.txt and owe them some detailed comments > > (appologies to them for the delay, busy). After some brief discussion > > and after a second reading, the intent seems a lot more clear. The > > usage material is at the end so when reading the document from front > > to back the intent is not clear until the end and then a second > > reading is required. > > > > Curtis > > From owner-mpls@UU.NET Thu Mar 23 16:35:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00024 for ; Thu, 23 Mar 2000 16:35:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihus01412; Thu, 23 Mar 2000 21:35:41 GMT Received: by mail-control.mail.uu.net id QQihus07822 for mpls-outgoing; Thu, 23 Mar 2000 21:35:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihus07809 for ; Thu, 23 Mar 2000 21:34:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihus15111 for ; Thu, 23 Mar 2000 16:34:39 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQihus00324 for ; Thu, 23 Mar 2000 21:34:39 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id QAA07011; Thu, 23 Mar 2000 16:17:35 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id QAA47638; Thu, 23 Mar 2000 16:17:53 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003232117.QAA47638@curtis-lt.avici.com> To: Shahram Davari cc: "'curtis@avici.com'" , Francois Le Faucheur , mpls@UU.NET, flefauch@europe.cisco.com, bsd@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@ntc.nokia.com, ram@nexabit.com, Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi Reply-To: curtis@avici.com Subject: Re: Proposal for last open issue re draft-ietf-mpls-diff-ext-04.t xt In-reply-to: Your message of "Thu, 23 Mar 2000 12:00:56 PST." <336ECDAFDF7DD311B9E30090277AEE4101B40467@nt-exchange-bby.pmc-sierra.bc.ca> Date: Thu, 23 Mar 2000 16:17:53 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <336ECDAFDF7DD311B9E30090277AEE4101B40467@nt-exchange-bby.pmc-sierra .bc.ca>, Shahram Davari writes: > Curtis, > > "uniform" model means that the LSP tunnel will treat the packets consistent > with the treatment that the packet would get if there was no LSP tunnel. > this is useful when both the tunnel and the network on its ingress/egress > belong to the same administrative domain. > > "Tunnel" mode means that the packets may be treated differently (under > another PHB) when they are passing through the LSP, but as soon as they > emerge from the other side of the Tunnel, they will continue with their > original PHB (the PHB before entering the Tunnel). This may be useful when a > service provider wants to Tunnel its traffic through another administrative > domain. For example a service provider A may need to pass AF-PHB traffic > through domain B (which is not under his control and offers only EF-PHB). > > Regards, > -Shahram Francois' prior message makes sense now. Thanks, Curtis From owner-mpls@UU.NET Thu Mar 23 16:49:26 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02904 for ; Thu, 23 Mar 2000 16:49:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihut02864; Thu, 23 Mar 2000 21:49:26 GMT Received: by mail-control.mail.uu.net id QQihut09236 for mpls-outgoing; Thu, 23 Mar 2000 21:48:53 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihut09219 for ; Thu, 23 Mar 2000 21:48:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihut00439 for ; Thu, 23 Mar 2000 16:48:40 -0500 (EST) Received: from lux.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [207.71.195.18]) id QQihut02067 for ; Thu, 23 Mar 2000 21:48:40 GMT Received: by LUX with Internet Mail Service (5.5.2448.0) id ; Thu, 23 Mar 2000 13:55:21 -0800 Message-ID: <51DA0AB3D747D311832F005004827CC013E299@LUX> From: Jonathan Lang To: "'Krishna Bala'" , curtis@avici.com, Jagan Shantigram Cc: Khaled Elsayed , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Thu, 23 Mar 2000 13:55:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Krishna, The Open model seems quite "Closed" to me - the very nature of clouds implies information hiding in my mind. What is exactly meant by open? Also, I'm not sure I agree with your definition of overlay, as many people allow the overlay model to encompass both your (2) and (3). Furthermore, I don't think the Peer Model implies OXCs are "agile but fat & dumb" since as they are "peers", this would also imply routers are "agile but fat & dumb" as well - and at some point, someone needs to have intelligence. I would suggest that the Peer model allows both routers and OXCs to interoperate intelligently. Regards, Jonathan -----Original Message----- From: Krishna Bala [mailto:kbala@tellium.com] Sent: Thursday, March 23, 2000 11:59 AM To: curtis@avici.com; Jagan Shantigram Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com Subject: RE: Comments on draft-ip-optical-framework-00.txt Jagan, There are several architectural models for IP over Optical Networks that are emerging: 1. Peer Model In this model the IP router is entirely aware of the details on the underlying optical network (topology information, wavelength and port usage and lamda assignment). It is able to control and manage entire end to end paths. In this model the OXC is "agile but fat & dumb". 2. Overlay Model The optical layer is "fat & dumb". The lamda connections between the IP routers behave as if they were dedicated fibers between them. The IP routes provision logical optical circuits over a fixed or at best a quasi-fixed optical layer. 3. Open Model In this scenario the optical layer comprises of several "vendor/network operator clouds" that have well defined interfaces. For example, an Optical UNI can be used to interconnect the IP router to the OXC and the Optical NNI can be used to connect two optical network domains together. Here the optical layer is "fat, smart and agile". It is unclear at this time which of these models will prevail. Krishna Bala Tellium > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis > Villamizar > Sent: Thursday, March 23, 2000 1:55 PM > To: Jagan Shantigram > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > ip-optical@lists.research.bell-labs.com > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > Shantigram wr > ites: > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > > > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > > >> > > >> > > >> Hello Jagan, > > >> > > >> > When we do not have lambda conversion however, this problem cannot > > >> > be solved optimally.. it is akin to the graph coloring > > >> > problem - which ofcourse has heuristics that can get us to > > >> > a factor (?) of the optimal solution. So, connections may > > >> > be blocked even though there is capacity on the fiber to > > >> > support it, just because the wavelength is already used up. > > >> > > > >> > > >> Connections can be blocked when?? At service provisioning time or > > >> at the time the connection is requested?? My point is a > > >> connection of 2.48 Gbps is not likely to be a random event or an > > >> ATM-like SVC. If a customer would require such huge bandwidth, it > > >> would need that BW to go through or it would better look for > > >> another carrier that will provide a TDM/leased line?? Of course > > >> wavelength conversion can help build a better-utilized network, > > >> no question about that. > > >> > > >> Khaled > > > > > > > > >The exception to the rule that "a connection of 2.48 Gbps is not > > >likely to be a random event" is where a very major event, possilble > > >external to one's own network results in a shift in traffic patterns > > >that is significant enough to require that additional lambdas be added > > >to existing paths. > > > > > >The real world example in the ISP world is a failure of a peering > > >point of some sort, a provider interconnect, a NAP or NAP connectivity > > >of some party. Since all major ISPs are connected to each other at > > >more than one geographically diverse peering point, the traffic will > > >still flow, but the path will have changed. > > > > > >This may mean that a path that previously required 3 lambdas (for > > >example), now requires 4 lambdas. There are at least 3 ways to > > >accommodate this requirement: > > > > > > 1. An external management system adds a lambda to both the routers > > > at either end and the optical switches (demonstrated at OFC). > > > > > > 2. The router signals the requirement/desire for an additional > > > lambda to the adjacent optical switch which sets up a path. > > > This is the overlay model. It can be trivially implemented with > > > MPLS by having the router send a loose source hop in the ERO > > > allowing the switch to create the path or reject the request. > > > > Curtis, > > > > Am trying to understand the model here. Does the overlay model > > as you put above imply that the optical devices need to be mini-routers > > in their own right? They have to be able to set up end-to-end optical > > paths.. perhaps some kind of binding between the end-host IP address > > and an addressing scheme for Optical devices.. ala ATM? > > What does the overlay model entail? > > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > > Alternately, the lambdas can be set statically and the edge router > simple advertises a Lambda-Switch Capable link ala > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt > accommodating the overlay model). > > I don't think draft-kompella-mpls-optical-00.txt has all the details > sufficiently ironed out for the case where the optical switch > advertises the availability of an optical link. If it does, then the > details ar just not clear to me. (Could be my careless reading). > > > > 3. The router has enough information about the characteristics of > > > the optical devices to compute the path and so it does so. This > > > is the peer model. > > > > > > > What does this model need.. a protocol for exchanging information > > between the router and the optical device? > > It needs a means to communicate OOB wrt the primary lightpath. That > means would again be running the IGP and RSVP. Based on reading the > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the > optical switch exchanges this information OOB although I would imagine > that it would be quite easy to maintian another interface (perhaps > even an electrical, though gig-E would do fine) between the router and > optical device in which the optical device advertises the optical > links. The router on either end of an optical link, seeing or having > set up a Packet-Switch Capable link would then have to bring up an > RSVP adjacency over it, though I think it would not need an IGP > adjacency. (I'm not clear on this last point.) > > The availability of certain types of links (Packet-Switch Capable, > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm > not clear on whether the adjacent LSR should advertise a Forwarding > Adjacency PSC after RSVP comes up over a set of optical links (it > seems to be the intent) but maybe the authors can clarify the usage. > > The ongoing discussion and the topic of the (way too numerous) > framework documents floating around has been what additional > information would be needed in order to provide adequate constraints > to set up optical paths, a particularly difficult problem for > transparent paths. > > > -jagan. > > > > >The way this might manifest itself is LSPs that might take an optical > > >path from A to C are going from A to B to C because A to C lambdas are > > >too full. If so, then A could in principle request an additional > > >lambda, but in practice the means to signal this has not been defined. > > > > > >Curtis > > > > Jagannath Shantigram > > Photonex Corporation > > btw- I exchanged some private email with one of the authors of > draft-kompella-mpls-optical.txt and owe them some detailed comments > (appologies to them for the delay, busy). After some brief discussion > and after a second reading, the intent seems a lot more clear. The > usage material is at the end so when reading the document from front > to back the intent is not clear until the end and then a second > reading is required. > > Curtis > From owner-mpls@UU.NET Thu Mar 23 16:51:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03395 for ; Thu, 23 Mar 2000 16:51:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihut16772; Thu, 23 Mar 2000 21:51:45 GMT Received: by mail-control.mail.uu.net id QQihut09449 for mpls-outgoing; Thu, 23 Mar 2000 21:51:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihut09444 for ; Thu, 23 Mar 2000 21:51:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihut19117 for ; Thu, 23 Mar 2000 16:51:13 -0500 (EST) Received: from lumen.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: magic03.kudonet.com [209.133.127.227]) id QQihut16212 for ; Thu, 23 Mar 2000 21:51:12 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id ; Thu, 23 Mar 2000 13:53:51 -0800 Message-ID: From: John Drake To: "'Krishna Bala'" , curtis@avici.com, Jagan Shantigram Cc: Khaled Elsayed , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Thu, 23 Mar 2000 13:53:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Krishna, A few points: 1) In the peer model, the routers are not necessarily aware of the complete details of every optical link; if there is information that they don't need, it can be filtered out on a link by link basis by the PXCs. 2) In the Overlay model, the PXC is computing the routes, so in your terminology it is fat, agile, and smart. There is also nothing that precludes an optical UNI in this model. 3) Why the open model is called open is beyond me, since by definition the control plane in each of the clouds is proprietary. I think a better way of characterizing the open model is that it is just a special case of either the peer or the overlay model, in which the vendor does not want to have a standards based control plane between its switches. I.e., it implements the standards based control plane at the edges of its network. What you're calling an optical NNI is what I would call MPL(ambda)S. Thanks, John -----Original Message----- From: Krishna Bala [mailto:kbala@tellium.com] Sent: Thursday, March 23, 2000 11:59 AM To: curtis@avici.com; Jagan Shantigram Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com Subject: RE: Comments on draft-ip-optical-framework-00.txt Jagan, There are several architectural models for IP over Optical Networks that are emerging: 1. Peer Model In this model the IP router is entirely aware of the details on the underlying optical network (topology information, wavelength and port usage and lamda assignment). It is able to control and manage entire end to end paths. In this model the OXC is "agile but fat & dumb". 2. Overlay Model The optical layer is "fat & dumb". The lamda connections between the IP routers behave as if they were dedicated fibers between them. The IP routes provision logical optical circuits over a fixed or at best a quasi-fixed optical layer. 3. Open Model In this scenario the optical layer comprises of several "vendor/network operator clouds" that have well defined interfaces. For example, an Optical UNI can be used to interconnect the IP router to the OXC and the Optical NNI can be used to connect two optical network domains together. Here the optical layer is "fat, smart and agile". It is unclear at this time which of these models will prevail. Krishna Bala Tellium > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis > Villamizar > Sent: Thursday, March 23, 2000 1:55 PM > To: Jagan Shantigram > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > ip-optical@lists.research.bell-labs.com > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > Shantigram wr > ites: > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > > > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > > >> > > >> > > >> Hello Jagan, > > >> > > >> > When we do not have lambda conversion however, this problem cannot > > >> > be solved optimally.. it is akin to the graph coloring > > >> > problem - which ofcourse has heuristics that can get us to > > >> > a factor (?) of the optimal solution. So, connections may > > >> > be blocked even though there is capacity on the fiber to > > >> > support it, just because the wavelength is already used up. > > >> > > > >> > > >> Connections can be blocked when?? At service provisioning time or > > >> at the time the connection is requested?? My point is a > > >> connection of 2.48 Gbps is not likely to be a random event or an > > >> ATM-like SVC. If a customer would require such huge bandwidth, it > > >> would need that BW to go through or it would better look for > > >> another carrier that will provide a TDM/leased line?? Of course > > >> wavelength conversion can help build a better-utilized network, > > >> no question about that. > > >> > > >> Khaled > > > > > > > > >The exception to the rule that "a connection of 2.48 Gbps is not > > >likely to be a random event" is where a very major event, possilble > > >external to one's own network results in a shift in traffic patterns > > >that is significant enough to require that additional lambdas be added > > >to existing paths. > > > > > >The real world example in the ISP world is a failure of a peering > > >point of some sort, a provider interconnect, a NAP or NAP connectivity > > >of some party. Since all major ISPs are connected to each other at > > >more than one geographically diverse peering point, the traffic will > > >still flow, but the path will have changed. > > > > > >This may mean that a path that previously required 3 lambdas (for > > >example), now requires 4 lambdas. There are at least 3 ways to > > >accommodate this requirement: > > > > > > 1. An external management system adds a lambda to both the routers > > > at either end and the optical switches (demonstrated at OFC). > > > > > > 2. The router signals the requirement/desire for an additional > > > lambda to the adjacent optical switch which sets up a path. > > > This is the overlay model. It can be trivially implemented with > > > MPLS by having the router send a loose source hop in the ERO > > > allowing the switch to create the path or reject the request. > > > > Curtis, > > > > Am trying to understand the model here. Does the overlay model > > as you put above imply that the optical devices need to be mini-routers > > in their own right? They have to be able to set up end-to-end optical > > paths.. perhaps some kind of binding between the end-host IP address > > and an addressing scheme for Optical devices.. ala ATM? > > What does the overlay model entail? > > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > > Alternately, the lambdas can be set statically and the edge router > simple advertises a Lambda-Switch Capable link ala > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt > accommodating the overlay model). > > I don't think draft-kompella-mpls-optical-00.txt has all the details > sufficiently ironed out for the case where the optical switch > advertises the availability of an optical link. If it does, then the > details ar just not clear to me. (Could be my careless reading). > > > > 3. The router has enough information about the characteristics of > > > the optical devices to compute the path and so it does so. This > > > is the peer model. > > > > > > > What does this model need.. a protocol for exchanging information > > between the router and the optical device? > > It needs a means to communicate OOB wrt the primary lightpath. That > means would again be running the IGP and RSVP. Based on reading the > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the > optical switch exchanges this information OOB although I would imagine > that it would be quite easy to maintian another interface (perhaps > even an electrical, though gig-E would do fine) between the router and > optical device in which the optical device advertises the optical > links. The router on either end of an optical link, seeing or having > set up a Packet-Switch Capable link would then have to bring up an > RSVP adjacency over it, though I think it would not need an IGP > adjacency. (I'm not clear on this last point.) > > The availability of certain types of links (Packet-Switch Capable, > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm > not clear on whether the adjacent LSR should advertise a Forwarding > Adjacency PSC after RSVP comes up over a set of optical links (it > seems to be the intent) but maybe the authors can clarify the usage. > > The ongoing discussion and the topic of the (way too numerous) > framework documents floating around has been what additional > information would be needed in order to provide adequate constraints > to set up optical paths, a particularly difficult problem for > transparent paths. > > > -jagan. > > > > >The way this might manifest itself is LSPs that might take an optical > > >path from A to C are going from A to B to C because A to C lambdas are > > >too full. If so, then A could in principle request an additional > > >lambda, but in practice the means to signal this has not been defined. > > > > > >Curtis > > > > Jagannath Shantigram > > Photonex Corporation > > btw- I exchanged some private email with one of the authors of > draft-kompella-mpls-optical.txt and owe them some detailed comments > (appologies to them for the delay, busy). After some brief discussion > and after a second reading, the intent seems a lot more clear. The > usage material is at the end so when reading the document from front > to back the intent is not clear until the end and then a second > reading is required. > > Curtis > From owner-mpls@UU.NET Thu Mar 23 17:31:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17871 for ; Thu, 23 Mar 2000 17:31:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihuw20047; Thu, 23 Mar 2000 22:31:36 GMT Received: by mail-control.mail.uu.net id QQihuw19577 for mpls-outgoing; Thu, 23 Mar 2000 22:31:05 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihuw19569 for ; Thu, 23 Mar 2000 22:30:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihuw26062 for ; Thu, 23 Mar 2000 17:30:39 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihuw19176 for ; Thu, 23 Mar 2000 22:30:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA13687 for mpls@uu.net; Thu, 23 Mar 2000 17:30:38 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihuv19452 for ; Thu, 23 Mar 2000 22:28:15 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihuv25696 for ; Thu, 23 Mar 2000 17:28:07 -0500 (EST) Received: from qnsgs000.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qnsgs000.nortelnetworks.com [47.211.0.31]) id QQihuv09142 for ; Thu, 23 Mar 2000 22:28:07 GMT Received: from zhard00m.europe.nortel.com (actually zhard00m) by qnsgs000.nortel.com; Thu, 23 Mar 2000 22:27:01 +0000 Received: from zvb1c004.corpemea.baynetworks.com (ZVB1C004 [141.251.160.84]) by zhard00m.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H32DGMYG; Thu, 23 Mar 2000 22:26:59 -0000 Received: from nortelnetworks.com (LANDERSS [141.251.192.198]) by zvb1c004.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNPXT1N5; Thu, 23 Mar 2000 23:26:57 +0100 Message-ID: <38DA99F3.1E9306DE@nortelnetworks.com> Date: Thu, 23 Mar 2000 23:25:55 +0100 X-Sybari-Space: 00000000 00000000 00000000 From: "Loa Andersson" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Eric Rosen CC: mpls@UU.NET Subject: Re: I-D ACTION:draft-rosen-mpls-profiles-00.txt References: <200003081530.KAA18272@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, it was pointed out to me today that where has not been any response to this. The only reason is that I thought it self evident that we are intrested in this work. I can't speak for the other authors of the draft-loa-mpls-cap-set, but it is certainly my intention to contribute. /Loa Eric Rosen wrote: > > I'd like to call your attention to the following draft, which is a first > attempt to specify small set of MPLS "profiles" in a way which is detailed > enough to ensure interoperability. > > We anticipate working with the authors of draft-loa-mpls-cap-set to merge > the two documents. In the meantime, the document below specifies only those > profiles which the authors believe are useful, although we recognize that > other members of the Working Group prefer other profiles. We would like to > try to keep this document focused though on things that are actually being > implemented. > > ------------------------------------------------------------------------ > > Subject: I-D ACTION:draft-rosen-mpls-profiles-00.txt > Date: Wed, 08 Mar 2000 06:32:21 -0500 > From: Internet-Drafts@ietf.org > To: IETF-Announce: ; > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : MPLS Profiles > Author(s) : E. Rosen, B. Thomas, L. Levine, > C. Iturralde, G. Swallow > Filename : draft-rosen-mpls-profiles-00.txt > Pages : 9 > Date : 07-Mar-00 > > The MPLS protocol specifications provide a large number of options, > and it can be difficult to know exactly which protocol messages, > objects, and procedures must be supported in order to provide some > particular application of MPLS, or in order to interoperate with some > other implementation. This document specifies a number of MPLS > 'Profiles'. Each Profile is a subset of the full MPLS functionality, > specified in enough detail to ensure that two implementations of a > given Profile will interoperate. This document also specifies which > Profiles may be used for which purposes. In the future, it is hoped > that specifications for the applications of MPLS will specify the > Profiles that must be implemented in order to support the > application. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosen-mpls-profiles-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-rosen-mpls-profiles-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-rosen-mpls-profiles-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ -- Loa Andersson Director Routing Architecture Lab, EMEA St Eriksgatan 115A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 e-mail: loa.andersson@nortelnetworks.com From owner-mpls@UU.NET Thu Mar 23 17:41:20 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21175 for ; Thu, 23 Mar 2000 17:41:20 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihuw27776; Thu, 23 Mar 2000 22:41:22 GMT Received: by mail-control.mail.uu.net id QQihuw20014 for mpls-outgoing; Thu, 23 Mar 2000 22:41:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihuw19965 for ; Thu, 23 Mar 2000 22:40:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihuw08682 for ; Thu, 23 Mar 2000 17:40:41 -0500 (EST) Received: from smtprtp.ntcom.nortel.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp.ntcom.nortel.net [137.118.22.15]) id QQihuw19414 for ; Thu, 23 Mar 2000 22:40:38 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Thu, 23 Mar 2000 17:32:32 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 17:31:43 -0500 Message-ID: From: "Don Fedyk" To: John.Shaw@tellabs.com, YickBeng.Gan@tellabs.com, mpls@UU.NET Subject: RE: RE: LDP/CR-LDP Date: Thu, 23 Mar 2000 17:31:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9517.9082BF9C" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9517.9082BF9C Content-Type: text/plain; charset="iso-8859-1" Please see the comments below, > -----Original Message----- > From: John.Shaw@tellabs.com [mailto:John.Shaw@tellabs.com] > Sent: Thursday, March 23, 2000 9:43 AM > To: YickBeng.Gan@tellabs.com; mpls@UU.NET > Subject: RE: RE: LDP/CR-LDP > > > VPNs and QoS are created by edge routers and can be done in many ways, > some discusssed openly in IETF and others more > vendor-specific. Cisco > uses BGP-based RFC-2457 as a means to distribute VPN membership > information among the edge routers. everst intent was to establish > virtual routers at the time IP interfaces are provisioned. > Cisco uses > RSVP to signal L2 paths to create specifc LSPs for the VPNs. I believe that Cisco uses TDP now and LDP in the future to create specific LSPs. Has this changed ? > Everest > was planning to use ATM-SVCs, then evolve to LSPs and would be > indifferent to RSVP vs. CR-LDP. QoS has many more options, most that > say to have a different LSP to the same edge-edge path for each QoS > class. These can be set up using RSVP or CR-LDP. Different vendors > have different approaches to QoS. Our approach is the triggfers and > treatments model. We will initially map into different ATM SVCs with > travel p rofiles. As we implement MPLS with LER, we would map > different classes into LSPs that have traffic profiles created using > CR-LDP or RSVP. AS a transit LSR, we only woiuld need to support > whatever scheme the LERs implement, assuming they are compatible. I > would not suppose that different vendors like Cisco or Nortel > would have > similar apporaches to QoS or VPNs, where they can't even agree on > simpler things. There are many models of VPNs. When it comes to MPLS, on the interior of the VPN you have: The Pipe model. MPLS LSPs for VPNs may be set up with specific traffic parameters using CR-LDP or RSVP-TE. Or the hose model. Applied to MPLS LSPs for VPNs a top label is used for connectivity without specific traffic parameters. A lower label specifies the VPN. This is the model of RFC 2547. Cisco suggests applying Diff-Serv CoS to the 2547 model for VPNs. There are advantages and draw backs to each scheme. As far as VPN routing goes, there are also several models. RFC 2764 talks about the different types of VPNs. The options of Virtual routers or BGP/MPLS based VPNs is discussed here. As far as vendor agreement goes, there are no standards for VPNs, just informational RFCs, I think we agree on that. Regards, Don > > -----Original Message----- > From: Gan, YickBeng /sg,its > Sent: Tuesday, March 21, 2000 8:41 PM > To: mpls@UU.NET > Cc: Gan, YickBeng /sg,its > Subject: FW: RE: LDP/CR-LDP > > Hi All > > I'm quite new to this. Does anybody know the answers to the below > questions. > > a) Can CR-LDP support VPN and QoS ? How can this be done ? > > b) Will both protocols (i.e. BGP and OSPF) affect VPN and QoS using > LDP/CR-LDP ? If yes, can I have the technical details. > > > > Thanks > > > Regards > Gan > > ------_=_NextPart_001_01BF9517.9082BF9C Content-Type: text/html; charset="iso-8859-1" RE: RE: LDP/CR-LDP

Please see the comments below,

> -----Original Message-----
> From: John.Shaw@tellabs.com [mailto:John.Shaw@tellabs.com]
> Sent: Thursday, March 23, 2000 9:43 AM
> To: YickBeng.Gan@tellabs.com; mpls@UU.NET
> Subject: RE: RE: LDP/CR-LDP
>
>
> VPNs and QoS are created by edge routers and can be done in many ways,
> some discusssed openly in IETF and others more
> vendor-specific.   Cisco
> uses BGP-based RFC-2457 as a means to distribute VPN membership
> information among the edge routers.  everst intent was to establish
> virtual routers at the time IP interfaces are provisioned.  
> Cisco uses
> RSVP to signal L2 paths to create specifc LSPs for the VPNs.
 
I believe that Cisco uses TDP now and LDP in the future to create
specific LSPs. Has this changed ?


> Everest
> was planning to use ATM-SVCs, then evolve to LSPs and would be
> indifferent to RSVP vs. CR-LDP.   QoS has many more options, most that
> say to have a different LSP to the same edge-edge path for each QoS
> class.  These can be set up using RSVP or CR-LDP.  Different vendors
> have different approaches to QoS.  Our approach is the triggfers and
> treatments model. We will initially map into different ATM SVCs with
> travel p rofiles.   As we implement MPLS with LER, we would map
> different classes into LSPs that have traffic profiles created using
> CR-LDP or RSVP.   AS a transit LSR, we only woiuld need to support
> whatever scheme the LERs implement, assuming they are compatible.   I
> would not suppose that different vendors like Cisco or Nortel
> would have
> similar apporaches to QoS or VPNs, where they can't even agree on
> simpler things.

There are many models of VPNs.
When it comes to MPLS, on the interior of the VPN you have:

The Pipe model. MPLS LSPs for VPNs may
be set up with specific traffic parameters using CR-LDP or RSVP-TE.

Or the hose model. 
Applied to MPLS LSPs for VPNs a top label is used for connectivity
without specific traffic parameters. A lower label specifies the
VPN. This is the model of RFC 2547.

Cisco suggests applying Diff-Serv CoS to the 2547 model for VPNs.

There are advantages and draw backs to each scheme.

As far as VPN routing goes, there are also several models. RFC 2764
talks about the different types of VPNs. The options of
Virtual routers or BGP/MPLS based VPNs is discussed here.

As far as vendor agreement goes, there are no standards for VPNs, just
informational RFCs, I think we agree on that. 

Regards,
Don



>
>     -----Original Message-----
>    From:       Gan, YickBeng /sg,its 
>    Sent:       Tuesday, March 21, 2000 8:41 PM
>    To:         mpls@UU.NET
>    Cc:         Gan, YickBeng /sg,its
>    Subject:    FW: RE: LDP/CR-LDP
>   
>    Hi All
>   
>    I'm quite new to this. Does anybody know the answers to the below
>    questions.
>   
>    a)    Can CR-LDP support VPN and QoS ? How can this be done ?
>      
>    b) Will both protocols (i.e. BGP and OSPF) affect VPN and QoS using
>       LDP/CR-LDP ? If yes, can I have the technical details.
>      
>   
>   
>    Thanks
>   
>   
>    Regards
>    Gan
>   
>

------_=_NextPart_001_01BF9517.9082BF9C-- From owner-mpls@UU.NET Thu Mar 23 17:54:16 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26185 for ; Thu, 23 Mar 2000 17:54:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihux01067; Thu, 23 Mar 2000 22:54:17 GMT Received: by mail-control.mail.uu.net id QQihux20605 for mpls-outgoing; Thu, 23 Mar 2000 22:53:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihux20599 for ; Thu, 23 Mar 2000 22:53:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihux28964; Thu, 23 Mar 2000 17:53:42 -0500 (EST) Received: from ckmso1.proxy.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ckmso1.att.com [12.20.58.69]) id QQihux00351; Thu, 23 Mar 2000 22:53:42 GMT Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id RAA15569; Thu, 23 Mar 2000 17:53:40 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA27743; Thu, 23 Mar 2000 17:52:54 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 17:53:44 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA01BBD7B6@njc240po03.ho.att.com> From: "Ash, Gerald R (Jerry), ALARC" To: te-wg@UU.NET Cc: "Ash, Gerald R (Jerry), ALARC" , mpls@UU.NET Subject: RE: TE & QoS Methods for IP-,ATM-,& TDM-Based Multiservice Networ ks Date: Thu, 23 Mar 2000 17:53:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I apologize for the problems with the PDF files in the earlier URL sent out. This has been updated and corrected. PDF files (with figures, 01 version) for can be located at: http://www.research.att.com/~jrex/jerry/ The draft will be presented at the Monday, March 27 TEWG meeting. Comments welcome. Thanks, Jerry Ash ------------------------------------------------------------ Gerald R. (Jerry) Ash AT&T Labs Middletown, NJ, USA gash@att.com ------------------------------------------------------------ To: IETF-Announce: ; Subject: I-D ACTION:draft-ash-te-qos-routing-00.txt From: Internet-Drafts@ietf.org Date: Wed, 15 Mar 2000 06:24:29 -0500 Reply-to: Internet-Drafts@ietf.org Sender: nsyracus@cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Traffic Engineering & QoS Methods for IP-,ATM-,& TDM-Based Multiservice Networks Author(s) : G. Ash Filename : draft-ash-te-qos-routing-00.txt Pages : 12 Date : 14-Mar-00 This contribution proposes initial text for a new recommendation on traffic engineering (TE) and QoS methods for IP-, ATM-. & TDM-based multiservice networks. This contribution describes and recommends TE methods which control a network's response to traffic demands and other stimuli, such as link failures or node failures. These TE methods include: (a) traffic management through control of routing functions, which include call routing (number/name translation to routing address), connection routing, QoS resource management, and routing table management. (b)capacity management through control of network design. (c)TE operational requirements for traffic management and capacity management, including forecasting, performance monitoring, and short-term network adjustment. These TE methods are recommended for application across network types based on established practice and experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-te-qos-routing-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ash-te-qos-routing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ash-te-qos-routing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. From owner-mpls@UU.NET Thu Mar 23 21:52:18 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19197 for ; Thu, 23 Mar 2000 21:52:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihvn10247; Fri, 24 Mar 2000 02:52:19 GMT Received: by mail-control.mail.uu.net id QQihvn03138 for mpls-outgoing; Fri, 24 Mar 2000 02:51:54 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihvn03133 for ; Fri, 24 Mar 2000 02:51:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihvn26058 for ; Thu, 23 Mar 2000 21:51:46 -0500 (EST) Received: from mail3.ntu.edu.sg by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail3.ntu.edu.sg [155.69.1.91]) id QQihvn09692 for ; Fri, 24 Mar 2000 02:51:37 GMT Received: by mail3.ntu.edu.sg with Internet Mail Service (5.5.2448.0) id ; Fri, 24 Mar 2000 10:50:58 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE01FDCDA8@exchange4.ntu.edu.sg> From: Shen Gangxiang To: "'Yangguang Xu'" , mpls@UU.NET Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Fri, 24 Mar 2000 10:50:52 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk Hi, To my knowledge, currently there seems no OXC product (commercially announce) supporting all-optical wavelength conversion. The all-optical wavelength converter is still costly and also not very mature. Gangxiang -----Original Message----- From: Yangguang Xu [mailto:xuyg@lucent.com] Sent: Thursday, March 23, 2000 11:32 PM To: mpls@UU.NET Subject: Re: Comments on draft-ip-optical-framework-00.txt There have been many discussions about wavelength conversion. And we all agree it is good. Can anyone tell me which OXC product (commercially announced) doesn't support wavelength conversion? Yangguang From owner-mpls@UU.NET Fri Mar 24 02:12:48 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02841 for ; Fri, 24 Mar 2000 02:12:47 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihwe06319; Fri, 24 Mar 2000 07:12:46 GMT Received: by mail-control.mail.uu.net id QQihwe24423 for mpls-outgoing; Fri, 24 Mar 2000 07:12:11 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihwe24409 for ; Fri, 24 Mar 2000 07:12:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihwe18344 for ; Fri, 24 Mar 2000 02:11:23 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihwe04812 for ; Fri, 24 Mar 2000 07:11:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA20613 for mpls@uu.net; Fri, 24 Mar 2000 02:11:22 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihwe24277 for ; Fri, 24 Mar 2000 07:10:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihwe18275 for ; Fri, 24 Mar 2000 02:10:32 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQihwe05757 for ; Fri, 24 Mar 2000 07:10:31 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id XAA27587; Thu, 23 Mar 2000 23:10:20 -0800 (PST) Message-Id: <4.2.2.20000324175057.00a95940@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 24 Mar 2000 18:09:16 +1100 To: "Don Fedyk" From: Jeremy Lawrence Subject: RE: RE: LDP/CR-LDP Cc: John.Shaw@tellabs.com, mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Don & John, One response inline. At 17:31 03/23/2000 -0500, Don Fedyk wrote: >Please see the comments below, > > > -----Original Message----- > > From: John.Shaw@tellabs.com [mailto:John.Shaw@tellabs.com] > > Sent: Thursday, March 23, 2000 9:43 AM > > To: YickBeng.Gan@tellabs.com; mpls@UU.NET > > Subject: RE: RE: LDP/CR-LDP > > > > > > VPNs and QoS are created by edge routers and can be done in many ways, > > some discusssed openly in IETF and others more > > vendor-specific. Cisco > > uses BGP-based RFC-2457 as a means to distribute VPN membership > > information among the edge routers. everst intent was to establish > > virtual routers at the time IP interfaces are provisioned. > > Cisco uses > > RSVP to signal L2 paths to create specifc LSPs for the VPNs. > >I believe that Cisco uses TDP now and LDP in the future to create >specific LSPs. Has this changed ? No. To qualify "future", Cisco has demonstrated working LDP code (with Nortel and others), though LDP is not yet in the fully-tested-and-shipping code. One nuance of RFC2547 (and draft-rosen-rfc2547bis-00.txt) is that LDP or TDP is used to set up LSPs for the aggregate traffic between edge LSRs, where each edge LSR is part of the service provider's network and supports numerous VPNs. LDP or TDP not used to "create specific LSPs for the VPNs". Hierachical labelling is used so that a top-level label is not used for each VPN; a second level of labelling is used to carry VPN information. The labels for the VPN information are distributed by piggy-backing them on the BGP distribution of the VPN routing information. Regards, Jeremy Lawrence From owner-mpls@UU.NET Fri Mar 24 05:38:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15416 for ; Fri, 24 Mar 2000 05:38:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihws19050; Fri, 24 Mar 2000 10:38:51 GMT Received: by mail-control.mail.uu.net id QQihws27620 for mpls-outgoing; Fri, 24 Mar 2000 10:38:14 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihws27614 for ; Fri, 24 Mar 2000 10:38:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihws17765 for ; Fri, 24 Mar 2000 05:37:43 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihws07895 for ; Fri, 24 Mar 2000 10:37:42 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA29114 for mpls@uu.net; Fri, 24 Mar 2000 05:37:37 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihws27580 for ; Fri, 24 Mar 2000 10:37:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihws05812 for ; Fri, 24 Mar 2000 05:36:58 -0500 (EST) Received: from qnsgs000.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qnsgs000.nortelnetworks.com [47.211.0.31]) id QQihws07577 for ; Fri, 24 Mar 2000 10:36:57 GMT Received: from zhard00m.europe.nortel.com (actually zhard00m) by qnsgs000.nortel.com; Fri, 24 Mar 2000 10:22:31 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Mar 2000 10:22:20 -0000 Message-ID: <33E324D95F44D311AA3E00204840075B603E21@zhard00e.europe.nortel.com> From: "Roy Mauger" To: "'Voice Over MPLS'" Cc: brucet@europe.cisco.com, alchiu@att.com, anttik@integralaccess.com, mpls@UU.NET, vompls Subject: RE: Announcing draft-lefaucheur-vompls-bearer-cont-00.txt Date: Fri, 24 Mar 2000 10:22:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF957A.D5E06086" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF957A.D5E06086 Content-Type: text/plain Francois, I found your extensions to the VoMPLS reference model interesting and your resume of the current work on QoS in the IETF quite helpful. However your suggestion in section 6 that this work be adopted, without review, as a baseline solution is premature. This meeting is a BOF with the objective of starting a working group. An appropriate task for the first meeting of the working group would be to consider reference solutions, obviously, current work would be prominent in such discussions. Roy Mauger Next Generation Networks Advanced Technology Labs Nortel Networks: Harlow > -----Original Message----- > From: Francois Le Faucheur [SMTP:flefauch@cisco.com] > Sent: 22 March 2000 21:03 > To: Voice Over MPLS > Cc: brucet@europe.cisco.com; alchiu@att.com; anttik@integralaccess.com; > mpls@UU.NET > Subject: Announcing draft-lefaucheur-vompls-bearer-cont-00.txt > > Hello, > > This is to announce that > "Bearer Control for VoIP and VoMPLS Control Plane" is now available from : > ftpeng.cisco.com/ftp/flefauch/ > > This draft will be presented during the VoMPLS BOF at the Adelaide > meeting. > > Thanks > > Francois > > --- > You are currently subscribed to vompls as: rhm@nortelnetworks.com > To subscribe: vompls-request@lists.integralaccess.com > In body: subscribe (unsubscribe) > Archive: http://sonic.sparklist.com/scripts/lyris.pl?enter=vompls ------_=_NextPart_001_01BF957A.D5E06086 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Announcing = draft-lefaucheur-vompls-bearer-cont-00.txt

Francois,

I found your = extensions to the VoMPLS reference model interesting and your resume of = the current work on QoS in the IETF quite helpful. However your = suggestion in section 6 that this work be adopted, without review, as a = baseline solution is premature. This meeting is a BOF with the = objective of starting a working group. An appropriate task for the = first meeting of the working group would be to consider reference = solutions, obviously, current work would be prominent in such = discussions.

Roy Mauger

Next Generation Networks
Advanced Technology Labs
Nortel Networks: Harlow


    -----Original Message-----
    From:   Francois Le Faucheur = [SMTP:flefauch@cisco.com]
    Sent:   22 March 2000 21:03
    To:     Voice Over MPLS
    Cc:     brucet@europe.cisco.com; alchiu@att.com; = anttik@integralaccess.com; mpls@UU.NET
    Subject:       = Announcing = draft-lefaucheur-vompls-bearer-cont-00.txt

    Hello,

    This is to announce that = <draft-lefaucheur-vompls-bearer-cont-00.txt>
    "Bearer Control for VoIP and = VoMPLS Control Plane" is now available from :
    ftpeng.cisco.com/ftp/flefauch/

    This draft will be presented during = the VoMPLS BOF at the Adelaide meeting.

    Thanks

    Francois

    ---
    You are currently subscribed to = vompls as: rhm@nortelnetworks.com
    To subscribe: = vompls-request@lists.integralaccess.com
    In body: subscribe = (unsubscribe)
    Archive: http://sonic.sparklist.com/scripts/lyris.pl?enter=3Dvo= mpls

------_=_NextPart_001_01BF957A.D5E06086-- From owner-mpls@UU.NET Fri Mar 24 07:50:35 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29767 for ; Fri, 24 Mar 2000 07:50:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihxb12299; Fri, 24 Mar 2000 12:50:34 GMT Received: by mail-control.mail.uu.net id QQihxb21386 for mpls-outgoing; Fri, 24 Mar 2000 12:50:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihxb21375 for ; Fri, 24 Mar 2000 12:50:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxb29227 for ; Fri, 24 Mar 2000 07:49:47 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQihxb08471 for ; Fri, 24 Mar 2000 12:49:46 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id HAA16373; Fri, 24 Mar 2000 07:49:39 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id HAA48617; Fri, 24 Mar 2000 07:49:55 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003241249.HAA48617@curtis-lt.avici.com> To: Rana Pratap Sircar cc: Krishna Bala , curtis@avici.com, Jagan Shantigram , Khaled Elsayed , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Reply-To: curtis@avici.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Fri, 24 Mar 2000 09:40:33 +0100." <38DB2A01.623C5AD6@mcd.alcatel.be> Date: Fri, 24 Mar 2000 07:49:55 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <38DB2A01.623C5AD6@mcd.alcatel.be>, Rana Pratap Sircar writes: > Hi , > > Can we also think of this possibility:- > > Space-based OXC overlay - In free Space , higher wavelengths can be used > as well as a larger number of wavelengths ( since the limitations due to > atmosphere [ scaterring and absorbtion etc.] and the limitation of glass > attenuation and dispertion is reduced ). Ofcourse, it has the limitation of > inherent difraction, and initial expenses of 3-4 Geostationary sattelites. So > , > having an Optical Network in space along with that on earth (fiber-based) fo > r > shorter ground based operations can be done. The data uplink and downlink to > and from the GEO can be through microwave ( possibility of inverse > multiplexing to increase the microwave data transmission ). This can give an > option of mobility to these networks ( can be downlinked at any point on > earth). > > Thanks & regards, > Rana I don't know of any deployment of this or plans for deployment. Its probably not worth the MPLS WG effort to accommodate special needs (which would more likely arise from the satellite uplinks than the fiberless optical network in space). If you periodically come back to earth keep us updated on progress. :-) Curtis From owner-mpls@UU.NET Fri Mar 24 08:51:36 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22163 for ; Fri, 24 Mar 2000 08:51:35 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihxf17921; Fri, 24 Mar 2000 13:51:32 GMT Received: by mail-control.mail.uu.net id QQihxf02798 for mpls-outgoing; Fri, 24 Mar 2000 13:51:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihxf02760 for ; Fri, 24 Mar 2000 13:50:51 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxf06552 for ; Fri, 24 Mar 2000 08:50:30 -0500 (EST) Received: from fire.integralaccess.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.160.25.239]) id QQihxf10862 for ; Fri, 24 Mar 2000 13:50:30 GMT Received: from akankkunen [192.168.1.124] by fire.integralaccess.com (SMTPD32-6.00) id A2361FD00DC; Fri, 24 Mar 2000 08:48:38 -0500 From: "Antti Kankkunen" To: "Voice Over MPLS" Cc: , , Subject: RE: Announcing draft-lefaucheur-vompls-bearer-cont-00.txt Date: Fri, 24 Mar 2000 08:48:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01BF956D.AE768500" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <33E324D95F44D311AA3E00204840075B603E21@zhard00e.europe.nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0021_01BF956D.AE768500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Announcing draft-lefaucheur-vompls-bearer-cont-00.txtFrancois & Roy, I would like to confirm that the main objective of the BOF is to demonstrate the level of interest in VoMPLS and to establish a working group. The first task of the working group is to achieve a consensus on the reference model and after that start work on the implementation details. Up to date we have avoided any discussion on implementation details with the intent of postponing that until we have a WG. Best regards, Antti K. ----Original Message----- From: Roy Mauger [mailto:rhm@nortelnetworks.com] Sent: Friday, March 24, 2000 5:22 AM To: Voice Over MPLS Cc: brucet@europe.cisco.com; alchiu@att.com; anttik@integralaccess.com; mpls@UU.NET; vompls Subject: RE: Announcing draft-lefaucheur-vompls-bearer-cont-00.txt Francois, I found your extensions to the VoMPLS reference model interesting and your resume of the current work on QoS in the IETF quite helpful. However your suggestion in section 6 that this work be adopted, without review, as a baseline solution is premature. This meeting is a BOF with the objective of starting a working group. An appropriate task for the first meeting of the working group would be to consider reference solutions, obviously, current work would be prominent in such discussions. Roy Mauger Next Generation Networks Advanced Technology Labs Nortel Networks: Harlow -----Original Message----- From: Francois Le Faucheur [SMTP:flefauch@cisco.com] Sent: 22 March 2000 21:03 To: Voice Over MPLS Cc: brucet@europe.cisco.com; alchiu@att.com; anttik@integralaccess.com; mpls@UU.NET Subject: Announcing draft-lefaucheur-vompls-bearer-cont-00.txt Hello, This is to announce that "Bearer Control for VoIP and VoMPLS Control Plane" is now available from : ftpeng.cisco.com/ftp/flefauch/ This draft will be presented during the VoMPLS BOF at the Adelaide meeting. Thanks Francois --- You are currently subscribed to vompls as: rhm@nortelnetworks.com To subscribe: vompls-request@lists.integralaccess.com In body: subscribe (unsubscribe) Archive: http://sonic.sparklist.com/scripts/lyris.pl?enter=vompls ------=_NextPart_000_0021_01BF956D.AE768500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Announcing = draft-lefaucheur-vompls-bearer-cont-00.txt
Francois & Roy,
 
I would like to confirm that the = main=20 objective of the BOF is to demonstrate the level of interest in VoMPLS = and to=20 establish a working group.
 
The first task of the working = group is to=20 achieve a consensus on the reference model and after that start work on = the=20 implementation details. Up to date we have avoided any discussion on=20 implementation details with the intent of postponing that until we have = a=20 WG.
 
Best regards,
 
Antti K.
  ----Original = Message-----
From: Roy=20 Mauger [mailto:rhm@nortelnetworks.com]
Sent: Friday, March = 24, 2000=20 5:22 AM
To: Voice Over MPLS
Cc: = brucet@europe.cisco.com;=20 alchiu@att.com; anttik@integralaccess.com; mpls@UU.NET;=20 vompls
Subject: RE: Announcing=20 draft-lefaucheur-vompls-bearer-cont-00.txt

Francois,

I found your extensions = to the VoMPLS=20 reference model interesting and your resume of the current work on QoS = in the=20 IETF quite helpful. However your suggestion in section 6 that this = work be=20 adopted, without review, as a baseline solution is premature. This = meeting is=20 a BOF with the objective of starting a working group. An appropriate = task for=20 the first meeting of the working group would be to consider reference=20 solutions, obviously, current work would be prominent in such=20 discussions.

Roy Mauger

Next Generation Networks =
Advanced Technology Labs
Nortel Networks: Harlow


    -----Original Message----- =
    From:   Francois Le Faucheur [SMTP:flefauch@cisco.com] =
    Sent:   22=20 March 2000 21:03
    To:     Voice=20 Over MPLS
    Cc:     brucet@europe.cisco.com; alchiu@att.com; = anttik@integralaccess.com;=20 mpls@UU.NET
    Subject:        = Announcing=20 draft-lefaucheur-vompls-bearer-cont-00.txt

    Hello,

    This is to announce that=20 <draft-lefaucheur-vompls-bearer-cont-00.txt>
    "Bearer Control for VoIP and VoMPLS Control = Plane" is now=20 available from :
    ftpeng.cisco.com/ftp/flefauch/

    This draft will be presented during = the VoMPLS=20 BOF at the Adelaide meeting.

    Thanks

    Francois

    ---
    You are=20 currently subscribed to vompls as: rhm@nortelnetworks.com =
    To subscribe:=20 vompls-request@lists.integralaccess.com
    In body: subscribe (unsubscribe)
    Archive: http://sonic.sparklist.com/scripts/lyris.pl?enter=3Dvompl= s=20

------=_NextPart_000_0021_01BF956D.AE768500-- From owner-mpls@UU.NET Fri Mar 24 09:09:40 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28124 for ; Fri, 24 Mar 2000 09:09:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihxg29464; Fri, 24 Mar 2000 14:09:38 GMT Received: by mail-control.mail.uu.net id QQihxg11033 for mpls-outgoing; Fri, 24 Mar 2000 14:09:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihxg10941 for ; Fri, 24 Mar 2000 14:08:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxg09196 for ; Fri, 24 Mar 2000 09:08:35 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihxg26534 for ; Fri, 24 Mar 2000 14:08:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA11625 for mpls@uu.net; Fri, 24 Mar 2000 09:08:34 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihxg09569 for ; Fri, 24 Mar 2000 14:07:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihxg26721 for ; Fri, 24 Mar 2000 09:07:17 -0500 (EST) Received: from albatross.wise.edt.ericsson.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQihxg27899 for ; Fri, 24 Mar 2000 14:07:16 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id OAA28205 for ; Fri, 24 Mar 2000 14:57:25 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA08103; Fri, 24 Mar 2000 15:00:30 +0100 (MET) Received: from eed.ericsson.se (akenpc-8 [164.48.130.236]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA23978; Fri, 24 Mar 2000 15:00:29 +0100 (MET) Message-ID: <38DB7479.D605EE62@eed.ericsson.se> Date: Fri, 24 Mar 2000 14:58:18 +0100 From: eedima Organization: Ericsson Eurolab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Voice Over MPLS CC: mpls@UU.NET Subject: Re: Announcing draft-lefaucheur-vompls-bearer-cont-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit A small comment to the VoMPLS framework doc: In 5.4.2 is stated: the abover requirements imply that VoMPLS systems should be constructed where call agent is aware of LSP usage..... doing so is against the princip of separation of call controll and bearer service which is one of the main goals of future multiservice network architectures. The call agent shall not be aware of the transport medium used and even more of LSP usage or not. To my opinion is the task of the BC or Resource Management function on the bearer level to aplly CAC. regards Ioannis Masmanidis -- Ericsson Eurolab Deutschland D-52134 Herzogenrath, Ericsson-Allee 1 email: Ioannis.Masmanidis@eed.ericsson.se phone: +49 2407 575 417 fax: ... 477 From owner-mpls@UU.NET Fri Mar 24 09:19:02 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01887 for ; Fri, 24 Mar 2000 09:19:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihxh06573; Fri, 24 Mar 2000 14:19:00 GMT Received: by mail-control.mail.uu.net id QQihxh12534 for mpls-outgoing; Fri, 24 Mar 2000 14:18:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihxh12529 for ; Fri, 24 Mar 2000 14:18:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxh10769 for ; Fri, 24 Mar 2000 09:17:54 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihxh05007 for ; Fri, 24 Mar 2000 14:17:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA12872 for mpls@uu.net; Fri, 24 Mar 2000 09:17:52 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihxh12499 for ; Fri, 24 Mar 2000 14:17:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxh28415 for ; Fri, 24 Mar 2000 09:17:30 -0500 (EST) Received: from mailgate.fore.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQihxh04683 for ; Fri, 24 Mar 2000 14:17:30 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA07179; Fri, 24 Mar 2000 09:17:22 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA28793; Fri, 24 Mar 2000 09:17:24 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Mar 2000 09:12:51 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF208B8A@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "'Voice Over MPLS'" Cc: mpls@UU.NET Subject: RE: Announcing draft-lefaucheur-vompls-bearer-cont-00.txt Date: Fri, 24 Mar 2000 09:16:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Separating bearer control from call control so far that call control is not aware of channel (lsp) bandwidth consumption is possible, but not in the direction many of us are going. I think that there are many who believe, and are implementing, schemes where call admission control is done in the call control, and uses its knowledge of bearer (lsp) capacity as part of its decisions. This arises from, among other things, the desire to keep the complexity of the media gateways low. It also arises from the inability of the bearer control to have all the information it would need to determine what bandwidth the stream actually uses, and what policies the network has for oversubscription. Brian > -----Original Message----- > From: eedima [mailto:eedima@eed.ericsson.se] > Sent: Friday, March 24, 2000 8:58 AM > To: Voice Over MPLS > Cc: mpls@UU.NET > Subject: Re: Announcing draft-lefaucheur-vompls-bearer-cont-00.txt > > > > > A small comment to the VoMPLS framework doc: > In 5.4.2 is stated: the abover requirements imply that VoMPLS systems > should be constructed where call agent is aware of LSP usage..... > > doing so is against the princip of separation of call controll and > bearer service > which is one of the main goals of future multiservice network > architectures. > The call agent shall not be aware of the transport medium > used and even > more > of LSP usage or not. To my opinion is the task of the BC or Resource > Management function on the bearer level to aplly CAC. > > regards > > Ioannis Masmanidis > -- > Ericsson Eurolab Deutschland > D-52134 Herzogenrath, Ericsson-Allee 1 > email: Ioannis.Masmanidis@eed.ericsson.se > phone: +49 2407 575 417 fax: ... 477 > > > > --- > You are currently subscribed to vompls as: brosen@fore.com > To subscribe: vompls-request@lists.integralaccess.com > In body: subscribe (unsubscribe) > Archive: http://sonic.sparklist.com/scripts/lyris.pl?enter=vompls > From owner-mpls@UU.NET Fri Mar 24 09:25:05 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03877 for ; Fri, 24 Mar 2000 09:25:04 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihxh10976; Fri, 24 Mar 2000 14:25:04 GMT Received: by mail-control.mail.uu.net id QQihxh12897 for mpls-outgoing; Fri, 24 Mar 2000 14:24:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihxh12892 for ; Fri, 24 Mar 2000 14:24:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxh29639 for ; Fri, 24 Mar 2000 09:24:14 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQihxh10648 for ; Fri, 24 Mar 2000 14:24:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA14010 for mpls@uu.net; Fri, 24 Mar 2000 09:24:12 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihxh12877 for ; Fri, 24 Mar 2000 14:23:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxh29518 for ; Fri, 24 Mar 2000 09:23:42 -0500 (EST) Received: from albatross.wise.edt.ericsson.se by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQihxh10142 for ; Fri, 24 Mar 2000 14:23:41 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA28665 for ; Fri, 24 Mar 2000 15:13:50 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA22059; Fri, 24 Mar 2000 15:16:54 +0100 (MET) Received: from eed.ericsson.se (akenpc-8 [164.48.130.236]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA27553; Fri, 24 Mar 2000 15:16:53 +0100 (MET) Message-ID: <38DB78B5.EB369E2C@eed.ericsson.se> Date: Fri, 24 Mar 2000 15:16:22 +0100 From: eedima Organization: Ericsson Eurolab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Voice Over MPLS CC: mpls@UU.NET Subject: CC part of the GW? References: <38DB7479.D605EE62@eed.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I've got a question regarding figure 2 in section 5.5. Why is the CC entity part of the GW? To my understanding GW represent network elements which are mainly convert between bearer services/transport protocols/transport medium. CC functions should be separated at least logically (see also comment below). There must be a generic interface/protocol (MGCP?) between CC and BC in the MG so that those 2 layers are kept independent. Ioannis eedima wrote: > A small comment to the VoMPLS framework doc: > In 5.4.2 is stated: the abover requirements imply that VoMPLS systems > should be constructed where call agent is aware of LSP usage..... > > doing so is against the princip of separation of call controll and > bearer service > which is one of the main goals of future multiservice network > architectures. > The call agent shall not be aware of the transport medium used and even > more > of LSP usage or not. To my opinion is the task of the BC or Resource > Management function on the bearer level to aplly CAC. > > regards > > Ioannis Masmanidis > ----- > You are currently subscribed to vompls as: Ioannis.Masmanidis@eed.ericsson.se > To subscribe: vompls-request@lists.integralaccess.com > In body: subscribe (unsubscribe) > Archive: http://sonic.sparklist.com/scripts/lyris.pl?enter=vompls -- Ericsson Eurolab Deutschland D-52134 Herzogenrath, Ericsson-Allee 1 email: Ioannis.Masmanidis@eed.ericsson.se phone: +49 2407 575 417 fax: ... 477 From owner-mpls@UU.NET Fri Mar 24 09:36:44 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07828 for ; Fri, 24 Mar 2000 09:36:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihxi19482; Fri, 24 Mar 2000 14:36:44 GMT Received: by mail-control.mail.uu.net id QQihxi13631 for mpls-outgoing; Fri, 24 Mar 2000 14:36:17 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihxi13618 for ; Fri, 24 Mar 2000 14:36:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihxi01911 for ; Fri, 24 Mar 2000 09:36:11 -0500 (EST) Received: from c2.ciena.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: c2.ciena.com [204.240.57.5]) id QQihxi18981 for ; Fri, 24 Mar 2000 14:36:10 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id JAA06301; Fri, 24 Mar 2000 09:35:56 -0500 (EST) Received: from wnt02exg01(204.240.57.200) by c2.ciena.com via smap (V2.0) id xmaa06294; Fri, 24 Mar 00 09:35:54 -0500 Received: by wnt02exg01.ciena.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Mar 2000 09:31:20 -0500 Message-ID: <33A5068D56ECD21184A30008C75D0CCEF964BA@wnt02exg01.ciena.com> From: "Berthold, Joseph" To: mpls@UU.NET, "'Shen Gangxiang'" Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Fri, 24 Mar 2000 09:31:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk It should not matter what technology an OXC product uses to support wavelength conversion. When an all optical technology is the best economic and technological choice it will be used. Currently wavelength conversion is accomplished by O/E/O conversion, and includes 3R regeneration as an extra bonus. Not all OXCs support wavelength conversion, but the ones that do remove most of the transmission impairments. When we have all-optical wavelength conversion we will see if it comes with a 3R function that works as well as O/E/O. If it dosen't we will need to keep track of transmission impairments in making the routing decision, as we need to do today for all optical OXCs. Joe > ---------- > From: Shen Gangxiang > Sent: Thursday, March 23, 2000 9:50 PM > To: 'Yangguang Xu'; mpls@UU.NET > Subject: RE: Comments on draft-ip-optical-framework-00.txt > > Hi, > > To my knowledge, currently there seems no OXC product (commercially > announce) supporting all-optical wavelength conversion. The all-optical > wavelength converter is still costly and also not very mature. > > > Gangxiang > > -----Original Message----- > From: Yangguang Xu [mailto:xuyg@lucent.com] > Sent: Thursday, March 23, 2000 11:32 PM > To: mpls@UU.NET > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > There have been many discussions about wavelength conversion. And we all > agree > it is good. Can anyone tell me which OXC product (commercially announced) > doesn't support wavelength conversion? > > Yangguang > From owner-mpls@UU.NET Fri Mar 24 10:52:34 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04226 for ; Fri, 24 Mar 2000 10:52:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihxn22606; Fri, 24 Mar 2000 15:52:32 GMT Received: by mail-control.mail.uu.net id QQihxn26450 for mpls-outgoing; Fri, 24 Mar 2000 15:51:55 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihxn26443 for ; Fri, 24 Mar 2000 15:51:47 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxn26708 for ; Fri, 24 Mar 2000 10:51:23 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQihxn14671 for ; Fri, 24 Mar 2000 15:51:23 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA23499 for ; Fri, 24 Mar 2000 08:17:28 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA26737 for mpls@uu.net; Fri, 24 Mar 2000 10:50:16 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQihwl07112 for ; Fri, 24 Mar 2000 08:55:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihwl09630 for ; Fri, 24 Mar 2000 03:55:19 -0500 (EST) Received: from smtp1-gw.tp1rc.edu.tw by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1-gw.tp1rc.edu.tw [163.28.16.23]) id QQihwl13042 for ; Fri, 24 Mar 2000 08:55:16 GMT Received: from ms.cc.ntu.edu.tw (ms.cc.ntu.edu.tw [140.112.8.200]) by smtp1-gw.tp1rc.edu.tw (8.9.3/8.9.3) with ESMTP id QAA98406 for ; Fri, 24 Mar 2000 16:50:50 +0800 (CST) (envelope-from d6942004@ms.cc.ntu.edu.tw) Received: from ms.cc.ntu.edu.tw (elephant.ee.ntu.edu.tw [140.112.19.82]) by ms.cc.ntu.edu.tw (8.9.1/8.9.1) with ESMTP id QAA18417 for ; Fri, 24 Mar 2000 16:55:01 +0800 (CST) Message-ID: <38DB2E5A.ADCB1A0@ms.cc.ntu.edu.tw> Date: Fri, 24 Mar 2000 16:59:06 +0800 From: d6942004 X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@UU.NET Subject: Difference between LSP and LSP tunnel? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi, Can somebody tell me the differences between LSP and LSP tunnel? I see the definition in "draft-ietf-mpls-arch-0.6txt". 1. LSP tunnel example: 3.27.4. Hierarchy: LSP Tunnels within LSPs Consider a LSP . Let us suppose that R1 receives unlabeled packet P, and pushes on its label stack the label to cause it to follow this path, and that this is in fact the Hop-by-hop path. However, let us further suppose that R2 and R3 are not directly connected, but are "neighbors" by virtue of being the endpoints of an LSP tunnel. So the actual sequence of LSRs traversed by P is . When P travels from R1 to R2, it will have a label stack of depth 1. R2, switching on the label, determines that P must enter the tunnel. R2 first replaces the Incoming label with a label that is meaningful to R3. Then it pushes on a new label. This level 2 label has a value which is meaningful to R21. Switching is done on the level 2 label by R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel, pops the label stack before forwarding the packet to R3. When R3 sees packet P, P has only a level 1 label, having now exited the tunnel. Since R3 is the penultimate hop in P's level 1 LSP, it pops the label stack, and R4 receives P unlabeled. but from the LSP definition In other words, we can speak of the level m LSP for Packet P as the sequence of routers: 1. which begins with an LSR (an "LSP Ingress") that pushes on a level m label, 2. all of whose intermediate LSRs make their forwarding decision by label Switching on a level m label, 3. which ends (at an "LSP Egress") when a forwarding decision is made by label Switching on a level m-k label, where k>0, or when a forwarding decision is made by "ordinary", non-MPLS forwarding procedures. So my questions are 1. Is a LSP? 2. Is a LSP tunnel? 3. Trsffic engineering works on LSP or LSP tunnel? From owner-mpls@UU.NET Fri Mar 24 10:52:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04397 for ; Fri, 24 Mar 2000 10:52:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihxn16108; Fri, 24 Mar 2000 15:52:59 GMT Received: by mail-control.mail.uu.net id QQihxn26533 for mpls-outgoing; Fri, 24 Mar 2000 15:52:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihxn26516 for ; Fri, 24 Mar 2000 15:52:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihxn15754 for ; Fri, 24 Mar 2000 10:51:25 -0500 (EST) Received: from kickme.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kickme.cisco.com [198.92.30.42]) id QQihxn21577 for ; Fri, 24 Mar 2000 15:51:24 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA03777 for ; Fri, 24 Mar 2000 07:37:04 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA26731 for mpls@uu.net; Fri, 24 Mar 2000 10:49:53 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihwk06539 for ; Fri, 24 Mar 2000 08:42:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihwk27264 for ; Fri, 24 Mar 2000 03:41:51 -0500 (EST) Received: from btm4r4.alcatel.be by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: btm4r4.alcatel.be [195.207.101.110]) id QQihwk27328 for ; Fri, 24 Mar 2000 08:41:50 GMT Received: from btk050.mcd.bel.alcatel.be (btk050.mcd.bel.alcatel.be [138.203.225.181]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id JAA22139; Fri, 24 Mar 2000 09:40:38 +0100 (MET) Received: from oldbtk0bz.mcd.bel.alcatel.be (oldbtk0bz [138.203.226.81]) by btk050.mcd.bel.alcatel.be (8.8.8+Sun/8.8.8/HiSpeedCompany) with ESMTP id JAA11645; Fri, 24 Mar 2000 09:40:35 +0100 (MET) Received: from mcd.alcatel.be (localhost [127.0.0.1]) by oldbtk0bz.mcd.bel.alcatel.be (8.8.8/8.8.8/HiSpeedCompanyV0.1beta) with ESMTP id JAA11660; Fri, 24 Mar 2000 09:40:33 +0100 (MET) Message-ID: <38DB2A01.623C5AD6@mcd.alcatel.be> Date: Fri, 24 Mar 2000 09:40:33 +0100 From: Rana Pratap Sircar Organization: Wipro Infotech Global R & D X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Krishna Bala CC: curtis@avici.com, Jagan Shantigram , Khaled Elsayed , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <002801bf9502$2e1c67f0$425cc697@tempest> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi , Can we also think of this possibility:- Space-based OXC overlay - In free Space , higher wavelengths can be used as well as a larger number of wavelengths ( since the limitations due to atmosphere [ scaterring and absorbtion etc.] and the limitation of glass attenuation and dispertion is reduced ). Ofcourse, it has the limitation of inherent difraction, and initial expenses of 3-4 Geostationary sattelites. So, having an Optical Network in space along with that on earth (fiber-based) for shorter ground based operations can be done. The data uplink and downlink to and from the GEO can be through microwave ( possibility of inverse multiplexing to increase the microwave data transmission ). This can give an option of mobility to these networks ( can be downlinked at any point on earth). Thanks & regards, Rana Krishna Bala wrote: > Jagan, > There are several architectural models for IP over Optical Networks that > are emerging: > > 1. Peer Model > In this model the IP router is entirely aware of the details on the > underlying > optical network (topology information, wavelength and port usage and lamda > assignment). > It is able to control and manage entire end to end paths. In this model the > OXC is "agile but fat & dumb". > 2. Overlay Model > The optical layer is "fat & dumb". The lamda connections between the IP > routers behave as if they were dedicated fibers between them. The IP routes > provision logical optical circuits over a fixed or at best a quasi-fixed > optical > layer. > 3. Open Model > In this scenario the optical layer comprises of several "vendor/network > operator clouds" > that have well defined interfaces. For example, an Optical UNI can be used > to > interconnect the IP router to the OXC and the Optical NNI can be used to > connect > two optical network domains together. Here the optical layer is "fat, smart > and agile". > > It is unclear at this time which of these models will prevail. > > Krishna Bala > Tellium > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis > > Villamizar > > Sent: Thursday, March 23, 2000 1:55 PM > > To: Jagan Shantigram > > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > > ip-optical@lists.research.bell-labs.com > > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > > > > > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > > Shantigram wr > > ites: > > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > > > > > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > > > >> > > > >> > > > >> Hello Jagan, > > > >> > > > >> > When we do not have lambda conversion however, this problem cannot > > > >> > be solved optimally.. it is akin to the graph coloring > > > >> > problem - which ofcourse has heuristics that can get us to > > > >> > a factor (?) of the optimal solution. So, connections may > > > >> > be blocked even though there is capacity on the fiber to > > > >> > support it, just because the wavelength is already used up. > > > >> > > > > >> > > > >> Connections can be blocked when?? At service provisioning time or > > > >> at the time the connection is requested?? My point is a > > > >> connection of 2.48 Gbps is not likely to be a random event or an > > > >> ATM-like SVC. If a customer would require such huge bandwidth, it > > > >> would need that BW to go through or it would better look for > > > >> another carrier that will provide a TDM/leased line?? Of course > > > >> wavelength conversion can help build a better-utilized network, > > > >> no question about that. > > > >> > > > >> Khaled > > > > > > > > > > > >The exception to the rule that "a connection of 2.48 Gbps is not > > > >likely to be a random event" is where a very major event, possilble > > > >external to one's own network results in a shift in traffic patterns > > > >that is significant enough to require that additional lambdas be added > > > >to existing paths. > > > > > > > >The real world example in the ISP world is a failure of a peering > > > >point of some sort, a provider interconnect, a NAP or NAP connectivity > > > >of some party. Since all major ISPs are connected to each other at > > > >more than one geographically diverse peering point, the traffic will > > > >still flow, but the path will have changed. > > > > > > > >This may mean that a path that previously required 3 lambdas (for > > > >example), now requires 4 lambdas. There are at least 3 ways to > > > >accommodate this requirement: > > > > > > > > 1. An external management system adds a lambda to both the routers > > > > at either end and the optical switches (demonstrated at OFC). > > > > > > > > 2. The router signals the requirement/desire for an additional > > > > lambda to the adjacent optical switch which sets up a path. > > > > This is the overlay model. It can be trivially implemented with > > > > MPLS by having the router send a loose source hop in the ERO > > > > allowing the switch to create the path or reject the request. > > > > > > Curtis, > > > > > > Am trying to understand the model here. Does the overlay model > > > as you put above imply that the optical devices need to be mini-routers > > > in their own right? They have to be able to set up end-to-end optical > > > paths.. perhaps some kind of binding between the end-host IP address > > > and an addressing scheme for Optical devices.. ala ATM? > > > What does the overlay model entail? > > > > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or > > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > > > > Alternately, the lambdas can be set statically and the edge router > > simple advertises a Lambda-Switch Capable link ala > > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt > > accommodating the overlay model). > > > > I don't think draft-kompella-mpls-optical-00.txt has all the details > > sufficiently ironed out for the case where the optical switch > > advertises the availability of an optical link. If it does, then the > > details ar just not clear to me. (Could be my careless reading). > > > > > > 3. The router has enough information about the characteristics of > > > > the optical devices to compute the path and so it does so. This > > > > is the peer model. > > > > > > > > > > What does this model need.. a protocol for exchanging information > > > between the router and the optical device? > > > > It needs a means to communicate OOB wrt the primary lightpath. That > > means would again be running the IGP and RSVP. Based on reading the > > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the > > optical switch exchanges this information OOB although I would imagine > > that it would be quite easy to maintian another interface (perhaps > > even an electrical, though gig-E would do fine) between the router and > > optical device in which the optical device advertises the optical > > links. The router on either end of an optical link, seeing or having > > set up a Packet-Switch Capable link would then have to bring up an > > RSVP adjacency over it, though I think it would not need an IGP > > adjacency. (I'm not clear on this last point.) > > > > The availability of certain types of links (Packet-Switch Capable, > > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm > > not clear on whether the adjacent LSR should advertise a Forwarding > > Adjacency PSC after RSVP comes up over a set of optical links (it > > seems to be the intent) but maybe the authors can clarify the usage. > > > > The ongoing discussion and the topic of the (way too numerous) > > framework documents floating around has been what additional > > information would be needed in order to provide adequate constraints > > to set up optical paths, a particularly difficult problem for > > transparent paths. > > > > > -jagan. > > > > > > >The way this might manifest itself is LSPs that might take an optical > > > >path from A to C are going from A to B to C because A to C lambdas are > > > >too full. If so, then A could in principle request an additional > > > >lambda, but in practice the means to signal this has not been defined. > > > > > > > >Curtis > > > > > > Jagannath Shantigram > > > Photonex Corporation > > > > btw- I exchanged some private email with one of the authors of > > draft-kompella-mpls-optical.txt and owe them some detailed comments > > (appologies to them for the delay, busy). After some brief discussion > > and after a second reading, the intent seems a lot more clear. The > > usage material is at the end so when reading the document from front > > to back the intent is not clear until the end and then a second > > reading is required. > > > > Curtis > > From owner-mpls@UU.NET Fri Mar 24 11:06:54 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09332 for ; Fri, 24 Mar 2000 11:06:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihxo02751; Fri, 24 Mar 2000 16:06:54 GMT Received: by mail-control.mail.uu.net id QQihxo03983 for mpls-outgoing; Fri, 24 Mar 2000 16:06:29 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihxo03878 for ; Fri, 24 Mar 2000 16:06:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihxo29521 for ; Fri, 24 Mar 2000 11:05:28 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQihxo01623 for ; Fri, 24 Mar 2000 16:05:26 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA05461 for ; Fri, 24 Mar 2000 08:31:10 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA26887 for mpls@uu.net; Fri, 24 Mar 2000 11:03:04 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihxo28883 for ; Fri, 24 Mar 2000 16:01:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxo28644 for ; Fri, 24 Mar 2000 11:00:54 -0500 (EST) Received: from gateway.oakwood.org by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: gateway.oakwood.org [198.111.175.3]) id QQihxo22110 for ; Fri, 24 Mar 2000 16:00:53 GMT Received: from mhntex01.oakwood.org by gateway.oakwood.org with SMTP id LAA23683 (InterLock SMTP Gateway 4.2 for ); Fri, 24 Mar 2000 11:00:03 -0500 Received: by MHNTEX01 with Internet Mail Service (5.5.2448.0) id ; Fri, 24 Mar 2000 10:58:05 -0500 Message-Id: From: HYADUCKJ To: "'John Drake'" , "'Krishna Bala'" , curtis@avici.com, Jagan Shantigram Cc: Khaled Elsayed , mpls@UU.NET, ip-optical@lists.research.bell-labs.com, HYADUCKJ Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Fri, 24 Mar 2000 10:58:02 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I believe the open model refers to areas not requiring constraints. The standardization process itself is a contraint system to specify limits and requirements on implementations. Where limits and other rigors are not essential for interoperability a case can be made for allowing "freedom to innovate" within a standardized framework. The constraints here apply to the "well defined interfaces" and allow for hiding (and later re-engineering or replacement) of the substrata. John *3. Open Model *In this scenario the optical layer comprises of several "vendor/network operator clouds" that have *well defined interfaces. For example, an Optical UNI can be used to interconnect the IP router to *the OXC and the Optical NNI can be used to connect two optical network domains together. Here the *optical layer is "fat, smart and agile". -----Original Message----- From: John Drake [mailto:jdrake@chromisys.com] Sent: Thursday, March 23, 2000 4:54 PM To: 'Krishna Bala'; curtis@avici.com; Jagan Shantigram Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com Subject: RE: Comments on draft-ip-optical-framework-00.txt >Krishna, > >A few points: >1) In the peer model, the routers are not necessarily aware of the complete >details of every optical link; if there is information that they don't >need, it can be filtered out on a link by link basis by the PXCs. >2) In the Overlay model, the PXC is computing the routes, so in your >terminology it is fat, agile, and smart. There is also nothing that >precludes an optical UNI in this model.. >3) Why the open model is called open is beyond me, since by definition the >control plane in each of the clouds is proprietary. I think a better way of >characterizing the open model is that it is just a special case of either >the peer or the overlay model, in which the vendor does not want to have a >standards based control plane between its switches. I.e., it >implements the standards based control plane at the edges of its network. >What you're calling an optical NNI is what I would call MPL(ambda)S. >Thanks, From owner-mpls@UU.NET Fri Mar 24 12:13:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02016 for ; Fri, 24 Mar 2000 12:13:22 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihxs25384; Fri, 24 Mar 2000 17:13:23 GMT Received: by mail-control.mail.uu.net id QQihxs17301 for mpls-outgoing; Fri, 24 Mar 2000 17:12:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQihxs17296 for ; Fri, 24 Mar 2000 17:12:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxs03907 for ; Fri, 24 Mar 2000 12:11:30 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQihxs23929 for ; Fri, 24 Mar 2000 17:11:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA20390 for ; Fri, 24 Mar 2000 09:37:01 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA27066 for mpls@uu.net; Fri, 24 Mar 2000 12:09:54 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihxr08135 for ; Fri, 24 Mar 2000 16:52:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQihxr10998 for ; Fri, 24 Mar 2000 11:52:27 -0500 (EST) Received: from rambo.globespan.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: p1.globespan.net [209.191.59.250]) id QQihxr09438 for ; Fri, 24 Mar 2000 16:52:27 GMT Received: from globespan.net (phoenix.ficon-tech.com [209.125.90.2]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HSB9GN9F; Fri, 24 Mar 2000 11:50:15 -0500 Message-ID: <38DB9E83.DBA69B4D@globespan.net> Date: Fri, 24 Mar 2000 11:57:40 -0500 From: Srinivasan Balaji Organization: GlobeSpan, Inc X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Fedyk CC: John.Shaw@tellabs.com, YickBeng.Gan@tellabs.com, mpls@UU.NET Subject: Re: LDP/CR-LDP References: Content-Type: multipart/alternative; boundary="------------7FF480F0287766283511C212" Sender: owner-mpls@UU.NET Precedence: bulk --------------7FF480F0287766283511C212 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, Please also look at the draft: draft-zhang-crldp-ext-for-vpn-00.txt. We have proposed a model for VPNs using CR-LDP & Potentially RSVP. Thanks Balaji. Don Fedyk wrote: > > > Please see the comments below, > > > -----Original Message----- > > From: John.Shaw@tellabs.com [mailto:John.Shaw@tellabs.com] > > Sent: Thursday, March 23, 2000 9:43 AM > > To: YickBeng.Gan@tellabs.com; mpls@UU.NET > > Subject: RE: RE: LDP/CR-LDP > > > > > > VPNs and QoS are created by edge routers and can be done in many > ways, > > some discusssed openly in IETF and others more > > vendor-specific. Cisco > > uses BGP-based RFC-2457 as a means to distribute VPN membership > > information among the edge routers. everst intent was to establish > > virtual routers at the time IP interfaces are provisioned. > > Cisco uses > > RSVP to signal L2 paths to create specifc LSPs for the VPNs. > > I believe that Cisco uses TDP now and LDP in the future to create > specific LSPs. Has this changed ? > > > Everest > > was planning to use ATM-SVCs, then evolve to LSPs and would be > > indifferent to RSVP vs. CR-LDP. QoS has many more options, most > that > > say to have a different LSP to the same edge-edge path for each QoS > > class. These can be set up using RSVP or CR-LDP. Different vendors > > > have different approaches to QoS. Our approach is the triggfers and > > > treatments model. We will initially map into different ATM SVCs with > > > travel p rofiles. As we implement MPLS with LER, we would map > > different classes into LSPs that have traffic profiles created using > > > CR-LDP or RSVP. AS a transit LSR, we only woiuld need to support > > whatever scheme the LERs implement, assuming they are compatible. > I > > would not suppose that different vendors like Cisco or Nortel > > would have > > similar apporaches to QoS or VPNs, where they can't even agree on > > simpler things. > > There are many models of VPNs. > When it comes to MPLS, on the interior of the VPN you have: > > The Pipe model. MPLS LSPs for VPNs may > be set up with specific traffic parameters using CR-LDP or RSVP-TE. > > Or the hose model. > Applied to MPLS LSPs for VPNs a top label is used for connectivity > without specific traffic parameters. A lower label specifies the > VPN. This is the model of RFC 2547. > > Cisco suggests applying Diff-Serv CoS to the 2547 model for VPNs. > > There are advantages and draw backs to each scheme. > > As far as VPN routing goes, there are also several models. RFC 2764 > talks about the different types of VPNs. The options of > Virtual routers or BGP/MPLS based VPNs is discussed here. > > As far as vendor agreement goes, there are no standards for VPNs, just > > informational RFCs, I think we agree on that. > > Regards, > Don > > > > > > -----Original Message----- > > From: Gan, YickBeng /sg,its > > Sent: Tuesday, March 21, 2000 8:41 PM > > To: mpls@UU.NET > > Cc: Gan, YickBeng /sg,its > > Subject: FW: RE: LDP/CR-LDP > > > > Hi All > > > > I'm quite new to this. Does anybody know the answers to the below > > > questions. > > > > a) Can CR-LDP support VPN and QoS ? How can this be done ? > > > > b) Will both protocols (i.e. BGP and OSPF) affect VPN and QoS > using > > LDP/CR-LDP ? If yes, can I have the technical details. > > > > > > > > Thanks > > > > > > Regards > > Gan > > > > -- ----------------------------------------------------------------- Srinivasan Balaji GlobeSpan, Inc Voice : (732) 283-2770 xtn.303 mailto:sbalaji@globespan.net Web : http://www.ficon-tech.com/home.htm ----------------------------------------------------------------- --------------7FF480F0287766283511C212 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Folks,
  Please also look at the draft: draft-zhang-crldp-ext-for-vpn-00.txt.
We have proposed a model for VPNs using CR-LDP & Potentially RSVP.

Thanks
Balaji.

Don Fedyk wrote:

 

Please see the comments below,

> -----Original Message-----
> From: John.Shaw@tellabs.com [mailto:John.Shaw@tellabs.com]
> Sent: Thursday, March 23, 2000 9:43 AM
> To: YickBeng.Gan@tellabs.com; mpls@UU.NET
> Subject: RE: RE: LDP/CR-LDP
>
>
> VPNs and QoS are created by edge routers and can be done in many ways,
> some discusssed openly in IETF and others more
> vendor-specific.   Cisco
> uses BGP-based RFC-2457 as a means to distribute VPN membership
> information among the edge routers.  everst intent was to establish
> virtual routers at the time IP interfaces are provisioned.
> Cisco uses
> RSVP to signal L2 paths to create specifc LSPs for the VPNs.

I believe that Cisco uses TDP now and LDP in the future to create
specific LSPs. Has this changed ?

> Everest
> was planning to use ATM-SVCs, then evolve to LSPs and would be
> indifferent to RSVP vs. CR-LDP.   QoS has many more options, most that
> say to have a different LSP to the same edge-edge path for each QoS
> class.  These can be set up using RSVP or CR-LDP.  Different vendors
> have different approaches to QoS.  Our approach is the triggfers and
> treatments model. We will initially map into different ATM SVCs with
> travel p rofiles.   As we implement MPLS with LER, we would map
> different classes into LSPs that have traffic profiles created using
> CR-LDP or RSVP.   AS a transit LSR, we only woiuld need to support
> whatever scheme the LERs implement, assuming they are compatible.   I
> would not suppose that different vendors like Cisco or Nortel
> would have
> similar apporaches to QoS or VPNs, where they can't even agree on
> simpler things.

There are many models of VPNs.
When it comes to MPLS, on the interior of the VPN you have:

The Pipe model. MPLS LSPs for VPNs may
be set up with specific traffic parameters using CR-LDP or RSVP-TE.

Or the hose model.
Applied to MPLS LSPs for VPNs a top label is used for connectivity
without specific traffic parameters. A lower label specifies the
VPN. This is the model of RFC 2547.

Cisco suggests applying Diff-Serv CoS to the 2547 model for VPNs.

There are advantages and draw backs to each scheme.

As far as VPN routing goes, there are also several models. RFC 2764
talks about the different types of VPNs. The options of
Virtual routers or BGP/MPLS based VPNs is discussed here.

As far as vendor agreement goes, there are no standards for VPNs, just
informational RFCs, I think we agree on that.

Regards,
Don
 

>
>     -----Original Message-----
>    From:       Gan, YickBeng /sg,its
>    Sent:       Tuesday, March 21, 2000 8:41 PM
>    To:         mpls@UU.NET
>    Cc:         Gan, YickBeng /sg,its
>    Subject:    FW: RE: LDP/CR-LDP
>
>    Hi All
>
>    I'm quite new to this. Does anybody know the answers to the below
>    questions.
>
>    a)    Can CR-LDP support VPN and QoS ? How can this be done ?
>
>    b) Will both protocols (i.e. BGP and OSPF) affect VPN and QoS using
>       LDP/CR-LDP ? If yes, can I have the technical details.
>
>
>
>    Thanks
>
>
>    Regards
>    Gan
>
>

--
  -----------------------------------------------------------------
  Srinivasan Balaji
  GlobeSpan, Inc
  Voice : (732) 283-2770 xtn.303
  mailto:sbalaji@globespan.net
  Web   : http://www.ficon-tech.com/home.htm
  -----------------------------------------------------------------
  --------------7FF480F0287766283511C212-- From owner-mpls@UU.NET Fri Mar 24 17:04:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17521 for ; Fri, 24 Mar 2000 17:04:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihym11612; Fri, 24 Mar 2000 22:04:46 GMT Received: by mail-control.mail.uu.net id QQihym17194 for mpls-outgoing; Fri, 24 Mar 2000 22:04:15 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQihym17179 for ; Fri, 24 Mar 2000 22:04:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihym18553 for ; Fri, 24 Mar 2000 17:04:00 -0500 (EST) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQihym22131 for ; Fri, 24 Mar 2000 22:04:00 GMT Received: from kbalalap by alpha.tellium.com (SMI-8.6/SMI-SVR4) id QAA10079; Fri, 24 Mar 2000 16:58:44 -0500 From: "Krishna Bala" To: "Jonathan Lang" , , "Jagan Shantigram" Cc: "Khaled Elsayed" , , Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Fri, 24 Mar 2000 17:04:12 -0500 Message-ID: <003701bf95dc$e362f400$425cc697@tempest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <51DA0AB3D747D311832F005004827CC013E299@LUX> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan, Point 1: Let me clarify the "open model". Open refers to the fact that this model supports the interconnection of several types of clients to an optical network (server layer). Examples of Clients: IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services" The open model also allows the interconnection of other Optical Network Elements to each other. Examples of other Network Elements: Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC, Wavelength Interchanging XC In general, since it offers the capability to support ALL services (not just IP) it is an Open Model. Point 2: Overlay Model vs. Open The connotation that goes typically with the Overlay model is that the optical layer is quasi static and might require N^2 connectivity at the IP/client layer. Hence, I prefer to distinguish the open model from overlay. Krishna Bala > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jonathan > Lang > Sent: Thursday, March 23, 2000 4:55 PM > To: 'Krishna Bala'; curtis@avici.com; Jagan Shantigram > Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com > Subject: RE: Comments on draft-ip-optical-framework-00.txt > > > Krishna, > The Open model seems quite "Closed" to me - the very nature of clouds > implies information hiding in my mind. What is exactly meant by open? > Also, I'm not sure I agree with your definition of overlay, as many people > allow the overlay model to encompass both your (2) and (3). > Furthermore, I > don't think the Peer Model implies OXCs are "agile but fat & > dumb" since as > they are "peers", this would also imply routers are "agile but fat & dumb" > as well - and at some point, someone needs to have intelligence. I would > suggest that the Peer model allows both routers and OXCs to interoperate > intelligently. > > Regards, > Jonathan > > -----Original Message----- > From: Krishna Bala [mailto:kbala@tellium.com] > Sent: Thursday, March 23, 2000 11:59 AM > To: curtis@avici.com; Jagan Shantigram > Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com > Subject: RE: Comments on draft-ip-optical-framework-00.txt > > > Jagan, > There are several architectural models for IP over Optical Networks that > are emerging: > > 1. Peer Model > In this model the IP router is entirely aware of the details on the > underlying > optical network (topology information, wavelength and port usage and lamda > assignment). > It is able to control and manage entire end to end paths. In this > model the > OXC is "agile but fat & dumb". > 2. Overlay Model > The optical layer is "fat & dumb". The lamda connections between the IP > routers behave as if they were dedicated fibers between them. The > IP routes > provision logical optical circuits over a fixed or at best a quasi-fixed > optical > layer. > 3. Open Model > In this scenario the optical layer comprises of several "vendor/network > operator clouds" > that have well defined interfaces. For example, an Optical UNI can be used > to > interconnect the IP router to the OXC and the Optical NNI can be used to > connect > two optical network domains together. Here the optical layer is > "fat, smart > and agile". > > It is unclear at this time which of these models will prevail. > > Krishna Bala > Tellium > > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis > > Villamizar > > Sent: Thursday, March 23, 2000 1:55 PM > > To: Jagan Shantigram > > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > > ip-optical@lists.research.bell-labs.com > > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > > > > > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > > Shantigram wr > > ites: > > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > > > > > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > > > >> > > > >> > > > >> Hello Jagan, > > > >> > > > >> > When we do not have lambda conversion however, this > problem cannot > > > >> > be solved optimally.. it is akin to the graph coloring > > > >> > problem - which ofcourse has heuristics that can get us to > > > >> > a factor (?) of the optimal solution. So, connections may > > > >> > be blocked even though there is capacity on the fiber to > > > >> > support it, just because the wavelength is already used up. > > > >> > > > > >> > > > >> Connections can be blocked when?? At service provisioning time or > > > >> at the time the connection is requested?? My point is a > > > >> connection of 2.48 Gbps is not likely to be a random event or an > > > >> ATM-like SVC. If a customer would require such huge bandwidth, it > > > >> would need that BW to go through or it would better look for > > > >> another carrier that will provide a TDM/leased line?? Of course > > > >> wavelength conversion can help build a better-utilized network, > > > >> no question about that. > > > >> > > > >> Khaled > > > > > > > > > > > >The exception to the rule that "a connection of 2.48 Gbps is not > > > >likely to be a random event" is where a very major event, possilble > > > >external to one's own network results in a shift in traffic patterns > > > >that is significant enough to require that additional > lambdas be added > > > >to existing paths. > > > > > > > >The real world example in the ISP world is a failure of a peering > > > >point of some sort, a provider interconnect, a NAP or NAP > connectivity > > > >of some party. Since all major ISPs are connected to each other at > > > >more than one geographically diverse peering point, the traffic will > > > >still flow, but the path will have changed. > > > > > > > >This may mean that a path that previously required 3 lambdas (for > > > >example), now requires 4 lambdas. There are at least 3 ways to > > > >accommodate this requirement: > > > > > > > > 1. An external management system adds a lambda to both the routers > > > > at either end and the optical switches (demonstrated at OFC). > > > > > > > > 2. The router signals the requirement/desire for an additional > > > > lambda to the adjacent optical switch which sets up a path. > > > > This is the overlay model. It can be trivially > implemented with > > > > MPLS by having the router send a loose source hop in the ERO > > > > allowing the switch to create the path or reject the request. > > > > > > Curtis, > > > > > > Am trying to understand the model here. Does the overlay model > > > as you put above imply that the optical devices need to be > mini-routers > > > in their own right? They have to be able to set up end-to-end optical > > > paths.. perhaps some kind of binding between the end-host IP address > > > and an addressing scheme for Optical devices.. ala ATM? > > > What does the overlay model entail? > > > > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or > > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > > > > Alternately, the lambdas can be set statically and the edge router > > simple advertises a Lambda-Switch Capable link ala > > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt > > accommodating the overlay model). > > > > I don't think draft-kompella-mpls-optical-00.txt has all the details > > sufficiently ironed out for the case where the optical switch > > advertises the availability of an optical link. If it does, then the > > details ar just not clear to me. (Could be my careless reading). > > > > > > 3. The router has enough information about the characteristics of > > > > the optical devices to compute the path and so it does > so. This > > > > is the peer model. > > > > > > > > > > What does this model need.. a protocol for exchanging information > > > between the router and the optical device? > > > > It needs a means to communicate OOB wrt the primary lightpath. That > > means would again be running the IGP and RSVP. Based on reading the > > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the > > optical switch exchanges this information OOB although I would imagine > > that it would be quite easy to maintian another interface (perhaps > > even an electrical, though gig-E would do fine) between the router and > > optical device in which the optical device advertises the optical > > links. The router on either end of an optical link, seeing or having > > set up a Packet-Switch Capable link would then have to bring up an > > RSVP adjacency over it, though I think it would not need an IGP > > adjacency. (I'm not clear on this last point.) > > > > The availability of certain types of links (Packet-Switch Capable, > > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm > > not clear on whether the adjacent LSR should advertise a Forwarding > > Adjacency PSC after RSVP comes up over a set of optical links (it > > seems to be the intent) but maybe the authors can clarify the usage. > > > > The ongoing discussion and the topic of the (way too numerous) > > framework documents floating around has been what additional > > information would be needed in order to provide adequate constraints > > to set up optical paths, a particularly difficult problem for > > transparent paths. > > > > > -jagan. > > > > > > >The way this might manifest itself is LSPs that might take an optical > > > >path from A to C are going from A to B to C because A to C > lambdas are > > > >too full. If so, then A could in principle request an additional > > > >lambda, but in practice the means to signal this has not > been defined. > > > > > > > >Curtis > > > > > > Jagannath Shantigram > > > Photonex Corporation > > > > btw- I exchanged some private email with one of the authors of > > draft-kompella-mpls-optical.txt and owe them some detailed comments > > (appologies to them for the delay, busy). After some brief discussion > > and after a second reading, the intent seems a lot more clear. The > > usage material is at the end so when reading the document from front > > to back the intent is not clear until the end and then a second > > reading is required. > > > > Curtis > > > From owner-mpls@UU.NET Fri Mar 24 20:04:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20810 for ; Fri, 24 Mar 2000 20:04:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQihyy06325; Sat, 25 Mar 2000 01:04:53 GMT Received: by mail-control.mail.uu.net id QQihyy28048 for mpls-outgoing; Sat, 25 Mar 2000 01:04:34 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQihyy28026 for ; Sat, 25 Mar 2000 01:04:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQihyy16118 for ; Fri, 24 Mar 2000 20:04:17 -0500 (EST) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQihyy05790 for ; Sat, 25 Mar 2000 01:04:17 GMT Received: from kbalalap by alpha.tellium.com (SMI-8.6/SMI-SVR4) id TAA14164; Fri, 24 Mar 2000 19:59:23 -0500 From: "Krishna Bala" To: "Yang Cao" Cc: , Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Fri, 24 Mar 2000 20:04:51 -0500 Message-ID: <006101bf95f6$1fd30600$425cc697@tempest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <38DA796F.B4F2C2AA@lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yang, The overlay model gives the impression that the optical layer is static (or quasi static at best). It also gives the impression that the IP layers needs to have N^2 connectivity in this case. Krishna > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yang Cao > Sent: Thursday, March 23, 2000 3:07 PM > To: Krishna Bala > Cc: mpls@UU.NET; ip-optical@lists.research.bell-labs.com > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > I try to clarify your definition, especially the difference between > your Overlay Model and Open Model. > > So in your definition, there is no O-UNI or O-NNI in the Overlay Model, > and in this Overlay Model, optical layer is only manual > provisioning based? > > Thanks, > Yang > > > Krishna Bala wrote: > > > > Jagan, > > There are several architectural models for IP over Optical Networks that > > are emerging: > > > > 1. Peer Model > > In this model the IP router is entirely aware of the details on the > > underlying > > optical network (topology information, wavelength and port > usage and lamda > > assignment). > > It is able to control and manage entire end to end paths. In > this model the > > OXC is "agile but fat & dumb". > > 2. Overlay Model > > The optical layer is "fat & dumb". The lamda connections between the IP > > routers behave as if they were dedicated fibers between them. > The IP routes > > provision logical optical circuits over a fixed or at best a quasi-fixed > > optical > > layer. > > 3. Open Model > > In this scenario the optical layer comprises of several "vendor/network > > operator clouds" > > that have well defined interfaces. For example, an Optical UNI > can be used > > to > > interconnect the IP router to the OXC and the Optical NNI can be used to > > connect > > two optical network domains together. Here the optical layer is > "fat, smart > > and agile". > > > > It is unclear at this time which of these models will prevail. > > > > Krishna Bala > > Tellium > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis > > > Villamizar > > > Sent: Thursday, March 23, 2000 1:55 PM > > > To: Jagan Shantigram > > > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > > > ip-optical@lists.research.bell-labs.com > > > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > > > > > > > > > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > > > Shantigram wr > > > ites: > > > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > > > > > > > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > > > > >> > > > > >> > > > > >> Hello Jagan, > > > > >> > > > > >> > When we do not have lambda conversion however, this > problem cannot > > > > >> > be solved optimally.. it is akin to the graph coloring > > > > >> > problem - which ofcourse has heuristics that can get us to > > > > >> > a factor (?) of the optimal solution. So, connections may > > > > >> > be blocked even though there is capacity on the fiber to > > > > >> > support it, just because the wavelength is already used up. > > > > >> > > > > > >> > > > > >> Connections can be blocked when?? At service provisioning time or > > > > >> at the time the connection is requested?? My point is a > > > > >> connection of 2.48 Gbps is not likely to be a random event or an > > > > >> ATM-like SVC. If a customer would require such huge bandwidth, it > > > > >> would need that BW to go through or it would better look for > > > > >> another carrier that will provide a TDM/leased line?? Of course > > > > >> wavelength conversion can help build a better-utilized network, > > > > >> no question about that. > > > > >> > > > > >> Khaled > > > > > > > > > > > > > > >The exception to the rule that "a connection of 2.48 Gbps is not > > > > >likely to be a random event" is where a very major event, possilble > > > > >external to one's own network results in a shift in > traffic patterns > > > > >that is significant enough to require that additional > lambdas be added > > > > >to existing paths. > > > > > > > > > >The real world example in the ISP world is a failure of a peering > > > > >point of some sort, a provider interconnect, a NAP or NAP > connectivity > > > > >of some party. Since all major ISPs are connected to each other at > > > > >more than one geographically diverse peering point, the > traffic will > > > > >still flow, but the path will have changed. > > > > > > > > > >This may mean that a path that previously required 3 lambdas (for > > > > >example), now requires 4 lambdas. There are at least 3 ways to > > > > >accommodate this requirement: > > > > > > > > > > 1. An external management system adds a lambda to both > the routers > > > > > at either end and the optical switches (demonstrated at OFC). > > > > > > > > > > 2. The router signals the requirement/desire for an additional > > > > > lambda to the adjacent optical switch which sets up a path. > > > > > This is the overlay model. It can be trivially > implemented with > > > > > MPLS by having the router send a loose source hop in the ERO > > > > > allowing the switch to create the path or reject the request. > > > > > > > > Curtis, > > > > > > > > Am trying to understand the model here. Does the overlay model > > > > as you put above imply that the optical devices need to be > mini-routers > > > > in their own right? They have to be able to set up > end-to-end optical > > > > paths.. perhaps some kind of binding between the end-host IP address > > > > and an addressing scheme for Optical devices.. ala ATM? > > > > What does the overlay model entail? > > > > > > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or > > > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > > > > > > Alternately, the lambdas can be set statically and the edge router > > > simple advertises a Lambda-Switch Capable link ala > > > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt > > > accommodating the overlay model). > > > > > > I don't think draft-kompella-mpls-optical-00.txt has all the details > > > sufficiently ironed out for the case where the optical switch > > > advertises the availability of an optical link. If it does, then the > > > details ar just not clear to me. (Could be my careless reading). > > > > > > > > 3. The router has enough information about the > characteristics of > > > > > the optical devices to compute the path and so it > does so. This > > > > > is the peer model. > > > > > > > > > > > > > What does this model need.. a protocol for exchanging information > > > > between the router and the optical device? > > > > > > It needs a means to communicate OOB wrt the primary lightpath. That > > > means would again be running the IGP and RSVP. Based on reading the > > > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the > > > optical switch exchanges this information OOB although I would imagine > > > that it would be quite easy to maintian another interface (perhaps > > > even an electrical, though gig-E would do fine) between the router and > > > optical device in which the optical device advertises the optical > > > links. The router on either end of an optical link, seeing or having > > > set up a Packet-Switch Capable link would then have to bring up an > > > RSVP adjacency over it, though I think it would not need an IGP > > > adjacency. (I'm not clear on this last point.) > > > > > > The availability of certain types of links (Packet-Switch Capable, > > > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > > > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm > > > not clear on whether the adjacent LSR should advertise a Forwarding > > > Adjacency PSC after RSVP comes up over a set of optical links (it > > > seems to be the intent) but maybe the authors can clarify the usage. > > > > > > The ongoing discussion and the topic of the (way too numerous) > > > framework documents floating around has been what additional > > > information would be needed in order to provide adequate constraints > > > to set up optical paths, a particularly difficult problem for > > > transparent paths. > > > > > > > -jagan. > > > > > > > > >The way this might manifest itself is LSPs that might take > an optical > > > > >path from A to C are going from A to B to C because A to C > lambdas are > > > > >too full. If so, then A could in principle request an additional > > > > >lambda, but in practice the means to signal this has not > been defined. > > > > > > > > > >Curtis > > > > > > > > Jagannath Shantigram > > > > Photonex Corporation > > > > > > btw- I exchanged some private email with one of the authors of > > > draft-kompella-mpls-optical.txt and owe them some detailed comments > > > (appologies to them for the delay, busy). After some brief discussion > > > and after a second reading, the intent seems a lot more clear. The > > > usage material is at the end so when reading the document from front > > > to back the intent is not clear until the end and then a second > > > reading is required. > > > > > > Curtis > > > > From owner-mpls@UU.NET Sat Mar 25 16:49:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24318 for ; Sat, 25 Mar 2000 16:49:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiicd21687; Sat, 25 Mar 2000 21:49:24 GMT Received: by mail-control.mail.uu.net id QQiicd02840 for mpls-outgoing; Sat, 25 Mar 2000 21:49:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiicd02835 for ; Sat, 25 Mar 2000 21:49:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiicd24090 for ; Sat, 25 Mar 2000 16:48:51 -0500 (EST) Received: from mail.rdc1.sfba.home.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ha1.rdc1.sfba.home.com [24.0.0.66]) id QQiicd21319 for ; Sat, 25 Mar 2000 21:48:51 GMT Received: from home.net ([24.5.203.21]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000325214850.NAEK25042.mail.rdc1.sfba.home.com@home.net>; Sat, 25 Mar 2000 13:48:50 -0800 Message-ID: <38DD3442.A949437@home.net> Date: Sat, 25 Mar 2000 13:48:50 -0800 From: Tony Li Organization: Li Consulting X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Krishna Bala CC: Jonathan Lang , curtis@avici.com, Jagan Shantigram , Khaled Elsayed , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <003701bf95dc$e362f400$425cc697@tempest> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Open refers to the fact that this model supports the interconnection of > several types of clients to an optical network (server layer). > Examples of Clients: > IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services" > > The open model also allows the interconnection of other Optical Network > Elements to each other. > Examples of other Network Elements: > Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC, Wavelength > Interchanging XC > > In general, since it offers the capability to support ALL services (not just > IP) it is an Open Model. The distinction that you make between the Open Model and the Peer Model is not clear to me. Certainly both models will support all services. Both models should be using IP as the basis of their routing and signalling protocols. What is the substantive basis for a difference? Tony From owner-mpls@UU.NET Sun Mar 26 23:32:00 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18919 for ; Sun, 26 Mar 2000 23:31:58 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiigw19292; Mon, 27 Mar 2000 04:31:49 GMT Received: by mail-control.mail.uu.net id QQiigw00895 for mpls-outgoing; Mon, 27 Mar 2000 04:31:33 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiigw00890 for ; Mon, 27 Mar 2000 04:31:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiigw08117 for ; Sun, 26 Mar 2000 23:30:33 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQiigv03629 for ; Mon, 27 Mar 2000 04:29:59 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id JAA01822 for ; Mon, 27 Mar 2000 09:56:09 -0600 (GMT) Message-ID: <009e01bf97a5$c12b4660$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Subject: QoS in CR-LDP across various domains Date: Mon, 27 Mar 2000 10:04:33 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01BF97D3.D96A9E00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_009B_01BF97D3.D96A9E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am working on CR-LDP at present and have the following doubt. To = gurantee QoS to customer the LER in "domain A" should be able to = negotiate the expected traffic parameters from it's neighbouring "domain = b" which could be MPLS or non MPLS. If "domain B" is non MPLS then how = does "domain A" go on to negotiate parameters with the peer router in = the neighbouring domain as in the case of Integrated Services in RSVP. = The SLA between the two is supposed to determine the maximum limit for = the services but how is the actual usage determined by "domain B" LER. = The scenario is depicted below: neighboring domain B (non MPLS) | My Domain A = (MPLS) | = =20 Router | LER=20 | The data is supposed to flow from domain B to domain A. santosh santoshgupta@poboxes.com ------=_NextPart_000_009B_01BF97D3.D96A9E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi
    I am working on CR-LDP at present and have the = following=20 doubt. To gurantee QoS to customer the LER in "domain A" should be able = to=20 negotiate the expected traffic parameters from it's neighbouring "domain = b"=20 which could be MPLS or non MPLS. If "domain B" is non MPLS then how = does "domain A" go on to negotiate parameters with = the peer=20 router in the neighbouring domain as in the case of Integrated = Services in=20 RSVP. The SLA between the two is supposed to determine the maximum limit = for the=20 services but how is the actual usage determined by "domain B" LER. The = scenario=20 is depicted below:
 
 
       =20 neighboring domain B (non MPLS)  =     =20 |            My Domain A=20 (MPLS)
            =    =20             =    =20             =    =20             =20     |       
           &n= bsp;           &nb= sp;           &nbs= p;           =20    Router    |    = LER=20
            =    =20             =    =20             =    =20             =20     |
 
The data is supposed to flow from domain B to domain A.
 
santosh
 
santoshgupta@poboxes.com ------=_NextPart_000_009B_01BF97D3.D96A9E00-- From owner-mpls@UU.NET Mon Mar 27 07:02:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26054 for ; Mon, 27 Mar 2000 07:02:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiia08710; Mon, 27 Mar 2000 12:02:20 GMT Received: by mail-control.mail.uu.net id QQiiia17895 for mpls-outgoing; Mon, 27 Mar 2000 12:01:36 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiiia17783 for ; Mon, 27 Mar 2000 12:01:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiia15155 for ; Mon, 27 Mar 2000 07:01:11 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQiiia22115 for ; Mon, 27 Mar 2000 12:00:55 GMT Received: from testras ([165.133.13.22]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id RAA09838 for ; Mon, 27 Mar 2000 17:27:26 -0600 (GMT) Message-ID: <002201bf97e3$bbc3b980$160d85a5@dti.daewoo.co.kr> From: "ashish" To: Subject: CR-LDP Date: Mon, 27 Mar 2000 17:28:12 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01BF9811.D4088F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001F_01BF9811.D4088F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In CR-LDP draft-03, one of the ER-HOP TLV types contain LSPID field that = is used for tunneling thru some existing LSP having that LSPID field. This means that that LSPID should be known in advance . How is that done. Does information regarding each LSP being created each having unique = LSPID is propagated to all LSR's. Please clarify. ------=_NextPart_000_001F_01BF9811.D4088F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In CR-LDP draft-03, one of the ER-HOP = TLV types=20 contain LSPID field that is used for tunneling thru some existing LSP = having=20 that LSPID field.
This means that that LSPID should be = known in=20 advance .
How is that done.
Does information regarding each LSP = being created=20 each having unique LSPID is propagated to all LSR's.
Please = clarify.
------=_NextPart_000_001F_01BF9811.D4088F60-- From owner-mpls@UU.NET Mon Mar 27 09:26:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26515 for ; Mon, 27 Mar 2000 09:26:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiij16817; Mon, 27 Mar 2000 14:26:29 GMT Received: by mail-control.mail.uu.net id QQiiij19163 for mpls-outgoing; Mon, 27 Mar 2000 14:26:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiij19137 for ; Mon, 27 Mar 2000 14:25:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiij18922 for ; Mon, 27 Mar 2000 09:25:20 -0500 (EST) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiiij01249 for ; Mon, 27 Mar 2000 14:25:17 GMT Received: from chaudhurilap by alpha.tellium.com (SMI-8.6/SMI-SVR4) id JAA15243; Mon, 27 Mar 2000 09:18:58 -0500 From: "Sid Chaudhuri" To: "Tony Li" , "Krishna Bala" Cc: "Jonathan Lang" , , "Jagan Shantigram" , "Khaled Elsayed" , , , "mpls@UU. NET" Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Mon, 27 Mar 2000 09:24:42 -0500 Message-ID: <000601bf97f8$313a4850$1761c697@tellium.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <38DD3442.A949437@home.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit You may be right that both models can support all services provided signaling and routing are IP-based. However, there are two fundamental differences between the Open and the Peer model: (1) In OPen model if an operator wants to offer "optical Pipe" services regardless what svc is carried within the pipes the operator would not like to share all its network resource information to its clients. Therefore what is needed for information exchange between the client NE and the optical network is a standard interface defining the minimum set of required parameters without sharing optical netrwork resource info with the clinet NE. That is what UNI spec being developed by OIF. (2)We do not need to impose the routing and signaling protocols to every client network elements for providing the optical layer services. Al they need to adhere to is the simplie UNI spec. Rest is done by the optical layer using IP signaling and routing. The driver for using IP routing and signaling in the optical layer is simply because these are well developed and well suited for the optical layer functions and there is no need to reinvent the wheel. Also, when multi-vendor optical networks are to work together other protocols such as BGP can be easily adopted. S0 unless we assume that all services to be provided by an optical network (inclcuing pipe svc) are accessed via routers that are within the opretor's domain the peer model by itself is unworkable and once we have the open model the need for peer model is diminshed to almost naught. Sid > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Tony Li > Sent: Saturday, March 25, 2000 4:49 PM > To: Krishna Bala > Cc: Jonathan Lang; curtis@avici.com; Jagan Shantigram; Khaled Elsayed; > mpls@UU.NET; ip-optical@lists.research.bell-labs.com > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > Open refers to the fact that this model supports the interconnection of > > several types of clients to an optical network (server layer). > > Examples of Clients: > > IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services" > > > > The open model also allows the interconnection of other Optical Network > > Elements to each other. > > Examples of other Network Elements: > > Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC, Wavelength > > Interchanging XC > > > > In general, since it offers the capability to support ALL > services (not just > > IP) it is an Open Model. > > The distinction that you make between the Open Model and the Peer > Model is not > clear to me. > > Certainly both models will support all services. Both models > should be using IP > as the basis of their routing and signalling protocols. > > What is the substantive basis for a difference? > > Tony > > From owner-mpls@UU.NET Mon Mar 27 09:40:36 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02724 for ; Mon, 27 Mar 2000 09:40:35 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiik10991; Mon, 27 Mar 2000 14:40:33 GMT Received: by mail-control.mail.uu.net id QQiiik19682 for mpls-outgoing; Mon, 27 Mar 2000 14:39:59 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiik19677 for ; Mon, 27 Mar 2000 14:39:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiik21351 for ; Mon, 27 Mar 2000 09:39:21 -0500 (EST) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQiiik10079 for ; Mon, 27 Mar 2000 14:39:20 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA21068 for ; Mon, 27 Mar 2000 06:39:19 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA03136 for mpls@uu.net; Mon, 27 Mar 2000 09:39:18 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiihh02032 for ; Mon, 27 Mar 2000 07:25:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiihh22373 for ; Mon, 27 Mar 2000 02:25:07 -0500 (EST) Received: from sasi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sasi.com [164.164.56.2]) id QQiihh17802 for ; Mon, 27 Mar 2000 07:25:04 GMT Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id MAA25411 for ; Mon, 27 Mar 2000 12:56:30 +0530 (IST) Received: from hpd11.sasi.com ([10.0.16.11]) by sasi.com; Mon, 27 Mar 2000 12:56:28 +0000 (IST) Received: from localhost (ramp@localhost) by hpd11.sasi.com (8.9.1/8.9.1) with ESMTP id NAA02078 for ; Mon, 27 Mar 2000 13:01:52 +0530 (IST) Date: Mon, 27 Mar 2000 13:01:52 +0530 (IST) From: R G Ramprasad Torati To: mpls@UU.NET Subject: Regarding MPLS simulation....! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I heard that some simulation part is available for MPLS combined with OSPF/ISIS floods. Can anybody please tell where can I get it. If U have a one, please send it to me. And I want to know is there any MPLS simulation results available. If any of U have these, please let me know. Thanks in advance Ramp From owner-mpls@UU.NET Mon Mar 27 10:14:34 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16986 for ; Mon, 27 Mar 2000 10:14:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiim04176; Mon, 27 Mar 2000 15:14:32 GMT Received: by mail-control.mail.uu.net id QQiiim29645 for mpls-outgoing; Mon, 27 Mar 2000 15:14:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiiim29593 for ; Mon, 27 Mar 2000 15:13:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiim13341 for ; Mon, 27 Mar 2000 10:13:30 -0500 (EST) Received: from bgslc02.TBG.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.104.68.2]) id QQiiim18204 for ; Mon, 27 Mar 2000 15:13:29 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2448.0) id ; Mon, 27 Mar 2000 08:12:08 -0700 Message-ID: <0C875DC28791D21192CD00104B95BFE76F610F@BGSLC02> From: Irwin Lazar To: "'R G Ramprasad Torati'" , mpls@UU.NET Cc: "'mpls-ops@mplsrc.com'" Subject: RE: Regarding MPLS simulation....! Date: Mon, 27 Mar 2000 08:12:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk We just added a link to Wandl's "Network Analysis and Planning Tools" to the MPLS Resource Center (www.mplsrc.com). You might want to see if this package meets your needs. http://www.wandl.com/npat/intro.html Irwin > -----Original Message----- > From: R G Ramprasad Torati [mailto:ramp@sasi.com] > Sent: Monday, March 27, 2000 2:32 AM > To: mpls@UU.NET > Subject: Regarding MPLS simulation....! > > > Hi, > > > I heard that some simulation part is available for MPLS combined with > OSPF/ISIS floods. Can anybody please tell where can I get it. > If U have > a one, please send it to me. > > And I want to know is there any MPLS simulation results > available. If any > of U have these, please let me know. > > Thanks in advance > Ramp > > > From owner-mpls@UU.NET Mon Mar 27 10:14:36 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17008 for ; Mon, 27 Mar 2000 10:14:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiim18993; Mon, 27 Mar 2000 15:14:34 GMT Received: by mail-control.mail.uu.net id QQiiim29665 for mpls-outgoing; Mon, 27 Mar 2000 15:14:04 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiiim29639 for ; Mon, 27 Mar 2000 15:13:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiim12798 for ; Mon, 27 Mar 2000 10:10:56 -0500 (EST) Received: from mail16.vwh1.net by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [209.238.9.59]) id QQiiim01562 for ; Mon, 27 Mar 2000 15:10:56 GMT Received: from 208.55.74.250 (208.55.74.250) by mail16.vwh1.net (RS ver 1.0.53) with SMTP id 015913566; Mon, 27 Mar 2000 10:10:08 -0500 (EST) Message-Id: <3.0.6.32.20000327101337.00b2d100@photonex.com> X-Sender: jagan@photonex.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 27 Mar 2000 10:13:37 -0500 To: "Krishna Bala" , "Jonathan Lang" , From: Jagan Shantigram Subject: RE: Comments on draft-ip-optical-framework-00.txt Cc: "Khaled Elsayed" , , In-Reply-To: <003701bf95dc$e362f400$425cc697@tempest> References: <51DA0AB3D747D311832F005004827CC013E299@LUX> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop-Detect: 1 Sender: owner-mpls@UU.NET Precedence: bulk At 05:04 PM 3/24/00 -0500, Krishna Bala wrote: >Jonathan, >Point 1: Let me clarify the "open model". > >Open refers to the fact that this model supports the interconnection of >several types of clients to an optical network (server layer). >Examples of Clients: >IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services" > >The open model also allows the interconnection of other Optical Network >Elements to >each other. >Examples of other Network Elements: >Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC, Wavelength >Interchanging XC > >In general, since it offers the capability to support ALL services (not just >IP) >it is an Open Model. Krishna, It seems like the above just described what people understand by the overlay model. In this model the optical layer presents itself as a layer that can provide a bunch of services to the upper data/IP layer. These services could include point to point clear channel, 1+1 protection, negotiable bandwidth etc.. (just to give examples). How the optical layer achieves these services is yet to be determined - which as you mention will require standardized interfaces between the various optical components and as well as a standardized API for these services to be requested. My question is what are these services that would be useful for the optical layer to provide and what are the tasks that have to be taken up to enable it? In any case it seems risky to take up a model that requires too much cooperation between the various layers - since that will mean that there will be inter-dependence in the development of that technology. Ofcourse there are others who have more experience on questions like this. > >Point 2: Overlay Model vs. Open > >The connotation that goes typically with the Overlay model is that the >optical >layer is quasi static and might require N^2 connectivity at the IP/client >layer. Am afraid I missed the point here. thanks, -jagan. >Hence, I prefer to distinguish the open model from overlay. >Krishna Bala > >> -----Original Message----- >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jonathan >> Lang >> Sent: Thursday, March 23, 2000 4:55 PM >> To: 'Krishna Bala'; curtis@avici.com; Jagan Shantigram >> Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com >> Subject: RE: Comments on draft-ip-optical-framework-00.txt >> >> >> Krishna, >> The Open model seems quite "Closed" to me - the very nature of clouds >> implies information hiding in my mind. What is exactly meant by open? >> Also, I'm not sure I agree with your definition of overlay, as many people >> allow the overlay model to encompass both your (2) and (3). >> Furthermore, I >> don't think the Peer Model implies OXCs are "agile but fat & >> dumb" since as >> they are "peers", this would also imply routers are "agile but fat & dumb" >> as well - and at some point, someone needs to have intelligence. I would >> suggest that the Peer model allows both routers and OXCs to interoperate >> intelligently. >> >> Regards, >> Jonathan >> >> -----Original Message----- >> From: Krishna Bala [mailto:kbala@tellium.com] >> Sent: Thursday, March 23, 2000 11:59 AM >> To: curtis@avici.com; Jagan Shantigram >> Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com >> Subject: RE: Comments on draft-ip-optical-framework-00.txt >> >> >> Jagan, >> There are several architectural models for IP over Optical Networks that >> are emerging: >> >> 1. Peer Model >> In this model the IP router is entirely aware of the details on the >> underlying >> optical network (topology information, wavelength and port usage and lamda >> assignment). >> It is able to control and manage entire end to end paths. In this >> model the >> OXC is "agile but fat & dumb". >> 2. Overlay Model >> The optical layer is "fat & dumb". The lamda connections between the IP >> routers behave as if they were dedicated fibers between them. The >> IP routes >> provision logical optical circuits over a fixed or at best a quasi-fixed >> optical >> layer. >> 3. Open Model >> In this scenario the optical layer comprises of several "vendor/network >> operator clouds" >> that have well defined interfaces. For example, an Optical UNI can be used >> to >> interconnect the IP router to the OXC and the Optical NNI can be used to >> connect >> two optical network domains together. Here the optical layer is >> "fat, smart >> and agile". >> >> It is unclear at this time which of these models will prevail. >> >> Krishna Bala >> Tellium >> >> >> >> > -----Original Message----- >> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis >> > Villamizar >> > Sent: Thursday, March 23, 2000 1:55 PM >> > To: Jagan Shantigram >> > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; >> > ip-optical@lists.research.bell-labs.com >> > Subject: Re: Comments on draft-ip-optical-framework-00.txt >> > >> > >> > >> > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan >> > Shantigram wr >> > ites: >> > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: >> > > > >> > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: >> > > >> >> > > >> >> > > >> Hello Jagan, >> > > >> >> > > >> > When we do not have lambda conversion however, this >> problem cannot >> > > >> > be solved optimally.. it is akin to the graph coloring >> > > >> > problem - which ofcourse has heuristics that can get us to >> > > >> > a factor (?) of the optimal solution. So, connections may >> > > >> > be blocked even though there is capacity on the fiber to >> > > >> > support it, just because the wavelength is already used up. >> > > >> > >> > > >> >> > > >> Connections can be blocked when?? At service provisioning time or >> > > >> at the time the connection is requested?? My point is a >> > > >> connection of 2.48 Gbps is not likely to be a random event or an >> > > >> ATM-like SVC. If a customer would require such huge bandwidth, it >> > > >> would need that BW to go through or it would better look for >> > > >> another carrier that will provide a TDM/leased line?? Of course >> > > >> wavelength conversion can help build a better-utilized network, >> > > >> no question about that. >> > > >> >> > > >> Khaled >> > > > >> > > > >> > > >The exception to the rule that "a connection of 2.48 Gbps is not >> > > >likely to be a random event" is where a very major event, possilble >> > > >external to one's own network results in a shift in traffic patterns >> > > >that is significant enough to require that additional >> lambdas be added >> > > >to existing paths. >> > > > >> > > >The real world example in the ISP world is a failure of a peering >> > > >point of some sort, a provider interconnect, a NAP or NAP >> connectivity >> > > >of some party. Since all major ISPs are connected to each other at >> > > >more than one geographically diverse peering point, the traffic will >> > > >still flow, but the path will have changed. >> > > > >> > > >This may mean that a path that previously required 3 lambdas (for >> > > >example), now requires 4 lambdas. There are at least 3 ways to >> > > >accommodate this requirement: >> > > > >> > > > 1. An external management system adds a lambda to both the routers >> > > > at either end and the optical switches (demonstrated at OFC). >> > > > >> > > > 2. The router signals the requirement/desire for an additional >> > > > lambda to the adjacent optical switch which sets up a path. >> > > > This is the overlay model. It can be trivially >> implemented with >> > > > MPLS by having the router send a loose source hop in the ERO >> > > > allowing the switch to create the path or reject the request. >> > > >> > > Curtis, >> > > >> > > Am trying to understand the model here. Does the overlay model >> > > as you put above imply that the optical devices need to be >> mini-routers >> > > in their own right? They have to be able to set up end-to-end optical >> > > paths.. perhaps some kind of binding between the end-host IP address >> > > and an addressing scheme for Optical devices.. ala ATM? >> > > What does the overlay model entail? >> > >> > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or >> > CRLDP) in a manner similar to the ATM UNI setting up an SVC. >> > >> > Alternately, the lambdas can be set statically and the edge router >> > simple advertises a Lambda-Switch Capable link ala >> > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt >> > accommodating the overlay model). >> > >> > I don't think draft-kompella-mpls-optical-00.txt has all the details >> > sufficiently ironed out for the case where the optical switch >> > advertises the availability of an optical link. If it does, then the >> > details ar just not clear to me. (Could be my careless reading). >> > >> > > > 3. The router has enough information about the characteristics of >> > > > the optical devices to compute the path and so it does >> so. This >> > > > is the peer model. >> > > > >> > > >> > > What does this model need.. a protocol for exchanging information >> > > between the router and the optical device? >> > >> > It needs a means to communicate OOB wrt the primary lightpath. That >> > means would again be running the IGP and RSVP. Based on reading the >> > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the >> > optical switch exchanges this information OOB although I would imagine >> > that it would be quite easy to maintian another interface (perhaps >> > even an electrical, though gig-E would do fine) between the router and >> > optical device in which the optical device advertises the optical >> > links. The router on either end of an optical link, seeing or having >> > set up a Packet-Switch Capable link would then have to bring up an >> > RSVP adjacency over it, though I think it would not need an IGP >> > adjacency. (I'm not clear on this last point.) >> > >> > The availability of certain types of links (Packet-Switch Capable, >> > Lambda-Switch Capable, Fiber-Switch Capable) as defined in >> > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm >> > not clear on whether the adjacent LSR should advertise a Forwarding >> > Adjacency PSC after RSVP comes up over a set of optical links (it >> > seems to be the intent) but maybe the authors can clarify the usage. >> > >> > The ongoing discussion and the topic of the (way too numerous) >> > framework documents floating around has been what additional >> > information would be needed in order to provide adequate constraints >> > to set up optical paths, a particularly difficult problem for >> > transparent paths. >> > >> > > -jagan. >> > > >> > > >The way this might manifest itself is LSPs that might take an optical >> > > >path from A to C are going from A to B to C because A to C >> lambdas are >> > > >too full. If so, then A could in principle request an additional >> > > >lambda, but in practice the means to signal this has not >> been defined. >> > > > >> > > >Curtis >> > > >> > > Jagannath Shantigram >> > > Photonex Corporation >> > >> > btw- I exchanged some private email with one of the authors of >> > draft-kompella-mpls-optical.txt and owe them some detailed comments >> > (appologies to them for the delay, busy). After some brief discussion >> > and after a second reading, the intent seems a lot more clear. The >> > usage material is at the end so when reading the document from front >> > to back the intent is not clear until the end and then a second >> > reading is required. >> > >> > Curtis >> > >> > > > > Jagannath Shantigram Photonex Corporation From owner-mpls@UU.NET Mon Mar 27 10:39:25 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20834 for ; Mon, 27 Mar 2000 10:39:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiio20921; Mon, 27 Mar 2000 15:39:26 GMT Received: by mail-control.mail.uu.net id QQiiio00987 for mpls-outgoing; Mon, 27 Mar 2000 15:38:54 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiio00979 for ; Mon, 27 Mar 2000 15:38:36 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiio02184 for ; Mon, 27 Mar 2000 10:33:54 -0500 (EST) Received: from miranda.tx.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: miranda.tx.fnc.fujitsu.com [167.254.254.199]) id QQiiio02334 for ; Mon, 27 Mar 2000 15:33:54 GMT Received: from tdd144115.tx.fnc.fujitsu.com (tdd144115.tddeng00.fnts.com [167.254.144.115]) by miranda.tx.fnc.fujitsu.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07168; Mon, 27 Mar 2000 09:33:06 -0600 (CST) Received: from fnc.fujitsu.com (localhost [127.0.0.1]) by tdd144115.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id JAA14372; Mon, 27 Mar 2000 09:33:06 -0600 (CST) Message-ID: <38DF7F31.6AD08B16@fnc.fujitsu.com> Date: Mon, 27 Mar 2000 09:33:06 -0600 From: Bharathi Devi Organization: Fujitsu Network Communications X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Irwin Lazar CC: "'R G Ramprasad Torati'" , mpls@UU.NET, "'mpls-ops@mplsrc.com'" Subject: Re: Regarding MPLS simulation....! References: <0C875DC28791D21192CD00104B95BFE76F610F@BGSLC02> Content-Type: multipart/mixed; boundary="------------CAF4EA524AB9B0E094DF9C76" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------CAF4EA524AB9B0E094DF9C76 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: My understanding of Wandl's simulation tool is that it can do static modeling rather than discrete event simulation. Sometime back, I had a talk with a representative from that company. He told me that their tool is mainly for network design and capacity planning. The failure scenario would tell about the capacity required in the network, not like what a discrete event simulator like BONes or OPNET would tell about packets lost, routing table convergence delay , etc. I am not sure whetherNS, the Network Simulator developed by UCB/LBNL/VINT Project, has MPLS capability. Regards, Bharathi Irwin Lazar wrote: > We just added a link to Wandl's "Network Analysis and Planning Tools" to the > MPLS Resource Center (www.mplsrc.com). You might want to see if this > package meets your needs. > > http://www.wandl.com/npat/intro.html > > Irwin > > > -----Original Message----- > > From: R G Ramprasad Torati [mailto:ramp@sasi.com] > > Sent: Monday, March 27, 2000 2:32 AM > > To: mpls@UU.NET > > Subject: Regarding MPLS simulation....! > > > > > > Hi, > > > > > > I heard that some simulation part is available for MPLS combined with > > OSPF/ISIS floods. Can anybody please tell where can I get it. > > If U have > > a one, please send it to me. > > > > And I want to know is there any MPLS simulation results > > available. If any > > of U have these, please let me know. > > > > Thanks in advance > > Ramp > > > > > > --------------CAF4EA524AB9B0E094DF9C76 Content-Type: text/x-vcard; charset=us-ascii; name="Bharathi.Devi.vcf" Content-Description: Card for Bharathi Devi Content-Disposition: attachment; filename="Bharathi.Devi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Devi;Bharathi tel;fax:972 479-7732 tel;work:972 479-4695 x-mozilla-html:FALSE org:Fujitsu Network Communications;System Engineering version:2.1 email;internet:Bharathi.Devi@fnc.fujitsu.com title:System Engineer adr;quoted-printable:;;2801 Telecom Parkway=0D=0A=0D=0A;Richardson;Texas ;75082;USA x-mozilla-cpt:;0 fn:Bharathi Devi end:vcard --------------CAF4EA524AB9B0E094DF9C76-- From owner-mpls@UU.NET Mon Mar 27 11:17:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21169 for ; Mon, 27 Mar 2000 11:17:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiir16147; Mon, 27 Mar 2000 16:17:11 GMT Received: by mail-control.mail.uu.net id QQiiir11202 for mpls-outgoing; Mon, 27 Mar 2000 16:16:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiir11197 for ; Mon, 27 Mar 2000 16:16:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiiq06853 for ; Mon, 27 Mar 2000 11:01:42 -0500 (EST) Received: from alpha.dtix.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.dtix.com [198.62.174.1]) id QQiiiq20046 for ; Mon, 27 Mar 2000 16:01:41 GMT Received: from salmon (beta.dtix.com [198.62.174.3]) by alpha.dtix.com (8.9.3/8.8.7) with SMTP id LAA07616; Mon, 27 Mar 2000 11:12:06 -0500 Message-ID: <001901bf9806$4851cf50$9dae3ec6@salmon> From: "Subodh Mathur" To: "ashish" , References: <002201bf97e3$bbc3b980$160d85a5@dti.daewoo.co.kr> Subject: Re: CR-LDP Date: Mon, 27 Mar 2000 11:05:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01BF97DC.5E503FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01BF97DC.5E503FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Only CR-LSP Ingress and participating LSRs will know about the LSP ID = and can use this information for efficient local repair in loose segment of CR-LSP.=20 Hope this will help. Subodh Digital Technology Inc. ----- Original Message -----=20 From: ashish=20 To: mpls@UU.NET=20 Sent: Monday, March 27, 2000 6:58 AM Subject: CR-LDP In CR-LDP draft-03, one of the ER-HOP TLV types contain LSPID field = that is used for tunneling thru some existing LSP having that LSPID = field. This means that that LSPID should be known in advance . How is that done. Does information regarding each LSP being created each having unique = LSPID is propagated to all LSR's. Please clarify. ------=_NextPart_000_0016_01BF97DC.5E503FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Only CR-LSP Ingress and participating = LSRs will=20 know about the LSP ID and can use this
information for efficient local repair = in loose=20 segment of CR-LSP.
Hope this will help.
Subodh
Digital Technology Inc.
----- Original Message -----
From:=20 ashish
Sent: Monday, March 27, 2000 = 6:58=20 AM
Subject: CR-LDP

In CR-LDP draft-03, one of the ER-HOP = TLV types=20 contain LSPID field that is used for tunneling thru some existing LSP = having=20 that LSPID field.
This means that that LSPID should be = known in=20 advance .
How is that done.
Does information regarding each LSP = being created=20 each having unique LSPID is propagated to all LSR's.
Please=20 clarify.
------=_NextPart_000_0016_01BF97DC.5E503FA0-- From owner-mpls@UU.NET Mon Mar 27 18:25:23 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26965 for ; Mon, 27 Mar 2000 18:25:22 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiijt05412; Mon, 27 Mar 2000 23:25:22 GMT Received: by mail-control.mail.uu.net id QQiijt07414 for mpls-outgoing; Mon, 27 Mar 2000 23:25:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiijt07408 for ; Mon, 27 Mar 2000 23:25:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiijt29078 for ; Mon, 27 Mar 2000 18:24:43 -0500 (EST) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiijt04913 for ; Mon, 27 Mar 2000 23:24:43 GMT Received: from kbalalap by alpha.tellium.com (SMI-8.6/SMI-SVR4) id SAA09112; Mon, 27 Mar 2000 18:18:25 -0500 From: "Krishna Bala" To: "Jagan Shantigram" , "Jonathan Lang" , Cc: "Khaled Elsayed" , , Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Mon, 27 Mar 2000 18:24:01 -0500 Message-ID: <00f801bf9843$888c2560$425cc697@tempest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <3.0.6.32.20000327101337.00b2d100@photonex.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jagan, Just to beat a dead horse .. the difference between the open model and the overlay is just that the overlay model typically suggests that there would be N^2 connectivity (i.e., every router, for instance, is statically connected to every other). In any case, the open model allows for fully dynamic operation. The overlay model suggests static operation of the optical layer. As I see it there are only two architectures that are worth considering: 1. Peer 2. Open I agree with you that there is no need to add the "overlay" model to this list. The open model covers the static and the dynamic cases. Krishna > -----Original Message----- > From: Jagan Shantigram [mailto:jagan@photonex.com] > Sent: Monday, March 27, 2000 10:14 AM > To: Krishna Bala; Jonathan Lang; curtis@avici.com > Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com > Subject: RE: Comments on draft-ip-optical-framework-00.txt > > > At 05:04 PM 3/24/00 -0500, Krishna Bala wrote: > >Jonathan, > >Point 1: Let me clarify the "open model". > > > >Open refers to the fact that this model supports the interconnection of > >several types of clients to an optical network (server layer). > >Examples of Clients: > >IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services" > > > >The open model also allows the interconnection of other Optical Network > >Elements to > >each other. > >Examples of other Network Elements: > >Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC, Wavelength > >Interchanging XC > > > >In general, since it offers the capability to support ALL > services (not just > >IP) > >it is an Open Model. > > Krishna, > > It seems like the above just described what people understand > by the overlay model. In this model the optical layer presents > itself as a layer that can provide a bunch of services to the > upper data/IP layer. These services could include point > to point clear channel, 1+1 protection, negotiable bandwidth > etc.. (just to give examples). How the optical layer > achieves these services is yet to be determined - which as you > mention will require standardized interfaces between the various > optical components and as well as a standardized API for these > services to be requested. > > My question is what are these services that would be useful > for the optical layer to provide and what are the tasks that > have to be taken up to enable it? > > In any case it seems risky to take up a model that requires > too much cooperation between the various layers - since that > will mean that there will be inter-dependence in the development > of that technology. Ofcourse there are others who have more > experience on questions like this. > > > > > >Point 2: Overlay Model vs. Open > > > >The connotation that goes typically with the Overlay model is that the > >optical > >layer is quasi static and might require N^2 connectivity at the IP/client > >layer. > > Am afraid I missed the point here. > > thanks, > -jagan. > > > >Hence, I prefer to distinguish the open model from overlay. > >Krishna Bala > > > >> -----Original Message----- > >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jonathan > >> Lang > >> Sent: Thursday, March 23, 2000 4:55 PM > >> To: 'Krishna Bala'; curtis@avici.com; Jagan Shantigram > >> Cc: Khaled Elsayed; mpls@UU.NET; > ip-optical@lists.research.bell-labs.com > >> Subject: RE: Comments on draft-ip-optical-framework-00.txt > >> > >> > >> Krishna, > >> The Open model seems quite "Closed" to me - the very nature of clouds > >> implies information hiding in my mind. What is exactly meant by open? > >> Also, I'm not sure I agree with your definition of overlay, as > many people > >> allow the overlay model to encompass both your (2) and (3). > >> Furthermore, I > >> don't think the Peer Model implies OXCs are "agile but fat & > >> dumb" since as > >> they are "peers", this would also imply routers are "agile but > fat & dumb" > >> as well - and at some point, someone needs to have > intelligence. I would > >> suggest that the Peer model allows both routers and OXCs to > interoperate > >> intelligently. > >> > >> Regards, > >> Jonathan > >> > >> -----Original Message----- > >> From: Krishna Bala [mailto:kbala@tellium.com] > >> Sent: Thursday, March 23, 2000 11:59 AM > >> To: curtis@avici.com; Jagan Shantigram > >> Cc: Khaled Elsayed; mpls@UU.NET; > ip-optical@lists.research.bell-labs.com > >> Subject: RE: Comments on draft-ip-optical-framework-00.txt > >> > >> > >> Jagan, > >> There are several architectural models for IP over Optical > Networks that > >> are emerging: > >> > >> 1. Peer Model > >> In this model the IP router is entirely aware of the details on the > >> underlying > >> optical network (topology information, wavelength and port > usage and lamda > >> assignment). > >> It is able to control and manage entire end to end paths. In this > >> model the > >> OXC is "agile but fat & dumb". > >> 2. Overlay Model > >> The optical layer is "fat & dumb". The lamda connections between the IP > >> routers behave as if they were dedicated fibers between them. The > >> IP routes > >> provision logical optical circuits over a fixed or at best a > quasi-fixed > >> optical > >> layer. > >> 3. Open Model > >> In this scenario the optical layer comprises of several "vendor/network > >> operator clouds" > >> that have well defined interfaces. For example, an Optical UNI > can be used > >> to > >> interconnect the IP router to the OXC and the Optical NNI can > be used to > >> connect > >> two optical network domains together. Here the optical layer is > >> "fat, smart > >> and agile". > >> > >> It is unclear at this time which of these models will prevail. > >> > >> Krishna Bala > >> Tellium > >> > >> > >> > >> > -----Original Message----- > >> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis > >> > Villamizar > >> > Sent: Thursday, March 23, 2000 1:55 PM > >> > To: Jagan Shantigram > >> > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > >> > ip-optical@lists.research.bell-labs.com > >> > Subject: Re: Comments on draft-ip-optical-framework-00.txt > >> > > >> > > >> > > >> > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > >> > Shantigram wr > >> > ites: > >> > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > >> > > > > >> > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > >> > > >> > >> > > >> > >> > > >> Hello Jagan, > >> > > >> > >> > > >> > When we do not have lambda conversion however, this > >> problem cannot > >> > > >> > be solved optimally.. it is akin to the graph coloring > >> > > >> > problem - which ofcourse has heuristics that can get us to > >> > > >> > a factor (?) of the optimal solution. So, connections may > >> > > >> > be blocked even though there is capacity on the fiber to > >> > > >> > support it, just because the wavelength is already used up. > >> > > >> > > >> > > >> > >> > > >> Connections can be blocked when?? At service > provisioning time or > >> > > >> at the time the connection is requested?? My point is a > >> > > >> connection of 2.48 Gbps is not likely to be a random event or an > >> > > >> ATM-like SVC. If a customer would require such huge > bandwidth, it > >> > > >> would need that BW to go through or it would better look for > >> > > >> another carrier that will provide a TDM/leased line?? Of course > >> > > >> wavelength conversion can help build a better-utilized network, > >> > > >> no question about that. > >> > > >> > >> > > >> Khaled > >> > > > > >> > > > > >> > > >The exception to the rule that "a connection of 2.48 Gbps is not > >> > > >likely to be a random event" is where a very major event, > possilble > >> > > >external to one's own network results in a shift in > traffic patterns > >> > > >that is significant enough to require that additional > >> lambdas be added > >> > > >to existing paths. > >> > > > > >> > > >The real world example in the ISP world is a failure of a peering > >> > > >point of some sort, a provider interconnect, a NAP or NAP > >> connectivity > >> > > >of some party. Since all major ISPs are connected to > each other at > >> > > >more than one geographically diverse peering point, the > traffic will > >> > > >still flow, but the path will have changed. > >> > > > > >> > > >This may mean that a path that previously required 3 lambdas (for > >> > > >example), now requires 4 lambdas. There are at least 3 ways to > >> > > >accommodate this requirement: > >> > > > > >> > > > 1. An external management system adds a lambda to both > the routers > >> > > > at either end and the optical switches > (demonstrated at OFC). > >> > > > > >> > > > 2. The router signals the requirement/desire for an additional > >> > > > lambda to the adjacent optical switch which sets up a path. > >> > > > This is the overlay model. It can be trivially > >> implemented with > >> > > > MPLS by having the router send a loose source hop in the ERO > >> > > > allowing the switch to create the path or reject > the request. > >> > > > >> > > Curtis, > >> > > > >> > > Am trying to understand the model here. Does the overlay model > >> > > as you put above imply that the optical devices need to be > >> mini-routers > >> > > in their own right? They have to be able to set up > end-to-end optical > >> > > paths.. perhaps some kind of binding between the end-host > IP address > >> > > and an addressing scheme for Optical devices.. ala ATM? > >> > > What does the overlay model entail? > >> > > >> > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or > >> > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > >> > > >> > Alternately, the lambdas can be set statically and the edge router > >> > simple advertises a Lambda-Switch Capable link ala > >> > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt > >> > accommodating the overlay model). > >> > > >> > I don't think draft-kompella-mpls-optical-00.txt has all the details > >> > sufficiently ironed out for the case where the optical switch > >> > advertises the availability of an optical link. If it does, then the > >> > details ar just not clear to me. (Could be my careless reading). > >> > > >> > > > 3. The router has enough information about the > characteristics of > >> > > > the optical devices to compute the path and so it does > >> so. This > >> > > > is the peer model. > >> > > > > >> > > > >> > > What does this model need.. a protocol for exchanging information > >> > > between the router and the optical device? > >> > > >> > It needs a means to communicate OOB wrt the primary lightpath. That > >> > means would again be running the IGP and RSVP. Based on reading the > >> > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the > >> > optical switch exchanges this information OOB although I > would imagine > >> > that it would be quite easy to maintian another interface (perhaps > >> > even an electrical, though gig-E would do fine) between the > router and > >> > optical device in which the optical device advertises the optical > >> > links. The router on either end of an optical link, seeing or having > >> > set up a Packet-Switch Capable link would then have to bring up an > >> > RSVP adjacency over it, though I think it would not need an IGP > >> > adjacency. (I'm not clear on this last point.) > >> > > >> > The availability of certain types of links (Packet-Switch Capable, > >> > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > >> > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm > >> > not clear on whether the adjacent LSR should advertise a Forwarding > >> > Adjacency PSC after RSVP comes up over a set of optical links (it > >> > seems to be the intent) but maybe the authors can clarify the usage. > >> > > >> > The ongoing discussion and the topic of the (way too numerous) > >> > framework documents floating around has been what additional > >> > information would be needed in order to provide adequate constraints > >> > to set up optical paths, a particularly difficult problem for > >> > transparent paths. > >> > > >> > > -jagan. > >> > > > >> > > >The way this might manifest itself is LSPs that might > take an optical > >> > > >path from A to C are going from A to B to C because A to C > >> lambdas are > >> > > >too full. If so, then A could in principle request an additional > >> > > >lambda, but in practice the means to signal this has not > >> been defined. > >> > > > > >> > > >Curtis > >> > > > >> > > Jagannath Shantigram > >> > > Photonex Corporation > >> > > >> > btw- I exchanged some private email with one of the authors of > >> > draft-kompella-mpls-optical.txt and owe them some detailed comments > >> > (appologies to them for the delay, busy). After some brief > discussion > >> > and after a second reading, the intent seems a lot more clear. The > >> > usage material is at the end so when reading the document from front > >> > to back the intent is not clear until the end and then a second > >> > reading is required. > >> > > >> > Curtis > >> > > >> > > > > > > > > > > Jagannath Shantigram > Photonex Corporation > From owner-mpls@UU.NET Mon Mar 27 18:42:45 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27172 for ; Mon, 27 Mar 2000 18:42:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiju15246; Mon, 27 Mar 2000 23:42:44 GMT Received: by mail-control.mail.uu.net id QQiiju08306 for mpls-outgoing; Mon, 27 Mar 2000 23:42:28 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiju08281 for ; Mon, 27 Mar 2000 23:42:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiju01545 for ; Mon, 27 Mar 2000 18:42:12 -0500 (EST) Received: from smtp6.mindspring.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQiiju14760 for ; Mon, 27 Mar 2000 23:42:12 GMT Received: from jluciani (ip106.cambridge1.ma.pub-ip.psi.net [38.32.111.106]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id SAA20598; Mon, 27 Mar 2000 18:41:52 -0500 (EST) Message-ID: <009e01bf9846$0cc47ec0$a4d0fea9@jluciani> Reply-To: "James V. Luciani" From: "James V. Luciani" To: "Krishna Bala" , "Jagan Shantigram" , "Jonathan Lang" , Cc: "Khaled Elsayed" , , References: <00f801bf9843$888c2560$425cc697@tempest> Subject: Re: Comments on draft-ip-optical-framework-00.txt Date: Mon, 27 Mar 2000 18:41:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Just to beat a dead horse .. the difference between the open model > and the overlay is just that the overlay model typically suggests that That depends... see below. > there would be N^2 connectivity (i.e., every router, for instance, is > statically connected to every other). In any case, the open model allows While there may indeed be some misunderstanding as to the meaning of the "overlay model" (not to mention the meaning of the other models :-)), the traditional definition of overlay is not one of static operation. NHRP and MPOA, for example, are overlay in my book (and most folks that I know). They most certainly imply non-static connections by defintion (i.e., use of SVCs). This having been said, I believe that we can do one of two things here. One, keep the current terms and potentially risk an ad nauseum inspection of the meaning of these terms; or two, come up with a term which is satisfactory to all. In the second case we would have models: 1) X 2) Peer where X is the PC term for what we want to get at. So my opine is that X="augmented routing model"/ARM model. Do I hear a hmmmm??? --Jim > for fully dynamic operation. The overlay model suggests static operation of > the optical layer. > > As I see it there are only two architectures that are worth considering: > 1. Peer > 2. Open > > I agree with you that there is no need to add the "overlay" model to > this list. The open model covers the static and the dynamic cases. > > Krishna > > > -----Original Message----- > > From: Jagan Shantigram [mailto:jagan@photonex.com] > > Sent: Monday, March 27, 2000 10:14 AM > > To: Krishna Bala; Jonathan Lang; curtis@avici.com > > Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com > > Subject: RE: Comments on draft-ip-optical-framework-00.txt > > > > > > At 05:04 PM 3/24/00 -0500, Krishna Bala wrote: > > >Jonathan, > > >Point 1: Let me clarify the "open model". > > > > > >Open refers to the fact that this model supports the interconnection of > > >several types of clients to an optical network (server layer). > > >Examples of Clients: > > >IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services" > > > > > >The open model also allows the interconnection of other Optical Network > > >Elements to > > >each other. > > >Examples of other Network Elements: > > >Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC, Wavelength > > >Interchanging XC > > > > > >In general, since it offers the capability to support ALL > > services (not just > > >IP) > > >it is an Open Model. > > > > Krishna, > > > > It seems like the above just described what people understand > > by the overlay model. In this model the optical layer presents > > itself as a layer that can provide a bunch of services to the > > upper data/IP layer. These services could include point > > to point clear channel, 1+1 protection, negotiable bandwidth > > etc.. (just to give examples). How the optical layer > > achieves these services is yet to be determined - which as you > > mention will require standardized interfaces between the various > > optical components and as well as a standardized API for these > > services to be requested. > > > > My question is what are these services that would be useful > > for the optical layer to provide and what are the tasks that > > have to be taken up to enable it? > > > > In any case it seems risky to take up a model that requires > > too much cooperation between the various layers - since that > > will mean that there will be inter-dependence in the development > > of that technology. Ofcourse there are others who have more > > experience on questions like this. > > > > > > > > > >Point 2: Overlay Model vs. Open > > > > > >The connotation that goes typically with the Overlay model is that the > > >optical > > >layer is quasi static and might require N^2 connectivity at the IP/client > > >layer. > > > > Am afraid I missed the point here. > > > > thanks, > > -jagan. > > > > > > >Hence, I prefer to distinguish the open model from overlay. > > >Krishna Bala > > > > > >> -----Original Message----- > > >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jonathan > > >> Lang > > >> Sent: Thursday, March 23, 2000 4:55 PM > > >> To: 'Krishna Bala'; curtis@avici.com; Jagan Shantigram > > >> Cc: Khaled Elsayed; mpls@UU.NET; > > ip-optical@lists.research.bell-labs.com > > >> Subject: RE: Comments on draft-ip-optical-framework-00.txt > > >> > > >> > > >> Krishna, > > >> The Open model seems quite "Closed" to me - the very nature of clouds > > >> implies information hiding in my mind. What is exactly meant by open? > > >> Also, I'm not sure I agree with your definition of overlay, as > > many people > > >> allow the overlay model to encompass both your (2) and (3). > > >> Furthermore, I > > >> don't think the Peer Model implies OXCs are "agile but fat & > > >> dumb" since as > > >> they are "peers", this would also imply routers are "agile but > > fat & dumb" > > >> as well - and at some point, someone needs to have > > intelligence. I would > > >> suggest that the Peer model allows both routers and OXCs to > > interoperate > > >> intelligently. > > >> > > >> Regards, > > >> Jonathan > > >> > > >> -----Original Message----- > > >> From: Krishna Bala [mailto:kbala@tellium.com] > > >> Sent: Thursday, March 23, 2000 11:59 AM > > >> To: curtis@avici.com; Jagan Shantigram > > >> Cc: Khaled Elsayed; mpls@UU.NET; > > ip-optical@lists.research.bell-labs.com > > >> Subject: RE: Comments on draft-ip-optical-framework-00.txt > > >> > > >> > > >> Jagan, > > >> There are several architectural models for IP over Optical > > Networks that > > >> are emerging: > > >> > > >> 1. Peer Model > > >> In this model the IP router is entirely aware of the details on the > > >> underlying > > >> optical network (topology information, wavelength and port > > usage and lamda > > >> assignment). > > >> It is able to control and manage entire end to end paths. In this > > >> model the > > >> OXC is "agile but fat & dumb". > > >> 2. Overlay Model > > >> The optical layer is "fat & dumb". The lamda connections between the IP > > >> routers behave as if they were dedicated fibers between them. The > > >> IP routes > > >> provision logical optical circuits over a fixed or at best a > > quasi-fixed > > >> optical > > >> layer. > > >> 3. Open Model > > >> In this scenario the optical layer comprises of several "vendor/network > > >> operator clouds" > > >> that have well defined interfaces. For example, an Optical UNI > > can be used > > >> to > > >> interconnect the IP router to the OXC and the Optical NNI can > > be used to > > >> connect > > >> two optical network domains together. Here the optical layer is > > >> "fat, smart > > >> and agile". > > >> > > >> It is unclear at this time which of these models will prevail. > > >> > > >> Krishna Bala > > >> Tellium > > >> > > >> > > >> > > >> > -----Original Message----- > > >> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis > > >> > Villamizar > > >> > Sent: Thursday, March 23, 2000 1:55 PM > > >> > To: Jagan Shantigram > > >> > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > > >> > ip-optical@lists.research.bell-labs.com > > >> > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > >> > > > >> > > > >> > > > >> > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > > >> > Shantigram wr > > >> > ites: > > >> > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > >> > > > > > >> > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: > > >> > > >> > > >> > > >> > > >> > > >> Hello Jagan, > > >> > > >> > > >> > > >> > When we do not have lambda conversion however, this > > >> problem cannot > > >> > > >> > be solved optimally.. it is akin to the graph coloring > > >> > > >> > problem - which ofcourse has heuristics that can get us to > > >> > > >> > a factor (?) of the optimal solution. So, connections may > > >> > > >> > be blocked even though there is capacity on the fiber to > > >> > > >> > support it, just because the wavelength is already used up. > > >> > > >> > > > >> > > >> > > >> > > >> Connections can be blocked when?? At service > > provisioning time or > > >> > > >> at the time the connection is requested?? My point is a > > >> > > >> connection of 2.48 Gbps is not likely to be a random event or an > > >> > > >> ATM-like SVC. If a customer would require such huge > > bandwidth, it > > >> > > >> would need that BW to go through or it would better look for > > >> > > >> another carrier that will provide a TDM/leased line?? Of course > > >> > > >> wavelength conversion can help build a better-utilized network, > > >> > > >> no question about that. > > >> > > >> > > >> > > >> Khaled > > >> > > > > > >> > > > > > >> > > >The exception to the rule that "a connection of 2.48 Gbps is not > > >> > > >likely to be a random event" is where a very major event, > > possilble > > >> > > >external to one's own network results in a shift in > > traffic patterns > > >> > > >that is significant enough to require that additional > > >> lambdas be added > > >> > > >to existing paths. > > >> > > > > > >> > > >The real world example in the ISP world is a failure of a peering > > >> > > >point of some sort, a provider interconnect, a NAP or NAP > > >> connectivity > > >> > > >of some party. Since all major ISPs are connected to > > each other at > > >> > > >more than one geographically diverse peering point, the > > traffic will > > >> > > >still flow, but the path will have changed. > > >> > > > > > >> > > >This may mean that a path that previously required 3 lambdas (for > > >> > > >example), now requires 4 lambdas. There are at least 3 ways to > > >> > > >accommodate this requirement: > > >> > > > > > >> > > > 1. An external management system adds a lambda to both > > the routers > > >> > > > at either end and the optical switches > > (demonstrated at OFC). > > >> > > > > > >> > > > 2. The router signals the requirement/desire for an additional > > >> > > > lambda to the adjacent optical switch which sets up a path. > > >> > > > This is the overlay model. It can be trivially > > >> implemented with > > >> > > > MPLS by having the router send a loose source hop in the ERO > > >> > > > allowing the switch to create the path or reject > > the request. > > >> > > > > >> > > Curtis, > > >> > > > > >> > > Am trying to understand the model here. Does the overlay model > > >> > > as you put above imply that the optical devices need to be > > >> mini-routers > > >> > > in their own right? They have to be able to set up > > end-to-end optical > > >> > > paths.. perhaps some kind of binding between the end-host > > IP address > > >> > > and an addressing scheme for Optical devices.. ala ATM? > > >> > > What does the overlay model entail? > > >> > > > >> > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or > > >> > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > > >> > > > >> > Alternately, the lambdas can be set statically and the edge router > > >> > simple advertises a Lambda-Switch Capable link ala > > >> > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt > > >> > accommodating the overlay model). > > >> > > > >> > I don't think draft-kompella-mpls-optical-00.txt has all the details > > >> > sufficiently ironed out for the case where the optical switch > > >> > advertises the availability of an optical link. If it does, then the > > >> > details ar just not clear to me. (Could be my careless reading). > > >> > > > >> > > > 3. The router has enough information about the > > characteristics of > > >> > > > the optical devices to compute the path and so it does > > >> so. This > > >> > > > is the peer model. > > >> > > > > > >> > > > > >> > > What does this model need.. a protocol for exchanging information > > >> > > between the router and the optical device? > > >> > > > >> > It needs a means to communicate OOB wrt the primary lightpath. That > > >> > means would again be running the IGP and RSVP. Based on reading the > > >> > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the > > >> > optical switch exchanges this information OOB although I > > would imagine > > >> > that it would be quite easy to maintian another interface (perhaps > > >> > even an electrical, though gig-E would do fine) between the > > router and > > >> > optical device in which the optical device advertises the optical > > >> > links. The router on either end of an optical link, seeing or having > > >> > set up a Packet-Switch Capable link would then have to bring up an > > >> > RSVP adjacency over it, though I think it would not need an IGP > > >> > adjacency. (I'm not clear on this last point.) > > >> > > > >> > The availability of certain types of links (Packet-Switch Capable, > > >> > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > > >> > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm > > >> > not clear on whether the adjacent LSR should advertise a Forwarding > > >> > Adjacency PSC after RSVP comes up over a set of optical links (it > > >> > seems to be the intent) but maybe the authors can clarify the usage. > > >> > > > >> > The ongoing discussion and the topic of the (way too numerous) > > >> > framework documents floating around has been what additional > > >> > information would be needed in order to provide adequate constraints > > >> > to set up optical paths, a particularly difficult problem for > > >> > transparent paths. > > >> > > > >> > > -jagan. > > >> > > > > >> > > >The way this might manifest itself is LSPs that might > > take an optical > > >> > > >path from A to C are going from A to B to C because A to C > > >> lambdas are > > >> > > >too full. If so, then A could in principle request an additional > > >> > > >lambda, but in practice the means to signal this has not > > >> been defined. > > >> > > > > > >> > > >Curtis > > >> > > > > >> > > Jagannath Shantigram > > >> > > Photonex Corporation > > >> > > > >> > btw- I exchanged some private email with one of the authors of > > >> > draft-kompella-mpls-optical.txt and owe them some detailed comments > > >> > (appologies to them for the delay, busy). After some brief > > discussion > > >> > and after a second reading, the intent seems a lot more clear. The > > >> > usage material is at the end so when reading the document from front > > >> > to back the intent is not clear until the end and then a second > > >> > reading is required. > > >> > > > >> > Curtis > > >> > > > >> > > > > > > > > > > > > > > > > Jagannath Shantigram > > Photonex Corporation > > From owner-mpls@UU.NET Mon Mar 27 19:03:12 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27518 for ; Mon, 27 Mar 2000 19:03:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiijw26930; Tue, 28 Mar 2000 00:03:11 GMT Received: by mail-control.mail.uu.net id QQiijw16938 for mpls-outgoing; Tue, 28 Mar 2000 00:02:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiijw16927 for ; Tue, 28 Mar 2000 00:02:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiijw19679 for ; Mon, 27 Mar 2000 19:02:06 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiijw07581 for ; Tue, 28 Mar 2000 00:02:04 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA20626 for mpls@uu.net; Mon, 27 Mar 2000 19:02:04 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiijw13706 for ; Tue, 28 Mar 2000 00:01:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiijw19538 for ; Mon, 27 Mar 2000 19:00:58 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiijw25570 for ; Tue, 28 Mar 2000 00:00:58 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 19:01:00 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F8E5@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'tnadeau@cisco.com'" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" , "Cucchiara, Joan" Subject: Additional comments on the LSR MIB Date: Mon, 27 Mar 2000 19:00:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom, Arun and Cheenu, A few more comments on the LSR MIB. -Joan * mplsLabelStackIndexNext is an Unsigned32 and the mplsLabelStackIndex is Integer32. One of these should be changed. * mplsLabelStackIndex should have MAX-ACCESS of not-accessible. * The mplsLabelStackTable should be made optional for LDP LSPs which use ATM or FR. Could this be added in the conformance section? * mplsTSpecIndexNext should start at zero. * mplsTSpecMeanRate -- what is the agent or mpls supposed to do with this value? Is the mean rate for an LSP calculated over time? * mplsTSpecMaxRate and mplsTSpecMaxBurstSize: are these objects related? If so, could an explanation be given of how they are related? Can the BurstSize exceed the MaxRate? What does it mean if this happens? * Is this table going to be made optional for LDP? * Could we have a description of what happens when the InSegment TSpec values are lower than the OutSegment TSpec values? (Seems like there should be some co-operation between the objects, or at least some "actual" objects which reflect what the true values are.) Why does one need to specify the TSpec for the InSegment? It would seem that the OutSegment is relevant and that the InSegment is not really configurable, could you explain why it is needed for the InSegment? * Could the individual trap enable/disable objects be placed near their respective information? (NOTE: they are grouped differently in the conformance section which is more where you would expect the objects to be in the MIB.) * In general, the MIB heirarchy could use some heirarchy :) Seems like everything is under 'mplsLsrObjects'. * In general, the Index objects which have MIN-ACCESS of read-only should be fixed in the mib to have not-accessible access and removed from the Conformance section. * The conformance information for the following object is worrisome because it is not clear under which circumstances one would not support all the enums. OBJECT mplsInSegmentAddrFamily SYNTAX INTEGER { other(0) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. A value of other(0) should be supported." If the agent can't tell or doesn't know what the Address Family is, then how are all the counters effected (specifically packet and octet counters) that are related to this InSegment on an MPLS Interface? OBJECT mplsOutSegmentIndexNext MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsXCIndexNext MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT mplsXCLabelStackIndexNext MIN-ACCESS read-only DESCRIPTION "Write access is not required." The above already have a MAX-ACCESS of read-only. From owner-mpls@UU.NET Mon Mar 27 19:25:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27804 for ; Mon, 27 Mar 2000 19:25:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiijx21386; Tue, 28 Mar 2000 00:25:46 GMT Received: by mail-control.mail.uu.net id QQiijx18750 for mpls-outgoing; Tue, 28 Mar 2000 00:25:08 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiijx18745 for ; Tue, 28 Mar 2000 00:25:01 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiijx22570 for ; Mon, 27 Mar 2000 19:24:59 -0500 (EST) Received: from mail16.vwh1.net by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [209.238.9.59]) id QQiijx20792 for ; Tue, 28 Mar 2000 00:24:58 GMT Received: from 208.55.74.250 (208.55.74.250) by mail16.vwh1.net (RS ver 1.0.53) with SMTP id 015851326; Mon, 27 Mar 2000 19:24:18 -0500 (EST) Message-Id: <3.0.6.32.20000327192747.00c9aa80@photonex.com> X-Sender: jagan@photonex.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 27 Mar 2000 19:27:47 -0500 To: "Krishna Bala" , "Jonathan Lang" , From: Jagan Shantigram Subject: RE: Comments on draft-ip-optical-framework-00.txt Cc: "Khaled Elsayed" , , In-Reply-To: <00f801bf9843$888c2560$425cc697@tempest> References: <3.0.6.32.20000327101337.00b2d100@photonex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Loop-Detect: 1 Sender: owner-mpls@UU.NET Precedence: bulk At 06:24 PM 3/27/00 -0500, Krishna Bala wrote: >Jagan, >Just to beat a dead horse .. the difference between the open model >and the overlay is just that the overlay model typically suggests that >there would be N^2 connectivity (i.e., every router, for instance, is >statically connected to every other). In any case, the open model allows >for fully dynamic operation. The overlay model suggests static operation of >the optical layer. > >As I see it there are only two architectures that are worth considering: >1. Peer >2. Open > >I agree with you that there is no need to add the "overlay" model to >this list. The open model covers the static and the dynamic cases. o-oh.. I wasn't suggesting that we do away with the term "overlay" at all.. But, your preference is noted ofcourse. Additionally - from my reading it did not seem that "overlay" implies static operation, or even a full connectivity between routers - N^2 as you mentioned. I was looking at some really old(?) IP/ATM debates and it seems like the term overlay/peer were used there as well and if I may, the debate was not much different either. In any case I do think that the parameters and the trade-offs are different than in the case of IP/ATM. I would like to see more discussion on that so that we can draw a more educated line between those two models in IP/Optical scenario. For example questions like - addressing, dynamic path establishment, router/router-like behavior of optical devices, L2-switch-like behavior of optical devices etc.. While the questions seem to be the same as when people were discussing how IP should be carried on ATM - will the answers be different in this case? One answer could be to let optics be stupid and simple and provide point to point connectivity - just the plain-old-transport-network? While we may be able to guarantee the behavior and correctly define the network in that case - it will probably not use the current technologies of configurability of wavelength paths and the ability to condense more and more high speed interfaces into a single box along with the switching intelligence that is required to make it powerful. -jagan. > >Krishna > >> -----Original Message----- >> From: Jagan Shantigram [mailto:jagan@photonex.com] >> Sent: Monday, March 27, 2000 10:14 AM >> To: Krishna Bala; Jonathan Lang; curtis@avici.com >> Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com >> Subject: RE: Comments on draft-ip-optical-framework-00.txt >> >> >> At 05:04 PM 3/24/00 -0500, Krishna Bala wrote: >> >Jonathan, >> >Point 1: Let me clarify the "open model". >> > >> >Open refers to the fact that this model supports the interconnection of >> >several types of clients to an optical network (server layer). >> >Examples of Clients: >> >IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services" >> > >> >The open model also allows the interconnection of other Optical Network >> >Elements to >> >each other. >> >Examples of other Network Elements: >> >Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC, Wavelength >> >Interchanging XC >> > >> >In general, since it offers the capability to support ALL >> services (not just >> >IP) >> >it is an Open Model. >> >> Krishna, >> >> It seems like the above just described what people understand >> by the overlay model. In this model the optical layer presents >> itself as a layer that can provide a bunch of services to the >> upper data/IP layer. These services could include point >> to point clear channel, 1+1 protection, negotiable bandwidth >> etc.. (just to give examples). How the optical layer >> achieves these services is yet to be determined - which as you >> mention will require standardized interfaces between the various >> optical components and as well as a standardized API for these >> services to be requested. >> >> My question is what are these services that would be useful >> for the optical layer to provide and what are the tasks that >> have to be taken up to enable it? >> >> In any case it seems risky to take up a model that requires >> too much cooperation between the various layers - since that >> will mean that there will be inter-dependence in the development >> of that technology. Ofcourse there are others who have more >> experience on questions like this. >> >> >> > >> >Point 2: Overlay Model vs. Open >> > >> >The connotation that goes typically with the Overlay model is that the >> >optical >> >layer is quasi static and might require N^2 connectivity at the IP/client >> >layer. >> >> Am afraid I missed the point here. >> >> thanks, >> -jagan. >> >> >> >Hence, I prefer to distinguish the open model from overlay. >> >Krishna Bala >> > >> >> -----Original Message----- >> >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jonathan >> >> Lang >> >> Sent: Thursday, March 23, 2000 4:55 PM >> >> To: 'Krishna Bala'; curtis@avici.com; Jagan Shantigram >> >> Cc: Khaled Elsayed; mpls@UU.NET; >> ip-optical@lists.research.bell-labs.com >> >> Subject: RE: Comments on draft-ip-optical-framework-00.txt >> >> >> >> >> >> Krishna, >> >> The Open model seems quite "Closed" to me - the very nature of clouds >> >> implies information hiding in my mind. What is exactly meant by open? >> >> Also, I'm not sure I agree with your definition of overlay, as >> many people >> >> allow the overlay model to encompass both your (2) and (3). >> >> Furthermore, I >> >> don't think the Peer Model implies OXCs are "agile but fat & >> >> dumb" since as >> >> they are "peers", this would also imply routers are "agile but >> fat & dumb" >> >> as well - and at some point, someone needs to have >> intelligence. I would >> >> suggest that the Peer model allows both routers and OXCs to >> interoperate >> >> intelligently. >> >> >> >> Regards, >> >> Jonathan >> >> >> >> -----Original Message----- >> >> From: Krishna Bala [mailto:kbala@tellium.com] >> >> Sent: Thursday, March 23, 2000 11:59 AM >> >> To: curtis@avici.com; Jagan Shantigram >> >> Cc: Khaled Elsayed; mpls@UU.NET; >> ip-optical@lists.research.bell-labs.com >> >> Subject: RE: Comments on draft-ip-optical-framework-00.txt >> >> >> >> >> >> Jagan, >> >> There are several architectural models for IP over Optical >> Networks that >> >> are emerging: >> >> >> >> 1. Peer Model >> >> In this model the IP router is entirely aware of the details on the >> >> underlying >> >> optical network (topology information, wavelength and port >> usage and lamda >> >> assignment). >> >> It is able to control and manage entire end to end paths. In this >> >> model the >> >> OXC is "agile but fat & dumb". >> >> 2. Overlay Model >> >> The optical layer is "fat & dumb". The lamda connections between the IP >> >> routers behave as if they were dedicated fibers between them. The >> >> IP routes >> >> provision logical optical circuits over a fixed or at best a >> quasi-fixed >> >> optical >> >> layer. >> >> 3. Open Model >> >> In this scenario the optical layer comprises of several "vendor/network >> >> operator clouds" >> >> that have well defined interfaces. For example, an Optical UNI >> can be used >> >> to >> >> interconnect the IP router to the OXC and the Optical NNI can >> be used to >> >> connect >> >> two optical network domains together. Here the optical layer is >> >> "fat, smart >> >> and agile". >> >> >> >> It is unclear at this time which of these models will prevail. >> >> >> >> Krishna Bala >> >> Tellium >> >> >> >> >> >> >> >> > -----Original Message----- >> >> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis >> >> > Villamizar >> >> > Sent: Thursday, March 23, 2000 1:55 PM >> >> > To: Jagan Shantigram >> >> > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; >> >> > ip-optical@lists.research.bell-labs.com >> >> > Subject: Re: Comments on draft-ip-optical-framework-00.txt >> >> > >> >> > >> >> > >> >> > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan >> >> > Shantigram wr >> >> > ites: >> >> > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: >> >> > > > >> >> > > >In message <38D76337.478CA5FC@ieee.org>, Khaled Elsayed writes: >> >> > > >> >> >> > > >> >> >> > > >> Hello Jagan, >> >> > > >> >> >> > > >> > When we do not have lambda conversion however, this >> >> problem cannot >> >> > > >> > be solved optimally.. it is akin to the graph coloring >> >> > > >> > problem - which ofcourse has heuristics that can get us to >> >> > > >> > a factor (?) of the optimal solution. So, connections may >> >> > > >> > be blocked even though there is capacity on the fiber to >> >> > > >> > support it, just because the wavelength is already used up. >> >> > > >> > >> >> > > >> >> >> > > >> Connections can be blocked when?? At service >> provisioning time or >> >> > > >> at the time the connection is requested?? My point is a >> >> > > >> connection of 2.48 Gbps is not likely to be a random event or an >> >> > > >> ATM-like SVC. If a customer would require such huge >> bandwidth, it >> >> > > >> would need that BW to go through or it would better look for >> >> > > >> another carrier that will provide a TDM/leased line?? Of course >> >> > > >> wavelength conversion can help build a better-utilized network, >> >> > > >> no question about that. >> >> > > >> >> >> > > >> Khaled >> >> > > > >> >> > > > >> >> > > >The exception to the rule that "a connection of 2.48 Gbps is not >> >> > > >likely to be a random event" is where a very major event, >> possilble >> >> > > >external to one's own network results in a shift in >> traffic patterns >> >> > > >that is significant enough to require that additional >> >> lambdas be added >> >> > > >to existing paths. >> >> > > > >> >> > > >The real world example in the ISP world is a failure of a peering >> >> > > >point of some sort, a provider interconnect, a NAP or NAP >> >> connectivity >> >> > > >of some party. Since all major ISPs are connected to >> each other at >> >> > > >more than one geographically diverse peering point, the >> traffic will >> >> > > >still flow, but the path will have changed. >> >> > > > >> >> > > >This may mean that a path that previously required 3 lambdas (for >> >> > > >example), now requires 4 lambdas. There are at least 3 ways to >> >> > > >accommodate this requirement: >> >> > > > >> >> > > > 1. An external management system adds a lambda to both >> the routers >> >> > > > at either end and the optical switches >> (demonstrated at OFC). >> >> > > > >> >> > > > 2. The router signals the requirement/desire for an additional >> >> > > > lambda to the adjacent optical switch which sets up a path. >> >> > > > This is the overlay model. It can be trivially >> >> implemented with >> >> > > > MPLS by having the router send a loose source hop in the ERO >> >> > > > allowing the switch to create the path or reject >> the request. >> >> > > >> >> > > Curtis, >> >> > > >> >> > > Am trying to understand the model here. Does the overlay model >> >> > > as you put above imply that the optical devices need to be >> >> mini-routers >> >> > > in their own right? They have to be able to set up >> end-to-end optical >> >> > > paths.. perhaps some kind of binding between the end-host >> IP address >> >> > > and an addressing scheme for Optical devices.. ala ATM? >> >> > > What does the overlay model entail? >> >> > >> >> > The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or >> >> > CRLDP) in a manner similar to the ATM UNI setting up an SVC. >> >> > >> >> > Alternately, the lambdas can be set statically and the edge router >> >> > simple advertises a Lambda-Switch Capable link ala >> >> > draft-kompella-mpls-optical-00.txt (if I understand their intent wrt >> >> > accommodating the overlay model). >> >> > >> >> > I don't think draft-kompella-mpls-optical-00.txt has all the details >> >> > sufficiently ironed out for the case where the optical switch >> >> > advertises the availability of an optical link. If it does, then the >> >> > details ar just not clear to me. (Could be my careless reading). >> >> > >> >> > > > 3. The router has enough information about the >> characteristics of >> >> > > > the optical devices to compute the path and so it does >> >> so. This >> >> > > > is the peer model. >> >> > > > >> >> > > >> >> > > What does this model need.. a protocol for exchanging information >> >> > > between the router and the optical device? >> >> > >> >> > It needs a means to communicate OOB wrt the primary lightpath. That >> >> > means would again be running the IGP and RSVP. Based on reading the >> >> > draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the >> >> > optical switch exchanges this information OOB although I >> would imagine >> >> > that it would be quite easy to maintian another interface (perhaps >> >> > even an electrical, though gig-E would do fine) between the >> router and >> >> > optical device in which the optical device advertises the optical >> >> > links. The router on either end of an optical link, seeing or having >> >> > set up a Packet-Switch Capable link would then have to bring up an >> >> > RSVP adjacency over it, though I think it would not need an IGP >> >> > adjacency. (I'm not clear on this last point.) >> >> > >> >> > The availability of certain types of links (Packet-Switch Capable, >> >> > Lambda-Switch Capable, Fiber-Switch Capable) as defined in >> >> > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. I'm >> >> > not clear on whether the adjacent LSR should advertise a Forwarding >> >> > Adjacency PSC after RSVP comes up over a set of optical links (it >> >> > seems to be the intent) but maybe the authors can clarify the usage. >> >> > >> >> > The ongoing discussion and the topic of the (way too numerous) >> >> > framework documents floating around has been what additional >> >> > information would be needed in order to provide adequate constraints >> >> > to set up optical paths, a particularly difficult problem for >> >> > transparent paths. >> >> > >> >> > > -jagan. >> >> > > >> >> > > >The way this might manifest itself is LSPs that might >> take an optical >> >> > > >path from A to C are going from A to B to C because A to C >> >> lambdas are >> >> > > >too full. If so, then A could in principle request an additional >> >> > > >lambda, but in practice the means to signal this has not >> >> been defined. >> >> > > > >> >> > > >Curtis >> >> > > >> >> > > Jagannath Shantigram >> >> > > Photonex Corporation >> >> > >> >> > btw- I exchanged some private email with one of the authors of >> >> > draft-kompella-mpls-optical.txt and owe them some detailed comments >> >> > (appologies to them for the delay, busy). After some brief >> discussion >> >> > and after a second reading, the intent seems a lot more clear. The >> >> > usage material is at the end so when reading the document from front >> >> > to back the intent is not clear until the end and then a second >> >> > reading is required. >> >> > >> >> > Curtis >> >> > >> >> >> > >> > >> > >> > >> >> Jagannath Shantigram >> Photonex Corporation >> > > > Jagannath Shantigram Photonex Corporation From owner-mpls@UU.NET Mon Mar 27 19:34:42 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27950 for ; Mon, 27 Mar 2000 19:34:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiijy14604; Tue, 28 Mar 2000 00:34:39 GMT Received: by mail-control.mail.uu.net id QQiijy19152 for mpls-outgoing; Tue, 28 Mar 2000 00:34:24 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiijy19147 for ; Tue, 28 Mar 2000 00:34:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiijy23655 for ; Mon, 27 Mar 2000 19:34:14 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiijy26344 for ; Tue, 28 Mar 2000 00:34:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA23945 for mpls@uu.net; Mon, 27 Mar 2000 19:34:12 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiijy19132 for ; Tue, 28 Mar 2000 00:33:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiijy23551 for ; Mon, 27 Mar 2000 19:33:34 -0500 (EST) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQiijy25929 for ; Tue, 28 Mar 2000 00:33:33 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA28158; Mon, 27 Mar 2000 16:31:49 -0800 (PST) Message-Id: <200003280031.QAA28158@omega.cisco.com> To: "James V. Luciani" cc: "Krishna Bala" , "Jagan Shantigram" , "Jonathan Lang" , curtis@avici.com, "Khaled Elsayed" , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Mon, 27 Mar 2000 18:41:54 EST." <009e01bf9846$0cc47ec0$a4d0fea9@jluciani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28154.954203508.1@cisco.com> Date: Mon, 27 Mar 2000 16:31:48 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Jim, > > Just to beat a dead horse .. the difference between the open model > > and the overlay is just that the overlay model typically suggests that > > That depends... see below. > > > there would be N^2 connectivity (i.e., every router, for instance, is > > statically connected to every other). In any case, the open model allows > > While there may indeed be some misunderstanding as to the meaning of the > "overlay model" (not to mention the meaning of the other models :-)), the > traditional definition of overlay is not one of static operation. NHRP and > MPOA, for example, are overlay in my book (and most folks that I know). > > They most certainly imply non-static connections by defintion (i.e., use of > SVCs). This having been said, I believe that we can do one of two things > here. One, keep the current terms and potentially risk an ad nauseum > inspection of the meaning of these terms; or two, come up with a term which > is satisfactory to all. In the second case we would have models: > 1) X > 2) Peer > where X is the PC term for what we want to get at. So my opine is that > X="augmented routing model"/ARM model. > > Do I hear a hmmmm??? I think you do. And it comes from you - it is your own hmmm. Yakov. From owner-mpls@UU.NET Mon Mar 27 20:46:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29183 for ; Mon, 27 Mar 2000 20:46:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiikd05836; Tue, 28 Mar 2000 01:46:37 GMT Received: by mail-control.mail.uu.net id QQiikd00846 for mpls-outgoing; Tue, 28 Mar 2000 01:46:10 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiikd00792 for ; Tue, 28 Mar 2000 01:46:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiikd17049 for ; Mon, 27 Mar 2000 20:46:03 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiikd24250 for ; Tue, 28 Mar 2000 01:46:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA29674 for mpls@uu.net; Mon, 27 Mar 2000 20:46:02 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiikc00531 for ; Tue, 28 Mar 2000 01:44:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiikc02277 for ; Mon, 27 Mar 2000 20:44:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQiikc04036 for ; Tue, 28 Mar 2000 01:44:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Mar 27 20:43:02 EST 2000 Received: from lucent.com (ex-vpn67.pa.bell-labs.com [135.250.1.67]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id UAA05286; Mon, 27 Mar 2000 20:42:55 -0500 (EST) Message-ID: <38E00ECB.B014BA0@lucent.com> Date: Mon, 27 Mar 2000 17:45:47 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Krishna Bala CC: mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <00f801bf9843$888c2560$425cc697@tempest> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Krishna Bala wrote: > > Jagan, > Just to beat a dead horse .. the difference between the open model > and the overlay is just that the overlay model typically suggests that > there would be N^2 connectivity (i.e., every router, for instance, is > statically connected to every other). In any case, the open model allows > for fully dynamic operation. The overlay model suggests static operation of > the optical layer. This isn't the definition of "overlay model" that has been used in the IETF for awhile. Static linking of all routers" is simply one instantiation. The key differentiator of an overlay model is the topological independence of the underlying and overlaying 'layers'. E.g. in an earlier century we talked about IP/ATM overlay models where the IP topology was logical wrt the switch-link topology of the underlying ATM network. The connectivity itself was static, soft, or dynamic as needed - however, the model was 'overlay' in each case. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Mon Mar 27 23:13:47 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03207 for ; Mon, 27 Mar 2000 23:13:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiikm13709; Tue, 28 Mar 2000 04:13:46 GMT Received: by mail-control.mail.uu.net id QQiikm01939 for mpls-outgoing; Tue, 28 Mar 2000 04:13:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiikm01924 for ; Tue, 28 Mar 2000 04:13:01 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiikm01757 for ; Mon, 27 Mar 2000 23:12:56 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQiikm21948 for ; Tue, 28 Mar 2000 04:11:52 GMT Received: from testras ([165.133.13.22]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id JAA00602; Tue, 28 Mar 2000 09:03:33 -0600 (GMT) Message-ID: <007c01bf9866$97d4b910$160d85a5@dti.daewoo.co.kr> From: "ashish" To: "Subodh Mathur" , References: <002201bf97e3$bbc3b980$160d85a5@dti.daewoo.co.kr> <001901bf9806$4851cf50$9dae3ec6@salmon> Subject: Re: CR-LDP Date: Tue, 28 Mar 2000 09:04:15 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01BF9894.97A68E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0077_01BF9894.97A68E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Subodh, Thanks for the response. In an MPLS network, there may be more than one Ingress LSR. In that scenario, to support LSP tunneling,(using ER-Hop TLV of type = LSPID) LSPID's of existing LSP's must be known.=20 So all Ingress LSR's must know about LSPID's. so my question is how the LSPID's are advertised. Please clarify. ashish ashishmonga@yahoo.com ----- Original Message -----=20 From: Subodh Mathur=20 To: ashish ; mpls@UU.NET=20 Sent: Monday, March 27, 2000 9:35 PM Subject: Re: CR-LDP Only CR-LSP Ingress and participating LSRs will know about the LSP ID = and can use this information for efficient local repair in loose segment of CR-LSP.=20 Hope this will help. Subodh Digital Technology Inc. ----- Original Message -----=20 From: ashish=20 To: mpls@UU.NET=20 Sent: Monday, March 27, 2000 6:58 AM Subject: CR-LDP In CR-LDP draft-03, one of the ER-HOP TLV types contain LSPID field = that is used for tunneling thru some existing LSP having that LSPID = field. This means that that LSPID should be known in advance . How is that done. Does information regarding each LSP being created each having unique = LSPID is propagated to all LSR's. Please clarify. ------=_NextPart_000_0077_01BF9894.97A68E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Subodh,
Thanks for the response.
In an MPLS network, there may be more = than one=20 Ingress LSR.
In that scenario, to support LSP = tunneling,(using=20 ER-Hop TLV of type LSPID) LSPID's of existing LSP's must be known. =
So all Ingress LSR's must know about=20 LSPID's.
so my question is how the LSPID's are=20 advertised.
Please clarify.
ashish
ashishmonga@yahoo.com
----- Original Message -----
From:=20 Subodh = Mathur=20
To: ashish ; mpls@UU.NET
Sent: Monday, March 27, 2000 = 9:35=20 PM
Subject: Re: CR-LDP

Only CR-LSP Ingress and participating = LSRs will=20 know about the LSP ID and can use this
information for efficient local = repair in loose=20 segment of CR-LSP.
Hope this will help.
Subodh
Digital Technology Inc.
----- Original Message -----
From:=20 ashish
Sent: Monday, March 27, 2000 = 6:58=20 AM
Subject: CR-LDP

In CR-LDP draft-03, one of the = ER-HOP TLV types=20 contain LSPID field that is used for tunneling thru some existing = LSP having=20 that LSPID field.
This means that that LSPID should = be known in=20 advance .
How is that done.
Does information regarding each LSP = being=20 created each having unique LSPID is propagated to all = LSR's.
Please=20 clarify.
------=_NextPart_000_0077_01BF9894.97A68E40-- From owner-mpls@UU.NET Mon Mar 27 23:45:46 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04176 for ; Mon, 27 Mar 2000 23:45:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiikp09549; Tue, 28 Mar 2000 04:45:47 GMT Received: by mail-control.mail.uu.net id QQiikp03544 for mpls-outgoing; Tue, 28 Mar 2000 04:45:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiikp03539 for ; Tue, 28 Mar 2000 04:45:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiikp05071 for ; Mon, 27 Mar 2000 23:45:13 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQiiko07989 for ; Tue, 28 Mar 2000 04:43:36 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id KAA01835; Tue, 28 Mar 2000 10:07:17 -0600 (GMT) Message-ID: <000e01bf9870$7a6ebce0$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: , Cc: "Ashish Monga" Subject: Re: CR-LDP Date: Tue, 28 Mar 2000 10:15:39 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01BF989E.90F9ADC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BF989E.90F9ADC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sumit The concerned section of CR-LDP draft is as below. 4.7.4. ER-Hop 4: LSPID The LSPID is used to identify the tunnel ingress point as the next hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an already established CR-LSP. It also allows for splicing the CR-LSP being established with an existing CR-LSP. If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may splice the CR-LSP of the incoming Label Request to the CR-LSP that currently exists with this LSPID. This is useful, for example, at the point at which a Label Request used for local repair arrives at the next ER-Hop after the loosely specified CR-LSP segment. Use of the LSPID Hop in this scenario eliminates the need for ER-Hops to keep the entire remaining ER-TLV at each LSR that is at either (upstream or downstream) end of a loosely specified CR-LSP segment as part of its state information. This is due to the fact that the upstream LSR needs only to keep the next ER-Hop and the LSPID and the downstream LSR needs only to keep the LSPID in order for each end to be able to recognize that the same LSP is being identified. In this it clearly states that it is not only the Ingress LER and the = LSRs in the path of this LSP but other LERs also need to know the LSP-ID = of different LSPs. The scenario is something like LER1 ------> LSR2-------->LSR3------>LSR4 = LER2-------->LSR5 there is an LSP setup as shown from LER1 thru LSR2,LSR3, LSR4. Now LER5 = receives a ER-TLV which says it has to make an LSP for which the next = hop is LSR3 and the already existing LSP with the LSP-ID is to be used. = Now the question is how does LSR5 or LER2 come to know about this = particular LSP-ID which actually originated at LER1? santosh santoshgupta@poboxes.com ----- Original Message -----=20 From: Sumit Garg=20 To: 'ashish'=20 Sent: Tuesday, March 28, 2000 3:49 A Subject: RE: CR-LDP Hi, =20 LSD-ID is a TLV defined by the CR-LDP draft. It is a combination of the = LSR-ID and a 2 octect number assigned by the ingress/ initiating LSR. = This would typically be an administor assigned/ monitored quantity and = thereof known a priori for LSP splicing/ tunneling. =20 The LSPID is propagated to downstream LSRs in the LSP setup request. =20 Regards Sumit =20 -----Original Message----- From: ashish [mailto:ashish@daewoo.dti.daewoo.co.kr] Sent: Monday, March 27, 2000 03:58 AM To: mpls@uu.net Subject: CR-LDP In CR-LDP draft-03, one of the ER-HOP TLV types contain LSPID field = that is used for tunneling thru some existing LSP having that LSPID = field. This means that that LSPID should be known in advance . How is that done. Does information regarding each LSP being created each having unique = LSPID is propagated to all LSR's. Please clarify. ------=_NextPart_000_000B_01BF989E.90F9ADC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Sumit
    The concerned section of CR-LDP draft is as = below.

4.7.4. ER-Hop 4: LSPID

The LSPID is used to identify the tunnel ingress = point as the=20 next
hop in the ER. This ER-Hop allows for stacking new = CR-LSPs=20 within an
already established CR-LSP. It also allows for = splicing the=20 CR-LSP
being established with an existing = CR-LSP.
If an LSPID Hop is the last ER-Hop in an ER-TLV, = than the LSR=20 may
splice the CR-LSP of the incoming Label Request to = the CR-LSP=20 that
currently exists with this LSPID. This is useful, = for example,=20 at
the point at which a Label Request used for local = repair=20 arrives at
the next ER-Hop after the loosely specified CR-LSP = segment.=20 Use of
the LSPID Hop in this scenario eliminates the need = for ER-Hops=20 to
keep the entire remaining ER-TLV at each LSR that is = at=20 either
(upstream or downstream) end of a loosely specified = CR-LSP=20 segment
as part of its state information. This is due to the = fact that=20 the
upstream LSR needs only to keep the next ER-Hop and = the LSPID=20 and
the downstream LSR needs only to keep the LSPID in = order for=20 each
end to be able to recognize that the same LSP is = being=20 identified.
 
In this it clearly states that it is not only the = Ingress LER=20 and the LSRs in the path of this LSP but other LERs also need to know = the LSP-ID=20 of different LSPs. The scenario is something like
 
            =    =20 LER1 ------>=20 LSR2-------->LSR3------>LSR4      &nb= sp;        =20
 
            =    =20 LER2-------->LSR5
 
there is an LSP setup as shown from LER1 thru LSR2,LSR3, LSR4. Now = LER5=20 receives a ER-TLV which says it has to make an LSP for which the next = hop is=20 LSR3 and the already existing LSP with the LSP-ID is to be used. Now the = question is how does LSR5 or LER2 come to know about this particular = LSP-ID=20 which actually originated at LER1?
 
santosh
 
santoshgupta@poboxes.com
 
 
----- Original Message -----=20
From: Sumit Garg=20
Sent: Tuesday, March 28, 2000 3:49 A
Subject: RE: CR-LDP

Hi,
 
LSD-ID is a TLV defined by the CR-LDP draft. = It is a=20 combination of the LSR-ID and a 2 octect number assigned by the ingress/ = initiating LSR. This would typically be an administor assigned/ = monitored=20 quantity and thereof known a priori for LSP splicing/=20 tunneling.
 
The LSPID is propagated to downstream LSRs in = the LSP=20 setup request.
 
Regards
Sumit
 
-----Original Message-----
From: ashish=20 [mailto:ashish@daewoo.dti.daewoo.co.kr]
Sent: Monday, March = 27, 2000=20 03:58 AM
To: mpls@uu.net
Subject:=20 CR-LDP

In CR-LDP draft-03, one of the ER-HOP = TLV types=20 contain LSPID field that is used for tunneling thru some existing LSP = having=20 that LSPID field.
This means that that LSPID should be = known in=20 advance .
How is that done.
Does information regarding each LSP = being created=20 each having unique LSPID is propagated to all LSR's.
Please=20 clarify.
------=_NextPart_000_000B_01BF989E.90F9ADC0-- From owner-mpls@UU.NET Mon Mar 27 23:51:28 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04223 for ; Mon, 27 Mar 2000 23:51:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiikp12497; Tue, 28 Mar 2000 04:51:29 GMT Received: by mail-control.mail.uu.net id QQiikp03854 for mpls-outgoing; Tue, 28 Mar 2000 04:51:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiikp03791 for ; Tue, 28 Mar 2000 04:51:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiikp05997 for ; Mon, 27 Mar 2000 23:50:49 -0500 (EST) Received: from hercules by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQiikp04024 for ; Tue, 28 Mar 2000 04:50:48 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id UAA12884; Mon, 27 Mar 2000 20:50:41 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 20:50:41 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A634685A@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Joan Cucchiara'" , "'tnadeau@cisco.com'" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" Subject: RE: LSR MIB comments and questions Date: Mon, 27 Mar 2000 20:50:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Joan, Thanks for your extensive comments. > * needs a table of contents We will try to put this in. > > * would be nice to have a revisions section to > track changes between versions, since this > has already been done on the email list, adding > it to the document should be trivial. No need for this, but when we issue the next rev based on the last-call comments, we will send the diff to the ML. > > * It seems that many tables in this MIB were gleaned > from the ATM MIB, specifically the mplsInterfaceConfTable > and the Cross Connect Tables. Could you add a > reference to the ATM MIB in the Reference Section? We can perhaps refer to it saying this MIB achieves for MPLS what ATOM MIB does for ATM (in some sense). Though LSR MIB is broader in scope. > > > > General MIB Comments > -------------------- > > * InterfaceIndex: understanding which InterfaceIndex > is being used is sometimes unclear. Since > this MIB handles all MPLS protocols, > the use of which InterfaceIndex and its > corresponding ifType and thus an indication of > where it would appear in the ifStackTable should > be clear, especially because many objects such > as InPacket, InDiscards, AdminStatus, OperStatus, etc > seem to me to potentially overlap with what is > in the ifTable and ifXTable for ifType mpls. > More description upfront would help with this. Will put descriptive text in the introduction section that depicts the MPLS interface stacked over a well-known interface. > > * StorageType objects need to be added throughout > various tables. Okay. > > > > FRONT SECTION > ------------- > > * Sections 8.0 'Application of the Interface Group to MPLS' > and 8.1 'Suport of the MPLS Layer by ifTable' > > "...Thus, the MPLS layer interface is represented as an entry in > the ifTable. This entry is concerned with the MPLS layer > as a whole, and not with individual LSPs/tunnels which are > managed via the MPLS-specific managed objects specified in this > memo and in [TEMIB]." The last sentence will be removed. We will also remove all references to TEMIB. 'Layer' here means the MPLS interface layer in interface stack. Adding general description (previous comment) will also add to clarity. > > I am confused by these statements. There is as of yet, no > concept of an MPLS Layer other than as outlined in the > architecture specification which talks about a shim layer. > > Is this the mpls shim layer (i.e. the layer where label > stacking takes place) or something else? No, See above comments. > > MIB > --- > * Revision history is incorrect. The > initial revision in June 1999. Will do. > > * ifIndex is not a textual convention Will do. > > * Last Updated clause is incorrect. The last > update should match the latest revision date > and these do not match. Okay. > > * MplsLsrIANAAddrFamily needs to be removed. > The AddressFamilyNumbers FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB > should be imported. See RFC2677 or LDP MIB. We are fixing this already based on some other comments. > > * MplsLabel needs to be updated to reflect the FRF decision > to drop 17-bit DLCI support. Also, missing REFERENCE for > 'MPLS using LDP and ATM VC Switching', draft-ietf-mpls-atm-02.txt. > (the LDP MIB has updated this and it would be good if we > could agree on a single definition for this TC.) Will remove DLCI size 17 from description. > > * IpV6Address -- ref. draft-ops-endpoint-mib-07.txt > Could you use similar IPv6 TCs as defined > in the draft-ops-endpoint-mib-07.txt MIB? > e.g. InetAddressIPv6 OCTET STRING (SIZE(16|20)) Will do. > > * In the MplsInterfaceConfTable a zero index for > mplsInterfaceConfIndex indicates that this entry > represents a global label space. There can also > be only one entry in the table which > contains a zero value for this index, correct? Yes. > > * Does the 'mplsInterfaceIsLocalLabelSpace' indicate > per interface label space only? > > I am confused why you need this object, it would > seem that if the value of mplsInterfaceConfIndex is > non-zero then this means that it is a per Interface > label space, and that the 'mplsInterfaceIsGlobalLabelSpace' > would indicate if it is participating in a global Label Space > also. Interfaces that have interface specific label space may also want to participate in global label space. The two objects, [...]LabelSpace, together enable that. > > Could a REFERENCE clause labels which are considered > both per interface and per platform be added to the > LocalLabelSpace Object? Will do. Section 3.14 of Arch. > > * Not sure that I understand the use of the MIN and MAX > IN/OUT labels. How does this relate to LDP which uses > an ATM-type interface (and thus has a bunch of label ranges)? > > Are these MIN/MAX values a proper superset of label ranges > on a per interface label space? Yes. > > * Total and Available Buffer. What is it that is supposed > to be learned from these values? This was added because of a few requests. I personally think this is not very useful information. Perhaps having available BW per priority level will be more useful. > > > * mplsInterfaceAdminStatus and mplsInterfaceOperStatus > why are these necessary? It seems like ifAdminStatus > and ifOperStatus should be used for this. Vestiges. Will throw them out. > > > * mplsInterfacePerfEntry is said to Augment the > mplsInterfaceConfEntry, what happens for the > situation when 'mplsInterfaceConfIndex' is zero? > > How are the values in this table counted when a label > participates in both the global and local label spaces? I assume you meant to ask a interface participates in both local and global label space. The counters are for basically the actual interfaces and should count for both types of labels (local as well as global). In addition, LSRs MAY count for global labels separately. Will add more text in the description to make this clear. > > Also, it seems that some of these overlap with > ifTable (specifically, mplsInterfaceInPackets, > mplsInterfaceInDiscards, mplsInterfaceOutPackets, > mplsInterfaceOutDiscards), maybe I am missing something > here, but on an mplsInterface, I would assume that the > ifTable and ifXTable would be counting Octets and Packets > which are in essence MPLS Octets and Packets. Vestiges. Will remove them. > > Could you add in the description something > which would differentiate these from the ifTable and > ifXTable at the mpls layer? See above comment. > > (Aside: because the front section of the document > includes how to interpret the ifTable and ifXTable > objects, I am under the assumption that these things > are being counted in those tables and not here....) > > * mplsInSegmentTable has no "IndexNext" object. > Could one be added? I think we can add that. > > * mplsInSegmentIfIndex type in Sequence doesn't match > Object's type. > > Also this should be not-accessible. Currently, it is > read-create. What is the ifType of this index? We caught this with the SMIC compiler. > Is this the same as the index used in the mplsInterfaceConfEntry > for the label related to this entry? Yes. > > Could more description be added to this index? Okay. > > * mplsInSegmentAddrFamily needs to use the > IANA-ADDRESS-FAMILY-NUMBER-MIB's AddressFamilyNumbers TC. > Reference is incorrect on this also. Will do. > > * mplsInSegmentXCIndex description is incorrect. A value > of zero could certainly indicates a valid cross connect. > The XC table does model XCs even for terminating InSegments > and Originating OutSegments. > > The syntax clause should be changed in either this > table or in the XC table since the syntax should be > the same in both places. We meant it to be this way, that is, 0 is not a valid XC index. 0 is used to indicate that the XC entries have exhausted. > > * mplsInSegmentTSpecIndex -- this object needs to be made > optional for LDP. Is already optional. A value of zero to indicate best effort. See description. > > * mplsInSegmentOwner -- could this be removed from the > table. > > These object are of little value in my opinion because > who really cares how the row got created? > > Also, if you have snmp and policyAgent, then you should > add cli, config file, web, etc.... > > Just seems to be a big rat hole in my opinion. If you don't want to identify yourself, you can choose the 'other' option ;-) It is there because folks asked for it. It provides tracking for usage information, for troubleshooting, and erroneous deletion by somebody how did not create it in the first place. > > * mplsOutSegmentIndexNext object range should start at 0 (zero). No. 0 is bad index; is used to identify terminating connections in the cross-connect. > > * mplsOutSegmentEntry is incorrect and should say 'outgoing' > in place of incoming which I think someone else mentioned > already. Evils of cut-and-paste. > > Also REF clause should be updated Will be removed and description adjusted. > > * mplsOutSegmentIfIndex should be not-accessible Hmmm..I guess so. > > * mplsOutSegmentPushTopLabel's description is > somewhat misleading with regard to the current > version of LDP. In the case of LDP using ATM, the > idea of a label popping does not apply. So it's > misleading to say, it does not support pop-and-go. > It does not support label popping at all. A label swapping is modelled as a pop followed by a push. See mplsInSegmentNPop. The description also talks about the ATM case. > > Could you rephrase this section to specifically > call out that for Version 1 of LDP using ATM or FR this should > be set to true and Reference Section 5. of the LDP Spec? I don't think we need to specially qualify LDP for this. This is common to any protocol on ATM. > > * mplsOutSegmentTopLabel > > Could this object be changed to contain the value of > the top label on egress? I think it would be > much more interesting to point to the egress label > especially since the prior object (mplsOutSegmentPushTopLabel) > tells whether or not this was pushed. Hmm..I guess I don't understand the comment. It already is what you are asking it to be. > > * mplsOutSegmentNextHopIpAddrType should use similar > TC's as defined in draft-ops-endpoint-mib-07.txt Done. > > Also, I have a question on this description: What is > meant by the outgoing interface being point-to-point in > the case of LDP using ATM? That is, 'none' is not a valid choice for any multi-access network. > > * mplsOutSegmentNextHopIpv4Addr and mplsOutSegmentNextHopIpv6Addr > these should be combined, and should also use the relevant > TC in draft-ops-endpoint-mib-07.txt Yes. > > * mplsXCIndexNext object's range should start at 0. It is alright the way it is. 0 is reserved to indicate "no more cross-connect entries available". > > * INDEX clause and description of the entry: > > The description redefines what a values of zero means > for the mplsInSegmentIfIndex and mplsInSegmentLabel; > in the mplsInSegmentTable they mean one thing, > and yet, they mean something else in the XC table. > Yes, they are different tables. Index zero is valid only for the InSegemntTable. > > * mplsXCIndex should be not-accessible Okay. > > * mplsXCCOS, should this object be made optional for > LDP? Will remove this object based on comments on ML. > > * mplsXCIsPersistent should have SYNTAX of StorageType Okay. > > * mplsXCOwner same comment as before, big rat hole, could > we get rid of this object? No, see comments above. > > * What do the AdminStatus and OperStatus objects mean when > the LSP is terminating or Originating for this entry? > Admin status is provided to control the cross-connect from passing data. Oper status may reflect the overall health of the cross-connect, for example, if the outgoing interface is down, then the cross-connect oper status may reflect that. -arun From owner-mpls@UU.NET Tue Mar 28 00:08:31 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04388 for ; Tue, 28 Mar 2000 00:08:31 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiikq21758; Tue, 28 Mar 2000 05:08:31 GMT Received: by mail-control.mail.uu.net id QQiikq12539 for mpls-outgoing; Tue, 28 Mar 2000 05:08:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiikq12534 for ; Tue, 28 Mar 2000 05:08:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiikq07685 for ; Tue, 28 Mar 2000 00:07:53 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiikq12813 for ; Tue, 28 Mar 2000 05:07:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA12333 for mpls@uu.net; Tue, 28 Mar 2000 00:07:51 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiikq12519 for ; Tue, 28 Mar 2000 05:07:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiikq21757 for ; Tue, 28 Mar 2000 00:06:58 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQiikq20912 for ; Tue, 28 Mar 2000 05:06:57 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id IAA22308; Tue, 28 Mar 2000 08:06:57 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14560.15856.901737.602824@lohi.eng.telia.fi> Date: Tue, 28 Mar 2000 08:06:56 +0300 (EEST) To: mpls@UU.NET Subject: tspec table In-Reply-To: <0F8929E5ED5FD311B892005004CED4A634685A@tonga.ncorenetworks.com> References: <0F8929E5ED5FD311B892005004CED4A634685A@tonga.ncorenetworks.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit in the lsr mib, tspec table only supports intserv style traffic parameters and thus sort of assumes that the lsp was set up using rsvp. cr-ldp has another set of traffic parameters. shall we add another optional table, e.g., mlpsTrafficTable, that includes cr-ldp traffic parameters or how do you want to handle this? -- juha ps. why is the mib called lsr rather than mlps node mib, since i haven't found in it anything that releates to forwarding of layer 3 packets? From owner-mpls@UU.NET Tue Mar 28 00:19:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04437 for ; Tue, 28 Mar 2000 00:19:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiikr19210; Tue, 28 Mar 2000 05:19:32 GMT Received: by mail-control.mail.uu.net id QQiikr13281 for mpls-outgoing; Tue, 28 Mar 2000 05:19:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiikr13276 for ; Tue, 28 Mar 2000 05:19:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiikr08661 for ; Tue, 28 Mar 2000 00:19:05 -0500 (EST) Received: from hercules by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQiikr18877 for ; Tue, 28 Mar 2000 05:19:05 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id VAA14242; Mon, 27 Mar 2000 21:19:01 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 21:19:01 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A634685B@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Cucchiara, Joan'" , "'tnadeau@cisco.com'" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" Subject: RE: Additional comments on the LSR MIB Date: Mon, 27 Mar 2000 21:18:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Joan, > * mplsLabelStackIndexNext is an Unsigned32 and > the mplsLabelStackIndex is Integer32. One of > these should be changed. Done. > > * mplsLabelStackIndex should have MAX-ACCESS of > not-accessible. Will do based on your previous comment. > > * The mplsLabelStackTable should be made optional for LDP LSPs > which use ATM or FR. Could this be added in > the conformance section? It already supports non-stackable environments. > > * mplsTSpecIndexNext should start at zero. See description of mplsTSpecIndexNext. > > * mplsTSpecMeanRate -- what is the agent or mpls > supposed to do with this value? > > Is the mean rate for an LSP calculated over time? No. This is one of the tuple for defining a token bucket. The agent has to ensure that the specified QoS requirement for the LSP is met. > > * mplsTSpecMaxRate and mplsTSpecMaxBurstSize: are > these objects related? If so, could an explanation > be given of how they are related? Can the BurstSize > exceed the MaxRate? What does it mean if this happens? See above comments. > > * Is this table going to be made optional for LDP? See my comments to your previous set of comments. > > * Could we have a description of what happens when the > InSegment TSpec values are lower than the OutSegment > TSpec values? (Seems like there should be some > co-operation between the objects, or at least some > "actual" objects which reflect what the true values > are.) The implication of such things may be platform specific. > > Why does one need to specify the TSpec for the > InSegment? It would seem that the OutSegment is > relevant and that the InSegment is not really > configurable, could you explain why it is needed > for the InSegment? Multipoint-to-point LSPs. > > * Could the individual trap enable/disable objects be placed near > their respective information? (NOTE: they are grouped > differently in the conformance section which is more where > you would expect the objects to be in the MIB.) Will consider. > > * In general, the MIB heirarchy could use some heirarchy :) > Seems like everything is under 'mplsLsrObjects'. Will fix that. > > * In general, the Index objects which have MIN-ACCESS of read-only > should be fixed in the mib to have not-accessible access and > removed from the Conformance section. If this is the general approach in other MIBs, will do so. > > * The conformance information for the following object > is worrisome because it is not clear under which circumstances > one would not support all the enums. > > OBJECT mplsInSegmentAddrFamily > SYNTAX INTEGER { other(0) } > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required. A value of > other(0) should be supported." > > If the agent can't tell or doesn't know what the Address Family > is, then how are all the counters effected (specifically > packet and octet counters) that are related to this > InSegment on an MPLS Interface? Addr family if for the MPLS payload. Counters are for MPLS 'frames'. MPLS counters may go up independent of payload type. > > OBJECT mplsOutSegmentIndexNext > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT mplsXCIndexNext > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT mplsXCLabelStackIndexNext > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > The above already have a MAX-ACCESS of read-only. > > -arun From owner-mpls@UU.NET Tue Mar 28 00:24:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04504 for ; Tue, 28 Mar 2000 00:24:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiikr00092; Tue, 28 Mar 2000 05:24:02 GMT Received: by mail-control.mail.uu.net id QQiikr13593 for mpls-outgoing; Tue, 28 Mar 2000 05:23:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiikr13587 for ; Tue, 28 Mar 2000 05:23:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiikr23194 for ; Tue, 28 Mar 2000 00:23:27 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiikr21547 for ; Tue, 28 Mar 2000 05:23:26 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA14573 for mpls@uu.net; Tue, 28 Mar 2000 00:23:25 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiikr13574 for ; Tue, 28 Mar 2000 05:23:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiikr09094 for ; Tue, 28 Mar 2000 00:22:50 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQiikr21223 for ; Tue, 28 Mar 2000 05:22:49 GMT Received: from tnadeau-pc02 (ch-janeiro-p15.cisco.com [171.69.209.219]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA13533; Tue, 28 Mar 2000 00:22:10 -0500 (EST) Message-Id: <4.2.2.20000328000603.070e57b0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 28 Mar 2000 00:11:56 -0500 To: Juha Heinanen , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: tspec table Cc: Arun Viswanathan , cheenu@tachion.com In-Reply-To: <14560.15856.901737.602824@lohi.eng.telia.fi> References: <0F8929E5ED5FD311B892005004CED4A634685A@tonga.ncorenetworks.com> <0F8929E5ED5FD311B892005004CED4A634685A@tonga.ncorenetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1647359==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_1647359==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, >in the lsr mib, tspec table only supports intserv style traffic >parameters and thus sort of assumes that the lsp was set up using rsvp. >cr-ldp has another set of traffic parameters. shall we add another >optional table, e.g., mlpsTrafficTable, that includes cr-ldp traffic >parameters or how do you want to handle this? Please be more specific as to how the cr-ldp parameters differ from those currently in the MIB. Please give specific examples. >ps. why is the mib called lsr rather than mlps node mib, since i haven't >found in it anything that releates to forwarding of layer 3 packets? The LSR-MIB models how labels are swapped (among other things), which is why I believe that name was chosen. With the MIB currently in WG Last Call, I do not believe that we will be changing its name at the 11th hour. --Tom --=====================_1647359==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

in the lsr mib, tspec table only supports intserv style traffic
parameters and thus sort of assumes that the lsp was set up using rsvp.
cr-ldp has another set of traffic parameters.  shall we add another
optional table, e.g., mlpsTrafficTable, that includes cr-ldp traffic
parameters or how do you want to handle this?

        Please be more specific as to how the cr-ldp
parameters differ from those currently in the MIB.
Please give specific examples.
        
ps. why is the mib called lsr rather than mlps node mib, since i haven't
found in it anything that releates to forwarding of layer 3 packets?

        The LSR-MIB models how labels are swapped (among
other things), which is why I believe that name was
chosen. With the MIB currently in WG Last Call, I do not
believe that we will be changing its name at the 11th
hour.

        --Tom

--=====================_1647359==_.ALT-- From owner-mpls@UU.NET Tue Mar 28 00:38:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04666 for ; Tue, 28 Mar 2000 00:38:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiks08023; Tue, 28 Mar 2000 05:38:32 GMT Received: by mail-control.mail.uu.net id QQiiks14152 for mpls-outgoing; Tue, 28 Mar 2000 05:38:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiks14147 for ; Tue, 28 Mar 2000 05:38:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiks10590 for ; Tue, 28 Mar 2000 00:38:01 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQiiks29201 for ; Tue, 28 Mar 2000 05:37:45 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id LAA03218 for ; Tue, 28 Mar 2000 11:04:03 -0600 (GMT) Message-ID: <003301bf9878$637b84c0$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Subject: LDP MIB Date: Tue, 28 Mar 2000 11:12:21 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01BF98A6.7D0A8DE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0030_01BF98A6.7D0A8DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20 In draft-ietf-mpls-ldp-mib-02.txt there are references to = "GlobalLabelSpace" and "PlatformLabelSpace". Could anyone help me out as = to what they mean? Thanx in advance.=20 santosh santoshgupta@poboxes.com ------=_NextPart_000_0030_01BF98A6.7D0A8DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
    In draft-ietf-mpls-ldp-mib-02.txt there are = references=20 to "GlobalLabelSpace" and "PlatformLabelSpace". Could anyone help me = out as=20 to what they mean?
Thanx in advance. 
santosh
 
santoshgupta@poboxes.com ------=_NextPart_000_0030_01BF98A6.7D0A8DE0-- From owner-mpls@UU.NET Tue Mar 28 00:43:25 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04765 for ; Tue, 28 Mar 2000 00:43:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiks02259; Tue, 28 Mar 2000 05:43:25 GMT Received: by mail-control.mail.uu.net id QQiiks14527 for mpls-outgoing; Tue, 28 Mar 2000 05:43:02 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiiks14520 for ; Tue, 28 Mar 2000 05:42:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiks25093 for ; Tue, 28 Mar 2000 00:42:51 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiiks01863 for ; Tue, 28 Mar 2000 05:42:50 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA17267 for mpls@uu.net; Tue, 28 Mar 2000 00:42:50 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiks14444 for ; Tue, 28 Mar 2000 05:42:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiks10928 for ; Tue, 28 Mar 2000 00:42:14 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQiiks01443 for ; Tue, 28 Mar 2000 05:42:13 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id IAA22384; Tue, 28 Mar 2000 08:41:54 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14560.17954.729658.34134@lohi.eng.telia.fi> Date: Tue, 28 Mar 2000 08:41:54 +0300 (EEST) To: "Thomas D. Nadeau" Cc: mpls@UU.NET, Arun Viswanathan , cheenu@tachion.com Subject: Re: tspec table In-Reply-To: <4.2.2.20000328000603.070e57b0@funnel.cisco.com> References: <0F8929E5ED5FD311B892005004CED4A634685A@tonga.ncorenetworks.com> <4.2.2.20000328000603.070e57b0@funnel.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thomas D. Nadeau writes: > Please be more specific as to how the cr-ldp > parameters differ from those currently in the MIB. > Please give specific examples. cr-ldp has the following traffic parameters: - frequency - peak data rate (same as mplsTSpecMaxRate) - peak burst size - committed data rate (same as mplsTSpecMeanRate) - committed burst size (same as mplsTSpecMaxBurstSize) - excess burst size so it appears that cr-ldp traffic parameters are a superset of rsvp traffic parameters and we might be able to solve the problem by renaming the current table and parameters using generci names and by adding the missing three parameters. > The LSR-MIB models how labels are swapped (among > other things), which is why I believe that name was > chosen. With the MIB currently in WG Last Call, I do not > believe that we will be changing its name at the 11th > hour. according to the terminology section of the architecture i-d, mpls node is a node that is dealing with labeled packets and can POSSIBLY also forward l3 packets, whereas lrs is an mpls node that also does forward l3 packets. that is why i would consider the mpls node mib a more appropriate name for the i-d. -- juha From owner-mpls@UU.NET Tue Mar 28 02:36:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17601 for ; Tue, 28 Mar 2000 02:36:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiila09734; Tue, 28 Mar 2000 07:36:25 GMT Received: by mail-control.mail.uu.net id QQiila05820 for mpls-outgoing; Tue, 28 Mar 2000 07:36:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiila05783 for ; Tue, 28 Mar 2000 07:36:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiila05475 for ; Tue, 28 Mar 2000 02:35:57 -0500 (EST) From: ajithn@sg.ibm.com Received: from ausmtp01.au.ibm.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ausmtp01.au.ibm.COM [202.135.136.97]) id QQiila09154 for ; Tue, 28 Mar 2000 07:35:22 GMT Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id RAA112340; Tue, 28 Mar 2000 17:30:20 +1000 Received: from d73mta04.au.ibm.com (f06n04s [9.185.166.98]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id RAA18366; Tue, 28 Mar 2000 17:31:20 +1000 Received: by d73mta04.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568B0.00294E5A ; Tue, 28 Mar 2000 17:31:10 +1000 X-Lotus-FromDomain: IBMSG@IBMAU To: "Santosh Gupta" cc: sumitg@rocketmail.com, "Ashish Monga" , mpls@UU.NET Message-ID: Date: Tue, 28 Mar 2000 15:33:15 +0800 Subject: Re: CR-LDP Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=v6I4cEN3qlFFgMYqaxnrwgxlSqE4IujRoNHqL8aBYIaEGHfzpCU47Nak" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk --0__=v6I4cEN3qlFFgMYqaxnrwgxlSqE4IujRoNHqL8aBYIaEGHfzpCU47Nak Content-type: text/plain; charset=us-ascii Content-Disposition: inline LSP-IDs become part of the "traffic engineering state" of the network. So it is legitimate to define a CR-LSP, whose ingress is LER2, stacking or splicing with an existing CR-LSP whose ingress is LER1, the latter being specified by its LSP-ID. The entity which does traffic engineering can be thought of as "higher" than the LSR, and it knows these LSP-IDs. At that level, there is global (or, supra-local) knowledge. However, from the point of view of LSRs, local knowledge is sufficient. LSRs need to know only the LSP-IDs they participate in. In your example, LER2 and LSR5 do not need to know the spliced/stacked CR-LSP's LSP-ID because all they do with it is, just pass it downward. That remains true as we go down the request path till we hit LSR3, for which it is intended. So there is no need for non-participating LSRs to be aware of the LSP-ID. -- Ajith -- "Santosh Gupta" on 03/28/2000 12:45:39 PM Please respond to "Santosh Gupta" To: sumitg@rocketmail.com, mpls@UU.NET cc: "Ashish Monga" (bcc: Ajith Narayanan/Singapore/IBM) Subject: Re: CR-LDP Hi Sumit The concerned section of CR-LDP draft is as below. 4.7.4. ER-Hop 4: LSPID The LSPID is used to identify the tunnel ingress point as the next hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an already established CR-LSP. It also allows for splicing the CR-LSP being established with an existing CR-LSP. If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may splice the CR-LSP of the incoming Label Request to the CR-LSP that currently exists with this LSPID. This is useful, for example, at the point at which a Label Request used for local repair arrives at the next ER-Hop after the loosely specified CR-LSP segment. Use of the LSPID Hop in this scenario eliminates the need for ER-Hops to keep the entire remaining ER-TLV at each LSR that is at either (upstream or downstream) end of a loosely specified CR-LSP segment as part of its state information. This is due to the fact that the upstream LSR needs only to keep the next ER-Hop and the LSPID and the downstream LSR needs only to keep the LSPID in order for each end to be able to recognize that the same LSP is being identified. In this it clearly states that it is not only the Ingress LER and the LSRs in the path of this LSP but other LERs also need to know the LSP-ID of different LSPs. The scenario is something like LER1 ------> LSR2-------->LSR3------>LSR4 LER2-------->LSR5 there is an LSP setup as shown from LER1 thru LSR2,LSR3, LSR4. Now LER5 receives a ER-TLV which says it has to make an LSP for which the next hop is LSR3 and the already existing LSP with the LSP-ID is to be used. Now the question is how does LSR5 or LER2 come to know about this particular LSP-ID which actually originated at LER1? santosh santoshgupta@poboxes.com ----- Original Message ----- From: Sumit Garg To: 'ashish' Sent: Tuesday, March 28, 2000 3:49 A Subject: RE: CR-LDP Hi, LSD-ID is a TLV defined by the CR-LDP draft. It is a combination of the LSR-ID and a 2 octect number assigned by the ingress/ initiating LSR. This would typically be an administor assigned/ monitored quantity and thereof known a priori for LSP splicing/ tunneling. The LSPID is propagated to downstream LSRs in the LSP setup request. Regards Sumit -----Original Message----- From: ashish [mailto:ashish@daewoo.dti.daewoo.co.kr] Sent: Monday, March 27, 2000 03:58 AM To: mpls@uu.net Subject: CR-LDP In CR-LDP draft-03, one of the ER-HOP TLV types contain LSPID field that is used for tunneling thru some existing LSP having that LSPID field. This means that that LSPID should be known in advance . How is that done. Does information regarding each LSP being created each having unique LSPID is propagated to all LSR's. Please clarify. --0__=v6I4cEN3qlFFgMYqaxnrwgxlSqE4IujRoNHqL8aBYIaEGHfzpCU47Nak Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjMxNC4xMDAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj5IaSBTdW1pdDwvRElWPg0KPERJVj4mbmJz cDsmbmJzcDsmbmJzcDsgVGhlIGNvbmNlcm5lZCBzZWN0aW9uIG9mIENSLUxEUCBkcmFmdCBpcyBh cyBiZWxvdy48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPFA+NC43LjQuIEVSLUhvcCA0OiBM U1BJRDwvUD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoZSBMU1BJRCBpcyB1c2VkIHRvIGlk ZW50aWZ5IHRoZSB0dW5uZWwgaW5ncmVzcyBwb2ludCBhcyB0aGUgDQpuZXh0PC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+aG9wIGluIHRoZSBFUi4gVGhpcyBFUi1Ib3AgYWxsb3dzIGZv ciBzdGFja2luZyBuZXcgQ1ItTFNQcyANCndpdGhpbiBhbjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPmFscmVhZHkgZXN0YWJsaXNoZWQgQ1ItTFNQLiBJdCBhbHNvIGFsbG93cyBmb3Ig c3BsaWNpbmcgdGhlIA0KQ1ItTFNQPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YmVp bmcgZXN0YWJsaXNoZWQgd2l0aCBhbiBleGlzdGluZyBDUi1MU1AuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+SWYgYW4gTFNQSUQgSG9wIGlzIHRoZSBsYXN0IEVSLUhvcCBpbiBhbiBF Ui1UTFYsIHRoYW4gdGhlIExTUiANCm1heTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PnNwbGljZSB0aGUgQ1ItTFNQIG9mIHRoZSBpbmNvbWluZyBMYWJlbCBSZXF1ZXN0IHRvIHRoZSBD Ui1MU1AgDQp0aGF0PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Y3VycmVudGx5IGV4 aXN0cyB3aXRoIHRoaXMgTFNQSUQuIFRoaXMgaXMgdXNlZnVsLCBmb3IgZXhhbXBsZSwgDQphdDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnRoZSBwb2ludCBhdCB3aGljaCBhIExhYmVs IFJlcXVlc3QgdXNlZCBmb3IgbG9jYWwgcmVwYWlyIA0KYXJyaXZlcyBhdDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPnRoZSBuZXh0IEVSLUhvcCBhZnRlciB0aGUgbG9vc2VseSBzcGVj aWZpZWQgQ1ItTFNQIHNlZ21lbnQuIA0KVXNlIG9mPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+dGhlIExTUElEIEhvcCBpbiB0aGlzIHNjZW5hcmlvIGVsaW1pbmF0ZXMgdGhlIG5lZWQg Zm9yIEVSLUhvcHMgDQp0bzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmtlZXAgdGhl IGVudGlyZSByZW1haW5pbmcgRVItVExWIGF0IGVhY2ggTFNSIHRoYXQgaXMgYXQgDQplaXRoZXI8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4odXBzdHJlYW0gb3IgZG93bnN0cmVhbSkg ZW5kIG9mIGEgbG9vc2VseSBzcGVjaWZpZWQgQ1ItTFNQIA0Kc2VnbWVudDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPmFzIHBhcnQgb2YgaXRzIHN0YXRlIGluZm9ybWF0aW9uLiBUaGlz IGlzIGR1ZSB0byB0aGUgZmFjdCB0aGF0IA0KdGhlPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+dXBzdHJlYW0gTFNSIG5lZWRzIG9ubHkgdG8ga2VlcCB0aGUgbmV4dCBFUi1Ib3AgYW5k IHRoZSBMU1BJRCANCmFuZDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnRoZSBkb3du c3RyZWFtIExTUiBuZWVkcyBvbmx5IHRvIGtlZXAgdGhlIExTUElEIGluIG9yZGVyIGZvciANCmVh Y2g8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5lbmQgdG8gYmUgYWJsZSB0byByZWNv Z25pemUgdGhhdCB0aGUgc2FtZSBMU1AgaXMgYmVpbmcgDQppZGVudGlmaWVkLjwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JbiB0aGlzIGl0IGNsZWFy bHkgc3RhdGVzIHRoYXQgaXQgaXMgbm90IG9ubHkgdGhlIEluZ3Jlc3MgTEVSIA0KYW5kIHRoZSBM U1JzIGluIHRoZSBwYXRoIG9mIHRoaXMgTFNQIGJ1dCBvdGhlciBMRVJzIGFsc28gbmVlZCB0byBr bm93IHRoZSBMU1AtSUQgDQpvZiBkaWZmZXJlbnQgTFNQcy4gVGhlIHNjZW5hcmlvIGlzIHNvbWV0 aGluZyBsaWtlPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7IA0KTEVSMSAtLS0tLS0mZ3Q7IA0KTFNSMi0tLS0tLS0tJmd0O0xTUjMtLS0tLS0m Z3Q7TFNSNCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KTEVSMi0tLS0tLS0tJmd0O0xT UjU8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPnRoZXJlIGlzIGFuIExTUCBzZXR1cCBh cyBzaG93biBmcm9tIExFUjEgdGhydSBMU1IyLExTUjMsIExTUjQuIE5vdyBMRVI1IA0KcmVjZWl2 ZXMgYSBFUi1UTFYgd2hpY2ggc2F5cyBpdCBoYXMgdG8gbWFrZSBhbiAgTFNQIGZvciB3aGljaCB0 aGUgbmV4dCBob3AgaXMgDQpMU1IzIGFuZCB0aGUgYWxyZWFkeSBleGlzdGluZyBMU1Agd2l0aCB0 aGUgTFNQLUlEIGlzIHRvIGJlIHVzZWQuIE5vdyB0aGUgDQpxdWVzdGlvbiBpcyBob3cgZG9lcyBM U1I1IG9yIExFUjIgY29tZSB0byBrbm93IGFib3V0IHRoaXMgcGFydGljdWxhciBMU1AtSUQgDQp3 aGljaCBhY3R1YWxseSBvcmlnaW5hdGVkIGF0IExFUjE/PC9ESVY+PC9GT05UPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+c2FudG9zaDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEEg DQpocmVmPSJtYWlsdG86c2FudG9zaGd1cHRhQHBvYm94ZXMuY29tIj5zYW50b3NoZ3VwdGFAcG9i b3hlcy5jb208L0E+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj4tLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgZm9udC1jb2xvcjog YmxhY2siPjxCPkZyb206PC9CPiA8QSANCmhyZWY9Im1haWx0bzpzdW1pdGdAcm9ja2V0bWFpbC5j b20iIHRpdGxlPXN1bWl0Z0Byb2NrZXRtYWlsLmNvbT5TdW1pdCBHYXJnPC9BPiANCjwvRElWPg0K PERJVj48Qj5Ubzo8L0I+IDxBIGhyZWY9Im1haWx0bzphc2hpc2hAZGFld29vLmR0aS5kYWV3b28u Y28ua3IiIA0KdGl0bGU9YXNoaXNoQGRhZXdvby5kdGkuZGFld29vLmNvLmtyPidhc2hpc2gnPC9B PiA8L0RJVj4NCjxESVY+PEI+U2VudDo8L0I+IFR1ZXNkYXksIE1hcmNoIDI4LCAyMDAwIDM6NDkg QTwvRElWPg0KPERJVj48Qj5TdWJqZWN0OjwvQj4gUkU6IENSLUxEUDwvRElWPjwvRElWPg0KPERJ Vj48QlI+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT0iQ291cmllciBOZXci IHNpemU9Mj48U1BBTiANCmNsYXNzPTAzMDExMjAyMi0yNzAzMjAwMD5IaSw8L1NQQU4+PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXpl PTI+PFNQQU4gDQpjbGFzcz0wMzAxMTIwMjItMjcwMzIwMDA+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0y PjxTUEFOIA0KY2xhc3M9MDMwMTEyMDIyLTI3MDMyMDAwPkxTRC1JRCBpcyBhIFRMViBkZWZpbmVk IGJ5IHRoZSBDUi1MRFAgZHJhZnQuIEl0IGlzIGEgDQpjb21iaW5hdGlvbiBvZiB0aGUgTFNSLUlE IGFuZCBhIDIgb2N0ZWN0IG51bWJlciBhc3NpZ25lZCBieSB0aGUgaW5ncmVzcy8gDQppbml0aWF0 aW5nIExTUi4gVGhpcyB3b3VsZCB0eXBpY2FsbHkgYmUgYW4gYWRtaW5pc3RvciBhc3NpZ25lZC8g bW9uaXRvcmVkIA0KcXVhbnRpdHkgYW5kIHRoZXJlb2Yga25vd24gYSBwcmlvcmkgZm9yIExTUCBz cGxpY2luZy8gDQp0dW5uZWxpbmcuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29s b3I9IzAwMDBmZiBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MDMwMTEy MDIyLTI3MDMyMDAwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9y PSMwMDAwZmYgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCmNsYXNzPTAzMDExMjAy Mi0yNzAzMjAwMD5UaGUgTFNQSUQgaXMgcHJvcGFnYXRlZCB0byBkb3duc3RyZWFtIExTUnMgaW4g dGhlIExTUCANCnNldHVwIHJlcXVlc3QuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg Y29sb3I9IzAwMDBmZiBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MDMw MTEyMDIyLTI3MDMyMDAwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNv bG9yPSMwMDAwZmYgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCmNsYXNzPTAzMDEx MjAyMi0yNzAzMjAwMD5SZWdhcmRzPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29s b3I9IzAwMDBmZiBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MDMwMTEy MDIyLTI3MDMyMDAwPlN1bWl0PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9 IzAwMDBmZiBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MDMwMTEyMDIy LTI3MDMyMDAwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxl PSJCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJ Ti1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweCI+DQogIDxESVYgYWxpZ249bGVmdCBjbGFz cz1PdXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRyPjxGT05UIGZhY2U9VGFob21hIA0KICBzaXpl PTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IGFzaGlzaCANCiAg W21haWx0bzphc2hpc2hAZGFld29vLmR0aS5kYWV3b28uY28ua3JdPEJSPjxCPlNlbnQ6PC9CPiBN b25kYXksIE1hcmNoIDI3LCAyMDAwIA0KICAwMzo1OCBBTTxCUj48Qj5Ubzo8L0I+IG1wbHNAdXUu bmV0PEJSPjxCPlN1YmplY3Q6PC9CPiANCiAgQ1ItTERQPEJSPjxCUj48L0RJVj48L0ZPTlQ+DQog IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SW4gQ1ItTERQIGRyYWZ0LTAzLCBvbmUgb2Yg dGhlIEVSLUhPUCBUTFYgdHlwZXMgDQogIGNvbnRhaW4gTFNQSUQgZmllbGQgdGhhdCBpcyB1c2Vk IGZvciB0dW5uZWxpbmcgdGhydSBzb21lIGV4aXN0aW5nIExTUCBoYXZpbmcgDQogIHRoYXQgTFNQ SUQgZmllbGQuPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlRo aXMgbWVhbnMgdGhhdCB0aGF0IExTUElEIHNob3VsZCBiZSBrbm93biBpbiANCiAgYWR2YW5jZSAu PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhvdyBpcyB0aGF0 IGRvbmUuPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkRvZXMg aW5mb3JtYXRpb24gcmVnYXJkaW5nIGVhY2ggTFNQIGJlaW5nIGNyZWF0ZWQgDQogIGVhY2ggaGF2 aW5nIHVuaXF1ZSBMU1BJRCBpcyBwcm9wYWdhdGVkIHRvIGFsbCBMU1Incy48L0ZPTlQ+PC9ESVY+ DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+UGxlYXNlIA0KY2xhcmlmeS48L0ZPTlQ+ PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --0__=v6I4cEN3qlFFgMYqaxnrwgxlSqE4IujRoNHqL8aBYIaEGHfzpCU47Nak-- From owner-mpls@UU.NET Tue Mar 28 03:11:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18006 for ; Tue, 28 Mar 2000 03:11:12 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiilc27594; Tue, 28 Mar 2000 08:11:14 GMT Received: by mail-control.mail.uu.net id QQiilc15668 for mpls-outgoing; Tue, 28 Mar 2000 08:10:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiilc15657 for ; Tue, 28 Mar 2000 08:10:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiilc08261 for ; Tue, 28 Mar 2000 03:10:03 -0500 (EST) Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQiilc18969 for ; Tue, 28 Mar 2000 08:10:02 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 00:09:51 -0800 Message-ID: From: Vijay Srinivasan To: "'mpls@uu.net'" Subject: Updated charter Date: Tue, 28 Mar 2000 00:09:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF988C.FDD74450" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF988C.FDD74450 Content-Type: text/plain; charset="iso-8859-1" Hi folks, Here is the updated charter based on comments to the mailing list, as well as feedback received from attendees at the Adelaide IETF. We will discuss this charter at the second MPLS session on Wedneday. The main changes are to add the following wording to the charter statement: "The working group will extend the concept of label switching to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming fiber to outgoing fiber)." and to remove references to optical crossconnects. Regarding Loa Andersson's comment: " 1. The charter says that the WG should co-ordinate the work with other organizations "such as OIF, ITU-T, ANSI, ODSI etc." I've the feeling that the list is a bit random. There could be other organizations that should be on that list, what about MSF? This is minor. I'm more concerned about the "coordintion/cooperation", what mandated does it vest on who and on behalf of whom? I've a feeling that there might be legal (US legal :-) aspects here." we would like to reiterate that if a formal liaison is required with a particular standards body, the IAB will be contacted to set one up. The above list is by no means intended to be comprehensive. Regards, MPLS WG Chairs ------------------------------------------------- Multiprotocol Label Switching (mpls) Charter Problem Statement: Label switching in conjunction with network layer routing has emerged as an important new technology. It is actively being applied to applications such as traffic engineering and virtual private networks. Among the problems this technology is expected to address are the following: 1. Greater flexibility in delivering routing services Using labels to identify particular traffic which are to receive special services, e.g. QoS. Using labels to provide forwarding along an explicit path different from the one constructed by destination-based forwarding. 2. Scalability of network layer routing Using labels as a means to aggregate forwarding information, while working in the presence of routing hierarchies. 3. Simplify integration of routers with cell switching based technologies a) making cell switches behave as peers to routers (thus reducing the number of routing peers that a router has to maintain), b) by making information about physical topology available to Network Layer routing procedures, and c) by employing common addressing, routing, and management procedures. 4. Simplify integration of routers with optical cross-connect based technologies a) making optical cross connects behave as peers to routers (thus reducing the number of routing peers that a router has to maintain), b) by making information about physical topology available to Network Layer routing procedures, and c) by employing common addressing, routing, and management procedures. High Level Requirements 1. The solution should be general with respect to data link technologies. Specific optimizations for particular media will be considered. 2. The solution must be compatible with existing internetwork technologies and routing protocols. 3. The solution should support a wide range of forwarding granularities associated with a given label, from a single application flow to a group of topologically related destinations. 4. The solution should support operations, administration, and maintenance facilities at least as extensive as those supported in IP networks. 5. The solution should provide stable routing. The protocols defined by MPLS must provide protocol mechanism(s) to either prevent the formation of loops and/or contain the amount of (networking) resources that could be consumed due to the presence of such loops. 6. The solution should be very scalable. Scalability issues will be considered and analyzed. Charter Statement: The working group is responsible for standardizing a base technology for using label switching in conjunction with network layer routing and for the implementation of that technology over various link level technologies, which may include Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,... This includes procedures and protocols for the distribution of labels between routers, encapsulations, multicast considerations, and the use of labels to support higher layer resource reservation and QoS mechanisms. The working group will extend the concept of label switching to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming fiber to outgoing fiber). Objectives: 1. Specify standard protocol(s) for maintenance and distribution of label binding information to support unicast destination-based routing. 2. Specify standard protocol(s) for maintenance and distribution of label binding information to support multicast routing. 3. Specify standard protocol(s) for maintenance and distribution of label binding information to support hierarchy of routing knowledge (e.g., complete segregation of intra and inter-domain routing). 4. Specify standard protocol(s) for maintenance and distribution of label binding information to support explicit paths in support of applications such as Traffic Engineering. 5. Specify standard protocols and procedures to support fast MPLS-based recovery. 6. Specify extensions to the protocols and procedures for signaling and recovery to support time-division, wavelength and spatial switching. 7. Specify standard procedures of carrying label information over various link level technologies. 8. Define the support of Differentiated and Integrated Services, including aggregated QoS, in an MPLS environment. 9. Specify standard protocols and procedures to support operations, administration, and maintenance facilities. 10. Specify a link management protocol for link provisioning and fault isolation, to facilitate LSP recovery. Coordination: The working group will coordinate its activities with other working groups as appropriate. For specific technologies, the WG will cooperate with the appropriate standards bodies such as OIF, ITU-T, ANSI, ODSI etc. Goals and Milestones: Mar 00 - Produce a document which defines support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks (Standards Track). Aug 00 - Produce a document which defines operation with "classic" RSVP (i.e. non-TE RSVP) for unicast destinations. (Standards Track). Aug 00 - Produce specifications for protocols and procedures that support fault recovery in an MPLS environment. Dec 00 - Produce specifications for a MPLS control plane for time-division, wavelength and spatial switching (Standards Track). Dec 00 - Produce specifications for a link management protocol for link provisioning and fault isolation (Standards Track). ------_=_NextPart_001_01BF988C.FDD74450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Updated charter

Hi folks,

Here is the updated charter based on comments to the = mailing list, as well as feedback received from attendees at the = Adelaide IETF.  We will discuss this charter at the second MPLS = session on Wedneday.

The main changes are to add the following wording to = the charter statement:
"The working group will extend the concept of = label switching to encompass
time-division (e.g. SONET ADMs), wavelength (optical = lambdas)
and spatial switching (e.g. incoming fiber to = outgoing fiber)."

and to remove references to optical = crossconnects.

Regarding Loa Andersson's comment:
" 1. The charter says that the WG should = co-ordinate the work with other
   organizations "such as OIF, ITU-T, = ANSI, ODSI etc." I've the feeling
   that the list is a bit random. There = could be other organizations
   that should be on that list, what about = MSF? This is minor.
   I'm more concerned about the = "coordintion/cooperation", what mandated
   does it vest on who and on behalf of = whom? I've a feeling that there
   might be legal (US legal :-) aspects = here."

we would like to reiterate that if a formal liaison =
is required with a particular standards body, the = IAB will be contacted
to set one up.  The above list is by no means = intended to be comprehensive.

Regards,
MPLS WG Chairs

-------------------------------------------------
Multiprotocol Label Switching (mpls) Charter

Problem Statement:

Label switching in conjunction with network layer = routing has emerged
as an important new technology.  It is actively = being applied to
applications such as traffic engineering and virtual = private networks.
Among the problems this technology is expected to = address are the
following:

1.  Greater flexibility in delivering routing = services

Using labels to identify particular traffic which are = to receive
special services, e.g. QoS.

Using labels to provide forwarding along an explicit = path different
from the one constructed by destination-based = forwarding.

2.  Scalability of network layer routing

Using labels as a means to aggregate forwarding = information, while
working in the presence of routing = hierarchies.

3.  Simplify integration of routers with cell = switching based
technologies

a) making cell switches behave as peers to routers = (thus reducing
the number of routing peers that a  router has = to maintain),

b) by making information about physical topology = available to
Network Layer routing procedures, and

c) by employing common addressing, routing, and = management
procedures.

4.  Simplify integration of routers with optical = cross-connect based
technologies

a) making optical cross connects behave as peers to = routers (thus
reducing the number of routing peers that a router = has to maintain),

b) by making information about physical topology = available to
Network Layer routing procedures, and

c) by employing common addressing, routing, and = management
procedures.

High Level Requirements

1.  The solution should be general with respect = to data link
technologies. Specific optimizations for particular = media will be
considered.

2.  The solution must be compatible with = existing internetwork
technologies and routing protocols.

3.  The solution should support a wide range of = forwarding
granularities associated with a given label, from a = single
application flow to a group of topologically related = destinations.

4.  The solution should support operations, = administration, and
maintenance facilities at least as extensive as = those supported in
IP networks.

5.  The solution should provide stable = routing.  The protocols defined
by MPLS must provide protocol mechanism(s) to either = prevent the
formation of loops and/or contain the amount of = (networking) resources
that could be consumed due to the presence of such = loops.

6.  The solution should be very scalable.  = Scalability issues will be
considered and analyzed.

Charter Statement:

The working group is responsible for standardizing a = base technology
for using label switching in conjunction with = network layer routing
and for the implementation of that technology over = various link level
technologies, which may include Packet-over-Sonet, = Frame Relay, ATM,
Ethernet (all forms, such as Gigabit Ethernet, = etc.), Token Ring,...

This includes procedures and protocols for the = distribution of labels
between routers, encapsulations, multicast = considerations, and the use
of labels to support higher layer resource = reservation and QoS
mechanisms.

The working group will extend the concept of label = switching to encompass
time-division (e.g. SONET ADMs), wavelength (optical = lambdas)
and spatial switching (e.g. incoming fiber to = outgoing fiber).

Objectives:

1.  Specify standard protocol(s) for maintenance = and distribution of
label binding information to support unicast = destination-based
routing.

2.  Specify standard protocol(s) for maintenance = and distribution of
label binding information to support multicast = routing.

3.  Specify standard protocol(s) for maintenance = and distribution of
label binding information to support hierarchy of = routing knowledge
(e.g., complete segregation of intra and = inter-domain routing).

4.  Specify standard protocol(s) for maintenance = and distribution of
label binding information to support explicit paths = in support of
applications such as Traffic Engineering.

5.  Specify standard protocols and procedures to = support fast
MPLS-based recovery.

6.  Specify extensions to the protocols and = procedures for
signaling and recovery to support time-division, = wavelength and
spatial switching.

7.  Specify standard procedures of carrying = label information over
various link level technologies.

8.  Define the support of Differentiated and = Integrated Services,
including aggregated QoS, in an MPLS = environment.

9.  Specify standard protocols and procedures to = support operations,
administration, and maintenance facilities.

10. Specify a link management protocol for link = provisioning and
fault isolation, to facilitate LSP recovery.

Coordination:

The working group will coordinate its activities with = other working
groups as appropriate.  For specific = technologies, the WG will
cooperate with the appropriate standards bodies such = as OIF, ITU-T,
ANSI, ODSI etc.

Goals and Milestones:

Mar 00 - Produce a document which defines support of = Differentiated
         = Services (Diff-Serv) over Multi-Protocol Label Switching
         = (MPLS) networks (Standards Track).

Aug 00 - Produce a document which defines operation = with "classic" RSVP
         = (i.e. non-TE RSVP) for unicast destinations. (Standards Track).

Aug 00 - Produce specifications for protocols and = procedures that support
         = fault recovery in an MPLS environment.

Dec 00 - Produce specifications for a MPLS control = plane for time-division,
         = wavelength and spatial switching (Standards Track).

Dec 00 - Produce specifications for a link management = protocol for link
         = provisioning and fault isolation (Standards Track).

------_=_NextPart_001_01BF988C.FDD74450-- From owner-mpls@UU.NET Tue Mar 28 03:50:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18442 for ; Tue, 28 Mar 2000 03:50:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiilf17981; Tue, 28 Mar 2000 08:50:33 GMT Received: by mail-control.mail.uu.net id QQiilf17649 for mpls-outgoing; Tue, 28 Mar 2000 08:50:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiilf17644 for ; Tue, 28 Mar 2000 08:50:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiilf12195 for ; Tue, 28 Mar 2000 03:48:33 -0500 (EST) Received: from mail.rdc1.sfba.home.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ha1.rdc1.sfba.home.com [24.0.0.66]) id QQiilf09332 for ; Tue, 28 Mar 2000 08:48:32 GMT Received: from home.net ([24.5.203.21]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000328084832.SYFQ5721.mail.rdc1.sfba.home.com@home.net>; Tue, 28 Mar 2000 00:48:32 -0800 Message-ID: <38E071DF.64F859BE@home.net> Date: Tue, 28 Mar 2000 00:48:31 -0800 From: Tony Li Organization: Li Consulting X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sid Chaudhuri CC: Krishna Bala , Jonathan Lang , curtis@avici.com, Jagan Shantigram , Khaled Elsayed , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <000601bf97f8$313a4850$1761c697@tellium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > You may be right that both models can support all services provided > signaling and routing are IP-based. However, there are two fundamental > differences between the Open and the Peer model: (1) In OPen model if an > operator wants to offer "optical Pipe" services regardless what svc is > carried within the pipes the operator would not like to share all its > network resource information to its clients. Therefore what is needed for > information exchange between the client NE and the optical network is a > standard interface defining the minimum set of required parameters without > sharing optical netrwork resource info with the clinet NE. That is what UNI > spec being developed by OIF. (2)We do not need to impose the routing and > signaling protocols to every client network elements for providing the > optical layer services. Al they need to adhere to is the simplie UNI spec. > Rest is done by the optical layer using IP signaling and routing. The > driver for using IP routing and signaling in the optical layer is simply > because these are well developed and well suited for the optical layer > functions and there is no need to reinvent the wheel. Also, when > multi-vendor optical networks are to work together other protocols such as > BGP can be easily adopted. Based on this, the difference is that you're emphasizing is the use of another protocol at the edge of a service providers network. If this is an accurate assesment of your position, then it would behoove us to distinguish between the intra-domain model and the inter-domain model. For example, one could reasonably say that the MPLS/TE model is currently a peer intra-domain model and that we've completely blown off the inter-domain model. So far, this seems to have a reasonable amount of appeal to the customer base. > S0 unless we assume that all services to be provided by an optical network > (inclcuing pipe svc) are accessed via routers that are within the opretor's > domain the peer model by itself is unworkable and once we have the open > model the need for peer model is diminshed to almost naught. If I follow that logic, it is impossible to get any services if multiple domains exist. I think the Internet is a small counterexample. Regards, Tony From owner-mpls@UU.NET Tue Mar 28 04:06:52 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18607 for ; Tue, 28 Mar 2000 04:06:52 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiilg19172; Tue, 28 Mar 2000 09:06:53 GMT Received: by mail-control.mail.uu.net id QQiilg26423 for mpls-outgoing; Tue, 28 Mar 2000 09:06:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiilg26417 for ; Tue, 28 Mar 2000 09:06:18 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiilg00497 for ; Tue, 28 Mar 2000 04:06:12 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQiilg18001 for ; Tue, 28 Mar 2000 09:04:48 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id OAA06817; Tue, 28 Mar 2000 14:29:21 -0600 (GMT) Message-ID: <002901bf9895$045fcec0$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Cc: References: Subject: Re: CR-LDP Date: Tue, 28 Mar 2000 14:37:15 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01BF98C3.1CC0B820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0026_01BF98C3.1CC0B820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ajit The label stacking scenario that you mentioned is possible in MPLS, = but if we implement it on ATM then how can it be done as the ATM cell = has a fixed header size (5 bytes) and there is just 12+16 bits allocated = for label (VPI/VCI ). Any suggestions. santosh ----- Original Message -----=20 From: ajithn@sg.ibm.com=20 To: Santosh Gupta=20 Cc: sumitg@rocketmail.com ; Ashish Monga ; mpls@UU.NET=20 Sent: Tuesday, March 28, 2000 1:03 PM Subject: Re: CR-LDP LSP-IDs become part of the "traffic engineering state" of the network. = So it is legitimate to define a CR-LSP, whose ingress is LER2, stacking = or splicing with an existing CR-LSP whose ingress is LER1, the latter = being specified by its LSP-ID. The entity which does traffic engineering = can be thought of as "higher" than the LSR, and it knows these LSP-IDs. At = that level, there is global (or, supra-local) knowledge. However, from the point of view of LSRs, local knowledge is = sufficient. LSRs need to know only the LSP-IDs they participate in. In your example, LER2 and LSR5 do not need to know the = spliced/stacked CR-LSP's LSP-ID because all they do with it is, just pass it downward. That remains true as we go down the request path till we hit LSR3, for which it is intended. So there is no need for non-participating LSRs = to be aware of the LSP-ID. -- Ajith -- "Santosh Gupta" on 03/28/2000 = 12:45:39 PM Please respond to "Santosh Gupta" To: sumitg@rocketmail.com, mpls@UU.NET cc: "Ashish Monga" (bcc: Ajith Narayanan/Singapore/IBM) Subject: Re: CR-LDP Hi Sumit The concerned section of CR-LDP draft is as below. 4.7.4. ER-Hop 4: LSPID The LSPID is used to identify the tunnel ingress point as the next hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an already established CR-LSP. It also allows for splicing the CR-LSP being established with an existing CR-LSP. If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may splice the CR-LSP of the incoming Label Request to the CR-LSP that currently exists with this LSPID. This is useful, for example, at the point at which a Label Request used for local repair arrives at the next ER-Hop after the loosely specified CR-LSP segment. Use of the LSPID Hop in this scenario eliminates the need for ER-Hops to keep the entire remaining ER-TLV at each LSR that is at either (upstream or downstream) end of a loosely specified CR-LSP segment as part of its state information. This is due to the fact that the upstream LSR needs only to keep the next ER-Hop and the LSPID and the downstream LSR needs only to keep the LSPID in order for each end to be able to recognize that the same LSP is being identified. In this it clearly states that it is not only the Ingress LER and the = LSRs in the path of this LSP but other LERs also need to know the LSP-ID of different LSPs. The scenario is something like LER1 ------> LSR2-------->LSR3------>LSR4 LER2-------->LSR5 there is an LSP setup as shown from LER1 thru LSR2,LSR3, LSR4. Now = LER5 receives a ER-TLV which says it has to make an LSP for which the next = hop is LSR3 and the already existing LSP with the LSP-ID is to be used. = Now the question is how does LSR5 or LER2 come to know about this particular = LSP-ID which actually originated at LER1? santosh santoshgupta@poboxes.com ----- Original Message ----- From: Sumit Garg To: 'ashish' Sent: Tuesday, March 28, 2000 3:49 A Subject: RE: CR-LDP Hi, LSD-ID is a TLV defined by the CR-LDP draft. It is a combination of = the LSR-ID and a 2 octect number assigned by the ingress/ initiating LSR. = This would typically be an administor assigned/ monitored quantity and = thereof known a priori for LSP splicing/ tunneling. The LSPID is propagated to downstream LSRs in the LSP setup request. Regards Sumit -----Original Message----- From: ashish [mailto:ashish@daewoo.dti.daewoo.co.kr] Sent: Monday, March 27, 2000 03:58 AM To: mpls@uu.net Subject: CR-LDP In CR-LDP draft-03, one of the ER-HOP TLV types contain LSPID field = that is used for tunneling thru some existing LSP having that LSPID field. This means that that LSPID should be known in advance . How is that done. Does information regarding each LSP being created each having unique LSPID is propagated to all LSR's. Please clarify. ------=_NextPart_000_0026_01BF98C3.1CC0B820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Ajit
    The label stacking scenario that you mentioned = is=20 possible in MPLS, but if  we implement it on ATM then how = can it=20 be done as the  ATM cell has a fixed header size (5=20 bytes) and there is just 12+16 bits allocated for label (VPI/VCI ). = Any=20 suggestions.
santosh
----- Original Message -----
From:=20 ajithn@sg.ibm.com
To: Santosh Gupta
Cc: sumitg@rocketmail.com ; Ashish Monga ; mpls@UU.NET
Sent: Tuesday, March 28, 2000 = 1:03=20 PM
Subject: Re: CR-LDP


LSP-IDs become part of the "traffic engineering = state" of=20 the network.  So
it is legitimate to define a CR-LSP, whose = ingress is=20 LER2,  stacking or
splicing with an existing CR-LSP whose = ingress is=20 LER1,  the latter being
specified by its LSP-ID.   = The=20 entity which does traffic engineering can be
thought of as "higher" = than=20 the LSR, and it knows these LSP-IDs.  At that
level, there is = global=20 (or, supra-local) knowledge.

However, from the point of view of = LSRs,=20 local knowledge is sufficient.
LSRs need to know only the LSP-IDs = they=20 participate in.

In your example,  LER2 and LSR5 do not = need to=20 know the spliced/stacked
CR-LSP's LSP-ID because all they do with = it is,=20 just pass it downward.
That remains true as we go down the request = path=20 till we hit LSR3, for
which it is intended.   So there is = no need=20 for non-participating LSRs to
be aware of the LSP-ID.

--=20 Ajith

--


"Santosh Gupta"=20 <santoshg@daewoo.dti.daewoo.co.kr> on 03/28/2000=20 12:45:39
PM

Please respond to "Santosh Gupta"=20 <santoshg@daewoo.dti.daewoo.co.kr>

To:  =20 sumitg@rocketmail.com, mpls@UU.NET
cc:   "Ashish Monga"=20 <ashish@daewoo.dti.daewoo.co.kr> (bcc:=20 Ajith
     =20 Narayanan/Singapore/IBM)
Subject:  Re: = CR-LDP




Hi=20 Sumit
    The concerned section of CR-LDP draft is = as=20 below.
4.7.4. ER-Hop 4: LSPID

The LSPID is used to identify = the=20 tunnel ingress point as the next
hop in the ER. This ER-Hop allows = for=20 stacking new CR-LSPs within an
already established CR-LSP. It also = allows=20 for splicing the CR-LSP
being established with an existing = CR-LSP.
If an=20 LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may
splice = the=20 CR-LSP of the incoming Label Request to the CR-LSP that
currently = exists=20 with this LSPID. This is useful, for example, at
the point at which = a Label=20 Request used for local repair arrives at
the next ER-Hop after the = loosely=20 specified CR-LSP segment. Use of
the LSPID Hop in this scenario = eliminates=20 the need for ER-Hops to
keep the entire remaining ER-TLV at each = LSR that=20 is at either
(upstream or downstream) end of a loosely specified = CR-LSP=20 segment
as part of its state information. This is due to the fact = that=20 the
upstream LSR needs only to keep the next ER-Hop and the LSPID=20 and
the downstream LSR needs only to keep the LSPID in order for=20 each
end to be able to recognize that the same LSP is being=20 identified.

In this it clearly states that it is not only the = Ingress=20 LER and the LSRs
in the path of this LSP but other LERs also need = to know=20 the LSP-ID of
different LSPs. The scenario is something=20 = like

          &= nbsp;    =20 LER1 ------>=20 = LSR2-------->LSR3------>LSR4

     &= nbsp;         =20 LER2-------->LSR5

there is an LSP setup as shown from LER1 = thru=20 LSR2,LSR3, LSR4. Now LER5
receives a ER-TLV which says it has to = make=20 an  LSP for which the next hop
is LSR3 and the already = existing LSP=20 with the LSP-ID is to be used. Now the
question is how does LSR5 or = LER2=20 come to know about this particular LSP-ID
which actually originated = at=20 LER1?

santosh

santoshgupta@poboxes.com


----- = Original=20 Message -----
From: Sumit Garg
To: 'ashish'
Sent: Tuesday, = March 28,=20 2000 3:49 A
Subject: RE: CR-LDP


Hi,

LSD-ID is a = TLV=20 defined by the CR-LDP draft. It is a combination of the
LSR-ID and = a 2=20 octect number assigned by the ingress/ initiating LSR. This
would = typically=20 be an administor assigned/ monitored quantity and thereof
known a = priori=20 for LSP splicing/ tunneling.

The LSPID is propagated to = downstream LSRs=20 in the LSP setup request.

Regards
Sumit

  = -----Original=20 Message-----
  From: ashish=20 [mailto:ashish@daewoo.dti.daewoo.co.kr]
  Sent: Monday, March = 27, 2000=20 03:58 AM
  To: mpls@uu.net
  Subject: = CR-LDP


 =20 In CR-LDP draft-03, one of the ER-HOP TLV types contain LSPID field = that
is=20 used for tunneling thru some existing LSP having that LSPID = field.
 =20 This means that that LSPID should be known in advance .
  How = is that=20 done.
  Does information regarding each LSP being created each = having=20 unique
LSPID is propagated to all LSR's.
  Please=20 clarify.
------=_NextPart_000_0026_01BF98C3.1CC0B820-- From owner-mpls@UU.NET Tue Mar 28 06:09:34 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19521 for ; Tue, 28 Mar 2000 06:09:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiilo21876; Tue, 28 Mar 2000 11:09:36 GMT Received: by mail-control.mail.uu.net id QQiilo17377 for mpls-outgoing; Tue, 28 Mar 2000 11:09:05 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiilo17334 for ; Tue, 28 Mar 2000 11:09:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiilo23487 for ; Tue, 28 Mar 2000 06:08:45 -0500 (EST) Received: from domino.netia.pl by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: domino.netia.pl [195.114.160.130]) id QQiilo21349 for ; Tue, 28 Mar 2000 11:08:42 GMT Subject: MPLS routing accross AS boundaries To: mpls@UU.NET From: "Andrzej Czerczak" Date: Tue, 28 Mar 2000 13:03:33 +0200 Message-ID: X-MIMETrack: Serialize by Router on WaWarNotes/HeadQ(Release 5.0.2c (Intl)|2 February 2000) at 2000-03-28 13:03:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Where can I get information on the subject of MPLS QoS routing accross Autonomous System boundaries? Thanks Andrzej From owner-mpls@UU.NET Tue Mar 28 08:47:19 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20858 for ; Tue, 28 Mar 2000 08:47:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiilz19023; Tue, 28 Mar 2000 13:47:19 GMT Received: by mail-control.mail.uu.net id QQiilz14451 for mpls-outgoing; Tue, 28 Mar 2000 13:46:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiilz14444 for ; Tue, 28 Mar 2000 13:46:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiilz09843 for ; Tue, 28 Mar 2000 08:46:25 -0500 (EST) Received: from students.itb.ac.id by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: students.ITB.ac.id [167.205.22.114]) id QQiilz18368 for ; Tue, 28 Mar 2000 13:46:20 GMT Received: (qmail 68844 invoked by uid 1210); 28 Mar 2000 13:45:51 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Mar 2000 13:45:51 -0000 Date: Tue, 28 Mar 2000 20:45:51 +0700 (JAVT) From: From MountIsland Nggowo Tresno To: mpls@UU.NET Subject: QoS MPLS in IP and ATM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Content-Disposition: INLINE Sender: owner-mpls@UU.NET Precedence: bulk hii..dear... who can help me to find site about the MPLS QoS to integrate IP and ATM that can prove about the advantage MPLS to integrate IP and ATM by the way thanks all -------------------------- KEEP PATIENT AND SILENT TRUST YOURSELF IN EVERYTHING ------------------------------- hidup akan hampa tanpa perjuangan From owner-mpls@UU.NET Tue Mar 28 09:27:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21294 for ; Tue, 28 Mar 2000 09:27:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiimb21173; Tue, 28 Mar 2000 14:27:40 GMT Received: by mail-control.mail.uu.net id QQiimb25930 for mpls-outgoing; Tue, 28 Mar 2000 14:27:12 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiimb25924 for ; Tue, 28 Mar 2000 14:27:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiimb03970 for ; Tue, 28 Mar 2000 09:27:00 -0500 (EST) From: ajithn@sg.ibm.com Received: from ausmtp01.au.ibm.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ausmtp01.au.ibm.COM [202.135.136.97]) id QQiimb20499 for ; Tue, 28 Mar 2000 14:26:48 GMT Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id AAA44936 for ; Wed, 29 Mar 2000 00:21:51 +1000 Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id AAA25302 for ; Wed, 29 Mar 2000 00:26:45 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568B0.004F5939 ; Wed, 29 Mar 2000 00:26:41 +1000 X-Lotus-FromDomain: IBMSG@IBMAU To: "Santosh Gupta" cc: mpls@UU.NET Message-ID: Date: Tue, 28 Mar 2000 22:28:24 +0800 Subject: Re: CR-LDP Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=4IqrKbTbXMRi8gMwEnGIugUxIIKvdkiaCzxKxOJOj5sJMuUIHnppwY2c" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk --0__=4IqrKbTbXMRi8gMwEnGIugUxIIKvdkiaCzxKxOJOj5sJMuUIHnppwY2c Content-type: text/plain; charset=us-ascii Content-Disposition: inline Please refer to draft-ietf-mpls-atm-02.txt section 9 (Encapsulation) which details the use of MPLS label stack for ATM based implementation. The top label is carried in the ATM VPI/VCI, and is therefore replicated on every cell header for that packet. The (rest of the) label stack appears in the packet's shim header and NOT in any cell header. -- Ajith | Ajith Narayanan --- "Santosh Gupta" on 03/28/2000 05:07:15 PM Please respond to "Santosh Gupta" To: Ajith Narayanan/Singapore/IBM@IBMSG cc: mpls@UU.NET Subject: Re: CR-LDP Hi Ajit The label stacking scenario that you mentioned is possible in MPLS, but if we implement it on ATM then how can it be done as the ATM cell has a fixed header size (5 bytes) and there is just 12+16 bits allocated for label (VPI/VCI ). Any suggestions. santosh ----- Original Message ----- From: ajithn@sg.ibm.com To: Santosh Gupta Cc: sumitg@rocketmail.com ; Ashish Monga ; mpls@UU.NET Sent: Tuesday, March 28, 2000 1:03 PM Subject: Re: CR-LDP LSP-IDs become part of the "traffic engineering state" of the network. So it is legitimate to define a CR-LSP, whose ingress is LER2, stacking or splicing with an existing CR-LSP whose ingress is LER1, the latter being specified by its LSP-ID. The entity which does traffic engineering can be thought of as "higher" than the LSR, and it knows these LSP-IDs. At that level, there is global (or, supra-local) knowledge. However, from the point of view of LSRs, local knowledge is sufficient. LSRs need to know only the LSP-IDs they participate in. In your example, LER2 and LSR5 do not need to know the spliced/stacked CR-LSP's LSP-ID because all they do with it is, just pass it downward. That remains true as we go down the request path till we hit LSR3, for which it is intended. So there is no need for non-participating LSRs to be aware of the LSP-ID. -- Ajith -- "Santosh Gupta" on 03/28/2000 12:45:39 PM Please respond to "Santosh Gupta" To: sumitg@rocketmail.com, mpls@UU.NET cc: "Ashish Monga" (bcc: Ajith Narayanan/Singapore/IBM) Subject: Re: CR-LDP Hi Sumit The concerned section of CR-LDP draft is as below. 4.7.4. ER-Hop 4: LSPID The LSPID is used to identify the tunnel ingress point as the next hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an already established CR-LSP. It also allows for splicing the CR-LSP being established with an existing CR-LSP. If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may splice the CR-LSP of the incoming Label Request to the CR-LSP that currently exists with this LSPID. This is useful, for example, at the point at which a Label Request used for local repair arrives at the next ER-Hop after the loosely specified CR-LSP segment. Use of the LSPID Hop in this scenario eliminates the need for ER-Hops to keep the entire remaining ER-TLV at each LSR that is at either (upstream or downstream) end of a loosely specified CR-LSP segment as part of its state information. This is due to the fact that the upstream LSR needs only to keep the next ER-Hop and the LSPID and the downstream LSR needs only to keep the LSPID in order for each end to be able to recognize that the same LSP is being identified. In this it clearly states that it is not only the Ingress LER and the LSRs in the path of this LSP but other LERs also need to know the LSP-ID of different LSPs. The scenario is something like LER1 ------> LSR2-------->LSR3------>LSR4 LER2-------->LSR5 there is an LSP setup as shown from LER1 thru LSR2,LSR3, LSR4. Now LER5 receives a ER-TLV which says it has to make an LSP for which the next hop is LSR3 and the already existing LSP with the LSP-ID is to be used. Now the question is how does LSR5 or LER2 come to know about this particular LSP-ID which actually originated at LER1? santosh santoshgupta@poboxes.com ----- Original Message ----- From: Sumit Garg To: 'ashish' Sent: Tuesday, March 28, 2000 3:49 A Subject: RE: CR-LDP Hi, LSD-ID is a TLV defined by the CR-LDP draft. It is a combination of the LSR-ID and a 2 octect number assigned by the ingress/ initiating LSR. This would typically be an administor assigned/ monitored quantity and thereof known a priori for LSP splicing/ tunneling. The LSPID is propagated to downstream LSRs in the LSP setup request. Regards Sumit -----Original Message----- From: ashish [mailto:ashish@daewoo.dti.daewoo.co.kr] Sent: Monday, March 27, 2000 03:58 AM To: mpls@uu.net Subject: CR-LDP In CR-LDP draft-03, one of the ER-HOP TLV types contain LSPID field that is used for tunneling thru some existing LSP having that LSPID field. This means that that LSPID should be known in advance . How is that done. Does information regarding each LSP being created each having unique LSPID is propagated to all LSR's. Please clarify. --0__=4IqrKbTbXMRi8gMwEnGIugUxIIKvdkiaCzxKxOJOj5sJMuUIHnppwY2c Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjMxNC4xMDAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj5IaSBBaml0PC9ESVY+DQo8RElWPiZuYnNw OyZuYnNwOyZuYnNwOyBUaGUgbGFiZWwgc3RhY2tpbmcgc2NlbmFyaW8gdGhhdCB5b3UgbWVudGlv bmVkIGlzIA0KcG9zc2libGUgaW4gTVBMUywgYnV0IGlmJm5ic3A7IHdlIGltcGxlbWVudCBpdCZu YnNwO29uIEFUTSB0aGVuIGhvdyBjYW4mbmJzcDtpdCANCmJlIGRvbmUgYXMgdGhlJm5ic3A7Jm5i c3A7QVRNJm5ic3A7Y2VsbCBoYXMgYSBmaXhlZCBoZWFkZXIgc2l6ZSAoNSANCmJ5dGVzKSZuYnNw O2FuZCB0aGVyZSBpcyBqdXN0IDEyKzE2IGJpdHMgYWxsb2NhdGVkIGZvciBsYWJlbCAoVlBJL1ZD SSApLiBBbnkgDQpzdWdnZXN0aW9ucy48L0RJVj4NCjxESVY+c2FudG9zaDwvRElWPg0KPEJMT0NL UVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tTEVG VDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklH SFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRl NGU0OyBGT05UOiAxMHB0IGFyaWFsOyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0K ICA8QSBocmVmPSJtYWlsdG86YWppdGhuQHNnLmlibS5jb20iIA0KICB0aXRsZT1haml0aG5Ac2cu aWJtLmNvbT5haml0aG5Ac2cuaWJtLmNvbTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDEwcHQgYXJpYWwiPjxCPlRvOjwvQj4gPEEgDQogIGhyZWY9Im1haWx0bzpzYW50b3NoZ0BkYWV3 b28uZHRpLmRhZXdvby5jby5rciIgDQogIHRpdGxlPXNhbnRvc2hnQGRhZXdvby5kdGkuZGFld29v LmNvLmtyPlNhbnRvc2ggR3VwdGE8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0 IGFyaWFsIj48Qj5DYzo8L0I+IDxBIA0KICBocmVmPSJtYWlsdG86c3VtaXRnQHJvY2tldG1haWwu Y29tIiANCiAgdGl0bGU9c3VtaXRnQHJvY2tldG1haWwuY29tPnN1bWl0Z0Byb2NrZXRtYWlsLmNv bTwvQT4gOyA8QSANCiAgaHJlZj0ibWFpbHRvOmFzaGlzaEBkYWV3b28uZHRpLmRhZXdvby5jby5r ciIgDQogIHRpdGxlPWFzaGlzaEBkYWV3b28uZHRpLmRhZXdvby5jby5rcj5Bc2hpc2ggTW9uZ2E8 L0E+IDsgPEEgDQogIGhyZWY9Im1haWx0bzptcGxzQFVVLk5FVCIgdGl0bGU9bXBsc0BVVS5ORVQ+ bXBsc0BVVS5ORVQ8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48 Qj5TZW50OjwvQj4gVHVlc2RheSwgTWFyY2ggMjgsIDIwMDAgMTowMyANCiAgUE08L0RJVj4NCiAg PERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+U3ViamVjdDo8L0I+IFJlOiBDUi1MRFA8 L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+PEJSPkxTUC1JRHMgYmVjb21lIHBhcnQgb2YgdGhlICJ0 cmFmZmljIGVuZ2luZWVyaW5nIHN0YXRlIiBvZiANCiAgdGhlIG5ldHdvcmsuJm5ic3A7IFNvPEJS Pml0IGlzIGxlZ2l0aW1hdGUgdG8gZGVmaW5lIGEgQ1ItTFNQLCB3aG9zZSBpbmdyZXNzIGlzIA0K ICBMRVIyLCZuYnNwOyBzdGFja2luZyBvcjxCUj5zcGxpY2luZyB3aXRoIGFuIGV4aXN0aW5nIENS LUxTUCB3aG9zZSBpbmdyZXNzIGlzIA0KICBMRVIxLCZuYnNwOyB0aGUgbGF0dGVyIGJlaW5nPEJS PnNwZWNpZmllZCBieSBpdHMgTFNQLUlELiZuYnNwOyZuYnNwOyBUaGUgDQogIGVudGl0eSB3aGlj aCBkb2VzIHRyYWZmaWMgZW5naW5lZXJpbmcgY2FuIGJlPEJSPnRob3VnaHQgb2YgYXMgImhpZ2hl ciIgdGhhbiANCiAgdGhlIExTUiwgYW5kIGl0IGtub3dzIHRoZXNlIExTUC1JRHMuJm5ic3A7IEF0 IHRoYXQ8QlI+bGV2ZWwsIHRoZXJlIGlzIGdsb2JhbCANCiAgKG9yLCBzdXByYS1sb2NhbCkga25v d2xlZGdlLjxCUj48QlI+SG93ZXZlciwgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBMU1JzLCAN CiAgbG9jYWwga25vd2xlZGdlIGlzIHN1ZmZpY2llbnQuPEJSPkxTUnMgbmVlZCB0byBrbm93IG9u bHkgdGhlIExTUC1JRHMgdGhleSANCiAgcGFydGljaXBhdGUgaW4uPEJSPjxCUj5JbiB5b3VyIGV4 YW1wbGUsJm5ic3A7IExFUjIgYW5kIExTUjUgZG8gbm90IG5lZWQgdG8gDQogIGtub3cgdGhlIHNw bGljZWQvc3RhY2tlZDxCUj5DUi1MU1AncyBMU1AtSUQgYmVjYXVzZSBhbGwgdGhleSBkbyB3aXRo IGl0IGlzLCANCiAganVzdCBwYXNzIGl0IGRvd253YXJkLjxCUj5UaGF0IHJlbWFpbnMgdHJ1ZSBh cyB3ZSBnbyBkb3duIHRoZSByZXF1ZXN0IHBhdGggDQogIHRpbGwgd2UgaGl0IExTUjMsIGZvcjxC Uj53aGljaCBpdCBpcyBpbnRlbmRlZC4mbmJzcDsmbmJzcDsgU28gdGhlcmUgaXMgbm8gbmVlZCAN CiAgZm9yIG5vbi1wYXJ0aWNpcGF0aW5nIExTUnMgdG88QlI+YmUgYXdhcmUgb2YgdGhlIExTUC1J RC48QlI+PEJSPi0tIA0KICBBaml0aDxCUj48QlI+LS08QlI+PEJSPjxCUj4iU2FudG9zaCBHdXB0 YSIgDQogICZsdDtzYW50b3NoZ0BkYWV3b28uZHRpLmRhZXdvby5jby5rciZndDsgb24gMDMvMjgv MjAwMCANCiAgMTI6NDU6Mzk8QlI+UE08QlI+PEJSPlBsZWFzZSByZXNwb25kIHRvICJTYW50b3No IEd1cHRhIiANCiAgJmx0O3NhbnRvc2hnQGRhZXdvby5kdGkuZGFld29vLmNvLmtyJmd0OzxCUj48 QlI+VG86Jm5ic3A7Jm5ic3A7IA0KICBzdW1pdGdAcm9ja2V0bWFpbC5jb20sIG1wbHNAVVUuTkVU PEJSPmNjOiZuYnNwOyZuYnNwOyAiQXNoaXNoIE1vbmdhIiANCiAgJmx0O2FzaGlzaEBkYWV3b28u ZHRpLmRhZXdvby5jby5rciZndDsgKGJjYzogDQogIEFqaXRoPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCiAgTmFyYXlhbmFuL1NpbmdhcG9yZS9JQk0pPEJSPlN1YmplY3Q6Jm5i c3A7IFJlOiBDUi1MRFA8QlI+PEJSPjxCUj48QlI+PEJSPkhpIA0KICBTdW1pdDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsgVGhlIGNvbmNlcm5lZCBzZWN0aW9uIG9mIENSLUxEUCBkcmFmdCBpcyBhcyAN CiAgYmVsb3cuPEJSPjQuNy40LiBFUi1Ib3AgNDogTFNQSUQ8QlI+PEJSPlRoZSBMU1BJRCBpcyB1 c2VkIHRvIGlkZW50aWZ5IHRoZSANCiAgdHVubmVsIGluZ3Jlc3MgcG9pbnQgYXMgdGhlIG5leHQ8 QlI+aG9wIGluIHRoZSBFUi4gVGhpcyBFUi1Ib3AgYWxsb3dzIGZvciANCiAgc3RhY2tpbmcgbmV3 IENSLUxTUHMgd2l0aGluIGFuPEJSPmFscmVhZHkgZXN0YWJsaXNoZWQgQ1ItTFNQLiBJdCBhbHNv IGFsbG93cyANCiAgZm9yIHNwbGljaW5nIHRoZSBDUi1MU1A8QlI+YmVpbmcgZXN0YWJsaXNoZWQg d2l0aCBhbiBleGlzdGluZyBDUi1MU1AuPEJSPklmIGFuIA0KICBMU1BJRCBIb3AgaXMgdGhlIGxh c3QgRVItSG9wIGluIGFuIEVSLVRMViwgdGhhbiB0aGUgTFNSIG1heTxCUj5zcGxpY2UgdGhlIA0K ICBDUi1MU1Agb2YgdGhlIGluY29taW5nIExhYmVsIFJlcXVlc3QgdG8gdGhlIENSLUxTUCB0aGF0 PEJSPmN1cnJlbnRseSBleGlzdHMgDQogIHdpdGggdGhpcyBMU1BJRC4gVGhpcyBpcyB1c2VmdWws IGZvciBleGFtcGxlLCBhdDxCUj50aGUgcG9pbnQgYXQgd2hpY2ggYSBMYWJlbCANCiAgUmVxdWVz dCB1c2VkIGZvciBsb2NhbCByZXBhaXIgYXJyaXZlcyBhdDxCUj50aGUgbmV4dCBFUi1Ib3AgYWZ0 ZXIgdGhlIGxvb3NlbHkgDQogIHNwZWNpZmllZCBDUi1MU1Agc2VnbWVudC4gVXNlIG9mPEJSPnRo ZSBMU1BJRCBIb3AgaW4gdGhpcyBzY2VuYXJpbyBlbGltaW5hdGVzIA0KICB0aGUgbmVlZCBmb3Ig RVItSG9wcyB0bzxCUj5rZWVwIHRoZSBlbnRpcmUgcmVtYWluaW5nIEVSLVRMViBhdCBlYWNoIExT UiB0aGF0IA0KICBpcyBhdCBlaXRoZXI8QlI+KHVwc3RyZWFtIG9yIGRvd25zdHJlYW0pIGVuZCBv ZiBhIGxvb3NlbHkgc3BlY2lmaWVkIENSLUxTUCANCiAgc2VnbWVudDxCUj5hcyBwYXJ0IG9mIGl0 cyBzdGF0ZSBpbmZvcm1hdGlvbi4gVGhpcyBpcyBkdWUgdG8gdGhlIGZhY3QgdGhhdCANCiAgdGhl PEJSPnVwc3RyZWFtIExTUiBuZWVkcyBvbmx5IHRvIGtlZXAgdGhlIG5leHQgRVItSG9wIGFuZCB0 aGUgTFNQSUQgDQogIGFuZDxCUj50aGUgZG93bnN0cmVhbSBMU1IgbmVlZHMgb25seSB0byBrZWVw IHRoZSBMU1BJRCBpbiBvcmRlciBmb3IgDQogIGVhY2g8QlI+ZW5kIHRvIGJlIGFibGUgdG8gcmVj b2duaXplIHRoYXQgdGhlIHNhbWUgTFNQIGlzIGJlaW5nIA0KICBpZGVudGlmaWVkLjxCUj48QlI+ SW4gdGhpcyBpdCBjbGVhcmx5IHN0YXRlcyB0aGF0IGl0IGlzIG5vdCBvbmx5IHRoZSBJbmdyZXNz IA0KICBMRVIgYW5kIHRoZSBMU1JzPEJSPmluIHRoZSBwYXRoIG9mIHRoaXMgTFNQIGJ1dCBvdGhl ciBMRVJzIGFsc28gbmVlZCB0byBrbm93IA0KICB0aGUgTFNQLUlEIG9mPEJSPmRpZmZlcmVudCBM U1BzLiBUaGUgc2NlbmFyaW8gaXMgc29tZXRoaW5nIA0KICBsaWtlPEJSPjxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIExFUjEgLS0tLS0tJmd0OyANCiAgTFNSMi0tLS0t LS0tJmd0O0xTUjMtLS0tLS0mZ3Q7TFNSNDxCUj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICBMRVIyLS0tLS0tLS0mZ3Q7TFNSNTxCUj48QlI+dGhlcmUgaXMgYW4gTFNQ IHNldHVwIGFzIHNob3duIGZyb20gTEVSMSB0aHJ1IA0KICBMU1IyLExTUjMsIExTUjQuIE5vdyBM RVI1PEJSPnJlY2VpdmVzIGEgRVItVExWIHdoaWNoIHNheXMgaXQgaGFzIHRvIG1ha2UgDQogIGFu Jm5ic3A7IExTUCBmb3Igd2hpY2ggdGhlIG5leHQgaG9wPEJSPmlzIExTUjMgYW5kIHRoZSBhbHJl YWR5IGV4aXN0aW5nIExTUCANCiAgd2l0aCB0aGUgTFNQLUlEIGlzIHRvIGJlIHVzZWQuIE5vdyB0 aGU8QlI+cXVlc3Rpb24gaXMgaG93IGRvZXMgTFNSNSBvciBMRVIyIA0KICBjb21lIHRvIGtub3cg YWJvdXQgdGhpcyBwYXJ0aWN1bGFyIExTUC1JRDxCUj53aGljaCBhY3R1YWxseSBvcmlnaW5hdGVk IGF0IA0KICBMRVIxPzxCUj48QlI+c2FudG9zaDxCUj48QlI+c2FudG9zaGd1cHRhQHBvYm94ZXMu Y29tPEJSPjxCUj48QlI+LS0tLS0gT3JpZ2luYWwgDQogIE1lc3NhZ2UgLS0tLS08QlI+RnJvbTog U3VtaXQgR2FyZzxCUj5UbzogJ2FzaGlzaCc8QlI+U2VudDogVHVlc2RheSwgTWFyY2ggMjgsIA0K ICAyMDAwIDM6NDkgQTxCUj5TdWJqZWN0OiBSRTogQ1ItTERQPEJSPjxCUj48QlI+SGksPEJSPjxC Uj5MU0QtSUQgaXMgYSBUTFYgDQogIGRlZmluZWQgYnkgdGhlIENSLUxEUCBkcmFmdC4gSXQgaXMg YSBjb21iaW5hdGlvbiBvZiB0aGU8QlI+TFNSLUlEIGFuZCBhIDIgDQogIG9jdGVjdCBudW1iZXIg YXNzaWduZWQgYnkgdGhlIGluZ3Jlc3MvIGluaXRpYXRpbmcgTFNSLiBUaGlzPEJSPndvdWxkIHR5 cGljYWxseSANCiAgYmUgYW4gYWRtaW5pc3RvciBhc3NpZ25lZC8gbW9uaXRvcmVkIHF1YW50aXR5 IGFuZCB0aGVyZW9mPEJSPmtub3duIGEgcHJpb3JpIA0KICBmb3IgTFNQIHNwbGljaW5nLyB0dW5u ZWxpbmcuPEJSPjxCUj5UaGUgTFNQSUQgaXMgcHJvcGFnYXRlZCB0byBkb3duc3RyZWFtIExTUnMg DQogIGluIHRoZSBMU1Agc2V0dXAgcmVxdWVzdC48QlI+PEJSPlJlZ2FyZHM8QlI+U3VtaXQ8QlI+ PEJSPiZuYnNwOyAtLS0tLU9yaWdpbmFsIA0KICBNZXNzYWdlLS0tLS08QlI+Jm5ic3A7IEZyb206 IGFzaGlzaCANCiAgW21haWx0bzphc2hpc2hAZGFld29vLmR0aS5kYWV3b28uY28ua3JdPEJSPiZu YnNwOyBTZW50OiBNb25kYXksIE1hcmNoIDI3LCAyMDAwIA0KICAwMzo1OCBBTTxCUj4mbmJzcDsg VG86IG1wbHNAdXUubmV0PEJSPiZuYnNwOyBTdWJqZWN0OiBDUi1MRFA8QlI+PEJSPjxCUj4mbmJz cDsgDQogIEluIENSLUxEUCBkcmFmdC0wMywgb25lIG9mIHRoZSBFUi1IT1AgVExWIHR5cGVzIGNv bnRhaW4gTFNQSUQgZmllbGQgdGhhdDxCUj5pcyANCiAgdXNlZCBmb3IgdHVubmVsaW5nIHRocnUg c29tZSBleGlzdGluZyBMU1AgaGF2aW5nIHRoYXQgTFNQSUQgZmllbGQuPEJSPiZuYnNwOyANCiAg VGhpcyBtZWFucyB0aGF0IHRoYXQgTFNQSUQgc2hvdWxkIGJlIGtub3duIGluIGFkdmFuY2UgLjxC Uj4mbmJzcDsgSG93IGlzIHRoYXQgDQogIGRvbmUuPEJSPiZuYnNwOyBEb2VzIGluZm9ybWF0aW9u IHJlZ2FyZGluZyBlYWNoIExTUCBiZWluZyBjcmVhdGVkIGVhY2ggaGF2aW5nIA0KICB1bmlxdWU8 QlI+TFNQSUQgaXMgcHJvcGFnYXRlZCB0byBhbGwgTFNSJ3MuPEJSPiZuYnNwOyBQbGVhc2UgDQpj bGFyaWZ5LjxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --0__=4IqrKbTbXMRi8gMwEnGIugUxIIKvdkiaCzxKxOJOj5sJMuUIHnppwY2c-- From owner-mpls@UU.NET Tue Mar 28 09:51:05 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21629 for ; Tue, 28 Mar 2000 09:51:04 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiimd01232; Tue, 28 Mar 2000 14:51:05 GMT Received: by mail-control.mail.uu.net id QQiimd27457 for mpls-outgoing; Tue, 28 Mar 2000 14:50:32 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiimd27450 for ; Tue, 28 Mar 2000 14:50:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiimd07940 for ; Tue, 28 Mar 2000 09:50:15 -0500 (EST) Received: from kickme.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kickme.cisco.com [198.92.30.42]) id QQiimd06320 for ; Tue, 28 Mar 2000 14:50:15 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id GAA18253 for ; Tue, 28 Mar 2000 06:49:56 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA06842 for mpls@uu.net; Tue, 28 Mar 2000 09:49:59 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiilz15282 for ; Tue, 28 Mar 2000 13:56:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiilz29176 for ; Tue, 28 Mar 2000 08:56:43 -0500 (EST) Received: from inet-tsb.toshiba.co.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: inet-tsb.toshiba.co.jp [202.33.96.40]) id QQiilz01477 for ; Tue, 28 Mar 2000 13:56:42 GMT Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id WAA17229; Tue, 28 Mar 2000 22:52:19 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id WAA21257; Tue, 28 Mar 2000 22:52:19 +0900 (JST) Received: by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id WAA17076; Tue, 28 Mar 2000 22:52:18 +0900 (JST) To: ajithn@sg.ibm.com Cc: santoshg@daewoo.dti.daewoo.co.kr, sumitg@rocketmail.com, ashish@daewoo.dti.daewoo.co.kr, mpls@UU.NET Subject: Re: CR-LDP In-Reply-To: Your message of "Tue, 28 Mar 2000 15:33:15 +0800" References: X-Mailer: Mew version 1.92 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003281352.WAA17076@toshiba.co.jp> Date: Tue, 28 Mar 2000 22:33:15 +0900 From: Yoshihiro Ohba X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ajithn, > LSP-IDs become part of the "traffic engineering state" of the network. So > it is legitimate to define a CR-LSP, whose ingress is LER2, stacking or > splicing with an existing CR-LSP whose ingress is LER1, the latter being > specified by its LSP-ID. The entity which does traffic engineering can be > thought of as "higher" than the LSR, and it knows these LSP-IDs. At that > level, there is global (or, supra-local) knowledge. > However, from the point of view of LSRs, local knowledge is sufficient. > LSRs need to know only the LSP-IDs they participate in. > In your example, LER2 and LSR5 do not need to know the spliced/stacked > CR-LSP's LSP-ID because all they do with it is, just pass it downward. > That remains true as we go down the request path till we hit LSR3, for > which it is intended. So there is no need for non-participating LSRs to > be aware of the LSP-ID. There is an issue here on how an LSR that is not aware of the LSP-ID can determine who is the "downward" LSR for the LSP-ID. I think it depends on the FEC type used for the CR-LSP, that is, an opaque FEC should not be used in this case. If we use a prefix FEC or host address FEC, the "downward" LSR can be determined based on the FEC information. Yoshihiro Ohba > -- Ajith From owner-mpls@UU.NET Tue Mar 28 10:11:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21899 for ; Tue, 28 Mar 2000 10:11:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiime24308; Tue, 28 Mar 2000 15:11:46 GMT Received: by mail-control.mail.uu.net id QQiime07595 for mpls-outgoing; Tue, 28 Mar 2000 15:11:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiime07589 for ; Tue, 28 Mar 2000 15:11:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiime11661 for ; Tue, 28 Mar 2000 10:11:06 -0500 (EST) From: ajithn@sg.ibm.com Received: from ausmtp02.au.ibm.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ausmtp02.au.ibm.COM [202.135.136.105]) id QQiime14810 for ; Tue, 28 Mar 2000 15:10:59 GMT Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id BAA102826; Wed, 29 Mar 2000 01:06:19 +1000 Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id BAA30276; Wed, 29 Mar 2000 01:04:35 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568B0.0052CCD7 ; Wed, 29 Mar 2000 01:04:23 +1000 X-Lotus-FromDomain: IBMSG@IBMAU To: Yoshihiro Ohba cc: santoshg@daewoo.dti.daewoo.co.kr, sumitg@rocketmail.com, ashish@daewoo.dti.daewoo.co.kr, mpls@UU.NET Message-ID: Date: Tue, 28 Mar 2000 23:06:40 +0800 Subject: Re: CR-LDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Ohba, >Ajithn, > > > LSP-IDs become part of the "traffic engineering state" of the network. So > > it is legitimate to define a CR-LSP, whose ingress is LER2, stacking or > > splicing with an existing CR-LSP whose ingress is LER1, the latter being > > specified by its LSP-ID. The entity which does traffic engineering can be > > thought of as "higher" than the LSR, and it knows these LSP-IDs. At that > > level, there is global (or, supra-local) knowledge. > > > However, from the point of view of LSRs, local knowledge is sufficient. > > LSRs need to know only the LSP-IDs they participate in. > > > In your example, LER2 and LSR5 do not need to know the spliced/stacked > > CR-LSP's LSP-ID because all they do with it is, just pass it downward. > > That remains true as we go down the request path till we hit LSR3, for > > which it is intended. So there is no need for non-participating LSRs to > > be aware of the LSP-ID. > >There is an issue here on how an LSR that is not aware of the LSP-ID >can determine who is the "downward" LSR for the LSP-ID. > >I think it depends on the FEC type used for the CR-LSP, that is, >an opaque FEC should not be used in this case. If we use a prefix FEC or >host address FEC, the "downward" LSR can be determined based >on the FEC information. > >Yoshihiro Ohba > That sounds drastic, and I dont see a need to modify the FEC. The ER list is powerful enough to handle these kinds of cases. For the problem as stated (in Santosh's example), the (a?) correct way to formulate the ER list is where LSP-ID1 identifies the CR-LSP depicted as originating at LER1 and transiting through LSR-3. If that is the ER list, there remains no issue for LSR-3 in determining the downward LSR for LSP-ID1; LSR-3 already knows LSP-ID1. The case where LSP-ID1 is unknown to LSR-3 would be an error, and it should then reject the request. --Ajith | Ajith Narayanan From owner-mpls@UU.NET Tue Mar 28 10:14:47 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21932 for ; Tue, 28 Mar 2000 10:14:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiime17855; Tue, 28 Mar 2000 15:14:48 GMT Received: by mail-control.mail.uu.net id QQiime07753 for mpls-outgoing; Tue, 28 Mar 2000 15:14:17 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiime07741 for ; Tue, 28 Mar 2000 15:14:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiime25601 for ; Tue, 28 Mar 2000 10:13:50 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiime16907 for ; Tue, 28 Mar 2000 15:13:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA23997 for mpls@uu.net; Tue, 28 Mar 2000 10:13:45 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiime07669 for ; Tue, 28 Mar 2000 15:13:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiime25398 for ; Tue, 28 Mar 2000 10:12:55 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiime25588 for ; Tue, 28 Mar 2000 15:12:54 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 10:12:56 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F8E8@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Arun Viswanathan'" , "Cucchiara, Joan" , "'tnadeau@cisco.com'" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" Subject: RE: LSR MIB comments and questions Date: Tue, 28 Mar 2000 10:12:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Arun, (bunch of stuff deleted...) > > > > * mplsInSegmentXCIndex description is incorrect. A value > > of zero could certainly indicates a valid cross connect. > > The XC table does model XCs even for terminating InSegments > > and Originating OutSegments. > > > > The syntax clause should be changed in either this > > table or in the XC table since the syntax should be > > the same in both places. > > We meant it to be this way, that is, 0 is not a valid > XC index. 0 is used to indicate that the XC entries > have exhausted. Currently, mplsInSegmentXCIndex has: SYNTAX Integer32(1..2147483647) DESCRIPTION "The index into mplsXCTable is used to identify which cross-connect entry this segment is part of. Note that a value of zero indicates that it is not being referred to by any cross-connect entry." DEFVAL {0} Could this object be made a RowPointer? > > > > > * mplsInSegmentTSpecIndex -- this object needs to be made > > optional for LDP. > > Is already optional. A value of zero to indicate best effort. > See description. Why is it necessary for an LDP only implementation to support this? > > > > > * mplsInSegmentOwner -- could this be removed from the > > table. > > > > These object are of little value in my opinion because > > who really cares how the row got created? > > > > Also, if you have snmp and policyAgent, then you should > > add cli, config file, web, etc.... > > > > Just seems to be a big rat hole in my opinion. > > If you don't want to identify yourself, you can choose the > 'other' option ;-) > > It is there because folks asked for it. It provides > tracking for usage information, for troubleshooting, > and erroneous deletion by somebody how did not create > it in the first place. Are you planning on specifying in the enum the other possibilities (cli, config file, web, etc...)? Also, why is policyAgent one of the choices, this is a MIB and it was my understanding that policyAgent's used PIBs. PolicyAgents can't support RowStatus, so I believe that choice should be removed. > > > > > * mplsOutSegmentIndexNext object range should start at 0 (zero). > > No. 0 is bad index; is used to identify terminating connections > in the cross-connect. The description for this object says: "If the number of unassigned entries is exhausted, this object will take on the value of 0...." But the SYNTAX starts at 1, I believe that the SYNTAX should start at 0. > > > > > * mplsOutSegmentEntry is incorrect and should say 'outgoing' > > in place of incoming which I think someone else mentioned > > already. > > Evils of cut-and-paste. > > > > > Also REF clause should be updated > > Will be removed and description adjusted. > > > > > * mplsOutSegmentIfIndex should be not-accessible > > Hmmm..I guess so. > > > > > * mplsOutSegmentPushTopLabel's description is > > somewhat misleading with regard to the current > > version of LDP. In the case of LDP using ATM, the > > idea of a label popping does not apply. So it's > > misleading to say, it does not support pop-and-go. > > It does not support label popping at all. > > > A label swapping is modelled as a pop followed by a push. > See mplsInSegmentNPop. The description also talks about > the ATM case. > > > > > Could you rephrase this section to specifically > > call out that for Version 1 of LDP using ATM or FR this should > > be set to true and Reference Section 5. of the LDP Spec? > > I don't think we need to specially qualify LDP for this. This > is common to any protocol on ATM. I think that if you expect that people support this MIB for LDP then you should be more accomodating. I'm only asking for a clarifying description and reference to be added. > > > > > * mplsOutSegmentTopLabel > > > > Could this object be changed to contain the value of > > the top label on egress? I think it would be > > much more interesting to point to the egress label > > especially since the prior object (mplsOutSegmentPushTopLabel) > > tells whether or not this was pushed. > > > Hmm..I guess I don't understand the comment. > It already is what you are asking it to be. Sorry, my mistake. I think the name confused me, would you consider a name change to mplsOutSegmentLabel? I know that we discussed this before and the reason that you gave was that the MIB had been this way since Feb 1999, but I am still confused as to why you believe the indexing of this table to be better than (mplsOutSegmentIfIndex, mplsOutSegmentLabel) Also, this would imply a change to the XC table as being (mplsInSegmentIfIndex, mplsInSegmentLabel, mplsOutSegmentIfIndex and mplsOutSegmentLabel). Something to keep in mind is that the above is more in line with what is already being done in the internal XC tables, so forcing another indexing on top of that is somewhat inefficient for implementations to support. Could text be added as to why the present indexing is thought to be more efficient? > > > > > * mplsOutSegmentNextHopIpAddrType should use similar > > TC's as defined in draft-ops-endpoint-mib-07.txt > > Done. > > > > > Also, I have a question on this description: What is > > meant by the outgoing interface being point-to-point in > > the case of LDP using ATM? > > That is, 'none' is not a valid choice for any multi-access network. > > > > > * mplsOutSegmentNextHopIpv4Addr and mplsOutSegmentNextHopIpv6Addr > > these should be combined, and should also use the relevant > > TC in draft-ops-endpoint-mib-07.txt > > Yes. > > > > > * mplsXCIndexNext object's range should start at 0. > > It is alright the way it is. 0 is reserved to indicate > "no more cross-connect entries available". I agree but the SYNTAX clause starts at 1 and should start at 0. > > > > > * INDEX clause and description of the entry: > > > > The description redefines what a values of zero means > > for the mplsInSegmentIfIndex and mplsInSegmentLabel; > > in the mplsInSegmentTable they mean one thing, > > and yet, they mean something else in the XC table. > > > > Yes, they are different tables. > Index zero is valid only for the InSegemntTable. They may be different tables but they are the same indices, so they should be used the same everywhere they are referenced. It is not acceptable to redefine what a value means just because they are in different tables. > > > > > * mplsXCIndex should be not-accessible > > Okay. > > > > > * mplsXCCOS, should this object be made optional for > > LDP? > > Will remove this object based on comments on ML. > > > > > * mplsXCIsPersistent should have SYNTAX of StorageType > > Okay. > > > > > * mplsXCOwner same comment as before, big rat hole, could > > we get rid of this object? > > No, see comments above. see my comments above also :) > > > > > * What do the AdminStatus and OperStatus objects mean when > > the LSP is terminating or Originating for this entry? > > > > Admin status is provided to control the cross-connect from > passing data. Oper status may reflect the overall health of > the cross-connect, for example, if the outgoing interface is > down, then the cross-connect oper status may reflect that. But what do they mean in the case of a terminating or originating LSP which is in the XC table? If AdminStatus is down, what does this imply for a terminating LSP? Could the description be clarified to call this out, because this is something which could be interpretted differently by different vendors and needs to be clarified. Thanks, Joan > > -arun > From owner-mpls@UU.NET Tue Mar 28 10:19:51 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22003 for ; Tue, 28 Mar 2000 10:19:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiimf21519; Tue, 28 Mar 2000 15:19:52 GMT Received: by mail-control.mail.uu.net id QQiimf08362 for mpls-outgoing; Tue, 28 Mar 2000 15:19:19 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiimf08350 for ; Tue, 28 Mar 2000 15:19:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiimf26516 for ; Tue, 28 Mar 2000 10:18:52 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiimf20660 for ; Tue, 28 Mar 2000 15:18:47 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id KAA17223; Tue, 28 Mar 2000 10:18:39 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id KAA54508; Tue, 28 Mar 2000 10:19:02 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003281519.KAA54508@curtis-lt.avici.com> To: "Krishna Bala" cc: "Jagan Shantigram" , "Jonathan Lang" , curtis@avici.com, "Khaled Elsayed" , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Reply-To: curtis@avici.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Mon, 27 Mar 2000 18:24:01 EST." <00f801bf9843$888c2560$425cc697@tempest> Date: Tue, 28 Mar 2000 10:19:02 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <00f801bf9843$888c2560$425cc697@tempest>, "Krishna Bala" writes: > Jagan, > Just to beat a dead horse .. the difference between the open model > and the overlay is just that the overlay model typically suggests that > there would be N^2 connectivity (i.e., every router, for instance, is > statically connected to every other). In any case, the open model allows > for fully dynamic operation. The overlay model suggests static operation of > the optical layer. > > As I see it there are only two architectures that are worth considering: > 1. Peer > 2. Open > > I agree with you that there is no need to add the "overlay" model to > this list. The open model covers the static and the dynamic cases. > > Krishna In terms of visibility into the optical layer and control over path selection, the proposals on the talbe can be characterized as follows: 1. Static Overlay Model - paths endpoints are specified through a network management system though the paths may be laid out statically (by the NMS system) or dynamically (by the network elements). This is similar to ATM PVCs and SPVCs. [Note: networks built using the overlay model need not provide a full mesh contrary to misinformation provided on this mailing list. Today ATM PVC based IP backbones are often not built as full mesh networks to reduce the nuber of routing adjacencies.] 2. Signaled Overlay Model (aka "Open" model) - paths endpoints are specified through signaling via a UNI. Paths must be laid out dynamically since they are specified by signaling. This is similar to ATM SVCs. 3. Peer model - The network elements are provided enough information such that they MAY attempt to set up path in addition to specifying their endpoints. Paths may be laid out by the optical elements if the edge LSR provides only a static hop. Paths may be laid out by the LSR. Paths may also be laid out statically by having the NMS system configure explicit paths on the LSR and have those paths signaled. It was my understanding that the MPLS WG traffic engineering work was motivated largely by major Internet service provider's experience with ATM and was making an effort to avoid repeating the mistakes of the ATMF and therfore (among other differences between ATM and MPLS) is interested in the peer model. Note - If the OIF wants to ignore the experience that the Internet community has had with ATM and wants to ignore the feedback through the IETF of people involved in building those networks and and build IP routers with ATM interfaces that were constrained to make use of the interfaces that the ATMF chose to provide (in some cases omiting capabilities over the loud objections within IETF WGs such as IP over ATM) then that is a matter for OIF. If we are putting together a framework, then in addition to the "static overlay model" and "peer model", a distinction should be made and a separate "signaled overlay model" can be provided. In the interest of completelness the framework can point out that the OIF is working on a UNI which is based on the signaled overlay model. I prefer the term "signaled overlay model" over "open model" because the former is descriptive and that latter seems motivated by the desire to use the marketing buzzword "open" rather than provide a descriptive term. Some people had envisioned going directly from static overlay model to peer model or going directly to the peer model with the understanding that the LSR can still be configured with explicit paths from an NMS as long as quantifying and signaling impairments remains slightly beyond the state of the art and determining the impact of optical impairments remains a black art. Curtis From owner-mpls@UU.NET Tue Mar 28 10:21:31 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22031 for ; Tue, 28 Mar 2000 10:21:31 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiimf23080; Tue, 28 Mar 2000 15:21:33 GMT Received: by mail-control.mail.uu.net id QQiimf08525 for mpls-outgoing; Tue, 28 Mar 2000 15:21:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiimf08478 for ; Tue, 28 Mar 2000 15:21:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiimf26977 for ; Tue, 28 Mar 2000 10:21:01 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiimf22596 for ; Tue, 28 Mar 2000 15:21:00 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id KAA17415; Tue, 28 Mar 2000 10:20:56 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id KAA54527; Tue, 28 Mar 2000 10:21:20 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003281521.KAA54527@curtis-lt.avici.com> To: "James V. Luciani" cc: "Krishna Bala" , "Jagan Shantigram" , "Jonathan Lang" , curtis@avici.com, "Khaled Elsayed" , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Reply-To: curtis@avici.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Mon, 27 Mar 2000 18:41:54 EST." <009e01bf9846$0cc47ec0$a4d0fea9@jluciani> Date: Tue, 28 Mar 2000 10:21:20 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <009e01bf9846$0cc47ec0$a4d0fea9@jluciani>, "James V. Luciani" writes : > 1) X > 2) Peer > where X is the PC term for what we want to get at. So my opine is that > X="augmented routing model"/ARM model. > > Do I hear a hmmmm??? > --Jim cough. From owner-mpls@UU.NET Tue Mar 28 10:23:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22044 for ; Tue, 28 Mar 2000 10:23:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiimf05509; Tue, 28 Mar 2000 15:23:39 GMT Received: by mail-control.mail.uu.net id QQiimf08655 for mpls-outgoing; Tue, 28 Mar 2000 15:23:05 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiimf08650 for ; Tue, 28 Mar 2000 15:22:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiimf14122 for ; Tue, 28 Mar 2000 10:22:55 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiimf24291 for ; Tue, 28 Mar 2000 15:22:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA26343 for mpls@uu.net; Tue, 28 Mar 2000 10:22:54 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiimf08626 for ; Tue, 28 Mar 2000 15:22:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiimf13943 for ; Tue, 28 Mar 2000 10:22:26 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiimf23881 for ; Tue, 28 Mar 2000 15:22:26 GMT Received: from rschmitt-nt (ch2-dhcp134-243.cisco.com [161.44.134.243]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA26103; Tue, 28 Mar 2000 10:22:07 -0500 (EST) Message-Id: <4.2.0.58.20000328100217.00a4c2d0@pilgrim.cisco.com> X-Sender: rschmitt@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 28 Mar 2000 10:24:35 -0800 To: Arun Viswanathan From: Rob Schmitt Subject: RE: LSR MIB comments and questions Cc: "'Joan Cucchiara'" , "'tnadeau@cisco.com'" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" , "'mpls@uu.net'" In-Reply-To: <0F8929E5ED5FD311B892005004CED4A634685A@tonga.ncorenetworks .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I also question why this extra variable is required to convey the label space membership attributes. If mplsInterfaceConfIndex is zero, then it uneqivocally has the attributes 'in global label space' and 'not in local label space'. If mplsInterfaceConfIndex is non-zero, that it uneqivocally has the attribute 'in local label space' and the 'in global label space' variable arbitrates that (optional) attribute. So Joan's point that the value of mplsInterfaceConfIndex is sufficient to describe membership is valid. /rs At 08:50 PM 3/27/00 -0800, Arun Viswanathan wrote: > > * Does the 'mplsInterfaceIsLocalLabelSpace' indicate > > per interface label space only? > > > > I am confused why you need this object, it would > > seem that if the value of mplsInterfaceConfIndex is > > non-zero then this means that it is a per Interface > > label space, and that the 'mplsInterfaceIsGlobalLabelSpace' > > would indicate if it is participating in a global Label Space > > also. > >Interfaces that have interface specific label space may also >want to participate in global label space. The two objects, >[...]LabelSpace, together enable that. From owner-mpls@UU.NET Tue Mar 28 10:29:11 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22121 for ; Tue, 28 Mar 2000 10:29:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiimf28431; Tue, 28 Mar 2000 15:29:08 GMT Received: by mail-control.mail.uu.net id QQiimf09146 for mpls-outgoing; Tue, 28 Mar 2000 15:28:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiimf09139 for ; Tue, 28 Mar 2000 15:28:40 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiimf15193 for ; Tue, 28 Mar 2000 10:28:22 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiimf27814 for ; Tue, 28 Mar 2000 15:28:21 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA27792 for mpls@uu.net; Tue, 28 Mar 2000 10:28:20 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiimf09120 for ; Tue, 28 Mar 2000 15:27:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiimf28225 for ; Tue, 28 Mar 2000 10:27:34 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiimf27366 for ; Tue, 28 Mar 2000 15:27:34 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 10:27:36 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F8E9@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Arun Viswanathan'" , "Cucchiara, Joan" , "'tnadeau@cisco.com'" , "'cheenu@tachion.com'" Cc: "'mpls@uu.net'" Subject: RE: Additional comments on the LSR MIB Date: Tue, 28 Mar 2000 10:27:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > > > > * The mplsLabelStackTable should be made optional for LDP LSPs > > which use ATM or FR. Could this be added in > > the conformance section? > > It already supports non-stackable environments. That is not really the issue, the issue is why does LDP using ATM or FR need to support this table? It is some amount of overhead and no help whatsoever for this case. Also, the concept of having to support a LabelStack in these cases is misleading. This should be made optional. > > > > > * mplsTSpecIndexNext should start at zero. > > See description of mplsTSpecIndexNext. DESCRIPTION says: "...The value 0 indicates that no unassigned entries are available...." The SYNTAX clause starts at 1 and it should start at 0. > > > > > * mplsTSpecMeanRate -- what is the agent or mpls > > supposed to do with this value? > > > > Is the mean rate for an LSP calculated over time? > > No. This is one of the tuple for defining a token bucket. > The agent has to ensure that the specified QoS requirement > for the LSP is met. > > > > > * mplsTSpecMaxRate and mplsTSpecMaxBurstSize: are > > these objects related? If so, could an explanation > > be given of how they are related? Can the BurstSize > > exceed the MaxRate? What does it mean if this happens? > > See above comments. > > > > > * Is this table going to be made optional for LDP? > > See my comments to your previous set of comments. Which ones? > > > > > * Could we have a description of what happens when the > > InSegment TSpec values are lower than the OutSegment > > TSpec values? (Seems like there should be some > > co-operation between the objects, or at least some > > "actual" objects which reflect what the true values > > are.) > > The implication of such things may be platform specific. I completely agree which is why I suggest adding "actual" objects to see what the "real" values are. Just because something is configured does not mean that those are the actual rates/burst size. > > > > > Why does one need to specify the TSpec for the > > InSegment? It would seem that the OutSegment is > > relevant and that the InSegment is not really > > configurable, could you explain why it is needed > > for the InSegment? > > Multipoint-to-point LSPs. That still doesn't explain what it means to configure values for an InSegment and how it relates to the OutSegment which could have different (i.e. higher values). Could an explanation be added for the situations where the OutSegment is lower than the InSegment and vice versa? > > > > > * Could the individual trap enable/disable objects be placed near > > their respective information? (NOTE: they are grouped > > differently in the conformance section which is more where > > you would expect the objects to be in the MIB.) > > Will consider. > > > > > * In general, the MIB heirarchy could use some heirarchy :) > > Seems like everything is under 'mplsLsrObjects'. > > Will fix that. > > > > > * In general, the Index objects which have MIN-ACCESS of read-only > > should be fixed in the mib to have not-accessible access and > > removed from the Conformance section. > > If this is the general approach in other MIBs, will do so. > > > > > * The conformance information for the following object > > is worrisome because it is not clear under which circumstances > > one would not support all the enums. > > > > OBJECT mplsInSegmentAddrFamily > > SYNTAX INTEGER { other(0) } > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required. A value of > > other(0) should be supported." > > > > If the agent can't tell or doesn't know what the Address Family > > is, then how are all the counters effected (specifically > > packet and octet counters) that are related to this > > InSegment on an MPLS Interface? > > Addr family if for the MPLS payload. Counters are for MPLS 'frames'. > MPLS counters may go up independent of payload type. The only time that other(0) would be valid is when the value is not one of the other AddressFamily types. The way this Conformance Info is written leads me to believe that "other" is being used to mean something different. What does the value of "other" in this context mean? Thanks, Joan > > > > > OBJECT mplsOutSegmentIndexNext > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required." > > > > OBJECT mplsXCIndexNext > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required." > > > > OBJECT mplsXCLabelStackIndexNext > > MIN-ACCESS read-only > > DESCRIPTION > > "Write access is not required." > > > > The above already have a MAX-ACCESS of read-only. > > > > > > > -arun > From owner-mpls@UU.NET Tue Mar 28 12:20:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23891 for ; Tue, 28 Mar 2000 12:20:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiimn06536; Tue, 28 Mar 2000 17:20:34 GMT Received: by mail-control.mail.uu.net id QQiimn03272 for mpls-outgoing; Tue, 28 Mar 2000 17:20:10 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiimn03267 for ; Tue, 28 Mar 2000 17:20:01 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiimn06285 for ; Tue, 28 Mar 2000 12:19:58 -0500 (EST) Received: from hercules by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQiimn05882 for ; Tue, 28 Mar 2000 17:19:57 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id JAA18922; Tue, 28 Mar 2000 09:19:53 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 09:19:53 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A634685C@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Juha Heinanen'" , "'mpls@UU.NET'" Subject: RE: tspec table Date: Tue, 28 Mar 2000 09:19:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Juha, > in the lsr mib, tspec table only supports intserv style traffic > parameters and thus sort of assumes that the lsp was set up > using rsvp. > cr-ldp has another set of traffic parameters. shall we add another > optional table, e.g., mlpsTrafficTable, that includes cr-ldp traffic > parameters or how do you want to handle this? > While defining the LSR MIB, one of the primary objective was to keep it protocol agnostic. However, QoS being an inherent property of an LSR (or for that matter an LSP) we choose a generally acceptable way of defining QoS, that is, using token bucket. But if try to extend that to support various other QoS specifications, then we may not find an end to this. Sometime back we raised this issue. It would be nice if we had another MIB that modeled QoS and admission control on a router/LSR, and we could simply point to the table and be done with. Unfortunately nothing like that exists, besides we didn't measure any interest in the WG on the issue of having a common QoS resources MIB. Hence the simple token bucket approach. I believe trying to expand the scope of the TSpec table to satisfy various QoS specifications is an undertaking in itself and outside the scope of this document IMHO, but if it were available we would have surely used it. > -- juha > > ps. why is the mib called lsr rather than mlps node mib, > since i haven't > found in it anything that releates to forwarding of layer 3 packets? > > Considering that an MPLS node will run one or more of the MPLS protocols and one or more of the L3 routing protocols, will be "capable of forwarding native L3 packets". However, we will add some text in the introduction section to stay clear of any ambiguity. -arun From owner-mpls@UU.NET Tue Mar 28 12:49:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24312 for ; Tue, 28 Mar 2000 12:49:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiimp00335; Tue, 28 Mar 2000 17:49:27 GMT Received: by mail-control.mail.uu.net id QQiimp05345 for mpls-outgoing; Tue, 28 Mar 2000 17:48:50 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiimp05338 for ; Tue, 28 Mar 2000 17:48:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiimp26276 for ; Tue, 28 Mar 2000 12:48:20 -0500 (EST) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kahu.new-access.com [216.217.10.2] (may be forged)) id QQiimp12676 for ; Tue, 28 Mar 2000 17:48:19 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 09:52:07 -0800 Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7B90@ICARIAN> From: Eric Gray To: "'Vijay Srinivasan'" Cc: "'MPLS Working Group'" Subject: Re: Updated Charter Date: Tue, 28 Mar 2000 09:52:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Vijay, Sorry I was unable to attend the meeting. I have the following general observations to make about the updated MPLS charter. There are interesting implications in the new MPLS charter. The goal of reducing the number of directly connected peers by physically co-locating forwarding and routing functionality is made simpler by the MPLS technology itself. At the same time, reducing the number of directly connected peers in any network of a given size increases the radius of the network in terms of the number of routers that must be traversed by both routing protocol interactions and data being forwarded - thus complicating the process of route convergence. In addition, the goal of being able to peer with devices directly connected to each interface may impose requirements for additional router protocol support on each and every device. I am not saying that this goal is not a good idea, but I think it is important that people do not get the idea that the goals in the updated MPLS charter will result necessarily in cheaper switches or more scalable networks unless it is also a goal of the MPLS working group to provide routing that is MORE stable than currently existing. Which I do not believe is the case, in spite of the ambiguity in bullet number 5 under High Level Requirements. -- Eric Gray From owner-mpls@UU.NET Tue Mar 28 14:01:08 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25039 for ; Tue, 28 Mar 2000 14:01:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiimu20851; Tue, 28 Mar 2000 19:00:47 GMT Received: by mail-control.mail.uu.net id QQiimu18391 for mpls-outgoing; Tue, 28 Mar 2000 19:00:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiimu18151 for ; Tue, 28 Mar 2000 19:00:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiimu00750 for ; Tue, 28 Mar 2000 14:00:03 -0500 (EST) Received: from mailhost.iitb.ac.in by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [202.54.44.115]) id QQiimt10927 for ; Tue, 28 Mar 2000 18:59:59 GMT Received: (qmail 29263 invoked from network); 28 Mar 2000 19:16:45 -0000 Received: from bhairav.ee.iitb.ernet.in (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 28 Mar 2000 19:16:45 -0000 Received: from localhost (gabhijit@localhost) by bhairav.ee.iitb.ernet.in (8.8.8/8.8.8) with SMTP id AAA02501 for ; Wed, 29 Mar 2000 00:31:15 +0530 (IST) Date: Wed, 29 Mar 2000 00:31:15 +0530 (IST) From: Abhijit To: mpls@UU.NET Subject: Using Hop by hop path as lsp in draft-ietf-mpls-arch-06.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi all In draft-ietf-mpls-arch-06.txt , in section 4.1.3, the example given says that 4.1.3. Using the Hop by Hop path as the LSP Following lines are included from the draft -----> If the hop-by-hop path that packet P needs to follow is , then can be an LSP as long as: 1. there is a single address prefix X, such that, for all i, 1<=i; Tue, 28 Mar 2000 14:06:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiimu25335; Tue, 28 Mar 2000 19:06:17 GMT Received: by mail-control.mail.uu.net id QQiimu25356 for mpls-outgoing; Tue, 28 Mar 2000 19:05:58 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiimu25336 for ; Tue, 28 Mar 2000 19:05:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiimu16921 for ; Tue, 28 Mar 2000 14:05:38 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiimu15454 for ; Tue, 28 Mar 2000 19:05:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA02374 for mpls@uu.net; Tue, 28 Mar 2000 14:05:36 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiimu25126 for ; Tue, 28 Mar 2000 19:04:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiimu16589 for ; Tue, 28 Mar 2000 14:03:47 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiimu23474 for ; Tue, 28 Mar 2000 19:03:47 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 14:03:48 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F8F2@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Santosh Gupta'" , mpls@UU.NET Cc: "'arun@force10networks.com'" , "'tnadeau@cisco.com'" , "'cheenu@tachion.com'" Subject: RE: LDP MIB Date: Tue, 28 Mar 2000 14:03:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Santosh, Are you asking about the LSR MIB, draft-ietf-mpls-lsr-mib-02.txt? If so then I think these are the same thing. Could LSR MIB authors clarify this as I didn't see any description of "GlobalLabelSpace" in the Framework or Arch documents, so the term is one which should be defined someplace? I have a similar comment with the term LocalLabelSpace which means per-platform...could these terms be clarified? (Actually, using per-platform and per-interface instead of these other terms would be preferable in my opinion, but would be okay with clarifying these terms....) Thanks, Joan -----Original Message----- >From: Santosh Gupta [mailto:santoshg@daewoo.dti.daewoo.co.kr] >Sent: Tuesday, March 28, 2000 12:42 AM >To: mpls@UU.NET >Subject: LDP MIB > > >Hi > In draft-ietf-mpls-ldp-mib-02.txt there are references to "GlobalLabelSpace" ? >and "PlatformLabelSpace". Could anyone help me out as to what they mean? >Thanx in advance. >santosh > >santoshgupta@poboxes.com > From owner-mpls@UU.NET Tue Mar 28 17:18:49 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27428 for ; Tue, 28 Mar 2000 17:18:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiinh16379; Tue, 28 Mar 2000 22:18:26 GMT Received: by mail-control.mail.uu.net id QQiinh03013 for mpls-outgoing; Tue, 28 Mar 2000 22:18:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiinh03004 for ; Tue, 28 Mar 2000 22:17:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiinh08659 for ; Tue, 28 Mar 2000 17:17:49 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiinh15787 for ; Tue, 28 Mar 2000 22:17:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA03075 for mpls@uu.net; Tue, 28 Mar 2000 17:17:48 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiinh02964 for ; Tue, 28 Mar 2000 22:17:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiinh08593 for ; Tue, 28 Mar 2000 17:17:14 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQiinh02057 for ; Tue, 28 Mar 2000 22:17:13 GMT Received: from tnadeau-pc02 (ch-janeiro-p16.cisco.com [171.69.209.220]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA28797; Tue, 28 Mar 2000 17:17:03 -0500 (EST) Message-Id: <4.2.2.20000328163624.070de870@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 28 Mar 2000 16:37:36 -0500 To: Rob Schmitt , Arun Viswanathan From: "Thomas D. Nadeau" Subject: RE: LSR MIB comments and questions Cc: "'Joan Cucchiara'" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" , "'mpls@uu.net'" In-Reply-To: <4.2.0.58.20000328100217.00a4c2d0@pilgrim.cisco.com> References: <0F8929E5ED5FD311B892005004CED4A634685A@tonga.ncorenetworks .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, >I also question why this extra variable is required to >convey the label space membership attributes. > >If mplsInterfaceConfIndex is zero, then it uneqivocally >has the attributes 'in global label space' and 'not in >local label space'. > >If mplsInterfaceConfIndex is non-zero, that it uneqivocally >has the attribute 'in local label space' and the 'in >global label space' variable arbitrates that (optional) >attribute. Yes, but there are cases in ATM where an interface needs to be part of both label spaces. This is why we have provided two separate variables here. --Tom From owner-mpls@UU.NET Tue Mar 28 17:19:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27440 for ; Tue, 28 Mar 2000 17:19:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiinh03433; Tue, 28 Mar 2000 22:19:12 GMT Received: by mail-control.mail.uu.net id QQiinh03039 for mpls-outgoing; Tue, 28 Mar 2000 22:18:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiinh03023 for ; Tue, 28 Mar 2000 22:18:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiinh24985 for ; Tue, 28 Mar 2000 17:18:10 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiinh16035 for ; Tue, 28 Mar 2000 22:18:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA03140 for mpls@uu.net; Tue, 28 Mar 2000 17:18:09 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiinh02983 for ; Tue, 28 Mar 2000 22:17:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiinh24899 for ; Tue, 28 Mar 2000 17:17:30 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQiinh02198 for ; Tue, 28 Mar 2000 22:17:25 GMT Received: from tnadeau-pc02 (ch-janeiro-p16.cisco.com [171.69.209.220]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA28817; Tue, 28 Mar 2000 17:17:09 -0500 (EST) Message-Id: <4.2.2.20000328163759.070dfe10@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 28 Mar 2000 16:44:15 -0500 To: "Cucchiara, Joan" , "'Arun Viswanathan'" , "Cucchiara, Joan" , "'cheenu@tachion.com'" From: "Thomas D. Nadeau" Subject: RE: Additional comments on the LSR MIB Cc: "'mpls@uu.net'" In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB15F8E9@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4714471==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_4714471==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, > > > * The mplsLabelStackTable should be made optional for LDP LSPs > > > which use ATM or FR. Could this be added in > > > the conformance section? > > > > It already supports non-stackable environments. > >That is not really the issue, the issue is why does >LDP using ATM or FR need to support this table? > >It is some amount of overhead and no help whatsoever >for this case. Also, the concept of having to support >a LabelStack in these cases is misleading. This >should be made optional. Are you then advocating making it optional in the conformance statement? With regard to some of your other questions where you requested that additional text be added to descriptions, could you please provide the text that you feel would make the object clearer or better defined so that we can just look over your text and decide whether or not it can go in, or perhaps just tweak the text a bit and then add it? Otherwise we will change the text, re-publish the document, and then have to field additional comments. I don't like being pedantic, but I am just trying to get explicit opinions here so that we can reach a quick and specific consensus on these last remaining issues. I hope that you understand. 8) --Tom --=====================_4714471==_.ALT Content-Type: text/html; charset="us-ascii"
        Hi,

> > * The mplsLabelStackTable should be made optional for LDP LSPs
> >   which use ATM or FR.  Could this be added in
> >   the conformance section?
>
> It already supports non-stackable environments.

That is not really the issue, the issue is why does
LDP using ATM or FR need to support this table?

It is some amount of overhead and no help whatsoever
for this case.  Also, the concept of having to support
a LabelStack in these cases is misleading.  This
should be made optional.

        Are you then advocating making it optional
in the conformance statement?

        With regard to some of your other questions
where you requested that additional text be added to
descriptions, could you please provide the text that
you feel would make the object clearer or better
defined so that we can just look over your
text and decide whether or not it can go in, or
perhaps just tweak the text a bit and then add it?
Otherwise we will change the text, re-publish the
document, and then have to field additional comments.

        I don't like being pedantic, but I am just
trying to get explicit opinions here so that we
can reach a quick and specific consensus on these
last remaining issues. I hope that you
understand. 8)

        --Tom

        
--=====================_4714471==_.ALT-- From owner-mpls@UU.NET Tue Mar 28 21:38:31 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01426 for ; Tue, 28 Mar 2000 21:38:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiinx09949; Wed, 29 Mar 2000 02:23:13 GMT Received: by mail-control.mail.uu.net id QQiinx19043 for mpls-outgoing; Wed, 29 Mar 2000 02:22:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiinx19034 for ; Wed, 29 Mar 2000 02:22:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiinx08093 for ; Tue, 28 Mar 2000 21:22:23 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiinx01607 for ; Wed, 29 Mar 2000 02:22:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA25331 for mpls@uu.net; Tue, 28 Mar 2000 21:22:15 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiinf23894 for ; Tue, 28 Mar 2000 21:59:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiinf05598 for ; Tue, 28 Mar 2000 16:59:48 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiinf20476 for ; Tue, 28 Mar 2000 21:59:48 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 16:59:49 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F8F7@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "Cucchiara, Joan" , "'Santosh Gupta'" , mpls@UU.NET Cc: "'arun@force10networks.com'" , "'tnadeau@cisco.com'" , "'cheenu@tachion.com'" Subject: RE: LDP MIB Date: Tue, 28 Mar 2000 16:59:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Cucchiara, Joan [mailto:JCucchiara@Brixnet.com] > Sent: Tuesday, March 28, 2000 2:04 PM > To: 'Santosh Gupta'; mpls@UU.NET > Cc: 'arun@force10networks.com'; 'tnadeau@cisco.com'; > 'cheenu@tachion.com' > Subject: RE: LDP MIB > > > > Hi Santosh, > > Are you asking about the LSR MIB, draft-ietf-mpls-lsr-mib-02.txt? > > If so then I think these are the same thing. > > Could LSR MIB authors clarify this as I didn't see any > description of "GlobalLabelSpace" in the Framework or Arch > documents, so the term is one which should be defined someplace? > > I have a similar comment with the term LocalLabelSpace which > means per-platform...could these terms be clarified? Sorry, I meant to type per-interface in the above line. (so Local is equivalent to per-interface, and global is equivalent to per-platform). > > (Actually, using per-platform and per-interface instead of > these other terms would be preferable in my opinion, but would > be okay with clarifying these terms....) > > Thanks, Joan > > > -----Original Message----- > >From: Santosh Gupta [mailto:santoshg@daewoo.dti.daewoo.co.kr] > >Sent: Tuesday, March 28, 2000 12:42 AM > >To: mpls@UU.NET > >Subject: LDP MIB > > > > > >Hi > > In draft-ietf-mpls-ldp-mib-02.txt there are references to > "GlobalLabelSpace" ? > >and "PlatformLabelSpace". Could anyone help me out as to > what they mean? > >Thanx in advance. > >santosh > > > >santoshgupta@poboxes.com > > > From owner-mpls@UU.NET Tue Mar 28 21:42:28 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01446 for ; Tue, 28 Mar 2000 21:42:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiny10452; Wed, 29 Mar 2000 02:36:39 GMT Received: by mail-control.mail.uu.net id QQiiny19876 for mpls-outgoing; Wed, 29 Mar 2000 02:36:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiny19871 for ; Wed, 29 Mar 2000 02:36:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiny09491 for ; Tue, 28 Mar 2000 21:36:15 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiiny10045 for ; Wed, 29 Mar 2000 02:36:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA26677 for mpls@uu.net; Tue, 28 Mar 2000 21:36:14 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiny19776 for ; Wed, 29 Mar 2000 02:35:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiny09467 for ; Tue, 28 Mar 2000 21:35:56 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQiiny09844 for ; Wed, 29 Mar 2000 02:35:56 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id FAA24078; Wed, 29 Mar 2000 05:35:55 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14561.27659.583674.64984@lohi.eng.telia.fi> Date: Wed, 29 Mar 2000 05:35:55 +0300 (EEST) To: mpls@UU.NET Subject: tspec table X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit arun, i'm not sure if the tspec table has much value if it only contains a set of leaky bucket parameters. it should be accurately describe the traffic characteristics (traffic class(es) plus traffic parameters) of the lsps. if the traffic characteristics currenly expressable by rsvp and crldp are not all included, then it would be better to leave the whole table out until we have a proper qos mib to refer to. -- juha From owner-mpls@UU.NET Tue Mar 28 22:30:18 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02721 for ; Tue, 28 Mar 2000 22:30:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiob18535; Wed, 29 Mar 2000 03:29:40 GMT Received: by mail-control.mail.uu.net id QQiiob00370 for mpls-outgoing; Wed, 29 Mar 2000 03:29:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiob00365 for ; Wed, 29 Mar 2000 03:29:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiob14468 for ; Tue, 28 Mar 2000 22:29:14 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiiob17536 for ; Wed, 29 Mar 2000 03:29:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA00640 for mpls@uu.net; Tue, 28 Mar 2000 22:29:13 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiiob00356 for ; Wed, 29 Mar 2000 03:28:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiob00125 for ; Tue, 28 Mar 2000 22:28:41 -0500 (EST) Received: from ficon-tech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [12.10.198.190]) id QQiiob17722 for ; Wed, 29 Mar 2000 03:28:37 GMT Received: from ficon-tech.com (acheru.india.ficon-tech.com [172.25.1.113]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id IAA91884; Wed, 29 Mar 2000 08:51:52 +0530 (IST) (envelope-from acheru@ficon-tech.com) Message-ID: <38E177AD.31BEEE4F@ficon-tech.com> Date: Wed, 29 Mar 2000 08:55:33 +0530 From: Anup Anil Cheruvathoor Organization: Ficon Technology X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: Abhijit CC: mpls@UU.NET Subject: Re: Using Hop by hop path as lsp in draft-ietf-mpls-arch-06.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Typically the aggregation of routes are configured through policies, to reduce the volume of routing updates or some administrative reasons. So the routing protocol which is advertising a agregated route has information that the it is the point of deaggregation. So when a packet with FEC say P and it matches to an advertised aggrgated route then the LSR knows that it has to perform deaggregation. Regardx, -Cheru Abhijit wrote: > Hi all > > In draft-ietf-mpls-arch-06.txt , in section 4.1.3, the example given says > that 4.1.3. Using the Hop by Hop path as the LSP > > Following lines are included from the draft > -----> > If the hop-by-hop path that packet P needs to follow is Rn>, then can be an LSP as long as: > > 1. there is a single address prefix X, such that, for all i, > 1<=i destination address; > > 2. for all i, 1 that label to R[i-1]. > > Note that a packet's LSP can extend only until it encounters a router > whose forwarding tables have a longer best match address prefix for > the packet's destination address. At that point, the LSP must end and > the best match algorithm must be performed again. > > Suppose, for example, that packet P, with destination address > 10.2.153.178 needs to go from R1 to R2 to R3. Suppose also that R2 > advertises address prefix 10.2/16 to R1, but R3 advertises > 10.2.153/23, 10.2.154/23, and 10.2/16 to R2. That is, R2 is > advertising an "aggregated route" to R1. In this situation, packet P > can be label Switched until it reaches R2, but since R2 has performed > route aggregation, it must execute the best match algorithm to find > P's FEC. > <------------ > > My question is R3 in this case should not advertise prefix 10.2/16 to R2 > as when the Label Request for FEC 10.2/16 comes to R2, it > can assign a binding to it and can forward that request to R3, wherein R3 > can in turn give the binding to R2 again, but when the labelled packet > arrives at R2 it forwards it to R3 and there is no way for R3 to know now > where it should forward that packet. > > In Other words how can R2 know that it has better prefix match than > 10.2/16 and thus issue a new request to R3. and stop Label Switching the > packets there? > > Thanks in advance > > Abhijit -- Name : Anup Anil Chervathoor E-mail : mailto:acheru@ficon-tech.com Web : www.ficon-tech.com From owner-mpls@UU.NET Tue Mar 28 23:27:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03964 for ; Tue, 28 Mar 2000 23:27:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiof28349; Wed, 29 Mar 2000 04:26:46 GMT Received: by mail-control.mail.uu.net id QQiiof11259 for mpls-outgoing; Wed, 29 Mar 2000 04:26:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiof11231 for ; Wed, 29 Mar 2000 04:26:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiof20102 for ; Tue, 28 Mar 2000 23:26:06 -0500 (EST) Received: from smtp6.mindspring.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQiiof18361 for ; Wed, 29 Mar 2000 04:26:05 GMT Received: from jluciani (ip133.cambridge2.ma.pub-ip.psi.net [38.32.112.133]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id XAA28397; Tue, 28 Mar 2000 23:25:07 -0500 (EST) Message-ID: <007a01bf9936$ca31ac80$3c03fea9@jluciani> Reply-To: "James V. Luciani" From: "James V. Luciani" To: "Yakov Rekhter" Cc: "Krishna Bala" , "Jagan Shantigram" , "Jonathan Lang" , , "Khaled Elsayed" , , References: <200003280031.QAA28158@omega.cisco.com> Subject: Re: Comments on draft-ip-optical-framework-00.txt Date: Tue, 28 Mar 2000 23:25:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov, Wow, such rapier-like wit and technical depth all wrapped in a one-liner. Now if you would like to help clarify the issue rather than snipe at someone who is trying to be helpful, I for one would like to hear your input. --Jim ----- Original Message ----- From: Yakov Rekhter To: James V. Luciani Cc: Krishna Bala ; Jagan Shantigram ; Jonathan Lang ; ; Khaled Elsayed ; ; Sent: Monday, March 27, 2000 7:31 PM Subject: Re: Comments on draft-ip-optical-framework-00.txt > Jim, > > > > Just to beat a dead horse .. the difference between the open model > > > and the overlay is just that the overlay model typically suggests that > > > > That depends... see below. > > > > > there would be N^2 connectivity (i.e., every router, for instance, is > > > statically connected to every other). In any case, the open model allows > > > > While there may indeed be some misunderstanding as to the meaning of the > > "overlay model" (not to mention the meaning of the other models :-)), the > > traditional definition of overlay is not one of static operation. NHRP and > > MPOA, for example, are overlay in my book (and most folks that I know). > > > > They most certainly imply non-static connections by defintion (i.e., use of > > SVCs). This having been said, I believe that we can do one of two things > > here. One, keep the current terms and potentially risk an ad nauseum > > inspection of the meaning of these terms; or two, come up with a term which > > is satisfactory to all. In the second case we would have models: > > 1) X > > 2) Peer > > where X is the PC term for what we want to get at. So my opine is that > > X="augmented routing model"/ARM model. > > > > Do I hear a hmmmm??? > > I think you do. And it comes from you - it is your own hmmm. > > Yakov. From owner-mpls@UU.NET Wed Mar 29 00:07:45 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04735 for ; Wed, 29 Mar 2000 00:07:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiioi16355; Wed, 29 Mar 2000 05:07:28 GMT Received: by mail-control.mail.uu.net id QQiioi21102 for mpls-outgoing; Wed, 29 Mar 2000 05:07:05 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiioi21097 for ; Wed, 29 Mar 2000 05:07:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiioi24658 for ; Wed, 29 Mar 2000 00:06:56 -0500 (EST) Received: from exchsrv1.cosinecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: proxy5.cosinecom.com [208.248.148.134]) id QQiioi20161 for ; Wed, 29 Mar 2000 05:06:55 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 21:06:43 -0800 Message-ID: From: Vijay Srinivasan To: "'mpls@uu.net'" Subject: yet another revision of the charter Date: Tue, 28 Mar 2000 21:06:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF993C.931292FE" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF993C.931292FE Content-Type: text/plain; charset="iso-8859-1" Hi folks, Here is another revision of the charter, based upon discussion at today's WG meeting. I have added the following objectives: -- 11. Specify standard protocols and procedures to enable header compression across a single link as well as across an LSP. 12. Specify appropriate extensions to LDP and RSVP for authentication of LSP originators. 13. Define requirements and standard protocols and procedures for policy support in MPLS-based networks. This work will be complementary to, and will build upon, other policy-related work ongoing in the IETF. -- We did not discuss milestones for the policy and authentication work. Your input on these would be appreciated. Regards, - Chairs ----------------------------------------------------------------------- Multiprotocol Label Switching (mpls) Charter Problem Statement: Label switching in conjunction with network layer routing has emerged as an important new technology. It is actively being applied to applications such as traffic engineering and virtual private networks. Among the problems this technology is expected to address are the following: 1. Greater flexibility in delivering routing services Using labels to identify particular traffic which are to receive special services, e.g. QoS. Using labels to provide forwarding along an explicit path different from the one constructed by destination-based forwarding. 2. Scalability of network layer routing Using labels as a means to aggregate forwarding information, while working in the presence of routing hierarchies. 3. Simplify integration of routers with cell switching based technologies a) making cell switches behave as peers to routers (thus reducing the number of routing peers that a router has to maintain), b) by making information about physical topology available to Network Layer routing procedures, and c) by employing common addressing, routing, and management procedures. 4. Simplify integration of routers with time-division, wavelength and spatial switching technologies a) making time-division, wavelength and spatial switching devices behave as peers to routers (thus reducing the number of routing peers that a router has to maintain), b) by making information about physical topology available to Network Layer routing procedures, and c) by employing common addressing, routing, and management procedures. High Level Requirements 1. The solution should be general with respect to data link technologies. Specific optimizations for particular media will be considered. 2. The solution must be compatible with existing internetwork technologies and routing protocols. 3. The solution should support a wide range of forwarding granularities associated with a given label, from a single application flow to a group of topologically related destinations. 4. The solution should support operations, administration, and maintenance facilities at least as extensive as those supported in IP networks. 5. The solution should provide stable routing. The protocols defined by MPLS must provide protocol mechanism(s) to either prevent the formation of loops and/or contain the amount of (networking) resources that could be consumed due to the presence of such loops. 6. The solution should be very scalable. Scalability issues will be considered and analyzed. Charter Statement: The working group is responsible for standardizing a base technology for using label switching in conjunction with network layer routing and for the implementation of that technology over various link level technologies, which may include Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,... This includes procedures and protocols for the distribution of labels between routers, encapsulations, multicast considerations, and the use of labels to support higher layer resource reservation and QoS mechanisms. The working group will extend the concept of label switching to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming fiber to outgoing fiber). Objectives: 1. Specify standard protocol(s) for maintenance and distribution of label binding information to support unicast destination-based routing. 2. Specify standard protocol(s) for maintenance and distribution of label binding information to support multicast routing. 3. Specify standard protocol(s) for maintenance and distribution of label binding information to support hierarchy of routing knowledge (e.g., complete segregation of intra and inter-domain routing). 4. Specify standard protocol(s) for maintenance and distribution of label binding information to support explicit paths in support of applications such as Traffic Engineering. 5. Specify standard protocols and procedures to support fast MPLS-based recovery. 6. Specify extensions to the protocols and procedures for signaling and recovery to support time-division, wavelength and spatial switching. 7. Specify standard procedures of carrying label information over various link level technologies. 8. Define the support of Differentiated and Integrated Services, including aggregated QoS, in an MPLS environment. 9. Specify standard protocols and procedures to support operations, administration, and maintenance facilities. 10. Specify a link management protocol for link provisioning and fault isolation, to facilitate LSP recovery. 11. Specify standard protocols and procedures to enable header compression across a single link as well as across an LSP. 12. Specify appropriate extensions to LDP and RSVP for authentication of LSP originators. 13. Define requirements and standard protocols and procedures for policy support in MPLS-based networks. This work will be complementary to, and will build upon, other policy-related work ongoing in the IETF. Coordination: The working group will coordinate its activities with other working groups as appropriate. For specific technologies, the WG will cooperate with the appropriate standards bodies such as OIF, ITU-T, ANSI, ODSI etc. Goals and Milestones: Mar 00 - Produce a document which defines support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks (Standards Track). Aug 00 - Produce a document which defines operation with "classic" RSVP (i.e. non-TE RSVP) for unicast destinations. (Standards Track). Aug 00 - Produce specifications for protocols and procedures that support fault recovery in an MPLS environment. Dec 00 - Produce specifications for a MPLS control plane for time-division, wavelength and spatial switching (Standards Track). Dec 00 - Produce specifications for a link management protocol for link provisioning and fault isolation (Standards Track). Dec 00 - Produce specifications for header compression over LSPs Dec 00 - Product specifications for header compression, including MPLS headers, over a link ------_=_NextPart_001_01BF993C.931292FE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable yet another revision of the charter

Hi folks,

Here is another revision of the charter, based upon = discussion at today's WG meeting.  I have added the following = objectives:

--
11. Specify standard protocols and procedures to = enable header compression
across a single link as well as across an = LSP.

12. Specify appropriate extensions to LDP and RSVP = for authentication
of LSP originators.

13. Define requirements and standard protocols and = procedures for policy
support in MPLS-based networks.  This work will = be complementary to, and
will build upon, other policy-related work ongoing = in the IETF.
--

We did not discuss milestones for the policy and = authentication work.  Your input on these would be = appreciated.

Regards,
- Chairs

---------------------------------------------------------------= --------
Multiprotocol Label Switching (mpls) Charter

Problem Statement:

Label switching in conjunction with network layer = routing has emerged
as an important new technology.  It is actively = being applied to
applications such as traffic engineering and virtual = private networks.
Among the problems this technology is expected to = address are the
following:

1.  Greater flexibility in delivering routing = services

Using labels to identify particular traffic which are = to receive
special services, e.g. QoS.

Using labels to provide forwarding along an explicit = path different
from the one constructed by destination-based = forwarding.

2.  Scalability of network layer routing

Using labels as a means to aggregate forwarding = information, while
working in the presence of routing = hierarchies.

3.  Simplify integration of routers with cell = switching based
technologies

a) making cell switches behave as peers to routers = (thus reducing
the number of routing peers that a  router has = to maintain),

b) by making information about physical topology = available to
Network Layer routing procedures, and

c) by employing common addressing, routing, and = management
procedures.

4.  Simplify integration of routers with = time-division, wavelength
and spatial switching technologies

a) making time-division, wavelength and spatial = switching devices
behave as peers to routers (thus reducing the number = of routing peers
that a router has to maintain),

b) by making information about physical topology = available to
Network Layer routing procedures, and

c) by employing common addressing, routing, and = management
procedures.

High Level Requirements

1.  The solution should be general with respect = to data link
technologies. Specific optimizations for particular = media will be
considered.

2.  The solution must be compatible with = existing internetwork
technologies and routing protocols.

3.  The solution should support a wide range of = forwarding
granularities associated with a given label, from a = single
application flow to a group of topologically related = destinations.

4.  The solution should support operations, = administration, and
maintenance facilities at least as extensive as = those supported in
IP networks.

5.  The solution should provide stable = routing.  The protocols defined
by MPLS must provide protocol mechanism(s) to either = prevent the
formation of loops and/or contain the amount of = (networking) resources
that could be consumed due to the presence of such = loops.

6.  The solution should be very scalable.  = Scalability issues will be
considered and analyzed.

Charter Statement:

The working group is responsible for standardizing a = base technology
for using label switching in conjunction with = network layer routing
and for the implementation of that technology over = various link level
technologies, which may include Packet-over-Sonet, = Frame Relay, ATM,
Ethernet (all forms, such as Gigabit Ethernet, = etc.), Token Ring,...

This includes procedures and protocols for the = distribution of labels
between routers, encapsulations, multicast = considerations, and the use
of labels to support higher layer resource = reservation and QoS
mechanisms.

The working group will extend the concept of label = switching to encompass
time-division (e.g. SONET ADMs), wavelength (optical = lambdas)
and spatial switching (e.g. incoming fiber to = outgoing fiber).

Objectives:

1.  Specify standard protocol(s) for maintenance = and distribution of
label binding information to support unicast = destination-based
routing.

2.  Specify standard protocol(s) for maintenance = and distribution of
label binding information to support multicast = routing.

3.  Specify standard protocol(s) for maintenance = and distribution of
label binding information to support hierarchy of = routing knowledge
(e.g., complete segregation of intra and = inter-domain routing).

4.  Specify standard protocol(s) for maintenance = and distribution of
label binding information to support explicit paths = in support of
applications such as Traffic Engineering.

5.  Specify standard protocols and procedures to = support fast
MPLS-based recovery.

6.  Specify extensions to the protocols and = procedures for
signaling and recovery to support time-division, = wavelength and
spatial switching.

7.  Specify standard procedures of carrying = label information over
various link level technologies.

8.  Define the support of Differentiated and = Integrated Services,
including aggregated QoS, in an MPLS = environment.

9.  Specify standard protocols and procedures to = support operations,
administration, and maintenance facilities.

10. Specify a link management protocol for link = provisioning and
fault isolation, to facilitate LSP recovery.

11. Specify standard protocols and procedures to = enable header compression
across a single link as well as across an = LSP.

12. Specify appropriate extensions to LDP and RSVP = for authentication
of LSP originators.

13. Define requirements and standard protocols and = procedures for policy
support in MPLS-based networks.  This work will = be complementary to, and
will build upon, other policy-related work ongoing = in the IETF.

Coordination:

The working group will coordinate its activities with = other working
groups as appropriate.  For specific = technologies, the WG will
cooperate with the appropriate standards bodies such = as OIF, ITU-T,
ANSI, ODSI etc.

Goals and Milestones:

Mar 00 - Produce a document which defines support of = Differentiated
         = Services (Diff-Serv) over Multi-Protocol Label Switching
         = (MPLS) networks (Standards Track).

Aug 00 - Produce a document which defines operation = with "classic" RSVP
         = (i.e. non-TE RSVP) for unicast destinations. (Standards Track).

Aug 00 - Produce specifications for protocols and = procedures that support
         = fault recovery in an MPLS environment.

Dec 00 - Produce specifications for a MPLS control = plane for time-division,
         = wavelength and spatial switching (Standards Track).

Dec 00 - Produce specifications for a link management = protocol for link
         = provisioning and fault isolation (Standards Track).

Dec 00 - Produce specifications for header = compression over LSPs

Dec 00 - Product specifications for header = compression, including MPLS
         = headers, over a link



------_=_NextPart_001_01BF993C.931292FE-- From owner-mpls@UU.NET Wed Mar 29 00:43:51 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05107 for ; Wed, 29 Mar 2000 00:43:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiok12035; Wed, 29 Mar 2000 05:43:36 GMT Received: by mail-control.mail.uu.net id QQiiok22966 for mpls-outgoing; Wed, 29 Mar 2000 05:43:06 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiiok22959 for ; Wed, 29 Mar 2000 05:43:02 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiok13687 for ; Wed, 29 Mar 2000 00:42:49 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQiiok11097 for ; Wed, 29 Mar 2000 05:42:16 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id LAA14671; Wed, 29 Mar 2000 11:06:02 -0600 (GMT) Message-ID: <003701bf9941$d53afcc0$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: , "Yoshihiro Ohba" Cc: , , References: <200003281352.WAA17076@toshiba.co.jp> Subject: Re: CR-LDP Date: Wed, 29 Mar 2000 11:14:19 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Yoshihiro Please see the embedded comments. > Ajithn, > > > LSP-IDs become part of the "traffic engineering state" of the network. So > > it is legitimate to define a CR-LSP, whose ingress is LER2, stacking or > > splicing with an existing CR-LSP whose ingress is LER1, the latter being > > specified by its LSP-ID. The entity which does traffic engineering can be > > thought of as "higher" than the LSR, and it knows these LSP-IDs. At that > > level, there is global (or, supra-local) knowledge. > > > However, from the point of view of LSRs, local knowledge is sufficient. > > LSRs need to know only the LSP-IDs they participate in. > > > In your example, LER2 and LSR5 do not need to know the spliced/stacked > > CR-LSP's LSP-ID because all they do with it is, just pass it downward. > > That remains true as we go down the request path till we hit LSR3, for > > which it is intended. So there is no need for non-participating LSRs to > > be aware of the LSP-ID. > > There is an issue here on how an LSR that is not aware of the LSP-ID > can determine who is the "downward" LSR for the LSP-ID. > > I think it depends on the FEC type used for the CR-LSP, that is, > an opaque FEC should not be used in this case. If we use a prefix FEC or > host address FEC, the "downward" LSR can be determined based > on the FEC information. Who is supposed to be the "Downstream" peer is decided by the global (or, supra-local) entity which has the knowledge of all the LSPs and the topology of the network. An Opaque FEC has to be used for CR-LSP(sec 4.10 in draft-ietf-mpls-cr-ldp-03) since this feature is there only in CR-LDP and to setup a CR-LSP it is compulsory. One more issue that crops up at this point is that how is this type of LSP to be setup. The initial scenario that we discussed was LER1 ------> LSR2-------->LSR3------>LSR4 LER2-------->LSR5 Now suppose the scenario were like LER1 ------> LSR2-------->LSR3------>LSR4------>LSR6 LER2-------->LSR5------->LSR7 and LSR7 was supposed to connect to LSR4. How is the new LSP to be setup? The global (or, supra-local) entity will inform only LER2 which will be sending message to LSR5 which would in turn send the request to LSR7. Is there any standard draft on how this is to be handled? Santosh Gupta > > Yoshihiro Ohba > > > > -- Ajith > > From owner-mpls@UU.NET Wed Mar 29 01:08:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05753 for ; Wed, 29 Mar 2000 01:08:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiom29636; Wed, 29 Mar 2000 06:08:27 GMT Received: by mail-control.mail.uu.net id QQiiom02120 for mpls-outgoing; Wed, 29 Mar 2000 06:08:05 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiom02115 for ; Wed, 29 Mar 2000 06:08:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiom00739 for ; Wed, 29 Mar 2000 01:07:58 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiiom23302 for ; Wed, 29 Mar 2000 06:07:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA13063 for mpls@uu.net; Wed, 29 Mar 2000 01:07:56 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiom02102 for ; Wed, 29 Mar 2000 06:07:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiom00712 for ; Wed, 29 Mar 2000 01:07:27 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQiiom28829 for ; Wed, 29 Mar 2000 06:07:26 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id JAA24635; Wed, 29 Mar 2000 09:07:22 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14561.40346.557571.661905@lohi.eng.telia.fi> Date: Wed, 29 Mar 2000 09:07:22 +0300 (EEST) To: Vijay Srinivasan Cc: "'mpls@uu.net'" Subject: yet another revision of the charter In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijay Srinivasan writes: > 1. Specify standard protocol(s) for maintenance and distribution of > label binding information to support unicast destination-based > routing. i guess the soft permanent lsps fit into this category? -- juha From owner-mpls@UU.NET Wed Mar 29 01:11:47 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06146 for ; Wed, 29 Mar 2000 01:11:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiom02209; Wed, 29 Mar 2000 06:11:32 GMT Received: by mail-control.mail.uu.net id QQiiom02300 for mpls-outgoing; Wed, 29 Mar 2000 06:11:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiom02286 for ; Wed, 29 Mar 2000 06:11:03 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiom01025 for ; Wed, 29 Mar 2000 01:10:55 -0500 (EST) Received: from bgslc02.TBG.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [199.104.68.2]) id QQiiom01630 for ; Wed, 29 Mar 2000 06:10:54 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2448.0) id ; Tue, 28 Mar 2000 23:09:31 -0700 Message-ID: <0C875DC28791D21192CD00104B95BFE76D06EB@BGSLC02> From: Irwin Lazar To: mpls@UU.NET Cc: mpls-ops@mplsrc.com Subject: The MPLS FAQ Date: Tue, 28 Mar 2000 23:09:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9945.583D6538" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9945.583D6538 Content-Type: text/plain; charset="iso-8859-1" We've completed the initial outline of our MPLS FAQ. It is now available at http://www.mplsrc.com/mplsfaq.shtml for browsing. If anyone is interested in providing answers for any of the unanswered questions, please contact us at faq@mplsrc.com . We're also looking for suggestions on questions to add, and perhaps, questions to delete. Thanks in advance, Irwin ------_=_NextPart_001_01BF9945.583D6538 Content-Type: text/html; charset="iso-8859-1"
We've completed the initial outline of our MPLS FAQ.  It is now available at http://www.mplsrc.com/mplsfaq.shtml for browsing.  If anyone is interested in providing answers for any of the unanswered questions, please contact us at faq@mplsrc.com.
 
We're also looking for suggestions on questions to add, and perhaps, questions to delete.
 
Thanks in advance,
 
Irwin 
------_=_NextPart_001_01BF9945.583D6538-- From owner-mpls@UU.NET Wed Mar 29 02:27:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16984 for ; Wed, 29 Mar 2000 02:27:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiior11765; Wed, 29 Mar 2000 07:27:12 GMT Received: by mail-control.mail.uu.net id QQiior13993 for mpls-outgoing; Wed, 29 Mar 2000 07:26:43 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiior13988 for ; Wed, 29 Mar 2000 07:26:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiior07583 for ; Wed, 29 Mar 2000 02:26:25 -0500 (EST) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiior17099 for ; Wed, 29 Mar 2000 07:26:25 GMT Received: from kbalalap by alpha.tellium.com (SMI-8.6/SMI-SVR4) id CAA07250; Wed, 29 Mar 2000 02:21:08 -0500 From: "Krishna Bala" To: "James V. Luciani" , "Jagan Shantigram" , "Jonathan Lang" , Cc: "Khaled Elsayed" , , Subject: RE: Comments on draft-ip-optical-framework-00.txt Date: Wed, 29 Mar 2000 02:26:33 -0500 Message-ID: <000001bf9950$1bcd5c60$425cc697@tempest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <009e01bf9846$0cc47ec0$a4d0fea9@jluciani> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jim, Hmm! The OIF is using the terms 1) Peer 2) Open So, if possible ... so as to avoid creating yet another term for the same thing (X in this case) I suggest we call it "open". Krishna > -----Original Message----- > From: James V. Luciani [mailto:jluciani@tollbridgetech.com] > Sent: Monday, March 27, 2000 6:42 PM > To: Krishna Bala; Jagan Shantigram; Jonathan Lang; curtis@avici.com > Cc: Khaled Elsayed; mpls@UU.NET; ip-optical@lists.research.bell-labs.com > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > > Just to beat a dead horse .. the difference between the open model > > and the overlay is just that the overlay model typically suggests that > > That depends... see below. > > > there would be N^2 connectivity (i.e., every router, for instance, is > > statically connected to every other). In any case, the open model allows > > While there may indeed be some misunderstanding as to the meaning of the > "overlay model" (not to mention the meaning of the other models :-)), the > traditional definition of overlay is not one of static operation. > NHRP and > MPOA, for example, are overlay in my book (and most folks that I know). > They most certainly imply non-static connections by defintion > (i.e., use of > SVCs). This having been said, I believe that we can do one of two things > here. One, keep the current terms and potentially risk an ad nauseum > inspection of the meaning of these terms; or two, come up with a > term which > is satisfactory to all. In the second case we would have models: > 1) X > 2) Peer > where X is the PC term for what we want to get at. So my opine is that > X="augmented routing model"/ARM model. > > Do I hear a hmmmm??? > --Jim > > > for fully dynamic operation. The overlay model suggests static operation > of > > the optical layer. > > > > As I see it there are only two architectures that are worth considering: > > 1. Peer > > 2. Open > > > > I agree with you that there is no need to add the "overlay" model to > > this list. The open model covers the static and the dynamic cases. > > > > Krishna > > > > > -----Original Message----- > > > From: Jagan Shantigram [mailto:jagan@photonex.com] > > > Sent: Monday, March 27, 2000 10:14 AM > > > To: Krishna Bala; Jonathan Lang; curtis@avici.com > > > Cc: Khaled Elsayed; mpls@UU.NET; > ip-optical@lists.research.bell-labs.com > > > Subject: RE: Comments on draft-ip-optical-framework-00.txt > > > > > > > > > At 05:04 PM 3/24/00 -0500, Krishna Bala wrote: > > > >Jonathan, > > > >Point 1: Let me clarify the "open model". > > > > > > > >Open refers to the fact that this model supports the > interconnection of > > > >several types of clients to an optical network (server layer). > > > >Examples of Clients: > > > >IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services" > > > > > > > >The open model also allows the interconnection of other > Optical Network > > > >Elements to > > > >each other. > > > >Examples of other Network Elements: > > > >Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC, > Wavelength > > > >Interchanging XC > > > > > > > >In general, since it offers the capability to support ALL > > > services (not just > > > >IP) > > > >it is an Open Model. > > > > > > Krishna, > > > > > > It seems like the above just described what people understand > > > by the overlay model. In this model the optical layer presents > > > itself as a layer that can provide a bunch of services to the > > > upper data/IP layer. These services could include point > > > to point clear channel, 1+1 protection, negotiable bandwidth > > > etc.. (just to give examples). How the optical layer > > > achieves these services is yet to be determined - which as you > > > mention will require standardized interfaces between the various > > > optical components and as well as a standardized API for these > > > services to be requested. > > > > > > My question is what are these services that would be useful > > > for the optical layer to provide and what are the tasks that > > > have to be taken up to enable it? > > > > > > In any case it seems risky to take up a model that requires > > > too much cooperation between the various layers - since that > > > will mean that there will be inter-dependence in the development > > > of that technology. Ofcourse there are others who have more > > > experience on questions like this. > > > > > > > > > > > > > >Point 2: Overlay Model vs. Open > > > > > > > >The connotation that goes typically with the Overlay model > is that the > > > >optical > > > >layer is quasi static and might require N^2 connectivity at the > IP/client > > > >layer. > > > > > > Am afraid I missed the point here. > > > > > > thanks, > > > -jagan. > > > > > > > > > >Hence, I prefer to distinguish the open model from overlay. > > > >Krishna Bala > > > > > > > >> -----Original Message----- > > > >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Jonathan > > > >> Lang > > > >> Sent: Thursday, March 23, 2000 4:55 PM > > > >> To: 'Krishna Bala'; curtis@avici.com; Jagan Shantigram > > > >> Cc: Khaled Elsayed; mpls@UU.NET; > > > ip-optical@lists.research.bell-labs.com > > > >> Subject: RE: Comments on draft-ip-optical-framework-00.txt > > > >> > > > >> > > > >> Krishna, > > > >> The Open model seems quite "Closed" to me - the very nature of > clouds > > > >> implies information hiding in my mind. What is exactly meant by > open? > > > >> Also, I'm not sure I agree with your definition of overlay, as > > > many people > > > >> allow the overlay model to encompass both your (2) and (3). > > > >> Furthermore, I > > > >> don't think the Peer Model implies OXCs are "agile but fat & > > > >> dumb" since as > > > >> they are "peers", this would also imply routers are "agile but > > > fat & dumb" > > > >> as well - and at some point, someone needs to have > > > intelligence. I would > > > >> suggest that the Peer model allows both routers and OXCs to > > > interoperate > > > >> intelligently. > > > >> > > > >> Regards, > > > >> Jonathan > > > >> > > > >> -----Original Message----- > > > >> From: Krishna Bala [mailto:kbala@tellium.com] > > > >> Sent: Thursday, March 23, 2000 11:59 AM > > > >> To: curtis@avici.com; Jagan Shantigram > > > >> Cc: Khaled Elsayed; mpls@UU.NET; > > > ip-optical@lists.research.bell-labs.com > > > >> Subject: RE: Comments on draft-ip-optical-framework-00.txt > > > >> > > > >> > > > >> Jagan, > > > >> There are several architectural models for IP over Optical > > > Networks that > > > >> are emerging: > > > >> > > > >> 1. Peer Model > > > >> In this model the IP router is entirely aware of the details on the > > > >> underlying > > > >> optical network (topology information, wavelength and port > > > usage and lamda > > > >> assignment). > > > >> It is able to control and manage entire end to end paths. In this > > > >> model the > > > >> OXC is "agile but fat & dumb". > > > >> 2. Overlay Model > > > >> The optical layer is "fat & dumb". The lamda connections > between the > IP > > > >> routers behave as if they were dedicated fibers between them. The > > > >> IP routes > > > >> provision logical optical circuits over a fixed or at best a > > > quasi-fixed > > > >> optical > > > >> layer. > > > >> 3. Open Model > > > >> In this scenario the optical layer comprises of several > "vendor/network > > > >> operator clouds" > > > >> that have well defined interfaces. For example, an Optical UNI > > > can be used > > > >> to > > > >> interconnect the IP router to the OXC and the Optical NNI can > > > be used to > > > >> connect > > > >> two optical network domains together. Here the optical layer is > > > >> "fat, smart > > > >> and agile". > > > >> > > > >> It is unclear at this time which of these models will prevail. > > > >> > > > >> Krishna Bala > > > >> Tellium > > > >> > > > >> > > > >> > > > >> > -----Original Message----- > > > >> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Curtis > > > >> > Villamizar > > > >> > Sent: Thursday, March 23, 2000 1:55 PM > > > >> > To: Jagan Shantigram > > > >> > Cc: curtis@avici.com; Khaled Elsayed; mpls@UU.NET; > > > >> > ip-optical@lists.research.bell-labs.com > > > >> > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > >> > > > > >> > > > > >> > > > > >> > In message <3.0.6.32.20000323114004.00b74c60@photonex.com>, Jagan > > > >> > Shantigram wr > > > >> > ites: > > > >> > > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote: > > > >> > > > > > > >> > > >In message <38D76337.478CA5FC@ieee.org>, Khaled > Elsayed writes: > > > >> > > >> > > > >> > > >> > > > >> > > >> Hello Jagan, > > > >> > > >> > > > >> > > >> > When we do not have lambda conversion however, this > > > >> problem cannot > > > >> > > >> > be solved optimally.. it is akin to the graph coloring > > > >> > > >> > problem - which ofcourse has heuristics that can get us to > > > >> > > >> > a factor (?) of the optimal solution. So, connections may > > > >> > > >> > be blocked even though there is capacity on the fiber to > > > >> > > >> > support it, just because the wavelength is > already used up. > > > >> > > >> > > > > >> > > >> > > > >> > > >> Connections can be blocked when?? At service > > > provisioning time or > > > >> > > >> at the time the connection is requested?? My point is a > > > >> > > >> connection of 2.48 Gbps is not likely to be a > random event or > an > > > >> > > >> ATM-like SVC. If a customer would require such huge > > > bandwidth, it > > > >> > > >> would need that BW to go through or it would better look for > > > >> > > >> another carrier that will provide a TDM/leased line?? Of > course > > > >> > > >> wavelength conversion can help build a better-utilized > network, > > > >> > > >> no question about that. > > > >> > > >> > > > >> > > >> Khaled > > > >> > > > > > > >> > > > > > > >> > > >The exception to the rule that "a connection of 2.48 > Gbps is not > > > >> > > >likely to be a random event" is where a very major event, > > > possilble > > > >> > > >external to one's own network results in a shift in > > > traffic patterns > > > >> > > >that is significant enough to require that additional > > > >> lambdas be added > > > >> > > >to existing paths. > > > >> > > > > > > >> > > >The real world example in the ISP world is a failure of a > peering > > > >> > > >point of some sort, a provider interconnect, a NAP or NAP > > > >> connectivity > > > >> > > >of some party. Since all major ISPs are connected to > > > each other at > > > >> > > >more than one geographically diverse peering point, the > > > traffic will > > > >> > > >still flow, but the path will have changed. > > > >> > > > > > > >> > > >This may mean that a path that previously required 3 lambdas > (for > > > >> > > >example), now requires 4 lambdas. There are at least > 3 ways to > > > >> > > >accommodate this requirement: > > > >> > > > > > > >> > > > 1. An external management system adds a lambda to both > > > the routers > > > >> > > > at either end and the optical switches > > > (demonstrated at OFC). > > > >> > > > > > > >> > > > 2. The router signals the requirement/desire for an > additional > > > >> > > > lambda to the adjacent optical switch which sets up a > path. > > > >> > > > This is the overlay model. It can be trivially > > > >> implemented with > > > >> > > > MPLS by having the router send a loose source hop in the > ERO > > > >> > > > allowing the switch to create the path or reject > > > the request. > > > >> > > > > > >> > > Curtis, > > > >> > > > > > >> > > Am trying to understand the model here. Does the overlay model > > > >> > > as you put above imply that the optical devices need to be > > > >> mini-routers > > > >> > > in their own right? They have to be able to set up > > > end-to-end optical > > > >> > > paths.. perhaps some kind of binding between the end-host > > > IP address > > > >> > > and an addressing scheme for Optical devices.. ala ATM? > > > >> > > What does the overlay model entail? > > > >> > > > > >> > The optical devices run the same IGP (ISIS or OSPF) and use RSVP > (or > > > >> > CRLDP) in a manner similar to the ATM UNI setting up an SVC. > > > >> > > > > >> > Alternately, the lambdas can be set statically and the > edge router > > > >> > simple advertises a Lambda-Switch Capable link ala > > > >> > draft-kompella-mpls-optical-00.txt (if I understand their intent > wrt > > > >> > accommodating the overlay model). > > > >> > > > > >> > I don't think draft-kompella-mpls-optical-00.txt has all the > details > > > >> > sufficiently ironed out for the case where the optical switch > > > >> > advertises the availability of an optical link. If it does, then > the > > > >> > details ar just not clear to me. (Could be my careless reading). > > > >> > > > > >> > > > 3. The router has enough information about the > > > characteristics of > > > >> > > > the optical devices to compute the path and so it does > > > >> so. This > > > >> > > > is the peer model. > > > >> > > > > > > >> > > > > > >> > > What does this model need.. a protocol for exchanging > information > > > >> > > between the router and the optical device? > > > >> > > > > >> > It needs a means to communicate OOB wrt the primary lightpath. > That > > > >> > means would again be running the IGP and RSVP. Based on reading > the > > > >> > draft-kompella-mpls-optical-00.txt draft, I'm not clear > on how the > > > >> > optical switch exchanges this information OOB although I > > > would imagine > > > >> > that it would be quite easy to maintian another > interface (perhaps > > > >> > even an electrical, though gig-E would do fine) between the > > > router and > > > >> > optical device in which the optical device advertises the optical > > > >> > links. The router on either end of an optical link, seeing or > having > > > >> > set up a Packet-Switch Capable link would then have to > bring up an > > > >> > RSVP adjacency over it, though I think it would not need an IGP > > > >> > adjacency. (I'm not clear on this last point.) > > > >> > > > > >> > The availability of certain types of links > (Packet-Switch Capable, > > > >> > Lambda-Switch Capable, Fiber-Switch Capable) as defined in > > > >> > draft-kompella-mpls-optical-00.txt would be advertised via RSVP. > I'm > > > >> > not clear on whether the adjacent LSR should advertise a > Forwarding > > > >> > Adjacency PSC after RSVP comes up over a set of optical links (it > > > >> > seems to be the intent) but maybe the authors can clarify the > usage. > > > >> > > > > >> > The ongoing discussion and the topic of the (way too numerous) > > > >> > framework documents floating around has been what additional > > > >> > information would be needed in order to provide adequate > constraints > > > >> > to set up optical paths, a particularly difficult problem for > > > >> > transparent paths. > > > >> > > > > >> > > -jagan. > > > >> > > > > > >> > > >The way this might manifest itself is LSPs that might > > > take an optical > > > >> > > >path from A to C are going from A to B to C because A to C > > > >> lambdas are > > > >> > > >too full. If so, then A could in principle request an > additional > > > >> > > >lambda, but in practice the means to signal this has not > > > >> been defined. > > > >> > > > > > > >> > > >Curtis > > > >> > > > > > >> > > Jagannath Shantigram > > > >> > > Photonex Corporation > > > >> > > > > >> > btw- I exchanged some private email with one of the authors of > > > >> > draft-kompella-mpls-optical.txt and owe them some > detailed comments > > > >> > (appologies to them for the delay, busy). After some brief > > > discussion > > > >> > and after a second reading, the intent seems a lot more > clear. The > > > >> > usage material is at the end so when reading the document from > front > > > >> > to back the intent is not clear until the end and then a second > > > >> > reading is required. > > > >> > > > > >> > Curtis > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > Jagannath Shantigram > > > Photonex Corporation > > > > From owner-mpls@UU.NET Wed Mar 29 02:49:51 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17206 for ; Wed, 29 Mar 2000 02:49:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiot27049; Wed, 29 Mar 2000 07:49:38 GMT Received: by mail-control.mail.uu.net id QQiiot15211 for mpls-outgoing; Wed, 29 Mar 2000 07:49:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiot15204 for ; Wed, 29 Mar 2000 07:48:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiot09665 for ; Wed, 29 Mar 2000 02:48:50 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiiot29019 for ; Wed, 29 Mar 2000 07:48:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA18942 for mpls@uu.net; Wed, 29 Mar 2000 02:48:49 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiot15184 for ; Wed, 29 Mar 2000 07:48:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiot09633 for ; Wed, 29 Mar 2000 02:48:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQiiot26199 for ; Wed, 29 Mar 2000 07:48:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Mar 29 02:47:22 EST 2000 Received: from lucent.com (ex-vpn65.pa.bell-labs.com [135.250.1.65]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id CAA11176; Wed, 29 Mar 2000 02:47:12 -0500 (EST) Message-ID: <38E1B5AD.1AAD0876@lucent.com> Date: Tue, 28 Mar 2000 23:50:05 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Krishna Bala CC: mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt References: <000001bf9950$1bcd5c60$425cc697@tempest> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The OIF's use is hardly compelling. Curtis makes a good observation that the word "open" isn't particularly descriptive in this context. Are you *sure* you aren't really talking about a form of overlay model (as clarified)? The word "overlay" (with or without "signaled" as Curtis suggested) seems to be more descriptive (naturally, IMHO). cheers, gja Krishna Bala wrote: > > Jim, > Hmm! > > The OIF is using the terms > 1) Peer > 2) Open > > So, if possible ... so as to avoid creating yet another term for > the same thing (X in this case) I suggest we call it "open". > > Krishna [..] ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Wed Mar 29 07:07:14 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19814 for ; Wed, 29 Mar 2000 07:07:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiipk29227; Wed, 29 Mar 2000 12:07:00 GMT Received: by mail-control.mail.uu.net id QQiipk04649 for mpls-outgoing; Wed, 29 Mar 2000 12:06:28 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiipk04527 for ; Wed, 29 Mar 2000 12:06:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiipk16416 for ; Wed, 29 Mar 2000 07:06:11 -0500 (EST) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQiipk08051 for ; Wed, 29 Mar 2000 12:06:11 GMT Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id EAA06862; Wed, 29 Mar 2000 04:06:11 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id EAA10790; Wed, 29 Mar 2000 04:06:10 -0800 (PST) Date: Wed, 29 Mar 2000 04:06:10 -0800 (PST) From: Kireeti Kompella Message-Id: <200003291206.EAA10790@kummer.juniper.net> To: gja@lucent.com, kbala@tellium.com Subject: Re: Comments on draft-ip-optical-framework-00.txt Cc: ip-optical@lists.research.bell-labs.com, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk > The OIF's use is hardly compelling. Curtis makes a good > observation that the word "open" isn't particularly descriptive > in this context. I would go further: "open" is a misnomer. As Jonathan pointed out, the "open" model looks closed from another point of view. Note that the terms "peer", "overlay" and "integrated" all describe topological relationships between network elements, but "open" instead describes services offered. Non sequitur. > Are you *sure* you aren't really talking about > a form of overlay model (as clarified)? The word "overlay" (with > or without "signaled" as Curtis suggested) seems to be more > descriptive (naturally, IMHO). IMHO, here's what is going on: the term "overlay" may appear to some to have bad connotations; the term "open" has good connotations. So, while it is nice to have descriptive names, let's call this model X (and, if desired, call the peer model Y) to lose the connotational baggage, and get on with the real task of defining the models by property and context of usefulness. Krishna, you make the comment: > It is unclear at this time which of these models will prevail. I don't know that any one model will "prevail". Furthermore, by designing a routing and signaling architecture that encompasses all models, it won't matter which prevails, and will also allow for a smoother transition from one to another. I would say our real mission here is to arrive at such an architecture .... Kireeti. From owner-mpls@UU.NET Wed Mar 29 08:39:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20787 for ; Wed, 29 Mar 2000 08:39:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiipq03430; Wed, 29 Mar 2000 13:39:24 GMT Received: by mail-control.mail.uu.net id QQiipq22686 for mpls-outgoing; Wed, 29 Mar 2000 13:38:52 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiipq22681 for ; Wed, 29 Mar 2000 13:38:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiipq25901 for ; Wed, 29 Mar 2000 08:37:08 -0500 (EST) Received: from smtprtp.ntcom.nortel.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp.ntcom.nortel.net [137.118.22.15]) id QQiipq00904 for ; Wed, 29 Mar 2000 13:37:08 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Wed, 29 Mar 2000 08:36:33 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 08:36:31 -0500 Message-ID: <03E3E0690542D211A1490000F80836F4029F977D@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'Andrzej Czerczak'" , mpls@UU.NET Subject: RE: MPLS routing accross AS boundaries Date: Wed, 29 Mar 2000 08:36:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9983.CA7D8072" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9983.CA7D8072 Content-Type: text/plain; charset="iso-8859-1" Currently the MPLS working group has not addressed this subject in any depth although there was a draft presented in the routing area group today in Adelaide that started to talk about solutions. As far as I know there are basically two ways to attack this problem, or at least two general flavors. piecewise source routing. In this approach you compute a gateway based on the destination address and then do normal flat source routing to that gateway. Go through the gateway and repeat. In other words you are doing piecewise traffic engineering but letting the exterior gateway protocols figure out which gateway you should be going to next. Obviously there are problems with this approach since it puts everything though the same gateway. I actually helped built a piecewise solution like this a while ago. It has some good advantages in that local (at least local to an AS) repair is natural to do as are local modification etc. hierarchical source routing. This is what ATM does, you compute a hop list hierarchically against a hierarchical topology database etc. etc. I'm not sure this approach is appropriate for the Internet due to the massive size of the problem but I'm really not an ATM hierarchical routing guy. I would hope that the MPLS working group or the Traffic Engineering working group can start looking at these issues, possibly with some simulations of the different approaches against a set of real AS topologies. Some of the PNNI architects and BGP architects are active members of the MPLS working group so you can be sure that it will cause some heated debate ... should be extremely interesting and challenging. Cheers, Peter -----Original Message----- From: Andrzej Czerczak [SMTP:Andrzej_Czerczak/HeadQ@netia.pl] Sent: Tuesday, March 28, 2000 6:04 AM To: mpls@UU.NET Subject: MPLS routing accross AS boundaries Hi, Where can I get information on the subject of MPLS QoS routing accross Autonomous System boundaries? Thanks Andrzej ------_=_NextPart_001_01BF9983.CA7D8072 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS routing accross AS boundaries

Currently the MPLS working group has = not addressed this subject in any depth although there was a draft = presented in the routing area group today in Adelaide that started to = talk about solutions.

As far as I know there are basically = two ways to attack this problem, or at least two general flavors. =

piecewise source routing. In this = approach you compute a gateway based on the destination address and = then do normal flat source routing to that gateway. Go through the = gateway and repeat. In other words you are doing piecewise traffic = engineering but letting the exterior gateway protocols figure out which = gateway you should be going to next. Obviously there are problems with = this approach since it puts everything though the same gateway. I = actually helped built a piecewise solution like this a while ago. It = has some good advantages in that local (at least local to an AS) repair = is natural to do as are local modification etc.

hierarchical source routing. This is = what ATM does, you compute a hop list hierarchically against a = hierarchical topology database etc. etc. I'm not sure this approach is = appropriate for the Internet due to the massive size of the problem but = I'm really not an ATM hierarchical routing guy.

I would hope that the MPLS working = group or the Traffic Engineering working group can start looking at = these issues, possibly with some simulations of the different = approaches against a set of real AS topologies. Some of the PNNI = architects and BGP architects are active members  of the MPLS = working group so you can be sure that it will cause some heated debate = ... should be extremely interesting and challenging.

Cheers,

Peter



    -----Original = Message-----
    From:   Andrzej Czerczak = [SMTP:Andrzej_Czerczak/HeadQ@netia.pl]
    Sent:   Tuesday, March 28, 2000 6:04 AM
    To:     mpls@UU.NET
    Subject:       = MPLS routing accross AS = boundaries

    Hi,
     Where can I get information on = the subject of MPLS QoS routing accross
    Autonomous System boundaries?

    Thanks
    Andrzej

------_=_NextPart_001_01BF9983.CA7D8072-- From owner-mpls@UU.NET Wed Mar 29 09:05:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21142 for ; Wed, 29 Mar 2000 09:05:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiips22983; Wed, 29 Mar 2000 14:05:08 GMT Received: by mail-control.mail.uu.net id QQiips28369 for mpls-outgoing; Wed, 29 Mar 2000 14:04:35 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiips28342 for ; Wed, 29 Mar 2000 14:04:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiips16004 for ; Wed, 29 Mar 2000 09:04:14 -0500 (EST) Received: from momotaro.labs.nec.co.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: momotaro.labs.nec.co.jp [202.247.6.209]) id QQiips21745 for ; Wed, 29 Mar 2000 14:03:47 GMT Received: from iwata-pc2 by momotaro.labs.nec.co.jp (8.9.0/MOMO-990105) with ESMTP id XAA07964; Wed, 29 Mar 2000 23:02:52 +0900 (JST) Message-Id: <4.2.0.58.J.20000329230505.00a41be0@momotaro.labs.nec.co.jp> X-Sender: iwata@momotaro.labs.nec.co.jp Reply-To: iwata@ccm.CL.nec.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 29 Mar 2000 23:09:42 +0900 To: "Peter Ashwood-Smith" From: Atsushi Iwata Subject: RE: MPLS routing accross AS boundaries Cc: mpls@UU.NET, "'Andrzej Czerczak'" , Norihito Fujita In-Reply-To: <03E3E0690542D211A1490000F80836F4029F977D@zcard00f.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, all The draft that peter mentioned is our following draft. draft-fujita-ospf-te-summary-00.txt This approach assumes a hierarchical QoS path computation that PNNI routing protocol does in the ATM world. I would like to get any opinion or any suggestions (Pros and Cons) on this approach. Regards, At 08:36 00/03/29 -0500, Peter Ashwood-Smith wrote: >Currently the MPLS working group has not addressed this subject in any >depth although there was a draft presented in the routing area group today >in Adelaide that started to talk about solutions. > >As far as I know there are basically two ways to attack this problem, or >at least two general flavors. > >piecewise source routing. In this approach you compute a gateway based on >the destination address and then do normal flat source routing to that >gateway. Go through the gateway and repeat. In other words you are doing >piecewise traffic engineering but letting the exterior gateway protocols >figure out which gateway you should be going to next. Obviously there are >problems with this approach since it puts everything though the same >gateway. I actually helped built a piecewise solution like this a while >ago. It has some good advantages in that local (at least local to an AS) >repair is natural to do as are local modification etc. > >hierarchical source routing. This is what ATM does, you compute a hop list >hierarchically against a hierarchical topology database etc. etc. I'm not >sure this approach is appropriate for the Internet due to the massive size >of the problem but I'm really not an ATM hierarchical routing guy. > >I would hope that the MPLS working group or the Traffic Engineering >working group can start looking at these issues, possibly with some >simulations of the different approaches against a set of real AS >topologies. Some of the PNNI architects and BGP architects are active >members of the MPLS working group so you can be sure that it will cause >some heated debate ... should be extremely interesting and challenging. > >Cheers, > >Peter > >-----Original Message----- From: Andrzej Czerczak >[SMTP:Andrzej_Czerczak/HeadQ@netia.pl] Sent: Tuesday, March 28, 2000 >6:04 AM To: mpls@UU.NET Subject: MPLS routing accross AS >boundaries > >Hi, Where can I get information on the subject of MPLS QoS routing >accross Autonomous System boundaries? > >Thanks Andrzej ---------------------------------------------------------------- Atsushi Iwata Assistant Manager Network System TG, C&C Media Research Labs, NEC Corporation 4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555 TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 E-mail: iwata@ccm.CL.nec.co.jp From owner-mpls@UU.NET Wed Mar 29 09:25:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21245 for ; Wed, 29 Mar 2000 09:25:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiipt03596; Wed, 29 Mar 2000 14:24:49 GMT Received: by mail-control.mail.uu.net id QQiipt04742 for mpls-outgoing; Wed, 29 Mar 2000 14:24:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiipt04733 for ; Wed, 29 Mar 2000 14:23:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiipt03045 for ; Wed, 29 Mar 2000 09:22:36 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiipt01778 for ; Wed, 29 Mar 2000 14:22:36 GMT Received: from mjork-pc (mjork-pc.avici.com [10.1.2.168]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id JAA04378 for ; Wed, 29 Mar 2000 09:22:35 -0500 (EST) Received: by localhost with Microsoft MAPI; Wed, 29 Mar 2000 09:22:35 -0500 Message-ID: <01BF9960.517BC800.mjork@avici.com> From: Markus Jork To: "'mpls@uu.net'" Subject: RE: yet another revision of the charter Date: Wed, 29 Mar 2000 09:22:34 -0500 Organization: Avici X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, March 29, 2000 12:07 AM, Vijay Srinivasan wrote: > > Hi folks, > > Here is another revision of the charter, based upon discussion at today's WG > meeting. I have added the following objectives: > -- > 11. Specify standard protocols and procedures to enable header compression > across a single link as well as across an LSP. > > 12. Specify appropriate extensions to LDP and RSVP for authentication > of LSP originators. What is the rationale for this work item? There is already hop-by-hop authentication that can give you a chain of trust from LSP ingress to egress. This seems good enough for the intra-domain case. Why the extra end-to-end authentication? Is this for some inter-domain scenario? Markus From owner-mpls@UU.NET Wed Mar 29 10:23:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21841 for ; Wed, 29 Mar 2000 10:23:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiipx15567; Wed, 29 Mar 2000 15:22:38 GMT Received: by mail-control.mail.uu.net id QQiipx17171 for mpls-outgoing; Wed, 29 Mar 2000 15:21:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiipx17162 for ; Wed, 29 Mar 2000 15:21:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiipx16595 for ; Wed, 29 Mar 2000 10:21:26 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiipx04380 for ; Wed, 29 Mar 2000 15:21:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA20408 for mpls@uu.net; Wed, 29 Mar 2000 10:21:24 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiipx16984 for ; Wed, 29 Mar 2000 15:20:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiipx01635 for ; Wed, 29 Mar 2000 10:20:29 -0500 (EST) Received: from inet-tsb.toshiba.co.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: inet-tsb.toshiba.co.jp [202.33.96.40]) id QQiipx03450 for ; Wed, 29 Mar 2000 15:20:28 GMT Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id AAA29143; Thu, 30 Mar 2000 00:19:50 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id AAA05430; Thu, 30 Mar 2000 00:19:49 +0900 (JST) Received: by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id AAA26837; Thu, 30 Mar 2000 00:19:49 +0900 (JST) To: santoshg@daewoo.dti.daewoo.co.kr Cc: ajithn@sg.ibm.com, yoshihiro.ohba@toshiba.co.jp, sumitg@rocketmail.com, ashish@daewoo.dti.daewoo.co.kr, mpls@UU.NET Subject: Re: CR-LDP In-Reply-To: Your message of "Wed, 29 Mar 2000 11:14:19 +0530" <003701bf9941$d53afcc0$100d85a5@dti.daewoo.co.kr> References: <003701bf9941$d53afcc0$100d85a5@dti.daewoo.co.kr> X-Mailer: Mew version 1.92 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003291519.AAA26837@toshiba.co.jp> Date: Thu, 30 Mar 2000 00:00:44 +0900 From: Yoshihiro Ohba X-Dispatcher: imput version 980905(IM100) Lines: 43 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, > Who is supposed to be the "Downstream" peer is decided by the global (or, > supra-local) entity which has the knowledge of all the LSPs and the topology > of the network. Okay. In such an assumption, an opaque FEC can be used, however..., > An Opaque FEC has to be used for CR-LSP(sec 4.10 in > draft-ietf-mpls-cr-ldp-03) since this feature is there only in CR-LDP and to > setup a CR-LSP it is compulsory. section 4.10 of the CR-LDP draft does not preclude the use of other FECs elements (Type=0x01, 0x02, 0x03) in CR-LDP messages. > One more issue that crops up at this point is that how is this type of LSP > to be setup. The initial scenario that we discussed was > LER1 ------> LSR2-------->LSR3------>LSR4 LER2--------> LSR5 > Now suppose the scenario were like > LER1 ------> LSR2-------->LSR3------>LSR4------>LSR6 LER2--------> LSR5------->LSR7 > and LSR7 was supposed to connect to LSR4. How is the new LSP to be setup? > The global (or, supra-local) entity will inform only LER2 which will be > sending message to LSR5 which would in turn send the request to LSR7. Is > there any standard draft on how this is to be handled? I don't think there is any standard draft proposing to distribute LSPID information to/from the global entity. But is there a situation where the supposed scenario is useful? Yoshihiro Ohba > Santosh Gupta From owner-mpls@UU.NET Wed Mar 29 10:35:15 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21981 for ; Wed, 29 Mar 2000 10:35:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiipy17150; Wed, 29 Mar 2000 15:34:55 GMT Received: by mail-control.mail.uu.net id QQiipy18515 for mpls-outgoing; Wed, 29 Mar 2000 15:34:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiipy18503 for ; Wed, 29 Mar 2000 15:34:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiipy19428 for ; Wed, 29 Mar 2000 10:32:34 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiipy14611 for ; Wed, 29 Mar 2000 15:32:04 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA22392 for mpls@uu.net; Wed, 29 Mar 2000 10:32:03 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiipy18337 for ; Wed, 29 Mar 2000 15:31:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiipy19054 for ; Wed, 29 Mar 2000 10:30:53 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiipy21920 for ; Wed, 29 Mar 2000 15:30:53 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 10:30:55 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB15F8FC@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Thomas D. Nadeau'" , Rob Schmitt , Arun Viswanathan Cc: "Cucchiara, Joan" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" , "'mpls@uu.net'" Subject: RE: LSR MIB comments and questions Date: Wed, 29 Mar 2000 10:30:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tom, > > >I also question why this extra variable is required to > >convey the label space membership attributes. > > > >If mplsInterfaceConfIndex is zero, then it uneqivocally > >has the attributes 'in global label space' and 'not in > >local label space'. > > > >If mplsInterfaceConfIndex is non-zero, that it uneqivocally > >has the attribute 'in local label space' and the 'in > >global label space' variable arbitrates that (optional) > >attribute. > > Yes, but there are cases in ATM where an interface needs > to be part of both label spaces. This is why we have > provided two separate variables here. The combination of the index and ONE of these objects would (I think) allow all combinations. For example, mplsInterfaceConfIndex SYNTAX InterfaceIndexOrZero DESCRIPTION "...A non-zero index for an entry indicates the ifIndex for the corresponding interface entry in (of) the MPLS-layer in the ifTable. Note that the global label space may apply to several interfaces, and therefore the configuration of the global label space interface parameters will apply to all of the interfaces that are participating in the global label space." It has been stated that there will be at most 1 occurance of mplsInterfaceConfIndex == 0 in this table. Which means that the entry represents the perPlatform Label Space. Further, a non-zero value represents the ifIndex (with ifType of mpls(166)) represents a perInterface Label Space for that "mpls interface". Additionally, there are two objects: mplsInterfaceIsGlobalLabelSpace SYNTAX TruthValue DESCRIPTION "This value indicates whether or not this interface participates in the global label space." and mplsInterfaceIsLocalLabelSpace SYNTAX TruthValue DESCRIPTION "This value indicates whether or not this interface uses in the local or per-interface label space." As far as I can tell the object 'mplsInterfaceIsLocalLabelSpace' is redundant with a non-zero value of 'mplsInterfaceConfIndex'. Here are the possible combinations GlobalLabelSpace: mplsInterfaceConfIndex == 0 mplsInterfaceIsGlobalLabelSpace == TRUE Combo (GlobalLabelSpace and LocalLabelSpace) mplsInterfaceConfIndex == non-zero, ifIndex value mplsInterfaceIsGlobalLabelSpace == TRUE LocalLabelSpace mplsInterfaceConfIndex == non-zero, ifIndex value mplsInterfaceIsGlobalLabelSpace == FALSE NOT Possible mplsInterfaceConfIndex == 0 mplsInterfaceIsGlobalLabelSpace == FALSE. Are the above all that are necessary? If not, could the other possibilities be given? Here are suggestions for what they are worth. * Replace the term GlobalLabelSpace with PerPlatformLabelSpace throughout the MIB. * Replace the term LocalLabelSpace with PerInterfaceLabelSpace throughout the MIB. * Remove the object mplsInterfaceIsLocalLabelSpace * Reword the description for the object mplsInterfaceIsGlobalLabelSpace as: mplsInterfacePerPlatformLabelSpaceAlso OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If the value of the 'mplsInterfaceConfIndex is non-zero, and the value of this object is 'true' then the interface represented by this entry also participates in the PerPlatform Label Space as described in Section 3.14 of the MPLS Architecture. If the value of the 'mplsInterfaceConfIndex is zero, then this entry indicates is for the PerPlatform Label Space and the value of this object must be 'true'." -Joan > > --Tom > > From owner-mpls@UU.NET Wed Mar 29 12:13:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22786 for ; Wed, 29 Mar 2000 12:13:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiqe19699; Wed, 29 Mar 2000 17:13:09 GMT Received: by mail-control.mail.uu.net id QQiiqe11901 for mpls-outgoing; Wed, 29 Mar 2000 17:12:32 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiqe11889 for ; Wed, 29 Mar 2000 17:12:15 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiqe00155 for ; Wed, 29 Mar 2000 12:11:58 -0500 (EST) Received: from dnsmx1rrc.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQiiqe18249 for ; Wed, 29 Mar 2000 17:11:57 GMT Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id MAA04883 for ; Wed, 29 Mar 2000 12:11:56 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568B1.005E797C ; Wed, 29 Mar 2000 12:11:54 -0500 X-Lotus-FromDomain: TELCORDIA From: "Gurpreet Singh" To: mpls@UU.NET Message-ID: <852568B1.005E7756.00@notes950.cc.telcordia.com> Date: Wed, 29 Mar 2000 12:11:44 -0500 Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Wed Mar 29 12:44:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23043 for ; Wed, 29 Mar 2000 12:44:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiqg18798; Wed, 29 Mar 2000 17:44:41 GMT Received: by mail-control.mail.uu.net id QQiiqg14643 for mpls-outgoing; Wed, 29 Mar 2000 17:44:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiqg14637 for ; Wed, 29 Mar 2000 17:43:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiqg08152 for ; Wed, 29 Mar 2000 12:43:03 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiiqg07410 for ; Wed, 29 Mar 2000 17:43:02 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id MAA20306; Wed, 29 Mar 2000 12:42:55 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id MAA56136; Wed, 29 Mar 2000 12:42:33 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003291742.MAA56136@curtis-lt.avici.com> To: "James V. Luciani" cc: "Yakov Rekhter" , "Krishna Bala" , "Jagan Shantigram" , "Jonathan Lang" , curtis@avici.com, "Khaled Elsayed" , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Reply-To: curtis@avici.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Tue, 28 Mar 2000 23:25:11 EST." <007a01bf9936$ca31ac80$3c03fea9@jluciani> Date: Wed, 29 Mar 2000 12:42:33 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <007a01bf9936$ca31ac80$3c03fea9@jluciani>, "James V. Luciani" writes : > Yakov, > Wow, such rapier-like wit and technical depth all wrapped in a > one-liner. Now if you would like to help clarify the issue rather than > snipe at someone who is trying to be helpful, I for one would like to hear > your input. > --Jim Jim, Maybe Yakov just didn't like the suggested term "augmented routing model". I certainly didn't. I suggested that we make the distinction between "static overlay" and "signaled overlay". What you describe as X would be signaled overlay. Curtis btw- NHRP and MPOA might be bad examples. > ----- Original Message ----- > From: Yakov Rekhter > To: James V. Luciani > Cc: Krishna Bala ; Jagan Shantigram ; > Jonathan Lang ; ; Khaled Elsayed > ; ; > Sent: Monday, March 27, 2000 7:31 PM > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > Jim, > > > > > > Just to beat a dead horse .. the difference between the open model > > > > and the overlay is just that the overlay model typically suggests that > > > > > > That depends... see below. > > > > > > > there would be N^2 connectivity (i.e., every router, for instance, is > > > > statically connected to every other). In any case, the open model > allows > > > > > > While there may indeed be some misunderstanding as to the meaning of the > > > "overlay model" (not to mention the meaning of the other models :-)), > the > > > traditional definition of overlay is not one of static operation. NHRP > and > > > MPOA, for example, are overlay in my book (and most folks that I know). > > > > > > They most certainly imply non-static connections by defintion (i.e., use > of > > > SVCs). This having been said, I believe that we can do one of two > things > > > here. One, keep the current terms and potentially risk an ad nauseum > > > inspection of the meaning of these terms; or two, come up with a term > which > > > is satisfactory to all. In the second case we would have models: > > > 1) X > > > 2) Peer > > > where X is the PC term for what we want to get at. So my opine is that > > > X="augmented routing model"/ARM model. > > > > > > Do I hear a hmmmm??? > > > > I think you do. And it comes from you - it is your own hmmm. > > > > Yakov. > > From owner-mpls@UU.NET Wed Mar 29 13:23:28 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23316 for ; Wed, 29 Mar 2000 13:23:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiqj16367; Wed, 29 Mar 2000 18:23:15 GMT Received: by mail-control.mail.uu.net id QQiiqj26246 for mpls-outgoing; Wed, 29 Mar 2000 18:22:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiqj26238 for ; Wed, 29 Mar 2000 18:22:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiqj16784 for ; Wed, 29 Mar 2000 13:21:50 -0500 (EST) Received: from dnsmx1rrc.telcordia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQiiqj12088 for ; Wed, 29 Mar 2000 18:21:44 GMT Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id NAA10667 for ; Wed, 29 Mar 2000 13:21:37 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568B1.0064D963 ; Wed, 29 Mar 2000 13:21:32 -0500 X-Lotus-FromDomain: TELCORDIA From: "Gurpreet Singh" To: mpls@UU.NET Message-ID: <852568B1.0064D35E.00@notes950.cc.telcordia.com> Date: Wed, 29 Mar 2000 13:21:11 -0500 Subject: MPLS Performnce Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi Folks Is there any information available related to performance evaluation of an LSR implementing MPLS. Thanks Gurpreet From owner-mpls@UU.NET Wed Mar 29 13:28:58 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23336 for ; Wed, 29 Mar 2000 13:28:57 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiqj16996; Wed, 29 Mar 2000 18:28:39 GMT Received: by mail-control.mail.uu.net id QQiiqj26678 for mpls-outgoing; Wed, 29 Mar 2000 18:28:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiqj26670 for ; Wed, 29 Mar 2000 18:27:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiqj17705 for ; Wed, 29 Mar 2000 13:27:43 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiiqj16273 for ; Wed, 29 Mar 2000 18:27:43 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id NAA23757; Wed, 29 Mar 2000 13:27:00 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id NAA56424; Wed, 29 Mar 2000 13:27:23 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003291827.NAA56424@curtis-lt.avici.com> To: iwata@ccm.CL.nec.co.jp cc: "Peter Ashwood-Smith" , mpls@UU.NET, "'Andrzej Czerczak'" , Norihito Fujita Reply-To: curtis@avici.com Subject: Re: MPLS routing accross AS boundaries In-reply-to: Your message of "Wed, 29 Mar 2000 23:09:42 +0900." <4.2.0.58.J.20000329230505.00a41be0@momotaro.labs.nec.co.jp> Date: Wed, 29 Mar 2000 13:27:23 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4.2.0.58.J.20000329230505.00a41be0@momotaro.labs.nec.co.jp>, Atsush i Iwata writes: > Hi, all > > The draft that peter mentioned is our following draft. > > draft-fujita-ospf-te-summary-00.txt > > This approach assumes a hierarchical QoS path computation that PNNI routing > protocol does in the ATM world. > > I would like to get any opinion or any suggestions (Pros and Cons) on this > approach. > > Regards, Someone needed to do this. You are missing some key parameters like reservable bandwidth at each of the 8 priority levels. There is no good way to specify colr since we're not talking about a link. This is not interprovider, but rather inter-area in OSPF. Besides advertising this information a LSR also needs to do something with it when forming an ERO. You should have some sort of usage section. For example, if a BGP route has a next hop covered by the area, then the ERO would contain a router to an ABR ending with a loose hop to the BGP next hop address. The ABR may either replace the loose hop with a set of strict hops, or put the LSP into an existing aggregate tunnel. In this case the aggregate tunnel may go from the ABR all the way to the network edge. The PSC in draft-kompella-mpls-optical-00.txt serves a similar purpose when the endpoints of the aggregate tunnel are not the ABR and the area edge. In the former case there is no signaling of a PSC required within the area. Curtis From owner-mpls@UU.NET Wed Mar 29 14:58:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23946 for ; Wed, 29 Mar 2000 14:58:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiqp17513; Wed, 29 Mar 2000 19:58:23 GMT Received: by mail-control.mail.uu.net id QQiiqp10195 for mpls-outgoing; Wed, 29 Mar 2000 19:58:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiqp10190 for ; Wed, 29 Mar 2000 19:57:54 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiqp02922 for ; Wed, 29 Mar 2000 14:57:52 -0500 (EST) Received: from alpha.dtix.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.dtix.com [198.62.174.1]) id QQiiqp17092 for ; Wed, 29 Mar 2000 19:57:51 GMT Received: from salmon (beta.dtix.com [198.62.174.3]) by alpha.dtix.com (8.9.3/8.8.7) with SMTP id PAA28350; Wed, 29 Mar 2000 15:08:26 -0500 Message-ID: <009901bf99b9$9547bf90$9dae3ec6@salmon> From: "Subodh Mathur" To: "Santosh Gupta" Cc: References: <200003281352.WAA17076@toshiba.co.jp> <003701bf9941$d53afcc0$100d85a5@dti.daewoo.co.kr> Subject: Re: CR-LDP Date: Wed, 29 Mar 2000 15:01:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit By using loose hop problem mentioned below can be solved. Suppose second LSP is to terminate at LER10 which is topologically adjacent to LSR6. LER2----->LSR5----->LSR7----->LSR4----->LSR6----->LER10 So if LER2 construct a ER TLV with ER-Hops where LER10 is a loose ER-Hop. LSR7 will determine using some routing algo. that LSR4 is the next hop. So it will modify the ER TLV as . Now LSR4 can use its knowledge of existing LSP ID for tunneling and ER TLV will be . Subodh > One more issue that crops up at this point is that how is this type of LSP > to be setup. The initial scenario that we discussed was > > LER1 ------> LSR2-------->LSR3------>LSR4 > > LER2-------->LSR5 > > Now suppose the scenario were like > > LER1 ------> LSR2-------->LSR3------>LSR4------>LSR6 > > LER2-------->LSR5------->LSR7 > > and LSR7 was supposed to connect to LSR4. How is the new LSP to be setup? > The global (or, supra-local) entity will inform only LER2 which will be > sending message to LSR5 which would in turn send the request to LSR7. Is > there any standard draft on how this is to be handled? > > Santosh Gupta > From owner-mpls@UU.NET Wed Mar 29 17:06:11 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24926 for ; Wed, 29 Mar 2000 17:06:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiqy08734; Wed, 29 Mar 2000 22:05:53 GMT Received: by mail-control.mail.uu.net id QQiiqy12101 for mpls-outgoing; Wed, 29 Mar 2000 22:05:29 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiqy12096 for ; Wed, 29 Mar 2000 22:05:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiqy25208 for ; Wed, 29 Mar 2000 17:05:21 -0500 (EST) Received: from nsa-mail.us.newbridge.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [209.58.11.226]) id QQiiqy11362 for ; Wed, 29 Mar 2000 22:05:20 GMT Received: (from smtpd@localhost) by nsa-mail.us.newbridge.com (8.9.3/8.9.2) id QAA15072 for ; Wed, 29 Mar 2000 16:59:10 -0500 (EST) Received: from nsa-gw1.us.newbridge.com(209.58.11.225), claiming to be "herndon-mh1.us.newbridge.com" via SMTP by nsa-mail.us.newbridge.com, id smtpdAAAa003fQ; Wed Mar 29 16:58:58 2000 Received: from nsamail01.us.newbridge.com by herndon-mh1.us.newbridge.com with ESMTP for mpls@UU.NET; Wed, 29 Mar 2000 17:05:03 -0500 Received: from newbridge.com ([138.120.241.43]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA7C9; Wed, 29 Mar 2000 17:05:02 -0500 Message-Id: <38E27BF8.5D1DC71A@newbridge.com> Date: Wed, 29 Mar 2000 16:56:08 -0500 From: "Phani Koganti" Reply-To: pkoganti@newbridge.com Organization: Newbridge Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ashwood-Smith CC: "'Andrzej Czerczak'" , mpls@UU.NET Subject: Re: MPLS routing accross AS boundaries References: <03E3E0690542D211A1490000F80836F4029F977D@zcard00f.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------8809A05EFBBF4402E3AD2BC2" Sender: owner-mpls@UU.NET Precedence: bulk --------------8809A05EFBBF4402E3AD2BC2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have been doing some thinking on this area for a while, but am not sure if i am in the right direction. Please correct me where ever neccessary. For Qos routing across autonomous systems isn't it required that there be a mechanism to figure out whether we have the required Qos end to end. Doesn't Bandwidth broker concept address the inter-domain Qos routing ? Instead of having a centralized entity per AS as in bandwidth broker architecture, if all the routers running BGP can generate bandwidth and QoS related attributes for the routes generated from the AS (along with the labels). As a result based on the policies the routers can have multiple routes to a destination mapping to different Qos/bandwidths. So seems like we need a well defined mechanism to export the traffic engineering attributes of the IGP protocols to the BGP protocol and also, the intermediate ASs when forwarding the routes received need to figure out the QoS/bandwidth available to the next-hop and forward the cumulative QoS/Bandwidth constrained route to other ASs. Phani Phanidhar Koganti Newbridge Networks Inc. Peter Ashwood-Smith wrote: > > > Currently the MPLS working group has not addressed this subject in any > depth although there was a draft presented in the routing area group > today in Adelaide that started to talk about solutions. > > As far as I know there are basically two ways to attack this problem, > or at least two general flavors. > > piecewise source routing. In this approach you compute a gateway based > on the destination address and then do normal flat source routing to > that gateway. Go through the gateway and repeat. In other words you > are doing piecewise traffic engineering but letting the exterior > gateway protocols figure out which gateway you should be going to > next. Obviously there are problems with this approach since it puts > everything though the same gateway. I actually helped built a > piecewise solution like this a while ago. It has some good advantages > in that local (at least local to an AS) repair is natural to do as are > local modification etc. > > hierarchical source routing. This is what ATM does, you compute a hop > list hierarchically against a hierarchical topology database etc. etc. > I'm not sure this approach is appropriate for the Internet due to the > massive size of the problem but I'm really not an ATM hierarchical > routing guy. > > I would hope that the MPLS working group or the Traffic Engineering > working group can start looking at these issues, possibly with some > simulations of the different approaches against a set of real AS > topologies. Some of the PNNI architects and BGP architects are active > members of the MPLS working group so you can be sure that it will > cause some heated debate ... should be extremely interesting and > challenging. > > Cheers, > > Peter > > > -----Original Message----- > From: Andrzej Czerczak [SMTP:Andrzej_Czerczak/HeadQ@netia.pl] > Sent: Tuesday, March 28, 2000 6:04 AM > To: mpls@UU.NET > Subject: MPLS routing accross AS boundaries > > Hi, > Where can I get information on the subject of MPLS QoS routing > accross > Autonomous System boundaries? > > Thanks > Andrzej > --------------8809A05EFBBF4402E3AD2BC2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I have been doing some thinking on this area for a while, but am not sure if i am in the right direction. Please correct me where ever neccessary.

For Qos routing across autonomous systems isn't it required that there be a mechanism to figure out whether we have the required Qos end to end.

Doesn't Bandwidth broker concept address the inter-domain Qos routing ?

Instead of having a centralized entity per AS as in bandwidth broker architecture, if all the routers running BGP can generate bandwidth and QoS related attributes for the routes generated from the AS (along with the labels). As a result based on the policies the routers can have multiple routes to a destination mapping to different Qos/bandwidths.

So seems like we need a well defined mechanism to export the traffic engineering attributes of the IGP protocols to the BGP protocol and also, the intermediate ASs when forwarding the routes received need to figure out the QoS/bandwidth available to the next-hop and forward the cumulative QoS/Bandwidth constrained route to other ASs.

Phani

Phanidhar Koganti
Newbridge Networks Inc.

Peter Ashwood-Smith wrote:

 

Currently the MPLS working group has not addressed this subject in any depth although there was a draft presented in the routing area group today in Adelaide that started to talk about solutions.

As far as I know there are basically two ways to attack this problem, or at least two general flavors.

piecewise source routing. In this approach you compute a gateway based on the destination address and then do normal flat source routing to that gateway. Go through the gateway and repeat. In other words you are doing piecewise traffic engineering but letting the exterior gateway protocols figure out which gateway you should be going to next. Obviously there are problems with this approach since it puts everything though the same gateway. I actually helped built a piecewise solution like this a while ago. It has some good advantages in that local (at least local to an AS) repair is natural to do as are local modification etc.

hierarchical source routing. This is what ATM does, you compute a hop list hierarchically against a hierarchical topology database etc. etc. I'm not sure this approach is appropriate for the Internet due to the massive size of the problem but I'm really not an ATM hierarchical routing guy.

I would hope that the MPLS working group or the Traffic Engineering working group can start looking at these issues, possibly with some simulations of the different approaches against a set of real AS topologies. Some of the PNNI architects and BGP architects are active members  of the MPLS working group so you can be sure that it will cause some heated debate ... should be extremely interesting and challenging.

Cheers,

Peter
 

    -----Original Message-----
    From:   Andrzej Czerczak [SMTP:Andrzej_Czerczak/HeadQ@netia.pl]
    Sent:   Tuesday, March 28, 2000 6:04 AM
    To:     mpls@UU.NET
    Subject:        MPLS routing accross AS boundaries

    Hi,
     Where can I get information on the subject of MPLS QoS routing accross
    Autonomous System boundaries?

    Thanks
    Andrzej

--------------8809A05EFBBF4402E3AD2BC2-- From owner-mpls@UU.NET Wed Mar 29 17:29:19 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25075 for ; Wed, 29 Mar 2000 17:29:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiqz22515; Wed, 29 Mar 2000 22:29:03 GMT Received: by mail-control.mail.uu.net id QQiiqz13516 for mpls-outgoing; Wed, 29 Mar 2000 22:28:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiqz13509 for ; Wed, 29 Mar 2000 22:28:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiqz28678 for ; Wed, 29 Mar 2000 17:28:24 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQiiqz22062 for ; Wed, 29 Mar 2000 22:28:24 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Wed, 29 Mar 2000 17:28:01 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CFB2@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Subject: RE: MPLS routing accross AS boundaries Date: Wed, 29 Mar 2000 17:28:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I'm probably out of my league here so please correct me. One of the rules of BGP, and in general inter-domain routing protocols is to advertise reachability to other AS's, while hiding as much as possible the local AS's topology. Such that when route Ax (AS A, route x) needs to send a packet to an address D, the only thing it will learn from BGP is that there's a route to the destination D, that travels through some AS's along the way. It will also learn the egress router in his own AS that needs to get the packet. How he needs to get to the egress router is a matter for an IGP to resolve. Any of this correct ? Now my question is, why can't this model be followed under traffic engineering conditions ? Router Ax will learn from BGP what is the local AS egress point towards D. It will then consult the IGP-TE database and construct an explicit route to that router, and tuck at the end a loose route to D. It is then the egress router's job to "fix" the explicit route such that the ERO now reflects the route to the next AS. The Ingress router in transit AS's will do just the same - it will change the ERO (that now contains 2 entries - one that indicates the current AS, and one for the end destination) such that it contains a strict route accross the new current AS and a loose route to the destination. and so on till the destination AS. Each BGP router can consult what ever TE constraits it has to deceid what BGP next hop to use, but it will only construct a strict route through the local AS and append a loose route to the final destination. Please let me know if this makes some sense. From owner-mpls@UU.NET Wed Mar 29 17:59:23 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25261 for ; Wed, 29 Mar 2000 17:59:23 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiirb13576; Wed, 29 Mar 2000 22:59:11 GMT Received: by mail-control.mail.uu.net id QQiirb15310 for mpls-outgoing; Wed, 29 Mar 2000 22:58:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiirb15305 for ; Wed, 29 Mar 2000 22:58:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiirb02949 for ; Wed, 29 Mar 2000 17:58:35 -0500 (EST) Received: from mailgate.fore.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQiirb13069 for ; Wed, 29 Mar 2000 22:58:30 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA29082 for ; Wed, 29 Mar 2000 17:58:27 -0500 (EST) Received: from fore.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA05822 for ; Wed, 29 Mar 2000 17:58:30 -0500 (EST) Message-ID: <38E28A7D.134BD731@fore.com> Date: Wed, 29 Mar 2000 17:58:05 -0500 From: David Charlap X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: MPLS mailing list Subject: Re: MPLS routing accross AS boundaries References: <496A8683261CD211BF6C0008C733261A48CFB2@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Abes, Andi" wrote: > > Now my question is, why can't this model be followed under traffic > engineering conditions ? > > Router Ax will learn from BGP what is the local AS egress point > towards D. It will then consult the IGP-TE database and construct an > explicit route to that router, and tuck at the end a loose route to D. > It is then the egress router's job to "fix" the explicit route such > that the ERO now reflects the route to the next AS. The Ingress router > in transit AS's will do just the same - it will change the ERO (that > now contains 2 entries - one that indicates the current AS, and one > for the end destination) such that it contains a strict route accross > the new current AS and a loose route to the destination. and so on > till the destination AS. Actually, you should be able to do better than this (if RSVP-TE is used, anyway. I don't know about CR-LDP) According to draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, the explicit route object supports an AS-number subobject. So, the ingress router should be able to get (from BGP) an explicit route of AS numbers from source to destination. It can make an ERO that begins with the hops through the local net, and ends with the list of AS numbers for ASes beyond the local network. Upon arrival in the next AS, the router there can replace the AS-subobject for itself with a per-hop route to the next AS on the list. And so on. So the ingress router can't specify the complete path, but it can specify which ASes it wants the path to go through on its way to the destination AS. > Each BGP router can consult what ever TE constraits it has to deceid > what BGP next hop to use, but it will only construct a strict route > through the local AS and append a loose route to the final > destination. It could do this also. A loose route from the last local router to the final destination could work, but that means the actual path chosen is left completely up to the routers in other ASes. A route that explicitly lists ASes may be better. There is still some looseness, since each AS will determine its own route through, but you can keep the route going through the ASes you want. The first way would definitely be easier to implement, but the second way might also be desirable under certain circumstances. -- David From owner-mpls@UU.NET Wed Mar 29 18:03:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25342 for ; Wed, 29 Mar 2000 18:03:04 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiirc12508; Wed, 29 Mar 2000 23:02:53 GMT Received: by mail-control.mail.uu.net id QQiirc22237 for mpls-outgoing; Wed, 29 Mar 2000 23:02:22 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiirc21688 for ; Wed, 29 Mar 2000 23:02:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiirc20824 for ; Wed, 29 Mar 2000 18:01:54 -0500 (EST) Received: from adn.alcatel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: workstation.adn.alcatel.com [198.205.32.33] (may be forged)) id QQiirc11628 for ; Wed, 29 Mar 2000 23:01:53 GMT Received: from postal.adn.alcatel.com (postal [143.209.80.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id RAA29861 for ; Wed, 29 Mar 2000 17:54:49 -0500 (EST) Received: from adn.alcatel.com ([143.209.82.55]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA180D; Wed, 29 Mar 2000 18:08:32 -0500 Message-ID: <38E28B2C.DEEF90A6@adn.alcatel.com> Date: Wed, 29 Mar 2000 18:01:00 -0500 From: Ben Abarbanel X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Abes, Andi" CC: MPLS mailing list Subject: Re: MPLS routing accross AS boundaries References: <496A8683261CD211BF6C0008C733261A48CFB2@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps maybe the gentlemen was looking at the traffic engineering level from a much higher view and is considering a virtual tunnel that treats each AS as a node. The AS-Path attribute in BGP route is used to define the AS path a route is propagated through. Maybe additional attribute information can be piggybacked to each AS-PATH entry, which would allow for traffic engineering steering of these tunnels. Maybe some sort of traffic engineering modeling can be done at this higher plane? I will agree that the current model of a strict tunnel formed between the Ingress and Egress IBGP routers will take us from one end of the AS to the other, then applying loose routes between ASs, then strict again within the other transient ASs. This will work, but requires a more AS to AS traffic engineering tuning. The overall path that is formed by a series of strict and loose tunnels may not be optimal for traffic engineering the entire Internet. The example I mentioned above treats all the ASs as one entity and thereby allows for a more global view of traffic engineering management. Regards, Ben "Abes, Andi" wrote: > Hi, > > I'm probably out of my league here so please correct me. > > One of the rules of BGP, and in general inter-domain routing protocols > is to advertise reachability to other AS's, while hiding as much as possible > > the local AS's topology. > > Such that when route Ax (AS A, route x) needs to send a packet to an address > D, the only thing it will learn from BGP is that there's a route to the > destination D, that travels through some AS's along the way. It will also > learn the egress router in his own AS that needs to get the packet. > How he needs to get to the egress router is a matter for an IGP to resolve. > > Any of this correct ? > > Now my question is, why can't this model be followed under traffic > engineering conditions ? > > Router Ax will learn from BGP what is the local AS egress point towards D. > It will then consult the IGP-TE database and construct an explicit route to > that router, and tuck at the end a loose route to D. > It is then the egress router's job to "fix" the explicit route such that the > ERO now reflects the route to the next AS. The Ingress router in transit > AS's will do just the same - it will change the ERO (that now contains 2 > entries - one that indicates the current AS, and one for the end > destination) such that it contains a strict route accross the new current AS > and a loose route to the destination. > and so on till the destination AS. > > Each BGP router can consult what ever TE constraits it has to deceid what > BGP next hop to use, but it will only construct a strict route through the > local AS and append a loose route to the final destination. > > Please let me know if this makes some sense. > > > > > > > > > > > > > -- Remember ======== "Don't be afraid to try something new. Amateurs built the Arc, professionals built Titanic" From owner-mpls@UU.NET Wed Mar 29 18:25:33 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25462 for ; Wed, 29 Mar 2000 18:25:31 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiird25420; Wed, 29 Mar 2000 23:25:13 GMT Received: by mail-control.mail.uu.net id QQiird25347 for mpls-outgoing; Wed, 29 Mar 2000 23:24:43 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiird25342 for ; Wed, 29 Mar 2000 23:24:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiird06735 for ; Wed, 29 Mar 2000 18:24:12 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQiird24677 for ; Wed, 29 Mar 2000 23:24:12 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Wed, 29 Mar 2000 17:06:45 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 17:04:14 -0600 Message-ID: <03E3E0690542D211A1490000F80836F4029F9781@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: MPLS mailing list Cc: "Bilel Jamoussi" Subject: RE: MPLS routing accross AS boundaries Date: Wed, 29 Mar 2000 17:04:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF99D3.19E47036" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF99D3.19E47036 Content-Type: text/plain; charset="iso-8859-1" All of it is correct and you are perfectly right that it is possible to do local constraint based routing between AS's but not over the AS. This is called stepwise or piecewise constraint based routing as opposed to hierarchical constraint based routing which requires that summarized constraint information cross AS boundaries. My own opinion, for what it is worth, is that we will probably have to start with piecewise routing since this is relatively easy to do. Then we can look at ways to make better gateway decisions based on constraints, possibly with more elaborate forms of inter AS feedback. We will have far more success getting something working reasonably well if we keep the solution simple and start with stepwise. My guess is the BGP guys will like this idea and the PNNI guys will prefer full hierarchy. Like I said though some simulations are probably in order here to help put things properly in perspective. This would be a great project for a masters student somewhere, simulate the two approaches for a set of real AS and come to PA with some results. Perhaps some of the George Mason Students from the advanced research lab would be interested in doing this? Cheers, Peter Ashwod-Smith -----Original Message----- From: Abes, Andi [SMTP:aabes@quarrytech.com] Sent: Wednesday, March 29, 2000 5:28 PM To: MPLS mailing list Subject: RE: MPLS routing accross AS boundaries Hi, I'm probably out of my league here so please correct me. One of the rules of BGP, and in general inter-domain routing protocols is to advertise reachability to other AS's, while hiding as much as possible the local AS's topology. Such that when route Ax (AS A, route x) needs to send a packet to an address D, the only thing it will learn from BGP is that there's a route to the destination D, that travels through some AS's along the way. It will also learn the egress router in his own AS that needs to get the packet. How he needs to get to the egress router is a matter for an IGP to resolve. Any of this correct ? Now my question is, why can't this model be followed under traffic engineering conditions ? Router Ax will learn from BGP what is the local AS egress point towards D. It will then consult the IGP-TE database and construct an explicit route to that router, and tuck at the end a loose route to D. It is then the egress router's job to "fix" the explicit route such that the ERO now reflects the route to the next AS. The Ingress router in transit AS's will do just the same - it will change the ERO (that now contains 2 entries - one that indicates the current AS, and one for the end destination) such that it contains a strict route accross the new current AS and a loose route to the destination. and so on till the destination AS. Each BGP router can consult what ever TE constraits it has to deceid what BGP next hop to use, but it will only construct a strict route through the local AS and append a loose route to the final destination. Please let me know if this makes some sense. ------_=_NextPart_001_01BF99D3.19E47036 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS routing accross AS boundaries

All of it is correct and you are = perfectly right that it is possible to do local constraint based = routing between AS's but not over the AS. This is called stepwise or = piecewise constraint based routing as opposed to hierarchical = constraint based routing which requires that summarized constraint = information cross AS boundaries.

My own opinion, for what it is worth, = is that we will probably have to start with piecewise routing since = this is relatively easy to do.  Then we can look at ways to make = better gateway decisions based on constraints, possibly with more = elaborate forms of inter AS feedback. We will have far more success = getting something working reasonably well if we keep the solution = simple and start with stepwise.

My guess is the BGP guys will like = this idea and the PNNI guys will prefer full hierarchy. Like I said = though some simulations are probably in order here to help put things = properly in perspective.

This would be a great project for a = masters student somewhere, simulate the two approaches for a set of = real AS and come to PA with some results. Perhaps some of the George = Mason Students from the advanced research lab would be interested in = doing this?

Cheers,

Peter Ashwod-Smith

    -----Original = Message-----
    From:   Abes, Andi = [SMTP:aabes@quarrytech.com]
    Sent:   Wednesday, March 29, 2000 5:28 PM
    To:     MPLS mailing list
    Subject:       = RE: MPLS routing accross AS = boundaries

    Hi,
     
    I'm probably out of my league here so = please correct me.
     
    One of the rules of BGP, and in = general inter-domain routing protocols
    is to advertise reachability to other = AS's, while hiding as much as possible

    the local AS's topology.
     
    Such that when route Ax (AS A, route = x) needs to send a packet to an address
    D, the only thing it will learn from = BGP is that there's a route to the
    destination D, that travels through = some AS's along the way. It will also
    learn the egress router in his own AS = that needs to get the packet.
    How he needs to get to the egress = router is a matter for an IGP to resolve.
     
    Any of this correct ?
     
    Now my question is, why can't this = model be followed under traffic
    engineering conditions ?
     
    Router Ax will learn from BGP what is = the local AS egress point towards D.
    It will then consult the IGP-TE = database and construct an explicit route to
    that router, and tuck at the end a = loose route to D.
    It is then the egress router's job to = "fix" the explicit route such that the
    ERO now reflects the route to the = next AS. The Ingress router in transit
    AS's will do just the same - it will = change the ERO (that now contains 2
    entries - one that indicates the = current AS, and one for the end
    destination) such that it contains a = strict route accross the new current AS
    and a loose route to the = destination.
    and so on till the destination = AS.
     
    Each BGP router can consult what ever = TE constraits it has to deceid what
    BGP next hop to use, but it will only = construct a strict route through the
    local AS and append a loose route to = the final destination.
     
    Please let me know if this makes some = sense.
     
     
     
     
     
     
     
     
     
     
     

            

------_=_NextPart_001_01BF99D3.19E47036-- From owner-mpls@UU.NET Wed Mar 29 19:01:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25869 for ; Wed, 29 Mar 2000 19:01:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiirg18312; Thu, 30 Mar 2000 00:00:49 GMT Received: by mail-control.mail.uu.net id QQiirg28018 for mpls-outgoing; Thu, 30 Mar 2000 00:00:02 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiirf27934 for ; Wed, 29 Mar 2000 23:59:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiirf27611 for ; Wed, 29 Mar 2000 18:59:46 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQiirf17555 for ; Wed, 29 Mar 2000 23:59:45 GMT Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Wed, 29 Mar 2000 18:09:33 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 18:09:30 -0500 Message-ID: <03E3E0690542D211A1490000F80836F4029F9782@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'Gurpreet Singh'" , mpls@UU.NET Subject: RE: MPLS Performnce Date: Wed, 29 Mar 2000 18:09:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF99D3.D5FAFA4C" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF99D3.D5FAFA4C Content-Type: text/plain; charset="iso-8859-1" Yes, of course but you don't expect any of us to publish figures here do you? Contact the respective company marketing folks to get this kind of data. You might be able to get some public domain code figures here though ... not sure. Peter -----Original Message----- From: Gurpreet Singh [SMTP:gsingh1@telcordia.com] Sent: Wednesday, March 29, 2000 1:21 PM To: mpls@UU.NET Subject: MPLS Performnce Hi Folks Is there any information available related to performance evaluation of an LSR implementing MPLS. Thanks Gurpreet ------_=_NextPart_001_01BF99D3.D5FAFA4C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS Performnce

Yes, of course but you don't expect = any of us to publish figures here do you?

Contact the respective company = marketing folks to get this kind of data. You might be able to get some = public domain code figures here though ... not sure.

Peter

    -----Original = Message-----
    From:   Gurpreet Singh = [SMTP:gsingh1@telcordia.com]
    Sent:   Wednesday, March 29, 2000 1:21 PM
    To:     mpls@UU.NET
    Subject:       = MPLS Performnce



    Hi Folks

    Is there any information available = related to performance evaluation of an LSR
    implementing MPLS.


    Thanks

    Gurpreet

------_=_NextPart_001_01BF99D3.D5FAFA4C-- From owner-mpls@UU.NET Wed Mar 29 19:03:33 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25936 for ; Wed, 29 Mar 2000 19:03:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiirg19565; Thu, 30 Mar 2000 00:02:48 GMT Received: by mail-control.mail.uu.net id QQiirg03591 for mpls-outgoing; Thu, 30 Mar 2000 00:02:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiirg03309 for ; Thu, 30 Mar 2000 00:02:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiirg11077 for ; Wed, 29 Mar 2000 19:01:48 -0500 (EST) Received: from nsa-mail.us.newbridge.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [209.58.11.226]) id QQiirg18962 for ; Thu, 30 Mar 2000 00:01:48 GMT Received: (from smtpd@localhost) by nsa-mail.us.newbridge.com (8.9.3/8.9.2) id SAA18168 for ; Wed, 29 Mar 2000 18:55:39 -0500 (EST) Received: from nsa-gw1.us.newbridge.com(209.58.11.225), claiming to be "herndon-mh1.us.newbridge.com" via SMTP by nsa-mail.us.newbridge.com, id smtpdBAAa004Rk; Wed Mar 29 18:55:35 2000 Received: from nsamail01.us.newbridge.com by herndon-mh1.us.newbridge.com with ESMTP for MPLS@UU.NET; Wed, 29 Mar 2000 19:01:41 -0500 Received: from newbridge.com ([138.120.241.43]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA26EF; Wed, 29 Mar 2000 19:01:39 -0500 Message-Id: <38E2974E.A0E8DAEB@newbridge.com> Date: Wed, 29 Mar 2000 18:52:47 -0500 From: "Phani Koganti" Reply-To: pkoganti@newbridge.com Organization: Newbridge Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Abarbanel CC: "Abes, Andi" , MPLS mailing list Subject: Re: MPLS routing accross AS boundaries References: <496A8683261CD211BF6C0008C733261A48CFB2@email.quarrytech.com> <38E28B2C.DEEF90A6@adn.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yes i indeed was looking at traffic engineering across ASs from a very high level. By propagating TE attributes along with AS_PATH for a BGP route, another dimension will be added to route selection across AS boundaries. This will find a optimised path for the required QoS/Bandwidth from say AS x and AS y provided there are multiple paths present. Surely when signalling a MPLS LSP the ingress LSR of each AS specified will calculate a explicit route based on the constraints. Ben Abarbanel wrote: > Perhaps maybe the gentlemen was looking at the traffic engineering level from a > much higher view and > is considering a virtual tunnel that treats each AS as a node. The AS-Path > attribute in BGP route is used > to define the AS path a route is propagated through. Maybe additional attribute > information can be piggybacked to each AS-PATH entry, which would allow for > traffic engineering steering of these tunnels. Maybe some sort of traffic > engineering modeling can be done at this higher plane? > > I will agree that the current model of a strict tunnel formed between the > Ingress and Egress IBGP routers will take us from one end of the AS to the > other, then applying loose routes between ASs, then strict again within the > other transient ASs. This will work, but requires a more AS to AS traffic > engineering tuning. The overall path that is formed by a series of strict and > loose tunnels may not be optimal for traffic engineering > the entire Internet. > > The example I mentioned above treats all the ASs as one entity and thereby > allows for a more global view of traffic engineering management. > > Regards, > Ben > > "Abes, Andi" wrote: > > > Hi, > > > > I'm probably out of my league here so please correct me. > > > > One of the rules of BGP, and in general inter-domain routing protocols > > is to advertise reachability to other AS's, while hiding as much as possible > > > > the local AS's topology. > > > > Such that when route Ax (AS A, route x) needs to send a packet to an address > > D, the only thing it will learn from BGP is that there's a route to the > > destination D, that travels through some AS's along the way. It will also > > learn the egress router in his own AS that needs to get the packet. > > How he needs to get to the egress router is a matter for an IGP to resolve. > > > > Any of this correct ? > > > > Now my question is, why can't this model be followed under traffic > > engineering conditions ? > > > > Router Ax will learn from BGP what is the local AS egress point towards D. > > It will then consult the IGP-TE database and construct an explicit route to > > that router, and tuck at the end a loose route to D. > > It is then the egress router's job to "fix" the explicit route such that the > > ERO now reflects the route to the next AS. The Ingress router in transit > > AS's will do just the same - it will change the ERO (that now contains 2 > > entries - one that indicates the current AS, and one for the end > > destination) such that it contains a strict route accross the new current AS > > and a loose route to the destination. > > and so on till the destination AS. > > > > Each BGP router can consult what ever TE constraits it has to deceid what > > BGP next hop to use, but it will only construct a strict route through the > > local AS and append a loose route to the final destination. > > > > Please let me know if this makes some sense. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Remember > ======== > "Don't be afraid to try something new. Amateurs built the Arc, professionals > built Titanic" From owner-mpls@UU.NET Wed Mar 29 20:56:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26982 for ; Wed, 29 Mar 2000 20:56:16 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiirn24092; Thu, 30 Mar 2000 01:56:02 GMT Received: by mail-control.mail.uu.net id QQiirn24411 for mpls-outgoing; Thu, 30 Mar 2000 01:55:32 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiirn24398 for ; Thu, 30 Mar 2000 01:55:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiirn25849 for ; Wed, 29 Mar 2000 20:55:03 -0500 (EST) Received: from hercules by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQiirn25876 for ; Thu, 30 Mar 2000 01:55:03 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id RAA17278; Wed, 29 Mar 2000 17:54:54 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 17:54:54 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A6346862@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Juha Heinanen'" , "'mpls@UU.NET'" Subject: RE: tspec table Date: Wed, 29 Mar 2000 17:54:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Juha, > arun, > > i'm not sure if the tspec table has much value if it only > contains a set > of leaky bucket parameters. it should be accurately describe the > traffic characteristics (traffic class(es) plus traffic parameters) of > the lsps. if the traffic characteristics currenly expressable by rsvp > and crldp are not all included, then it would be better to leave the > whole table out until we have a proper qos mib to refer to. > I can only sympathize with your comments. There was no Tspec table earlier. Having no table at all doesn't help either. Defining a router-wide QoS MIB is outside the charter of this WG, and getting convergence on something like QoS is yet another story. Seems to me that the current TSpec table must be used in lieu of a QoS MIB till such time it becomes available. I would like to suggest that we have a row pointer to the TSpec table. That way, some implementation can replace the TSpec table with vendor specific MIB or the QoS MIB when it becomes available. -arun From owner-mpls@UU.NET Wed Mar 29 22:54:36 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29897 for ; Wed, 29 Mar 2000 22:54:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiirv25689; Thu, 30 Mar 2000 03:54:06 GMT Received: by mail-control.mail.uu.net id QQiirv21195 for mpls-outgoing; Thu, 30 Mar 2000 03:53:31 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiirv21184 for ; Thu, 30 Mar 2000 03:53:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiirv24484 for ; Wed, 29 Mar 2000 22:53:07 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiirv24820 for ; Thu, 30 Mar 2000 03:52:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA22848 for mpls@uu.net; Wed, 29 Mar 2000 22:52:56 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiirv21127 for ; Thu, 30 Mar 2000 03:52:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiirv24437 for ; Wed, 29 Mar 2000 22:52:10 -0500 (EST) Received: from mail.iagu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns.iagu.net [203.32.153.69]) id QQiirv24416 for ; Thu, 30 Mar 2000 03:52:08 GMT Received: from dhcp-192-155.ietf.connect.com.au [169.208.192.155] by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id NAA10980 return ; Thu, 30 Mar 2000 13:21:51 +0930 (CST) Message-Id: <4.2.2.20000329224708.025c07e0@alpo.casc.com> X-Sender: amalis@alpo.casc.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 29 Mar 2000 22:51:46 -0500 To: Vijay Srinivasan From: "Andrew G. Malis" Subject: Re: yet another revision of the charter Cc: "'mpls@uu.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8104924==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_8104924==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Vijay, I'm probably being pedantic, but in points 6 and 9, the word "MPLS" should be inserted to make the charter goals clear. So they should read: 6. Specify extensions to the MPLS protocols and procedures for signaling and recovery to support time-division, wavelength and spatial switching. 9. Specify standard MPLS protocols and procedures to support operations, administration, and maintenance facilities. Thanks much, Andy ------- At 09:06 PM 3/28/00 -0800, Vijay Srinivasan wrote: >6. Specify extensions to the protocols and procedures for >signaling and recovery to support time-division, wavelength and >spatial switching. > >9. Specify standard protocols and procedures to support operations, >administration, and maintenance facilities. --=====================_8104924==_.ALT Content-Type: text/html; charset="us-ascii" Vijay,

I'm probably being pedantic, but in points 6 and 9, the word "MPLS" should be inserted to make the charter goals clear.  So they should read:

6.  Specify extensions to the MPLS protocols and procedures for signaling and recovery to support time-division, wavelength and spatial switching.

9.  Specify standard MPLS protocols and procedures to support operations, administration, and maintenance facilities.

Thanks much,
Andy

-------

At 09:06 PM 3/28/00 -0800, Vijay Srinivasan wrote:

6.  Specify extensions to the protocols and procedures for
signaling and recovery to support time-division, wavelength and
spatial switching.

9.  Specify standard protocols and procedures to support operations,
administration, and maintenance facilities.
--=====================_8104924==_.ALT-- From owner-mpls@UU.NET Thu Mar 30 00:43:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01676 for ; Thu, 30 Mar 2000 00:43:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiisc21449; Thu, 30 Mar 2000 05:42:31 GMT Received: by mail-control.mail.uu.net id QQiisc16732 for mpls-outgoing; Thu, 30 Mar 2000 05:42:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiisc16717 for ; Thu, 30 Mar 2000 05:42:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiisc17087 for ; Thu, 30 Mar 2000 00:41:59 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQiisc21077 for ; Thu, 30 Mar 2000 05:41:40 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id LAA27371; Thu, 30 Mar 2000 11:07:01 -0600 (GMT) Message-ID: <00aa01bf9a0b$20ad2880$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: "Yoshihiro Ohba" Cc: References: <003701bf9941$d53afcc0$100d85a5@dti.daewoo.co.kr> <200003291519.AAA26837@toshiba.co.jp> Subject: Re: CR-LDP Date: Thu, 30 Mar 2000 11:15:15 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Yoshihiro Plz see my comments inline. > Santosh, > > > Who is supposed to be the "Downstream" peer is decided by the global (or, > > supra-local) entity which has the knowledge of all the LSPs and the topology > > of the network. > > Okay. In such an assumption, an opaque FEC can be used, however..., > > > An Opaque FEC has to be used for CR-LSP(sec 4.10 in > > draft-ietf-mpls-cr-ldp-03) since this feature is there only in CR-LDP and to > > setup a CR-LSP it is compulsory. > > section 4.10 of the CR-LDP draft does not preclude the use of other > FECs elements (Type=0x01, 0x02, 0x03) in CR-LDP messages. > > > One more issue that crops up at this point is that how is this type of LSP > > to be setup. The initial scenario that we discussed was > > > > LER1 ------> LSR2-------->LSR3------>LSR4 > > LER2--------> LSR5 > > > Now suppose the scenario were like > > > LER1 ------> LSR2-------->LSR3------>LSR4------>LSR6 > > LER2--------> LSR5------->LSR7 > > > and LSR7 was supposed to connect to LSR4. How is the new LSP to be setup? > > The global (or, supra-local) entity will inform only LER2 which will be > > sending message to LSR5 which would in turn send the request to LSR7. Is > > there any standard draft on how this is to be handled? > > I don't think there is any standard draft proposing to distribute > LSPID information to/from the global entity. But is there a > situation where the supposed scenario is useful? This could be useful in the case when lots of traffic is meant for the same destination. If we make the traffic go thru the same LSP that would reduce load on the switch as it will have less no. of LSPs in the state information. This case is the same as "Merging" of LSPs. Santosh > > Yoshihiro Ohba > > > > Santosh Gupta > > > From owner-mpls@UU.NET Thu Mar 30 02:06:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13192 for ; Thu, 30 Mar 2000 02:06:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiisi03784; Thu, 30 Mar 2000 07:06:33 GMT Received: by mail-control.mail.uu.net id QQiisi10008 for mpls-outgoing; Thu, 30 Mar 2000 07:06:12 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiisi09961 for ; Thu, 30 Mar 2000 07:06:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiisi24176 for ; Thu, 30 Mar 2000 02:06:02 -0500 (EST) Received: from mail.rdc1.sfba.home.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ha1.rdc1.sfba.home.com [24.0.0.66]) id QQiisi03439 for ; Thu, 30 Mar 2000 07:06:02 GMT Received: from home.net ([24.5.203.21]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000330070558.DYCL13305.mail.rdc1.sfba.home.com@home.net>; Wed, 29 Mar 2000 23:05:58 -0800 Message-ID: <38E2FCD5.263ECE5E@home.net> Date: Wed, 29 Mar 2000 23:05:57 -0800 From: Tony Li Organization: Li Consulting X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ashwood-Smith CC: MPLS mailing list , Bilel Jamoussi Subject: Re: MPLS routing accross AS boundaries References: <03E3E0690542D211A1490000F80836F4029F9781@zcard00f.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > All of it is correct and you are perfectly right that it is possible > to do local constraint based routing between AS's but not over the AS. > This is called stepwise or piecewise constraint based routing as > opposed to hierarchical constraint based routing which requires that > summarized constraint information cross AS boundaries. > > My own opinion, for what it is worth, is that we will probably have to > start with piecewise routing since this is relatively easy to do. > Then we can look at ways to make better gateway decisions based on > constraints, possibly with more elaborate forms of inter AS feedback. > We will have far more success getting something working reasonably > well if we keep the solution simple and start with stepwise. > > My guess is the BGP guys will like this idea and the PNNI guys will > prefer full hierarchy. Like I said though some simulations are > probably in order here to help put things properly in perspective. This BGP guy will simply point out that BGP does not and cannot reasonably propagate anything like the number of possible paths necessary to perform any reasonable type of inter-domain traffic engineering, stepwise or global. This is simply due to the path-vector nature of the protocol. We should be directing our efforts to the locations that will maximize our return: - continued experience with intra-domain TE - expansion of this technology into the optical plane Regards, Tony From owner-mpls@UU.NET Thu Mar 30 03:51:56 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14333 for ; Thu, 30 Mar 2000 03:51:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiisp26304; Thu, 30 Mar 2000 08:51:43 GMT Received: by mail-control.mail.uu.net id QQiisp27291 for mpls-outgoing; Thu, 30 Mar 2000 08:51:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiisp27277 for ; Thu, 30 Mar 2000 08:51:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiisp20722 for ; Thu, 30 Mar 2000 03:50:55 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiisp25366 for ; Thu, 30 Mar 2000 08:50:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA09383 for mpls@uu.net; Thu, 30 Mar 2000 03:50:49 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiisp27133 for ; Thu, 30 Mar 2000 08:50:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiisp03197 for ; Thu, 30 Mar 2000 03:50:10 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQiisp24908 for ; Thu, 30 Mar 2000 08:50:09 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id LAA27105; Thu, 30 Mar 2000 11:50:06 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14563.5438.414273.201116@lohi.eng.telia.fi> Date: Thu, 30 Mar 2000 11:50:06 +0300 (EEST) To: Arun Viswanathan Cc: "'mpls@UU.NET'" Subject: RE: tspec table In-Reply-To: <0F8929E5ED5FD311B892005004CED4A6346862@tonga.ncorenetworks.com> References: <0F8929E5ED5FD311B892005004CED4A6346862@tonga.ncorenetworks.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit arun, if you want to keep the tspec table, then atleast make its name rsvp independent. call it traffic parameter table or something like that. -- juha From owner-mpls@UU.NET Thu Mar 30 04:05:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14499 for ; Thu, 30 Mar 2000 04:05:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiisq03956; Thu, 30 Mar 2000 09:04:56 GMT Received: by mail-control.mail.uu.net id QQiisq06274 for mpls-outgoing; Thu, 30 Mar 2000 09:04:33 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiisq06251 for ; Thu, 30 Mar 2000 09:04:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiisq04866 for ; Thu, 30 Mar 2000 04:04:09 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiisq03454 for ; Thu, 30 Mar 2000 09:04:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA10270 for mpls@uu.net; Thu, 30 Mar 2000 04:04:08 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiisq06140 for ; Thu, 30 Mar 2000 09:03:40 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiisq04682 for ; Thu, 30 Mar 2000 04:02:02 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQiisq02222 for ; Thu, 30 Mar 2000 09:02:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Mar 30 04:00:25 EST 2000 Received: from lucent.com (ex-vpn64.pa.bell-labs.com [135.250.1.64]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id EAA06574; Thu, 30 Mar 2000 04:00:15 -0500 (EST) Message-ID: <38E3184E.A254D404@lucent.com> Date: Thu, 30 Mar 2000 01:03:10 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Arun Viswanathan CC: Juha Heinanen , "'mpls@UU.NET'" Subject: Re: tspec table References: <0F8929E5ED5FD311B892005004CED4A6346862@tonga.ncorenetworks.com> <14563.5438.414273.201116@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit juha's suggestion sounds reasonable. gja Juha Heinanen wrote: > > arun, > > if you want to keep the tspec table, then atleast make its name rsvp > independent. call it traffic parameter table or something like that. > > -- juha -- ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Thu Mar 30 05:59:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15335 for ; Thu, 30 Mar 2000 05:59:16 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiisx29474; Thu, 30 Mar 2000 10:59:02 GMT Received: by mail-control.mail.uu.net id QQiisx24538 for mpls-outgoing; Thu, 30 Mar 2000 10:58:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiisx24529 for ; Thu, 30 Mar 2000 10:58:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiisx13912 for ; Thu, 30 Mar 2000 05:58:14 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQiisx29007 for ; Thu, 30 Mar 2000 10:58:14 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Thu, 30 Mar 2000 05:55:43 -0500 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H70BG7XX; Thu, 30 Mar 2000 05:55:39 -0500 Received: from americasm01.nt.com (BBS [47.182.199.12]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H8W6R15C; Thu, 30 Mar 2000 05:55:38 -0500 Message-ID: <38E3322F.CBB643B8@americasm01.nt.com> Date: Thu, 30 Mar 2000 05:53:35 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (Win95; I) X-Accept-Language: en MIME-Version: 1.0 CC: Arun Viswanathan , "'mpls@UU.NET'" Subject: Re: tspec table References: <0F8929E5ED5FD311B892005004CED4A6346862@tonga.ncorenetworks.com> <14563.5438.414273.201116@lohi.eng.telia.fi> <38E3184E.A254D404@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Juha's suggestion sounds reasonable to me too. - Philip Grenville Armitage wrote: > > juha's suggestion sounds reasonable. > > gja > > Juha Heinanen wrote: > > > > arun, > > > > if you want to keep the tspec table, then atleast make its name rsvp > > independent. call it traffic parameter table or something like that. > > > > -- juha From owner-mpls@UU.NET Thu Mar 30 10:01:17 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16917 for ; Thu, 30 Mar 2000 10:01:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiito15419; Thu, 30 Mar 2000 15:01:00 GMT Received: by mail-control.mail.uu.net id QQiito15594 for mpls-outgoing; Thu, 30 Mar 2000 15:00:41 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiito15574 for ; Thu, 30 Mar 2000 15:00:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiito00692 for ; Thu, 30 Mar 2000 10:00:35 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiito14931 for ; Thu, 30 Mar 2000 15:00:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA03310 for mpls@uu.net; Thu, 30 Mar 2000 10:00:33 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiitn14712 for ; Thu, 30 Mar 2000 14:59:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiitn11916 for ; Thu, 30 Mar 2000 09:59:33 -0500 (EST) Received: from farley.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: farley.cisco.com [171.71.153.30]) id QQiitn14199 for ; Thu, 30 Mar 2000 14:59:32 GMT Received: from cisco.com (apraveen-dsl1.cisco.com [10.19.35.170]) by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA28297 for ; Thu, 30 Mar 2000 06:59:31 -0800 (PST) Message-ID: <38E36C37.6748E1D0@cisco.com> Date: Thu, 30 Mar 2000 07:01:11 -0800 From: Praveen Athmanath Reply-To: apraveen@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Unsubscribe. From owner-mpls@UU.NET Thu Mar 30 11:06:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17397 for ; Thu, 30 Mar 2000 11:06:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiits00174; Thu, 30 Mar 2000 16:05:44 GMT Received: by mail-control.mail.uu.net id QQiits01593 for mpls-outgoing; Thu, 30 Mar 2000 16:05:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiits01411 for ; Thu, 30 Mar 2000 16:05:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiits23803 for ; Thu, 30 Mar 2000 11:05:01 -0500 (EST) Received: from hercules by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQiits00071 for ; Thu, 30 Mar 2000 16:05:01 GMT Received: from tonga.ncorenetworks.com by hercules (SMI-8.6/ncore-main9-99) id IAA05558; Thu, 30 Mar 2000 08:04:57 -0800 Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Mar 2000 08:04:57 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A6346865@tonga.ncorenetworks.com> From: Arun Viswanathan To: "'Juha Heinanen'" , "'Arun Viswanathan'" Cc: "'mpls@UU.NET'" Subject: RE: tspec table Date: Thu, 30 Mar 2000 08:04:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Will do so. -arun > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juha > Heinanen > Sent: Thursday, March 30, 2000 12:50 AM > To: Arun Viswanathan > Cc: 'mpls@UU.NET' > Subject: RE: tspec table > > > arun, > > if you want to keep the tspec table, then atleast make its name rsvp > independent. call it traffic parameter table or something like that. > > -- juha > > > From owner-mpls@UU.NET Thu Mar 30 12:18:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18143 for ; Thu, 30 Mar 2000 12:18:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiitx18788; Thu, 30 Mar 2000 17:18:13 GMT Received: by mail-control.mail.uu.net id QQiitx17799 for mpls-outgoing; Thu, 30 Mar 2000 17:17:55 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiitx17782 for ; Thu, 30 Mar 2000 17:17:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiitx06295 for ; Thu, 30 Mar 2000 12:17:42 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiitx17509 for ; Thu, 30 Mar 2000 17:17:42 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id MAA13605; Thu, 30 Mar 2000 12:17:40 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id MAA57195; Thu, 30 Mar 2000 12:18:02 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200003301718.MAA57195@curtis-lt.avici.com> To: David Charlap cc: MPLS mailing list Reply-To: curtis@avici.com Subject: Re: MPLS routing accross AS boundaries In-reply-to: Your message of "Wed, 29 Mar 2000 17:58:05 EST." <38E28A7D.134BD731@fore.com> Date: Thu, 30 Mar 2000 12:18:02 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <38E28A7D.134BD731@fore.com>, David Charlap writes: > "Abes, Andi" wrote: > > > > Now my question is, why can't this model be followed under traffic > > engineering conditions ? > > > > Router Ax will learn from BGP what is the local AS egress point > > towards D. It will then consult the IGP-TE database and construct an > > explicit route to that router, and tuck at the end a loose route to D. > > It is then the egress router's job to "fix" the explicit route such > > that the ERO now reflects the route to the next AS. The Ingress router > > in transit AS's will do just the same - it will change the ERO (that > > now contains 2 entries - one that indicates the current AS, and one > > for the end destination) such that it contains a strict route accross > > the new current AS and a loose route to the destination. and so on > > till the destination AS. > > Actually, you should be able to do better than this (if RSVP-TE is used, > anyway. I don't know about CR-LDP) > > According to draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, the explicit route > object supports an AS-number subobject. > > So, the ingress router should be able to get (from BGP) an explicit > route of AS numbers from source to destination. It can make an ERO that > begins with the hops through the local net, and ends with the list of AS > numbers for ASes beyond the local network. > > Upon arrival in the next AS, the router there can replace the > AS-subobject for itself with a per-hop route to the next AS on the list. > > And so on. > > So the ingress router can't specify the complete path, but it can > specify which ASes it wants the path to go through on its way to the > destination AS. > > > Each BGP router can consult what ever TE constraits it has to deceid > > what BGP next hop to use, but it will only construct a strict route > > through the local AS and append a loose route to the final > > destination. > > It could do this also. > > A loose route from the last local router to the final destination could > work, but that means the actual path chosen is left completely up to the > routers in other ASes. > > A route that explicitly lists ASes may be better. There is still some > looseness, since each AS will determine its own route through, but you > can keep the route going through the ASes you want. > > The first way would definitely be easier to implement, but the second > way might also be desirable under certain circumstances. > > -- David This would work on a smaller scale such as a single provider. AFAIK none of the current implementations from major router vendors support AS in the ERO mostly because no one actually building an ISP backbone wants it. End to end LSPs across AS boundaries just isn't going to happen. Each ingress might have to originate 10,000s of LSPs. In the core there could potentially be 70,000 * 70,000 LSPs. Even with these LSPs inside of aggregated traffic engineered LSPs and backbone LSRs that could handle that amount of state, the 20 bit label number space could be exceeded. End-to-end LSPs is true connection oriented QoS routing which doesn't work. It isn't what MPLS was designed for and for good reason. End-to-end QoS across providers is still acheivable but the solution won't involve end-to-end LSPs. Curtis From owner-mpls@UU.NET Thu Mar 30 13:06:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18953 for ; Thu, 30 Mar 2000 13:06:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiua18845; Thu, 30 Mar 2000 18:06:07 GMT Received: by mail-control.mail.uu.net id QQiiua28192 for mpls-outgoing; Thu, 30 Mar 2000 18:05:47 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiiua28187 for ; Thu, 30 Mar 2000 18:05:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiua03660 for ; Thu, 30 Mar 2000 13:05:20 -0500 (EST) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiiua18267 for ; Thu, 30 Mar 2000 18:05:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA08552; Thu, 30 Mar 2000 10:05:08 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA14997; Thu, 30 Mar 2000 13:05:05 -0500 (EST) Message-Id: <200003301805.NAA14997@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Juha Heinanen cc: "Thomas D. Nadeau" , mpls@UU.NET, Arun Viswanathan , cheenu@tachion.com Subject: Re: tspec table In-reply-to: Your message of Tue, 28 Mar 2000 08:41:54 +0300. <14560.17954.729658.34134@lohi.eng.telia.fi> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Mar 2000 13:05:05 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Juha> according to the terminology section of the architecture i-d, mpls Juha> node is a node that is dealing with labeled packets and can POSSIBLY Juha> also forward l3 packets, whereas lsr is an mpls node that also does Juha> forward l3 packets. I think that's a bug in the terminology section, since that is not the usage that is followed in the rest of the document. From owner-mpls@UU.NET Thu Mar 30 16:58:52 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22119 for ; Thu, 30 Mar 2000 16:58:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiup22510; Thu, 30 Mar 2000 21:58:40 GMT Received: by mail-control.mail.uu.net id QQiiup06866 for mpls-outgoing; Thu, 30 Mar 2000 21:58:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiup06860 for ; Thu, 30 Mar 2000 21:58:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiup24764 for ; Thu, 30 Mar 2000 16:57:57 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiiup27229 for ; Thu, 30 Mar 2000 21:57:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA09274 for mpls@uu.net; Thu, 30 Mar 2000 16:57:52 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiiup06843 for ; Thu, 30 Mar 2000 21:57:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiup17221 for ; Thu, 30 Mar 2000 16:57:17 -0500 (EST) Received: from hubbub.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hubbub.cisco.com [171.69.11.2]) id QQiiup26918 for ; Thu, 30 Mar 2000 21:57:17 GMT Received: from ORANLT (ssh.cisco.com [171.69.10.34]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id NAA25774; Thu, 30 Mar 2000 13:56:33 -0800 (PST) From: "David Oran" To: "Vijay Srinivasan" , "'mpls@uu.net'" Subject: RE: yet another revision of the charter Date: Thu, 30 Mar 2000 16:56:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit A couple of queries about the new iems: > Hi folks, > Here is another revision of the charter, based upon discussion at > today's WG meeting. I have added the following objectives: > -- > 11. Specify standard protocols and procedures to enable header > compression > across a single link as well as across an LSP. > 12. Specify appropriate extensions to LDP and RSVP for authentication > of LSP originators. In the case of RSVP, what, precisely, is missing? RSVP already has both integrity objects for hop-by-hop authentication, and policy data objects themselves containing integrity objects, for end-to-end authentication. > 13. Define requirements and standard protocols and procedures for policy > support in MPLS-based networks. This work will be complementary to, and > will build upon, other policy-related work ongoing in the IETF. This strikes me as both too nebulous and open-ended. What, precisely is being proposed? > -- > We did not discuss milestones for the policy and authentication > work. Your input on these would be appreciated. > Regards, > - Chairs From owner-mpls@UU.NET Thu Mar 30 18:01:55 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23107 for ; Thu, 30 Mar 2000 18:01:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiuu01693; Thu, 30 Mar 2000 23:01:45 GMT Received: by mail-control.mail.uu.net id QQiiuu22720 for mpls-outgoing; Thu, 30 Mar 2000 23:01:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiuu22654 for ; Thu, 30 Mar 2000 23:01:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiuu04237 for ; Thu, 30 Mar 2000 18:00:59 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiiuu01040 for ; Thu, 30 Mar 2000 23:00:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA17364 for mpls@uu.net; Thu, 30 Mar 2000 18:00:53 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiiuu20229 for ; Thu, 30 Mar 2000 23:00:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiuu27373 for ; Thu, 30 Mar 2000 18:00:18 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQiiuu05727 for ; Thu, 30 Mar 2000 23:00:18 GMT Received: from tnadeau-pc02 (ch-janeiro-p43.cisco.com [171.69.209.247]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA29756; Thu, 30 Mar 2000 17:59:37 -0500 (EST) Message-Id: <4.2.2.20000330174918.0709e6b0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 30 Mar 2000 17:49:41 -0500 To: Arun Viswanathan , "'Juha Heinanen'" , "'Arun Viswanathan'" From: "Thomas D. Nadeau" Subject: RE: tspec table Cc: "'mpls@UU.NET'" In-Reply-To: <0F8929E5ED5FD311B892005004CED4A6346865@tonga.ncorenetworks .com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2883402==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_2883402==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Just to clarify, we will call the table mplsTrafficParamTable. --Tom > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juha > > Heinanen > > Sent: Thursday, March 30, 2000 12:50 AM > > To: Arun Viswanathan > > Cc: 'mpls@UU.NET' > > Subject: RE: tspec table > > > > > > arun, > > > > if you want to keep the tspec table, then atleast make its name rsvp > > independent. call it traffic parameter table or something like that. > > > > -- juha > > > > > > --=====================_2883402==_.ALT Content-Type: text/html; charset="us-ascii"
        Just to clarify, we will call the table
mplsTrafficParamTable.

        --Tom


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juha
> Heinanen
> Sent: Thursday, March 30, 2000 12:50 AM
> To: Arun Viswanathan
> Cc: 'mpls@UU.NET'
> Subject: RE: tspec table
>
>
> arun,
>
> if you want to keep the tspec table, then atleast make its name rsvp
> independent.   call it traffic parameter table or something like that.
>
> -- juha
>
>
>
--=====================_2883402==_.ALT-- From owner-mpls@UU.NET Thu Mar 30 18:52:45 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23563 for ; Thu, 30 Mar 2000 18:52:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiux01242; Thu, 30 Mar 2000 23:52:29 GMT Received: by mail-control.mail.uu.net id QQiiux28926 for mpls-outgoing; Thu, 30 Mar 2000 23:51:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiiux28921 for ; Thu, 30 Mar 2000 23:51:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiux03419 for ; Thu, 30 Mar 2000 18:51:27 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiiux00201 for ; Thu, 30 Mar 2000 23:51:26 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA22536 for mpls@uu.net; Thu, 30 Mar 2000 18:51:26 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiiux28892 for ; Thu, 30 Mar 2000 23:51:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiux03395 for ; Thu, 30 Mar 2000 18:51:08 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQiiux00028 for ; Thu, 30 Mar 2000 23:51:07 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id CAA28388; Fri, 31 Mar 2000 02:50:54 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14563.59486.559021.975672@lohi.eng.telia.fi> Date: Fri, 31 Mar 2000 02:50:54 +0300 (EEST) To: erosen@cisco.com Cc: "Thomas D. Nadeau" , mpls@UU.NET, Arun Viswanathan , cheenu@tachion.com Subject: Re: tspec table In-Reply-To: <200003301805.NAA14997@erosen-sun.cisco.com> References: <14560.17954.729658.34134@lohi.eng.telia.fi> <200003301805.NAA14997@erosen-sun.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Rosen writes: > > Juha> according to the terminology section of the architecture i-d, mpls > Juha> node is a node that is dealing with labeled packets and can POSSIBLY > Juha> also forward l3 packets, whereas lsr is an mpls node that also does > Juha> forward l3 packets. > > I think that's a bug in the terminology section, since that is not the usage > that is followed in the rest of the document. if so, tell me then what is the difference between an mpls node and lsr. -- juha From owner-mpls@UU.NET Fri Mar 31 06:38:10 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12749 for ; Fri, 31 Mar 2000 06:38:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiws01504; Fri, 31 Mar 2000 11:37:52 GMT Received: by mail-control.mail.uu.net id QQiiws09469 for mpls-outgoing; Fri, 31 Mar 2000 11:37:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiws09464 for ; Fri, 31 Mar 2000 11:37:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiiws11290 for ; Fri, 31 Mar 2000 06:36:43 -0500 (EST) Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: daewoo.dti.daewoo.co.kr [165.133.13.60]) id QQiiws00718 for ; Fri, 31 Mar 2000 11:36:27 GMT Received: from daewoo (santosh [165.133.13.16]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id RAA14545 for ; Fri, 31 Mar 2000 17:02:53 -0600 (GMT) Message-ID: <012b01bf9b05$f8b645e0$100d85a5@dti.daewoo.co.kr> Reply-To: "Santosh Gupta" From: "Santosh Gupta" To: Subject: LSPID in CR-LDP Date: Fri, 31 Mar 2000 17:10:50 +0530 Organization: Daewoo Telecom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0128_01BF9B34.10DD3380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0128_01BF9B34.10DD3380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi The LSPID TLV in section 4.5 of draft-ietf-mpls-cr-ldp-03 has given = Ingress LSR Router ID as 4 bytes only. Does that mean there is no = support for IPv6 IP addresses ?=20 santosh --------------------------------------------------------------- Santosh Gupta Daewoo Telecom=20 santoshgupta@poboxes.com ------=_NextPart_000_0128_01BF9B34.10DD3380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
    The LSPID TLV in section 4.5 of=20 draft-ietf-mpls-cr-ldp-03 has given Ingress LSR Router ID as 4 bytes = only. Does=20 that mean there is no support for IPv6 IP addresses ?

santosh
 
---------------------------------------------------------------
S= antosh=20 Gupta
Daewoo Telecom
santoshgupta@poboxes.com ------=_NextPart_000_0128_01BF9B34.10DD3380-- From owner-mpls@UU.NET Fri Mar 31 07:19:09 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13029 for ; Fri, 31 Mar 2000 07:19:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiiwv23887; Fri, 31 Mar 2000 12:18:56 GMT Received: by mail-control.mail.uu.net id QQiiwv20222 for mpls-outgoing; Fri, 31 Mar 2000 12:18:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiiwv20209 for ; Fri, 31 Mar 2000 12:18:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiwv14512 for ; Fri, 31 Mar 2000 07:17:51 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiiwv27498 for ; Fri, 31 Mar 2000 12:17:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA29931 for mpls@uu.net; Fri, 31 Mar 2000 07:17:06 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiiwv20078 for ; Fri, 31 Mar 2000 12:16:36 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiiwv14456 for ; Fri, 31 Mar 2000 07:16:34 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQiiwv27186 for ; Fri, 31 Mar 2000 12:16:33 GMT Received: from tnadeau-pc02 (ch-janeiro-p25.cisco.com [171.69.209.229]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA04932; Fri, 31 Mar 2000 07:14:56 -0500 (EST) Message-Id: <4.2.2.20000331070443.03d4faf0@funnel.cisco.com> X-Sender: tnadeau@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 31 Mar 2000 07:05:07 -0500 To: Juha Heinanen , erosen@cisco.com From: "Thomas D. Nadeau" Subject: Re: tspec table Cc: mpls@UU.NET, Arun Viswanathan , cheenu@tachion.com In-Reply-To: <14563.59486.559021.975672@lohi.eng.telia.fi> References: <200003301805.NAA14997@erosen-sun.cisco.com> <14560.17954.729658.34134@lohi.eng.telia.fi> <200003301805.NAA14997@erosen-sun.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2162385==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_2162385==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Juha, I believe that they are one in the same. --Tom >if so, tell me then what is the difference between an mpls node and >lsr. > >-- juha --=====================_2162385==_.ALT Content-Type: text/html; charset="us-ascii"
        Juha,

        I believe that they are one in the same.

        --Tom

if so, tell me then what is the difference between an mpls node and
lsr.   

-- juha
--=====================_2162385==_.ALT-- From owner-mpls@UU.NET Fri Mar 31 09:13:33 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13802 for ; Fri, 31 Mar 2000 09:13:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiixc02464; Fri, 31 Mar 2000 14:13:16 GMT Received: by mail-control.mail.uu.net id QQiixc12908 for mpls-outgoing; Fri, 31 Mar 2000 14:12:44 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiixc12903 for ; Fri, 31 Mar 2000 14:12:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiixc20434 for ; Fri, 31 Mar 2000 09:12:27 -0500 (EST) Received: from alpha.dtix.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.dtix.com [198.62.174.1]) id QQiixc01575 for ; Fri, 31 Mar 2000 14:12:26 GMT Received: from salmon (beta.dtix.com [198.62.174.3]) by alpha.dtix.com (8.9.3/8.8.7) with SMTP id JAA10634; Fri, 31 Mar 2000 09:22:57 -0500 Message-ID: <011501bf9b1b$9d36f4b0$9dae3ec6@salmon> From: "Subodh Mathur" To: "Santosh Gupta" , References: <012b01bf9b05$f8b645e0$100d85a5@dti.daewoo.co.kr> Subject: Re: LSPID in CR-LDP Date: Fri, 31 Mar 2000 09:15:48 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01BF9AF1.B3E83A40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0112_01BF9AF1.B3E83A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, LSR ID has nothing to do with type of IP address being supported. It is = just an identifier used to uniquely identify an LSR. Interface Address = is a good candidate for it, hence its use as LSR ID is recommended. Subodh Mathur Digital Technology Inc., Bedford, MA 01730 ----- Original Message -----=20 From: Santosh Gupta=20 To: mpls@UU.NET=20 Sent: Friday, March 31, 2000 6:40 AM Subject: LSPID in CR-LDP Hi The LSPID TLV in section 4.5 of draft-ietf-mpls-cr-ldp-03 has = given Ingress LSR Router ID as 4 bytes only. Does that mean there is no = support for IPv6 IP addresses ?=20 santosh --------------------------------------------------------------- Santosh Gupta Daewoo Telecom=20 santoshgupta@poboxes.com ------=_NextPart_000_0112_01BF9AF1.B3E83A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
LSR ID has nothing to do with type of = IP address=20 being supported. It is just an identifier used to uniquely identify = an LSR.=20 Interface Address is a good candidate for it, hence its use as LSR=20 ID
is recommended.
 
Subodh Mathur
Digital Technology=20 Inc.,
Bedford, MA 01730
----- Original Message -----
From:=20 Santosh Gupta
Sent: Friday, March 31, 2000 = 6:40=20 AM
Subject: LSPID in CR-LDP

Hi
    The LSPID TLV in section 4.5 of=20 draft-ietf-mpls-cr-ldp-03 has given Ingress LSR Router ID as 4 bytes = only.=20 Does that mean there is no support for IPv6 IP addresses ?

santosh
 
=
---------------------------------------------------------------
S= antosh=20 Gupta
Daewoo Telecom
santoshgupta@poboxes.com ------=_NextPart_000_0112_01BF9AF1.B3E83A40-- From owner-mpls@UU.NET Fri Mar 31 09:42:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14141 for ; Fri, 31 Mar 2000 09:42:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiixe21899; Fri, 31 Mar 2000 14:41:59 GMT Received: by mail-control.mail.uu.net id QQiixe14514 for mpls-outgoing; Fri, 31 Mar 2000 14:41:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiixe14509 for ; Fri, 31 Mar 2000 14:41:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiixe25112 for ; Fri, 31 Mar 2000 09:41:12 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiixe21157 for ; Fri, 31 Mar 2000 14:41:12 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA11780 for mpls@uu.net; Fri, 31 Mar 2000 09:41:11 -0500 (EST) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiixe14397 for ; Fri, 31 Mar 2000 14:40:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiixe24959 for ; Fri, 31 Mar 2000 09:40:34 -0500 (EST) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQiixe19901 for ; Fri, 31 Mar 2000 14:40:34 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA18709; Fri, 31 Mar 2000 06:39:27 -0800 (PST) Message-Id: <200003311439.GAA18709@omega.cisco.com> To: curtis@avici.com cc: "James V. Luciani" , "Yakov Rekhter" , "Krishna Bala" , "Jagan Shantigram" , "Jonathan Lang" , "Khaled Elsayed" , mpls@UU.NET, ip-optical@lists.research.bell-labs.com Subject: Re: Comments on draft-ip-optical-framework-00.txt In-reply-to: Your message of "Wed, 29 Mar 2000 12:42:33 EST." <200003291742.MAA56136@curtis-lt.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18706.954513566.1@cisco.com> Date: Fri, 31 Mar 2000 06:39:27 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Curtis, > > Wow, such rapier-like wit and technical depth all wrapped in a > > one-liner. Now if you would like to help clarify the issue rather than > > snipe at someone who is trying to be helpful, I for one would like to hear > > your input. > > --Jim > > Jim, > > Maybe Yakov just didn't like the suggested term "augmented routing > model". I certainly didn't. Yes, that was my point. > I suggested that we make the distinction between "static overlay" and > "signaled overlay". What you describe as X would be signaled overlay. Agreed. > Curtis > > btw- NHRP and MPOA might be bad examples. just brain-damaged.... Yakov. > > > > ----- Original Message ----- > > From: Yakov Rekhter > > To: James V. Luciani > > Cc: Krishna Bala ; Jagan Shantigram ; > > Jonathan Lang ; ; Khaled Elsaye d > > ; ; > > Sent: Monday, March 27, 2000 7:31 PM > > Subject: Re: Comments on draft-ip-optical-framework-00.txt > > > > > > > Jim, > > > > > > > > Just to beat a dead horse .. the difference between the open model > > > > > and the overlay is just that the overlay model typically suggests tha t > > > > > > > > That depends... see below. > > > > > > > > > there would be N^2 connectivity (i.e., every router, for instance, is > > > > > statically connected to every other). In any case, the open model > > allows > > > > > > > > While there may indeed be some misunderstanding as to the meaning of th e > > > > "overlay model" (not to mention the meaning of the other models :-)), > > the > > > > traditional definition of overlay is not one of static operation. NHRP > > and > > > > MPOA, for example, are overlay in my book (and most folks that I know). > > > > > > > > They most certainly imply non-static connections by defintion (i.e., us e > > of > > > > SVCs). This having been said, I believe that we can do one of two > > things > > > > here. One, keep the current terms and potentially risk an ad nauseum > > > > inspection of the meaning of these terms; or two, come up with a term > > which > > > > is satisfactory to all. In the second case we would have models: > > > > 1) X > > > > 2) Peer > > > > where X is the PC term for what we want to get at. So my opine is that > > > > X="augmented routing model"/ARM model. > > > > > > > > Do I hear a hmmmm??? > > > > > > I think you do. And it comes from you - it is your own hmmm. > > > > > > Yakov. > > > > > From owner-mpls@UU.NET Fri Mar 31 09:55:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14251 for ; Fri, 31 Mar 2000 09:55:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiixf01846; Fri, 31 Mar 2000 14:55:06 GMT Received: by mail-control.mail.uu.net id QQiixf15181 for mpls-outgoing; Fri, 31 Mar 2000 14:54:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiixf15172 for ; Fri, 31 Mar 2000 14:54:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiixf04515 for ; Fri, 31 Mar 2000 09:54:19 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQiixf01057 for ; Fri, 31 Mar 2000 14:54:17 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id GAA29132 for ; Fri, 31 Mar 2000 06:53:44 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA18038 for mpls@uu.net; Fri, 31 Mar 2000 09:51:57 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiivf20393 for ; Fri, 31 Mar 2000 01:45:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiivf20784 for ; Thu, 30 Mar 2000 20:45:32 -0500 (EST) Received: from smtp1-gw.tp1rc.edu.tw by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1-gw.tp1rc.edu.tw [163.28.16.23]) id QQiivf05507 for ; Fri, 31 Mar 2000 01:45:27 GMT Received: from ms.cc.ntu.edu.tw (ms.cc.ntu.edu.tw [140.112.8.200]) by smtp1-gw.tp1rc.edu.tw (8.9.3/8.9.3) with ESMTP id JAA96289 for ; Fri, 31 Mar 2000 09:41:17 +0800 (CST) (envelope-from d6942004@ms.cc.ntu.edu.tw) Received: from ms.cc.ntu.edu.tw (dino.ee.ntu.edu.tw [140.112.19.252]) by ms.cc.ntu.edu.tw (8.9.1/8.9.1) with ESMTP id JAA04189 for ; Fri, 31 Mar 2000 09:45:15 +0800 (CST) Message-ID: <38E40561.92FE8871@ms.cc.ntu.edu.tw> Date: Fri, 31 Mar 2000 09:54:41 +0800 From: d6942004 X-Mailer: Mozilla 4.5 [zhtw]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: difference between LSP and LSP tunnel? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi, Can somebody tell me the differences between LSP and LSP tunnel? I see the definition in "draft-ietf-mpls-arch-0.6txt". 1. LSP tunnel example: 3.27.4. Hierarchy: LSP Tunnels within LSPs Consider a LSP . Let us suppose that R1 receives unlabeled packet P, and pushes on its label stack the label to cause it to follow this path, and that this is in fact the Hop-by-hop path. However, let us further suppose that R2 and R3 are not directly connected, but are "neighbors" by virtue of being the endpoints of an LSP tunnel. So the actual sequence of LSRs traversed by P is . When P travels from R1 to R2, it will have a label stack of depth 1. R2, switching on the label, determines that P must enter the tunnel. R2 first replaces the Incoming label with a label that is meaningful to R3. Then it pushes on a new label. This level 2 label has a value which is meaningful to R21. Switching is done on the level 2 label by R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel, pops the label stack before forwarding the packet to R3. When R3 sees packet P, P has only a level 1 label, having now exited the tunnel. Since R3 is the penultimate hop in P's level 1 LSP, it pops the label stack, and R4 receives P unlabeled. but from the LSP definition In other words, we can speak of the level m LSP for Packet P as the sequence of routers: 1. which begins with an LSR (an "LSP Ingress") that pushes on a level m label, 2. all of whose intermediate LSRs make their forwarding decision by label Switching on a level m label, 3. which ends (at an "LSP Egress") when a forwarding decision is made by label Switching on a level m-k label, where k>0, or when a forwarding decision is made by "ordinary", non-MPLS forwarding procedures. So my questions are 1. Is a LSP? 2. Is a LSP tunnel? 3. Trsffic engineering works on LSP or LSP tunnel? Sincerely yours Ling-chih Kao From owner-mpls@UU.NET Fri Mar 31 10:01:13 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14357 for ; Fri, 31 Mar 2000 10:01:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiixg06200; Fri, 31 Mar 2000 15:01:01 GMT Received: by mail-control.mail.uu.net id QQiixg17011 for mpls-outgoing; Fri, 31 Mar 2000 15:00:38 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiixg16520 for ; Fri, 31 Mar 2000 15:00:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiixg28687 for ; Fri, 31 Mar 2000 10:00:06 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiixg05332 for ; Fri, 31 Mar 2000 15:00:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA14612 for mpls@uu.net; Fri, 31 Mar 2000 10:00:05 -0500 (EST) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiixf15400 for ; Fri, 31 Mar 2000 14:59:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiixf05388 for ; Fri, 31 Mar 2000 09:59:28 -0500 (EST) Received: from alpo.casc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: alpo.casc.com [152.148.10.6]) id QQiixf04781 for ; Fri, 31 Mar 2000 14:59:28 GMT Received: from snowman.casc.com (snowman [152.148.10.28]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id JAA19533; Fri, 31 Mar 2000 09:59:32 -0500 (EST) Received: by snowman.casc.com (8.8.8+Sun/SMI-SVR4) id JAA25898; Fri, 31 Mar 2000 09:59:32 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14564.48468.349583.336921@gargle.gargle.HOWL> Date: Fri, 31 Mar 2000 09:59:32 -0500 (EST) From: Sridhar Komandur To: mpls@UU.NET Subject: bug in draft-ietf-rsvp-lsp-tunel-04 ? X-Mailer: VM 6.75 under 19.14 XEmacs Lucid Reply-To: Sridhar Komandur Cc: skomandu@casc.com, jshaio@casc.com, amalis@casc.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Section 3.2 (page 14) currently has ::= [ ]