From owner-mpls@UU.NET Sun Apr 1 04:07:38 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03570 for ; Sun, 1 Apr 2001 04:07:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkivo27888; Sun, 1 Apr 2001 08:06:32 GMT Received: by mail-control.mail.uu.net id QQkivo11999 for mpls-outgoing; Sun, 1 Apr 2001 08:05:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkivo11964 for ; Sun, 1 Apr 2001 08:05:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkivo22381 for ; Sun, 1 Apr 2001 08:05:24 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkivo14966 for ; Sun, 1 Apr 2001 08:05:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA01063 for mpls@uu.net; Sun, 1 Apr 2001 04:05:22 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkivo11487 for ; Sun, 1 Apr 2001 08:04:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkivo09324 for ; Sun, 1 Apr 2001 08:04:33 GMT Received: from sj-msg-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQkivo11377 for ; Sun, 1 Apr 2001 08:04:32 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id AAA21391; Sun, 1 Apr 2001 00:02:41 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f3183js22856; Sun, 1 Apr 2001 00:03:47 -0800 (PST) Message-ID: <3AC6E087.7A290E46@cisco.com> Date: Sun, 01 Apr 2001 00:02:15 -0800 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: giles@goneto.net, Bora Akyol CC: neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: <3AC3A8C0.F8433A12@goneto.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Giles, > > For the user-plane, the failure modes which must be considered/defined are: > > - simple below MPLS fabric server layer connectivity breaks; > > - simple within MPLS fabric connectivity breaks (at or below the LSP > > level considered); > > Both of these will be detected by the RSVP signalling, won't they? Sure but the question is when ? Do you think that RSVP Error/Tear msgs will travel immediately - case of link failure or are you proposing to run RSVP refresh in the interval less then 1 sec - to detect the case of node failure ? The point is that this draft is not about detection, but about backup LSP setup and label allocation under the __local__ protection scheme. So let's talk on the subject here. If one questions the use of local protection all together please specify how else you will achive the same results of even less then 1 sec end to end traffic disruption with end to end protection under both link & node failures for the TE- LSP ? Bora, Which CCAMP IDs address the setup & label allocation of backup tunnels for local protection ? R. From owner-mpls@UU.NET Sun Apr 1 10:52:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29673 for ; Sun, 1 Apr 2001 10:52:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiwp17906; Sun, 1 Apr 2001 14:50:29 GMT Received: by mail-control.mail.uu.net id QQkiwp05229 for mpls-outgoing; Sun, 1 Apr 2001 14:49:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiwp05224 for ; Sun, 1 Apr 2001 14:49:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiwp00720 for ; Sun, 1 Apr 2001 14:49:21 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkiwp15853 for ; Sun, 1 Apr 2001 14:49:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA11347 for mpls@uu.net; Sun, 1 Apr 2001 10:49:19 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiwp05176 for ; Sun, 1 Apr 2001 14:48:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiwp28028 for ; Sun, 1 Apr 2001 14:48:28 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkiwp15330 for ; Sun, 1 Apr 2001 14:48:28 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA24003; Sun, 1 Apr 2001 10:47:36 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA00138; Sun, 1 Apr 2001 10:48:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20010401104317.01cd3c40@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 01 Apr 2001 10:48:48 -0500 To: Eric Gray , "Wijnen, Bert (Bert)" From: "Thomas D. Nadeau" Subject: Re: Draft MPLS minutes Cc: mpls@UU.NET, George Swallow In-Reply-To: <3AC4E0F0.8B8E0191@sandburst.com> References: <2413FED0DFE6D111B3F90008C7FA61FB0BD4F7AD@nl0006exch002u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 02:39 PM 3/30/2001 -0500, Eric Gray wrote: >Bert, > > It can be a pleasure to second guess a second guesser. :-) > >You wrote: > > > Sorry to bother you with admib/process like issues > > See inline > > > > > ---------- > > > From: George Swallow[SMTP:swallow@cisco.com] > > > Sent: Thursday, March 29, 2001 12:56 AM > > > To: mpls@UU.NET > > > Subject: Draft MPLS minutes > > > > > > > > > MPLS WG Meeting Thursday, March 22, 2001 > > > ======================================== > > > > > .. snip ... > > > > > 4. MIBs (in IESG last call) > > > > > > Definitions of Managed Objects for the Multiprotocol Label Switching, > > > Label Distribution Protocol (LDP) > > > > > > > > > MPLS Label Switch Router Management Information Base Using SMIv2 > > > > > > > > > Authors are in the process addressing comments from the IESG. > > > Another round of last calls is probably not required. > > > > > I am not so sure of that. Some serious issues have been found, and I > > think some real changes may occur. Let's see what the next rev > > of these drafts will look like first. > >Please state which drafts you think this observation applies to. > >There is no sense in holding a last call on all regenerated drafts >because there is a sense that some serious issues (may) have >been raised with respect to some drafts. Being the one fixing the aforementioned "serious issues", let me elucidate what I think those issues are. 8) a) the MIB needing a good recompile, b) some specifics on descriptions being deficient, c) a request from the IESG to take all of the TCs out of that MIB as well as from the LDP/TE MIBs, and put them into a single MPLS-TC-MIB. I am nearly finished with all of the edits required for these changes, and should be handing over the new version of the LSR MIB (and the TC MIB) to Bert on Monday or Tuesday, and will seek guidance on the TC-MIB from him at that time. I presume that these same "serious" issues and in particular, b and c, exist with the LDP MIB as well. --Tom > > ... snip .... > > > > > 7. Generalized MPLS Signaling drafts > > > > > > These drafts are nearly complete. They will be updated based on > > > the results of CCAMP. Once updated they will be sent for joint > > > CCAMP and MPLS WG last call. Consensus to do the MPLS WG last call > > > was reached in this meeting. > > > > > This point 7 does not harm I guess... But in principle, "consensus is never > > reached in a f2f meeting". Need to check for consensus on the WG > > mailing list. But I guess this could be reworded to say "the meeting > > agreed to do a WG last call for this doc to gauge consensus on the > > document". > >"Rough consensus" is basically obtained when the chairs say >it has been. I'm not sure where your quote comes from and >I'm having trouble making it fit with my experiences with the >IETF. > > > > > > > > 8. Unnumbered, Bundle, Hierarchy drafts > > > > > > After the "sub IP" re-org, these drafts remain in MPLS. > > > > > > Proposal: Accept draft-kompella-mpls-undle-05.txt as working group > > > draft. Update the draft as draft-mpls-bundle-00.txt. Some of the > >This should read "draft-ietf-mpls-bundle-00.txt" > > > > > > other drafts will also be updated. Once updated a WG last call > > > will be issued. None opposed; consensus. > > > > > Again... consensus on this MUST be sought on the WG mailing list. > >On the contrary, in order to successfully argue that rough consensus >has not been achieved, there needs to be more than one or two lone >voices in the wilderness that disagree. > > > > > > > ... snip .... > > > > > IV. LDP Fault Tollerance Philip Matthews > > > > > > > > > Summarized draft. Discussed changes between last version and current > > > version. Expect to ask for wg last call soon. Requested comments now or > > > via > > > mailing list. > > > > > > George: Consensus to put this draft to a wg last call. Luca Martini > > > opposes > > > wg last call; no other objections. > > > > > Make sure we have consensus on WG mailing list! > >On this, we can agree. However, the process is simple - the chair >asserts that "rough consensus" was achieved, and the people on >the mailing list have an opportunity to disagree. > >Do you disagree that these things should happen, or are >you strictly arguing process? > > > > > > > Bert > >-- >Eric Gray From owner-mpls@UU.NET Sun Apr 1 11:16:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04260 for ; Sun, 1 Apr 2001 11:16:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiwq01729; Sun, 1 Apr 2001 15:14:39 GMT Received: by mail-control.mail.uu.net id QQkiwq22503 for mpls-outgoing; Sun, 1 Apr 2001 15:14:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiwq22494 for ; Sun, 1 Apr 2001 15:14:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkiwq13878 for ; Sun, 1 Apr 2001 15:13:49 GMT Received: from johnson.mail.mindspring.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: johnson.mail.mindspring.net [207.69.200.177]) id QQkiwq10011 for ; Sun, 1 Apr 2001 15:13:48 GMT Received: from mindspring.com (user-2ive3cs.dialup.mindspring.com [165.247.13.156]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA02177; Sun, 1 Apr 2001 11:13:37 -0400 (EDT) Message-ID: <3AC74575.70D97323@mindspring.com> Date: Sun, 01 Apr 2001 11:12:53 -0400 From: Eric W Gray X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Bora Akyol CC: George Swallow , mpls@UU.NET, Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: <200103310108.f2V184d00890@localhost.pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora, The idea of delaying work because other work that is "in the pipe-line" may make it obsolete seems to come up a lot. There are two ways to look at this sort of idea: 1) the work will perform some necessary function as is and should be progressed; future work can then use this work as part of the "prior art" on which it should be based. 2) the work will not perform a useful function until the additional work that is "in the pipe-line" has reached some reasonably well understood state of maturity (e.g. - it published as a standard). I believe the working group has weighed in on the side of the former interpretation - which is a good thing, in my mind, because the expression "in the pipe-line" is a thinly disguised variation of another well-known white lie ("in the mail"). -- Eric Gray Bora Akyol wrote: > George > > The point that I was trying to make is that there is **other** reroute > work going on within the CCAMP WG and I am not sure about the > interaction between that work and the draft that is in question. Hence I > asked **a** question below. > > If it turns out that the WG consensus is to do a last call and send the > draft forward, fine by me. However, the draft may get obsoleted quickly > once the CCAMP WG concludes the fast reroute work. > > Bora > > On Friday, March 30, 2001, at 01:04 PM, George Swallow wrote: > > >> As far as I understand this draft outlines a mechanism for fast reroute > >> in MPLS networks. With this in mind, shouldn't we delay the last call > >> on > >> this draft until ther **other** fast reroute related drafts in CCAMP > >> run > >> to completion? > >> > >> Regards > >> > >> Bora > > > > Bora - > > > > I don't get your point. Would you suggest that Sonet not specify BLSR > > or closer to home IPoPTR not work on rerouting schemes? This is a > > technology specific mechanism which has immediate application. How or > > even if it fits into a larger picture is irrelavant. > > > > ...George > > > > > > ================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Mon Apr 2 00:24:00 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16088 for ; Mon, 2 Apr 2001 00:24:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiyr02482; Mon, 2 Apr 2001 04:21:53 GMT Received: by mail-control.mail.uu.net id QQkiyr02672 for mpls-outgoing; Mon, 2 Apr 2001 04:21:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkiyr02666 for ; Mon, 2 Apr 2001 04:21:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiyr09885 for ; Mon, 2 Apr 2001 04:20:52 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkiyr01814 for ; Mon, 2 Apr 2001 04:20:48 GMT Received: from goneto.net (dhcp64-134-59-138.ght.bos.wayport.net [64.134.59.138]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 84AB915F7E6; Mon, 2 Apr 2001 05:20:10 +0100 (BST) Message-ID: <3AC80ABA.D6AA99B2@goneto.net> Date: Mon, 02 Apr 2001 06:14:34 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, neil.2.harrison@bt.com wrote: > > Giles Heron [mailto:giles@goneto.net] wrote 29 March 2001 22:27 > > neil.2.harrison@bt.com wrote: > > > > > > > 2 At the top of page 5 in section 2 it says: > > > " When a failure occurs and the backup comes into use,......" > > > > > > All user-plane (and indeed control-plane) failure modes > > must be identified > > > and specified in terms of entry/exit criteria and > > consequent actions before > > > we can meaningfully proceed with this draft. > > > > > > For the user-plane, the failure modes which must be > > considered/defined are: > > > - simple below MPLS fabric server layer connectivity breaks; > > > - simple within MPLS fabric connectivity breaks (at > > or below the LSP > > > level considered); > > > > Both of these will be detected by the RSVP signalling, won't they? > NH=> Not necessarily. The functionality/processing of the user-plane and > control-traffic is not identical......and they can be subject to different > failure modes. Each needs its own OAM to handle defects relevant to its own > case. Further, one would like to have SLAs for the user-plane (for > customers) that require specific and consistent measurement. They also > require certain 'consequential actions' which are not currently specified > anywhere else but in our ID. And in general, one should not look at just > 'some' cases of defect in isolation.....they all require a harmonised > approach and, with careful up-front thought, this should also yield > simplicity of design. If you don't think about these aspects at the outset > then things can get very complex later should you require to add such > functionality. I'm not sure what to make of this paragraph. Can you please give us some examples of situations where the control plane will not detect the user plane defect? (other than the buggy software case below of course.) > > > - swapped LSPs, ie instead of A1->A2 and B1->B2 a > > defect creates > > > A1->B2 and B1->A2; > > > - mismerged LSPs, eg instead of A1->A2 and B1->B2 a > > defect creates > > > A1->A2 and A1+B1->B2 say (though there are potentially > > several variations on > > > this). > > > > Both of these would only occur (as far as I can tell) if the router > > software is buggy. As I have stated before I don't really see the > > benefit of adding code to fix buggy code. > NH=> It can be HW as well as SW that is faulty. The OAM has nothing to do > with 'fixing buggy code'....indeed it will not *fix* the defects, but only > allow correct handling should they occur to protect my customers and help my > Ops people diagnose the problem. It is also there to ensure a consistent > (and indeed simple) method of measuring availability and QoS (the former is > *the* critical metric, and the latter is dependent on former since it only > applies to the up-state). I have not seen any work (other than what is in > our ID) which shows how availability/QoS metrics can be consistently and > simply measured for all defect cases. And as a carrier this is something I > want. However, the overall purpose of the OAM is stated in the principles > section of the ID. I refer people back to this rather than repeat here. I'll take your point that it could be hardware as well as software that is buggy. And no - when I used the word "fix" I wasn't envisioning your OAM ID making binary patches to faulty code in real time ;-) > > > For the latter 2 defects it will be vital to suppress the > > traffic due to > > > potential security/censorship/misbilling implications for > > carriers and > > > customers. Speaking as a carrier these issues are > > requirements that must be > > > addressed. This is not optional, and rigorous definitions > > must be provided > > > (or referenced). > > > > Speaking as another carrier I *don't* see these as requirements that > > must be addressed. If software is buggy things go wrong. So > > let's fix > > the software rather than adding another layer to "manage" the bugs. > NH=> How are you going to decide/detect that the SW (or HW) is wrong in > order to fix it? Are you really also telling me you have no requirements to > offer/measure availability/QoS SLAs for customers?......but if you do then I > would be interested to know how you are going to do this, ie do you have an > alternative proposal you can share with us for evaluation please? It would > also be nice to hear from more carriers on this subject.....I know BT, FT, > DT, NTT and AT&T have an interest since they have seen/commented on what > appears in the work you have seen. I expect I'll detect buggy software or hardware by the usual combination of lab testing prior to deployment and network monitoring to look for anomalous behaviours. And yes, of course I have a requirement to offer SLAs to customers. Originally I had thought that some sort of MPLS OAM might be useful for this. Having read your draft, having seen the complexity involved, having figured out that all it seems to detect that cannot be detected by other means is mismerged/swapped LSPs, and having discovered that it doesn't support merging LSPs, I have come to the conclusion (rightly or wrongly) that I'm better off without. Giles -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Mon Apr 2 00:39:33 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18858 for ; Mon, 2 Apr 2001 00:39:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiys03329; Mon, 2 Apr 2001 04:37:37 GMT Received: by mail-control.mail.uu.net id QQkiys03482 for mpls-outgoing; Mon, 2 Apr 2001 04:37:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiys03472 for ; Mon, 2 Apr 2001 04:36:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiys07982 for ; Mon, 2 Apr 2001 04:35:37 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkiys29496 for ; Mon, 2 Apr 2001 04:35:35 GMT Received: from goneto.net (dhcp64-134-59-138.ght.bos.wayport.net [64.134.59.138]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id AFF2615F7E6; Mon, 2 Apr 2001 05:31:00 +0100 (BST) Message-ID: <3AC80D44.DDF87B3F@goneto.net> Date: Mon, 02 Apr 2001 06:25:24 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: raszuk@cisco.com Cc: Bora Akyol , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: <3AC3A8C0.F8433A12@goneto.net> <3AC6E087.7A290E46@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert Raszuk wrote: > > Giles, > > > > For the user-plane, the failure modes which must be considered/defined are: > > > - simple below MPLS fabric server layer connectivity breaks; > > > - simple within MPLS fabric connectivity breaks (at or below the LSP > > > level considered); > > > > Both of these will be detected by the RSVP signalling, won't they? > > Sure but the question is when ? > > Do you think that RSVP Error/Tear msgs will travel immediately - case of > link failure or are you proposing to run RSVP refresh in the interval > less then 1 sec - to detect the case of node failure ? The point is that > this draft is not about detection, but about backup LSP setup and label > allocation under the __local__ protection scheme. So let's talk on the > subject here. Sorry if I drifted off (or was led off) topic there. In any case yes I would expect link failures to be detected immediately. Node failures presumably require some form of polling to detect - so the questions are: at what level should this occur (link layer, RSVP, "MPLS OAM"?) how low is it reasonable to set the timers? > If one questions the use of local protection all together please specify > how else you will achive the same results of even less then 1 sec end to > end traffic disruption with end to end protection under both link & node > failures for the TE- LSP ? I'm all for local protection - precisely because it would be so hard to get end to end protection to meet the <1 sec goal. Giles > > Bora, > > Which CCAMP IDs address the setup & label allocation of backup tunnels > for local protection ? > > R. -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Mon Apr 2 01:18:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26828 for ; Mon, 2 Apr 2001 01:18:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkiyv22422; Mon, 2 Apr 2001 05:16:53 GMT Received: by mail-control.mail.uu.net id QQkiyv22582 for mpls-outgoing; Mon, 2 Apr 2001 05:16:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiyv22557 for ; Mon, 2 Apr 2001 05:16:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiyv11028 for ; Mon, 2 Apr 2001 05:15:51 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkiyv03016 for ; Mon, 2 Apr 2001 05:15:51 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id BAA05957 for mpls@uu.net; Mon, 2 Apr 2001 01:15:50 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiyv22523 for ; Mon, 2 Apr 2001 05:15:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkiyv09316 for ; Mon, 2 Apr 2001 05:15:04 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkiyv02423 for ; Mon, 2 Apr 2001 05:15:03 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA04372; Sun, 1 Apr 2001 22:15:02 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f325EuJ12770; Sun, 1 Apr 2001 22:14:57 -0700 (PDT) Message-ID: <3AC80A76.6838FAC4@cisco.com> Date: Sun, 01 Apr 2001 22:13:26 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: giles@goneto.net CC: Bora Akyol , neil.2.harrison@bt.com, swallow@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: <3AC3A8C0.F8433A12@goneto.net> <3AC6E087.7A290E46@cisco.com> <3AC80D44.DDF87B3F@goneto.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Giles, > In any case yes I would expect link failures to be detected > immediately. Detection does not equal headend notification, but anyway as you agree that local protection is a good thing I don't see a reason to hold this draft and not to proceed to last call - we needed it for customers using FRR today and want to interoperate with multiple vendors. Unless there is any other piece of work addressing this very specific issue of label allocation on bypass tunnels (not reroute in general) in mpls or ccamp I would agree with George's last call. R. From owner-mpls@UU.NET Mon Apr 2 05:22:40 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17960 for ; Mon, 2 Apr 2001 05:22:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkizl20492; Mon, 2 Apr 2001 09:21:05 GMT Received: by mail-control.mail.uu.net id QQkizl13447 for mpls-outgoing; Mon, 2 Apr 2001 09:20:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkizl13431 for ; Mon, 2 Apr 2001 09:20:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkizl24515 for ; Mon, 2 Apr 2001 09:19:34 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQkizl27001 for ; Mon, 2 Apr 2001 09:19:34 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Mon, 2 Apr 2001 10:19:20 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Mon, 2 Apr 2001 10:19:22 +0100 Message-ID: To: raszuk@cisco.com Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Mon, 2 Apr 2001 10:19:07 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Robert Raszuk [mailto:raszuk@cisco.com] wrote 01 April 2001 09:02 > Giles, > > > > For the user-plane, the failure modes which must be > considered/defined are: > > > - simple below MPLS fabric server layer connectivity breaks; > > > - simple within MPLS fabric connectivity breaks (at > or below the LSP > > > level considered); > > > > Both of these will be detected by the RSVP signalling, won't they? > > Sure but the question is when ? > > Do you think that RSVP Error/Tear msgs will travel > immediately - case of > link failure or are you proposing to run RSVP refresh in the interval > less then 1 sec - to detect the case of node failure ? The > point is that > this draft is not about detection, but about backup LSP setup > and label > allocation under the __local__ protection scheme. So let's talk on the > subject here. > > If one questions the use of local protection all together > please specify > how else you will achive the same results of even less then 1 > sec end to > end traffic disruption with end to end protection under both > link & node > failures for the TE- LSP ? NH=> Fair point Robert.....but it still leaves me wondering: 1 Why do we need such fast action......voice surely does not need few 10s ms restoration, 1-3s would be fine I feel sure (for the relatively rare case of failure......unless, perhaps, one expects such failures to occur on a very frequent basis)? BTW- I suspect the biggest source of 'disruptions' will be planned-works by operators at L1, ie pre-meditiated re-routing of traffic.....so some care should be taken that such actions don't invoke unecessary actions in higher layers. 2 Where are the failures referenced specified? Have Cisco their own specifications for this? We would really like to see these specified in some standard manner. thanks/regards, neil From owner-mpls@UU.NET Mon Apr 2 05:24:05 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18146 for ; Mon, 2 Apr 2001 05:24:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkizl29394; Mon, 2 Apr 2001 09:22:13 GMT Received: by mail-control.mail.uu.net id QQkizl13459 for mpls-outgoing; Mon, 2 Apr 2001 09:20:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkizl13449 for ; Mon, 2 Apr 2001 09:20:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkizl12662 for ; Mon, 2 Apr 2001 09:20:01 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkizl27330 for ; Mon, 2 Apr 2001 09:20:01 GMT Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP; Mon, 2 Apr 2001 10:20:59 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Mon, 2 Apr 2001 10:19:10 +0100 Message-ID: To: giles@goneto.net Cc: mpls@UU.NET Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Mon, 2 Apr 2001 10:19:08 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Giles Heron [mailto:giles@goneto.net] wrote 02 April 2001 06:15 > Can you please give us some examples of situations where the control > plane will not detect the user plane defect? (other than the buggy > software case below of course.) NH=> Any situation where the user and control-plane do not go through *exactly* the same routing/processing. In GMPLS-type situation this is a given, in MPLS this is less obvious I agree (except for those hopefully rare SW/HW failures modes).....especially for base LDP. However, as a general principle one should aim to make user and control-plane defect handing independent so as to allow flexibility of user and control-plane network topology design (they are quite distinct in principle, and the control-plane topology has to takes its design cues from the duct for rigorous resilience design). > > > And yes, of course I have a requirement to offer SLAs to customers. > Originally I had thought that some sort of MPLS OAM might be > useful for > this. Having read your draft, having seen the complexity involved, > having figured out that all it seems to detect that cannot be detected > by other means is mismerged/swapped LSPs, and having > discovered that it > doesn't support merging LSPs NH=> Lots of things don't support merging....nor is merging always such a wonderful thing. , I have come to the conclusion > (rightly or > wrongly) that I'm better off without. NH=> I can understand your view .....especially if all you ever want to use MPLS for is in a LDP-type of deployment. But I am still left with these unanswered questions for a path-oriented view/use of LSPs: - where are the definitions of defects specified? Note - I know some defects should be rare.......but we should aim to be rigorous in specification at the outset and we need to weight the 'prob of event' by its 'potential impact' to properly assess the real risk....it is not sufficinet to appeal to the rare prob alone (cf the aircraft or nuclear-power industries....OK networks don't kill people (usually at least!), but I hope you get my point). I am sure the vendors must have some specification, albeit currently proprietary....but these need standardising. - where are the 'consequent actions' on failure specified? - where is the definition of availability specified? - and how can we move on to define QoS metrics/objectives if we can't define availablity? As an operator we are coming under increasing pressure to be able to define these (esp for VPN customers), and in any case these are issues that should be thought about up-front and not later (when it might be too difficult to make changes). It seems clear that you don't have any answers to these questions, but you also don't have any alternative proposals either. BTW - I am surprised you thought the proposals complex. This is about as simple as we could make them, and Shahram (who works for a chip supplier) did not think these complex. regards, neil From owner-mpls@UU.NET Mon Apr 2 05:37:59 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20003 for ; Mon, 2 Apr 2001 05:37:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkizm11356; Mon, 2 Apr 2001 09:36:05 GMT Received: by mail-control.mail.uu.net id QQkizm14302 for mpls-outgoing; Mon, 2 Apr 2001 09:35:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkizm14293 for ; Mon, 2 Apr 2001 09:35:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkizm00423 for ; Mon, 2 Apr 2001 09:34:57 GMT Received: from sktelecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQkizm10429 for ; Mon, 2 Apr 2001 09:34:56 GMT Received: from LocalHost (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f329cZh12619 for ; Mon, 2 Apr 2001 18:38:35 +0900 (KST) Message-ID: <005a01c0bb57$f6d9ed80$77131796@sktelecom.com> From: "Rae M. Chang" To: Subject: Priority Date: Mon, 2 Apr 2001 18:33:23 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01C0BBA3.661B4360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C0BBA3.661B4360 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SW4gUkZDMjcwMiwgIlJlcSd0cyBmb3IgVEUgd2l0aCBNUExTIiwNCmNvdWxkIGFueW9uZSBjbGFy aWZ5IHRoZSBjb25jZXB0IG9mICJ0cmFmZmljIHRydW5rIiB3aGVuIGV4cGxhaW5pbmcgdGhlIGNv bmNlcHQgb2YgcHJpb3JpdHkgYXR0cmlidXRlPw0KSXMgdGhhdCBwcmlvcml0eSBzZXQgdXAgd2hl biBlc3RhYmxpc2hpbmcgYSBuZXcgTFNQIG9yIA0KcHJlLWVzdGFibGlzaGVkIGZvciBlYWNoIGxp bmsgYmFuZHdpZHRoIGJlZm9yZSBlc3RhYmxpc2hpbmcgYW55IExTUHM/DQoNCkFuZCwgbW9yZSBk ZXRhaWxlZCBleHBsYW5hdGlvbiBpcyBuZWVkZWQgZm9yIHRoZSAic2hhcmVkIGV4cGxpY2l0IHJl c2VydmF0aW9uIHN0eWxlIg0Kd2hlbiB5b3UgbWFrZSBhIHJlcm91dGUgcGF0aCBmb3IgYW55IGxp bmsgY29uZ2VzdGlvbiBvciBmYWlsdXJlcy4NCg0KUmFlLg0K ------=_NextPart_000_0057_01C0BBA3.661B4360 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkluIFJGQzI3 MDIsICJSZXEndHMgZm9yIFRFIHdpdGggTVBMUyIsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+Y291bGQgYW55b25lIGNsYXJpZnkgdGhlIGNvbmNlcHQgb2YgInRyYWZmaWMgDQp0cnVu ayImbmJzcDt3aGVuJm5ic3A7ZXhwbGFpbmluZyB0aGUgY29uY2VwdCBvZiBwcmlvcml0eSBhdHRy aWJ1dGU/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SXMgdGhhdCBwcmlvcml0eSBz ZXQgdXAmbmJzcDt3aGVuIGVzdGFibGlzaGluZyBhIG5ldyBMU1Agb3IgDQo8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5wcmUtZXN0YWJsaXNoZWQgZm9yJm5ic3A7ZWFjaCBsaW5rIGJh bmR3aWR0aCBiZWZvcmUgDQplc3RhYmxpc2hpbmcgYW55IExTUHM/PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QW5k LCZuYnNwO21vcmUgZGV0YWlsZWQgZXhwbGFuYXRpb24gaXMgbmVlZGVkIGZvciB0aGUgInNoYXJl ZCANCmV4cGxpY2l0IHJlc2VydmF0aW9uIHN0eWxlIjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPndoZW4geW91IG1ha2UgYSByZXJvdXRlIHBhdGggZm9yIGFueSBsaW5rIGNvbmdlc3Rp b24gb3IgDQpmYWlsdXJlcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5SYWUuPC9GT05UPjwvRElWPjwvQk9EWT48 L0hUTUw+DQo= ------=_NextPart_000_0057_01C0BBA3.661B4360-- From owner-mpls@UU.NET Mon Apr 2 06:45:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27988 for ; Mon, 2 Apr 2001 06:45:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkizq28996; Mon, 2 Apr 2001 10:41:56 GMT Received: by mail-control.mail.uu.net id QQkizq05326 for mpls-outgoing; Mon, 2 Apr 2001 10:41:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkizq05291 for ; Mon, 2 Apr 2001 10:41:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkizq07154 for ; Mon, 2 Apr 2001 10:40:17 GMT Received: from auemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQkizq28104 for ; Mon, 2 Apr 2001 10:40:16 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA00892 for ; Mon, 2 Apr 2001 06:40:16 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA00858 for ; Mon, 2 Apr 2001 06:40:15 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 12:40:14 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0BD4FBDB@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eric Gray , "Thomas D. Nadeau" Cc: mpls@UU.NET, George Swallow Subject: RE: Draft MPLS minutes Date: Mon, 2 Apr 2001 12:40:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Inline > ---------- > From: Thomas D. Nadeau[SMTP:tnadeau@cisco.com] > Sent: Sunday, April 01, 2001 5:48 PM > To: Eric Gray; Wijnen, Bert (Bert) > Cc: mpls@UU.NET; George Swallow > Subject: Re: Draft MPLS minutes > > At 02:39 PM 3/30/2001 -0500, Eric Gray wrote: ... snip ... > > > > Authors are in the process addressing comments from the IESG. > > > > Another round of last calls is probably not required. > > > > > > > I am not so sure of that. Some serious issues have been found, and I > > > think some real changes may occur. Let's see what the next rev > > > of these drafts will look like first. > > > >Please state which drafts you think this observation applies to. > > > >There is no sense in holding a last call on all regenerated drafts > >because there is a sense that some serious issues (may) have > >been raised with respect to some drafts. > > Being the one fixing the aforementioned "serious issues", > let me elucidate what I think those issues are. 8) > > a) the MIB needing a good recompile, > b) some specifics on descriptions being deficient, > c) a request from the IESG to take all of the TCs out > of that MIB as well as from the LDP/TE MIBs, and put them > into > a single MPLS-TC-MIB. > > I am nearly finished with all of the edits required for > these changes, and should be handing over the new version of the > LSR MIB (and the TC MIB) to Bert on Monday or Tuesday, and will seek > guidance on the TC-MIB from him at that time. I presume that these > same "serious" issues and in particular, b and c, exist with the > LDP MIB as well. > I would hope/assume that LSR MIB authors and LDP MIB authors get together to discuss this. There were TCs that have the same names but had different semantics. Such cannot be approved. As a result, I expect enough changes to the MIBs that another WG last call is appropriate. Bert From owner-mpls@UU.NET Mon Apr 2 07:01:16 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28983 for ; Mon, 2 Apr 2001 07:01:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkizs21190; Mon, 2 Apr 2001 11:00:25 GMT Received: by mail-control.mail.uu.net id QQkizs06618 for mpls-outgoing; Mon, 2 Apr 2001 11:00:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkizr06538 for ; Mon, 2 Apr 2001 10:59:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkizr07318 for ; Mon, 2 Apr 2001 10:59:27 GMT Received: from ultra5.unile.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ultra5.unile.it [193.204.77.251]) id QQkizr20217 for ; Mon, 2 Apr 2001 10:59:26 GMT Received: from jack (drum.unile.it [193.204.77.151]) by ultra5.unile.it (8.9.1b+Sun/8.9.1) with SMTP id MAA17051; Mon, 2 Apr 2001 12:57:25 +0100 (WET DST) Message-ID: <00ee01c0bb63$a56e4e80$974dccc1@unile.it> Reply-To: "Simone Molendini" From: "Simone Molendini" To: "mpls_list" Cc: "Franco Tommasi" , "Andrea Tricco" Subject: Fw: I-D ACTION:draft-tommasi-mpls-intserv-00.txt Date: Mon, 2 Apr 2001 12:57:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkizs21190 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA28983 FYI, a new draft related to MPLS is available from the ID directory. Comments and hints are welcome. Best regards, Simone Molendini ----- Original Message ----- From: To: Sent: venerd́ 30 marzo 2001 14.30 Subject: I-D ACTION:draft-tommasi-mpls-intserv-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Integrated Services across MPLS domains using CR-LDP > signaling > Author(s) : F. Tommasi, S. Molendini, A. Tricco > Filename : draft-tommasi-mpls-intserv-00.txt > Pages : 26 > Date : 29-Mar-01 > > The Integrated Services (IntServ) architecture [RFC1633] defines QoS > services and reservation parameters to be used to obtain for an > Internet flow the required QoS. After a reservation has been > established using the RSVP protocol [RFC2205], a router classifies > each incoming IP packet to determine whether it belongs to a QoS > flow. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tommasi-mpls-intserv-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-tommasi-mpls-intserv-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-tommasi-mpls-intserv-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. > From owner-mpls@UU.NET Mon Apr 2 08:48:35 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05808 for ; Mon, 2 Apr 2001 08:48:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkizz02643; Mon, 2 Apr 2001 12:45:42 GMT Received: by mail-control.mail.uu.net id QQkizz16661 for mpls-outgoing; Mon, 2 Apr 2001 12:45:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkizz16525 for ; Mon, 2 Apr 2001 12:45:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkizy20601 for ; Mon, 2 Apr 2001 12:44:35 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkizy22519 for ; Mon, 2 Apr 2001 12:44:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA21418 for mpls@uu.net; Mon, 2 Apr 2001 08:44:34 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkizy16392 for ; Mon, 2 Apr 2001 12:43:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkizy25329 for ; Mon, 2 Apr 2001 12:43:17 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkizy08817 for ; Mon, 2 Apr 2001 12:43:17 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA09457; Mon, 2 Apr 2001 08:42:23 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (rtp-dial-2-67.cisco.com [10.83.96.67]) by bucket.cisco.com (Mirapoint) with ESMTP id AAB02216; Mon, 2 Apr 2001 08:43:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20010402084247.0ec1bc00@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Apr 2001 08:43:40 -0500 To: "Wijnen, Bert (Bert)" , Eric Gray From: "Thomas D. Nadeau" Subject: RE: Draft MPLS minutes Cc: mpls@UU.NET, George Swallow In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0BD4FBDB@nl0006exch002u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 12:40 PM 4/2/2001 +0200, Wijnen, Bert (Bert) wrote: >Inline > > > ---------- > > From: Thomas D. Nadeau[SMTP:tnadeau@cisco.com] > > Sent: Sunday, April 01, 2001 5:48 PM > > To: Eric Gray; Wijnen, Bert (Bert) > > Cc: mpls@UU.NET; George Swallow > > Subject: Re: Draft MPLS minutes > > > > At 02:39 PM 3/30/2001 -0500, Eric Gray wrote: >... snip ... > > > > > Authors are in the process addressing comments from the IESG. > > > > > Another round of last calls is probably not required. > > > > > > > > > I am not so sure of that. Some serious issues have been found, and I > > > > think some real changes may occur. Let's see what the next rev > > > > of these drafts will look like first. > > > > > >Please state which drafts you think this observation applies to. > > > > > >There is no sense in holding a last call on all regenerated drafts > > >because there is a sense that some serious issues (may) have > > >been raised with respect to some drafts. > > > > Being the one fixing the aforementioned "serious issues", > > let me elucidate what I think those issues are. 8) > > > > a) the MIB needing a good recompile, > > b) some specifics on descriptions being deficient, > > c) a request from the IESG to take all of the TCs out > > of that MIB as well as from the LDP/TE MIBs, and put them > > into > > a single MPLS-TC-MIB. > > > > I am nearly finished with all of the edits required for > > these changes, and should be handing over the new version of the > > LSR MIB (and the TC MIB) to Bert on Monday or Tuesday, and will seek > > guidance on the TC-MIB from him at that time. I presume that these > > same "serious" issues and in particular, b and c, exist with the > > LDP MIB as well. > > >I would hope/assume that LSR MIB authors and LDP MIB authors get >together to discuss this. There were TCs that have the same names >but had different semantics. Such cannot be approved. As a result, >I expect enough changes to the MIBs that another WG last call >is appropriate. Yes, we are getting together today to coordinate the new TC MIB. --Tom From owner-mpls@UU.NET Mon Apr 2 09:32:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08194 for ; Mon, 2 Apr 2001 09:32:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjab14286; Mon, 2 Apr 2001 13:29:20 GMT Received: by mail-control.mail.uu.net id QQkjab06440 for mpls-outgoing; Mon, 2 Apr 2001 13:28:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjab06434 for ; Mon, 2 Apr 2001 13:28:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjab03868 for ; Mon, 2 Apr 2001 13:27:53 GMT Received: from WATERTOWN.litchfieldcomm.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.252.190.60]) id QQkjab07395 for ; Mon, 2 Apr 2001 13:27:53 GMT Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Mon, 2 Apr 2001 09:27:49 -0400 Message-ID: <0E2DFCE7E586904DA0F583CB5EAD73CC0312F9@WATERTOWN.litchfieldcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Last Call on RSVP Label Allocation for Backup Tunnels Thread-Index: AcC7eLaWzjJHm7Y3Q6S95TTKu7Ih0g== From: "Dave Danenberg" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 To: , content-class: urn:content-classes:message Cc: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA08194 Neil/Giles, I've been watching your exchange with interest. Especially when discussing whether MPLS signaling can be used reliably for data-plane failure detection. So let me just throw this into the discussion... Won't most MPLS deployments support statically configured MPLS connections? If so, then signaling would not be there - even if it could reliably detect data-plane failures. Seems like a good argument for MPLS OAM. Also, (being in the chips and systems business) I agree with Neil and Shahram that MPLS OAM implementation is not complex. --Dave -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of neil.2.harrison@bt.com Sent: Monday, April 02, 2001 5:19 AM To: giles@goneto.net Cc: mpls@UU.NET Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Giles Heron [mailto:giles@goneto.net] wrote 02 April 2001 06:15 > Can you please give us some examples of situations where the control > plane will not detect the user plane defect? (other than the buggy > software case below of course.) NH=> Any situation where the user and control-plane do not go through *exactly* the same routing/processing. In GMPLS-type situation this is a given, in MPLS this is less obvious I agree (except for those hopefully rare SW/HW failures modes).....especially for base LDP. However, as a general principle one should aim to make user and control-plane defect handing independent so as to allow flexibility of user and control-plane network topology design (they are quite distinct in principle, and the control-plane topology has to takes its design cues from the duct for rigorous resilience design). > > > And yes, of course I have a requirement to offer SLAs to customers. > Originally I had thought that some sort of MPLS OAM might be > useful for > this. Having read your draft, having seen the complexity involved, > having figured out that all it seems to detect that cannot be detected > by other means is mismerged/swapped LSPs, and having > discovered that it > doesn't support merging LSPs NH=> Lots of things don't support merging....nor is merging always such a wonderful thing. , I have come to the conclusion > (rightly or > wrongly) that I'm better off without. NH=> I can understand your view .....especially if all you ever want to use MPLS for is in a LDP-type of deployment. But I am still left with these unanswered questions for a path-oriented view/use of LSPs: - where are the definitions of defects specified? Note - I know some defects should be rare.......but we should aim to be rigorous in specification at the outset and we need to weight the 'prob of event' by its 'potential impact' to properly assess the real risk....it is not sufficinet to appeal to the rare prob alone (cf the aircraft or nuclear-power industries....OK networks don't kill people (usually at least!), but I hope you get my point). I am sure the vendors must have some specification, albeit currently proprietary....but these need standardising. - where are the 'consequent actions' on failure specified? - where is the definition of availability specified? - and how can we move on to define QoS metrics/objectives if we can't define availablity? As an operator we are coming under increasing pressure to be able to define these (esp for VPN customers), and in any case these are issues that should be thought about up-front and not later (when it might be too difficult to make changes). It seems clear that you don't have any answers to these questions, but you also don't have any alternative proposals either. BTW - I am surprised you thought the proposals complex. This is about as simple as we could make them, and Shahram (who works for a chip supplier) did not think these complex. regards, neil From owner-mpls@UU.NET Mon Apr 2 10:22:50 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11426 for ; Mon, 2 Apr 2001 10:22:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjaf10939; Mon, 2 Apr 2001 14:20:03 GMT Received: by mail-control.mail.uu.net id QQkjaf27956 for mpls-outgoing; Mon, 2 Apr 2001 14:19:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjaf27949 for ; Mon, 2 Apr 2001 14:19:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjaf28390 for ; Mon, 2 Apr 2001 14:18:08 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkjaf16409 for ; Mon, 2 Apr 2001 14:18: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 HAA27255 for ; Mon, 2 Apr 2001 07:18:29 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA09899 for mpls@uu.net; Mon, 2 Apr 2001 10:18:06 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkiwv11585 for ; Sun, 1 Apr 2001 16:15:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkiwu05709 for ; Sun, 1 Apr 2001 16:14:50 GMT Received: from omta03.mta.everyone.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sitemail.everyone.net [216.200.145.35]) id QQkiwu07018 for ; Sun, 1 Apr 2001 16:14:49 GMT Received: from sitemail.everyone.net (reports [216.200.145.62]) by omta03.mta.everyone.net (Postfix) with ESMTP id 4B6B248CEE; Sun, 1 Apr 2001 09:14:49 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id 11B4436F9; Sun, 1 Apr 2001 09:14:49 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) Date: Sun, 1 Apr 2001 09:14:49 -0700 (PDT) From: Vikram Gupta To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Why no separate MPLS label/Shim Header when we use MPLS over ATM ?? Reply-To: vikram_gupta@firstlinux.net X-Originating-Ip: [203.197.168.163] Message-Id: <20010401161449.11B4436F9@sitemail.everyone.net> Sender: owner-mpls@UU.NET Precedence: bulk Hello Everybody, I have 2 questions about which I am pretty confused....... 1.Why is it that sometimes the MPLS label is embedded in the header of the data link layer ( e.g in the ATM VCI/VPI and the frame-relay DLCI ) and sometimes it is in the shim (between the Layer-2 data- link header and Layer-3 network layer header, as in Point -to-Point PPP/Ethernet). Why 2 different mechanisms ? 2.Would it be correct to say that when ATM is the data-link layer ,then we have No separate MPLS label/Shim Header to encapsulate the IP Packet.The IP packet is directly encapsulated in ATM cells . ..and the VPI/VCI Present in the ATM Cell Header do the work of MPLS Labels. In such a case what would be the significance of MPLS signaling protocols like LDP /RSVP which co-ordinate Label Distribution and create LSPs ? Would they co-ordinate which VPIs/VCIs would be used for which LSP ? But how could LDP possibly tell ATM which VPI/VCI to use for which LSP ?? Sorry if the questions sound stupid...since I am new to this field. Thanks a lot, Vik _____________________________________________________________ Want a new web-based email account ? ---> http://www.firstlinux.net From owner-mpls@UU.NET Mon Apr 2 14:13:37 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24118 for ; Mon, 2 Apr 2001 14:13:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjau18944; Mon, 2 Apr 2001 18:09:41 GMT Received: by mail-control.mail.uu.net id QQkjau23126 for mpls-outgoing; Mon, 2 Apr 2001 18:09:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjau23100 for ; Mon, 2 Apr 2001 18:09:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjau00989 for ; Mon, 2 Apr 2001 18:08:41 GMT Received: from hclhprnd.hclt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkjau16609 for ; Mon, 2 Apr 2001 18:08:39 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id AAA26741; Tue, 3 Apr 2001 00:06:45 +0530 Received: from MALLIKPC ([192.168.232.110]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G2MJAP32; Mon, 2 Apr 2001 23:37:28 +0530 Message-ID: <012801c0bba0$057c0830$6ee8a8c0@hclt.com> From: "gopinathg" To: , Subject: How to find a CR-LSP Label from a Label release Message with no optional parameters? Date: Mon, 2 Apr 2001 23:38:58 +0530 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 As per the section 3.5 of draft-ietf-mpls-cr-ldp-05.txt says " The Label Release , Label Withdraw, and Label Abort Request Messages are used as specified in [1]. These messages may also carry the LSPID TLV " ( And it also refers to [1] ie RFC 3036) As from the above words " These messages may also carry the LSPID TLV " we can assume that LSPID TLV is not mandatory ( and hence optional). As per the section 3.5.11 of RFC 3036 Label TLV is optional . Now suppose if we have a label release message with no Label TLV, no LSPID TLV(as we can assume both are optional from the above ) and FEC TLV with CR-LSP FEC Element. Now how will an LSR find the CR-LSP Label with the above information. ? Thanks In Advance gopinathg From owner-mpls@UU.NET Mon Apr 2 14:38:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25406 for ; Mon, 2 Apr 2001 14:38:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjaw16933; Mon, 2 Apr 2001 18:35:28 GMT Received: by mail-control.mail.uu.net id QQkjaw26735 for mpls-outgoing; Mon, 2 Apr 2001 18:34:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjaw26494 for ; Mon, 2 Apr 2001 18:31:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjaw17024 for ; Mon, 2 Apr 2001 18:30:09 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkjaw11614 for ; Mon, 2 Apr 2001 18:30:08 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA21428 for ; Mon, 2 Apr 2001 14:30:06 -0400 (EDT) Received: from marconi.com (lego-king.dc.fore.com [169.144.136.180]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA05930 for ; Mon, 2 Apr 2001 14:30:07 -0400 (EDT) Message-ID: <3AC8C535.799FF933@marconi.com> Date: Mon, 02 Apr 2001 14:30:13 -0500 From: Jack Brennen X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: How to find a CR-LSP Label from a Label release Message with no optional parameters? References: <012801c0bba0$057c0830$6ee8a8c0@hclt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit My opinion, for what it's worth: To quote RFC 3036: "If no Label TLV follows the FEC, all labels associated with the FEC are to be released..." If a Label Release message is received with a FEC consisting of a single CR-LSP FEC Element, and no Label TLV is present, it seems that it would be appropriate to release all Labels associated with such a FEC. That would generally mean releasing all CR-LSPs on the associated label space. Any dissenters? Jack Brennen gopinathg wrote: > > Hi > > As per the section 3.5 of draft-ietf-mpls-cr-ldp-05.txt says > > " The Label Release , Label Withdraw, and Label Abort Request Messages > are used as specified in [1]. These messages may also carry the > LSPID TLV " ( And it also refers to [1] ie RFC 3036) > > As from the above words " These messages may also carry the LSPID TLV " we can > assume that LSPID TLV is not mandatory ( and hence optional). > > As per the section 3.5.11 of RFC 3036 Label TLV is optional . > > Now suppose if we have a label release message with no Label TLV, no LSPID > TLV(as we can assume both are optional from the above ) and FEC TLV with > CR-LSP FEC Element. > Now how will an LSR find the CR-LSP Label with the above information. ? > > Thanks In Advance > > gopinathg From owner-mpls@UU.NET Mon Apr 2 15:18:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26533 for ; Mon, 2 Apr 2001 15:18:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjaz27317; Mon, 2 Apr 2001 19:15:34 GMT Received: by mail-control.mail.uu.net id QQkjaz17375 for mpls-outgoing; Mon, 2 Apr 2001 19:15:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjay17368 for ; Mon, 2 Apr 2001 19:14:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjay02335 for ; Mon, 2 Apr 2001 19:14:35 GMT Received: from hclhprnd.hclt.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkjay09662 for ; Mon, 2 Apr 2001 19:14:34 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id BAA27675; Tue, 3 Apr 2001 01:13:03 +0530 Received: from MALLIKPC ([192.168.232.110]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G2MJAPRN; Tue, 3 Apr 2001 00:43:46 +0530 Message-ID: <013a01c0bba9$4936a900$6ee8a8c0@hclt.com> From: "gopinathg" To: "Jack Brennen" , References: <012801c0bba0$057c0830$6ee8a8c0@hclt.com> <3AC8C535.799FF933@marconi.com> Subject: Re: How to find a CR-LSP Label from a Label release Message with no optional parameters? Date: Tue, 3 Apr 2001 00:45:18 +0530 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 Jack Your opinion is correct in case of LDP but, If LSP's are established using CR-LDP then all CR-LSP Labels will have same FEC TLV ie FEC TLV with CR-LSP Element. If it is the case then there will be no CR- LDP LSP's after receiving Label Release. Thanks gopinathg ----- Original Message ----- From: Jack Brennen To: Sent: Tuesday, April 03, 2001 1:00 AM Subject: Re: How to find a CR-LSP Label from a Label release Message with no optional parameters? > My opinion, for what it's worth: > > To quote RFC 3036: "If no Label TLV follows the FEC, all labels > associated with the FEC are to be released..." > > If a Label Release message is received with a FEC consisting of > a single CR-LSP FEC Element, and no Label TLV is present, it seems > that it would be appropriate to release all Labels associated > with such a FEC. That would generally mean releasing all CR-LSPs > on the associated label space. > > Any dissenters? > > Jack Brennen > > gopinathg wrote: > > > > Hi > > > > As per the section 3.5 of draft-ietf-mpls-cr-ldp-05.txt says > > > > " The Label Release , Label Withdraw, and Label Abort Request Messages > > are used as specified in [1]. These messages may also carry the > > LSPID TLV " ( And it also refers to [1] ie RFC 3036) > > > > As from the above words " These messages may also carry the LSPID TLV " we can > > assume that LSPID TLV is not mandatory ( and hence optional). > > > > As per the section 3.5.11 of RFC 3036 Label TLV is optional . > > > > Now suppose if we have a label release message with no Label TLV, no LSPID > > TLV(as we can assume both are optional from the above ) and FEC TLV with > > CR-LSP FEC Element. > > Now how will an LSR find the CR-LSP Label with the above information. ? > > > > Thanks In Advance > > > > gopinathg From owner-mpls@UU.NET Mon Apr 2 15:20:03 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26604 for ; Mon, 2 Apr 2001 15:20:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjaz17354; Mon, 2 Apr 2001 19:17:07 GMT Received: by mail-control.mail.uu.net id QQkjaz18090 for mpls-outgoing; Mon, 2 Apr 2001 19:16:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjaz17810 for ; Mon, 2 Apr 2001 19:16:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjaz11417 for ; Mon, 2 Apr 2001 19:15:07 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkjaz15442 for ; Mon, 2 Apr 2001 19:15:07 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 68E6994006; Mon, 2 Apr 2001 15:15:03 -0400 (EDT) Message-ID: <3AC8CFB7.48D8A7E4@sandburst.com> Date: Mon, 02 Apr 2001 15:15:03 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: gopinathg Cc: mpls@UU.NET Subject: Re: How to find a CR-LSP Label from a Label release Message with no optional parameters? References: <012801c0bba0$057c0830$6ee8a8c0@hclt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gopinath, The set of options you describe below is possible and should be allowed, but it is unlikely that an implementation will use that set (at least very often). The FEC TLV is manadatory in a Label Release and a Label may be omitted if you effectively would like to release all labels associated with that FEC. In the event that a CR-LDP implementation wanted - for some reason - to release ALL labels associated with the CR-LSP FEC, then it would omit the label TLV. I can think of one - semi-reasonable - reason for doing this: an implementation may determine (based on internal information or configuration) that it needs to drop back from supporting CR-LDP to just support LDP. By omitting the set of optional TLVs you mention, it might be able to do this fairly quickly and still avoid having to drop the LDP session (thus invalidating hop-by-hop labels as well). How likely this is to be useful in practice is another question. In every case where it was not the intention to drop all LSPs associated with the CR-LSP FEC, an implementation would need to include the Label TLV in order to scope the effects of the Label Release message. -- Eric Gray You wrote: > Hi > > As per the section 3.5 of draft-ietf-mpls-cr-ldp-05.txt says > > " The Label Release , Label Withdraw, and Label Abort Request Messages > are used as specified in [1]. These messages may also carry the > LSPID TLV " ( And it also refers to [1] ie RFC 3036) > > As from the above words " These messages may also carry the LSPID TLV " we can > assume that LSPID TLV is not mandatory ( and hence optional). > > As per the section 3.5.11 of RFC 3036 Label TLV is optional . > > Now suppose if we have a label release message with no Label TLV, no LSPID > TLV(as we can assume both are optional from the above ) and FEC TLV with > CR-LSP FEC Element. > Now how will an LSR find the CR-LSP Label with the above information. ? > > Thanks In Advance > > gopinathg From owner-mpls@UU.NET Mon Apr 2 15:28:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26823 for ; Mon, 2 Apr 2001 15:28:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjaz24568; Mon, 2 Apr 2001 19:24:40 GMT Received: by mail-control.mail.uu.net id QQkjaz18740 for mpls-outgoing; Mon, 2 Apr 2001 19:24:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjaz18735 for ; Mon, 2 Apr 2001 19:24:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjaz06137 for ; Mon, 2 Apr 2001 19:22:49 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkjaz22849 for ; Mon, 2 Apr 2001 19:22:49 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id E61A69400A; Mon, 2 Apr 2001 15:22:48 -0400 (EDT) Message-ID: <3AC8D188.A011C532@sandburst.com> Date: Mon, 02 Apr 2001 15:22:48 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: gopinathg Cc: Jack Brennen , mpls@UU.NET Subject: Re: How to find a CR-LSP Label from a Label release Message with no optional parameters? References: <012801c0bba0$057c0830$6ee8a8c0@hclt.com> <3AC8C535.799FF933@marconi.com> <013a01c0bba9$4936a900$6ee8a8c0@hclt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gopinath, A point of confusion about what it means for something to be 'optional'. The fact that something is optional does not guarantee that you will like the results of not including it. -- Eric Gray You wrote: > Hi Jack > > Your opinion is correct in case of LDP but, If LSP's are established using > CR-LDP > then all CR-LSP Labels will have same FEC TLV ie FEC TLV with CR-LSP > Element. > > If it is the case then there will be no CR- LDP LSP's after receiving Label > Release. > > Thanks > gopinathg > > ----- Original Message ----- > From: Jack Brennen > To: > Sent: Tuesday, April 03, 2001 1:00 AM > Subject: Re: How to find a CR-LSP Label from a Label release Message with no > optional parameters? > > > My opinion, for what it's worth: > > > > To quote RFC 3036: "If no Label TLV follows the FEC, all labels > > associated with the FEC are to be released..." > > > > If a Label Release message is received with a FEC consisting of > > a single CR-LSP FEC Element, and no Label TLV is present, it seems > > that it would be appropriate to release all Labels associated > > with such a FEC. That would generally mean releasing all CR-LSPs > > on the associated label space. > > > > Any dissenters? > > > > Jack Brennen > > > > gopinathg wrote: > > > > > > Hi > > > > > > As per the section 3.5 of draft-ietf-mpls-cr-ldp-05.txt says > > > > > > " The Label Release , Label Withdraw, and Label Abort Request Messages > > > are used as specified in [1]. These messages may also carry the > > > LSPID TLV " ( And it also refers to [1] ie RFC 3036) > > > > > > As from the above words " These messages may also carry the LSPID TLV " we > can > > > assume that LSPID TLV is not mandatory ( and hence optional). > > > > > > As per the section 3.5.11 of RFC 3036 Label TLV is optional . > > > > > > Now suppose if we have a label release message with no Label TLV, no LSPID > > > TLV(as we can assume both are optional from the above ) and FEC TLV with > > > CR-LSP FEC Element. > > > Now how will an LSR find the CR-LSP Label with the above information. ? > > > > > > Thanks In Advance > > > > > > gopinathg From owner-mpls@UU.NET Mon Apr 2 15:29:38 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26874 for ; Mon, 2 Apr 2001 15:29:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjaz21442; Mon, 2 Apr 2001 19:26:07 GMT Received: by mail-control.mail.uu.net id QQkjaz18863 for mpls-outgoing; Mon, 2 Apr 2001 19:25:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjaz18839 for ; Mon, 2 Apr 2001 19:25:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjaz08869 for ; Mon, 2 Apr 2001 19:24:17 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkjaz24185 for ; Mon, 2 Apr 2001 19:24:17 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27257; Mon, 2 Apr 2001 15:24:15 -0400 (EDT) Received: from marconi.com (lego-king.dc.fore.com [169.144.136.180]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22977; Mon, 2 Apr 2001 15:24:15 -0400 (EDT) Message-ID: <3AC8D1DD.8035A66@marconi.com> Date: Mon, 02 Apr 2001 15:24:13 -0500 From: Jack Brennen X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: gopinathg CC: mpls@UU.NET Subject: Re: How to find a CR-LSP Label from a Label release Message with no optional parameters? References: <012801c0bba0$057c0830$6ee8a8c0@hclt.com> <3AC8C535.799FF933@marconi.com> <013a01c0bba9$4936a900$6ee8a8c0@hclt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yes, that's my interpretation also (that there will be no CR-LDP LSP's after receiving the Label Release message). I think one way of describing this is that the Label TLV is _syntactically_ optional, but _semantically_ mandatory (unless you really want to release all CR-LSP labels). Jack gopinathg wrote: > > Hi Jack > > Your opinion is correct in case of LDP but, If LSP's are established using > CR-LDP > then all CR-LSP Labels will have same FEC TLV ie FEC TLV with CR-LSP > Element. > > If it is the case then there will be no CR- LDP LSP's after receiving Label > Release. > > Thanks > gopinathg > > ----- Original Message ----- > From: Jack Brennen > To: > Sent: Tuesday, April 03, 2001 1:00 AM > Subject: Re: How to find a CR-LSP Label from a Label release Message with no > optional parameters? > > > My opinion, for what it's worth: > > > > To quote RFC 3036: "If no Label TLV follows the FEC, all labels > > associated with the FEC are to be released..." > > > > If a Label Release message is received with a FEC consisting of > > a single CR-LSP FEC Element, and no Label TLV is present, it seems > > that it would be appropriate to release all Labels associated > > with such a FEC. That would generally mean releasing all CR-LSPs > > on the associated label space. > > > > Any dissenters? > > > > Jack Brennen > > > > gopinathg wrote: > > > > > > Hi > > > > > > As per the section 3.5 of draft-ietf-mpls-cr-ldp-05.txt says > > > > > > " The Label Release , Label Withdraw, and Label Abort Request Messages > > > are used as specified in [1]. These messages may also carry the > > > LSPID TLV " ( And it also refers to [1] ie RFC 3036) > > > > > > As from the above words " These messages may also carry the LSPID TLV " we > can > > > assume that LSPID TLV is not mandatory ( and hence optional). > > > > > > As per the section 3.5.11 of RFC 3036 Label TLV is optional . > > > > > > Now suppose if we have a label release message with no Label TLV, no LSPID > > > TLV(as we can assume both are optional from the above ) and FEC TLV with > > > CR-LSP FEC Element. > > > Now how will an LSR find the CR-LSP Label with the above information. ? > > > > > > Thanks In Advance > > > > > > gopinathg From owner-mpls@UU.NET Mon Apr 2 15:38:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27129 for ; Mon, 2 Apr 2001 15:38:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjba01205; Mon, 2 Apr 2001 19:34:58 GMT Received: by mail-control.mail.uu.net id QQkjba19753 for mpls-outgoing; Mon, 2 Apr 2001 19:34:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjba19743 for ; Mon, 2 Apr 2001 19:34:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjba04740 for ; Mon, 2 Apr 2001 19:32:39 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjba14779 for ; Mon, 2 Apr 2001 19:32:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA26789 for mpls@uu.net; Mon, 2 Apr 2001 15:32:37 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjba19612 for ; Mon, 2 Apr 2001 19:31:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjba22621 for ; Mon, 2 Apr 2001 19:31:11 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkjba03963 for ; Mon, 2 Apr 2001 19:31:11 GMT Received: (qmail 25243 invoked by uid 104); 2 Apr 2001 19:31:10 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 2.240171 secs); 02/04/2001 12:31:07 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 2 Apr 2001 19:31:06 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f32JV6909801 for ; Mon, 2 Apr 2001 12:31:06 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 12:31:43 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B81@BBY1EXM01> From: Shahram Davari To: "'mpls@uu.net'" Subject: mpls statistics Date: Mon, 2 Apr 2001 12:31:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0BBAB.8B6B7150" 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_01C0BBAB.8B6B7150 Content-Type: text/plain; charset="iso-8859-1" Hi all, Is the MPLS statistics as defined in LSR-MIB mandatory or optional? Regards, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 <> ------_=_NextPart_000_01C0BBAB.8B6B7150 Content-Type: application/octet-stream; name="Shahram Davari.vcf" Content-Disposition: attachment; filename="Shahram Davari.vcf" BEGIN:VCARD VERSION:2.1 N:Davari;Shahram FN:Shahram Davari ORG:PMC-Sierra, Inc.;R&D Research Ottawa-109203 TITLE:Product Research Engineer TEL;WORK;VOICE:+1 613 271 4018 ADR;WORK:;Ottawa;Kanata Research Park, Suite 834, Office Tower B, 555 Legget Drive;Kanata;Ontario;K2K 2X3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ottawa=0D=0AKanata Research Park, Suite 834, Office Tower B, 555 Legget Driv= e=0D=0AKanata, Ontario K2K 2X3=0D=0ACanada EMAIL;PREF;INTERNET:Shahram_Davari@pmc-sierra.com REV:20010112T213717Z END:VCARD ------_=_NextPart_000_01C0BBAB.8B6B7150-- From owner-mpls@UU.NET Mon Apr 2 16:01:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28220 for ; Mon, 2 Apr 2001 16:01:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjbb24942; Mon, 2 Apr 2001 19:58:16 GMT Received: by mail-control.mail.uu.net id QQkjbb22277 for mpls-outgoing; Mon, 2 Apr 2001 19:57:42 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjbb22191 for ; Mon, 2 Apr 2001 19:57:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjbb15746 for ; Mon, 2 Apr 2001 19:55:47 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjbb07202 for ; Mon, 2 Apr 2001 19:55:46 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA29787 for mpls@uu.net; Mon, 2 Apr 2001 15:55:45 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjbb21320 for ; Mon, 2 Apr 2001 19:48:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjbb22531 for ; Mon, 2 Apr 2001 19:48:09 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkjbb15046 for ; Mon, 2 Apr 2001 19:48:09 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA27666; Mon, 2 Apr 2001 15:47:08 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAB09682; Mon, 2 Apr 2001 15:47:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20010402154746.01c508c8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Apr 2001 15:48:26 -0500 To: Shahram Davari , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: Re: mpls statistics Cc: Arun Viswanathan , Cheenu Srinivasan In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B81@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Is the MPLS statistics as defined in LSR-MIB mandatory or optional? A quick look at the MIB reveals that the performance group is indeed mandatory: MANDATORY-GROUPS { mplsInSegmentGroup, mplsOutSegmentGroup, mplsXCGroup, mplsInterfaceGroup, mplsPerfGroup, mplsSegmentDiscontinuityGroup } --Tom >Regards, >Shahram Davari >Systems Engineer >Product Research Group >PMC-Sierra, Inc. (Ottawa) >Phone: (613) 271-4018 >Fax: (613) 271-7007 > <> From owner-mpls@UU.NET Mon Apr 2 17:39:57 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02062 for ; Mon, 2 Apr 2001 17:39:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjbi25127; Mon, 2 Apr 2001 21:35:30 GMT Received: by mail-control.mail.uu.net id QQkjbi04907 for mpls-outgoing; Mon, 2 Apr 2001 21:34:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjbi04885 for ; Mon, 2 Apr 2001 21:34:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjbi20740 for ; Mon, 2 Apr 2001 21:34:14 GMT Received: from evita2.cs.fredonia.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: evita2.cs.fredonia.edu [141.238.30.9]) id QQkjbi08818 for ; Mon, 2 Apr 2001 21:34:14 GMT Received: from Zubairi.cs.fredonia.edu (zubairi.cs.fredonia.edu [141.238.30.211]) by evita2.cs.fredonia.edu (8.9.3/8.9.3) with ESMTP id RAA30168; Mon, 2 Apr 2001 17:20:48 -0400 Message-ID: <003301c0bbbb$28fe3240$d31eee8d@cs.fredonia.edu> From: "Junaid Ahmed Zubairi" To: "gopinathg" , "Jack Brennen" , References: <012801c0bba0$057c0830$6ee8a8c0@hclt.com> <3AC8C535.799FF933@marconi.com> <013a01c0bba9$4936a900$6ee8a8c0@hclt.com> Subject: Re: How to find a CR-LSP Label from a Label release Message with no optional parameters? Date: Mon, 2 Apr 2001 17:23:25 -0400 Organization: SUNY/Fredonia 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 For reading such messages, we need an acronym filter in our email clients. Such a filter would detect and expand acronyms to their full forms ;-) ----- Original Message ----- From: gopinathg To: Jack Brennen ; Sent: Monday, April 02, 2001 3:15 PM Subject: Re: How to find a CR-LSP Label from a Label release Message with no optional parameters? > Hi Jack > > Your opinion is correct in case of LDP but, If LSP's are established using > CR-LDP > then all CR-LSP Labels will have same FEC TLV ie FEC TLV with CR-LSP > Element. > > If it is the case then there will be no CR- LDP LSP's after receiving Label > Release. > > Thanks > gopinathg > > ----- Original Message ----- > From: Jack Brennen > To: > Sent: Tuesday, April 03, 2001 1:00 AM > Subject: Re: How to find a CR-LSP Label from a Label release Message with no > optional parameters? > > > > My opinion, for what it's worth: > > > > To quote RFC 3036: "If no Label TLV follows the FEC, all labels > > associated with the FEC are to be released..." > > > > If a Label Release message is received with a FEC consisting of > > a single CR-LSP FEC Element, and no Label TLV is present, it seems > > that it would be appropriate to release all Labels associated > > with such a FEC. That would generally mean releasing all CR-LSPs > > on the associated label space. > > > > Any dissenters? > > > > Jack Brennen > > > > gopinathg wrote: > > > > > > Hi > > > > > > As per the section 3.5 of draft-ietf-mpls-cr-ldp-05.txt says > > > > > > " The Label Release , Label Withdraw, and Label Abort Request Messages > > > are used as specified in [1]. These messages may also carry the > > > LSPID TLV " ( And it also refers to [1] ie RFC 3036) > > > > > > As from the above words " These messages may also carry the LSPID TLV " we > can > > > assume that LSPID TLV is not mandatory ( and hence optional). > > > > > > As per the section 3.5.11 of RFC 3036 Label TLV is optional . > > > > > > Now suppose if we have a label release message with no Label TLV, no LSPID > > > TLV(as we can assume both are optional from the above ) and FEC TLV with > > > CR-LSP FEC Element. > > > Now how will an LSR find the CR-LSP Label with the above information. ? > > > > > > Thanks In Advance > > > > > > gopinathg > From owner-mpls@UU.NET Mon Apr 2 19:46:13 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04281 for ; Mon, 2 Apr 2001 19:46:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjbq08632; Mon, 2 Apr 2001 23:43:28 GMT Received: by mail-control.mail.uu.net id QQkjbq16827 for mpls-outgoing; Mon, 2 Apr 2001 23:42:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjbq16822 for ; Mon, 2 Apr 2001 23:42:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjbq18046 for ; Mon, 2 Apr 2001 23:42:40 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjbq07993 for ; Mon, 2 Apr 2001 23:42:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA14063 for mpls@uu.net; Mon, 2 Apr 2001 19:42:38 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjbq16803 for ; Mon, 2 Apr 2001 23:41:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjbq20028 for ; Mon, 2 Apr 2001 23:40:17 GMT Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11]) id QQkjbq16970 for ; Mon, 2 Apr 2001 23:40:16 GMT Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id XAA00941; Mon, 2 Apr 2001 23:40:13 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 02 Apr 2001 23:40:09 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2FL420R1>; Mon, 2 Apr 2001 16:40:10 -0700 Message-ID: From: "Sharma, Prem" To: "'vikram_gupta@firstlinux.net'" , "'mpls@uu.net'" Subject: RE: Why no separate MPLS label/Shim Header when we use MPLS over ATM ?? Date: Mon, 2 Apr 2001 13:24:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Vikram, > -----Original Message----- > From: Vikram Gupta [mailto:vikram_gupta@firstlinux.net] > Subject: Why no separate MPLS label/Shim Header when we use MPLS over > ATM ?? > > > Hello Everybody, > > I have 2 questions about which I am pretty > confused....... > 1.Why is it that sometimes the MPLS label is embedded in > the header of the data link layer ( e.g in the ATM VCI/VPI and the > frame-relay DLCI ) and sometimes it is in the shim (between > the Layer-2 data- > link header and Layer-3 network layer header, as in Point > -to-Point PPP/Ethernet). > Why 2 different mechanisms ? The mechanisms are not different. The idea is to switch the packet at layer 2 itself rather than doing the route lookup at each and every hop. The support for carrying the labels is available from the underlying layers when the underlying layers happen to be ATM or frame relay [VPI/VCI in ATM and DLCI in Frame Relay] but the same support is not there when the underlying layer is PPP/Ethernet. So, shim header, which is placed between the layer 2 and layer 3 headers is actually a place holder for carrying the labels. [It serves some other purposes also.] > > 2.Would it be correct to say that when ATM is the data-link > layer ,then we have > No separate MPLS label/Shim Header to encapsulate the IP > Packet.The IP packet is directly encapsulated in ATM cells . > ..and the VPI/VCI > Present in the ATM Cell Header do the work of MPLS Labels. > This assumption is not correct. Even when the underlying layers are ATM or Frame Relay, the Shim Header is framed and placed before the layer3 header (and payload). Then the resultant is segmented and sent in individual cells/frames (after null encapsulation of RFC 2684). There could be multiple shim headers ahead of the layer 3 packet (label stacking) but the top label decides the value VPI/VCI in the ATM cell header and DLCI in frame relay header. > In such a case what would be the significance of MPLS > signaling protocols like LDP /RSVP which co-ordinate Label > Distribution and create LSPs ? The signalling protocols are used to obtain labels (VPI/VCI or DLCI) for the LSPs. > Would they co-ordinate which VPIs/VCIs would be used for > which LSP ? Yes. > But how could LDP possibly tell ATM > which VPI/VCI to use for which LSP ?? The label value in the topmost shim header dictates which VPI/VCI to use for the ATM cell header. [Normally, this happens at the ingress end of the LSP; Core routers just switch the cells.] > > Sorry if the questions sound stupid...since I am new to this field. > Thanks a lot, > Vik > No problem, that's fine. A lot of useful information is available on the web for MPLS. You could go though some whitepapers also. Prem > > _____________________________________________________________ > Want a new web-based email account ? ---> http://www.firstlinux.net > > From owner-mpls@UU.NET Mon Apr 2 21:44:48 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06951 for ; Mon, 2 Apr 2001 21:44:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjby06542; Tue, 3 Apr 2001 01:40:00 GMT Received: by mail-control.mail.uu.net id QQkjby27016 for mpls-outgoing; Tue, 3 Apr 2001 01:39:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjby27007 for ; Tue, 3 Apr 2001 01:39:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjby15687 for ; Tue, 3 Apr 2001 01:39:13 GMT Received: from yc.shu.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.120.127.220]) id QQkjby05880 for ; Tue, 3 Apr 2001 01:39:12 GMT Received: from xyx ([202.120.127.81]) by yc.shu.edu.cn (8.9.3+Sun/8.9.1) with SMTP id JAA15379 for ; Tue, 3 Apr 2001 09:41:45 +0800 (CST) Message-ID: <000e01c0bbdf$a32fe4e0$517f78ca@xyx> From: "Xu Yingxiao" To: "mpls" References: Subject: When the word of MPLS first come out Date: Tue, 3 Apr 2001 09:44:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA06951 I am investigating the background of MPLS, the earlier document I find is A Framework for Multiprotocol Label Switching in May 12, 1997. Is it the first appearence of the word MPLS? I think there should be some articles first arise the word MPLS in periodical or conference. From owner-mpls@UU.NET Mon Apr 2 23:02:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08968 for ; Mon, 2 Apr 2001 23:02:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjcd25211; Tue, 3 Apr 2001 02:58:43 GMT Received: by mail-control.mail.uu.net id QQkjcd18703 for mpls-outgoing; Tue, 3 Apr 2001 02:58:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjcd18698 for ; Tue, 3 Apr 2001 02:58:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjcd16509 for ; Tue, 3 Apr 2001 02:57:36 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjcd12832 for ; Tue, 3 Apr 2001 02:57:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA23061 for mpls@uu.net; Mon, 2 Apr 2001 22:57:34 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjcd18672 for ; Tue, 3 Apr 2001 02:56:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjcd17002 for ; Tue, 3 Apr 2001 02:55:27 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkjcd18194 for ; Tue, 3 Apr 2001 02:55:26 GMT Received: from lir.cisco.com (lir.cisco.com [161.44.172.144]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA08006; Mon, 2 Apr 2001 22:55:25 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id WAA08740; Mon, 2 Apr 2001 22:55:24 -0400 (EDT) Message-Id: <200104030255.WAA08740@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: "Xu Yingxiao" cc: "mpls" , swallow@cisco.com Subject: Re: When the word of MPLS first come out In-reply-to: Your message of "Tue, 03 Apr 2001 09:44:35 +0800." <000e01c0bbdf$a32fe4e0$517f78ca@xyx> Date: Mon, 02 Apr 2001 22:55:24 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk It first appeared in the MPLS charter. Circa Jan 97. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Apr 3 08:00:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27630 for ; Tue, 3 Apr 2001 08:00:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjdn01916; Tue, 3 Apr 2001 11:55:56 GMT Received: by mail-control.mail.uu.net id QQkjdn19933 for mpls-outgoing; Tue, 3 Apr 2001 11:55:23 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjdn19928 for ; Tue, 3 Apr 2001 11:55:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjdn09254 for ; Tue, 3 Apr 2001 11:54:07 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjdn00904 for ; Tue, 3 Apr 2001 11:54:07 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA11122 for mpls@uu.net; Tue, 3 Apr 2001 07:54:06 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjdn19894 for ; Tue, 3 Apr 2001 11:53:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjdn13132 for ; Tue, 3 Apr 2001 11:53:08 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkjdn24825 for ; Tue, 3 Apr 2001 11:53:08 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27279; Tue, 3 Apr 2001 07:53:06 -0400 (EDT) Message-Id: <200104031153.HAA27279@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-ftn-mib-01.txt Date: Tue, 03 Apr 2001 07:53:06 -0400 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 : Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base Using SMIv2 Author(s) : T. Nadeau, C. Srinivasan, A. Viswanathan Filename : draft-ietf-mpls-ftn-mib-01.txt Pages : 22 Date : 02-Apr-01 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 defining FEC-to-NHLFE mapping and corresponding actions for use with Multiprotocol Label Switching (MPLS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-01.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-ftn-mib-01.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-ftn-mib-01.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: <20010402124817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ftn-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ftn-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124817.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Apr 3 08:34:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28462 for ; Tue, 3 Apr 2001 08:34:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjdq01626; Tue, 3 Apr 2001 12:30:12 GMT Received: by mail-control.mail.uu.net id QQkjdp08950 for mpls-outgoing; Tue, 3 Apr 2001 12:29:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjdp08935 for ; Tue, 3 Apr 2001 12:29:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjdp27250 for ; Tue, 3 Apr 2001 12:29:24 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjdp00764 for ; Tue, 3 Apr 2001 12:29:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA13332 for mpls@uu.net; Tue, 3 Apr 2001 08:29:23 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjdp08890 for ; Tue, 3 Apr 2001 12:28:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjdp26331 for ; Tue, 3 Apr 2001 12:27:26 GMT Received: from sj-msg-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10]) id QQkjdp28919 for ; Tue, 3 Apr 2001 12:27:26 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id FAA00537; Tue, 3 Apr 2001 05:26:57 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f33CQpi23057; Tue, 3 Apr 2001 05:26:52 -0700 (PDT) Message-ID: <3AC9C132.451D984B@cisco.com> Date: Tue, 03 Apr 2001 05:25:22 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Neil, > > If one questions the use of local protection all together > > please specify > > how else you will achive the same results of even less then 1 > > sec end to > > end traffic disruption with end to end protection under both > > link & node > > failures for the TE- LSP ? > > NH=> Fair point Robert.....but it still leaves me wondering: > 1 Why do we need such fast action......voice surely does not need few > 10s ms restoration, 1-3s would be fine I feel sure (for the relatively rare > case of failure......unless, perhaps, one expects such failures to occur on > a very frequent basis)? > BTW- I suspect the biggest source of 'disruptions' will be planned-works by > operators at L1, ie pre-meditiated re-routing of traffic.....so some care > should be taken that such actions don't invoke unecessary actions in higher > layers. Well 10s of ms is just that with local link protection we get it for free. It would be quite artificial to try to slow this down :). For node protection sure one can reduce the detection frequency to make it slower. I think vendors will support knob to do this if one desire. > 2 Where are the failures referenced specified? Have Cisco their own > specifications for this? We would really like to see these specified in > some standard manner. I understand but I don't have any pointer to the formal detailed specification of failure cases which would be addressed by local protection. R. From owner-mpls@UU.NET Tue Apr 3 13:21:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08941 for ; Tue, 3 Apr 2001 13:21:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjej13185; Tue, 3 Apr 2001 17:16:58 GMT Received: by mail-control.mail.uu.net id QQkjei23103 for mpls-outgoing; Tue, 3 Apr 2001 17:14:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjei23090 for ; Tue, 3 Apr 2001 17:14:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjei05643 for ; Tue, 3 Apr 2001 17:10:52 GMT From: Aditya@in.huawei.com Received: from mail.in.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQkjei25166 for ; Tue, 3 Apr 2001 17:10:25 GMT Received: by mail.in.huawei.com with Internet Mail Service (5.5.2650.21) id <2AAL877N>; Tue, 3 Apr 2001 22:02:52 +0500 Message-ID: <70EB682332F4D41187D6000629AE2C651FF687@mail.in.huawei.com> To: mpls@UU.NET Subject: sunscribe Date: Tue, 3 Apr 2001 22:02:49 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BC5F.EB167610" 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_01C0BC5F.EB167610 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01C0BC5F.EB167610 Content-Type: text/html; charset="iso-8859-1" sunscribe ------_=_NextPart_001_01C0BC5F.EB167610-- From owner-mpls@UU.NET Tue Apr 3 15:14:55 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13850 for ; Tue, 3 Apr 2001 15:14:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjeq00925; Tue, 3 Apr 2001 19:10:47 GMT Received: by mail-control.mail.uu.net id QQkjeq04658 for mpls-outgoing; Tue, 3 Apr 2001 19:10:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjeq04651 for ; Tue, 3 Apr 2001 19:10:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjeq11274 for ; Tue, 3 Apr 2001 19:08:25 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjeq25968 for ; Tue, 3 Apr 2001 19:08:23 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA88665; Tue, 3 Apr 2001 15:06:44 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104031906.PAA88665@workhorse.fictitious.org> To: George Swallow , af@dataconnection.com, pjb@dataconnection.com, philipma@nortelnetworks.com, eric.gray@sandburst.com cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on LDP Fault Tollerance In-reply-to: Your message of "Wed, 28 Mar 2001 18:00:03 EST." <200103282300.SAA15343@pilgrim.cisco.com> Date: Tue, 03 Apr 2001 15:06:44 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200103282300.SAA15343@pilgrim.cisco.com>, George Swallow writes: > This message commences a workgroup last call on LDP Fault Tollerance, > . The last call closes April 11, 12 pm > GMT. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 Adrian, et al, I would like to make a comment and leave it up to the authors discression as to whether to incorporate any change into the document. There appears to be a school of thought where it is deemed beneficial to keep forwarding state intact in only very limited cases such as midnight controlled reload of routers for purposes such as software upgrade. This case can be even further limited to maintaining forwarding state only if network topology has not changed while adjacency is unavailable. The justification for retaining forwarding state is to eliminate unnecessary forwarding state churn that may cause transient forwarding disruptions. The justification for not retaining forwarding state if topology changes is to prevent persistent forwarding problems that could occur if loops or black holes formed as a result of inconsistent forwarding state on a router in which the means to synchronize state was unavailable. Stated more simply -- Its nice to avoid dumping a few packets on the floor but if topology changes it may be better to endure some transient route churn than to endure inconsistent routing state that lasts for the duration of a router reloading new software and could dump a whole lot more packets on the floor than what the transient would cause. If changes are made, one possible addition would be to add a section 4.4.2: 4.4.2 Optional Reconnect Expire on Topology Change If topology change is detected through some means outside LDP such as change in an Interior Gateway Protocol Link State Database (IGP-LSDB) it may be desireable to prematurely expire the FT Reconnection Timer. An option SHOULD be provided to enable such a feature on a per peer basis. I leave it entirely up to the authors as to whether they would like to add this text. I would prefer if something to this effect were added unless there is objection to this addition on the list. A vendor could always include such a feature and make it optional and disabled by default regardless of whether it is stated in the document so there is little sense of urgency. Curtis From owner-mpls@UU.NET Tue Apr 3 15:22:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14108 for ; Tue, 3 Apr 2001 15:22:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjer07085; Tue, 3 Apr 2001 19:18:05 GMT Received: by mail-control.mail.uu.net id QQkjer05786 for mpls-outgoing; Tue, 3 Apr 2001 19:17:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjer05767 for ; Tue, 3 Apr 2001 19:17:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjeq20668 for ; Tue, 3 Apr 2001 19:14:13 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjeq07504 for ; Tue, 3 Apr 2001 19:14:10 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA88707; Tue, 3 Apr 2001 15:14:05 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104031914.PAA88707@workhorse.fictitious.org> To: George Swallow cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels In-reply-to: Your message of "Wed, 28 Mar 2001 18:03:30 EST." <200103282303.SAA15707@pilgrim.cisco.com> Date: Tue, 03 Apr 2001 15:14:05 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200103282303.SAA15707@pilgrim.cisco.com>, George Swallow writes: > This message commences a workgroup last call on "RSVP Label Allocation > for Backup Tunnels" . This > draft is informational. The last call closes April 11, 12 PM GMT. > > ...George + Cisco Systems may have intellectual property rights claimed in regard + to some or all of the specification contained in this document. George, Can you be more specific. Do you or don't you have intellectual property rights claims on this. This is open ended. If you aren't sure, then I suggest that the WG hold the document until you can find out if you do. If you do, I suggest that you be more specific in stating what they are and under what terms usage is granted to others. Curtis From owner-mpls@UU.NET Tue Apr 3 15:31:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14551 for ; Tue, 3 Apr 2001 15:31:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjer19587; Tue, 3 Apr 2001 19:27:47 GMT Received: by mail-control.mail.uu.net id QQkjer06340 for mpls-outgoing; Tue, 3 Apr 2001 19:27:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjer06330 for ; Tue, 3 Apr 2001 19:27:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjer23923 for ; Tue, 3 Apr 2001 19:25:15 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjer27863 for ; Tue, 3 Apr 2001 19:25:11 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA88744; Tue, 3 Apr 2001 15:24:54 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104031924.PAA88744@workhorse.fictitious.org> To: neil.2.harrison@bt.com cc: swallow@cisco.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels In-reply-to: Your message of "Thu, 29 Mar 2001 09:45:07 +0100." Date: Tue, 03 Apr 2001 15:24:54 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , nei l.2.harrison@bt.com writes: > Some comments: > > 1 Where did the requirements in section 1 come (and is there a > reference?): > "In order to meet the needs of realtime applications such as Voice > over IP, it is highly desirable to be able to repair LSP tunnels in > 10s of milliseconds. "? > > I would suggest voice would be one application where 1-2s of outage was > tolerable, cf someone not answering a question immediately, but instead > thinking for a short period of time before answering. In general I do not > believe customers would close down a voice call for an outage of the order > of 10ms, but they might on the order >3s. You telco guys can never make up you minds how touchy this SONET stuff actually is. :-) What I've heard indirectly is that the per NE budget in sonet is 50 msec and that some sonet gear is fairly hard coded to drop connections if more than on the order of 100 msec of signal loss is observed. Maybe that's just a nasty rumor going around. :-) > 2 At the top of page 5 in section 2 it says: > " When a failure occurs and the backup comes into use,......" > > All user-plane (and indeed control-plane) failure modes must be identified > and specified in terms of entry/exit criteria and consequent actions before > we can meaningfully proceed with this draft. I see no reason to expand the scope of this document. > For the user-plane, the failure modes which must be considered/defined are: > - simple below MPLS fabric server layer connectivity breaks; > - simple within MPLS fabric connectivity breaks (at or below the LSP > level considered); > - swapped LSPs, ie instead of A1->A2 and B1->B2 a defect creates > A1->B2 and B1->A2; > - mismerged LSPs, eg instead of A1->A2 and B1->B2 a defect creates > A1->A2 and A1+B1->B2 say (though there are potentially several variations on > this). Link defects are covered. IE: the link is POS over linear SONET and SONET framing has detected that the link is no longer useable. If a label table was incorrect on this router and it was detectable, the solution would not be to reroute it would be to fix the table entry. > For the latter 2 defects it will be vital to suppress the traffic due to > potential security/censorship/misbilling implications for carriers and > customers. Speaking as a carrier these issues are requirements that must be > addressed. This is not optional, and rigorous definitions must be provided > (or referenced). > > Neil Harrison > BT/Ignite/CTO/Network Architecture > Tel +44 1 604 820 724 > mail neil.2.harrison@bt.com It would almost appear to me that you are simply interested in expanding the scope of this document to require your OAM document so that it could detect failures that it currently isn't intended to address. Nice try. Curtis From owner-mpls@UU.NET Tue Apr 3 15:49:19 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14971 for ; Tue, 3 Apr 2001 15:49:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjet09702; Tue, 3 Apr 2001 19:45:29 GMT Received: by mail-control.mail.uu.net id QQkjes07395 for mpls-outgoing; Tue, 3 Apr 2001 19:44:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjes07371 for ; Tue, 3 Apr 2001 19:44:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjes20019 for ; Tue, 3 Apr 2001 19:41:56 GMT Received: from spomail01.attla.corp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.netstream.com.br [200.192.1.34]) id QQkjes06695 for ; Tue, 3 Apr 2001 19:41:55 GMT Received: from nsrjo4.attla.corp ([10.21.10.6]) by spomail01.attla.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10) id HNANWFB6; Tue, 3 Apr 2001 16:43:41 -0300 Received: by nsrjo4 with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Apr 2001 16:41:16 -0300 Message-ID: From: "Loureiro, Rodrigo" To: "'mpls@uu.net'" Subject: VPN/MPLS question Date: Tue, 3 Apr 2001 16:41:08 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 PAA14971 Hi all, Thinking about use EBGP sessions between the PE-CE connection, in order to insert customer´s routing information into the VPN routing table and provide layer 3 redundancy for the customer´s site using BGP, a scalability problem arises: Once BGP has a loop avoidance mechanism based on the as-path vector, and considering that i will not summarize the prefixes in the PEs, every site participating in the VPN (peer) should have a different private autonomous system. Once i have only 1014 private as-numbes, this could represent a scalability problem, for example, if i think about a big extranet client. Is it correct? Regards, -- Rodrigo Loureiro Systems Engineer - AT&T LA Tel: 55-11-3365-1670/9965-9676 ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ------------------------------------------ The Art of Strategy: "Those who are victorious plan effectively and change decisively. They are like a great river that maintains its course but adjusts its flow... They have form but are formless. They are skilled in both planning and adapting and need not fear the result of a thousand battles; for they win in advance, defeating those that have already lost." - Sun Tzu, Chinese Warrior and Philosopher, 100 B.C. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ------------------------------------------ From owner-mpls@UU.NET Tue Apr 3 16:13:38 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15519 for ; Tue, 3 Apr 2001 16:13:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjeu13450; Tue, 3 Apr 2001 20:09:45 GMT Received: by mail-control.mail.uu.net id QQkjeu26174 for mpls-outgoing; Tue, 3 Apr 2001 20:09:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjeu26146 for ; Tue, 3 Apr 2001 20:08:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjeu26615 for ; Tue, 3 Apr 2001 20:07:06 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjeu06667 for ; Tue, 3 Apr 2001 20:06:51 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA88847; Tue, 3 Apr 2001 16:06:03 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104032006.QAA88847@workhorse.fictitious.org> To: Francis Arts cc: rgoguen@cisco.com, swallow@cisco.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Comments to In-reply-to: Your message of "Fri, 30 Mar 2001 13:53:59 +0200." <3AC473D7.7A50CB85@alcatel.be> Date: Tue, 03 Apr 2001 16:06:03 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3AC473D7.7A50CB85@alcatel.be>, Francis Arts writes: > > Hello Rob, George, > > Please find included my comments to your > draft. > > Regards, > > Francis. Francis, Responses inline. This is my understanding of the draft. George can correct me. Curtis > 1) PHP vs global label space. > > The text of section 2 states the following: > "The penultimate hop of the backup tunnel would > pop the label for the backup tunnel, revealing the label which M > expects." > > However, when reading your proposal, the use of PHP does not seem > mandatory, even when a global space is used in the merge node M. > > Please add an explicit statement to the text whether or not PHP is > mandatory in the global label space case. It is not manditory. If the egress is capable of doing a POP and then looking at the next label, its allowed to do that. > 2) Bypass tunnel. > > The text of section 2 states the following: > "When a failure occurs and the backup comes into use, a means of > maintaining the RSVP state is required. In this simple case the Path > > messages can simply be sent via the backup link or tunnel as the case > > may be." > > Refreshing RSVP messages down a bypass tunnel is not described in any > RFC or ID (also not in draft-ietf-mpls-rsvp-lsp-tunnel-08). Therefore, > the mechanism needs to be explained in your draft. e.g. Which value > should be used for the PHOP object when refreshing the PATH message down > the bypass tunnel? > > Note: You could consider reusing the signalling mechanisms Kireeti > Kompella has defined for LSPs used as FAs. Can we consider that to be out of scope? That way it doesn't have to be defined in both the hierarchical draft and in this one. As long as there is a defined way to do this. > 4) p.6, section 2, extended tunnel id. > > Is it for the purpose of your draft allowed to set the extended tunnel > id to all 0s as well as setting it to an IPv4 address of the ingress > LSR? While you are allowed to set this to all 0s, I don't know any reason to set to all 0s. Unlike some people I don't assume that all backup tunnels will have a zero bandwidth reservation and therefore if you want make-before-break to work, all 0s would be a poor choice. > 5) p.6, section 2, last but one paragraph. > > The text states that 'it is thus necessary to properly associate the > LSP_ID of a backup tunnel with the LSP_ID of the tunnel being backed > up'. > > However, from the text (p.6, section 2, last but one paragraph) it does > not seem to be necessary to copy the LSP_ID since the 'other LSP' > mentioned in the text, has another 'IPv4 tunnel sender address' in the > SENDER_TEMPLATE. A drawing showing an example, would be useful. I don't understand the reason for this restriction and how one to many backup tunnels would be accomodated if the LSP_ID is copied. George? Curtis From owner-mpls@UU.NET Tue Apr 3 16:31:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15920 for ; Tue, 3 Apr 2001 16:31:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjev05681; Tue, 3 Apr 2001 20:27:04 GMT Received: by mail-control.mail.uu.net id QQkjev27642 for mpls-outgoing; Tue, 3 Apr 2001 20:26:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjev27633 for ; Tue, 3 Apr 2001 20:26:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjev21593 for ; Tue, 3 Apr 2001 20:26:09 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjev04303 for ; Tue, 3 Apr 2001 20:26:06 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA88949; Tue, 3 Apr 2001 16:25:40 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104032025.QAA88949@workhorse.fictitious.org> To: Bora Akyol cc: George Swallow , mpls@UU.NET, Kireeti Kompella , ccamp@ops.ietf.org Reply-To: curtis@avici.com Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels In-reply-to: Your message of "Fri, 30 Mar 2001 12:53:48 PST." <200103302053.f2UKrmd00747@localhost.pluris.com> Date: Tue, 03 Apr 2001 16:25:40 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200103302053.f2UKrmd00747@localhost.pluris.com>, Bora Akyol writes: > As far as I understand this draft outlines a mechanism for fast reroute > in MPLS networks. With this in mind, shouldn't we delay the last call on > this draft until ther **other** fast reroute related drafts in CCAMP run > to completion? > > Regards > > Bora Bora, This draft seems to provide only a means to reduce the number of labels required to provide backup by allowing shared backup tunnels. It is applicable to any technique that involves local protection as opposed to ingress protection. It does not preclude doing ingress protection. I don't understand your objection. Curtis > On Wednesday, March 28, 2001, at 03:03 PM, George Swallow wrote: > > > This message commences a workgroup last call on "RSVP Label Allocation > > for Backup Tunnels" . This > > draft is informational. The last call closes April 11, 12 PM GMT. > > > > ...George > > > > ====================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Apr 3 16:55:51 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16748 for ; Tue, 3 Apr 2001 16:55:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjex18207; Tue, 3 Apr 2001 20:51:58 GMT Received: by mail-control.mail.uu.net id QQkjex29837 for mpls-outgoing; Tue, 3 Apr 2001 20:51:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjex29827 for ; Tue, 3 Apr 2001 20:51:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjex03724 for ; Tue, 3 Apr 2001 20:49:46 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkjex04418 for ; Tue, 3 Apr 2001 20:49:45 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 4B8D094006; Tue, 3 Apr 2001 16:49:45 -0400 (EDT) Message-ID: <3ACA3769.1E1C006F@sandburst.com> Date: Tue, 03 Apr 2001 16:49:45 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com Cc: George Swallow , Adrian Farrel , pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET Subject: Re: Last Call on LDP Fault Tollerance References: <200104031906.PAA88665@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, In general, I found this proposal not unreasonable. On reflection however, I have two relatively minor issues with it - each having an additive effect making the resulting concern a little less minor. The first issue is actually a two parter. Once you start adding knobs for the user to configure when the protocol bumps this way and when it bumps that way you do two things: 1) you make the implementing and testing more complex and 2) you open the door to suggestions for similar knobs. The second is that we currently have no experiential evidence to indicate that implementers will get this wrong and deployers will get it right. I believe we should wait for such evidence to start coming in before adding an optional knob for optional behaviors based on various permutations of the presence, or absence of other optional knobs and behaviors. I believe that the knob you are asking for will actually only complicate implementation and testing for those people who are trying to get the implementation right. In other words, a correct implementation should internally determine on its own whether or not the topology information on which LDP bases LSP forwarding is suspect. Adding a knob to have such an implementation either not perform the topology sanity check - or ignore the results if it does (by assuming insanity) will introduce additional test cases. I also suspect that you may be understating the advantages of maintaining session context. Consider the impact to the network if LSPs are dropped lightly and these LSP are in turn being used to carry (stacked) LSPs. -- Eric Gray You wrote: > In message <200103282300.SAA15343@pilgrim.cisco.com>, George Swallow writes: > > This message commences a workgroup last call on LDP Fault Tollerance, > > . The last call closes April 11, 12 pm > > GMT. > > > > ...George > > > > ====================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > Adrian, et al, > > I would like to make a comment and leave it up to the authors > discression as to whether to incorporate any change into the document. > > There appears to be a school of thought where it is deemed beneficial > to keep forwarding state intact in only very limited cases such as > midnight controlled reload of routers for purposes such as software > upgrade. This case can be even further limited to maintaining > forwarding state only if network topology has not changed while > adjacency is unavailable. > > The justification for retaining forwarding state is to eliminate > unnecessary forwarding state churn that may cause transient forwarding > disruptions. The justification for not retaining forwarding state if > topology changes is to prevent persistent forwarding problems that > could occur if loops or black holes formed as a result of inconsistent > forwarding state on a router in which the means to synchronize state > was unavailable. > > Stated more simply -- Its nice to avoid dumping a few packets on the > floor but if topology changes it may be better to endure some > transient route churn than to endure inconsistent routing state that > lasts for the duration of a router reloading new software and could > dump a whole lot more packets on the floor than what the transient > would cause. > > If changes are made, one possible addition would be to add a section > 4.4.2: > > 4.4.2 Optional Reconnect Expire on Topology Change > > this is needed from the authors> > > If topology change is detected through some means outside LDP such > as change in an Interior Gateway Protocol Link State Database > (IGP-LSDB) it may be desireable to prematurely expire the FT > Reconnection Timer. An option SHOULD be provided to enable such a > feature on a per peer basis. > > I leave it entirely up to the authors as to whether they would like to > add this text. I would prefer if something to this effect were added > unless there is objection to this addition on the list. A vendor > could always include such a feature and make it optional and disabled > by default regardless of whether it is stated in the document so there > is little sense of urgency. > > Curtis From owner-mpls@UU.NET Tue Apr 3 17:02:43 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17013 for ; Tue, 3 Apr 2001 17:02:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjey22760; Tue, 3 Apr 2001 21:00:09 GMT Received: by mail-control.mail.uu.net id QQkjex00201 for mpls-outgoing; Tue, 3 Apr 2001 20:59:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjex00193 for ; Tue, 3 Apr 2001 20:59:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjex24741 for ; Tue, 3 Apr 2001 20:58:49 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjex19492 for ; Tue, 3 Apr 2001 20:58:47 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA89148; Tue, 3 Apr 2001 16:58:14 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104032058.QAA89148@workhorse.fictitious.org> To: "Dave Danenberg" cc: neil.2.harrison@bt.com, giles@goneto.net, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels In-reply-to: Your message of "Mon, 02 Apr 2001 09:27:49 EDT." <0E2DFCE7E586904DA0F583CB5EAD73CC0312F9@WATERTOWN.litchfieldcomm.com> Date: Tue, 03 Apr 2001 16:58:14 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <0E2DFCE7E586904DA0F583CB5EAD73CC0312F9@WATERTOWN.litchfieldcomm.com >, "Dave Danenberg" writes: > Neil/Giles, > > I've been watching your exchange with interest. Especially when > discussing > whether MPLS signaling can be used reliably for data-plane failure > detection. > So let me just throw this into the discussion... Won't most MPLS > deployments > support statically configured MPLS connections? No. In fact, none so far AFAIK. Curtis From owner-mpls@UU.NET Tue Apr 3 17:08:07 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17111 for ; Tue, 3 Apr 2001 17:08:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjey04920; Tue, 3 Apr 2001 21:05:45 GMT Received: by mail-control.mail.uu.net id QQkjey16246 for mpls-outgoing; Tue, 3 Apr 2001 21:05:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjey14453 for ; Tue, 3 Apr 2001 21:04:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjey01477 for ; Tue, 3 Apr 2001 21:04:45 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjey03778 for ; Tue, 3 Apr 2001 21:04:44 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA89223; Tue, 3 Apr 2001 17:04:35 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104032104.RAA89223@workhorse.fictitious.org> To: "Xu Yingxiao" cc: "mpls" Reply-To: curtis@avici.com Subject: Re: When the word of MPLS first come out In-reply-to: Your message of "Tue, 03 Apr 2001 09:44:35 +0800." <000e01c0bbdf$a32fe4e0$517f78ca@xyx> Date: Tue, 03 Apr 2001 17:04:35 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <000e01c0bbdf$a32fe4e0$517f78ca@xyx>, "Xu Yingxiao" writes: > I am investigating the background of MPLS, the earlier document I find is A > Framework for Multiprotocol Label Switching > in May 12, 1997. > > Is it the first appearence of the word MPLS? I think there should be some art > icles first arise the word MPLS in periodical or conference. Try the mailing list archives for the intserv WG. Discussions of the predicessors to MPLS occurred on that list. Curtis From owner-mpls@UU.NET Tue Apr 3 17:28:51 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17574 for ; Tue, 3 Apr 2001 17:28:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjez15727; Tue, 3 Apr 2001 21:26:02 GMT Received: by mail-control.mail.uu.net id QQkjez18523 for mpls-outgoing; Tue, 3 Apr 2001 21:25:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjez18517 for ; Tue, 3 Apr 2001 21:25:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjez21153 for ; Tue, 3 Apr 2001 21:24:49 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjez04364 for ; Tue, 3 Apr 2001 21:24:48 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA89481; Tue, 3 Apr 2001 17:16:07 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104032116.RAA89481@workhorse.fictitious.org> To: Eric Gray cc: curtis@avici.com, George Swallow , Adrian Farrel , pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on LDP Fault Tollerance In-reply-to: Your message of "Tue, 03 Apr 2001 16:49:45 EDT." <3ACA3769.1E1C006F@sandburst.com> Date: Tue, 03 Apr 2001 17:16:07 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3ACA3769.1E1C006F@sandburst.com>, Eric Gray writes: > > I also suspect that you may be understating the advantages > of maintaining session context. Consider the impact to the > network if LSPs are dropped lightly and these LSP are in turn > being used to carry (stacked) LSPs. > > -- > Eric Gray You wouldn't be using LDP in that case. ;-) Curtis From owner-mpls@UU.NET Tue Apr 3 17:38:38 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17943 for ; Tue, 3 Apr 2001 17:38:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfa26312; Tue, 3 Apr 2001 21:35:55 GMT Received: by mail-control.mail.uu.net id QQkjfa19121 for mpls-outgoing; Tue, 3 Apr 2001 21:35:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjfa19084 for ; Tue, 3 Apr 2001 21:35:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjfa10270 for ; Tue, 3 Apr 2001 21:33:32 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkjfa22457 for ; Tue, 3 Apr 2001 21:33:32 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id C4EBE9400A; Tue, 3 Apr 2001 17:33:31 -0400 (EDT) Message-ID: <3ACA41AB.2A3ACB59@sandburst.com> Date: Tue, 03 Apr 2001 17:33:31 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com Cc: George Swallow , Adrian Farrel , pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET Subject: Re: Last Call on LDP Fault Tollerance References: <200104032116.RAA89481@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, As I understand it, LDP is the preferred protocol for use with MPLS BGP when BGP peers are not adjacent with respect to an MPLS domain. Suppose that MPLS BGP is used to establish many VPN services which are possibly being used to provide a label switching service to enterprise customers. For that matter, suppose that LDP is being used to signal and maintain VPN technology's LSPs. You wrote: > In message <3ACA3769.1E1C006F@sandburst.com>, Eric Gray writes: > > > > I also suspect that you may be understating the advantages > > of maintaining session context. Consider the impact to the > > network if LSPs are dropped lightly and these LSP are in turn > > being used to carry (stacked) LSPs. > > > > -- > > Eric Gray > > You wouldn't be using LDP in that case. ;-) > > Curtis From owner-mpls@UU.NET Tue Apr 3 17:56:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18258 for ; Tue, 3 Apr 2001 17:56:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfb09148; Tue, 3 Apr 2001 21:54:10 GMT Received: by mail-control.mail.uu.net id QQkjfb20602 for mpls-outgoing; Tue, 3 Apr 2001 21:53:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjfb20592 for ; Tue, 3 Apr 2001 21:53:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjfb16946 for ; Tue, 3 Apr 2001 21:53:06 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjfb08202 for ; Tue, 3 Apr 2001 21:53:06 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA00504 for mpls@uu.net; Tue, 3 Apr 2001 17:53:05 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjfb20541 for ; Tue, 3 Apr 2001 21:52:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjfb15187 for ; Tue, 3 Apr 2001 21:51:21 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkjfb27416 for ; Tue, 3 Apr 2001 21:51:20 GMT Received: from localhost (swallow@localhost) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA26300; Tue, 3 Apr 2001 17:50:31 -0400 (EDT) Message-Id: <200104032150.RAA26300@pilgrim.cisco.com> To: curtis@avici.com cc: Francis Arts , rgoguen@cisco.com, swallow@cisco.com, mpls@UU.NET, swallow@cisco.com Subject: Re: Comments to In-reply-to: Your message of "Tue, 03 Apr 2001 16:06:03 EDT." <200104032006.QAA88847@workhorse.fictitious.org> Date: Tue, 03 Apr 2001 17:50:31 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Francis, Curtis - > In message <3AC473D7.7A50CB85@alcatel.be>, Francis Arts writes: > > > > Hello Rob, George, > > > > Please find included my comments to your > > draft. > > > > Regards, > > > > Francis. > > > Francis, > > Responses inline. This is my understanding of the draft. George can > correct me. > > Curtis > > > > > 1) PHP vs global label space. > > > > The text of section 2 states the following: > > "The penultimate hop of the backup tunnel would > > pop the label for the backup tunnel, revealing the label which M > > expects." > > > > However, when reading your proposal, the use of PHP does not seem > > mandatory, even when a global space is used in the merge node M. > > > > Please add an explicit statement to the text whether or not PHP is > > mandatory in the global label space case. > > > It is not manditory. If the egress is capable of doing a POP and then > looking at the next label, its allowed to do that. Correct. The text that you are questioning was only meant as an example. I'll add some text to make that clearer. > > 2) Bypass tunnel. > > > > The text of section 2 states the following: > > "When a failure occurs and the backup comes into use, a means of > > maintaining the RSVP state is required. In this simple case the Path > > > > messages can simply be sent via the backup link or tunnel as the case > > > > may be." > > > > Refreshing RSVP messages down a bypass tunnel is not described in any > > RFC or ID (also not in draft-ietf-mpls-rsvp-lsp-tunnel-08). Therefore, > > the mechanism needs to be explained in your draft. e.g. Which value > > should be used for the PHOP object when refreshing the PATH message down > > the bypass tunnel? > > > > Note: You could consider reusing the signalling mechanisms Kireeti > > Kompella has defined for LSPs used as FAs. > > Can we consider that to be out of scope? That way it doesn't have to > be defined in both the hierarchical draft and in this one. As long as > there is a defined way to do this. I think the FA draft is beyond the scope. Some words about PHOP are in order. I'll add some. The important thing is that the PLR node be able to associate the RESV message with the Path message it sent down the tunnel. How the PLR does this is a local matter. One thing to note is that the IP address of the orginal outbound interface could in some cases become unreachable if that link goes down. So some care needs to be used here. I would personnally recommend using the same IP address that you use in the Sender Object, but there's nothing mandatory about that. > > 4) p.6, section 2, extended tunnel id. > > > > Is it for the purpose of your draft allowed to set the extended tunnel > > id to all 0s as well as setting it to an IPv4 address of the ingress > > LSR? > > > While you are allowed to set this to all 0s, I don't know any reason > to set to all 0s. Unlike some people I don't assume that all backup > tunnels will have a zero bandwidth reservation and therefore if you > want make-before-break to work, all 0s would be a poor choice. If you're doing SE reservations on the tunnel and the backup tunnel, then the scope of the sharing is limited by RSVP to senders to the same session. So, if you want the reservations shared then you need to use the identical Session object. > > 5) p.6, section 2, last but one paragraph. > > > > The text states that 'it is thus necessary to properly associate the > > LSP_ID of a backup tunnel with the LSP_ID of the tunnel being backed > > up'. > > > > However, from the text (p.6, section 2, last but one paragraph) it does > > not seem to be necessary to copy the LSP_ID since the 'other LSP' > > mentioned in the text, has another 'IPv4 tunnel sender address' in the > > SENDER_TEMPLATE. A drawing showing an example, would be useful. > > I don't understand the reason for this restriction I'll remove the text. It's dangling text that has to do with some other stuff I took out of the draft before it was ever published (including draft-00). The idea was to allow downstream nodes to be able to associate which back up path state went with which primary state during a reroute operation. But that isn't all that useful so I removed it. >and how one to many > backup tunnels would be accomodated if the LSP_ID is copied. George? I don't understand the question. The Session objects differentiate the many backup tunnels. It doesn't matter if some of those backup tunnels happen to have identical sender objects. > Curtis ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Apr 3 19:45:26 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20402 for ; Tue, 3 Apr 2001 19:45:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfi07551; Tue, 3 Apr 2001 23:42:48 GMT Received: by mail-control.mail.uu.net id QQkjfi01825 for mpls-outgoing; Tue, 3 Apr 2001 23:42:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjfi01808 for ; Tue, 3 Apr 2001 23:41:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjfi25221 for ; Tue, 3 Apr 2001 23:41:26 GMT Received: from smtp1.phx.gblx.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQkjfi06307 for ; Tue, 3 Apr 2001 23:41:25 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id f33NfIP01157; Tue, 3 Apr 2001 16:41:18 -0700 (MST) Received: from UNKNOWN(64.208.25.102), claiming to be "davevaio" via SMTP by smtp1, id smtpdAAAonaOoc; Tue Apr 3 16:41:10 2001 From: "Dave Cooper" To: "Dave Danenberg" , , Cc: , "Brook Bailey" Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Tue, 3 Apr 2001 15:19:10 -0700 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: <0E2DFCE7E586904DA0F583CB5EAD73CC0312F9@WATERTOWN.litchfieldcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > > Neil/Giles, > > I've been watching your exchange with interest. Especially when > discussing > whether MPLS signaling can be used reliably for data-plane failure > detection. > So let me just throw this into the discussion... Won't most MPLS > deployments > support statically configured MPLS connections? If so, then signaling > would > not be there - even if it could reliably detect data-plane failures. Nope. In fact, the wide scale use of statically defined MPLS connections sends shivers down my spine. But on the topic of MPLS OAM, it has its merits -- especially when software failures (whereby the control plane does not detect failures in the data plane) seem to continue to be the bane of most MPLS implementations. I've been preaching this directly to vendors for quite some time and despite what tweaks we put into the control plane for dealing with failure (whether its fast reroute, normal reroute, whatever), its still doesnt fix this constant problem. Customers are tired of hearing the vendor bug excuse. dave > Seems > like a good argument for MPLS OAM. Also, (being in the chips and systems > business) I agree with Neil and Shahram that MPLS OAM implementation is > not > complex. > > --Dave > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > neil.2.harrison@bt.com > Sent: Monday, April 02, 2001 5:19 AM > To: giles@goneto.net > Cc: mpls@UU.NET > Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels > > > Giles Heron [mailto:giles@goneto.net] wrote 02 April 2001 06:15 > > Can you please give us some examples of situations where the control > > plane will not detect the user plane defect? (other than the buggy > > software case below of course.) > NH=> Any situation where the user and control-plane do not go through > *exactly* the same routing/processing. In GMPLS-type situation this is > a > given, in MPLS this is less obvious I agree (except for those hopefully > rare > SW/HW failures modes).....especially for base LDP. However, as a > general > principle one should aim to make user and control-plane defect handing > independent so as to allow flexibility of user and control-plane network > topology design (they are quite distinct in principle, and the > control-plane > topology has to takes its design cues from the duct for rigorous > resilience > design). > > > > > > And yes, of course I have a requirement to offer SLAs to customers. > > Originally I had thought that some sort of MPLS OAM might be > > useful for > > this. Having read your draft, having seen the complexity involved, > > having figured out that all it seems to detect that cannot be detected > > by other means is mismerged/swapped LSPs, and having > > discovered that it > > doesn't support merging LSPs > NH=> Lots of things don't support merging....nor is merging always such > a > wonderful thing. > , I have come to the conclusion > > (rightly or > > wrongly) that I'm better off without. > NH=> I can understand your view .....especially if all you ever want to > use > MPLS for is in a LDP-type of deployment. But I am still left with these > unanswered questions for a path-oriented view/use of LSPs: > - where are the definitions of defects specified? > Note - I know some defects should be rare.......but we should aim to be > rigorous in specification at the outset and we need to weight the 'prob > of > event' by its 'potential impact' to properly assess the real risk....it > is > not sufficinet to appeal to the rare prob alone (cf the aircraft or > nuclear-power industries....OK networks don't kill people (usually at > least!), but I hope you get my point). I am sure the vendors must have > some > specification, albeit currently proprietary....but these need > standardising. > - where are the 'consequent actions' on failure specified? > - where is the definition of availability specified? > - and how can we move on to define QoS metrics/objectives if we > can't > define availablity? > As an operator we are coming under increasing pressure to be able to > define > these (esp for VPN customers), and in any case these are issues that > should > be thought about up-front and not later (when it might be too difficult > to > make changes). It seems clear that you don't have any answers to these > questions, but you also don't have any alternative proposals either. > BTW - I am surprised you thought the proposals complex. This is about > as > simple as we could make them, and Shahram (who works for a chip > supplier) > did not think these complex. > > regards, neil > From owner-mpls@UU.NET Tue Apr 3 20:19:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20805 for ; Tue, 3 Apr 2001 20:19:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfl07266; Wed, 4 Apr 2001 00:16:41 GMT Received: by mail-control.mail.uu.net id QQkjfl22040 for mpls-outgoing; Wed, 4 Apr 2001 00:16:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjfl21988 for ; Wed, 4 Apr 2001 00:15:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjfl12850 for ; Wed, 4 Apr 2001 00:15:32 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjfl19763 for ; Wed, 4 Apr 2001 00:15:28 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id UAA89975; Tue, 3 Apr 2001 20:11:17 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104040011.UAA89975@workhorse.fictitious.org> To: Eric Gray cc: curtis@avici.com, George Swallow , Adrian Farrel , pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on LDP Fault Tollerance In-reply-to: Your message of "Tue, 03 Apr 2001 17:33:31 EDT." <3ACA41AB.2A3ACB59@sandburst.com> Date: Tue, 03 Apr 2001 20:11:17 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3ACA41AB.2A3ACB59@sandburst.com>, Eric Gray writes: > Curtis, > > As I understand it, LDP is the preferred protocol for use > with MPLS BGP when BGP peers are not adjacent with > respect to an MPLS domain. Suppose that MPLS BGP is > used to establish many VPN services which are possibly > being used to provide a label switching service to enterprise > customers. > > For that matter, suppose that LDP is being used to signal > and maintain VPN technology's LSPs. Eric, You wouldn't be using LDP on the outer tunnel, just the inner VPN tunnel. The outer tunnel is a RSVP-TE tunnel. We are already lab testing this at a customer and it interoperates nicely with other people's BGP/VPN LDP implementations. Because the TE tunnel is rerouted around a failure the LDP adjacency that ride inside the TE tunnels never go down. The LDP TCP connection sees some temporary loss at worst and then continues as if no topology change occurred because the logical adjacency never went down. This works as long as there is a brief holddown on the TE tunnel and it reroutes before the holddown expires. In practice works great. Where you want to maintain LDP (and IGP) adjacency is where a router is reloaded for something like software upgrade and nothing else in the IGP changes during the reload time. If you have two route processors on the router that was reloaded, that should be a switch in well under a second. Rumor has it that some routers with one route processor take a few minutes to reload so for those, if the topology changes you'd rather route around them. So please remind me, exactly what was the point of your objection. :-) Curtis > You wrote: > > > In message <3ACA3769.1E1C006F@sandburst.com>, Eric Gray writes: > > > > > > I also suspect that you may be understating the advantages > > > of maintaining session context. Consider the impact to the > > > network if LSPs are dropped lightly and these LSP are in turn > > > being used to carry (stacked) LSPs. > > > > > > -- > > > Eric Gray > > > > You wouldn't be using LDP in that case. ;-) > > > > Curtis From owner-mpls@UU.NET Tue Apr 3 20:32:56 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21009 for ; Tue, 3 Apr 2001 20:32:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfm04368; Wed, 4 Apr 2001 00:31:09 GMT Received: by mail-control.mail.uu.net id QQkjfm22941 for mpls-outgoing; Wed, 4 Apr 2001 00:30:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjfm22931 for ; Wed, 4 Apr 2001 00:30:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjfl03114 for ; Wed, 4 Apr 2001 00:28:58 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjfl17259 for ; Wed, 4 Apr 2001 00:28:47 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id UAA90014; Tue, 3 Apr 2001 20:28:18 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104040028.UAA90014@workhorse.fictitious.org> To: George Swallow cc: curtis@avici.com, Francis Arts , rgoguen@cisco.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Comments to In-reply-to: Your message of "Tue, 03 Apr 2001 17:50:31 EDT." <200104032150.RAA26300@pilgrim.cisco.com> Date: Tue, 03 Apr 2001 20:28:18 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200104032150.RAA26300@pilgrim.cisco.com>, George Swallow writes: > > > > > > Is it for the purpose of your draft allowed to set the extended tunnel > > > id to all 0s as well as setting it to an IPv4 address of the ingress > > > LSR? > > > > > > While you are allowed to set this to all 0s, I don't know any reason > > to set to all 0s. Unlike some people I don't assume that all backup > > tunnels will have a zero bandwidth reservation and therefore if you > > want make-before-break to work, all 0s would be a poor choice. > > If you're doing SE reservations on the tunnel and the backup tunnel, > then the scope of the sharing is limited by RSVP to senders to the > same session. So, if you want the reservations shared then you need > to use the identical Session object. The backup and the primary should merge at some point and that point would be the egress of the backup. If so, then there is no common link and no opportunity to share. The backup can serve as backup for as many primary LSP as need route around the failure on that path. I had envisioned sharing backup bandwdith using the techniques described in draft-kini-* but that too is out of scope for draft-swallow-rsvp-bypass-label-01 and orthogonal to it. > > > 5) p.6, section 2, last but one paragraph. > > > > > > The text states that 'it is thus necessary to properly associate the > > > LSP_ID of a backup tunnel with the LSP_ID of the tunnel being backed > > > up'. > > > > > > However, from the text (p.6, section 2, last but one paragraph) it does > > > not seem to be necessary to copy the LSP_ID since the 'other LSP' > > > mentioned in the text, has another 'IPv4 tunnel sender address' in the > > > SENDER_TEMPLATE. A drawing showing an example, would be useful. > > > > I don't understand the reason for this restriction > > I'll remove the text. It's dangling text that has to do with some > other stuff I took out of the draft before it was ever published > (including draft-00). The idea was to allow downstream nodes to be > able to associate which back up path state went with which primary > state during a reroute operation. But that isn't all that useful so I > removed it. Good. I thought it was me being dense again. > >and how one to many > > backup tunnels would be accomodated if the LSP_ID is copied. George? > > I don't understand the question. The Session objects differentiate > the many backup tunnels. It doesn't matter if some of those backup > tunnels happen to have identical sender objects. Dumb question. Never mind. I was considering the case where the join occurs exactly one logical hop away and uses a platform label. You don't have to signal an inner tunnel, just the shared outer tunnel and use the platform label from the primary tunnel. That may not be a behavior endorsed by the draft. If you have a shared outer tunnel and signaled inner backup tunnels, then copying the LSP_ID to the inner tunnel would be fine. You increase the signaling load but you still save on labels since only the labels for the shared outer tunnel is needed on the physical backup hops. What you describe is needed if you want to use interface labels and need to take one extra hop along the primary path before the final POP so that the primary path label shows up on the same interface. Curtis ps- Sorry for the dumb question. This draft is a bit old and it was a while ago that we thought this stuff through. Still makes sense. From owner-mpls@UU.NET Tue Apr 3 21:42:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22781 for ; Tue, 3 Apr 2001 21:42:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfq05795; Wed, 4 Apr 2001 01:39:07 GMT Received: by mail-control.mail.uu.net id QQkjfq13087 for mpls-outgoing; Wed, 4 Apr 2001 01:38:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjfq13074 for ; Wed, 4 Apr 2001 01:38:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjfq12062 for ; Wed, 4 Apr 2001 01:36:17 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjfq01528 for ; Wed, 4 Apr 2001 01:36:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA12056 for mpls@uu.net; Tue, 3 Apr 2001 21:36:17 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjfq13010 for ; Wed, 4 Apr 2001 01:35:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjfq27666 for ; Wed, 4 Apr 2001 01:33:25 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkjfq23944 for ; Wed, 4 Apr 2001 01:33:24 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id SAA27556; Tue, 3 Apr 2001 18:33:23 -0700 (PDT) Message-ID: <3ACA79D7.91254F54@juniper.net> Date: Tue, 03 Apr 2001 18:33:11 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Cooper CC: mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dave Cooper wrote: > > But on the topic of MPLS OAM, it has its > merits -- especially when software failures (whereby the control plane > does not detect failures in the data plane) seem to continue to be the > bane of most MPLS implementations. I've been preaching this directly > to vendors for quite some time and despite what tweaks we put into the > control plane for dealing with failure (whether its fast reroute, normal > reroute, whatever), its still doesnt fix this constant problem. Customers > are tired of hearing the vendor bug excuse. > > dave > Dave, Agree! Also it's hard to find much overlap between MPLS fast-reroute and physical link failure detection (such as SONET APS). Although both try to minimize packet loss, these are fundamentally different technologies. One does not replace the other, and one does not preclude the use of other. In particular, one big difference between the two is timing: fast-reroute time is probably lower than typical ISIS/OSPF convergence time in today's backbone. But fast-reroute time may still be higher than SONET APS. In particular, I don't think that fast-reroute can offer guarantees on the upper bound of fail-over time. There are simply too many uncontrollable variables affecting the fail-over speed, no matter what type of fast-reroute mechanism you choose. Regards, - Ping From owner-mpls@UU.NET Tue Apr 3 21:42:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22800 for ; Tue, 3 Apr 2001 21:42:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfq05364; Wed, 4 Apr 2001 01:40:28 GMT Received: by mail-control.mail.uu.net id QQkjfq13098 for mpls-outgoing; Wed, 4 Apr 2001 01:38:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjfq13093 for ; Wed, 4 Apr 2001 01:38:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjfq27160 for ; Wed, 4 Apr 2001 01:37:51 GMT Received: from osf1.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQkjfq02770 for ; Wed, 4 Apr 2001 01:37:48 GMT Received: from localhost (rpapneja@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id VAA08203; Tue, 3 Apr 2001 21:32:37 -0400 (EDT) Date: Tue, 3 Apr 2001 21:32:37 -0400 (EDT) From: Rajiv Papneja To: MPLS@gmu.edu, mpls@UU.NET Subject: MPLS 2001 International Conference - Oct. 7-9 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Dear friends, The MPLS 2001 International Conference will again be hosted jointly by UUNET Technologies and Advanced Internet Lab, and will be held at the Omni Shoreham Hotel in Washington, DC, October 7-9, 2001. The conference begins with tutorials on Sunday October 7 and continues with full-day technical sessions on Monday and Tuesday, October 8-9. A series of public Interoperability demonstrations will follow on October 10-12 at Advanced Internet Lab. Conference information, technical program, and other details, including the testing and public Interoperability events will be made available at http://www.mpls2001.com. The technical program for MPLS 2001 will be unique, as were the programs for previous events in this series. MPLS 98 was the first conference on the topic of Multiprotocol Label Switching. The attendance has continued to grow each year. Last year, at MPLS 2000, 17 sponsors exhibited their products and services throughout the conference. This year, we have reserved a larger space to accommodate additional sponsors. If you are interested in securing exhibit space at MPLS 2001, please contact sponsor@mpls2001.com, 703.218.3770 (phone), or 703.218.3780 (fax). Three categories of sponsorship are available. Exhibit space is limited and will be committed on a first-come, first-served basis. For additional information, hotel reservation, last year's sponsors please visit http://www.mpls2001.com. We look forward to seeing you in the "MPLS 2001 International Conference." Thanks. Regards, - Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** From owner-mpls@UU.NET Tue Apr 3 21:48:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22881 for ; Tue, 3 Apr 2001 21:48:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfr11445; Wed, 4 Apr 2001 01:47:03 GMT Received: by mail-control.mail.uu.net id QQkjfr13772 for mpls-outgoing; Wed, 4 Apr 2001 01:46:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjfr13757 for ; Wed, 4 Apr 2001 01:46:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjfr20239 for ; Wed, 4 Apr 2001 01:45:48 GMT From: afarrel@movaz.com Received: from ims002.dcat.ops.broadbandoffice.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: external00.dca55.ops.bbo.com [64.47.146.7]) id QQkjfr19329 for ; Wed, 4 Apr 2001 01:45:48 GMT Received: by ims002.dcat.ops.broadbandoffice.net with Internet Mail Service (5.5.2650.21) id <2HY5TFDB>; Tue, 3 Apr 2001 21:45:47 -0400 Message-ID: <4F9E13BCC53ED411A629009027E8D00C043336DA@msg001.dcat.ops.broadbandoffice.net> To: curtis@avici.com, pjb@metaswitch.com, philipma@nortelnetworks.com, eric.gray@sandburst.com Cc: mpls@UU.NET Subject: RE: Last Call on LDP Fault Tolerance Date: Tue, 3 Apr 2001 21:45:45 -0400 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, I can't see any reason not to point out that a "give up and run away" type of timer can be overridden by other events. The one you suggest (significant IGP change) could well be applicable to LDP, although I think it is less significant in CR-LDP. I find... > There appears to be a school of thought where it is deemed beneficial > to keep forwarding state intact in only very limited cases such as > midnight controlled reload of routers for purposes such as software > upgrade. ...odd. When a line card fails I should like to be able to swap to a new card and continue forwarding data with only a very short (10s of ms) break. Adrian -- Adrian Farrel Movaz Networks Inc afarrel@movaz.com > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Tuesday, April 03, 2001 3:07 PM > To: George Swallow; af@dataconnection.com; pjb@dataconnection.com; > philipma@nortelnetworks.com; eric.gray@sandburst.com > Cc: mpls@UU.NET > Subject: Re: Last Call on LDP Fault Tollerance > > > > In message <200103282300.SAA15343@pilgrim.cisco.com>, George > Swallow writes: > > This message commences a workgroup last call on LDP Fault > Tollerance, > > . The last call closes > April 11, 12 pm > > GMT. > > > > ...George > > > > > ====================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > Adrian, et al, > > I would like to make a comment and leave it up to the authors > discression as to whether to incorporate any change into the document. > > There appears to be a school of thought where it is deemed beneficial > to keep forwarding state intact in only very limited cases such as > midnight controlled reload of routers for purposes such as software > upgrade. This case can be even further limited to maintaining > forwarding state only if network topology has not changed while > adjacency is unavailable. > > The justification for retaining forwarding state is to eliminate > unnecessary forwarding state churn that may cause transient forwarding > disruptions. The justification for not retaining forwarding state if > topology changes is to prevent persistent forwarding problems that > could occur if loops or black holes formed as a result of inconsistent > forwarding state on a router in which the means to synchronize state > was unavailable. > > Stated more simply -- Its nice to avoid dumping a few packets on the > floor but if topology changes it may be better to endure some > transient route churn than to endure inconsistent routing state that > lasts for the duration of a router reloading new software and could > dump a whole lot more packets on the floor than what the transient > would cause. > > If changes are made, one possible addition would be to add a section > 4.4.2: > > 4.4.2 Optional Reconnect Expire on Topology Change > > this is needed from the authors> > > If topology change is detected through some means outside LDP such > as change in an Interior Gateway Protocol Link State Database > (IGP-LSDB) it may be desireable to prematurely expire the FT > Reconnection Timer. An option SHOULD be provided to enable such a > feature on a per peer basis. > > I leave it entirely up to the authors as to whether they would like to > add this text. I would prefer if something to this effect were added > unless there is objection to this addition on the list. A vendor > could always include such a feature and make it optional and disabled > by default regardless of whether it is stated in the document so there > is little sense of urgency. > > Curtis > From owner-mpls@UU.NET Tue Apr 3 21:51:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22932 for ; Tue, 3 Apr 2001 21:51:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfr26050; Wed, 4 Apr 2001 01:49:01 GMT Received: by mail-control.mail.uu.net id QQkjfr13999 for mpls-outgoing; Wed, 4 Apr 2001 01:48:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjfr13976 for ; Wed, 4 Apr 2001 01:48:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjfr25893 for ; Wed, 4 Apr 2001 01:47:37 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host200.pluris.com [208.227.9.200]) id QQkjfr12012 for ; Wed, 4 Apr 2001 01:47:36 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id SAA29091; Tue, 3 Apr 2001 18:47:35 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <2ABFN41W>; Tue, 3 Apr 2001 18:47:35 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA0951C9@avalon.pluris.com> From: Bora Akyol To: "'Ping Pan'" , Dave Cooper Cc: mpls@UU.NET Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Tue, 3 Apr 2001 18:47:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Ping At least in one implementation of APS and FR that I am familiar with, the timing to generate a switchover between the two is very close in terms of failover and in this particular implementation, APS switchover timing meets less than 50 ms. So I would not immediately rule out FR timing in place of APS. Bora Who is quite "familiar" with one implementation -----Original Message----- From: Ping Pan [mailto:pingpan@juniper.net] Sent: Tuesday, April 03, 2001 6:33 PM To: Dave Cooper Cc: mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels Dave Cooper wrote: > > But on the topic of MPLS OAM, it has its > merits -- especially when software failures (whereby the control plane > does not detect failures in the data plane) seem to continue to be the > bane of most MPLS implementations. I've been preaching this directly > to vendors for quite some time and despite what tweaks we put into the > control plane for dealing with failure (whether its fast reroute, normal > reroute, whatever), its still doesnt fix this constant problem. Customers > are tired of hearing the vendor bug excuse. > > dave > Dave, Agree! Also it's hard to find much overlap between MPLS fast-reroute and physical link failure detection (such as SONET APS). Although both try to minimize packet loss, these are fundamentally different technologies. One does not replace the other, and one does not preclude the use of other. In particular, one big difference between the two is timing: fast-reroute time is probably lower than typical ISIS/OSPF convergence time in today's backbone. But fast-reroute time may still be higher than SONET APS. In particular, I don't think that fast-reroute can offer guarantees on the upper bound of fail-over time. There are simply too many uncontrollable variables affecting the fail-over speed, no matter what type of fast-reroute mechanism you choose. Regards, - Ping From owner-mpls@UU.NET Tue Apr 3 22:33:07 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24417 for ; Tue, 3 Apr 2001 22:33:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfu20870; Wed, 4 Apr 2001 02:30:35 GMT Received: by mail-control.mail.uu.net id QQkjfu02047 for mpls-outgoing; Wed, 4 Apr 2001 02:30:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjft01994 for ; Wed, 4 Apr 2001 02:29:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjft29327 for ; Wed, 4 Apr 2001 02:28:08 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjft17882 for ; Wed, 4 Apr 2001 02:28:08 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA15719 for mpls@uu.net; Tue, 3 Apr 2001 22:28:07 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjft01953 for ; Wed, 4 Apr 2001 02:27:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjft03564 for ; Wed, 4 Apr 2001 02:27:15 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkjft11615 for ; Wed, 4 Apr 2001 02:27:15 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA00774; Tue, 3 Apr 2001 19:27:09 -0700 (PDT) Message-ID: <3ACA8670.59713EAC@juniper.net> Date: Tue, 03 Apr 2001 19:26:56 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: Dave Cooper , mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: <17C81AD1F1FED411991E006008F6D1CA0951C9@avalon.pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol wrote: > > Ping > > At least in one implementation of APS and FR that I am familiar with, the > timing to generate a switchover between the two is very close in terms of > failover and in this particular implementation, APS switchover timing meets > less than 50 ms. > > So I would not immediately rule out FR timing in place of APS. > > Bora Bora, I was pointing out that the fail-over time can be *unpredictable* at protocol level, where a link failure may trigger heavy processing among many protocols (such as BGP and RSVP). I have no doubt that if you put a link detection routine within link card's driver or something, the failover time can be quite fast. - Ping From owner-mpls@UU.NET Tue Apr 3 23:29:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24964 for ; Tue, 3 Apr 2001 23:29:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjfx05097; Wed, 4 Apr 2001 03:28:22 GMT Received: by mail-control.mail.uu.net id QQkjfx22186 for mpls-outgoing; Wed, 4 Apr 2001 03:27:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjfx22181 for ; Wed, 4 Apr 2001 03:27:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjfx04063 for ; Wed, 4 Apr 2001 03:27:32 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host200.pluris.com [208.227.9.200]) id QQkjfx09975 for ; Wed, 4 Apr 2001 03:27:31 GMT Received: from [192.168.123.149] (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA01397; Tue, 3 Apr 2001 20:27:29 -0700 (PDT) Mime-Version: 1.0 X-Sender: akyol@127.0.0.1 Message-Id: In-Reply-To: <3ACA8670.59713EAC@juniper.net> References: <17C81AD1F1FED411991E006008F6D1CA0951C9@avalon.pluris.com> <3ACA8670.59713EAC@juniper.net> Date: Tue, 3 Apr 2001 20:27:10 -0700 To: Ping Pan From: Bora Akyol Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels Cc: Bora Akyol , Dave Cooper , mpls@UU.NET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 7:26 PM -0700 4/3/01, Ping Pan wrote: >Bora Akyol wrote: >> >> Ping >> >> At least in one implementation of APS and FR that I am familiar with, the >> timing to generate a switchover between the two is very close in terms of >> failover and in this particular implementation, APS switchover timing meets >> less than 50 ms. >> >> So I would not immediately rule out FR timing in place of APS. >> >> Bora > >Bora, > >I was pointing out that the fail-over time can be *unpredictable* at >protocol level, where a link failure may trigger heavy processing among >many protocols (such as BGP and RSVP). I have no doubt that if you put a >link detection routine within link card's driver or something, the >failover time can be quite fast. > >- Ping Agreed but what I was trying to say thatthe failover time despite being dependent on the number of LSPs that have fast reroute enabled is not terribly different than SONET APS switchover times. But yes if you have N LSPs where N is really large the failover may take longer than if you had only one. In practice you will probably not have more than 1000 LSPs so this processing delay is not huge. Bora From owner-mpls@UU.NET Wed Apr 4 00:15:34 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25758 for ; Wed, 4 Apr 2001 00:15:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjga26412; Wed, 4 Apr 2001 04:13:31 GMT Received: by mail-control.mail.uu.net id QQkjga11672 for mpls-outgoing; Wed, 4 Apr 2001 04:13:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjga11664 for ; Wed, 4 Apr 2001 04:12:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjga00411 for ; Wed, 4 Apr 2001 04:12:34 GMT From: rexyan@us.sina.com Received: from c000.zsm.cp.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: c000-h009.c000.zsm.cp.net [209.228.56.68]) id QQkjga10011 for ; Wed, 4 Apr 2001 04:12:34 GMT Received: (cpmta 8061 invoked from network); 3 Apr 2001 21:12:33 -0700 Date: 3 Apr 2001 21:12:33 -0700 Message-ID: <20010404041233.8060.cpmta@c000.zsm.cp.net> X-Sent: 4 Apr 2001 04:12:33 GMT Received: from [192.11.226.121] by mail.us.sina.com with HTTP; 03 Apr 2001 21:12:33 PDT Content-Type: text/plain; charset=unicode-1-1-utf-8 Content-Disposition: inline Mime-Version: 1.0 To: mpls@UU.NET X-Mailer: Web Mail 3.0 Subject: ER-Hop 3 Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I got some questions about ER-Hop 3. in draft-ietf-mpls-cr-ldp-05.txt, it says: <<<<<<<<<<<<<<<<<<<<< To determine the next hop for the path, a node performs the following steps: 1. The node receiving the Label Request Message must first evaluate the first ER-Hop. If the L bit is not set in the first ER-Hop and if the node is not part of the abstract node described by the first ER-Hop, it has received the message in error, and should return a "Bad Initial ER-Hop" error. If the L bit is set and the local node is not part of the abstract node described by the first ER-Hop, the node selects a next hop that is along the path to the abstract node described by the first ER-Hop. If there is no first ER-Hop, the message is also in error and the system should return a "Bad Explicit Routing TLV" error using a Notification Message sent upstream. >>>>>>>>>>>>>>>>>>> Q1: How to verify that a local node is not a part of the abstract node described by AS? Does it mean that the the AS number of local node is different from the AS number of the abstract node? Q2: If 1) the first ER-Hop's L bit is set (i.e. loose ER-LSP); 2) and the local node is not a part of the abstract node described by the first ER-Hop; 3) the first ER-Hop is an AS number. How to select a next hop that is along the path to the abstract described by an AS number? Is it possible to query a route using an AS number as an input to the routing table? If yes, how to? by using routing socket? Thanks in advance. X.Q. Yan _______________________________________________________________ http://www.SINA.com - #1 Destination Site for Chinese Worldwide From owner-mpls@UU.NET Wed Apr 4 03:48:04 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10841 for ; Wed, 4 Apr 2001 03:48:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjgp25694; Wed, 4 Apr 2001 07:46:48 GMT Received: by mail-control.mail.uu.net id QQkjgp13901 for mpls-outgoing; Wed, 4 Apr 2001 07:46:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjgp13854 for ; Wed, 4 Apr 2001 07:45:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjgp16356 for ; Wed, 4 Apr 2001 07:45:23 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQkjgp22867 for ; Wed, 4 Apr 2001 07:45:21 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f347hqQ19068; Wed, 4 Apr 2001 09:43:52 +0200 (MET DST) Received: from alcatel.be ([138.203.197.202]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A24.002A6E36; Wed, 4 Apr 2001 09:43:27 +0200 Message-ID: <3ACAD09D.521CD298@alcatel.be> Date: Wed, 04 Apr 2001 09:43:25 +0200 From: Francis Arts X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: curtis@avici.com, rgoguen@cisco.com, mpls@UU.NET Subject: Re: Comments to References: <200104032150.RAA26300@pilgrim.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, George, My comments are in-line. Since the subsequent mails exchanged on the subject, trimmed part of the questions I want to comment on, I use this one. Francis. ------------- George Swallow wrote: > Francis, Curtis - > > > In message <3AC473D7.7A50CB85@alcatel.be>, Francis Arts writes: > > > > > > Hello Rob, George, > > > > > > Please find included my comments to your > > > draft. > > > > > > Regards, > > > > > > Francis. > > > > > > Francis, > > > > Responses inline. This is my understanding of the draft. George can > > correct me. > > > > Curtis > > > > > > > > > 1) PHP vs global label space. > > > > > > The text of section 2 states the following: > > > "The penultimate hop of the backup tunnel would > > > pop the label for the backup tunnel, revealing the label which M > > > expects." > > > > > > However, when reading your proposal, the use of PHP does not seem > > > mandatory, even when a global space is used in the merge node M. > > > > > > Please add an explicit statement to the text whether or not PHP is > > > mandatory in the global label space case. > > > > > > It is not manditory. If the egress is capable of doing a POP and then > > looking at the next label, its allowed to do that. > > Correct. The text that you are questioning was only meant as an > example. I'll add some text to make that clearer. > Ok. > > > > 2) Bypass tunnel. > > > > > > The text of section 2 states the following: > > > "When a failure occurs and the backup comes into use, a means of > > > maintaining the RSVP state is required. In this simple case the Path > > > > > > messages can simply be sent via the backup link or tunnel as the case > > > > > > may be." > > > > > > Refreshing RSVP messages down a bypass tunnel is not described in any > > > RFC or ID (also not in draft-ietf-mpls-rsvp-lsp-tunnel-08). Therefore, > > > the mechanism needs to be explained in your draft. e.g. Which value > > > should be used for the PHOP object when refreshing the PATH message down > > > the bypass tunnel? > > > > > > Note: You could consider reusing the signalling mechanisms Kireeti > > > Kompella has defined for LSPs used as FAs. > > > > Can we consider that to be out of scope? That way it doesn't have to > > be defined in both the hierarchical draft and in this one. As long as > > there is a defined way to do this. > > I think the FA draft is beyond the scope. Some words about PHOP are > in order. I'll add some. The important thing is that the PLR node be > able to associate the RESV message with the Path message it sent down > the tunnel. How the PLR does this is a local matter. One thing to > note is that the IP address of the orginal outbound interface could in > some cases become unreachable if that link goes down. So some care > needs to be used here. I would personnally recommend using the same > IP address that you use in the Sender Object, but there's nothing > mandatory about that. > Comment: * You state that 'it is a local matter how the RESV message is associated with the correct PATH message'. However, I don't think this is a local matter: This is done using the SESSION and FILTER SPEC objects; it does not involve the PHOP object. * The idea in the RSVP protocol is to use the IP address of the connection to the next IP router. In this case this connection is an LSP. Therefore, the question is which IP address is associated with this LSP. My understanding of your draft is that no such IP address <==> backup LSP relation is considered (correct me if I got that wrong). Therefore, I propose to add an explicit statement to the text that 'when sending the PATH message into the backup tunnel, the PHOP object can conatin any IP address of the PLR'. > > > > 4) p.6, section 2, extended tunnel id. > > > > > > Is it for the purpose of your draft allowed to set the extended tunnel > > > id to all 0s as well as setting it to an IPv4 address of the ingress > > > LSR? > > > > > > While you are allowed to set this to all 0s, I don't know any reason > > to set to all 0s. Unlike some people I don't assume that all backup > > tunnels will have a zero bandwidth reservation and therefore if you > > want make-before-break to work, all 0s would be a poor choice. > > If you're doing SE reservations on the tunnel and the backup tunnel, > then the scope of the sharing is limited by RSVP to senders to the > same session. So, if you want the reservations shared then you need > to use the identical Session object. > Comment to Curtis' statement: * I agree that it cannot be assumed that the backup tunnel has zero bandwidth. * As George states the same SESSION object and the SE reservation style are mandatory to get make-before-break to work. However, if I understand you correctly, you state that the settings of the extended tunnel id is important for make-before-break to work. I don't think this is necessary: Make-before-break can work when extended tunnel id == 0 as well as when extended tunnel id < > all 0s. The importance of the extended tunnel id is that SE style reservations can be shared between different sender nodes (extended tunnel id == all 0s) or not (extended tunnel id < > all 0s). This is important when setting up multipoint-to-point LSPs. * The sharing of resources happens from the downstream node on where the backup tunnel and the tunnel being backed up, merge again. [As you indicate in 1 of your subsequent mails, I agree that there is no resource sharing in between the PLR and the merge node.] Comment to George's statement: * I agree that using identical SESSION objects is mandatory to share reservations. Therefore, your proposal to copy the SESSION object from the tunnel being backed up, to the backup tunnel is mandatory: This allows to merge the backup tunnel again in the downstream node with the original tunnel. > > > > 5) p.6, section 2, last but one paragraph. > > > > > > The text states that 'it is thus necessary to properly associate the > > > LSP_ID of a backup tunnel with the LSP_ID of the tunnel being backed > > > up'. > > > > > > However, from the text (p.6, section 2, last but one paragraph) it does > > > not seem to be necessary to copy the LSP_ID since the 'other LSP' > > > mentioned in the text, has another 'IPv4 tunnel sender address' in the > > > SENDER_TEMPLATE. A drawing showing an example, would be useful. > > > > I don't understand the reason for this restriction > > I'll remove the text. It's dangling text that has to do with some > other stuff I took out of the draft before it was ever published > (including draft-00). The idea was to allow downstream nodes to be > able to associate which back up path state went with which primary > state during a reroute operation. But that isn't all that useful so I > removed it. Comment: Please note that also the last paragraph of p.6 ("we therefore propose ...") needs some updating: * The text indicates that "the SESSION object and the LSP_ID should be copied from the LSP tunnel being backed up to the backup tunnel". However, copying the LSP_ID is then no longer necessary. * The text states that "if the head-end of a tunnel is also acting as the PLR, it must choose an IP address different from the one used in the SENDER_TEMPLATE of the original LSP tunnel". However, choosing in this case a different IP address, is no longer necessary: Just choose a different LSP_ID. > > > >and how one to many > > backup tunnels would be accomodated if the LSP_ID is copied. George? > > I don't understand the question. The Session objects differentiate > the many backup tunnels. It doesn't matter if some of those backup > tunnels happen to have identical sender objects. > > > Curtis > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Apr 4 07:07:07 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13499 for ; Wed, 4 Apr 2001 07:07:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjhc12228; Wed, 4 Apr 2001 11:04:44 GMT Received: by mail-control.mail.uu.net id QQkjhc28576 for mpls-outgoing; Wed, 4 Apr 2001 11:04:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjhc26641 for ; Wed, 4 Apr 2001 11:03:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjhc06230 for ; Wed, 4 Apr 2001 11:03:33 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkjhc06440 for ; Wed, 4 Apr 2001 11:03:33 GMT Received: from goneto.net (unknown [195.167.134.116]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id EDF9315F7E6; Wed, 4 Apr 2001 12:03:31 +0100 (BST) Message-ID: <3ACB0C46.CA5725A9@goneto.net> Date: Wed, 04 Apr 2001 12:57:58 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: MPLS OAM (was Re: Last Call on RSVP Label Allocation for Backup Tunnels) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit neil.2.harrison@bt.com wrote: > > Giles Heron [mailto:giles@goneto.net] wrote 02 April 2001 06:15 > > Can you please give us some examples of situations where the control > > plane will not detect the user plane defect? (other than the buggy > > software case below of course.) > NH=> Any situation where the user and control-plane do not go through > *exactly* the same routing/processing. In GMPLS-type situation this is a > given, in MPLS this is less obvious I agree (except for those hopefully rare > SW/HW failures modes).....especially for base LDP. However, as a general > principle one should aim to make user and control-plane defect handing > independent so as to allow flexibility of user and control-plane network > topology design (they are quite distinct in principle, and the control-plane > topology has to takes its design cues from the duct for rigorous resilience > design). I'll take that as a "no" then ;-) Seriously I think it is the case that for MPLS the control and user plane will almost always go through the same path (since in the LDP case both the control and user planes follow the IGP, whilst in the RSVP case the user plane follows the path of the RSVP RESV message.) The exception could be when BGP is used for label distribution (because of route reflection etc.) However for the BGP VPN case there is a layer of (typically LDP derived) labels over which the VPN labels operate (and so these will detect any network failure), whilst in the eBGP case you'd hope that the MP-eBGP session runs directly over the link for which labels are being assigned? > > And yes, of course I have a requirement to offer SLAs to customers. > > Originally I had thought that some sort of MPLS OAM might be > > useful for > > this. Having read your draft, having seen the complexity involved, > > having figured out that all it seems to detect that cannot be detected > > by other means is mismerged/swapped LSPs, and having > > discovered that it > > doesn't support merging LSPs > NH=> Lots of things don't support merging....nor is merging always such a > wonderful thing. No, it isn't always a wonderful thing. But it is a useful tool to have. > , I have come to the conclusion > > (rightly or > > wrongly) that I'm better off without. > NH=> I can understand your view .....especially if all you ever want to use > MPLS for is in a LDP-type of deployment. But I am still left with these > unanswered questions for a path-oriented view/use of LSPs: > - where are the definitions of defects specified? > Note - I know some defects should be rare.......but we should aim to be > rigorous in specification at the outset and we need to weight the 'prob of > event' by its 'potential impact' to properly assess the real risk....it is > not sufficinet to appeal to the rare prob alone (cf the aircraft or > nuclear-power industries....OK networks don't kill people (usually at > least!), but I hope you get my point). I am sure the vendors must have some > specification, albeit currently proprietary....but these need standardising. I think a fair assumption is to say that if the LSP fails from the control plane point of view then it is considered to be down. I know this doesn't catch the "rare" cases, but I think it is workable for all intents and purposes (especially since the OAM code to catch the "rare" cases would have failure modes itself!) > - where are the 'consequent actions' on failure specified? Presumably in the case of George's draft the "consequent action" should be to reroute over a backup tunnel? > - where is the definition of availability specified? I'd specify it as the % of time for which the LSP is up from the control plane point of view? > - and how can we move on to define QoS metrics/objectives if we can't > define availablity? Agreed - so let's take a simple definition as above. > As an operator we are coming under increasing pressure to be able to define > these (esp for VPN customers), and in any case these are issues that should > be thought about up-front and not later (when it might be too difficult to > make changes). It seems clear that you don't have any answers to these > questions, but you also don't have any alternative proposals either. I'd say I just made a perfectly workable proposal - from the point of view of a pragmatist who has to build and run a production network. I suspect your viewpoint is somewhat different. > BTW - I am surprised you thought the proposals complex. This is about as > simple as we could make them, and Shahram (who works for a chip supplier) > did not think these complex. I'd say 29 pages for a first revision of a draft is pretty meaty. Especially when the P flow and support for merging LSPs are FFS, and the figures are all missing? Giles -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Wed Apr 4 10:04:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19725 for ; Wed, 4 Apr 2001 10:04:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjho10460; Wed, 4 Apr 2001 14:01:41 GMT Received: by mail-control.mail.uu.net id QQkjho21063 for mpls-outgoing; Wed, 4 Apr 2001 14:01:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjho20537 for ; Wed, 4 Apr 2001 14:00:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjhn04321 for ; Wed, 4 Apr 2001 13:59:24 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkjhn17057 for ; Wed, 4 Apr 2001 13:59: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 GAA20220 for ; Wed, 4 Apr 2001 06:59:46 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA13222 for mpls@uu.net; Wed, 4 Apr 2001 09:59:22 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjgr03089 for ; Wed, 4 Apr 2001 08:28:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjgr18776 for ; Wed, 4 Apr 2001 08:28:10 GMT Received: from tlvsdy.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tlvsdy.vim.tlt.alcatel.it [194.243.74.244]) id QQkjgr10088 for ; Wed, 4 Apr 2001 08:28:10 GMT Received: from tlvhdk.netit.alcatel.it (tlvhgd.netit.alcatel.it [151.98.14.48]) by tlvsdy.vim.tlt.alcatel.it (8.9.3+Sun/8.9.3) with ESMTP id KAA23666 for ; Wed, 4 Apr 2001 10:28:30 +0200 (MET DST) Received: from netit.alcatel.it (ipl013.vim.tlt.alcatel.it [151.98.36.13]) by tlvhdk.netit.alcatel.it (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA04229 for ; Wed, 4 Apr 2001 10:24:05 +0200 (METDST) Message-ID: <3ACADB24.8570FC29@netit.alcatel.it> Date: Wed, 04 Apr 2001 10:28:20 +0200 From: Roberto Guglielmi Organization: Alcatel - IP R&D X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: MPLS WG Subject: Checksum in RSVP messages Content-Type: multipart/mixed; boundary="------------CD5AC5F7A5B7BE8D7C656790" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------CD5AC5F7A5B7BE8D7C656790 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I have a couple of questions about calculating RSVP checksum in the common header. Our SW product implementing RSVP calculates the checksum making the one's complement of sum two-by-two of the bytes contained in the messages. The problem is that using the Sniffer protocol analizer to decode the messages sent by the nodes, the checksum seems to be wrong. The RFC 2205 says the checksum is calculated in the following way: "The one's complement of the one's complement sum of the message , with the checksum field replaced by zero..." Are the bytes within the message supposed to be added one-by-one or two-by-two? Are we supposed to make the one's complement of the message, make the sum and, at the end, the one's complement of the sum? I would appreciate your help to solve my problem since I don't know where to get more info. Thanks --------------CD5AC5F7A5B7BE8D7C656790 Content-Type: text/x-vcard; charset=us-ascii; name="roberto.guglielmi.vcf" Content-Description: Card for Roberto Guglielmi Content-Disposition: attachment; filename="roberto.guglielmi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Guglielmi;Roberto x-mozilla-html:FALSE org:Alcatel Italy;IP Laboratory adr:;;;;;; version:2.1 email;internet:roberto.guglielmi@netit.alcatel.it title:SW Designer note:Tel. +39 039 6864801 x-mozilla-cpt:;-20560 fn:Roberto Guglielmi end:vcard --------------CD5AC5F7A5B7BE8D7C656790-- From owner-mpls@UU.NET Wed Apr 4 10:16:31 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20400 for ; Wed, 4 Apr 2001 10:16:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjho21325; Wed, 4 Apr 2001 14:13:33 GMT Received: by mail-control.mail.uu.net id QQkjho04816 for mpls-outgoing; Wed, 4 Apr 2001 14:12:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjho04770 for ; Wed, 4 Apr 2001 14:12:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjho28744 for ; Wed, 4 Apr 2001 14:11:44 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjho18232 for ; Wed, 4 Apr 2001 14:11:44 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA15925 for mpls@uu.net; Wed, 4 Apr 2001 10:11:43 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjho00653 for ; Wed, 4 Apr 2001 14:07:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjho20414 for ; Wed, 4 Apr 2001 14:06:48 GMT Received: from viva.vivacenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.132]) id QQkjho15938 for ; Wed, 4 Apr 2001 14:06:48 GMT Received: from AMALIS.vivacenet.com [216.112.176.96] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id AA282F370216; Wed, 04 Apr 2001 06:05:28 -0700 Message-Id: <5.0.2.1.2.20010404095955.03974890@mail.vivacenetworks.com> X-Sender: Andy.Malis@mail.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 10:05:25 -0400 To: Rajiv Papneja From: "Andrew G. Malis" Subject: Re: MPLS 2001 International Conference - Oct. 7-9 Cc: MPLS@gmu.edu, mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Rajiv, I've haven't yet seen a call for program committee participation and/or abstracts for talks. As a member of the program committee and speaker for all of the past years of the conference, I certainly would like to continue in that role. I don't think we've had the opportunity to meet in the past, so you may not be immediately familiar with my current roles as the chair of the MPLS Forum's Technical Committee and their VP of Technology in addition to my work at the IETF. Anyway, I would like to continue to add value to the conference. Best regards, Andy Malis Chief Technologist, Vivace Networks ---------- At 4/3/2001 09:32 PM -0400, Rajiv Papneja wrote: >Dear friends, > > The MPLS 2001 International Conference will again be hosted jointly >by UUNET Technologies and Advanced Internet Lab, and will be held at >the Omni Shoreham Hotel in Washington, DC, October 7-9, 2001. > > > The conference begins with tutorials on Sunday October 7 and continues >with full-day technical sessions on Monday and Tuesday, October 8-9. A >series of public Interoperability demonstrations will follow on October >10-12 at Advanced Internet Lab. Conference information, technical >program, and other details, including the testing and public >Interoperability events will be made available at http://www.mpls2001.com. > > The technical program for MPLS 2001 will be unique, as were the >programs for previous events in this series. MPLS 98 was the first >conference on the topic of Multiprotocol Label Switching. The >attendance has continued to grow each year. Last year, at MPLS 2000, >17 sponsors exhibited their products and services throughout the >conference. This year, we have reserved a larger space to accommodate >additional sponsors. If you are interested in securing exhibit space at >MPLS 2001, please contact sponsor@mpls2001.com, 703.218.3770 (phone), or >703.218.3780 (fax). Three categories of sponsorship are available. >Exhibit space is limited and will be committed on a first-come, >first-served basis. > > For additional information, hotel reservation, last year's sponsors >please visit http://www.mpls2001.com. > > We look forward to seeing you in the "MPLS 2001 International Conference." >Thanks. > > Regards, > - Rajiv > >******************************** >Rajiv Papneja (GRA) >Advanced Internet Laboratory >George Mason University, >G10, Johnson Center, >Fairfax, VA 22030-4444 >Tel: 703.993.4703 >email: rpapneja@osf1.gmu.edu >******************************** ________________________________________________________________________ Andrew G. Malis Andy.Malis@vivacenetworks.com phone:408-383-7223 Vivace Networks/2730 Orchard Parkway/San Jose, CA 95134/fax:408-904-4748 http://www.vivacenetworks.com From owner-mpls@UU.NET Wed Apr 4 11:31:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23216 for ; Wed, 4 Apr 2001 11:31:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjht09655; Wed, 4 Apr 2001 15:29:06 GMT Received: by mail-control.mail.uu.net id QQkjht27679 for mpls-outgoing; Wed, 4 Apr 2001 15:28:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjht27668 for ; Wed, 4 Apr 2001 15:28:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjht04284 for ; Wed, 4 Apr 2001 15:26:06 GMT Received: from babelbrox.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: babelbrox.axion.bt.co.uk [132.146.16.6]) id QQkjht06253 for ; Wed, 4 Apr 2001 15:26:05 GMT Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) by babelbrox (local) with SMTP; Wed, 4 Apr 2001 16:25:47 +0100 Received: from ip-engineering.bt.com by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id QAA07850; Wed, 4 Apr 2001 16:25:45 +0100 (BST) Message-Id: <200104041525.QAA07850@celiborn.ip-engineering.bt.com> X-Mailer: exmh version 2.0.3 9/28/98 To: giles@goneto.net cc: mpls@UU.NET Subject: Re: FW: MPLS OAM (was Re: Last Call on RSVP Label Allocation for Bac kup Tunnels) In-reply-to: Your message of "Wed, 04 Apr 2001 15:51:16 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Apr 2001 16:25:45 +0100 From: Peter Willis Sender: owner-mpls@UU.NET Precedence: bulk From experience I think that the "rare" faults are not as "rare" as us network operators would like. I have colleagues who manage a national network with 9000 routers in it and a global network with hundreds of routers in it. This network has a "rare" fault about every 3 months. A "rare" fault is something like a router sending packets in a different direction to that indicated by the routers' routing table. In other words the user plane isn't doing what the control plane thinks. A much more common fault is bugs in the implementation of the control plane protocols. I've seen routers "forget" their routes many times. This is so common a fault I considered writing a script to check all the routing tables in all the routers to look for these "forgetting" events. Why wouldn't LSRs manifest similar bugs which would result in the LSPs going down in a manner the control plane protocols would not detect? According to Dave Cooper (gblx.net) MPLS implementations do manifest these types of faults. So "rare" events do happen and without some monitoring functions built into the routers and the protocols then Network Operators have to resort to customers detecting faults or create their own OAM systems to monitor the network. So you can debate how many milliseconds it takes to restore a LSP but milliseconds down-time is going to pale into insignificance against the hours of downtime it takes to detect and fix problems caused by software bugs. I'm not complaining about bugs in router software, all software has bugs, I'm complaining about the lack of capability to detect faults caused by the bugs. Giles Heron wrote: > Seriously I think it is the case that for MPLS the control and user > plane will almost always go through the same path ..... > I think a fair assumption is to say that if the LSP fails from the > control plane point of view then it is considered to be down. I know > this doesn't catch the "rare" cases, but I think it is workable for all > intents and purposes (especially since the OAM code to catch the "rare" > cases would have failure modes itself!) Peter. From owner-mpls@UU.NET Wed Apr 4 11:33:57 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23294 for ; Wed, 4 Apr 2001 11:33:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjhu02401; Wed, 4 Apr 2001 15:31:24 GMT Received: by mail-control.mail.uu.net id QQkjhu27817 for mpls-outgoing; Wed, 4 Apr 2001 15:30:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjht27724 for ; Wed, 4 Apr 2001 15:29:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjht09618 for ; Wed, 4 Apr 2001 15:28:00 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjht26181 for ; Wed, 4 Apr 2001 15:28:00 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA22150 for mpls@uu.net; Wed, 4 Apr 2001 11:27:59 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjht27600 for ; Wed, 4 Apr 2001 15:27:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjht00305 for ; Wed, 4 Apr 2001 15:24:46 GMT Received: from viva.vivacenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.132]) id QQkjht04778 for ; Wed, 4 Apr 2001 15:24:46 GMT Received: from AMALIS.vivacenet.com [216.112.176.96] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id ACBC2855020A; Wed, 04 Apr 2001 07:24:44 -0700 Message-Id: <5.0.2.1.2.20010404112334.04274b90@mail.vivacenetworks.com> X-Sender: Andy.Malis@mail.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 11:24:42 -0400 To: mpls@UU.NET From: "Andrew G. Malis" Subject: Sorry about that Cc: Andy.Malis@vivacenetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I just noticed, way too late, that I neglected to check the cc: on my previous email; I'm very sorry about that! Andy From owner-mpls@UU.NET Wed Apr 4 11:35:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23368 for ; Wed, 4 Apr 2001 11:35:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjhu06041; Wed, 4 Apr 2001 15:33:19 GMT Received: by mail-control.mail.uu.net id QQkjhu27975 for mpls-outgoing; Wed, 4 Apr 2001 15:32:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjhu27925 for ; Wed, 4 Apr 2001 15:32:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjhu14031 for ; Wed, 4 Apr 2001 15:31:51 GMT Received: from ns02.newbridge.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: ns02.newbridge.com [192.75.23.75]) id QQkjhu13095 for ; Wed, 4 Apr 2001 15:31:50 GMT Received: (qmail 14831 invoked from network); 4 Apr 2001 15:30:08 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 4 Apr 2001 15:30:08 -0000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Wed, 4 Apr 2001 11:28:49 -0400 Received: from alcatel.com ([138.120.52.154]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA7225; Wed, 4 Apr 2001 11:28:47 -0400 Message-Id: <3ACB3DAF.CBFEC282@alcatel.com> Date: Wed, 04 Apr 2001 11:28:47 -0400 From: Robin Park Organization: Alcatel CID X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: Dave Danenberg , neil.2.harrison@bt.com, giles@goneto.net, mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: <200104032058.QAA89148@workhorse.fictitious.org> Content-Type: multipart/mixed; boundary="------------77D7BFECF73FA26A09450C19" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------77D7BFECF73FA26A09450C19 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dave, Alcatel's implementation of MPLS does support statically configured LSPs. I would guess other vendors support statically configured LSPs. Whether service providers widely use statically configured LSPs is another question, but a blanket assumption that all LSPs are configured via signaling may not be true. In these cases, the control-plane would not detect data-plane failures. Regards, Robin. Curtis Villamizar wrote: > In message <0E2DFCE7E586904DA0F583CB5EAD73CC0312F9@WATERTOWN.litchfieldcomm.com > >, "Dave Danenberg" writes: > > Neil/Giles, > > > > I've been watching your exchange with interest. Especially when > > discussing > > whether MPLS signaling can be used reliably for data-plane failure > > detection. > > So let me just throw this into the discussion... Won't most MPLS > > deployments > > support statically configured MPLS connections? > > No. In fact, none so far AFAIK. > > Curtis --------------77D7BFECF73FA26A09450C19 Content-Type: text/x-vcard; charset=us-ascii; name="robin.park.vcf" Content-Description: Card for Robin Park Content-Disposition: attachment; filename="robin.park.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Park;Robin tel;work:(613) 784 6861 x-mozilla-html:TRUE org:Alcatel CID version:2.1 email;internet:robin.park@alcatel.com adr;quoted-printable:;;600 March Road=0D=0APO Box 13600;Kanata;Ontario;K2K 2E6;CANADA x-mozilla-cpt:;-12016 fn:
Robin Park
Software Designer
Carrier Internetworking Division
end:vcard --------------77D7BFECF73FA26A09450C19-- From owner-mpls@UU.NET Wed Apr 4 11:47:18 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23700 for ; Wed, 4 Apr 2001 11:47:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjhv08701; Wed, 4 Apr 2001 15:45:25 GMT Received: by mail-control.mail.uu.net id QQkjhu28984 for mpls-outgoing; Wed, 4 Apr 2001 15:44:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjhu28962 for ; Wed, 4 Apr 2001 15:44:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjhu22198 for ; Wed, 4 Apr 2001 15:44:19 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkjhu26233 for ; Wed, 4 Apr 2001 15:44:19 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12640 for ; Wed, 4 Apr 2001 11:44:17 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11037 for ; Wed, 4 Apr 2001 11:44:19 -0400 (EDT) Message-ID: <3ACB415D.285306CA@marconi.com> Date: Wed, 04 Apr 2001 11:44:29 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Checksum in RSVP messages References: <3ACADB24.8570FC29@netit.alcatel.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Roberto Guglielmi wrote: > > Hi all, > I have a couple of questions about calculating RSVP checksum in the > common header. > > Our SW product implementing RSVP calculates the checksum making the > one's complement of sum two-by-two of the bytes contained in the > messages. > The problem is that using the Sniffer protocol analizer to decode the > messages sent by the nodes, the checksum seems to be wrong. > > The RFC 2205 says the checksum is calculated in the following way: > > "The one's complement of the one's complement sum of the > message , with the checksum field replaced by zero..." > > Are the bytes within the message supposed to be added one-by-one or > two-by-two? > > Are we supposed to make the one's complement of the message, make the > sum and, at the end, the one's complement of the sum? It's the same algorithm used to generate IP header and TCP checksums. RFC 1071 explains the algorithm, along with detailed explanations, and sample code in C and some assembly languages. -- David From owner-mpls@UU.NET Wed Apr 4 12:04:01 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24295 for ; Wed, 4 Apr 2001 12:04:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjhw26038; Wed, 4 Apr 2001 16:01:15 GMT Received: by mail-control.mail.uu.net id QQkjhw02990 for mpls-outgoing; Wed, 4 Apr 2001 16:00:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjhw02935 for ; Wed, 4 Apr 2001 16:00:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjhw16045 for ; Wed, 4 Apr 2001 16:00:14 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkjhw15481 for ; Wed, 4 Apr 2001 16:00:13 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA29585; Wed, 4 Apr 2001 09:00:06 -0700 (PDT) Message-Id: <200104041600.JAA29585@red.juniper.net> To: "Loureiro, Rodrigo" cc: "'mpls@uu.net'" Subject: Re: VPN/MPLS question In-Reply-To: Your message of "Tue, 03 Apr 2001 16:41:08 -0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62359.986400006.1@juniper.net> Date: Wed, 04 Apr 2001 09:00:06 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Rodrigo, > Hi all, > > Thinking about use EBGP sessions between the PE-CE connection, in order to > insert customer's routing information into the VPN routing table and provide > layer 3 redundancy for the customer's site using BGP, a scalability problem > arises: > > Once BGP has a loop avoidance mechanism based on the as-path vector, and > considering that i will not summarize the prefixes in the PEs, every site > participating in the VPN (peer) should have a different private autonomous > system. not necessarily. See Section 7 of draft-rosen-rfc2547bis-03.txt (and specifically text on page 5 of that document) for more on this. > Once i have only 1014 private as-numbes, this could represent a > scalability problem, for example, if i think about a big extranet client. Is > it correct? see my previous comment. Yakov. From owner-mpls@UU.NET Wed Apr 4 12:17:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24628 for ; Wed, 4 Apr 2001 12:17:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjhw05033; Wed, 4 Apr 2001 16:14:53 GMT Received: by mail-control.mail.uu.net id QQkjhw19062 for mpls-outgoing; Wed, 4 Apr 2001 16:14:20 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjhw19040 for ; Wed, 4 Apr 2001 16:14:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjhw29841 for ; Wed, 4 Apr 2001 16:13:53 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkjhw03852 for ; Wed, 4 Apr 2001 16:13:53 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 56CEB94006; Wed, 4 Apr 2001 12:13:53 -0400 (EDT) Message-ID: <3ACB4841.4C92AA14@sandburst.com> Date: Wed, 04 Apr 2001 12:13:53 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com Cc: George Swallow , Adrian Farrel , pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET Subject: Re: Last Call on LDP Fault Tollerance References: <200104040011.UAA89975@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, The discussion of whether or not a network operator would use LDP - with or without fault tolerance - as a mechanism for establishing LSPs for the purpose of transporting other LSPs is a side-track, down which I do not wish to proceed any farther. I raised the point only to establish that there is another perspective and I believe I have accomplished that. Back on the issue you raised. As anyone who might have come close to correctly implementing LDP will know, routing drives LSP set-up and tear down. If an LSR looses a peer in a routing protocol (pick one, any one), routes are re-computed. For routes that have changed upon re-computation, LDP gives a rigorous set of procedures for determination of appropriate response with respect to existing LSPs (and - for the liberal retention case - validity of labels not even in use). Note that LDP procedures are defined indepedent from the specific _internal_ procedures that a router uses to determine that a route has changed. If you do not feel that this is the case, then I suggest you raise this issue with the working group as an issue with LDP rather than with LDP FT. In reading the current LDP FT specification, you probably discovered that it describes exactly how a fault tolerant LDP implementation is expected to deal with labels that are made invalid for the entire period during which it is unable to obtain confirmation that a peer has been informed of the invalidation. If there are details of this process that are not clear to you, please address those details. If, as I assert, LDP procedures are independent of specific routing protocols and LDP FT defines procedures for ensuring that LDP procedures are adhered to across multiple sessions, then LDP FT is equally independent of specific routing protocols. Hopefully, this will clear up any fear, uncertainty or other doubts that this discussion may have raised. :-) -- Eric Gray You wrote: > In message <3ACA41AB.2A3ACB59@sandburst.com>, Eric Gray writes: > > Curtis, > > > > As I understand it, LDP is the preferred protocol for use > > with MPLS BGP when BGP peers are not adjacent with > > respect to an MPLS domain. Suppose that MPLS BGP is > > used to establish many VPN services which are possibly > > being used to provide a label switching service to enterprise > > customers. > > > > For that matter, suppose that LDP is being used to signal > > and maintain VPN technology's LSPs. > > Eric, > > You wouldn't be using LDP on the outer tunnel, just the inner VPN > tunnel. The outer tunnel is a RSVP-TE tunnel. We are already lab > testing this at a customer and it interoperates nicely with other > people's BGP/VPN LDP implementations. > > Because the TE tunnel is rerouted around a failure the LDP adjacency > that ride inside the TE tunnels never go down. The LDP TCP connection > sees some temporary loss at worst and then continues as if no topology > change occurred because the logical adjacency never went down. This > works as long as there is a brief holddown on the TE tunnel and it > reroutes before the holddown expires. In practice works great. > > Where you want to maintain LDP (and IGP) adjacency is where a router > is reloaded for something like software upgrade and nothing else in > the IGP changes during the reload time. If you have two route > processors on the router that was reloaded, that should be a switch in > well under a second. Rumor has it that some routers with one route > processor take a few minutes to reload so for those, if the topology > changes you'd rather route around them. > > So please remind me, exactly what was the point of your objection. > :-) > > Curtis > > > You wrote: > > > > > In message <3ACA3769.1E1C006F@sandburst.com>, Eric Gray writes: > > > > > > > > I also suspect that you may be understating the advantages > > > > of maintaining session context. Consider the impact to the > > > > network if LSPs are dropped lightly and these LSP are in turn > > > > being used to carry (stacked) LSPs. > > > > > > > > -- > > > > Eric Gray > > > > > > You wouldn't be using LDP in that case. ;-) > > > > > > Curtis From owner-mpls@UU.NET Wed Apr 4 12:29:09 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24981 for ; Wed, 4 Apr 2001 12:29:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjhx17716; Wed, 4 Apr 2001 16:26:13 GMT Received: by mail-control.mail.uu.net id QQkjhx20395 for mpls-outgoing; Wed, 4 Apr 2001 16:25:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjhx20371 for ; Wed, 4 Apr 2001 16:25:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjhx22158 for ; Wed, 4 Apr 2001 16:24:26 GMT Received: from hclhprnd.hclt.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.5]) id QQkjhx20595 for ; Wed, 4 Apr 2001 16:24:25 GMT Received: from gayatri.hclt.com (gayatri.hclt.com [192.168.232.199]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id WAA19173 for ; Wed, 4 Apr 2001 22:23:59 +0530 Received: from MALLIKPC ([192.168.232.110]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2H69ZFA5; Wed, 4 Apr 2001 21:54:14 +0530 Message-ID: <007601c0bd23$e9bf5770$6ee8a8c0@hclt.com> From: "gopinathg" To: Subject: CR-LDP Label Release ... Date: Wed, 4 Apr 2001 21:55:37 +0530 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 I had a question regarding Label Release in CR-LDP Can we use a single Label Release message for releasing more than one CR-LSP ? From owner-mpls@UU.NET Wed Apr 4 13:04:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25910 for ; Wed, 4 Apr 2001 13:04:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjia18345; Wed, 4 Apr 2001 17:00:33 GMT Received: by mail-control.mail.uu.net id QQkjia23430 for mpls-outgoing; Wed, 4 Apr 2001 17:00:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjhz23373 for ; Wed, 4 Apr 2001 16:59:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjhz15062 for ; Wed, 4 Apr 2001 16:59:40 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkjhz17115 for ; Wed, 4 Apr 2001 16:59:39 GMT Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP; Wed, 4 Apr 2001 18:00:09 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 4 Apr 2001 17:58:18 +0100 Message-ID: To: giles@goneto.net Cc: mpls@UU.NET Subject: RE: MPLS OAM (was Re: Last Call on RSVP Label Allocation for Bac kup Tunnels) Date: Wed, 4 Apr 2001 17:58:15 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Giles Heron [mailto:giles@goneto.net] wrote 04 April 2001 12:58 > > I think a fair assumption is to say that if the LSP fails from the > control plane point of view then it is considered to be down. I know > this doesn't catch the "rare" cases, but I think it is > workable for all > intents and purposes (especially since the OAM code to catch > the "rare" > cases would have failure modes itself!) NH=> I note Dave Cooper does not agree with you nor do the people who run our IP networks.....and I see that Peter Willis has already responded with our experiences of these (not so) 'rare' defects due to mismatches between control and user planes. > > > - where are the 'consequent actions' on failure specified? > > Presumably in the case of George's draft the "consequent > action" should > be to reroute over a backup tunnel? NH=> But there are other consequent actions that need to be considered, and invoking a control-plane restoration action is only one of these (assuming this option is available). Others to consider are: - is there a potential security breach (eg leaking customer traffic) such that traffic squelching is required? - is there a need to raise an alarm? - what information needs to be sent to the NMS? - what needs to be sent to the client layers supported by the failed layer.....not a big issue when one's only focus is intra-domain (since one can, perhaps, appeal to NMS correlation), but it is an issue that should be considered for the inter-domain case (could result in geographically/organisationally disjoint alarms and uncessary Ops actions)? - what local action is needed in the NE, eg has the defect caused a (i) QoS perf hit only, (ii) a short-break or (iii) an unavailability event.....and the in latter 2 cases I would argue that QoS count aggregation (eg in the MIB say) needs suspending? - is there any impact (from the above) into the SLAs that affect customer billing and hence infomation needs to be transferred to the OSS? > > > - where is the definition of availability specified? > > I'd specify it as the % of time for which the LSP is up from > the control > plane point of view? NH=> It would need a more precise definition than that since we would want consistency across all vendors and for all customer SLAs. > > > - and how can we move on to define QoS > metrics/objectives if we can't > > define availablity? > > Agreed - so let's take a simple definition as above. NH=> Glad we have at least 1 point of common ground.....but it needs a proper definition, and this isn't one. > > > As an operator we are coming under increasing pressure to > be able to define > > these (esp for VPN customers), and in any case these are > issues that should > > be thought about up-front and not later (when it might be > too difficult to > > make changes). It seems clear that you don't have any > answers to these > > questions, but you also don't have any alternative proposals either. > > I'd say I just made a perfectly workable proposal - from the point of > view of a pragmatist who has to build and run a production network. I > suspect your viewpoint is somewhat different. NH=> Not really, but I do look ahead further than what is deployed today. Believe it or not, I honestly thought we had something simple that operators would like......clearly not. > > > BTW - I am surprised you thought the proposals complex. > This is about as > > simple as we could make them, and Shahram (who works for a > chip supplier) > > did not think these complex. > > I'd say 29 pages for a first revision of a draft is pretty meaty. > Especially when the P flow and support for merging LSPs are > FFS, and the > figures are all missing? NH=> The figures are missing since they don't port to ascii easily. On the other points: - the basic premise is very simple.....a 1s CV keepalive with unique source ID (it has to be a fixed period to ensure consistent/simple defect entry/exit criteria) - if the MIBs can do detailed ingress/egress pkt/octet counting then we don't need the P flow I guess - if you don't care about alarms storms and the inter-domain defect location info then you can dispense with the FDI (consequent action) too.....I expected this one to cause the most trouble (though its funny how some people take it for granted that an FDI will be provided from other server layer technologies, like SDH, when they want/appeal defect detection (in a client layer), and seem to ignore that its only there because someone specified the defects properly in a *different* layer network) - merging LSPs cannot be easily dealt with in the user-plane as I am sure you appreciate (and there are many other areas that make this FFS)....but I don't think one would use them for important traffic (such as VPNs perhaps?) So......the OAM could indeed be very, very simple and still give strong customer protection and reasonable decent Ops help. From owner-mpls@UU.NET Wed Apr 4 14:41:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28625 for ; Wed, 4 Apr 2001 14:41:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjig01640; Wed, 4 Apr 2001 18:39:05 GMT Received: by mail-control.mail.uu.net id QQkjig05616 for mpls-outgoing; Wed, 4 Apr 2001 18:38:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjig05604 for ; Wed, 4 Apr 2001 18:38:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjig25385 for ; Wed, 4 Apr 2001 18:38:00 GMT Received: from email.nist.gov by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.nist.gov [129.6.2.7]) id QQkjig15012 for ; Wed, 4 Apr 2001 18:37:59 GMT Received: from antd.nist.gov (octopus.antd.nist.gov [129.6.60.19]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id OAA28473 for ; Wed, 4 Apr 2001 14:37:55 -0400 (EDT) Message-ID: <3ACB9457.845B29FB@antd.nist.gov> Date: Wed, 04 Apr 2001 14:38:31 -0700 From: SuKyoung Lee X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Question about 1:n and m:n protections Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello. I have been working on the analysis of restoration time and backup path provisioning in protection. Especially, for 1:n and m:n case, is there any detailed mechanism about how many working paths could be protected by 1 backup path and determining the number of backup paths for n working paths? If anyone knows some general mechanisms, please let me know those to compare my work with. -- SuKyoung Lee High Speed Network Technologies Group Advanced Network Technologies Division National Institute of Standards & Technology Email: sukyoung@antd.nist.gov Phone: 301-975-4780 From owner-mpls@UU.NET Wed Apr 4 15:20:18 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29348 for ; Wed, 4 Apr 2001 15:20:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjij28306; Wed, 4 Apr 2001 19:17:37 GMT Received: by mail-control.mail.uu.net id QQkjij25499 for mpls-outgoing; Wed, 4 Apr 2001 19:17:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjij25477 for ; Wed, 4 Apr 2001 19:16:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjii15563 for ; Wed, 4 Apr 2001 19:14:52 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkjii03129 for ; Wed, 4 Apr 2001 19:14:51 GMT Received: from goneto.net (host62-7-186-63.host.btclick.com [62.7.186.63]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id CFC6415F7E5; Wed, 4 Apr 2001 20:14:48 +0100 (BST) Message-ID: <3ACB7F6B.EB88EA0E@goneto.net> Date: Wed, 04 Apr 2001 21:09:15 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Robin Park Cc: curtis@avici.com, Dave Danenberg , neil.2.harrison@bt.com, mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: <200104032058.QAA89148@workhorse.fictitious.org> <3ACB3DAF.CBFEC282@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robin Park wrote: > > Dave, > > Alcatel's implementation of MPLS does support statically configured LSPs. I would > guess other vendors support statically configured LSPs. Juniper certainly does. > Whether service providers widely use statically configured LSPs is another > question, but a blanket assumption that all LSPs are configured via signaling may > not be true. I've yet to see a live deployment with static LSPs, but then I've only got involved with 3 or 4 live MPLS networks. Once or twice I have considered using static LSPs for something - for about five seconds in each case! > In these cases, the control-plane would not detect data-plane failures. True. But in general if you choose to use statically configured LSPs then I suspect a pretty hefty dose of caveat emptor should apply - regardless of whether you have any OAM signalling... Giles > > Regards, > > Robin. > > Curtis Villamizar wrote: > > > In message <0E2DFCE7E586904DA0F583CB5EAD73CC0312F9@WATERTOWN.litchfieldcomm.com > > >, "Dave Danenberg" writes: > > > Neil/Giles, > > > > > > I've been watching your exchange with interest. Especially when > > > discussing > > > whether MPLS signaling can be used reliably for data-plane failure > > > detection. > > > So let me just throw this into the discussion... Won't most MPLS > > > deployments > > > support statically configured MPLS connections? > > > > No. In fact, none so far AFAIK. > > > > Curtis -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Wed Apr 4 17:36:45 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02484 for ; Wed, 4 Apr 2001 17:36:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjis24490; Wed, 4 Apr 2001 21:34:05 GMT Received: by mail-control.mail.uu.net id QQkjis09965 for mpls-outgoing; Wed, 4 Apr 2001 21:33:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjis09954 for ; Wed, 4 Apr 2001 21:33:21 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjis17245 for ; Wed, 4 Apr 2001 21:33:17 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjis05629 for ; Wed, 4 Apr 2001 21:33:16 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA25843 for mpls@uu.net; Wed, 4 Apr 2001 17:33:16 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjis09930 for ; Wed, 4 Apr 2001 21:32:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjis05570 for ; Wed, 4 Apr 2001 21:32:43 GMT Received: from che-cse-113.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-113.cisco.com [161.44.143.19]) id QQkjis22946 for ; Wed, 4 Apr 2001 21:32:43 GMT Received: (from eosborne@localhost) by che-cse-113.cisco.com (8.8.5/CA/950118) id RAA12042; Wed, 4 Apr 2001 17:31:44 -0400 (EDT) Date: Wed, 4 Apr 2001 17:31:44 -0400 From: Eric Osborne To: Giles Heron Cc: Robin Park , curtis@avici.com, Dave Danenberg , neil.2.harrison@bt.com, mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels Message-ID: <20010404173144.B12024@che-cse-113.cisco.com> References: <200104032058.QAA89148@workhorse.fictitious.org> <3ACB3DAF.CBFEC282@alcatel.com> <3ACB7F6B.EB88EA0E@goneto.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ACB7F6B.EB88EA0E@goneto.net>; from giles@goneto.net on Wed, Apr 04, 2001 at 09:09:15PM +0100 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, Apr 04, 2001 at 09:09:15PM +0100, Giles Heron wrote: > Robin Park wrote: > > > > Dave, > > > > Alcatel's implementation of MPLS does support statically configured LSPs. I would > > guess other vendors support statically configured LSPs. There's a few ways this can be defined. Do you mean "LSPs which are not signalled via RSVP, but have crossconnect label values manually configured at each hop", or "LSPs which have a per-hop path statically defined on the headend, which can be configured as to never ever change, but which the headend signals via RSVP"? eric From owner-mpls@UU.NET Wed Apr 4 19:12:26 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04313 for ; Wed, 4 Apr 2001 19:12:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjiy16565; Wed, 4 Apr 2001 23:09:33 GMT Received: by mail-control.mail.uu.net id QQkjiy20757 for mpls-outgoing; Wed, 4 Apr 2001 23:08:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjiy20740 for ; Wed, 4 Apr 2001 23:08:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjiy13808 for ; Wed, 4 Apr 2001 23:07:53 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjiy00714 for ; Wed, 4 Apr 2001 23:07:51 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id TAA92741; Wed, 4 Apr 2001 19:05:41 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104042305.TAA92741@workhorse.fictitious.org> To: afarrel@movaz.com cc: curtis@avici.com, pjb@metaswitch.com, philipma@nortelnetworks.com, eric.gray@sandburst.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on LDP Fault Tolerance In-reply-to: Your message of "Tue, 03 Apr 2001 21:45:45 EDT." <4F9E13BCC53ED411A629009027E8D00C043336DA@msg001.dcat.ops.broadbandoffice.net> Date: Wed, 04 Apr 2001 19:05:41 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4F9E13BCC53ED411A629009027E8D00C043336DA@msg001.dcat.ops.broadbando ffice.net>, afarrel@movaz.com writes: > Curtis, > > I can't see any reason not to point out that a "give up and run away" type > of timer can be overridden by other events. The one you suggest > (significant IGP change) could well be applicable to LDP, although I think > it is less significant in CR-LDP. > > I find... > > There appears to be a school of thought where it is deemed beneficial > > to keep forwarding state intact in only very limited cases such as > > midnight controlled reload of routers for purposes such as software > > upgrade. > ...odd. When a line card fails I should like to be able to swap to a new > card and continue forwarding data with only a very short (10s of ms) break. > Adrian > -- > Adrian Farrel > Movaz Networks Inc > afarrel@movaz.com When a line card fails, that line card will still be in the box for at least a few minutes, more likely the better part of an hour, maybe longer. I don't know of any technician that can swap a line card in 10 msec. I also don't know of any line card that can reboot in 10 msec. When a line card fails if there is a TE tunnel and local-protect on the TE tunnel, then the switch over is very fast. If it is LDP without TE or TE without local protect, the 10s of msec is very likely not acheived. That has absolutely nothing to do with LDP-FT so I don't see why you brought it up. At issue with LDP-FT is when the route processor fails and the line card does not fail. That is when the forwarding entries remain intact and the LDP adjacency will be back shortly. That is the case if the route processor's software is reloaded for software upgrade. As I said, I'll leave it up to the authors whether they want to make any change to the document. It sounds like you don't. That's fine. Curtis From owner-mpls@UU.NET Wed Apr 4 19:53:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04716 for ; Wed, 4 Apr 2001 19:53:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjjb29472; Wed, 4 Apr 2001 23:51:26 GMT Received: by mail-control.mail.uu.net id QQkjjb24613 for mpls-outgoing; Wed, 4 Apr 2001 23:50:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjjb24607 for ; Wed, 4 Apr 2001 23:50:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjjb21211 for ; Wed, 4 Apr 2001 23:50:01 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjjb27046 for ; Wed, 4 Apr 2001 23:50:00 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id TAA92895; Wed, 4 Apr 2001 19:49:36 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104042349.TAA92895@workhorse.fictitious.org> To: Robin Park cc: curtis@avici.com, Dave Danenberg , neil.2.harrison@bt.com, giles@goneto.net, mpls@UU.NET Reply-To: curtis@avici.com Subject: static MPLS (was Re: Last Call on RSVP Label Allocation for Backup Tunnels) In-reply-to: Your message of "Wed, 04 Apr 2001 11:28:47 EDT." <3ACB3DAF.CBFEC282@alcatel.com> Date: Wed, 04 Apr 2001 19:49:36 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3ACB3DAF.CBFEC282@alcatel.com>, Robin Park writes: > This is a multi-part message in MIME format. > --------------77D7BFECF73FA26A09450C19 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Dave, > > Alcatel's implementation of MPLS does support statically configured LSPs. I > would > guess other vendors support statically configured LSPs. Ours supports this feature as well. So does Cisco and Juniper. > Whether service providers widely use statically configured LSPs is another > question, but a blanket assumption that all LSPs are configured via signaling > may > not be true. My only point was that I know of no one that is building a network using statically configured LSPs. The assumption was made by Dave that the opposite was true. I was just commenting on the validity of that assumption. > In these cases, the control-plane would not detect data-plane failures. Providing measurement capabilities to better deal with rare errors that may be undetectable when using an unused feature sounds like a weak argument. I suppose it would be up to the TE-WG whether that constitutes a requirement. In the ITU maybe. :-) > Regards, > > Robin. The subject says "Last Call on RSVP Label Allocation for Backup Tunnels" and we have strayed off this topic. Curtis From owner-mpls@UU.NET Wed Apr 4 20:33:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05141 for ; Wed, 4 Apr 2001 20:33:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjje20862; Thu, 5 Apr 2001 00:31:01 GMT Received: by mail-control.mail.uu.net id QQkjje14246 for mpls-outgoing; Thu, 5 Apr 2001 00:30:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjje14238 for ; Thu, 5 Apr 2001 00:30:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjjd06867 for ; Thu, 5 Apr 2001 00:29:56 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjjd19122 for ; Thu, 5 Apr 2001 00:29:54 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id UAA92978; Wed, 4 Apr 2001 20:20:34 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104050020.UAA92978@workhorse.fictitious.org> To: Eric Gray cc: curtis@avici.com, George Swallow , Adrian Farrel , pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on LDP Fault Tollerance In-reply-to: Your message of "Wed, 04 Apr 2001 12:13:53 EDT." <3ACB4841.4C92AA14@sandburst.com> Date: Wed, 04 Apr 2001 20:20:33 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3ACB4841.4C92AA14@sandburst.com>, Eric Gray writes: > Curtis, > > The discussion of whether or not a network operator would > use LDP - with or without fault tolerance - as a mechanism > for establishing LSPs for the purpose of transporting other > LSPs is a side-track, down which I do not wish to proceed > any farther. I raised the point only to establish that there is > another perspective and I believe I have accomplished that. I agree. Whether LDP or CR-LDP would ever be used on the outer tunnel is a separate issue. > Back on the issue you raised. As anyone who might have > come close to correctly implementing LDP will know, routing > drives LSP set-up and tear down. If an LSR looses a peer in > a routing protocol (pick one, any one), routes are re-computed. > For routes that have changed upon re-computation, LDP gives > a rigorous set of procedures for determination of appropriate > response with respect to existing LSPs (and - for the liberal > retention case - validity of labels not even in use). > > Note that LDP procedures are defined indepedent from the > specific _internal_ procedures that a router uses to determine > that a route has changed. If you do not feel that this is the > case, then I suggest you raise this issue with the working > group as an issue with LDP rather than with LDP FT. If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went down, a topology change at D-E (D-E went down) may make the path A-B-C a poor choice. C may have decided that the best path is by way of A since D-E is unavailable and is dutifully trying to inform B of the situation with a Label Withdraw, who will take note of it and inform A in due time after its finished rebooting. In your example on page 24, C would play the role of P2 and queue the label withdraw. B would be P1. A is on the other side of P1. Maybe I'm missing something. > In reading the current LDP FT specification, you probably > discovered that it describes exactly how a fault tolerant LDP > implementation is expected to deal with labels that are made > invalid for the entire period during which it is unable to obtain > confirmation that a peer has been informed of the invalidation. > If there are details of this process that are not clear to you, > please address those details. Ok. I just went through it again and I don't see how the above example is handled. Maybe I'm just dense but I missed it and I'd like you to explain how the LDP-FT procedures handle the above example in the event that it take B some 20-30 seconds to come back up. > If, as I assert, LDP procedures are independent of specific > routing protocols and LDP FT defines procedures for ensuring > that LDP procedures are adhered to across multiple sessions, > then LDP FT is equally independent of specific routing protocols. > > Hopefully, this will clear up any fear, uncertainty or other > doubts that this discussion may have raised. :-) > > -- > Eric Gray Your explanation will certainly clear things up. Thanks in advance, Curtis > You wrote: > > > In message <3ACA41AB.2A3ACB59@sandburst.com>, Eric Gray writes: > > > Curtis, > > > > > > As I understand it, LDP is the preferred protocol for use > > > with MPLS BGP when BGP peers are not adjacent with > > > respect to an MPLS domain. Suppose that MPLS BGP is > > > used to establish many VPN services which are possibly > > > being used to provide a label switching service to enterprise > > > customers. > > > > > > For that matter, suppose that LDP is being used to signal > > > and maintain VPN technology's LSPs. > > > > Eric, > > > > You wouldn't be using LDP on the outer tunnel, just the inner VPN > > tunnel. The outer tunnel is a RSVP-TE tunnel. We are already lab > > testing this at a customer and it interoperates nicely with other > > people's BGP/VPN LDP implementations. > > > > Because the TE tunnel is rerouted around a failure the LDP adjacency > > that ride inside the TE tunnels never go down. The LDP TCP connection > > sees some temporary loss at worst and then continues as if no topology > > change occurred because the logical adjacency never went down. This > > works as long as there is a brief holddown on the TE tunnel and it > > reroutes before the holddown expires. In practice works great. > > > > Where you want to maintain LDP (and IGP) adjacency is where a router > > is reloaded for something like software upgrade and nothing else in > > the IGP changes during the reload time. If you have two route > > processors on the router that was reloaded, that should be a switch in > > well under a second. Rumor has it that some routers with one route > > processor take a few minutes to reload so for those, if the topology > > changes you'd rather route around them. > > > > So please remind me, exactly what was the point of your objection. > > :-) > > > > Curtis > > > > > You wrote: > > > > > > > In message <3ACA3769.1E1C006F@sandburst.com>, Eric Gray writes: > > > > > > > > > > I also suspect that you may be understating the advantages > > > > > of maintaining session context. Consider the impact to the > > > > > network if LSPs are dropped lightly and these LSP are in turn > > > > > being used to carry (stacked) LSPs. > > > > > > > > > > -- > > > > > Eric Gray > > > > > > > > You wouldn't be using LDP in that case. ;-) > > > > > > > > Curtis > > From owner-mpls@UU.NET Wed Apr 4 21:02:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05364 for ; Wed, 4 Apr 2001 21:02:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjjf25858; Thu, 5 Apr 2001 00:58:54 GMT Received: by mail-control.mail.uu.net id QQkjjf16429 for mpls-outgoing; Thu, 5 Apr 2001 00:58:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjjf16413 for ; Thu, 5 Apr 2001 00:58:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjjf15761 for ; Thu, 5 Apr 2001 00:57:53 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjjf16129 for ; Thu, 5 Apr 2001 00:57:50 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id UAA93227; Wed, 4 Apr 2001 20:57:36 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104050057.UAA93227@workhorse.fictitious.org> To: Ping Pan cc: Bora Akyol , Dave Cooper , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels In-reply-to: Your message of "Tue, 03 Apr 2001 19:26:56 PDT." <3ACA8670.59713EAC@juniper.net> Date: Wed, 04 Apr 2001 20:57:36 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3ACA8670.59713EAC@juniper.net>, Ping Pan writes: > Bora Akyol wrote: > > > > Ping > > > > At least in one implementation of APS and FR that I am familiar with, the > > timing to generate a switchover between the two is very close in terms of > > failover and in this particular implementation, APS switchover timing meets > > less than 50 ms. > > > > So I would not immediately rule out FR timing in place of APS. > > > > Bora > > Bora, > > I was pointing out that the fail-over time can be *unpredictable* at > protocol level, where a link failure may trigger heavy processing among > many protocols (such as BGP and RSVP). I have no doubt that if you put a > link detection routine within link card's driver or something, the > failover time can be quite fast. > > - Ping And since 10s of msec is a goal, why would you put it anywhere other than right on the forwarding cards? Curtis From owner-mpls@UU.NET Wed Apr 4 22:24:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07090 for ; Wed, 4 Apr 2001 22:24:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjjl23323; Thu, 5 Apr 2001 02:21:03 GMT Received: by mail-control.mail.uu.net id QQkjjl25834 for mpls-outgoing; Thu, 5 Apr 2001 02:20:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjjl25826 for ; Thu, 5 Apr 2001 02:20:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjjl11907 for ; Thu, 5 Apr 2001 02:19:58 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkjjl22264 for ; Thu, 5 Apr 2001 02:19:57 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 6BE1594006; Wed, 4 Apr 2001 22:19:57 -0400 (EDT) Message-ID: <3ACBD64D.FF5CFBCA@sandburst.com> Date: Wed, 04 Apr 2001 22:19:57 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com Cc: George Swallow , Adrian Farrel , pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET Subject: Re: Last Call on LDP Fault Tollerance References: <200104050020.UAA92978@workhorse.fictitious.org> Content-Type: multipart/alternative; boundary="------------5A9AD1722425D7E612CF999E" Sender: owner-mpls@UU.NET Precedence: bulk --------------5A9AD1722425D7E612CF999E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Curtis, First of all, I thought you were concerned that the fact that the LDP peer relationship was on hold would cause special problems when re-establishing the relationship. It is possible that this is not clear. However - based on your example, it now seems to me that your concern is about forwarding during the TCP outage. This should not be a problem because the specification is intended to support LDP sessions across a TCP connection failure. LDP itself should continue to function - in terms of the procedures defined with respect to the use of LSPs and the impact of route changes. If routing says that a path is not valid, then the corresponding LSP is not either. Please see below. You wrote: > In message <3ACB4841.4C92AA14@sandburst.com>, Eric Gray writes: > > Curtis, > > > > ... > > > Back on the issue you raised. As anyone who might have > > come close to correctly implementing LDP will know, routing > > drives LSP set-up and tear down. If an LSR looses a peer in > > a routing protocol (pick one, any one), routes are re-computed. > > For routes that have changed upon re-computation, LDP gives > > a rigorous set of procedures for determination of appropriate > > response with respect to existing LSPs (and - for the liberal > > retention case - validity of labels not even in use). > > > > Note that LDP procedures are defined indepedent from the > > specific _internal_ procedures that a router uses to determine > > that a route has changed. If you do not feel that this is the > > case, then I suggest you raise this issue with the working > > group as an issue with LDP rather than with LDP FT. > > If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went down, > a topology change at D-E (D-E went down) may make the path A-B-C a > poor choice. C may have decided that the best path is by way of A > since D-E is unavailable and is dutifully trying to inform B of the > situation with a Label Withdraw, who will take note of it and inform A > in due time after its finished rebooting. Since you didn't draw a picture, I'll try to unscramble this alphabet soup. My guess is the picture is supposed to look like this: B /|\ / | \ --- A | D --- E --- |\ | / | | \|/ | | C Z | | W --- X --- Y Is that the case? Also, guessing what you mean by B going down and D-E going down you mean that B is undergoing some kind of software maintenance which results in a temporary TCP failure and, subsequent to this, the link between D and E becomes inoperative. First of all, this is a two-failure scenario and - as such - is notoriously hard to protect against in any case. I can imagine a double failure of a single routing protocol that would produce worse results. But I look at this specific problem and I see the following: B is being upgraded (not rebooted - that would affect more than TCP and TCP-based LDP sessions). The link D-E goes down. Since (A,B,C,D,E,W,X,Y,Z) are all in the same routing domain and all are still active routers (or are you suggesting a third simultaneous failure?), all of them will eventually detect the missing link D-E. C determines that the best route for what used to be the path A-C-D-E is now A-W-X-Y-Z. C drops packets it already has received from A because split horizon dis- allows forwarding packets received from A back to A. In any case, A also will (eventually) know that these packets should go along the path A-W-X-Y-Z so on their merry way they go. Meanwhile - assuming that B is not yet aware of the topology change - B continues to forward packets on the path A-B-D-E but D is unable to forward them via E and sends them on a new path through C-A-W-X-Y-Z - making the path that packets traverse A-B-D-C-A-W-X-Y-Z-E for the smallish period of time it may take A to realize that it should not be forwarding the packets via B (it will eventually know that the path A-B-D-E is no longer valid and that A-B-D-C-A-W-X-Y-Z-E is not the shortest path) and B to realize that it should not be forwarding the packets via D. (Note - I am assuming that there is some reason why the packets went A-B-D-E in the first place - as opposed to A-C-D-E and that reason is related to the fact that they were received on the 'left' interface of A. If this is not the case, then packet will loop along A-B-D-C-A... until A figures out that it shouldn't be sending packets to B that are intended to go through E.) As soon as B becomes aware that the shortest path for packets it is receiving from A for the path A-B-D-E is now through A-W-X-Y-Z-E, it will start dropping packets (split horizon again). As soon as A realizes that the ONLY path to E is A-W-X-Y-Z-E, it will stop forwarding packets to B and C. So the fact that B is not in a position to pass on label release and withdraw messages should be irrelevant to the problem. The labels may be there, but nobody should be using them. B should not continue to forward packet on a bad path and - even if it does, A, C and D will do the right thing. Yes, you will have temporary looping of data, but you would have had the exact same looping data without MPLS, LDP or LDP FT. And, unless B is the ingress for CR-LDP based LSPs, the ingress (at least to the routing domain) _will_ know about the topology change and _will_ be able to re-route LSPs accordingly. Obviously, there are special problems with having the ingress to an explictly routed LSP go off-line. It will not be able to signal new explicit routed LSPs until after it re-establishes LDP peer relationships. But it will not erroneously forward packets on a bad path either. This is just a specific analysis showing how what I said is generally true is true in this specific case. What is it you think the specification needs to add to this? > > > In your example on page 24, C would play the role of P2 and queue the > label withdraw. B would be P1. A is on the other side of P1. Maybe > I'm missing something. > > > In reading the current LDP FT specification, you probably > > discovered that it describes exactly how a fault tolerant LDP > > implementation is expected to deal with labels that are made > > invalid for the entire period during which it is unable to obtain > > confirmation that a peer has been informed of the invalidation. > > If there are details of this process that are not clear to you, > > please address those details. > > Ok. I just went through it again and I don't see how the above > example is handled. Maybe I'm just dense but I missed it and I'd like > you to explain how the LDP-FT procedures handle the above example in > the event that it take B some 20-30 seconds to come back up. As explained above, the example I believe you are citing is handled by LDP and routing based finesse. > > > > If, as I assert, LDP procedures are independent of specific > > routing protocols and LDP FT defines procedures for ensuring > > that LDP procedures are adhered to across multiple sessions, > > then LDP FT is equally independent of specific routing protocols. > > > > Hopefully, this will clear up any fear, uncertainty or other > > doubts that this discussion may have raised. :-) > > > > -- > > Eric Gray > > Your explanation will certainly clear things up. I hope so. > > > Thanks in advance, > > Curtis > > > You wrote: > > > > > In message <3ACA41AB.2A3ACB59@sandburst.com>, Eric Gray writes: > > > > Curtis, > > > > > > > > As I understand it, LDP is the preferred protocol for use > > > > with MPLS BGP when BGP peers are not adjacent with > > > > respect to an MPLS domain. Suppose that MPLS BGP is > > > > used to establish many VPN services which are possibly > > > > being used to provide a label switching service to enterprise > > > > customers. > > > > > > > > For that matter, suppose that LDP is being used to signal > > > > and maintain VPN technology's LSPs. > > > > > > Eric, > > > > > > You wouldn't be using LDP on the outer tunnel, just the inner VPN > > > tunnel. The outer tunnel is a RSVP-TE tunnel. We are already lab > > > testing this at a customer and it interoperates nicely with other > > > people's BGP/VPN LDP implementations. > > > > > > Because the TE tunnel is rerouted around a failure the LDP adjacency > > > that ride inside the TE tunnels never go down. The LDP TCP connection > > > sees some temporary loss at worst and then continues as if no topology > > > change occurred because the logical adjacency never went down. This > > > works as long as there is a brief holddown on the TE tunnel and it > > > reroutes before the holddown expires. In practice works great. > > > > > > Where you want to maintain LDP (and IGP) adjacency is where a router > > > is reloaded for something like software upgrade and nothing else in > > > the IGP changes during the reload time. If you have two route > > > processors on the router that was reloaded, that should be a switch in > > > well under a second. Rumor has it that some routers with one route > > > processor take a few minutes to reload so for those, if the topology > > > changes you'd rather route around them. > > > > > > So please remind me, exactly what was the point of your objection. > > > :-) > > > > > > Curtis > > > > > > > You wrote: > > > > > > > > > In message <3ACA3769.1E1C006F@sandburst.com>, Eric Gray writes: > > > > > > > > > > > > I also suspect that you may be understating the advantages > > > > > > of maintaining session context. Consider the impact to the > > > > > > network if LSPs are dropped lightly and these LSP are in turn > > > > > > being used to carry (stacked) LSPs. > > > > > > > > > > > > -- > > > > > > Eric Gray > > > > > > > > > > You wouldn't be using LDP in that case. ;-) > > > > > > > > > > Curtis > > > > --------------5A9AD1722425D7E612CF999E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Curtis,

    First of all, I thought you were concerned that the fact
that the LDP peer relationship was on hold would cause
special problems when re-establishing the relationship.
It is possible that this is not clear.  However - based on
your example, it now seems to me that your concern is
about forwarding during the TCP outage.  This should not
be a problem because the specification is intended to
support LDP sessions across a TCP connection failure.
LDP itself should continue to function - in terms of the
procedures defined with respect to the use of LSPs and
the impact of route changes.  If routing says that a path
is not valid, then the corresponding LSP is not either.

    Please see below.

You wrote:

In message <3ACB4841.4C92AA14@sandburst.com>, Eric Gray writes:
> Curtis,
>
>     ...

>     Back on the issue you raised.  As anyone who might have
> come close to correctly implementing LDP will know, routing
> drives LSP set-up and tear down.  If an LSR looses a peer in
> a routing protocol (pick one, any one),  routes are re-computed.
> For routes that have changed upon re-computation, LDP gives
> a rigorous set of procedures for determination of appropriate
> response with respect to existing LSPs (and - for the liberal
> retention case - validity of labels not even in use).
>
>     Note that LDP procedures are defined indepedent from the
> specific _internal_ procedures that a router uses to determine
> that a route has changed.  If you do not feel that this is the
> case, then I suggest you raise this issue with the working
> group as an issue with LDP rather than with LDP FT.

If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went down,
a topology change at D-E (D-E went down) may make the path A-B-C a
poor choice.  C may have decided that the best path is by way of A
since D-E is unavailable and is dutifully trying to inform B of the
situation with a Label Withdraw, who will take note of it and inform A
in due time after its finished rebooting.


Since you didn't draw a picture, I'll try to unscramble this
alphabet soup.

My guess is the picture is supposed to look like this:

        B
       /|\
      / | \
 --- A  |  D --- E ---
     |\ | /      |
     | \|/       |
     |  C        Z
     |           |
     W --- X --- Y

Is that the case?

Also, guessing what you mean by B going down and D-E
going down you mean that B is undergoing some kind of
software maintenance which results in a temporary TCP
failure and, subsequent to this, the link between D and E
becomes inoperative.

First of all, this is a two-failure scenario and - as such -
is notoriously hard to protect against in any case.  I can
imagine a double failure of a single routing protocol that
would produce worse results.

But I look at this specific problem and I see the following:

B is being upgraded (not rebooted - that would affect more
than TCP and TCP-based LDP sessions).

The link D-E goes down.

Since (A,B,C,D,E,W,X,Y,Z) are all in the same routing
domain and all are still active routers (or are you suggesting
a third simultaneous failure?), all of them will eventually
detect the missing link D-E.

C determines that the best route for what used to be the
path A-C-D-E is now A-W-X-Y-Z.  C drops packets
it already has received from A because split horizon dis-
allows forwarding packets received from A back to A.
In any case, A also will (eventually) know that these
packets should go along the path A-W-X-Y-Z so on
their merry way they go.

Meanwhile - assuming that B is not yet aware of the topology
change - B continues to forward packets on the path A-B-D-E
but D is unable to forward them via E and sends them on a new
path through C-A-W-X-Y-Z - making the path that packets
traverse A-B-D-C-A-W-X-Y-Z-E for the smallish period of
time it may take A to realize that it should not be forwarding the
packets via B (it will eventually know that the path A-B-D-E
is no longer valid and that A-B-D-C-A-W-X-Y-Z-E is not
the shortest path) and B to realize that it should not be forwarding
the packets via D.

(Note - I am assuming that there is some reason why the
packets went A-B-D-E in the first place - as opposed to
A-C-D-E and that reason is related to the fact that they
were received on the 'left' interface of A.  If this is not
the case, then packet will loop along A-B-D-C-A...
until A figures out that it shouldn't be sending packets
to B that are intended to go through E.)

As soon as B becomes aware that the shortest path for packets
it is receiving from A for the path A-B-D-E is now through
A-W-X-Y-Z-E, it will start dropping packets (split horizon
again).  As soon as A realizes that the ONLY path to E is
A-W-X-Y-Z-E, it will stop forwarding packets to B and C.

So the fact that B is not in a position to pass on label release
and withdraw messages should be irrelevant to the problem.
The labels may be there, but nobody should be using them.
B should not continue to forward packet on a bad path and -
even if it does, A, C and D will do the right thing.  Yes, you
will have temporary looping of data, but you would have had
the exact same looping data without MPLS, LDP or LDP FT.
And, unless B is the ingress for CR-LDP based LSPs, the
ingress (at least to the routing domain) _will_ know about
the topology change and _will_ be able to re-route LSPs
accordingly.

Obviously, there are special problems with having the ingress
to an explictly routed LSP go off-line.  It will not be able to
signal new explicit routed LSPs until after it re-establishes
LDP peer relationships.  But it will not erroneously forward
packets on a bad path either.

This is just a specific analysis showing how what I said is
generally true is true in this specific case.  What is it you
think the specification needs to add to this?
 

 

In your example on page 24, C would play the role of P2 and queue the
label withdraw.  B would be P1.  A is on the other side of P1.  Maybe
I'm missing something.

>     In reading the current LDP FT specification, you probably
> discovered that it describes exactly how a fault tolerant LDP
> implementation is expected to deal with labels that are made
> invalid for the entire period during which it is unable to obtain
> confirmation that a peer has been informed of the invalidation.
> If there are details of this process that are not clear to you,
> please address those details.

Ok.  I just went through it again and I don't see how the above
example is handled.  Maybe I'm just dense but I missed it and I'd like
you to explain how the LDP-FT procedures handle the above example in
the event that it take B some 20-30 seconds to come back up.

As explained above, the example I believe you are citing is
handled by LDP and routing based finesse.
 

>     If, as I assert, LDP procedures are independent of specific
> routing protocols and LDP FT defines procedures for ensuring
> that LDP procedures are adhered to across multiple sessions,
> then LDP FT is equally independent of specific routing protocols.
>
>     Hopefully, this will clear up any fear, uncertainty or other
> doubts that this discussion may have raised. :-)
>
> --
> Eric Gray

Your explanation will certainly clear things up.

I hope so.
 

Thanks in advance,

Curtis

> You wrote:
>
> > In message <3ACA41AB.2A3ACB59@sandburst.com>, Eric Gray writes:
> > > Curtis,
> > >
> > >     As I understand it, LDP is the preferred protocol for use
> > > with MPLS BGP when BGP peers are not adjacent with
> > > respect to an MPLS domain.  Suppose that MPLS BGP is
> > > used to establish many VPN services which are possibly
> > > being used to provide a label switching service to enterprise
> > > customers.
> > >
> > >     For that matter, suppose that LDP is being used to signal
> > > and maintain <your favorite> VPN technology's LSPs.
> >
> > Eric,
> >
> > You wouldn't be using LDP on the outer tunnel, just the inner VPN
> > tunnel.  The outer tunnel is a RSVP-TE tunnel.  We are already lab
> > testing this at a customer and it interoperates nicely with other
> > people's BGP/VPN LDP implementations.
> >
> > Because the TE tunnel is rerouted around a failure the LDP adjacency
> > that ride inside the TE tunnels never go down.  The LDP TCP connection
> > sees some temporary loss at worst and then continues as if no topology
> > change occurred because the logical adjacency never went down.  This
> > works as long as there is a brief holddown on the TE tunnel and it
> > reroutes before the holddown expires.  In practice works great.
> >
> > Where you want to maintain LDP (and IGP) adjacency is where a router
> > is reloaded for something like software upgrade and nothing else in
> > the IGP changes during the reload time.  If you have two route
> > processors on the router that was reloaded, that should be a switch in
> > well under a second.  Rumor has it that some routers with one route
> > processor take a few minutes to reload so for those, if the topology
> > changes you'd rather route around them.
> >
> > So please remind me, exactly what was the point of your objection.
> > :-)
> >
> > Curtis
> >
> > > You wrote:
> > >
> > > > In message <3ACA3769.1E1C006F@sandburst.com>, Eric Gray writes:
> > > > >
> > > > >     I also suspect that you may be understating the advantages
> > > > > of maintaining session context.  Consider the impact to the
> > > > > network if LSPs are dropped lightly and these LSP are in turn
> > > > > being used to carry (stacked) LSPs.
> > > > >
> > > > > --
> > > > > Eric Gray
> > > >
> > > > You wouldn't be using LDP in that case.  ;-)
> > > >
> > > > Curtis
>
>

--------------5A9AD1722425D7E612CF999E-- From owner-mpls@UU.NET Thu Apr 5 00:33:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09709 for ; Thu, 5 Apr 2001 00:33:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjit14834; Wed, 4 Apr 2001 21:52:22 GMT Received: by mail-control.mail.uu.net id QQkjit11302 for mpls-outgoing; Wed, 4 Apr 2001 21:51:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjit11275 for ; Wed, 4 Apr 2001 21:51:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjit01651 for ; Wed, 4 Apr 2001 21:50:51 GMT Received: from mason2.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQkjit12936 for ; Wed, 4 Apr 2001 21:50:49 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id RAA27351 for ; Wed, 4 Apr 2001 17:50:47 -0400 (EDT) Date: Wed, 4 Apr 2001 17:50:47 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: mpls@UU.NET Subject: Re: MPLS 2001 International Conference - Oct. 7-9 In-Reply-To: <5.0.2.1.2.20010404095955.03974890@mail.vivacenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Please note that the topics and the technical program for MPLS 2001 will be selected by the Technical Program Committee of the conference. The TPC will solicit presentations, based on the topics discussed by the committee, from experts in the selected areas and will invite them for presentation at MPSL 2001. If you wish to bring out a particular topic or a contribution to the attention of the TPC, you should send your request as soon as possible to TPC@MPLS2001.com. If you are considering a proposal for presenation by yourself and believe your contribution is original and of significant value to the IETF technical community, you should send an extended summary of no more than 500 words with justification as to why you believe this work is original, or will be of signifcant value to the conference attendees, to TPC@MPLS2001.com. ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** On Wed, 4 Apr 2001, Andrew G. Malis wrote: > Rajiv, > > I've haven't yet seen a call for program committee participation and/or > abstracts for talks. As a member of the program committee and speaker for > all of the past years of the conference, I certainly would like to continue > in that role. I don't think we've had the opportunity to meet in the past, > so you may not be immediately familiar with my current roles as the chair > of the MPLS Forum's Technical Committee and their VP of Technology in > addition to my work at the IETF. Anyway, I would like to continue to add > value to the conference. > > Best regards, > Andy Malis > Chief Technologist, Vivace Networks > > ---------- > > At 4/3/2001 09:32 PM -0400, Rajiv Papneja wrote: > > >Dear friends, > > > > The MPLS 2001 International Conference will again be hosted jointly > >by UUNET Technologies and Advanced Internet Lab, and will be held at > >the Omni Shoreham Hotel in Washington, DC, October 7-9, 2001. > > > > > > The conference begins with tutorials on Sunday October 7 and continues > >with full-day technical sessions on Monday and Tuesday, October 8-9. A > >series of public Interoperability demonstrations will follow on October > >10-12 at Advanced Internet Lab. Conference information, technical > >program, and other details, including the testing and public > >Interoperability events will be made available at http://www.mpls2001.com. > > > > The technical program for MPLS 2001 will be unique, as were the > >programs for previous events in this series. MPLS 98 was the first > >conference on the topic of Multiprotocol Label Switching. The > >attendance has continued to grow each year. Last year, at MPLS 2000, > >17 sponsors exhibited their products and services throughout the > >conference. This year, we have reserved a larger space to accommodate > >additional sponsors. If you are interested in securing exhibit space at > >MPLS 2001, please contact sponsor@mpls2001.com, 703.218.3770 (phone), or > >703.218.3780 (fax). Three categories of sponsorship are available. > >Exhibit space is limited and will be committed on a first-come, > >first-served basis. > > > > For additional information, hotel reservation, last year's sponsors > >please visit http://www.mpls2001.com. > > > > We look forward to seeing you in the "MPLS 2001 International Conference." > >Thanks. > > > > Regards, > > - Rajiv > > > >******************************** > >Rajiv Papneja (GRA) > >Advanced Internet Laboratory > >George Mason University, > >G10, Johnson Center, > >Fairfax, VA 22030-4444 > >Tel: 703.993.4703 > >email: rpapneja@osf1.gmu.edu > >******************************** > > ________________________________________________________________________ > Andrew G. Malis Andy.Malis@vivacenetworks.com phone:408-383-7223 > Vivace Networks/2730 Orchard Parkway/San Jose, CA 95134/fax:408-904-4748 > http://www.vivacenetworks.com > > From owner-mpls@UU.NET Thu Apr 5 06:50:37 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26942 for ; Thu, 5 Apr 2001 06:50:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjkt07557; Thu, 5 Apr 2001 10:48:29 GMT Received: by mail-control.mail.uu.net id QQkjkt18439 for mpls-outgoing; Thu, 5 Apr 2001 10:47:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjkt18434 for ; Thu, 5 Apr 2001 10:47:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjkt20208 for ; Thu, 5 Apr 2001 10:46:25 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjkt28266 for ; Thu, 5 Apr 2001 10:46:25 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA27811 for mpls@uu.net; Thu, 5 Apr 2001 06:46:24 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjks17889 for ; Thu, 5 Apr 2001 10:41:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjks07642 for ; Thu, 5 Apr 2001 10:41:43 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkjks26440 for ; Thu, 5 Apr 2001 10:41:42 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id DAA25411; Thu, 5 Apr 2001 03:42:05 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f35AfeO28108; Thu, 5 Apr 2001 03:41:40 -0700 (PDT) Message-ID: <3ACC4B8B.1634911@cisco.com> Date: Thu, 05 Apr 2001 03:40:11 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Loureiro, Rodrigo" CC: "'mpls@uu.net'" Subject: Re: VPN/MPLS question References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQkjkt07557 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA26942 > system. Once i have only 1014 private as-numbes, this could represent a > scalability problem, for example, if i think about a big extranet client. Is > it correct? Not at all. There is a feature (at least in cisco) allowing you to automatically overwrite AS numbers of your VPN sites (with the provider AS) by PE so all of the given VPN sites could use the same AS number. R. > "Loureiro, Rodrigo" wrote: > > Hi all, > > Thinking about use EBGP sessions between the PE-CE connection, in order to > insert customer´s routing information into the VPN routing table and provide > layer 3 redundancy for the customer´s site using BGP, a scalability problem > arises: > > Once BGP has a loop avoidance mechanism based on the as-path vector, and > considering that i will not summarize the prefixes in the PEs, every site > participating in the VPN (peer) should have a different private autonomous > system. Once i have only 1014 private as-numbes, this could represent a > scalability problem, for example, if i think about a big extranet client. Is > it correct? > > Regards, > -- > > Rodrigo Loureiro > Systems Engineer - AT&T LA > Tel: 55-11-3365-1670/9965-9676 > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ------------------------------------------ > The Art of Strategy: "Those who are victorious plan effectively and change > decisively. They are like a great river that maintains its course but > adjusts its flow... They have form but are formless. They are skilled in > both planning and adapting and need not fear the result of a thousand > battles; for they win in advance, defeating those that have already lost." - > Sun Tzu, Chinese Warrior and Philosopher, 100 B.C. > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ------------------------------------------ From owner-mpls@UU.NET Thu Apr 5 08:49:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00124 for ; Thu, 5 Apr 2001 08:49:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjlb10983; Thu, 5 Apr 2001 12:46:21 GMT Received: by mail-control.mail.uu.net id QQkjlb28344 for mpls-outgoing; Thu, 5 Apr 2001 12:45:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjlb28339 for ; Thu, 5 Apr 2001 12:45:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjlb02315 for ; Thu, 5 Apr 2001 12:45:11 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQkjlb05567 for ; Thu, 5 Apr 2001 12:45:10 GMT Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 5 Apr 2001 08:22:40 -0400 Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2JJZHFLV; Thu, 5 Apr 2001 08:22:41 -0400 Received: from americasm01.nt.com (philipma-1.ca.nortel.com [47.129.70.233]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2FLVVBV4; Thu, 5 Apr 2001 08:22:40 -0400 Message-ID: <3ACBE2B6.3A9F990B@americasm01.nt.com> Date: Wed, 04 Apr 2001 23:12:54 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: afarrel@movaz.com CC: curtis@avici.com, pjb@metaswitch.com, eric.gray@sandburst.com, mpls@UU.NET Subject: Re: Last Call on LDP Fault Tolerance References: <4F9E13BCC53ED411A629009027E8D00C043336DA@msg001.dcat.ops.broadbandoffice.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I would be happy to include a paragraph or two about the interaction with a significant IGP change. I can see that mentioning this issue would help people understand the implications of Fault Tolerance better. However, I would prefer to say that an implementor MAY wish to abort the session recovery effort in this case, rather than saying that the implementor SHOULD implement an option to enable this on a per-peer basis. I don't think we understand this issue well enough yet to recommend such an option. But I am strongly against limiting (or even suggesting limiting) the use of fault tolerance to midnight software upgrades. I think other uses are quite valid. Adrian's redundant line cards are one good example. Another one is redundant control planes. - Philip Matthews Nortel Networks Corporation afarrel@movaz.com wrote: > > Curtis, > > I can't see any reason not to point out that a "give up and run away" type > of timer can be overridden by other events. The one you suggest > (significant IGP change) could well be applicable to LDP, although I think > it is less significant in CR-LDP. > > I find... > > There appears to be a school of thought where it is deemed beneficial > > to keep forwarding state intact in only very limited cases such as > > midnight controlled reload of routers for purposes such as software > > upgrade. > ...odd. When a line card fails I should like to be able to swap to a new > card and continue forwarding data with only a very short (10s of ms) break. > Adrian > -- > Adrian Farrel > Movaz Networks Inc > afarrel@movaz.com > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > Sent: Tuesday, April 03, 2001 3:07 PM > > To: George Swallow; af@dataconnection.com; pjb@dataconnection.com; > > philipma@nortelnetworks.com; eric.gray@sandburst.com > > Cc: mpls@UU.NET > > Subject: Re: Last Call on LDP Fault Tollerance > > > > > > > > In message <200103282300.SAA15343@pilgrim.cisco.com>, George > > Swallow writes: > > > This message commences a workgroup last call on LDP Fault > > Tollerance, > > > . The last call closes > > April 11, 12 pm > > > GMT. > > > > > > ...George > > > > > > > > ====================================================================== > > > George Swallow Cisco Systems (978) 244-8143 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 > > > > > > Adrian, et al, > > > > I would like to make a comment and leave it up to the authors > > discression as to whether to incorporate any change into the document. > > > > There appears to be a school of thought where it is deemed beneficial > > to keep forwarding state intact in only very limited cases such as > > midnight controlled reload of routers for purposes such as software > > upgrade. This case can be even further limited to maintaining > > forwarding state only if network topology has not changed while > > adjacency is unavailable. > > > > The justification for retaining forwarding state is to eliminate > > unnecessary forwarding state churn that may cause transient forwarding > > disruptions. The justification for not retaining forwarding state if > > topology changes is to prevent persistent forwarding problems that > > could occur if loops or black holes formed as a result of inconsistent > > forwarding state on a router in which the means to synchronize state > > was unavailable. > > > > Stated more simply -- Its nice to avoid dumping a few packets on the > > floor but if topology changes it may be better to endure some > > transient route churn than to endure inconsistent routing state that > > lasts for the duration of a router reloading new software and could > > dump a whole lot more packets on the floor than what the transient > > would cause. > > > > If changes are made, one possible addition would be to add a section > > 4.4.2: > > > > 4.4.2 Optional Reconnect Expire on Topology Change > > > > > this is needed from the authors> > > > > If topology change is detected through some means outside LDP such > > as change in an Interior Gateway Protocol Link State Database > > (IGP-LSDB) it may be desireable to prematurely expire the FT > > Reconnection Timer. An option SHOULD be provided to enable such a > > feature on a per peer basis. > > > > I leave it entirely up to the authors as to whether they would like to > > add this text. I would prefer if something to this effect were added > > unless there is objection to this addition on the list. A vendor > > could always include such a feature and make it optional and disabled > > by default regardless of whether it is stated in the document so there > > is little sense of urgency. > > > > Curtis > > From owner-mpls@UU.NET Thu Apr 5 09:44:21 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02022 for ; Thu, 5 Apr 2001 09:44:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjle18613; Thu, 5 Apr 2001 13:41:39 GMT Received: by mail-control.mail.uu.net id QQkjle17666 for mpls-outgoing; Thu, 5 Apr 2001 13:41:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjle17628 for ; Thu, 5 Apr 2001 13:40:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjle29675 for ; Thu, 5 Apr 2001 13:39:29 GMT Received: from web13702.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13702.mail.yahoo.com [216.136.175.135]) id QQkjle20458 for ; Thu, 5 Apr 2001 13:39:28 GMT Message-ID: <20010405133928.37665.qmail@web13702.mail.yahoo.com> Received: from [203.197.74.150] by web13702.mail.yahoo.com; Thu, 05 Apr 2001 06:39:28 PDT Date: Thu, 5 Apr 2001 06:39:28 -0700 (PDT) From: N S S Kishore Kankipati Subject: Diff-Serv over MPLS To: flefauch@cisco.com, liwwu@cisco.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk hi all Could any of you please explain about the following sentence in the draft-ietf-mpls-diff-ext-0.8.txt. section 1.2-- Exp-Inferred-PSC LSPS (E-LSP) "A single LSP can be used to support up to eight BAs of a given FEC, regardless of how many OAs these BAs span." A small doubt Suppose PHBs related to a PSC have been assigned to different E-LSPs (say AF11 to one LSP and AF12 to another LSP)and first few (say 1-10)Packets belonging to a microflow have been assigned to AF11 and later packets (say 10-15) to AF12. Is it not possible for the packets in AF12 LSP to get transferred before the packets in AF11 LSP? If that is the case the ordering constraint is violated i.e packets are reordered. (I think this may happen in the following case- if the LSPs are on different interfaces of a router and there may be some packets which are required to be served in the AF11 while the packets in AF12 may get immediately served as there are no packets before these which require service). thanks kk __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Thu Apr 5 09:56:57 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02454 for ; Thu, 5 Apr 2001 09:56:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjlf05780; Thu, 5 Apr 2001 13:54:02 GMT Received: by mail-control.mail.uu.net id QQkjlf19063 for mpls-outgoing; Thu, 5 Apr 2001 13:53:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjlf19056 for ; Thu, 5 Apr 2001 13:53:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjlf15356 for ; Thu, 5 Apr 2001 13:52:41 GMT Received: from spomail01.attla.corp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.netstream.com.br [200.192.1.34]) id QQkjlf08598 for ; Thu, 5 Apr 2001 13:52:40 GMT Received: from nsrjo4.attla.corp ([10.21.10.6]) by spomail01.attla.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10) id HNANWQYV; Thu, 5 Apr 2001 10:54:15 -0300 Received: by nsrjo4 with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Apr 2001 10:51:40 -0300 Message-ID: From: "Loureiro, Rodrigo" To: "'raszuk@cisco.com'" Cc: "'mpls@uu.net'" Subject: RES: VPN/MPLS question Date: Thu, 5 Apr 2001 10:51:39 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 JAA02454 Hi Robert, Thanks for the response. >> system. Once i have only 1014 private as-numbes, this could represent a >> scalability problem, for example, if i think about a big extranet client. Is >> it correct? >Not at all. There is a feature (at least in cisco) allowing you to >automatically overwrite AS numbers of your VPN sites (with the provider >AS) by PE so all of the given VPN sites could use the same AS number. I thought about use "remove-private-as" in the edge, but it doesn´t remove the private as-number of the as-path field, if the neighbor which will receive the advertisement is the same as the one i would like to remove. Could you tell me what feature are you talking about? Regards, -- Rodrigo From owner-mpls@UU.NET Thu Apr 5 09:57:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02475 for ; Thu, 5 Apr 2001 09:57:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjlf07944; Thu, 5 Apr 2001 13:55:22 GMT Received: by mail-control.mail.uu.net id QQkjlf19067 for mpls-outgoing; Thu, 5 Apr 2001 13:53:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjlf19058 for ; Thu, 5 Apr 2001 13:53:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjlf26207 for ; Thu, 5 Apr 2001 13:51:50 GMT Received: from email.nist.gov by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.nist.gov [129.6.2.7]) id QQkjlf07468 for ; Thu, 5 Apr 2001 13:51:50 GMT Received: from antd.nist.gov (octopus.antd.nist.gov [129.6.60.19]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id JAA06865; Thu, 5 Apr 2001 09:51:48 -0400 (EDT) Message-ID: <3ACCA2C8.13B72D07@antd.nist.gov> Date: Thu, 05 Apr 2001 09:52:24 -0700 From: SuKyoung Lee X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ramesh Bhandari , mpls@UU.NET Subject: Re: Question about 1:n and m:n protections References: <3ACB9457.845B29FB@antd.nist.gov> <3ACB8D79.FE395393@hotair.hobl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Ramesh Thank you for your information. Recently, I have been analyzing how to allocate backup paths to the group of working paths in m:n case. As you know, any researchers have proposed various restoration algorithms assuming ring or mesh networks. But I would like to know some mechanisms(if any) without that assmption. Ramesh Bhandari wrote: > Hello SuKyoung, > > I don't know what you mean by general mechanisms, but certainly a given > restoration path (or its)individual links can be used by several working > paths in a shared mesh restoration environment. There is a lot of > literature on shared mesh restoration technique, but if you are also > interested in algorithms for computing physically-disjoint restoration > paths, there is a book of mine: "Survivable Networks: Algorithms for > Diverse Routing", Kluwer Academic Publishers (1999), which in addition > to discussing the general technique for shared mesh restoration, > provides algorithms for finding optimal disjoint service and restoration > paths. The book can be obtained from bn.com, fatbrain,com, etc. > > Ramesh > > SuKyoung Lee wrote: > > > > Hello. > > > > I have been working on the analysis of restoration time and backup path > > provisioning in protection. > > Especially, for 1:n and m:n case, is there any detailed mechanism about > > how many working paths could be protected by 1 backup path and > > determining the number of backup paths for n working paths? > > If anyone knows some general mechanisms, please let me know those to > > compare > > my work with. > > > > -- > > SuKyoung Lee > > High Speed Network Technologies Group > > Advanced Network Technologies Division > > National Institute of Standards & Technology > > Email: sukyoung@antd.nist.gov > > Phone: 301-975-4780 -- SuKyoung Lee High Speed Network Technologies Group Advanced Network Technologies Division National Institute of Standards & Technology Email: sukyoung@antd.nist.gov Phone: 301-975-4780 From owner-mpls@UU.NET Thu Apr 5 10:29:03 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03148 for ; Thu, 5 Apr 2001 10:29:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjlh25948; Thu, 5 Apr 2001 14:26:20 GMT Received: by mail-control.mail.uu.net id QQkjlh07594 for mpls-outgoing; Thu, 5 Apr 2001 14:25:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjlh07589 for ; Thu, 5 Apr 2001 14:25:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjlh03115 for ; Thu, 5 Apr 2001 14:24:12 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjlh10937 for ; Thu, 5 Apr 2001 14:24:12 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA12176 for mpls@uu.net; Thu, 5 Apr 2001 10:24:11 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjlh07409 for ; Thu, 5 Apr 2001 14:23:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjlh25238 for ; Thu, 5 Apr 2001 14:23:06 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkjlh21537 for ; Thu, 5 Apr 2001 14:23:06 GMT Received: (qmail 10281 invoked by uid 104); 5 Apr 2001 14:23:05 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.386244 secs); 05/04/2001 07:23:05 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 5 Apr 2001 14:23:05 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f35EN4B24623; Thu, 5 Apr 2001 07:23:04 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Apr 2001 07:23:51 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B96@BBY1EXM01> From: Shahram Davari To: "'N S S Kishore Kankipati'" , flefauch@cisco.com, liwwu@cisco.com Cc: mpls@UU.NET Subject: RE: Diff-Serv over MPLS Date: Thu, 5 Apr 2001 07:23:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, > Could any of you please explain about the following > sentence in the draft-ietf-mpls-diff-ext-0.8.txt. > > section 1.2-- Exp-Inferred-PSC LSPS (E-LSP) > > "A single LSP can be used to support up to eight BAs > of > a given FEC, regardless of how many OAs these BAs > span." > This means that an E-LSP can support up to 8 PHBs. But the number of PSCs that can be supported is not fixed, because it depends on the type of PSCs. For example you could support 4 PSCs (= 8 PHBs) as following: AF1x, AF2x, EF, DF Or you could support only one PSC like CS (= 8 PHBs): CSx So the Max. number of OAs is variable but the Max number of BAs is fixed= 8. > A small doubt > Suppose PHBs related to a PSC have been assigned to > different E-LSPs (say AF11 to one LSP and AF12 to > another LSP)and first few (say 1-10)Packets belonging > to a microflow have been assigned to AF11 and later > packets (say 10-15) to AF12. > Is it not possible for the packets in AF12 LSP to get > transferred before the packets in AF11 LSP? If that is > the case the ordering constraint is violated i.e > packets are reordered. Although this can be done in theory, but you should not do it, becasue of the reordering problem that you mentioned. Yours, -Shahram > From owner-mpls@UU.NET Thu Apr 5 10:33:43 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03292 for ; Thu, 5 Apr 2001 10:33:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjli18927; Thu, 5 Apr 2001 14:30:50 GMT Received: by mail-control.mail.uu.net id QQkjli08060 for mpls-outgoing; Thu, 5 Apr 2001 14:30:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjli08055 for ; Thu, 5 Apr 2001 14:30:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjlh11922 for ; Thu, 5 Apr 2001 14:28:21 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjlh29102 for ; Thu, 5 Apr 2001 14:28:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA12541 for mpls@uu.net; Thu, 5 Apr 2001 10:28:20 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjlh07426 for ; Thu, 5 Apr 2001 14:24:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjlh11593 for ; Thu, 5 Apr 2001 14:22:51 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: london2.cisco.com [144.254.32.10]) id QQkjlh21202 for ; Thu, 5 Apr 2001 14:22:50 GMT Received: from JGUICHAR-W2K.cisco.com (jguichar-isdn-home.cisco.com [10.49.131.222]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA09953; Thu, 5 Apr 2001 16:22:47 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010405152135.01a17db0@london2.cisco.com> X-Sender: jguichar@london2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Apr 2001 15:22:38 +0100 To: "Loureiro, Rodrigo" From: jim guichard Subject: Re: RES: VPN/MPLS question Cc: "'raszuk@cisco.com'" , "'mpls@uu.net'" In-Reply-To: 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 KAA03292 Rodrigo, the feature you need is called AS Override - you can configure it under the vrf address family via 'neighbor x.x.x.x as-override' . Hope this helps. Jim At 10:51 05/04/2001 -0300, Loureiro, Rodrigo wrote: >Hi Robert, > >Thanks for the response. > > >> system. Once i have only 1014 private as-numbes, this could represent a > >> scalability problem, for example, if i think about a big extranet client. >Is > >> it correct? > > >Not at all. There is a feature (at least in cisco) allowing you to > >automatically overwrite AS numbers of your VPN sites (with the provider > >AS) by PE so all of the given VPN sites could use the same AS number. > >I thought about use "remove-private-as" in the edge, but it doesn´t remove >the private as-number of the as-path field, if the neighbor which will >receive the advertisement is the same as the one i would like to remove. >Could you tell me what feature are you talking about? > > >Regards, >-- > >Rodrigo Jim Guichard CCIE #2069 Technical Leader EMEA +44 208 756 8806 Mobile: +44 7802 809763 From owner-mpls@UU.NET Thu Apr 5 10:34:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03367 for ; Thu, 5 Apr 2001 10:34:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjli03396; Thu, 5 Apr 2001 14:32:10 GMT Received: by mail-control.mail.uu.net id QQkjli08138 for mpls-outgoing; Thu, 5 Apr 2001 14:30:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjli08096 for ; Thu, 5 Apr 2001 14:30:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjlh12541 for ; Thu, 5 Apr 2001 14:28:38 GMT From: afarrel@movaz.com Received: from ims000.dcat.ops.broadbandoffice.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: external00.dca55.ops.bbo.com [64.47.146.7]) id QQkjlh15761 for ; Thu, 5 Apr 2001 14:28:33 GMT Received: by ims000.dcat.ops.broadbandoffice.net with Internet Mail Service (5.5.2650.21) id <2JYW8GFD>; Thu, 5 Apr 2001 10:28:33 -0400 Message-ID: <4F9E13BCC53ED411A629009027E8D00C043336E0@msg001.dcat.ops.broadbandoffice.net> To: curtis@avici.com, afarrel@movaz.com Cc: pjb@metaswitch.com, philipma@nortelnetworks.com, eric.gray@sandburst.com, mpls@UU.NET Subject: RE: Last Call on LDP Fault Tolerance Date: Thu, 5 Apr 2001 10:28:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BDDC.B0C2B8E0" 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_01C0BDDC.B0C2B8E0 Content-Type: text/plain; charset="iso-8859-1" > > I find... > > > There appears to be a school of thought where it is > > > deemed beneficial to keep forwarding state intact > > > in only very limited cases such as midnight > > > controlled reload of routers for purposes such > > > as software upgrade. > > ...odd. When a line card fails I should like to be > > able to swap to a new card and continue forwarding > > data with only a very short (10s of ms) break. > > When a line card fails, that line card will still be in the box for at > least a few minutes, more likely the better part of an hour, maybe > longer. I don't know of any technician that can swap a line card in > 10 msec. I also don't know of any line card that can reboot in 10 > msec. When a line card fails if there is a TE tunnel and > local-protect on the TE tunnel, then the switch over is very fast. If > it is LDP without TE or TE without local protect, the 10s of msec is > very likely not acheived. That has absolutely nothing to do with > LDP-FT so I don't see why you brought it up. It has everything to do with LDP FT. One of the key aims is to be able to switch "seamlessly" to another card _that_is_already_in_the_box. If the failed card was running LDP you must preserve protocol states etc. If the failed card was a line card not running LDP, you must handle the failed TCP connection (i.e. LDP session) and re-instate it through the replacement card. > At issue with LDP-FT is when the route processor fails and the line > card does not fail. That is when the forwarding entries remain intact > and the LDP adjacency will be back shortly. That is the case if the > route processor's software is reloaded for software upgrade. You are making huge assumptions about what processing is done where in the system, the responsiblity of line cards, and whether line cards can be replicated. Features in one system may not be present in other systems. > As I said, I'll leave it up to the authors whether they want to make > any change to the document. It sounds like you don't. That's fine. Thanks. It looks like we will add some text to point out that state retention is a local matter. Adrian -- Adrian Farrel Movaz Networks Inc afarrel@movaz.com ------_=_NextPart_001_01C0BDDC.B0C2B8E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Last Call on LDP Fault Tolerance

> > I find...
> > > There appears to be a school of = thought where it is
> > > deemed beneficial to keep forwarding = state intact
> > > in only very limited cases such as = midnight
> > > controlled reload of routers for = purposes such
> > > as software upgrade.
> > ...odd.  When a line card fails I = should like to be
> > able to swap to a new card and continue = forwarding
> > data with only a very short (10s of ms) = break.
>
> When a line card fails, that line card will = still be in the box for at
> least a few minutes, more likely the better = part of an hour, maybe
> longer.  I don't know of any technician = that can swap a line card in
> 10 msec.  I also don't know of any line = card that can reboot in 10
> msec.  When a line card fails if there is = a TE tunnel and
> local-protect on the TE tunnel, then the switch = over is very fast.  If
> it is LDP without TE or TE without local = protect, the 10s of msec is
> very likely not acheived.  That has = absolutely nothing to do with
> LDP-FT so I don't see why you brought it = up.

It has everything to do with LDP FT.
One of the key aims is to be able to switch = "seamlessly" to another card = _that_is_already_in_the_box.
If the failed card was running LDP you must preserve = protocol states etc.
If the failed card was a line card not running LDP, = you must handle the failed TCP connection (i.e. LDP session) and = re-instate it through the replacement card.

> At issue with LDP-FT is when the route processor = fails and the line
> card does not fail.  That is when the = forwarding entries remain intact
> and the LDP adjacency will be back = shortly.  That is the case if the
> route processor's software is reloaded for = software upgrade.

You are making huge assumptions about what processing = is done where in the system, the responsiblity of line cards, and = whether line cards can be replicated.  Features in one system may = not be present in other systems.

> As I said, I'll leave it up to the authors = whether they want to make
> any change to the document.  It sounds = like you don't.  That's fine.

Thanks.  It looks like we will add some text to = point out that state retention is a local matter.

Adrian
--
Adrian Farrel
Movaz Networks Inc
afarrel@movaz.com

------_=_NextPart_001_01C0BDDC.B0C2B8E0-- From owner-mpls@UU.NET Thu Apr 5 11:03:33 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04272 for ; Thu, 5 Apr 2001 11:03:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjlk12241; Thu, 5 Apr 2001 15:00:46 GMT Received: by mail-control.mail.uu.net id QQkjlk12722 for mpls-outgoing; Thu, 5 Apr 2001 15:00:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjlk12128 for ; Thu, 5 Apr 2001 15:00:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjlj19030 for ; Thu, 5 Apr 2001 14:59:15 GMT Received: from mail2.packetengines.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail2.packetengines.com [208.227.187.173]) id QQkjlj04745 for ; Thu, 5 Apr 2001 14:59:15 GMT Received: from hostr607.alcatel.com by mail2.packetengines.com via smtpd (for cmr1.ash.ops.us.uu.net [198.5.241.39]) with SMTP; 5 Apr 2001 14:59:15 UT Received: by steam.corp.packetengines.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Apr 2001 07:56:52 -0700 Message-ID: From: Marc Lewis To: "'mpls@UU.NET'" Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Thu, 5 Apr 2001 07:56:52 -0700 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 Robin wrote: > Alcatel's implementation of MPLS does support statically configured LSPs. > I would guess other vendors support statically configured LSPs. That is not true for the switch/routers produced by the former Packet Engines (specifically, the Alcatel 7652 PowerRail Distribution Router). Our MPLS implementation does support statically configured LSPs, as well as LSPs signalled via RSVP-TE. We implemented our MPLS switching in hardware, and can do up to 3 label push/pop/swaps per frame and still maintain gigabit line rate. ---- H. Marc Lewis -- Sr. Software Engineer -- Alcatel Internetworking (PE) inc. Spokane, WA -- (509) 777-7316 -- Marc.Lewis@alcatel.com From owner-mpls@UU.NET Thu Apr 5 11:05:43 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04433 for ; Thu, 5 Apr 2001 11:05:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjlk29316; Thu, 5 Apr 2001 15:03:19 GMT Received: by mail-control.mail.uu.net id QQkjlk16891 for mpls-outgoing; Thu, 5 Apr 2001 15:02:47 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjlk16420 for ; Thu, 5 Apr 2001 15:02:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjlk01748 for ; Thu, 5 Apr 2001 15:02:12 GMT Received: from spomail01.attla.corp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.netstream.com.br [200.192.1.34]) id QQkjlk14458 for ; Thu, 5 Apr 2001 15:02:11 GMT Received: from nsrjo4.attla.corp ([10.21.10.6]) by spomail01.attla.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10) id HNANWR3C; Thu, 5 Apr 2001 12:04:02 -0300 Received: by nsrjo4 with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Apr 2001 12:01:33 -0300 Message-ID: From: "Loureiro, Rodrigo" To: "'Yakov Rekhter'" Cc: "'mpls@uu.net'" Subject: RES: VPN/MPLS question Date: Thu, 5 Apr 2001 12:01:31 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 LAA04433 Yakov, Thanks for the response. By the way, congratulations for all of the materials that you have produced. >> Hi all, >> >> Thinking about use EBGP sessions between the PE-CE connection, in order to >> insert customer's routing information into the VPN routing table and provide >> layer 3 redundancy for the customer's site using BGP, a scalability problem >> arises: >> >> Once BGP has a loop avoidance mechanism based on the as-path vector, and >> considering that i will not summarize the prefixes in the PEs, every site >> participating in the VPN (peer) should have a different private autonomous >> system. >not necessarily. See Section 7 of draft-rosen-rfc2547bis-03.txt >(and specifically text on page 5 of that document) for more on this. OK, i have already read this RFC and i see three scenarios: 1) MPLS in the CE; 2) Redistribution in the CE/PE; 3) BGP-4 in the CE. The network will be compound by many independent administrative sites (different companies). All of the sites will be connected to two VPN/MPLS service providers for redundancy, and the providers will be connected to each other advertising the related (VPNs) prefixes. Looking at the first scenario, i can see some problems. The first is that the CEs will be "CPEs", i mean, small/medium capacity routers and should not have support to MPLS. Also, this scenario will not scale regarding the configuration environment. We are talking about a partial-mesh network with hundreds of nodes and we don´t expect to mount an IBGP environment in the network; The second possibility is to use redistribution, once we can use the Site of Origin loop avoidance mechanism. This scenario have a redundancy problem, regarding routing convergence (ATM cloud); The last scenario was the chosen one, but the scalability question arised regarding the private numbers. Regards, -- Rodrigo From owner-mpls@UU.NET Thu Apr 5 11:17:11 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04766 for ; Thu, 5 Apr 2001 11:17:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjlk04097; Thu, 5 Apr 2001 15:14:36 GMT Received: by mail-control.mail.uu.net id QQkjlk29501 for mpls-outgoing; Thu, 5 Apr 2001 15:14:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjlk29486 for ; Thu, 5 Apr 2001 15:13:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjlk09556 for ; Thu, 5 Apr 2001 15:13:05 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkjlk28971 for ; Thu, 5 Apr 2001 15:13:05 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05683; Thu, 5 Apr 2001 08:13:00 -0700 (PDT) Message-Id: <200104051513.IAA05683@red.juniper.net> To: "Loureiro, Rodrigo" cc: "'mpls@uu.net'" Subject: Re: RES: VPN/MPLS question In-Reply-To: Your message of "Thu, 05 Apr 2001 12:01:31 -0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <91176.986483580.1@juniper.net> Date: Thu, 05 Apr 2001 08:13:00 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Rodrigo, > Yakov, > > Thanks for the response. By the way, congratulations for all of the > materials that you have produced. Thanks !!! > > >> Hi all, > >> > >> Thinking about use EBGP sessions between the PE-CE connection, in order > to > >> insert customer's routing information into the VPN routing table and > provide > >> layer 3 redundancy for the customer's site using BGP, a scalability > problem > >> arises: > >> > >> Once BGP has a loop avoidance mechanism based on the as-path vector, and > >> considering that i will not summarize the prefixes in the PEs, every site > >> participating in the VPN (peer) should have a different private > >> autonomous system. > > >not necessarily. See Section 7 of draft-rosen-rfc2547bis-03.txt > >(and specifically text on page 5 of that document) for more on this. sorry for the typo - it should be "page 25 of that document". > OK, i have already read this RFC and i see three scenarios: > > 1) MPLS in the CE; > > 2) Redistribution in the CE/PE; > > 3) BGP-4 in the CE. > > The network will be compound by many independent administrative sites > (different companies). All of the sites will be connected to two VPN/MPLS > service providers for redundancy, and the providers will be connected to > each other advertising the related (VPNs) prefixes. > > Looking at the first scenario, i can see some problems. The first is that > the CEs will be "CPEs", i mean, small/medium capacity routers and should not > have support to MPLS. Also, this scenario will not scale regarding the > configuration environment. We are talking about a partial-mesh network with > hundreds of nodes and we don't expect to mount an IBGP environment in the > network; > > The second possibility is to use redistribution, once we can use the Site of > Origin loop avoidance mechanism. That is the scenario I had in mind. Quoting from the Internet Draft: If a site is not in a transit VPN, note that it need not have a unique Autonomous System Number (ASN). Every CE whose site which is not in a transit VPN can use the same ASN. This can be chosen from the private ASN space, and it will be stripped out by the PE. Routing loops are prevented by use of the Site of Origin Attribute (see below). > This scenario have a redundancy problem, > regarding routing convergence (ATM cloud); Could you elaborate more on this please. Yakov. From owner-mpls@UU.NET Thu Apr 5 12:27:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07080 for ; Thu, 5 Apr 2001 12:27:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjlp25392; Thu, 5 Apr 2001 16:25:06 GMT Received: by mail-control.mail.uu.net id QQkjlp23352 for mpls-outgoing; Thu, 5 Apr 2001 16:24:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjlp23323 for ; Thu, 5 Apr 2001 16:24:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjlp19968 for ; Thu, 5 Apr 2001 16:22:43 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkjlp19468 for ; Thu, 5 Apr 2001 16:22:42 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 JAA12554 for ; Thu, 5 Apr 2001 09:22:59 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA17435 for mpls@uu.net; Thu, 5 Apr 2001 12:22:34 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjlp22897 for ; Thu, 5 Apr 2001 16:16:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjlp23176 for ; Thu, 5 Apr 2001 16:16:39 GMT Received: from anti_vir1.rad.co.il by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.116.244.108]) id QQkjlp01779 for ; Thu, 5 Apr 2001 16:16:38 GMT Received: from anti_vir1.rad.co.il (localhost [127.0.0.1]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id SAA01835 for ; Thu, 5 Apr 2001 18:15:14 +0200 (IST) Received: from radmail.rad.co.il (radmail [192.114.24.30]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id SAA01821; Thu, 5 Apr 2001 18:15:12 +0200 (IST) Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with ESMTP id il; Thu, 5 Apr 2001 17:19:38 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Apr 2001 18:15:35 +0200 Message-ID: From: Sasha Vainshtein To: "'N S S Kishore Kankipati'" , flefauch@cisco.com, liwwu@cisco.com Cc: mpls@UU.NET, "'diffserv@ietf.org'" Subject: RE: Diff-Serv over MPLS Date: Thu, 5 Apr 2001 18:15:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, The reordering issue has been addressed in , "New Terminology for Diffserv" with an explicit reference to work on MPLS Support of Differentiated Services. Section 5 of this I-D introduces the notion of an Ordering Aggregate (OA) as A set of Behavior Aggregates that share an ordering constraint. The set of PHBs that are applied to this set of Behavior Aggregates constitutes a PHB scheduling class. I suggest that should be updated to allow only grouping of multiple OAs (and not BAs as it does) into a single E-LSP. The current I-D version explicitly states that L-LSP is established for a given (OA, FEC) class but is ambiguous when it comes to E-LSPs. Nabil, in his message in this thread, has noticed that RFC 2597 defines AF (y=1,2,3) as an OA for any fixed value of x (1-4). The suggested modification would prohibit configurations like one described in the original message. ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@axerra.com phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) >>-----Original Message----- >>From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com] >>Sent: Thursday, April 05, 2001 3:39 PM >>To: flefauch@cisco.com; liwwu@cisco.com >>Cc: mpls@UU.NET >>Subject: Diff-Serv over MPLS >> >> >>hi all >> Could any of you please explain about the following >>sentence in the draft-ietf-mpls-diff-ext-0.8.txt. >> >>section 1.2-- Exp-Inferred-PSC LSPS (E-LSP) >> >>"A single LSP can be used to support up to eight BAs >>of >>a given FEC, regardless of how many OAs these BAs >>span." >> >>A small doubt >> Suppose PHBs related to a PSC have been assigned to >>different E-LSPs (say AF11 to one LSP and AF12 to >>another LSP)and first few (say 1-10)Packets belonging >>to a microflow have been assigned to AF11 and later >>packets (say 10-15) to AF12. >>Is it not possible for the packets in AF12 LSP to get >>transferred before the packets in AF11 LSP? If that is >>the case the ordering constraint is violated i.e >>packets are reordered. (I think this may happen in >>the following case- if the LSPs are on different >>interfaces of a router and there may be some packets >>which are required to be served in the AF11 while the >>packets in AF12 may get immediately served as there >>are >>no packets before these which require service). >> >>thanks >>kk >> >>__________________________________________________ >>Do You Yahoo!? >>Get email at your own domain with Yahoo! Mail. >>http://personal.mail.yahoo.com/ >> From owner-mpls@UU.NET Thu Apr 5 13:04:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08212 for ; Thu, 5 Apr 2001 13:04:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjls28636; Thu, 5 Apr 2001 17:01:59 GMT Received: by mail-control.mail.uu.net id QQkjls29950 for mpls-outgoing; Thu, 5 Apr 2001 17:01:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjls29878 for ; Thu, 5 Apr 2001 17:01:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjls12498 for ; Thu, 5 Apr 2001 17:00:44 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjls27015 for ; Thu, 5 Apr 2001 17:00:41 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA02276; Thu, 5 Apr 2001 12:51:49 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104051651.MAA02276@workhorse.fictitious.org> To: Eric Gray cc: curtis@avici.com, George Swallow , Adrian Farrel , pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on LDP Fault Tollerance In-reply-to: Your message of "Wed, 04 Apr 2001 22:19:57 EDT." <3ACBD64D.FF5CFBCA@sandburst.com> Date: Thu, 05 Apr 2001 12:51:49 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3ACBD64D.FF5CFBCA@sandburst.com>, Eric Gray writes: > > > If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went down, > > a topology change at D-E (D-E went down) may make the path A-B-C a > > poor choice. C may have decided that the best path is by way of A > > since D-E is unavailable and is dutifully trying to inform B of the > > situation with a Label Withdraw, who will take note of it and inform A > > in due time after its finished rebooting. > > Since you didn't draw a picture, I'll try to unscramble this > alphabet soup. > > My guess is the picture is supposed to look like this: > > B > /|\ > / | \ > --- A | D --- E --- > |\ | / | > | \|/ | > | C Z > | | > W --- X --- Y > > Is that the case? My description was off. Should be: If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went down, a topology change at D-E (D-E went down) may make the path A-B-D a poor choice. D may have decided that the best path is by ^ ^ way of A since D-E is unavailable and is dutifully trying to inform B of the situation with a Label Withdraw, who will take note of it and inform A in due time after its finished rebooting. Note the two places where C is changed to D above. This is the same picture you have without the B-C link. I answered my own question. In RFC3036 "A.1.7. Detect Change in FEC Next Hop" the "Received Label Mapping" event generated in NH.12 and Note 2 cover this case as long as the next hop changed. If we look at a similar example where C were not there and there was a B-E link (or B-...-E path) that was higher cost than B-D-E, then A would not see a next hop change. If we want to prevent a persistent loop, the very minimum would be for A to reject consideration of any FEC through B for which the next hop from B has changed because B has not reflected the change. There is no such procedure in draft-ietf-mpls-ldp-ft-01.txt. A simpler approach was taken in the OSPF WG. Adjacencies to the router that was down were declared down (the IGP Grace timer was prematurely expired) when there was a change in the topology. By virtue of the IGP Grace timer expiring LDP would see a next hop change so this case too is covered as long as the IGP prematurely expires its Grace timer. This would mean that LDP does not also have to prematurely expires its timer, though it would seem that there would be no difference in behaviour since all traffic is already diverted away by virtue of all IGP next hops being changed to go elsewhere. It would only be if the IGP did not expire its Grace timer that there would be a problem in LDP (and the IGP and therefore things like IBGP would be even worse off, so the IGP would clearly need to do something). Whether the LDP timer is prematurely expired does not effect whether LDP routes are diverted away from the downed router. If the timer is prematurely expired, it just changes the behavior during recovery, only impacting how soon FEC are sent through that router again. Either keeping the text as is or recommending prematurely expiring the timer both seem to be fine options. Since it is already last call and there is no urgency I can see good reason not to make this change. Thanks for the time taken for this discussion. Curtis From owner-mpls@UU.NET Thu Apr 5 13:06:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08302 for ; Thu, 5 Apr 2001 13:06:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjls02010; Thu, 5 Apr 2001 17:04:21 GMT Received: by mail-control.mail.uu.net id QQkjls05149 for mpls-outgoing; Thu, 5 Apr 2001 17:03:45 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjls05041 for ; Thu, 5 Apr 2001 17:03:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjls04786 for ; Thu, 5 Apr 2001 17:03:22 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjls05634 for ; Thu, 5 Apr 2001 17:03:20 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA02306; Thu, 5 Apr 2001 13:00:05 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104051700.NAA02306@workhorse.fictitious.org> To: "Philip Matthews" cc: afarrel@movaz.com, curtis@avici.com, pjb@metaswitch.com, eric.gray@sandburst.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on LDP Fault Tolerance In-reply-to: Your message of "Wed, 04 Apr 2001 23:12:54 EDT." <3ACBE2B6.3A9F990B@americasm01.nt.com> Date: Thu, 05 Apr 2001 13:00:05 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3ACBE2B6.3A9F990B@americasm01.nt.com>, "Philip Matthews" writes: > I would be happy to include a paragraph or two about the interaction with > a significant IGP change. I can see that mentioning this issue would help > people understand the implications of Fault Tolerance better. However, > I would prefer to say that an implementor MAY wish to abort the session recov > ery > effort in this case, rather than saying that the implementor SHOULD implement > an option > to enable this on a per-peer basis. I don't think we understand this issue > well enough yet to recommend such an option. > > But I am strongly against limiting (or even suggesting limiting) > the use of fault tolerance to midnight software upgrades. I think other uses > are quite valid. Adrian's redundant line cards are one good example. > Another one is redundant control planes. > > - Philip Matthews > Nortel Networks Corporation The redundant control plane was the reason I had suggested that a per peer option would be good. The assumption is that if the peer had a redundant control plane the timer would not be prematurely expired since the expectation is for the peer to recover faster than the IGP would converge or at least in the same order of magnitude. For the peer that had a single control plane, the timer would be expired prematurely under the assumption that it could be a long timer (in terms of tolerable outage) before the peer came back. The per peer option also gives the operator the chance to decide if this feature is better off enabled or disabled. I'm assuming network operators have fairly high intellegence and that is better to give them this control (along with hints regarding any accumulated experience in the field in the event someone else had experience). Curtis From owner-mpls@UU.NET Thu Apr 5 13:16:13 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08575 for ; Thu, 5 Apr 2001 13:16:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjls00688; Thu, 5 Apr 2001 17:14:13 GMT Received: by mail-control.mail.uu.net id QQkjls13366 for mpls-outgoing; Thu, 5 Apr 2001 17:13:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjls13361 for ; Thu, 5 Apr 2001 17:13:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjls24005 for ; Thu, 5 Apr 2001 17:12:10 GMT Received: from spomail01.attla.corp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.netstream.com.br [200.192.1.34]) id QQkjls25809 for ; Thu, 5 Apr 2001 17:12:09 GMT Received: from nsrjo4.attla.corp ([10.21.10.6]) by spomail01.attla.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10) id HNANWSJA; Thu, 5 Apr 2001 14:14:00 -0300 Received: by nsrjo4 with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Apr 2001 14:11:31 -0300 Message-ID: From: "Loureiro, Rodrigo" To: "'Yakov Rekhter'" Cc: "'mpls@uu.net'" Subject: RES: RES: VPN/MPLS question Date: Thu, 5 Apr 2001 14:11:30 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 NAA08575 Yakov, >> The second possibility is to use redistribution, once we can use the Site of >> Origin loop avoidance mechanism. >That is the scenario I had in mind. Quoting from the Internet Draft: > > If a site is not in a transit VPN, note that it need not have a > unique Autonomous System Number (ASN). Every CE whose site > which is not in a transit VPN can use the same ASN. This can > be chosen from the private ASN space, and it will be stripped > out by the PE. Routing loops are prevented by use of the Site > of Origin Attribute (see below). >>2) Use static routing in the CE/PE, redistributing them into the VPN routing table. >> >> This scenario have a redundancy problem, >> regarding routing convergence (ATM cloud); >Could you elaborate more on this please. OK. Regarding this approach we have two solutions: 1) Use BGP in the CE and a unique ASN for the whole network (VPNs), once it will be stripped in the PE. This solution can solve the scalability problem. 2) Use static routing in the CE/PE, redistributing them into the VPN routing table. As i said this solution has a redundancy problem. For this solution to work properly, the PE should stop redistribute the CE prefix into the VPN, once the IP connectivity between the PE/CE is not available anymore. If we think about an ATM cloud, the PE probably will be connected to an ATM switch, which creates a PVC through the ATM cloud till the access switch (probably a frame-relay switch), which is connected to the CE. Now consider that the physical link between the CE and the access switch went down. The protocol in the interface connecting the CE to the switch will went down, and the CE should converge correctly through the redundant interface (considering that the CE automaticaly removes the routes from the routing table). However, the PE is connected to an ATM switch through an ATM main interface, and the connection to the CE was done through an ATM subinterface. At this moment, the L2 protocol in the PE subinterface is already up (once it´s directly connected to the ATM switch), so the static route is already a valid entry in the PE routing table. This way the redundancy doesn´t work. Maybe should be possible to solve this problem using OAM cells, but, in fact, we cannot count on this at this moment. What do you think? Thanks, -- Rodrigo From owner-mpls@UU.NET Thu Apr 5 14:25:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10634 for ; Thu, 5 Apr 2001 14:25:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjlx18734; Thu, 5 Apr 2001 18:23:38 GMT Received: by mail-control.mail.uu.net id QQkjlx07054 for mpls-outgoing; Thu, 5 Apr 2001 18:23:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjlx07046 for ; Thu, 5 Apr 2001 18:23:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjlx11382 for ; Thu, 5 Apr 2001 18:20:21 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjlx16715 for ; Thu, 5 Apr 2001 18:20:20 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA02527; Thu, 5 Apr 2001 14:11:49 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104051811.OAA02527@workhorse.fictitious.org> To: afarrel@movaz.com cc: curtis@avici.com, pjb@metaswitch.com, philipma@nortelnetworks.com, eric.gray@sandburst.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Last Call on LDP Fault Tolerance In-reply-to: Your message of "Thu, 05 Apr 2001 10:28:32 EDT." <4F9E13BCC53ED411A629009027E8D00C043336E0@msg001.dcat.ops.broadbandoffice.net> Date: Thu, 05 Apr 2001 14:11:49 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <4F9E13BCC53ED411A629009027E8D00C043336E0@msg001.dcat.ops.broadbando ffice.net>, afarrel@movaz.com writes: > 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_01C0BDDC.B0C2B8E0 > Content-Type: text/plain; > charset="iso-8859-1" > > > > > > I find... > > > > There appears to be a school of thought where it is > > > > deemed beneficial to keep forwarding state intact > > > > in only very limited cases such as midnight > > > > controlled reload of routers for purposes such > > > > as software upgrade. > > > ...odd. When a line card fails I should like to be > > > able to swap to a new card and continue forwarding > > > data with only a very short (10s of ms) break. > > > > When a line card fails, that line card will still be in the box for at > > least a few minutes, more likely the better part of an hour, maybe > > longer. I don't know of any technician that can swap a line card in > > 10 msec. I also don't know of any line card that can reboot in 10 > > msec. When a line card fails if there is a TE tunnel and > > local-protect on the TE tunnel, then the switch over is very fast. If > > it is LDP without TE or TE without local protect, the 10s of msec is > > very likely not acheived. That has absolutely nothing to do with > > LDP-FT so I don't see why you brought it up. > > It has everything to do with LDP FT. > One of the key aims is to be able to switch "seamlessly" to another card > _that_is_already_in_the_box. > If the failed card was running LDP you must preserve protocol states etc. > If the failed card was a line card not running LDP, you must handle the > failed TCP connection (i.e. LDP session) and re-instate it through the > replacement card. I see your point. This is similar to the redundant control plane case. See my prior mail on that and why I suggested per peer configuration of this option. Curtis From owner-mpls@UU.NET Thu Apr 5 15:14:55 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11593 for ; Thu, 5 Apr 2001 15:14:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjma10075; Thu, 5 Apr 2001 19:12:47 GMT Received: by mail-control.mail.uu.net id QQkjma27280 for mpls-outgoing; Thu, 5 Apr 2001 19:12:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjma27275 for ; Thu, 5 Apr 2001 19:12:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjma07501 for ; Thu, 5 Apr 2001 19:11:25 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjma24696 for ; Thu, 5 Apr 2001 19:11:24 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA11702 for mpls@uu.net; Thu, 5 Apr 2001 15:11:24 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjma26759 for ; Thu, 5 Apr 2001 19:07:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjma23379 for ; Thu, 5 Apr 2001 19:04:25 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQkjma15983 for ; Thu, 5 Apr 2001 19:04:24 GMT Received: (qmail 25157 invoked by uid 104); 5 Apr 2001 19:04:24 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.459147 secs); 05/04/2001 12:04:23 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 5 Apr 2001 19:04:23 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f35J4MB17445; Thu, 5 Apr 2001 12:04:22 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Apr 2001 12:05:10 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6B9B@BBY1EXM01> From: Shahram Davari To: "'Sasha Vainshtein'" , "'N S S Kishore Kankipati'" , flefauch@cisco.com, liwwu@cisco.com Cc: mpls@UU.NET, "'diffserv@ietf.org'" Subject: RE: Diff-Serv over MPLS Date: Thu, 5 Apr 2001 12:05:02 -0700 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 Sasha, The Diffserv over MPLS draft is not introducing any changes to Diffserv. Therefore all the Diffserv standards must be followed including not reordering the packets belonging to a microflow. It is true that in theory it is possible to reorder packets that belong to a microflow if PHBs are not mapped properly to E-LSPs, but that is a misconfiguration. I think everybody knows that they should not misconfigure their network. I don't think we need to tell people how to avoid misordering, all we have to do is to require that no misordering to happen. Just as an example assume that an AF1x aggregate consists of only 2 microflows: A, and B. If A never exceeds its committed policed rate (therefore all packet belonging to A are AF11), and if B's committed rate is zero, in other words it always exceed its committed rate (therefore all its packets are AF12/AF13), then no reordering of microflow will happen if we send the AF11 aggregate through an E-LSP and the AF12/AF13 through another E-LSP. Not that I recommend such a configuration, but the above example shows a scenario that is actually compliant with Diffserv. Yours, -Shahram > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Thursday, April 05, 2001 12:16 PM > To: 'N S S Kishore Kankipati'; flefauch@cisco.com; liwwu@cisco.com > Cc: mpls@UU.NET; 'diffserv@ietf.org' > Subject: RE: Diff-Serv over MPLS > > > > Hi, > The reordering issue has been addressed in > , > "New Terminology for Diffserv" with an explicit > reference to work > on MPLS Support of Differentiated Services. > Section 5 of this I-D introduces the notion of an Ordering > Aggregate (OA) as > A set of Behavior Aggregates that share an ordering > constraint. > The set of PHBs that are applied to this set of > Behavior Aggregates > > constitutes a PHB scheduling class. > > I suggest that should > be updated > to > allow only grouping of multiple OAs (and not BAs as it > does) into > a single E-LSP. The current I-D version explicitly states > that L-LSP is established for a given (OA, FEC) class but is > ambiguous when it comes to E-LSPs. > > Nabil, in his message in this thread, has noticed that RFC 2597 > defines AF (y=1,2,3) as an OA for any fixed value > of x (1-4). > The suggested modification would prohibit > configurations like one > described > in the original message. > ______________________________________________ > With best regards, > Sasha Vainshtein > mailto: sasha@axerra.com > phone: +972-3-7659993 (office) > fax: +972-3-6487779 (office) > > > >>-----Original Message----- > >>From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com] > >>Sent: Thursday, April 05, 2001 3:39 PM > >>To: flefauch@cisco.com; liwwu@cisco.com > >>Cc: mpls@UU.NET > >>Subject: Diff-Serv over MPLS > >> > >> > >>hi all > >> Could any of you please explain about the following > >>sentence in the draft-ietf-mpls-diff-ext-0.8.txt. > >> > >>section 1.2-- Exp-Inferred-PSC LSPS (E-LSP) > >> > >>"A single LSP can be used to support up to eight BAs > >>of > >>a given FEC, regardless of how many OAs these BAs > >>span." > >> > >>A small doubt > >> Suppose PHBs related to a PSC have been assigned to > >>different E-LSPs (say AF11 to one LSP and AF12 to > >>another LSP)and first few (say 1-10)Packets belonging > >>to a microflow have been assigned to AF11 and later > >>packets (say 10-15) to AF12. > >>Is it not possible for the packets in AF12 LSP to get > >>transferred before the packets in AF11 LSP? If that is > >>the case the ordering constraint is violated i.e > >>packets are reordered. (I think this may happen in > >>the following case- if the LSPs are on different > >>interfaces of a router and there may be some packets > >>which are required to be served in the AF11 while the > >>packets in AF12 may get immediately served as there > >>are > >>no packets before these which require service). > >> > >>thanks > >>kk > >> > >>__________________________________________________ > >>Do You Yahoo!? > >>Get email at your own domain with Yahoo! Mail. > >>http://personal.mail.yahoo.com/ > >> > From owner-mpls@UU.NET Thu Apr 5 16:29:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13763 for ; Thu, 5 Apr 2001 16:29:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjmf20677; Thu, 5 Apr 2001 20:26:59 GMT Received: by mail-control.mail.uu.net id QQkjmf20769 for mpls-outgoing; Thu, 5 Apr 2001 20:26:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjmf20460 for ; Thu, 5 Apr 2001 20:23:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjmf19487 for ; Thu, 5 Apr 2001 20:19:43 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkjmf09963 for ; Thu, 5 Apr 2001 20:19:42 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 NAA08774 for ; Thu, 5 Apr 2001 13:20:04 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA18126 for mpls@uu.net; Thu, 5 Apr 2001 16:19:40 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjmd01121 for ; Thu, 5 Apr 2001 19:55:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjmd01629 for ; Thu, 5 Apr 2001 19:54:19 GMT Received: from stephens.ittc.ukans.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: stephens.ittc.ukans.edu [129.237.125.220]) id QQkjmd06350 for ; Thu, 5 Apr 2001 19:54:09 GMT Received: from bunsen.ittc.ukans.edu (bunsen.ittc.ukans.edu [129.237.126.78]) by stephens.ittc.ukans.edu (8.11.2/8.11.2/ITTC-NOSPAM-NOVIRUS-2.2) with ESMTP id f35Js8t21475 for ; Thu, 5 Apr 2001 14:54:08 -0500 Received: from localhost by bunsen.ittc.ukans.edu (8.9.3/KU-4.0-client) id OAA04864; Thu, 5 Apr 2001 14:54:08 -0500 Date: Thu, 5 Apr 2001 14:54:08 -0500 (CDT) From: Rameshbabu Prabagaran To: mpls@UU.NET Subject: doubt in RFC 2547bis-03 route-refresh mechanism Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I have a doubt regarding the route-refresh mechanisms to be used as per 2547bis-03. Consider the following transition from a fully meshed CUG to a hub and spoke type of VPN. CEred1 CEred2 | | | | CEblue1----PE1------------PE2----CEblue2 \ / \ / \ / \ / I \ / \ / PE3 | | CEred3 CEspoke1 CEspoke2 | | | | CEspoke3----PE1-------------PE2----CEspoke4 \ / \ / \ / \ / II \ / \ / PE3 | | CEhub In the above case, assuming that customers do not withdraw their routes, is a smooth transition possible from the CUG scenario to the Hub and spoke scenario. My question actually is, if PE1, PE2 and PE3 are configured with the new import and export targets, then, unless they are configured at _exactly_ the same time, they cannot have proper route dissemination with the new targets in place i.e. by using BGP route-refresh mechanism. To elaborate, if red RD is 100:1, blue RD is 100:2, spoke RD is 100:1 and hub RD is 100:2, and if PE1 is configured for the change prior to PE2, then there is a possibility that the routes that were earlier belonging to the blue VPN (CEblue2's routes) can be installed in the VRF belonging to RD 'spoke' (atleast temporarily) when a route-refresh message is sent from PE1. Is this a desired behavior or am I missing something here ? Thanks in advance for any inputs. regards, Ramesh. From owner-mpls@UU.NET Thu Apr 5 16:48:39 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14060 for ; Thu, 5 Apr 2001 16:48:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjmh16253; Thu, 5 Apr 2001 20:46:02 GMT Received: by mail-control.mail.uu.net id QQkjmh22664 for mpls-outgoing; Thu, 5 Apr 2001 20:45:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjmh22645 for ; Thu, 5 Apr 2001 20:45:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjmg24450 for ; Thu, 5 Apr 2001 20:44:25 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjmg04112 for ; Thu, 5 Apr 2001 20:44:25 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA19329 for mpls@uu.net; Thu, 5 Apr 2001 16:44:24 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjmg22286 for ; Thu, 5 Apr 2001 20:43:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjmg22729 for ; Thu, 5 Apr 2001 20:42:17 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkjmg05894 for ; Thu, 5 Apr 2001 20:42:16 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA25408; Thu, 5 Apr 2001 13:42:37 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f35Kg9A08819; Thu, 5 Apr 2001 13:42:10 -0700 (PDT) Message-ID: <3ACCD846.E4483053@cisco.com> Date: Thu, 05 Apr 2001 13:40:38 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rameshbabu Prabagaran CC: mpls@UU.NET Subject: Re: doubt in RFC 2547bis-03 route-refresh mechanism References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Rameshbabu, Yr msg is so confusing that I am not even sure how to start. First let me asnswer your question. If you want to transition from full mesh vpn to hub and spoke the simple steps would be: 1. Leave the RDs alone. 2. Inject default route from a future Hub site into all other site for a given VPN. 3. Adjust RT (route targets) to eliminate not needed routes at spoke (and spoke PEs). Done. I don't really see any issue with route-refresh here. The issue you are trying to descibe is the RD misconfiguration caused by operator. R. > Rameshbabu Prabagaran wrote: > > I have a doubt regarding the route-refresh mechanisms to be > used as per 2547bis-03. > > Consider the following transition from a fully meshed CUG to > a hub and spoke type of VPN. > > CEred1 CEred2 > | | > | | > CEblue1----PE1------------PE2----CEblue2 > \ / > \ / > \ / > \ / > I \ / > \ / > PE3 > | > | > CEred3 > > CEspoke1 CEspoke2 > | | > | | > CEspoke3----PE1-------------PE2----CEspoke4 > \ / > \ / > \ / > \ / > II \ / > \ / > PE3 > | > | > CEhub > > In the above case, assuming that customers do not withdraw their > routes, is a smooth transition possible from the CUG scenario to the > Hub and spoke scenario. > > My question actually is, if PE1, PE2 and PE3 are configured with the > new import and export targets, then, unless they are configured at > _exactly_ the same time, they cannot have proper route dissemination > with the new targets in place i.e. by using BGP route-refresh > mechanism. To elaborate, if red RD is 100:1, blue RD is 100:2, > spoke RD is 100:1 and hub RD is 100:2, and if PE1 is configured for > the change prior to PE2, then there is a possibility that the > routes that were earlier belonging to the blue VPN (CEblue2's routes) > can be installed in the VRF belonging to RD 'spoke' (atleast > temporarily) when a route-refresh message is sent from PE1. > > Is this a desired behavior or am I missing something here ? > Thanks in advance for any inputs. > > regards, > Ramesh. From owner-mpls@UU.NET Thu Apr 5 17:18:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14759 for ; Thu, 5 Apr 2001 17:18:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjmj18062; Thu, 5 Apr 2001 21:16:22 GMT Received: by mail-control.mail.uu.net id QQkjmj11427 for mpls-outgoing; Thu, 5 Apr 2001 21:15:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjmj11419 for ; Thu, 5 Apr 2001 21:15:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjmi25944 for ; Thu, 5 Apr 2001 21:14:48 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkjmi04203 for ; Thu, 5 Apr 2001 21:14:48 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15602 for ; Thu, 5 Apr 2001 17:14:45 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15016 for ; Thu, 5 Apr 2001 17:14:48 -0400 (EDT) Message-ID: <3ACCE057.2C4A2C27@marconi.com> Date: Thu, 05 Apr 2001 17:15:03 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: LDP remote peer question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I've a question regarding remote peers and the LDP protocol. Remote peers are managed using unicast UDP messages for Hello and TCP session. These peers are not (I think) bound to an interface. Which means that if the local routing table should change, then the interface associated with the remote peer may also change. If per-platform label spaces are used, this is not a problem. On routers with per-interface label spaces, however, this might be a real problem. Once the TCP socket moves to a different interface, all of its labels must also move. This may not be possible, since there may be conflicting label assignments on the new interface. But to release all of the remote peer's labels before the move, and then re-request them afterwards is a lot of overhead. And it will cause service interruptions during this reconvergence period. Is this correct? Is there a solution to this problem? Obviously, the best way is to implement per-platform label spaces, but this is may not be possible (or efficient) on all hardware platforms. -- David From owner-mpls@UU.NET Thu Apr 5 21:02:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17243 for ; Thu, 5 Apr 2001 21:02:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjll13127; Thu, 5 Apr 2001 15:24:05 GMT Received: by mail-control.mail.uu.net id QQkjll00468 for mpls-outgoing; Thu, 5 Apr 2001 15:23:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjll00462 for ; Thu, 5 Apr 2001 15:23:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjll04850 for ; Thu, 5 Apr 2001 15:21:04 GMT Received: from gw.tropicnetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: gw.tropicnetworks.com [209.87.233.9]) id QQkjll09268 for ; Thu, 5 Apr 2001 15:21:04 GMT Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for cmr0.ash.ops.us.uu.net [198.5.241.38]) with SMTP; 5 Apr 2001 15:21:04 UT Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with ESMTP id AAA4559; Thu, 5 Apr 2001 11:21:07 -0400 Message-ID: <3ACC8C63.CB5AC12F@tropicnetworks.com> Date: Thu, 05 Apr 2001 11:16:51 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: N S S Kishore Kankipati CC: flefauch@cisco.com, liwwu@cisco.com, mpls@UU.NET Subject: Re: Diff-Serv over MPLS References: <20010405133928.37665.qmail@web13702.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 > A small doubt > Suppose PHBs related to a PSC have been assigned to > different E-LSPs (say AF11 to one LSP and AF12 to > another LSP)and first few (say 1-10)Packets belonging > to a microflow have been assigned to AF11 and later > packets (say 10-15) to AF12. > Is it not possible for the packets in AF12 LSP to get > transferred before the packets in AF11 LSP? The above is not possible if you want to maintain conformance with RFC 2597. From section 2 of that document: "A DS node MUST NOT reorder AF packets of the same microflow when they belong to the same AF class regardless of their drop precedence." The means used to achieve the above are vendor-specific. One simple way is to ensure AF11 and AF12 packets are directed to the same physical queue. Of course, you also ensure that a micro-flow's packets are only marked for treatment with PHBs from a single AF class. --- Best, Nabil Seddigh nseddigh@tropicnetworks.com From owner-mpls@UU.NET Fri Apr 6 05:05:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06543 for ; Fri, 6 Apr 2001 05:05:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjoe07524; Fri, 6 Apr 2001 09:03:48 GMT Received: by mail-control.mail.uu.net id QQkjoe22703 for mpls-outgoing; Fri, 6 Apr 2001 09:03:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjoe22621 for ; Fri, 6 Apr 2001 09:03:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjoe28825 for ; Fri, 6 Apr 2001 09:03:03 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjoe07486 for ; Fri, 6 Apr 2001 09:03:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA15644 for mpls@uu.net; Fri, 6 Apr 2001 05:03:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjoe22169 for ; Fri, 6 Apr 2001 09:02:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjoe06387 for ; Fri, 6 Apr 2001 09:02:14 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQkjoe06618 for ; Fri, 6 Apr 2001 09:02:13 GMT Received: from flefauch-8kcdt.cisco.com (dhcp-nic-val-26-98.cisco.com [64.103.26.98]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA19097; Fri, 6 Apr 2001 11:01:54 +0200 (MET DST) Message-Id: <4.0.2.20010406101726.0219ae20@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 06 Apr 2001 10:55:08 +0200 To: Sasha Vainshtein From: Francois Le Faucheur Subject: RE: Diff-Serv over MPLS Cc: "'N S S Kishore Kankipati'" , flefauch@cisco.com, liwwu@cisco.com, mpls@UU.NET, "'diffserv@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_5988798==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_5988798==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sasha, Section 1.4 of contains the following= text: " For a given FEC, there may be more than one LSP carrying the same OA, for example for purposes of load balancing of the OA; However in order to respect ordering constraints, all packets of a given microflow, possibly spanning multiple BAs of a given Ordered Aggregate, MUST be transported over the same LSP. Conversely, each LSP MUST be capable of supporting all the (active) BAs of a given OA. " which applies both to E-LSPs and L-LSPs. So, I believe (i) the ordering constraint and (ii) the requirement for= L-LSPs to support all active BAs of an OA are already accurately addressed. The only question is whether the readability of the document would be= improved by some wordsmithing in section 1.2. If you feel that would help, we can slightly modify the beginning of section 1.2 into: " A single LSP can be used to support one or more OAs. Such LSPs can= support up to eight BAs of a given FEC, regardless of how many OAs these BAs span." Do you feel this would improve readability? If yes, can you confirm the above suggestion is fine? Cheers Francois At 18:15 05/04/2001 +0200, Sasha Vainshtein wrote: > >Hi, > The reordering issue has been addressed in >, > "New Terminology for Diffserv" with an explicit reference to work=20 > on MPLS Support of Differentiated Services. > Section 5 of this I-D introduces the notion of an Ordering >Aggregate (OA) as=20 > A set of Behavior Aggregates that share an ordering >constraint.=20 > The set of PHBs that are applied to this set of Behavior Aggregates > > constitutes a PHB scheduling class. > =20 > I suggest that should be updated >to=20 > allow only grouping of multiple OAs (and not BAs as it does) into > a single E-LSP. The current I-D version explicitly states > that L-LSP is established for a given (OA, FEC) class but is =20 > ambiguous when it comes to E-LSPs.=20 > > Nabil, in his message in this thread, has noticed that RFC 2597 > defines AF (y=3D1,2,3) as an OA for any fixed value of x= (1-4).=20 > The suggested modification would prohibit configurations like one >described > in the original message.=20 >______________________________________________ >With best regards, >Sasha Vainshtein >mailto: sasha@axerra.com >phone: +972-3-7659993 (office) >fax: +972-3-6487779 (office) > > >>>-----Original Message----- >>>From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com] >>>Sent: Thursday, April 05, 2001 3:39 PM >>>To: flefauch@cisco.com; liwwu@cisco.com >>>Cc: mpls@UU.NET >>>Subject: Diff-Serv over MPLS >>> >>> >>>hi all =20 >>> Could any of you please explain about the following >>>sentence in the draft-ietf-mpls-diff-ext-0.8.txt. >>> >>>section 1.2-- Exp-Inferred-PSC LSPS (E-LSP) >>> >>>"A single LSP can be used to support up to eight BAs >>>of >>>a given FEC, regardless of how many OAs these BAs >>>span." >>> >>>A small doubt >>> Suppose PHBs related to a PSC have been assigned to >>>different E-LSPs (say AF11 to one LSP and AF12 to >>>another LSP)and first few (say 1-10)Packets belonging >>>to a microflow have been assigned to AF11 and later >>>packets (say 10-15) to AF12.=20 >>>Is it not possible for the packets in AF12 LSP to get >>>transferred before the packets in AF11 LSP? If that is >>>the case the ordering constraint is violated i.e >>>packets are reordered. (I think this may happen in=20 >>>the following case- if the LSPs are on different=20 >>>interfaces of a router and there may be some packets >>>which are required to be served in the AF11 while the >>>packets in AF12 may get immediately served as there >>>are >>>no packets before these which require service). >>>=20 >>>thanks >>>kk >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Get email at your own domain with Yahoo! Mail.=20 >>>http://personal.mail.yahoo.com/ >>> >=20 PLEASE NOTE NEW CONTACT DETAILS - See below _________________________________________________________________ Francois Le Faucheur =20 Development Engineer, IOS Layer 3 Services=20 Cisco Systems=20 Office Phone: +33 4 97 23 26 19 Mobile : +33 6 89 108 159 Fax: +33 4 97 23 26 26 Email: flefauch@cisco.com _________________________________________________________________ Cisco Systems Europe Domaine Green Side 400, Avenue de Roumanille B=E2timent T3 06 410 BIOT=20 SOPHIA ANTIPOLIS FRANCE _________________________________________________________________ =20 --=====================_5988798==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sasha,

Section 1.4 of <draft-ietf-mpls-diff-ext-08.txt> contains the following text:

"   For a given FEC, there may be more than one LSP carrying the same
   OA, for example for purposes of load balancing of the OA; However in
   order to respect ordering constraints, all packets of a given
   microflow, possibly spanning multiple BAs of a given Ordered
   Aggregate, MUST be transported over the same LSP. Conversely, each
   LSP MUST be capable of supporting all the (active) BAs of a given
   OA.
"

which applies both to E-LSPs and L-LSPs.

So, I believe (i) the ordering constraint and (ii) the requirement for L-LSPs to support all active BAs of an OA are already accurately addressed.


The only question is whether the readability of the document would be improved by some wordsmithing in section 1.2. If you feel that would help, we can slightly modify the beginning of section 1.2 into:
"   A single LSP can be used to support one or more OAs. Such LSPs can support up to eight BAs of a given FEC,
   regardless of how many OAs these BAs=20 span."

Do you feel this would improve readability?
If yes, can you confirm the above suggestion is fine?

Cheers

Francois




At 18:15 05/04/2001 +0200, Sasha Vainshtein wrote:
>
>Hi,
>       The reordering issue has been addressed in
><draft-ietf-diffserv-new-terms-04.txt>,
>       "New Terminology for Diffserv" with an explicit reference to work
>       on MPLS Support of Differentiated Services.
>       Section 5 of this I-D introduces the notion of an Ordering
>Aggregate (OA) as
>       <quote> A set of Behavior Aggregates that share an ordering
>constraint.
>       The set of PHBs that are applied to this set of Behavior Aggregates
>
>       constitutes a PHB scheduling class. <end of quote>
>      
>       I suggest that <draft-ietf-mpls-diff-ext-08.txt> should be updated
>to
>       allow only grouping of multiple OAs (and not BAs as it does) into
>       a single E-LSP. The current I-D version explicitly states
>       that L-LSP is established for a given (OA, FEC) class but is 
>       ambiguous when it comes to E-LSPs.
>
>       Nabil, in his message in this thread, has noticed that RFC 2597
>       defines AF<x><y> (y=3D1,2,3) as an OA for any fixed value of x (1-4).
>       The suggested modification would prohibit configurations like one
>described
>       in the original message.
>______________________________________________
>With best regards,
>Sasha Vainshtein
>mailto: sasha@axerra.com
>phone: +972-3-7659993 (office)
>fax:      +972-3-6487779 (office)
>
>
>>>-----Original Message-----
>>>From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com]
>>>Sent: Thursday, April 05, 2001 3:39 PM
>>>To: flefauch@cisco.com; liwwu@cisco.com
>>>Cc: mpls@UU.NET
>>>Subject: Diff-Serv over MPLS
>>>
>>>
>>>hi all      
>>>   Could any of you please explain about the= following
>>>sentence in the draft-ietf-mpls-diff-ext-0.8.txt.
>>>
>>>section 1.2-- Exp-Inferred-PSC LSPS (E-LSP)
>>>
>>>"A single LSP can be used to support up to eight= BAs
>>>of
>>>a given FEC, regardless of how many OAs these BAs
>>>span."
>>>
>>>A small doubt
>>>  Suppose PHBs related to a PSC have been assigned= to
>>>different E-LSPs (say AF11 to one LSP and AF12 to
>>>another LSP)and first few (say 1-10)Packets belonging
>>>to a microflow have been assigned to AF11 and later
>>>packets (say 10-15) to AF12.
>>>Is it not possible for the packets in AF12 LSP to get
>>>transferred before the packets in AF11 LSP? If that= is
>>>the case the ordering constraint is violated i.e
>>>packets are reordered. (I think this may happen in
>>>the following case- if the LSPs are on different
>>>interfaces of a router and  there may be some= packets
>>>which are required to be served in the AF11 while the
>>>packets in AF12 may get immediately served as there
>>>are
>>>no packets before these which require service).
>>>
>>>thanks
>>>kk
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Get email at your own domain with Yahoo! Mail.
>>>
>=20
PLEASE NOTE NEW CONTACT DETAILS - See= below

_________________________________________________________= ________
Francois Le Faucheur  
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97= 23 26 19
Mobile= :            &n= bsp;  +33 6 89 108 159
Fax:            =        +33 4 97 23 26 26
Email:           &nbs= p;      flefauch@cisco.com
_________________________________________________________________
Cisco Systems Europe
Domaine Green Side
400, Avenue de Roumanille
B=E2timent T3
06 410   BIOT
SOPHIA ANTIPOLIS
FRANCE
_________________________________________________________________= --=====================_5988798==_.ALT-- From owner-mpls@UU.NET Fri Apr 6 08:08:22 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07898 for ; Fri, 6 Apr 2001 08:08:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjoq26351; Fri, 6 Apr 2001 12:06:35 GMT Received: by mail-control.mail.uu.net id QQkjoq00468 for mpls-outgoing; Fri, 6 Apr 2001 12:06:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjoq00439 for ; Fri, 6 Apr 2001 12:05:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjoq05427 for ; Fri, 6 Apr 2001 12:03:45 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjoq23260 for ; Fri, 6 Apr 2001 12:03:44 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA21434 for mpls@uu.net; Fri, 6 Apr 2001 08:03:44 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjoq23134 for ; Fri, 6 Apr 2001 12:03:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjoq25386 for ; Fri, 6 Apr 2001 12:02:11 GMT Received: from ckmso1.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ckmso1.att.com [12.20.58.69]) id QQkjoq21590 for ; Fri, 6 Apr 2001 12:02:11 GMT Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f36C1c108337; Fri, 6 Apr 2001 08:01:38 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id IAA19189; Fri, 6 Apr 2001 08:00:56 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 08:01:37 -0400 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'neil.2.harrison@bt.com'" , raszuk@cisco.com Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Fri, 6 Apr 2001 08:01:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Voice switches will drop the connections after 2.5 seconds. A large number of dropped calls will cause FCC reportable events, which is something that US carriers need to avoid. So restoration within this time frame is needed for support of trunks carrying voice traffic. Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Monday, April 02, 2001 5:19 AM To: raszuk@cisco.com Cc: mpls@UU.NET; ccamp@ops.ietf.org Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Robert Raszuk [mailto:raszuk@cisco.com] wrote 01 April 2001 09:02 > Giles, > > > > For the user-plane, the failure modes which must be > considered/defined are: > > > - simple below MPLS fabric server layer connectivity breaks; > > > - simple within MPLS fabric connectivity breaks (at > or below the LSP > > > level considered); > > > > Both of these will be detected by the RSVP signalling, won't they? > > Sure but the question is when ? > > Do you think that RSVP Error/Tear msgs will travel > immediately - case of > link failure or are you proposing to run RSVP refresh in the interval > less then 1 sec - to detect the case of node failure ? The > point is that > this draft is not about detection, but about backup LSP setup > and label > allocation under the __local__ protection scheme. So let's talk on the > subject here. > > If one questions the use of local protection all together > please specify > how else you will achive the same results of even less then 1 > sec end to > end traffic disruption with end to end protection under both > link & node > failures for the TE- LSP ? NH=> Fair point Robert.....but it still leaves me wondering: 1 Why do we need such fast action......voice surely does not need few 10s ms restoration, 1-3s would be fine I feel sure (for the relatively rare case of failure......unless, perhaps, one expects such failures to occur on a very frequent basis)? BTW- I suspect the biggest source of 'disruptions' will be planned-works by operators at L1, ie pre-meditiated re-routing of traffic.....so some care should be taken that such actions don't invoke unecessary actions in higher layers. 2 Where are the failures referenced specified? Have Cisco their own specifications for this? We would really like to see these specified in some standard manner. thanks/regards, neil From owner-mpls@UU.NET Fri Apr 6 09:04:00 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08522 for ; Fri, 6 Apr 2001 09:03:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjou13847; Fri, 6 Apr 2001 13:01:53 GMT Received: by mail-control.mail.uu.net id QQkjou08500 for mpls-outgoing; Fri, 6 Apr 2001 13:01:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjou08127 for ; Fri, 6 Apr 2001 13:01:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjou26926 for ; Fri, 6 Apr 2001 13:00:38 GMT Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.telefonica.com.ar [168.226.49.11]) id QQkjou27879 for ; Fri, 6 Apr 2001 13:00:36 GMT Received: by MAIL1 with Internet Mail Service (5.5.2448.0) id ; Fri, 6 Apr 2001 09:58:26 -0300 Message-ID: <49BB9783DE7FD411A29D00508B6F0AD852F2FC@MSTELEFONICA1> From: Zappacosta Rolando Jorge To: "'Lazer, Monica A, NNAD'" , "'neil.2.harrison@bt.com'" , raszuk@cisco.com Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Fri, 6 Apr 2001 09:58:24 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I agree, this is the same everywhere. I've been looking at these mails with interest because this may be an issue in the NGNs backbones. Take also into account that the disruption may be not enough to drop calls but to cause a voice quality degradation incompatible with the desired one, so the less the down time, the happier the service providers will be. > -----Mensaje original----- > De: Lazer, Monica A, NNAD [SMTP:mlazer@att.com] > Enviado el: Viernes 6 de Abril de 2001 09:02 > Para: 'neil.2.harrison@bt.com'; raszuk@cisco.com > CC: mpls@UU.NET; ccamp@ops.ietf.org > Asunto: RE: Last Call on RSVP Label Allocation for Backup Tunnels > > Voice switches will drop the connections after 2.5 seconds. A large number > of dropped calls will cause FCC reportable events, which is something that > US carriers need to avoid. So restoration within this time frame is needed > for support of trunks carrying voice traffic. > > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com > > > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Monday, April 02, 2001 5:19 AM > To: raszuk@cisco.com > Cc: mpls@UU.NET; ccamp@ops.ietf.org > Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels > > Robert Raszuk [mailto:raszuk@cisco.com] wrote 01 April 2001 09:02 > > Giles, > > > > > > For the user-plane, the failure modes which must be > > considered/defined are: > > > > - simple below MPLS fabric server layer connectivity breaks; > > > > - simple within MPLS fabric connectivity breaks (at > > or below the LSP > > > > level considered); > > > > > > Both of these will be detected by the RSVP signalling, won't they? > > > > Sure but the question is when ? > > > > Do you think that RSVP Error/Tear msgs will travel > > immediately - case of > > link failure or are you proposing to run RSVP refresh in the interval > > less then 1 sec - to detect the case of node failure ? The > > point is that > > this draft is not about detection, but about backup LSP setup > > and label > > allocation under the __local__ protection scheme. So let's talk on the > > subject here. > > > > If one questions the use of local protection all together > > please specify > > how else you will achive the same results of even less then 1 > > sec end to > > end traffic disruption with end to end protection under both > > link & node > > failures for the TE- LSP ? > NH=> Fair point Robert.....but it still leaves me wondering: > 1 Why do we need such fast action......voice surely does not need > few > 10s ms restoration, 1-3s would be fine I feel sure (for the relatively > rare > case of failure......unless, perhaps, one expects such failures to occur > on > a very frequent basis)? > BTW- I suspect the biggest source of 'disruptions' will be planned-works > by > operators at L1, ie pre-meditiated re-routing of traffic.....so some care > should be taken that such actions don't invoke unecessary actions in > higher > layers. > 2 Where are the failures referenced specified? Have Cisco their own > specifications for this? We would really like to see these specified in > some standard manner. > > thanks/regards, neil From owner-mpls@UU.NET Fri Apr 6 11:25:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12076 for ; Fri, 6 Apr 2001 11:25:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjpd28521; Fri, 6 Apr 2001 15:23:51 GMT Received: by mail-control.mail.uu.net id QQkjpd07519 for mpls-outgoing; Fri, 6 Apr 2001 15:23:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjpd07513 for ; Fri, 6 Apr 2001 15:23:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjpd27797 for ; Fri, 6 Apr 2001 15:15:57 GMT Received: from auemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQkjpd08623 for ; Fri, 6 Apr 2001 15:15:56 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA07169 for ; Fri, 6 Apr 2001 11:15:56 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA07136 for ; Fri, 6 Apr 2001 11:15:55 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Apr 2001 17:15:54 +0200 Message-ID: <114DE1AABD7DD41189B600508BAF1271956B29@nl0006exch005u.nl.lucent.com> From: "Mak, L (Leen)" To: "'Lazer, Monica A, NNAD'" , "'neil.2.harrison@bt.com'" , raszuk@cisco.com Cc: mpls@UU.NET, ccamp@ops.ietf.org, "Mak, L (Leen)" Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Fri, 6 Apr 2001 17:15:48 +0200 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 There are (used to be?) voice switches in the PSTN which start dropping calls within 100 ms after loosing a trunk. This was at least one of the reasons for the 50 ms figure found in SDH specs. If the trunk is carried on an STM16, you could loose >32k calls because of a cable cut. Some operators do not like that. Leen Mak > -----Original Message----- > From: Lazer, Monica A, NNAD [mailto:mlazer@att.com] > Sent: Friday, April 06, 2001 14:02 > To: 'neil.2.harrison@bt.com'; raszuk@cisco.com > Cc: mpls@UU.NET; ccamp@ops.ietf.org > Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels > > > Voice switches will drop the connections after 2.5 seconds. A > large number > of dropped calls will cause FCC reportable events, which is > something that > US carriers need to avoid. So restoration within this time > frame is needed > for support of trunks carrying voice traffic. > > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com > > > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Monday, April 02, 2001 5:19 AM > To: raszuk@cisco.com > Cc: mpls@UU.NET; ccamp@ops.ietf.org > Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels > > Robert Raszuk [mailto:raszuk@cisco.com] wrote 01 April 2001 09:02 > > Giles, > > > > > > For the user-plane, the failure modes which must be > > considered/defined are: > > > > - simple below MPLS fabric server layer > connectivity breaks; > > > > - simple within MPLS fabric connectivity breaks (at > > or below the LSP > > > > level considered); > > > > > > Both of these will be detected by the RSVP signalling, won't they? > > > > Sure but the question is when ? > > > > Do you think that RSVP Error/Tear msgs will travel > > immediately - case of > > link failure or are you proposing to run RSVP refresh in > the interval > > less then 1 sec - to detect the case of node failure ? The > > point is that > > this draft is not about detection, but about backup LSP setup > > and label > > allocation under the __local__ protection scheme. So let's > talk on the > > subject here. > > > > If one questions the use of local protection all together > > please specify > > how else you will achive the same results of even less then 1 > > sec end to > > end traffic disruption with end to end protection under both > > link & node > > failures for the TE- LSP ? > NH=> Fair point Robert.....but it still leaves me wondering: > 1 Why do we need such fast action......voice surely > does not need few > 10s ms restoration, 1-3s would be fine I feel sure (for the > relatively rare > case of failure......unless, perhaps, one expects such > failures to occur on > a very frequent basis)? > BTW- I suspect the biggest source of 'disruptions' will be > planned-works by > operators at L1, ie pre-meditiated re-routing of > traffic.....so some care > should be taken that such actions don't invoke unecessary > actions in higher > layers. > 2 Where are the failures referenced specified? Have > Cisco their own > specifications for this? We would really like to see these > specified in > some standard manner. > > thanks/regards, neil > From owner-mpls@UU.NET Fri Apr 6 13:55:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15735 for ; Fri, 6 Apr 2001 13:55:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjpn13077; Fri, 6 Apr 2001 17:53:26 GMT Received: by mail-control.mail.uu.net id QQkjpn25776 for mpls-outgoing; Fri, 6 Apr 2001 17:52:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjpn25751 for ; Fri, 6 Apr 2001 17:52:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjpn24185 for ; Fri, 6 Apr 2001 17:50:07 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQkjpn03404 for ; Fri, 6 Apr 2001 17:50:07 GMT Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQ3L4TSF; Fri, 6 Apr 2001 13:50:06 -0400 Message-Id: <3.0.5.32.20010406134627.007f3840@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 06 Apr 2001 13:46:27 -0400 To: mpls@UU.NET From: Mark Duffy Subject: Use of LDP for VPNs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi, BGP-MPLS VPNs require outer LSPs to provide MPLS connectivity between PE routers. Rfc2547bis calls for supporting the establishment of these LSPs using LDP, and optionally by other means (e.g. by RSVP-TE). The rationale, I believe, is that LDP can automatically create and maintain the (potentially large) mesh of LSPs needed. This also makes sense for other VPN approaches, such as virtual routers, using MPLS as a tunneling mechanism. My question: When using LDP for setting up the outer LSPs, which type of labels should the originating PE request, those associated with an Address Prefix FEC element or those associated with a Host Address FEC element? Both seem to have different drawbacks. In the case of Host Address FEC type, it is required to have the appropriate /32 route in every intervening LSR, in order for the LSPs to get established. How undesirable is it considered to be, to distribute host routes for all the PE routers throughout the network? In the case of Address Prefix FEC type, I suppose one would select an LSP with an address prefix FEC element that is the longest match for the address of the remote PE router. But one cannot be certain that this LSP reaches all the way to that remote PE, that there are not non-MPLS links or nodes intervening! I suppose one could try to ensure that by the design of the network but that doesn't seem such a robust solution. Also if using Address Prefix FEC type, it seems highly wasteful to "turn on" LDP and request labels for every FEC in the forwarding table, if the only LSPs needed are those to interconnect PE routers for VPN support. Since it is essentially a local decision by an LSR what labels to request, would there be any problem for PE routers to request labels for only those FECs needed to reach the other PE routers they need to reach? Thanks, Mark From owner-mpls@UU.NET Fri Apr 6 14:12:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16152 for ; Fri, 6 Apr 2001 14:12:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjpo28546; Fri, 6 Apr 2001 18:11:03 GMT Received: by mail-control.mail.uu.net id QQkjpo13848 for mpls-outgoing; Fri, 6 Apr 2001 18:10:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjpo13828 for ; Fri, 6 Apr 2001 18:10:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjpo06695 for ; Fri, 6 Apr 2001 18:09:33 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjpo29666 for ; Fri, 6 Apr 2001 18:09:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA18052 for mpls@uu.net; Fri, 6 Apr 2001 14:09:31 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjpo06311 for ; Fri, 6 Apr 2001 18:05:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjpo03240 for ; Fri, 6 Apr 2001 18:04:58 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkjpo20992 for ; Fri, 6 Apr 2001 18:04:57 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA10971; Fri, 6 Apr 2001 11:05:01 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f36I4qm10144; Fri, 6 Apr 2001 11:04:53 -0700 (PDT) Message-ID: <3ACE04E9.8DCEC49F@cisco.com> Date: Fri, 06 Apr 2001 11:03:21 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy CC: mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <3.0.5.32.20010406134627.007f3840@10.1.1.249> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mark, > My question: When using LDP for setting up the outer LSPs, which type of > labels should the originating PE request, those associated with an Address > Prefix FEC element or those associated with a Host Address FEC element? Host addresses are recommended. You have already answered why by yourself ;), by saying ... > But one cannot be certain that this LSP > reaches all the way to that remote PE, ... Btw the below ... > that there are not non-MPLS links or > nodes intervening! is a problem with both types so it is highly recommended that all of your links in the network which a PE-PE packet may take do run MPLS. R. > Mark Duffy wrote: > > Hi, > > BGP-MPLS VPNs require outer LSPs to provide MPLS connectivity between PE > routers. Rfc2547bis calls for supporting the establishment of these LSPs > using LDP, and optionally by other means (e.g. by RSVP-TE). The rationale, > I believe, is that LDP can automatically create and maintain the > (potentially large) mesh of LSPs needed. This also makes sense for other > VPN approaches, such as virtual routers, using MPLS as a tunneling mechanism. > > My question: When using LDP for setting up the outer LSPs, which type of > labels should the originating PE request, those associated with an Address > Prefix FEC element or those associated with a Host Address FEC element? > Both seem to have different drawbacks. > > In the case of Host Address FEC type, it is required to have the > appropriate /32 route in every intervening LSR, in order for the LSPs to > get established. How undesirable is it considered to be, to distribute > host routes for all the PE routers throughout the network? > > In the case of Address Prefix FEC type, I suppose one would select an LSP > with an address prefix FEC element that is the longest match for the > address of the remote PE router. But one cannot be certain that this LSP > reaches all the way to that remote PE, that there are not non-MPLS links or > nodes intervening! I suppose one could try to ensure that by the design of > the network but that doesn't seem such a robust solution. > > Also if using Address Prefix FEC type, it seems highly wasteful to "turn > on" LDP and request labels for every FEC in the forwarding table, if the > only LSPs needed are those to interconnect PE routers for VPN support. > Since it is essentially a local decision by an LSR what labels to request, > would there be any problem for PE routers to request labels for only those > FECs needed to reach the other PE routers they need to reach? > > Thanks, Mark From owner-mpls@UU.NET Fri Apr 6 14:52:40 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17289 for ; Fri, 6 Apr 2001 14:52:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjpr29637; Fri, 6 Apr 2001 18:50:52 GMT Received: by mail-control.mail.uu.net id QQkjpr18288 for mpls-outgoing; Fri, 6 Apr 2001 18:50:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjpr18279 for ; Fri, 6 Apr 2001 18:50:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjpr14487 for ; Fri, 6 Apr 2001 18:49:40 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkjpr17905 for ; Fri, 6 Apr 2001 18:49:40 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 LAA13689; Fri, 6 Apr 2001 11:49:39 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA21792; Fri, 6 Apr 2001 14:49:38 -0400 (EDT) Message-Id: <200104061849.OAA21792@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Mark Duffy cc: mpls@UU.NET Subject: Re: Use of LDP for VPNs In-reply-to: Your message of Fri, 06 Apr 2001 13:46:27 -0400. <3.0.5.32.20010406134627.007f3840@10.1.1.249> 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: Fri, 06 Apr 2001 14:49:37 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk If you are concerned about RFC2547 interoperability with other vendors, my suggestion would be to use the Address Prefix FEC to get labels for the /32 addresses that correspond to the BGP next hop values for the VPN-IP routes. (This does imply having each PE insert a /32 for itself into the IGP.) Another suggestion would be to use downstream unsolicited label distribution, which means the issue is not so much requesting labels as deciding for which of the IGP routes you need to distribute labels. Distributing labels for all of the IGP routes seems like a perfectly reasonable strategy, though distributing labels only for the /32s of the PE routers is fine too. It's probably a good idea to make sure that all the routers in the network have the same policy. From owner-mpls@UU.NET Fri Apr 6 15:38:29 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18453 for ; Fri, 6 Apr 2001 15:38:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjpu27002; Fri, 6 Apr 2001 19:36:36 GMT Received: by mail-control.mail.uu.net id QQkjpu08329 for mpls-outgoing; Fri, 6 Apr 2001 19:36:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjpu08294 for ; Fri, 6 Apr 2001 19:35:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjpu04111 for ; Fri, 6 Apr 2001 19:35:20 GMT Received: from exchange.gothamnetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: Exchange.GothamNetworks.com [64.69.107.186]) id QQkjpu25358 for ; Fri, 6 Apr 2001 19:35:19 GMT Received: FROM gothamnetworks.com BY exchange.gothamnetworks.com ; Fri Apr 06 15:35:09 2001 -0400 Message-ID: <3ACE1B67.9A15394F@gothamnetworks.com> Date: Fri, 06 Apr 2001 15:39:19 -0400 From: Karthik Radakrishnan X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: raszuk@cisco.com CC: Mark Duffy , mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <3.0.5.32.20010406134627.007f3840@10.1.1.249> <3ACE04E9.8DCEC49F@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Wouldn't a prefix FEC element with a mask length of 32 work in this case. -Karthik Robert Raszuk wrote: > Hi Mark, > > > My question: When using LDP for setting up the outer LSPs, which type of > > labels should the originating PE request, those associated with an Address > > Prefix FEC element or those associated with a Host Address FEC element? > > Host addresses are recommended. You have already answered why by > yourself ;), by saying > > ... > > But one cannot be certain that this LSP > > reaches all the way to that remote PE, > ... > > Btw the below ... > > > that there are not non-MPLS links or > > nodes intervening! > > is a problem with both types so it is highly recommended that all of > your links in the network which a PE-PE packet may take do run MPLS. > > R. > > > Mark Duffy wrote: > > > > Hi, > > > > BGP-MPLS VPNs require outer LSPs to provide MPLS connectivity between PE > > routers. Rfc2547bis calls for supporting the establishment of these LSPs > > using LDP, and optionally by other means (e.g. by RSVP-TE). The rationale, > > I believe, is that LDP can automatically create and maintain the > > (potentially large) mesh of LSPs needed. This also makes sense for other > > VPN approaches, such as virtual routers, using MPLS as a tunneling mechanism. > > > > My question: When using LDP for setting up the outer LSPs, which type of > > labels should the originating PE request, those associated with an Address > > Prefix FEC element or those associated with a Host Address FEC element? > > Both seem to have different drawbacks. > > > > In the case of Host Address FEC type, it is required to have the > > appropriate /32 route in every intervening LSR, in order for the LSPs to > > get established. How undesirable is it considered to be, to distribute > > host routes for all the PE routers throughout the network? > > > > In the case of Address Prefix FEC type, I suppose one would select an LSP > > with an address prefix FEC element that is the longest match for the > > address of the remote PE router. But one cannot be certain that this LSP > > reaches all the way to that remote PE, that there are not non-MPLS links or > > nodes intervening! I suppose one could try to ensure that by the design of > > the network but that doesn't seem such a robust solution. > > > > Also if using Address Prefix FEC type, it seems highly wasteful to "turn > > on" LDP and request labels for every FEC in the forwarding table, if the > > only LSPs needed are those to interconnect PE routers for VPN support. > > Since it is essentially a local decision by an LSR what labels to request, > > would there be any problem for PE routers to request labels for only those > > FECs needed to reach the other PE routers they need to reach? > > > > Thanks, Mark From owner-mpls@UU.NET Fri Apr 6 15:46:19 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18720 for ; Fri, 6 Apr 2001 15:46:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjpu07222; Fri, 6 Apr 2001 19:44:29 GMT Received: by mail-control.mail.uu.net id QQkjpu08876 for mpls-outgoing; Fri, 6 Apr 2001 19:43:52 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjpu08850 for ; Fri, 6 Apr 2001 19:43:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjpu20309 for ; Fri, 6 Apr 2001 19:40:18 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjpu01655 for ; Fri, 6 Apr 2001 19:40:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA25711 for mpls@uu.net; Fri, 6 Apr 2001 15:40:16 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjpu08564 for ; Fri, 6 Apr 2001 19:39:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjpu11626 for ; Fri, 6 Apr 2001 19:38:05 GMT Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQkjpu29152 for ; Fri, 6 Apr 2001 19:38:05 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21) id <2GWQRXKC>; Fri, 6 Apr 2001 15:33:16 -0400 Message-ID: <87009604743AD411B1F600508BA0F9597D8710@XOVER.dedham.mindspeed.com> From: "Herbst, Bill" To: "'Mark Duffy'" , mpls@UU.NET Subject: RE: Use of LDP for VPNs Date: Fri, 6 Apr 2001 15:33:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Mark, It seems to me that in section 2.1 of RFC 3036 such use of a Host FEC element is explicitly prohibited - - A packet which does not match a particular Host Address FEC element may not be sent on the corresponding LSP, even if the Host Address FEC element identifies the packet's egress router. You could use a /32 Prefix FEC element of the BGP next hop for that VPN-IP address. Bill > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Friday, April 06, 2001 1:46 PM > To: mpls@UU.NET > Subject: Use of LDP for VPNs > > > Hi, > > BGP-MPLS VPNs require outer LSPs to provide MPLS connectivity > between PE > routers. Rfc2547bis calls for supporting the establishment > of these LSPs > using LDP, and optionally by other means (e.g. by RSVP-TE). > The rationale, > I believe, is that LDP can automatically create and maintain the > (potentially large) mesh of LSPs needed. This also makes > sense for other > VPN approaches, such as virtual routers, using MPLS as a > tunneling mechanism. > > My question: When using LDP for setting up the outer LSPs, > which type of > labels should the originating PE request, those associated > with an Address > Prefix FEC element or those associated with a Host Address > FEC element? > Both seem to have different drawbacks. > > In the case of Host Address FEC type, it is required to have the > appropriate /32 route in every intervening LSR, in order for > the LSPs to > get established. How undesirable is it considered to be, to > distribute > host routes for all the PE routers throughout the network? > > In the case of Address Prefix FEC type, I suppose one would > select an LSP > with an address prefix FEC element that is the longest match for the > address of the remote PE router. But one cannot be certain > that this LSP > reaches all the way to that remote PE, that there are not > non-MPLS links or > nodes intervening! I suppose one could try to ensure that by > the design of > the network but that doesn't seem such a robust solution. > > Also if using Address Prefix FEC type, it seems highly > wasteful to "turn > on" LDP and request labels for every FEC in the forwarding > table, if the > only LSPs needed are those to interconnect PE routers for VPN support. > Since it is essentially a local decision by an LSR what > labels to request, > would there be any problem for PE routers to request labels > for only those > FECs needed to reach the other PE routers they need to reach? > > Thanks, Mark > From owner-mpls@UU.NET Fri Apr 6 16:15:37 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19330 for ; Fri, 6 Apr 2001 16:15:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjpw14385; Fri, 6 Apr 2001 20:13:44 GMT Received: by mail-control.mail.uu.net id QQkjpw27801 for mpls-outgoing; Fri, 6 Apr 2001 20:12:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjpw27213 for ; Fri, 6 Apr 2001 20:12:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjpw20587 for ; Fri, 6 Apr 2001 20:11:29 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkjpw04443 for ; Fri, 6 Apr 2001 20:11:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA28534 for mpls@uu.net; Fri, 6 Apr 2001 16:11:28 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjpw20356 for ; Fri, 6 Apr 2001 20:07:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjpw19130 for ; Fri, 6 Apr 2001 20:06:34 GMT Received: from sj-msg-core-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10]) id QQkjpw27763 for ; Fri, 6 Apr 2001 20:06:33 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01633; Fri, 6 Apr 2001 13:06:25 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f36Jxqp21758; Fri, 6 Apr 2001 12:59:52 -0700 (PDT) Message-ID: <3ACE1FDB.6203C854@cisco.com> Date: Fri, 06 Apr 2001 12:58:19 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Karthik Radakrishnan CC: Mark Duffy , mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <3.0.5.32.20010406134627.007f3840@10.1.1.249> <3ACE04E9.8DCEC49F@cisco.com> <3ACE1B67.9A15394F@gothamnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yes sure. The only reason I called it host FEC was that for me host FEC and prefix FEC of /32 are the same. (Yes I know for some reasons the rfc does not define it that way). Maybe some hardware could distinguish those two cases (host FEC and prefix FEC of /32 and make some use of this) but I don't know of any. R. > Karthik Radakrishnan wrote: > > Wouldn't a prefix FEC element with a mask length of 32 work in this case. > > -Karthik > > Robert Raszuk wrote: > > > Hi Mark, > > > > > My question: When using LDP for setting up the outer LSPs, which type of > > > labels should the originating PE request, those associated with an Address > > > Prefix FEC element or those associated with a Host Address FEC element? > > > > Host addresses are recommended. You have already answered why by > > yourself ;), by saying > > > > ... > > > But one cannot be certain that this LSP > > > reaches all the way to that remote PE, > > ... > > > > Btw the below ... > > > > > that there are not non-MPLS links or > > > nodes intervening! > > > > is a problem with both types so it is highly recommended that all of > > your links in the network which a PE-PE packet may take do run MPLS. > > > > R. > > > > > Mark Duffy wrote: > > > > > > Hi, > > > > > > BGP-MPLS VPNs require outer LSPs to provide MPLS connectivity between PE > > > routers. Rfc2547bis calls for supporting the establishment of these LSPs > > > using LDP, and optionally by other means (e.g. by RSVP-TE). The rationale, > > > I believe, is that LDP can automatically create and maintain the > > > (potentially large) mesh of LSPs needed. This also makes sense for other > > > VPN approaches, such as virtual routers, using MPLS as a tunneling mechanism. > > > > > > My question: When using LDP for setting up the outer LSPs, which type of > > > labels should the originating PE request, those associated with an Address > > > Prefix FEC element or those associated with a Host Address FEC element? > > > Both seem to have different drawbacks. > > > > > > In the case of Host Address FEC type, it is required to have the > > > appropriate /32 route in every intervening LSR, in order for the LSPs to > > > get established. How undesirable is it considered to be, to distribute > > > host routes for all the PE routers throughout the network? > > > > > > In the case of Address Prefix FEC type, I suppose one would select an LSP > > > with an address prefix FEC element that is the longest match for the > > > address of the remote PE router. But one cannot be certain that this LSP > > > reaches all the way to that remote PE, that there are not non-MPLS links or > > > nodes intervening! I suppose one could try to ensure that by the design of > > > the network but that doesn't seem such a robust solution. > > > > > > Also if using Address Prefix FEC type, it seems highly wasteful to "turn > > > on" LDP and request labels for every FEC in the forwarding table, if the > > > only LSPs needed are those to interconnect PE routers for VPN support. > > > Since it is essentially a local decision by an LSR what labels to request, > > > would there be any problem for PE routers to request labels for only those > > > FECs needed to reach the other PE routers they need to reach? > > > > > > Thanks, Mark From owner-mpls@UU.NET Fri Apr 6 16:29:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19620 for ; Fri, 6 Apr 2001 16:29:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjpx25266; Fri, 6 Apr 2001 20:27:37 GMT Received: by mail-control.mail.uu.net id QQkjpx02030 for mpls-outgoing; Fri, 6 Apr 2001 20:26:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjpx02006 for ; Fri, 6 Apr 2001 20:26:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjpx29804 for ; Fri, 6 Apr 2001 20:24:32 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQkjpx28180 for ; Fri, 6 Apr 2001 20:24:32 GMT Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQ3L4T9Z; Fri, 6 Apr 2001 16:24:31 -0400 Message-Id: <3.0.5.32.20010406162005.0081bd20@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 06 Apr 2001 16:20:05 -0400 To: "Herbst, Bill" , mpls@UU.NET From: Mark Duffy Subject: RE: Use of LDP for VPNs In-Reply-To: <87009604743AD411B1F600508BA0F9597D8710@XOVER.dedham.mindsp eed.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Bill, Your comment raises another question which I have been wondering about. RFC 3036 sect. 2.1 gives very specific rules for what *packets may be sent* on a particular LSP. But it doesn't say anything about what higher-level *LSPs may be stacked* on the LSP. Presumably one stacks higher level LSPs whose next hop matches a FEC element associated with the outer LSP. If one applied the rules of section 2.1 to the stacking, it would (for example) require that an outer LSP with a Host Address FEC be chosen in preference to any LSP with an Address Prefix FEC. Was it the intent of the authors that the same rules for assigning packets to an LSP also be used for assigning higher level LSPs into the LSP? If the same rules apply then I would agree with you; it appears that the Host Address FEC LSP should not be used to stack any higher level LSPs, except for other Host Address FEC LSPs with the same Host Address! This would be consistent with what I see in the mailing list archive (LDP: need to eliminate useless FEC type, Aug 98) which seems to conclude that LSPs bound to a Host Address FEC should only be used for control traffic addressed to the LSR itself. If the rules of sect. 2.1 do not apply, then I see no reason why this would necessarily be disallowed. All the same, I'm getting the distinct impression that the Host Address FEC type is probably not widely used. -Thanks, Mark At 03:33 PM 4/6/01 -0400, Herbst, Bill wrote: >Mark, > >It seems to me that in section 2.1 of RFC 3036 such use of a Host FEC >element >is explicitly prohibited - > > - A packet which does not match a particular Host Address FEC > element may not be sent on the corresponding LSP, even if the > Host Address FEC element identifies the packet's egress router. > >You could use a /32 Prefix FEC element of the BGP next hop for that VPN-IP >address. > >Bill > > >> -----Original Message----- >> From: Mark Duffy [mailto:mduffy@quarrytech.com] >> Sent: Friday, April 06, 2001 1:46 PM >> To: mpls@UU.NET >> Subject: Use of LDP for VPNs >> >> >> Hi, >> >> BGP-MPLS VPNs require outer LSPs to provide MPLS connectivity >> between PE >> routers. Rfc2547bis calls for supporting the establishment >> of these LSPs >> using LDP, and optionally by other means (e.g. by RSVP-TE). >> The rationale, >> I believe, is that LDP can automatically create and maintain the >> (potentially large) mesh of LSPs needed. This also makes >> sense for other >> VPN approaches, such as virtual routers, using MPLS as a >> tunneling mechanism. >> >> My question: When using LDP for setting up the outer LSPs, >> which type of >> labels should the originating PE request, those associated >> with an Address >> Prefix FEC element or those associated with a Host Address >> FEC element? >> Both seem to have different drawbacks. >> >> In the case of Host Address FEC type, it is required to have the >> appropriate /32 route in every intervening LSR, in order for >> the LSPs to >> get established. How undesirable is it considered to be, to >> distribute >> host routes for all the PE routers throughout the network? >> >> In the case of Address Prefix FEC type, I suppose one would >> select an LSP >> with an address prefix FEC element that is the longest match for the >> address of the remote PE router. But one cannot be certain >> that this LSP >> reaches all the way to that remote PE, that there are not >> non-MPLS links or >> nodes intervening! I suppose one could try to ensure that by >> the design of >> the network but that doesn't seem such a robust solution. >> >> Also if using Address Prefix FEC type, it seems highly >> wasteful to "turn >> on" LDP and request labels for every FEC in the forwarding >> table, if the >> only LSPs needed are those to interconnect PE routers for VPN support. >> Since it is essentially a local decision by an LSR what >> labels to request, >> would there be any problem for PE routers to request labels >> for only those >> FECs needed to reach the other PE routers they need to reach? >> >> Thanks, Mark >> > From owner-mpls@UU.NET Sat Apr 7 04:34:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12174 for ; Sat, 7 Apr 2001 04:34:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjpf27428; Fri, 6 Apr 2001 15:53:24 GMT Received: by mail-control.mail.uu.net id QQkjpf10494 for mpls-outgoing; Fri, 6 Apr 2001 15:52:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjpf10480 for ; Fri, 6 Apr 2001 15:52:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjpf25870 for ; Fri, 6 Apr 2001 15:49:46 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkjpf01310 for ; Fri, 6 Apr 2001 15:49:46 GMT Received: from cclmsent02.lon.bt.com by gollum (local) with ESMTP; Fri, 6 Apr 2001 16:21:26 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Fri, 6 Apr 2001 16:19:38 +0100 Message-ID: To: zappacor@TELEFONICA.COM.AR, mlazer@att.com, raszuk@cisco.com Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels Date: Fri, 6 Apr 2001 16:19:34 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Can I check please Monica/Rolando.....I assume the issue is *not* voice per se (ie not a function of the application) but perhaps something to do with *some* signalling protocol? In which case the ideal would be to make the signalling protocol more robust....but I suspect this will not be possible. neil > -----Original Message----- > From: Zappacosta Rolando Jorge [mailto:zappacor@TELEFONICA.COM.AR] > Sent: 06 April 2001 13:58 > To: 'Lazer, Monica A, NNAD'; 'neil.2.harrison@bt.com'; > raszuk@cisco.com > Cc: mpls@UU.NET; ccamp@ops.ietf.org > Subject: RE: Last Call on RSVP Label Allocation for Backup Tunnels > > > I agree, this is the same everywhere. I've been looking at > these mails with > interest because this may be an issue in the NGNs backbones. > Take also into account that the disruption may be not enough > to drop calls > but to cause a voice quality degradation incompatible with > the desired one, > so the less the down time, the happier the service providers will be. > > > > -----Mensaje original----- > > De: Lazer, Monica A, NNAD [SMTP:mlazer@att.com] > > Enviado el: Viernes 6 de Abril de 2001 09:02 > > Para: 'neil.2.harrison@bt.com'; raszuk@cisco.com > > CC: mpls@UU.NET; ccamp@ops.ietf.org > > Asunto: RE: Last Call on RSVP Label Allocation for > Backup Tunnels > > > > Voice switches will drop the connections after 2.5 seconds. > A large number > > of dropped calls will cause FCC reportable events, which is > something that > > US carriers need to avoid. So restoration within this time > frame is needed > > for support of trunks carrying voice traffic. > > > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning From owner-mpls@UU.NET Sat Apr 7 05:36:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12378 for ; Sat, 7 Apr 2001 05:36:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjry17369; Sat, 7 Apr 2001 09:35:24 GMT Received: by mail-control.mail.uu.net id QQkjry04982 for mpls-outgoing; Sat, 7 Apr 2001 09:34:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjry04961 for ; Sat, 7 Apr 2001 09:34:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjry29042 for ; Sat, 7 Apr 2001 09:34:12 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkjry26513 for ; Sat, 7 Apr 2001 09:34:11 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f379WSB01415 for ; Sat, 7 Apr 2001 02:32:29 -0700 (PDT) Reply-To: From: "Anil Gunturu" To: Subject: LSP intiator Date: Sat, 7 Apr 2001 02:32:38 -0700 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Who initates the LSP setup in case of Ordered Downstream-on-Demand mode of LDP operation. RFC3031 indicates that for Ordered control LSP setup may be initiated from either the ingress or the Egress LER. But, if the distribution mode is Ordered Downstream-on-Demand can the LSP setup be initated from Egress? Thanks, -Anil Anil Gunturu, Software Engineer Ericsson, Inc phone: (805) 562 6431 Datacom & IP Services email: anilg@acc.am.ericsson.se 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Sat Apr 7 10:52:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14849 for ; Sat, 7 Apr 2001 10:52:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjst27233; Sat, 7 Apr 2001 14:51:05 GMT Received: by mail-control.mail.uu.net id QQkjst19323 for mpls-outgoing; Sat, 7 Apr 2001 14:50:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkjst19318 for ; Sat, 7 Apr 2001 14:50:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjst16629 for ; Sat, 7 Apr 2001 14:49:56 GMT From: djiang1@lucent.com Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQkjst10905 for ; Sat, 7 Apr 2001 14:49:56 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA00013 for ; Sat, 7 Apr 2001 10:49:54 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA29995; Sat, 7 Apr 2001 10:49:53 -0400 (EDT) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA13949; Sat, 7 Apr 2001 10:49:52 -0400 (EDT) Subject: Re: LSP intiator To: Cc: mpls@UU.NET Date: Sat, 7 Apr 2001 10:44:48 -0400 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 04/07/2001 10:44:49 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Anil, For ordered control LSP setup, the initiation can be from either the ingress or the egress LER. However, for ordered downstream-on-demand LSP setup, the initiation has to be initiated by the ingress LER, because the "on-demand" is the demand from the upstream. Regards, Jane D. Jiang "Anil Gunturu" @UU.NET on 04/07/2001 05:32:38 AM Please respond to Sent by: owner-mpls@UU.NET To: cc: Subject: LSP intiator Hi, Who initates the LSP setup in case of Ordered Downstream-on-Demand mode of LDP operation. RFC3031 indicates that for Ordered control LSP setup may be initiated from either the ingress or the Egress LER. But, if the distribution mode is Ordered Downstream-on-Demand can the LSP setup be initated from Egress? Thanks, -Anil Anil Gunturu, Software Engineer Ericsson, Inc phone: (805) 562 6431 Datacom & IP Services email: anilg@acc.am.ericsson.se 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Sat Apr 7 13:19:41 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16589 for ; Sat, 7 Apr 2001 13:19:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjtd05420; Sat, 7 Apr 2001 17:19:14 GMT Received: by mail-control.mail.uu.net id QQkjtd16474 for mpls-outgoing; Sat, 7 Apr 2001 17:18:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjtd16469 for ; Sat, 7 Apr 2001 17:18:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjtd07084 for ; Sat, 7 Apr 2001 17:17:31 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQkjtd03631 for ; Sat, 7 Apr 2001 17:17:30 GMT Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQ3L44S3; Sat, 7 Apr 2001 13:17:29 -0400 Message-Id: <3.0.5.32.20010407123425.0082d550@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 07 Apr 2001 12:34:25 -0400 To: mpls@UU.NET From: Mark Duffy Subject: Re: Use of LDP for VPNs In-Reply-To: <3.0.5.32.20010406134627.007f3840@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Thank you for the responses several of you have sent on this question. After reading your comments, and rereading the various RFCs and I-D's, I have arrived at a more fundamental issue. I had been under the mistaken impression that an LSP set up using LDP and bound to a Host Address type FEC would fail to be established if it did not reach all the way to the specified host (LSR). I now understand that these behave just like LSPs bound to an Address Prefix type FEC, which is to say that the ingress LSR does not have knowledge of how far the LSP extends. This type of behavior seems problematic to me when using LSPs set up by LDP as tunnels in which to stack higher level LSPs. Since the labels of the higher level LSPs are meaningless except at the LSRs that distributed them, if the outer LSPs happen not to reach to the next hop of the inner LSPs there will not be connectivity of the inner LSP. One could try to prevent this problem would from arising by making sure that MPLS is deployed throughout the entire network connecting the end points of the higher level LSPs (e.g. PE devices providing VPN services) but that does not strike me as providing a robust and high confidence solution. Using TE tunnels set up by RSVP-TE or CR-LDP would avoid the problem, but that seems to present a different problem of ensuring that all the required PE-PE tunnels are always present (as previously discussed on this list). -Mark From owner-mpls@UU.NET Sat Apr 7 15:36:45 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17531 for ; Sat, 7 Apr 2001 15:36:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjtm13514; Sat, 7 Apr 2001 19:35:50 GMT Received: by mail-control.mail.uu.net id QQkjtm28616 for mpls-outgoing; Sat, 7 Apr 2001 19:35:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjtm28611 for ; Sat, 7 Apr 2001 19:35:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjtm11218 for ; Sat, 7 Apr 2001 19:33:53 GMT Received: from interceptor.mahinetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: 216-174-224-194.atgi.net [216.174.224.194]) id QQkjtm11299 for ; Sat, 7 Apr 2001 19:33:52 GMT Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Sat, 07 Apr 2001 11:38:44 -0700 (Pacific Daylight Time) Received: by main.mahinetworks.com with Internet Mail Service (5.5.2650.21) id ; Sat, 7 Apr 2001 12:35:23 -0700 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C9921379@main.mahinetworks.com> From: Jayaram Beladakere To: "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs Date: Sat, 7 Apr 2001 12:35:14 -0700 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 Shahram, Thanks for this clarification. I have a follow-up question on this topic. Suppose that the preconfigured EXP<-->PHB table has not been configured by the network administrator; thus, all EXP values map to the Default PHB. If an E-LSP tunnel is now set up with no Diffserv Context, how should the LSR encode the outgoing PHBs? Obviously, the E-LSP tunnel would only support Default PHB. But, there are eight EXP field values that map to that PHB. Which value shall be used for outgoing EXP field? Otherwise, is it mandatory to specify a Diffserv Context for an E-LSP tunnel? Regards, Jayaram -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, March 28, 2001 8:21 AM To: 'Jayaram Beladakere'; 'mpls@uu.net' Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs Hi Jayaram, The intention of configured E-LSPs is to have the MPLS+Diffserv network behave the same as a Diffserv-only network. Since RFC-2474 section 3 says: " Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior (see Sec. 4), and their codepoints should not be changed. Such packets MUST NOT cause the network node to malfunction. " So the answer to you question is that the EXP should be left unchanged in the normal swap operation. It is however, possible to push another label and have either non-configured, configured or even signaled E-LSP for the new LSP (which we call tunnel-LSP). In that case depending on the type of the tunnel (Uniform or pipe), the top label could have its EXP set to the same EXP, or to the Default EXP or something else. In case the tunnel-LSP is a uniform tunnel that is a non-configured (and non-signaled) E-LSP, then the same behavior as explained in the above quote from RFC-2474 is the correct behavior (i.e., setting the EXP of the pushed label to the same EXP as the incoming label). Yours, -Shahram > -----Original Message----- > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > Sent: Tuesday, March 27, 2001 2:06 PM > To: 'mpls@uu.net' > Subject: Preconfigured EXP<-->PHB mapping for E-LSPs > > > The following is from "MPLS Support of Differentiated Services" > (draft-ietf-mpls-diff-ext-08.txt). > > 3.2.1 Preconfigured EXP<-->PHB mapping > .... > In case, the preconfigured EXP<-->PHB mapping has not actually been > configured by the Network Administrator, the LSR should use a > default preconfigured EXP<-->PHB mapping which maps all EXP values > to the Default PHB. > > In the above case, the LSR provides Default PHB treatment to > all labeled > packets (belonging to LSPs with preconfigured EXP<-->PHB > mapping). What > shall be the value of the outgoing EXP field for such labeled > packets, both > with label-swap and label-push operations at the LSR? In > particular, shall > the outgoing EXP match incoming EXP, or shall it be '000'? Is there a > difference if the label operation is swap rather than push? > > Regards, > Jayaram Beladakere > Mahi Networks, Inc. > From owner-mpls@UU.NET Sat Apr 7 21:36:40 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20001 for ; Sat, 7 Apr 2001 21:36:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjlv02405; Thu, 5 Apr 2001 17:48:59 GMT Received: by mail-control.mail.uu.net id QQkjlv16870 for mpls-outgoing; Thu, 5 Apr 2001 17:48:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkjlv16820 for ; Thu, 5 Apr 2001 17:47:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjlv07992 for ; Thu, 5 Apr 2001 17:47:12 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkjlv29439 for ; Thu, 5 Apr 2001 17:47:12 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 2104394006; Thu, 5 Apr 2001 13:47:08 -0400 (EDT) Message-ID: <3ACCAF9C.13A91D02@sandburst.com> Date: Thu, 05 Apr 2001 13:47:08 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com Cc: George Swallow , Adrian Farrel , pjb@dataconnection.com, philipma@nortelnetworks.com, mpls@UU.NET Subject: Re: Last Call on LDP Fault Tollerance References: <200104051651.MAA02276@workhorse.fictitious.org> Content-Type: multipart/alternative; boundary="------------8736AC5438D9FC9A3DD5339A" Sender: owner-mpls@UU.NET Precedence: bulk --------------8736AC5438D9FC9A3DD5339A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Curtis, Thanks for the clarifications. You wrote: > In message <3ACBD64D.FF5CFBCA@sandburst.com>, Eric Gray writes: > > > > > If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went down, > > > a topology change at D-E (D-E went down) may make the path A-B-C a > > > poor choice. C may have decided that the best path is by way of A > > > since D-E is unavailable and is dutifully trying to inform B of the > > > situation with a Label Withdraw, who will take note of it and inform A > > > in due time after its finished rebooting. > > > > Since you didn't draw a picture, I'll try to unscramble this > > alphabet soup. > > > > My guess is the picture is supposed to look like this: > > > > B > > /|\ > > / | \ > > --- A | D --- E --- > > |\ | / | > > | \|/ | > > | C Z > > | | > > W --- X --- Y > > > > Is that the case? > > My description was off. Should be: > > If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went > down, a topology change at D-E (D-E went down) may make the path > A-B-D a poor choice. D may have decided that the best path is by > ^ ^ > way of A since D-E is unavailable and is dutifully trying to inform > B of the situation with a Label Withdraw, who will take note of it > and inform A in due time after its finished rebooting. > > Note the two places where C is changed to D above. This is the same > picture you have without the B-C link. > > I answered my own question. > > In RFC3036 "A.1.7. Detect Change in FEC Next Hop" the "Received Label > Mapping" event generated in NH.12 and Note 2 cover this case as long > as the next hop changed. > > If we look at a similar example where C were not there and there was a > B-E link (or B-...-E path) that was higher cost than B-D-E, then A > would not see a next hop change. Nor would it need to. Now you have proposed the following picture: B -------. / \ | / \ | --- A D --- E --- |\ / | | \ / | | C Z | | W --- X --- Y If path A-B-E is more expensive than path A-B-D-E, but less expensive than A-W-X-Y-Z-E, then A will not see a route change and will continue to forward to B. So what? B has the perfectly legitimate path via E (useful if B - for example - was using liberal retention). If B cannot, in fact, forward packets on the link B-E, then it should not include this link in its advertisements (a fact that I had pointed out to the authors of the MPLS Framework document 2 years ago). In any case, this is not persistent in any serious sense in the redundant control plane case. In that case, the switch over is in hundreds of milliseconds at worst - making the recommended 5 second timeout roughly equivalent to setting your watch by the progression of lunar phases. > > > If we want to prevent a persistent loop, the very minimum would be for > A to reject consideration of any FEC through B for which the next hop > from B has changed because B has not reflected the change. There is > no such procedure in draft-ietf-mpls-ldp-ft-01.txt. > > > A simpler approach was taken in the OSPF WG. I'm happy for them. However, they are solving a different problem. > > Adjacencies to the > router that was down were declared down (the IGP Grace timer was > prematurely expired) when there was a change in the topology. This is OSPF routers dealing with the fact that an OSPF router that is known to be unable to process OSPF transactions is now known to have an invalid topological picture. The behavior you describe makes sense in that context. You had suggested that LDP should adopt a similar (or at least related) approach. I disagree. In the LDP case, the co-resident routing function is _not_ unable to process routing transactions. Therfore, there is little justification in hamming up the already reasonably well-defined interactions between LDP and the still-functioning routing control plane by adding the behavior proposed for OSPF. > > > By virtue of the IGP Grace timer expiring LDP would see a next hop > change so this case too is covered as long as the IGP prematurely > expires its Grace timer. > > This would mean that LDP does not also have to prematurely expires its > timer, though it would seem that there would be no difference in > behaviour since all traffic is already diverted away by virtue of all > IGP next hops being changed to go elsewhere. > > It would only be if the IGP did not expire its Grace timer that there > would be a problem in LDP (and the IGP and therefore things like IBGP > would be even worse off, so the IGP would clearly need to do > something). > > Whether the LDP timer is prematurely expired does not effect whether > LDP routes are diverted away from the downed router. If the timer is > prematurely expired, it just changes the behavior during recovery, > only impacting how soon FEC are sent through that router again. Agreed. > > > Either keeping the text as is or recommending prematurely expiring the > timer both seem to be fine options. Since it is already last call and > there is no urgency I can see good reason not to make this change. > Thanks for the time taken for this discussion. You're welcome. > > > Curtis -- Eric Gray --------------8736AC5438D9FC9A3DD5339A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Curtis,

    Thanks for the clarifications.

You wrote:

In message <3ACBD64D.FF5CFBCA@sandburst.com>, Eric Gray writes:
>
> > If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went down,
> > a topology change at D-E (D-E went down) may make the path A-B-C a
> > poor choice.  C may have decided that the best path is by way of A
> > since D-E is unavailable and is dutifully trying to inform B of the
> > situation with a Label Withdraw, who will take note of it and inform A
> > in due time after its finished rebooting.
>
> Since you didn't draw a picture, I'll try to unscramble this
> alphabet soup.
>
> My guess is the picture is supposed to look like this:
>
>         B
>        /|\
>       / | \
>  --- A  |  D --- E ---
>      |\ | /      |
>      | \|/       |
>      |  C        Z
>      |           |
>      W --- X --- Y
>
> Is that the case?

My description was off.  Should be:

  If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went
  down, a topology change at D-E (D-E went down) may make the path
  A-B-D a poor choice.  D may have decided that the best path is by
      ^                 ^
  way of A since D-E is unavailable and is dutifully trying to inform
  B of the situation with a Label Withdraw, who will take note of it
  and inform A in due time after its finished rebooting.

Note the two places where C is changed to D above.  This is the same
picture you have without the B-C link.

I answered my own question.

In RFC3036 "A.1.7. Detect Change in FEC Next Hop" the "Received Label
Mapping" event generated in NH.12 and Note 2 cover this case as long
as the next hop changed.

If we look at a similar example where C were not there and there was a
B-E link (or B-...-E path) that was higher cost than B-D-E, then A
would not see a next hop change.

Nor would it need to.  Now you have proposed the following
picture:

         B -------.
        / \       |
       /   \      |
  --- A     D --- E ---
      |\   /      |
      | \ /       |
      |  C        Z
      |           |
      W --- X --- Y

If path A-B-E is more expensive than path A-B-D-E,
but less expensive than A-W-X-Y-Z-E, then A will
not see a route change and will continue to forward
to B.  So what?  B has the perfectly legitimate
path via E (useful if B - for example - was using
liberal retention).  If B cannot, in fact, forward
packets on the link B-E, then it should not include
this link in its advertisements (a fact that I had
pointed out to the authors of the MPLS Framework
document 2 years ago).

In any case, this is not persistent in any serious
sense in the redundant control plane case.  In that
case, the switch over is in hundreds of milliseconds
at worst - making the recommended 5 second timeout
roughly equivalent to setting your watch by the
progression of lunar phases.

 

If we want to prevent a persistent loop, the very minimum would be for
A to reject consideration of any FEC through B for which the next hop
from B has changed because B has not reflected the change.  There is
no such procedure in draft-ietf-mpls-ldp-ft-01.txt.

 

A simpler approach was taken in the OSPF WG.

I'm happy for them.  However, they are solving a different
problem.

Adjacencies to the
router that was down were declared down (the IGP Grace timer was
prematurely expired) when there was a change in the topology.
This is OSPF routers dealing with the fact that an OSPF
router that is known to be unable to process OSPF transactions
is now known to have an invalid topological picture.  The behavior
you describe makes sense in that context.

You had suggested that LDP should adopt a similar (or at least
related) approach.  I disagree.  In the LDP case, the co-resident
routing function is _not_ unable to process <whatever> routing
transactions.  Therfore, there is little justification in hamming
up the already reasonably well-defined interactions between
LDP and the still-functioning routing control plane by adding
the behavior proposed for OSPF.

 

By virtue of the IGP Grace timer expiring LDP would see a next hop
change so this case too is covered as long as the IGP prematurely
expires its Grace timer.

This would mean that LDP does not also have to prematurely expires its
timer, though it would seem that there would be no difference in
behaviour since all traffic is already diverted away by virtue of all
IGP next hops being changed to go elsewhere.

It would only be if the IGP did not expire its Grace timer that there
would be a problem in LDP (and the IGP and therefore things like IBGP
would be even worse off, so the IGP would clearly need to do
something).

Whether the LDP timer is prematurely expired does not effect whether
LDP routes are diverted away from the downed router.  If the timer is
prematurely expired, it just changes the behavior during recovery,
only impacting how soon FEC are sent through that router again.

Agreed.
 

Either keeping the text as is or recommending prematurely expiring the
timer both seem to be fine options.  Since it is already last call and
there is no urgency I can see good reason not to make this change.
Thanks for the time taken for this discussion.

You're welcome.
 

Curtis


--
Eric Gray --------------8736AC5438D9FC9A3DD5339A-- From owner-mpls@UU.NET Sun Apr 8 22:50:35 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15690 for ; Sun, 8 Apr 2001 22:50:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjyh08245; Mon, 9 Apr 2001 02:48:24 GMT Received: by mail-control.mail.uu.net id QQkjyh01730 for mpls-outgoing; Mon, 9 Apr 2001 02:47:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjyh01715 for ; Mon, 9 Apr 2001 02:47:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjyh19142 for ; Mon, 9 Apr 2001 02:46:19 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjyh11658 for ; Mon, 9 Apr 2001 02:46:18 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA00719; Sun, 8 Apr 2001 22:36:33 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104090236.WAA00719@workhorse.fictitious.org> To: "Lazer, Monica A, NNAD" cc: "'neil.2.harrison@bt.com'" , raszuk@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org Reply-To: curtis@avici.com Subject: restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels) In-reply-to: Your message of "Fri, 06 Apr 2001 08:01:35 EDT." <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com> Date: Sun, 08 Apr 2001 22:36:33 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com>, "L azer, Monica A, NNAD" writes: > Voice switches will drop the connections after 2.5 seconds. A large number > of dropped calls will cause FCC reportable events, which is something that > US carriers need to avoid. So restoration within this time frame is needed > for support of trunks carrying voice traffic. > > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com Monica, We're off topic, so I changed the subject. Thanks for providing the 2.5 second figure. I've heard carrier transport people grumble about SONET equipment they'd be please to get rid of that will shut down even when used as linear SONET with no protect path and as a result would require <100msec restoration. Since there is enough of this SONET gear, the carriers can't really get rid of it although it will probably disappear over time and so they will make fast restoration a requirement of people they buy from. To be safe, the request for <50msec has been made. If you are not blessed with such equipment or you are able to work around it when doing VoIP, then you are among the fortunate. Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with such that I could say with confidence that it could not be configured to hold on longer or to not shut down at all if there was no protect. OTOH there are those who (claim to) want to configure SONET on some links but not on others and don't want a fast restoration. They want to be assured that restoration will occur only after it is safe to assume that SONET restoration is not available. Curtis From owner-mpls@UU.NET Sun Apr 8 22:55:22 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15715 for ; Sun, 8 Apr 2001 22:55:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjyh17508; Mon, 9 Apr 2001 02:54:36 GMT Received: by mail-control.mail.uu.net id QQkjyh02104 for mpls-outgoing; Mon, 9 Apr 2001 02:54:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjyh02099 for ; Mon, 9 Apr 2001 02:54:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjyh05288 for ; Mon, 9 Apr 2001 02:53:53 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkjyh16039 for ; Mon, 9 Apr 2001 02:53:51 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA00773; Sun, 8 Apr 2001 22:51:06 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104090251.WAA00773@workhorse.fictitious.org> To: Mark Duffy cc: "Herbst, Bill" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Use of LDP for VPNs In-reply-to: Your message of "Fri, 06 Apr 2001 16:20:05 EDT." <3.0.5.32.20010406162005.0081bd20@10.1.1.249> Date: Sun, 08 Apr 2001 22:51:06 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3.0.5.32.20010406162005.0081bd20@10.1.1.249>, Mark Duffy writes: > Hi Bill, > > Your comment raises another question which I have been wondering about. > RFC 3036 sect. 2.1 gives very specific rules for what *packets may be sent* > on a particular LSP. But it doesn't say anything about what higher-level > *LSPs may be stacked* on the LSP. > > Presumably one stacks higher level LSPs whose next hop matches a FEC > element associated with the outer LSP. If one applied the rules of section > 2.1 to the stacking, it would (for example) require that an outer LSP with > a Host Address FEC be chosen in preference to any LSP with an Address > Prefix FEC. For most usage of MPLS, the notion of FEC is a broken one. In RSVP/TE, there is no FEC signalled which is a good thing. For a hierarchical tunnel, you can carry any traffic that needs to pass that way. A specific case would be a BGP VPN tunnel directly inside a TE tunnel (which elsewhere could go directly inside another TE tunnel). If an outer tunnel will only accept inner tunnels with a specific L3PID, then we set that L3PID on the outer tunnel. If it is allowed to carry any L3PID, then the MPLS L3PID is used. If the MPLS L3PID is used, this also indicates that there must be another label underneath since there is no way to determine how to interpret the payload. Curtis From owner-mpls@UU.NET Mon Apr 9 03:56:02 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01484 for ; Mon, 9 Apr 2001 03:56:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjzb15489; Mon, 9 Apr 2001 07:54:26 GMT Received: by mail-control.mail.uu.net id QQkjzb15701 for mpls-outgoing; Mon, 9 Apr 2001 07:53:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjzb15692 for ; Mon, 9 Apr 2001 07:53:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkjzb08886 for ; Mon, 9 Apr 2001 07:53:02 GMT Received: from beamer.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQkjzb18609 for ; Mon, 9 Apr 2001 07:52:58 GMT Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA16112; Mon, 9 Apr 2001 09:52:43 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA01152; Mon, 9 Apr 2001 09:52:39 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 09:52:41 +0200 Message-ID: From: Heiles Juergen To: "'curtis@avici.com'" , "Lazer, Monica A, NNAD" Cc: "'neil.2.harrison@bt.com'" , raszuk@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels) Date: Mon, 9 Apr 2001 09:52:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Curtis >Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with .... you are completely wrong and I suggest you better make measurments and get familiar with SONET before making such statements.. SONET/SDH equipment will not shut down/drop connections. Today SONET connections are permanent connections setup via the management system. An automatic drop of a conneciton as it is the case for switched connections will not occur. What you will see is the insertion of AIS (alarm indication signal) after the detection of an defect. But as soon as the defect is gone the AIS is removed and the connection is running again. AIS is nothing harmful as due to the defect the connection is interupted in any case. Furthermore the AIS avoids downstream alarms (alarm storms). What could be of concern are the following points. I talk about a server layer for a SONET/SDH network (e.g. an Optical Network) providing protection/restoration: Stacked protection/restoration: If you use protection/restoration at an optical network layer (server) and a SONET/SDH network layer (client) the server layer switching times should be faster than the client layer reaction times, so that the server layer does the protection/restoration and the client layer doesn't react. Automatic power reduction/automatic laser shutdown APR/ALS APR is used for safety reasons in order to avoid harmful emission of laser light in case of a fiber cut. One implementation switches off the transmit laser in case of loss of signal at the receiver. A restart action which is triggered automatically in intervals of several seconds is required in order to test if the link is repaired. Normally the APR function can be switched off if not needed. The APR function needs some careful consideration in case of protection/restoration and automatic connection setup in all optical networks. Regards Juergen > -----Original Message----- > From: Curtis Villamizar [SMTP:curtis@workhorse.fictitious.org] > Sent: Monday, April 09, 2001 4:37 AM > To: Lazer, Monica A, NNAD > Cc: 'neil.2.harrison@bt.com'; raszuk@cisco.com; mpls@UU.NET; ccamp@ops.ietf.org > Subject: restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels) > > > In message <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com>, "L > azer, Monica A, NNAD" writes: > > Voice switches will drop the connections after 2.5 seconds. A large number > > of dropped calls will cause FCC reportable events, which is something that > > US carriers need to avoid. So restoration within this time frame is needed > > for support of trunks carrying voice traffic. > > > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning > > > > 908 234 8462 > > mlazer@att.com > > > Monica, > > We're off topic, so I changed the subject. > > Thanks for providing the 2.5 second figure. > > I've heard carrier transport people grumble about SONET equipment > they'd be please to get rid of that will shut down even when used as > linear SONET with no protect path and as a result would require > <100msec restoration. Since there is enough of this SONET gear, the > carriers can't really get rid of it although it will probably > disappear over time and so they will make fast restoration a > requirement of people they buy from. To be safe, the request for > <50msec has been made. > > If you are not blessed with such equipment or you are able to work > around it when doing VoIP, then you are among the fortunate. > > Then again, this is second hand, so I could be completely wrong. This > is not a measurement I've made myself and the SONET equipment is not > something I'm familiar with such that I could say with confidence that > it could not be configured to hold on longer or to not shut down at> > all if there was no protect. > > OTOH there are those who (claim to) want to configure SONET on some > links but not on others and don't want a fast restoration. They want > to be assured that restoration will occur only after it is safe to > assume that SONET restoration is not available. > > Curtis From owner-mpls@UU.NET Mon Apr 9 07:06:11 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02796 for ; Mon, 9 Apr 2001 07:06:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjzo23963; Mon, 9 Apr 2001 11:05:14 GMT Received: by mail-control.mail.uu.net id QQkjzo04567 for mpls-outgoing; Mon, 9 Apr 2001 11:04:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjzo04546 for ; Mon, 9 Apr 2001 11:04:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjzo07465 for ; Mon, 9 Apr 2001 11:04:27 GMT From: ytr@123india.com Received: from c001.zsm.cp.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: c001-h001.c001.zsm.cp.net [209.228.56.115]) id QQkjzo24621 for ; Mon, 9 Apr 2001 11:04:26 GMT Received: (cpmta 15589 invoked from network); 9 Apr 2001 04:04:24 -0700 Date: 9 Apr 2001 04:04:24 -0700 Message-ID: <20010409110424.15588.cpmta@c001.zsm.cp.net> X-Sent: 9 Apr 2001 11:04:24 GMT Received: from [132.233.247.5] by mail.123india.com with HTTP; 09 Apr 2001 04:04:24 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: mpls@UU.NET Cc: jleu@mindspring.com X-Mailer: Web Mail 3.9.0.19 Subject: label allocation on shared media Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I have a queastion on label allocation on shared (ethernet) media. If u have already discussed pls provide pointers to mail archives. There is chance to have more than 1 same outgoing label at LSR 'A', which are genearted by LSR B and LSR C in the following situation. A B |-------| |-------| | | | | | |---------------| | | | | | | --------- | --------- | |---------|-------| | | | | | | --------- C If outgoing labels are diffrentiated on interface basic, this ambiguty is not resloved. How to resolve this amibguty?. Regards YTR ______________________________________________________ 123India.com - India's Premier Portal Get your Free Email Account at http://www.123india.com From owner-mpls@UU.NET Mon Apr 9 09:06:29 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05349 for ; Mon, 9 Apr 2001 09:06:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjzw15951; Mon, 9 Apr 2001 13:04:34 GMT Received: by mail-control.mail.uu.net id QQkjzw13309 for mpls-outgoing; Mon, 9 Apr 2001 13:03:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjzw10939 for ; Mon, 9 Apr 2001 13:03:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjzw07376 for ; Mon, 9 Apr 2001 13:02:50 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkjzw18991 for ; Mon, 9 Apr 2001 13:02:50 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 GAA27419 for ; Mon, 9 Apr 2001 06:03:12 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA00984 for mpls@uu.net; Mon, 9 Apr 2001 09:02:48 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjze05400 for ; Mon, 9 Apr 2001 08:41:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkjze18196 for ; Mon, 9 Apr 2001 08:40:39 GMT Received: from anti_vir1.rad.co.il by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.116.244.108]) id QQkjze09941 for ; Mon, 9 Apr 2001 08:40:38 GMT Received: from anti_vir1.rad.co.il (localhost [127.0.0.1]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id KAA07624 for ; Mon, 9 Apr 2001 10:39:07 +0200 (IST) Received: from radmail.rad.co.il (radmail [192.114.24.30]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id KAA07614; Mon, 9 Apr 2001 10:39:06 +0200 (IST) Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with ESMTP id il; Mon, 9 Apr 2001 10:43:36 +0300 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 11:40:22 +0200 Message-ID: From: Sasha Vainshtein To: "'Francois Le Faucheur'" , Sasha Vainshtein Cc: "'N S S Kishore Kankipati'" , liwwu@cisco.com, mpls@UU.NET, "'diffserv@ietf.org'" Subject: RE: [Diffserv] RE: Diff-Serv over MPLS Date: Mon, 9 Apr 2001 11:40:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkjzw15951 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA05349 Francois, The modification you suggest indeed improves readability of the document. However: 1. I am not sure that people really expect MUST/MUST NOT clauses to appear in the _Introduction_ part of an RFC/I-D as it happens with such clauses in Sections 1.4 and 1.6. Of course, this is my personal opinion only. 2. Just to be on the safe side, I would also add an _explicit_ pointer to Section 1.4 (or whatever number it would be if you decide to move it out of the Intro part) to Section 1.2, e.g.: "Section 1.4. describes overall operation of both E-LSPs and L-LSPs. Detailed operations of E-LSPs are specified in section 3." Hopefully these notes will be helpful and not just disturbing. ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@axerra.com phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) -----Original Message----- From: Francois Le Faucheur [mailto:flefauch@cisco.com] Sent: Friday, April 06, 2001 10:55 AM To: Sasha Vainshtein Cc: 'N S S Kishore Kankipati'; flefauch@cisco.com; liwwu@cisco.com; mpls@UU.NET; 'diffserv@ietf.org' Subject: [Diffserv] RE: Diff-Serv over MPLS Sasha, Section 1.4 of contains the following text: " For a given FEC, there may be more than one LSP carrying the same OA, for example for purposes of load balancing of the OA; However in order to respect ordering constraints, all packets of a given microflow, possibly spanning multiple BAs of a given Ordered Aggregate, MUST be transported over the same LSP. Conversely, each LSP MUST be capable of supporting all the (active) BAs of a given OA. " which applies both to E-LSPs and L-LSPs. So, I believe (i) the ordering constraint and (ii) the requirement for L-LSPs to support all active BAs of an OA are already accurately addressed. The only question is whether the readability of the document would be improved by some wordsmithing in section 1.2. If you feel that would help, we can slightly modify the beginning of section 1.2 into: " A single LSP can be used to support one or more OAs. Such LSPs can support up to eight BAs of a given FEC, regardless of how many OAs these BAs span." Do you feel this would improve readability? If yes, can you confirm the above suggestion is fine? Cheers Francois At 18:15 05/04/2001 +0200, Sasha Vainshtein wrote: > >Hi, > The reordering issue has been addressed in >, > "New Terminology for Diffserv" with an explicit reference to work > on MPLS Support of Differentiated Services. > Section 5 of this I-D introduces the notion of an Ordering >Aggregate (OA) as > A set of Behavior Aggregates that share an ordering >constraint. > The set of PHBs that are applied to this set of Behavior Aggregates > > constitutes a PHB scheduling class. > > I suggest that should be updated >to > allow only grouping of multiple OAs (and not BAs as it does) into > a single E-LSP. The current I-D version explicitly states > that L-LSP is established for a given (OA, FEC) class but is > ambiguous when it comes to E-LSPs. > > Nabil, in his message in this thread, has noticed that RFC 2597 > defines AF (y=1,2,3) as an OA for any fixed value of x (1-4). > The suggested modification would prohibit configurations like one >described > in the original message. >______________________________________________ >With best regards, >Sasha Vainshtein >mailto: sasha@axerra.com >phone: +972-3-7659993 (office) >fax: +972-3-6487779 (office) > > >>>-----Original Message----- >>>From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com] >>>Sent: Thursday, April 05, 2001 3:39 PM >>>To: flefauch@cisco.com; liwwu@cisco.com >>>Cc: mpls@UU.NET >>>Subject: Diff-Serv over MPLS >>> >>> >>>hi all >>> Could any of you please explain about the following >>>sentence in the draft-ietf-mpls-diff-ext-0.8.txt. >>> >>>section 1.2-- Exp-Inferred-PSC LSPS (E-LSP) >>> >>>"A single LSP can be used to support up to eight BAs >>>of >>>a given FEC, regardless of how many OAs these BAs >>>span." >>> >>>A small doubt >>> Suppose PHBs related to a PSC have been assigned to >>>different E-LSPs (say AF11 to one LSP and AF12 to >>>another LSP)and first few (say 1-10)Packets belonging >>>to a microflow have been assigned to AF11 and later >>>packets (say 10-15) to AF12. >>>Is it not possible for the packets in AF12 LSP to get >>>transferred before the packets in AF11 LSP? If that is >>>the case the ordering constraint is violated i.e >>>packets are reordered. (I think this may happen in >>>the following case- if the LSPs are on different >>>interfaces of a router and there may be some packets >>>which are required to be served in the AF11 while the >>>packets in AF12 may get immediately served as there >>>are >>>no packets before these which require service). >>> >>>thanks >>>kk >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Get email at your own domain with Yahoo! Mail. >>>http://personal.mail.yahoo.com/ >>> > PLEASE NOTE NEW CONTACT DETAILS - See below _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 97 23 26 19 Mobile : +33 6 89 108 159 Fax: +33 4 97 23 26 26 Email: flefauch@cisco.com _________________________________________________________________ Cisco Systems Europe Domaine Green Side 400, Avenue de Roumanille Bâtiment T3 06 410 BIOT SOPHIA ANTIPOLIS FRANCE _________________________________________________________________ From owner-mpls@UU.NET Mon Apr 9 09:08:10 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05377 for ; Mon, 9 Apr 2001 09:08:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjzw23256; Mon, 9 Apr 2001 13:05:50 GMT Received: by mail-control.mail.uu.net id QQkjzw15019 for mpls-outgoing; Mon, 9 Apr 2001 13:04:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjzw14632 for ; Mon, 9 Apr 2001 13:04:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjzw17335 for ; Mon, 9 Apr 2001 13:02:38 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkjzw18625 for ; Mon, 9 Apr 2001 13:02:34 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 GAA27239 for ; Mon, 9 Apr 2001 06:02:54 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA00979 for mpls@uu.net; Mon, 9 Apr 2001 09:02:30 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjxv29556 for ; Sun, 8 Apr 2001 23:49:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjxv11966 for ; Sun, 8 Apr 2001 23:47:13 GMT Received: from kcmgwp01.corp.sprint.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker1.sprint.com [208.18.122.165]) id QQkjxv21049 for ; Sun, 8 Apr 2001 23:47:11 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f38Nl7422089; Sun, 8 Apr 2001 18:47:07 -0500 (CDT) Received: from kcopmp06.corp.sprint.com (KCOPMP06.corp.sprint.com [10.74.0.81]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f38Nl6s13735; Sun, 8 Apr 2001 18:47:06 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp06.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id SAA15517; Sun, 8 Apr 2001 18:47:06 -0500 (CDT) From: Wil.Walkoe@mail.sprint.com X-OpenMail-Hops: 1 Date: Sun, 8 Apr 2001 18:47:05 -0500 Message-Id: Subject: EndToEndQos.doc MIME-Version: 1.0 TO: diffserv@ietf.org, mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-238944ed-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-238944ed-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Sun, 8 Apr 2001 18:47:03 -0500" Content-Transfer-Encoding: 7bit Dear people, The attached document is a working draft from the Broadband Content Delivery Forum's Infrastructure Working Group, addressing quality of service in end-to-end data delivery. It addresses QoS from a perspective that takes account of the many different intermediaries that play a role in data delivery and contribute to end-to-end delay, throughput, etc. I would be interested in your comments on this material, both on the content itself (errors, omissions, material from your standards work that should be addressed) and on where this topic could most effectively be addressed in the IETF. We will be editing this draft at the BCD Forum meeting April 25 - 27 in Las Vegas, and it would be very helpful to be able to include your ideas in the process. Sincerely, Wil Walkoe Vice-Chair, BCD Forum Infrastructure Working Group --openmail-part-238944ed-00000001 Content-Type: application/msword Content-Disposition: attachment; filename="EndToEndQos.doc" ;Creation-Date="Sun, 8 Apr 2001 18:47:05 -0500" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAAwEAAAAA AAAAEAAABQEAAAEAAAD+////AAAAAAABAAABAQAAAgEAAP////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAA 3oUAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAAAAAJBBYA7/UAADd8AAA3fAAAfWsAAJUA AABLAAAAAAAAAAAAAAAAAAAAgBUAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAGwAAAAAAFQDAAAAAAAAVAMAAFQDAAAKAAAAXgMAAAwAAACmGgAA AAAAAKYaAAAAAAAAphoAACQAAAAAAAAAAAAAAMoaAAAAAAAA9EgAAAAAAAD0SAAAAAAAAPRI AABQAAAAREkAADwAAACASQAArAAAAMoaAAAAAAAAeeQAAK4BAAA4SgAAAAAAADhKAAAAAAAA OEoAAAAAAAA4SgAAAAAAADhKAAAAAAAAs8QAAAAAAACzxAAAAAAAALPEAAAAAAAA+OMAAAIA AAD64wAAAAAAAPrjAAAAAAAA+uMAAAAAAAD64wAAAAAAAPrjAAAAAAAA+uMAACQAAAAn5gAA IAIAAEfoAACwAAAAHuQAABUAAAAAAAAAAAAAAAAAAAAAAAAAphoAAAAAAACzxAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAVuQAAngsAALPEAAAAAAAAs8QAAAAAAACzxAAAAAAAAB7kAAAAAAAA +8oAAAAAAABqAwAAAAAAAGoDAAAAAAAAOEoAAAAAAAAAAAAAAAAAADhKAADdbgAAM+QAABYA AAD7ygAAAAAAAPvKAAAAAAAA+8oAAAAAAACzxAAARgAAAGoDAADGEAAAOEoAAAAAAACmGgAA AAAAADhKAAAAAAAA+OMAAAAAAAAAAAAAAAAAAPvKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAs8QAAAAAAAD44wAAAAAAAPvKAAAeBgAA +8oAAAAAAAAZ0QAA/gAAAJfgAAAvAgAAMBQAAHYGAACmGgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzuMAAAAAAAA4SgAA AAAAACxKAAAMAAAAEOq1KKq/wAHKGgAAKi4AAPRIAAAAAAAA+cQAAJoAAADG4gAAGAAAAAAA AAAAAAAA3OMAABwAAABJ5AAAMAAAAHnkAAAAAAAA3uIAAPAAAAD36AAAAAAAAJPFAABoBQAA 9+gAAAAAAADO4wAADgAAAPvKAAAAAAAAyhoAAAAAAADKGgAAAAAAAGoDAAAAAAAAagMAAAAA AABqAwAAAAAAAGoDAAAAAAAAAgDZAAAAQkNEIEZvcnVtIEluZnJhc3RydWN0dXJlIFdvcmtp bmcgR3JvdXANRFJBRlQgUmVxdWlyZW1lbnRzIGZvciB0aGUgRW5kIHRvIEVuZCBNYW5hZ2Vt ZW50IG9mIE5ldHdvcmsgUXVhbGl0eSBvZiBTZXJ2aWNlIChRb1MpDUJDRCBGb3J1bSBDb250 cmlidXRvcnM6IFNpbW9uIEJyeWRlbiwgR2FyeSBEaXNoZXIsIE1pY2hlbCBGaXNoZXIsIERh bmllbCBUZWljaG1hbiwgV2lsIFdhbGtvZSwgJiBTdGV2ZSBXZXN0DVByb2JsZW06DUEgc3Vi c2NyaWJlciByZXF1ZXN0cyBjb250ZW50IGFuZC9vciBhbiBpbnRlcmFjdGl2ZSBzZXJ2aWNl LiBUaGUgbmV0d29yayBtdXN0IHByb3Zpc2lvbiBlbm91Z2ggYmFuZHdpZHRoIGFuZCBtYW5h Z2UgdGhlIGRlbGF5IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgc2Vzc2lvbiB0byBzYXRpc2Z5 IHRoaXMgcmVxdWVzdC4NDUluIG9yZGVyIHRvIGJlbmVmaXQgZnJvbSB0aGUgc2NhbGUgYW5k IGVmZmljaWVuY3kgb2Ygc2hhcmVkIFdBTnMgdGhhdCBzdXBwb3J0IG11bHRpcGxlIGFwcGxp Y2F0aW9ucywgdGhlIGVmZmVjdHMgb2YgY29udGVudGlvbiB3aWxsIG5lZWQgdG8gYmUgbWFu YWdlZCBlbmQgdG8gZW5kIGluIGEgd2F5IHRoYXQgdGFrZXMgYWNjb3VudCBvZiB0aGUgc3Bl Y2lmaWMgcmVxdWlyZW1lbnRzIG9mIHRoZSB1c2VyLCB1c2VyIGRldmljZSwgYXBwbGljYXRp b24sIGFuZCBjb250ZW50Lg0NVGhlIHNoYXJlZCBXQU4gbXVzdCBiZSBhYmxlIHRvIGFwcG9y dGlvbiBzZXJ2aWNlIChiYW5kd2lkdGggYW5kIGxhdGVuY3kpIHRvIHVzZXJzIHNvIHRoYXQg dGhlc2UgdXNlcnMgY2FuIHN1YnNjcmliZSB0byBhIGNvbnNpc3RlbnQgYW5kIHByZWRpY3Rh YmxlIGV4cGVyaWVuY2UuICBQcmVkaWN0YWJsZSBzZXJ2aWNlIGxldmVsIGlzIGEgcmVxdWly ZW1lbnQgZm9yIGNvbW1lcmNpYWwgZGVwbG95bWVudCBvZiBtYW55IG5ldyBoaWdoIHZhbHVl IHNlcnZpY2VzIHRoYXQgcmVseSBvbiB0aGUgYnJvYWRiYW5kIG5ldHdvcmsuICANDVdpdGgg dHJhZGl0aW9uYWwgdGVsZWNvbSBuZXR3b3Jrcywgc2VydmljZSBsZXZlbCBpcyBkZXRlcm1p bmVkIGJ5IGEgY29udHJhY3QgYmV0d2VlbiB0aGUgY2FycmllciBhbmQgdGhlIGVuZCB1c2Vy LiAgIFRoZSBlbmQgdXNlciBpcyBub3QgY29uY2VybmVkIHdpdGggdGhlIHN0cnVjdHVyZSBv ZiB0aGUgY2FycmllcpJzIG5ldHdvcmssIGFuZCBpcyBpc29sYXRlZCBmcm9tIHRoZSBlZmZl Y3RzIG9mIHRyYWZmaWMgZGVtYW5kcyBvZiBvdGhlciB1c2Vycy4gIA0NTmV3IGJyb2FkYmFu ZCBzZXJ2aWNlcyBhbmQgYXBwbGljYXRpb25zIHJlcXVpcmUgc2ltaWxhciBwcmVkaWN0YWJp bGl0eSBhbmQgc2ltcGxpY2l0eSwgZXZlbiB3aGVuIG11bHRpcGxlIHNlcnZpY2UgcHJvdmlk ZXJzIHBhcnRpY2lwYXRlIGluIGRlbGl2ZXJpbmcgdGhlIGRhdGEuICAgRW5kLXRvLUVuZCBR b1MgaXMgYW4gZWNvbm9taWMgaW1wZXJhdGl2ZSBmb3IgY2FycmllcnMsIHNlcnZpY2UgcHJv dmlkZXJzIGFuZCBmb3IgZW5kLXVzZXJzLg0NQ2FycmllcnMgcmVxdWlyZSB0aGUgYWJpbGl0 eSB0byBwcmljZSB0cmFuc3BvcnQgYmFzZWQgb24gaXRzIHZhbHVlIHRvIHRoZSBzZXJ2aWNl IHByb3ZpZGVyIGFuZCB0byB0aGUgZW5kLXVzZXIuICBSZXZlbnVlIGlzIHJlcXVpcmVkIHRv IGp1c3RpZnkgdGhlIHJlcXVpcmVkIGludmVzdG1lbnRzIGluIG5ldHdvcmsgaW5mcmFzdHJ1 Y3R1cmUuICBQcmVkaWN0YWJsZSBFbmQtdG8tRW5kIFFvUyB3aWxsIGVuYWJsZSBhIHJhbmdl IG9mIG5ldyBoaWdoIHZhbHVlIGFwcGxpY2F0aW9ucyBhbmQgc2VydmljZXMgYnkgY29udGVu dCwgYXBwbGljYXRpb24sIHN0b3JhZ2UgYW5kIHNlcnZpY2UgcHJvdmlkZXJzLiAgUHJpY2Ug ZGlmZmVyZW50aWF0aW9uIGlzIHVsdGltYXRlbHkgaW4gdGhlIGludGVyZXN0IG9mIGVuZC11 c2Vycywgd2hvIHdpbGwgZW5qb3kgYSByYW5nZSBvZiBuZXcgc2VydmljZSBhbHRlcm5hdGl2 ZXMuICANSXNzdWVzOg1UaGUgQnJva2VuIEhvdXJnbGFzcw1UaGUgb3JpZ2luYWwgbW9kZWwg b2YgdGhlIEludGVybmV0LCBhcyBpbGx1c3RyYXRlZCBpbiBGaWd1cmUgMSwgd2FzIHRoYXQg bWFueSBkaWZmZXJlbnQgdHlwZXMgb2YgaG9zdCBjb21wdXRlcnMsIGRhdGEgc291cmNlcywg YW5kIGFwcGxpY2F0aW9uIHNlcnZlcnMgY291bGQgZGVsaXZlciBhIHdpZGUgcmFuZ2Ugb2Yg Y29udGVudCBhbmQgYXBwbGljYXRpb25zIHRvIGFuIGVxdWFsbHkgZGl2ZXJzZSByYW5nZSBv ZiBjbGllbnQgZGV2aWNlcywgb3ZlciBhIGxpbmtlZCBzZXQgb2YgaG9tb2dlbmVvdXMgbmV0 d29ya3MgdGhhdCBwcm92aWRlZCBhIHNpbmdsZSwgd2VsbC1kZWZpbmVkIHNlcnZpY2U6ICBj b25uZWN0aW9ubGVzcyB0cmFuc3BvcnQgb2YgZGF0YSBwYWNrZXRzLiAgVGhlIHByb3ZpZGVy cyBvZiB0aGUgdHJhbnNwb3J0IG5ldHdvcmtzIHdvdWxkIG5vdCBuZWVkIGFueSBrbm93bGVk Z2Ugb2YgdGhlIGNvbXBsZXggc2VydmljZXMgY29uc3RydWN0ZWQgYXQgbmV0d29yayBlbmRw b2ludHMsIGJlY2F1c2UgYWxsIHRyYWZmaWMgd291bGQgYmUgZnVubmVsbGVkIGludG8gYSBj b21tb24gSW50ZXJuZXR3b3JraW5nIFByb3RvY29sLg0NQmVjYXVzZSB0aGUgbG93LWZ1bmN0 aW9uIEludGVybmV0IHByb3ZpZGluZyBjb21tb24gdHJhbnNwb3J0IGRpZCBub3QgbmVlZCB0 byBzdXBwb3J0IGFueSBmdW5jdGlvbmFsaXR5IGJleW9uZCB0aGUgYmFzaWMgbmV0d29yayBw cm90b2NvbCwgaXQgZGlkbpJ0IG1hdHRlciB0byB0aGUgZW5kIHN5c3RlbXMgaWYgdGhlIHBh Y2tldHMgdHJhdmVsbGVkIG92ZXIgYSBzaW5nbGUsIG1hbmFnZWQgbmV0d29yayBvciBwYXNz ZWQgdGhyb3VnaCBzZXZlcmFsIG5ldHdvcmtzIHJ1biBieSBkaWZmZXJlbnQgc2VydmljZSBw cm92aWRlcnMuICBJUCBhbmQgaXRzIGFzc29jaWF0ZWQgaGFuZG9mZiBwcm90b2NvbHMgY291 bGQgZGVsaXZlciB0aGUgcGFja2V0czsgZGVsaXZlcnkgY291bGQgYmUgbWFkZSByZWxpYWJs ZSBhbmQgc2VsZi1tYW5hZ2luZyB3aXRoIHRoZSBhZGRpdGlvbiBvZiBhIFRDUCBsYXllciwg YW5kIGFueSBmdXJ0aGVyIHNlcnZpY2UgZGVmaW5pdGlvbiBjb3VsZCBiZSBsZWZ0IGVudGly ZWx5IHRvIHRoZSBjb250ZW50IHNvdXJjZXMgYW5kIGNsaWVudHMuDQ1UaGlzIJNob3VyZ2xh c3OUIG1vZGVsIG9mIHRoZSBJbnRlcm5ldCBzdXBwb3J0ZWQgdGhlIGV2b2x1dGlvbiBvZiBh IHdpZGUgcmFuZ2Ugb2Ygc2VydmljZXMsIGVuY291cmFnaW5nIGlubm92YXRpb24gYnkgbWFr aW5nIG5ldyBzZXJ2aWNlIGNvbmNlcHRzIHZlcnkgZWFzeSB0byBwdXQgaW50byBwcmFjdGlj ZTogIEp1c3QgYnVpbGQgdGhlIHNlcnZpY2UsIG1hcCBpdCB0byBJUCB0cmFuc3BvcnQsIGFu ZCBpbnZpdGUgdXNlcnMgdGhyb3VnaG91dCB0aGUgd29ybGQgdG8gdHJ5IGl0IG91dC4NDVVu Zm9ydHVuYXRlbHksIHRoZXJlIGFyZSBzb21lIHNlcnZpY2UgaW5ub3ZhdGlvbnMgdGhhdCB0 aGUgaG91cmdsYXNzIG1vZGVsIGNhbm5vdCBzdXBwb3J0LiAgVHdvLXdheSBjb21tdW5pY2F0 aW9uIHNlcnZpY2VzIHN1Y2ggYXMgSW50ZXJuZXQgdGVsZXBob255IGFuZCBJbnRlcm5ldCB2 aWRlbyBjb25mZXJlbmNpbmcgYXJlIG9ubHkgZWZmZWN0aXZlIGlmIHRoZSBkYXRhIGlzIHRy YW5zbWl0dGVkIHdpdGggbG93IGRlbGF5LiAgSW50ZXJuZXQgdmlkZW8gY292ZXJhZ2Ugb2Yg YSBsaXZlIGV2ZW50IGxvc2VzIG11Y2ggb2YgaXRzIHZhbHVlIGlmIHRoZSByZWNlaXZlciBt dXN0IGhlYXZpbHkgYnVmZmVyIHRoZSB0cmFmZmljIJYgYnV0IHRoZSBhbHRlcm5hdGl2ZSBp cyB0byBkZWxpdmVyIHRoZSBtZWRpYSBzdHJlYW0gYXQgYSBwcmVkaWN0YWJsZSBtaW5pbXVt IGRhdGEgcmF0ZSBhbmQgd2l0aCBib3VuZGVkIGRlbGF5IHZhcmlhbmNlLiAgSVAsIHdoaWNo IHdhcyBkZWxpYmVyYXRlbHkgc2ltcGxpZmllZCB0byB0aGUgZnVuY3Rpb24gb2YgZ2V0dGlu ZyBkYXRhIGZyb20gcG9pbnQgQSB0byBwb2ludCBCLCBwcm92aWRlcyBubyB3YXkgdG8gbWFu YWdlIGRlbGF5LCB0aHJvdWdocHV0LCBvciBkZWxheSB2YXJpYW5jZS4gIEV2ZW4gYSBtYWlu c3RyZWFtIEludGVybmV0IGFwcGxpY2F0aW9uIHN1Y2ggYXMgV2ViIGJyb3dzaW5nIGNhbiBi ZSBtYWRlIGluZWZmZWN0aXZlIGJ5IJNmbGFzaCBjcm93ZJQgdHJhZmZpYyBhbmQvb3IgdGhl IHRyYW5zbWlzc2lvbiBvZiBsYXJnZSBmaWxlcyBhbmQgcmljaCBtZWRpYSBzdHJlYW1zIHRv IGJyb2FkYmFuZCB1c2Vycy4NDU5ldHdvcmsgZGVsYXlzIGFuZCB0aHJvdWdocHV0IGxpbWl0 YXRpb25zIGFyZSBuYXR1cmFsIGNvbnNlcXVlbmNlcyBvZiBjb25nZXN0aW9uIGF0IHZhcmlv dXMgcGxhY2VzIGFsb25nIHRoZSBkYXRhIHRyYW5zbWlzc2lvbiBwYXRoLiAgSGVhdmlseSBv dmVyLXByb3Zpc2lvbmluZyBuZXR3b3JrIHJlc291cmNlcyBjYW4gb3ZlcmNvbWUgdGhlIHBy b2JsZW1zLCBzbyB0aGF0IGNvbmdlc3Rpb24gZG9lcyBub3Qgb2NjdXIsIGJ1dCB0aGlzIGNh biBiZSBhbiBleHBlbnNpdmUgc29sdXRpb24gdW5sZXNzIGl0IGlzIHVzZWQgc2VsZWN0aXZl bHkuAiAgV2hlbiB0cmFuc3BvcnQgY29zdHMgYXJlIGEgc2lnbmlmaWNhbnQgcGFydCBvZiB0 aGUgdG90YWwgY29zdCBvZiBydW5uaW5nIGFuIGFwcGxpY2F0aW9uIG9yIHNlcnZpY2UsIHRo ZXJlIGFyZSBzdHJvbmcgZmluYW5jaWFsIGluY2VudGl2ZXMgdG8gaW1wcm92ZSBsaW5rIHV0 aWxpemF0aW9uLiAgIE1vcmUgZWZmaWNpZW50IGFwcHJvYWNoZXMgaW52b2x2ZSBtYW5hZ2lu ZyB0aGUgcG90ZW50aWFsIG5ldHdvcmsgYm90dGxlbmVja3MgaW4gc3VjaCBhIHdheSB0aGF0 IHNvbWUgb2YgdGhlIHRyYWZmaWMgZ2V0cyBzcGVjaWFsIGhhbmRsaW5nLCBzZWxlY3RpdmVs eSBtYW5hZ2luZyBhY2Nlc3MgdG8gZGVkaWNhdGVkIGJhbmR3aWR0aCwgYW5kIHNlbGVjdGl2 ZWx5IGJ5cGFzc2luZyB3aWRlLWFyZWEgbmV0d29ya3MgYnkgc3RhZ2luZyBjb250ZW50IGZv ciBsb2NhbCBkZWxpdmVyeS4gIA0NSW4gb3JkZXIgdG8gcHJvdmlkZSB0aGlzIHNvcnQgb2Yg UW9TIG1hbmFnZW1lbnQsIHRvZGF5knMgbmV0d29ya3MgcHJvdmlkZSBhIG51bWJlciBvZiB0 cmFmZmljIGNvbnRyb2wgbWVjaGFuaXNtcyBhdCBldmVyeSBzdGFnZSBpbiB0aGUgY29udGVu dCBkZWxpdmVyeSBjaGFpbiBzaG93biBpbiBGaWd1cmUgMi4gIA0NV2hpbGUgdGhlIGVuZHBv aW50cyBvZiB0aGUgZGF0YSBzZXNzaW9uIGFyZSBzdGlsbCBhY3RpdmVseSBpbnZvbHZlZCBp biBwcm92aWRpbmcgUW9TIHRocm91Z2ggYXJlYXMgb2YgdHJhZmZpYyBjb250ZW50aW9uLCB0 aGVyZSBhcmUgc2V2ZXJhbCBjb250ZW50aW9uIHBvaW50cyB0aGF0IG11c3QgYmUgbWFuYWdl ZCBieSBvdGhlciBwYXJ0aWNpcGFudHMgaW4gdGhlIGRlbGl2ZXJ5IGNoYWluLiAgUmF0aGVy IHRoYW4gYmVpbmcgaGlkZGVuIGJlaGluZCBhIHNpbXBsZSBJUCBpbnRlcmZhY2UsIHRoZSBw cm92aWRlcnMgb2YgdGhlIGFjY2VzcyBuZXR3b3JrLCBkYXRhIGFnZ3JlZ2F0aW9uIJNlZGdl lCBjZW50ZXJzLCBhbmQgbXVsdGlwbGUgd2lkZS1hcmVhIG5ldHdvcmtzIHBsYXkgYW4gYWN0 aXZlIHJvbGUgaW4gbWFuYWdpbmcgdGhyb3VnaHB1dCBhbmQgZGVsYXkuICAgSW5zdGVhZCBv ZiBzaW1wbHkgaGFuZGluZyBkYXRhIG9mZiB0byBhIHNpbXBsZSBJUCBuZXR3b3JrLCB0aGUg ZW5kcG9pbnRzIG11c3Qgbm93IG5lZ290aWF0ZSBhcHByb3ByaWF0ZSBzZXJ2aWNlIGNoYXJh Y3RlcmlzdGljcyB3aXRoIGEgbnVtYmVyIG9mIGludGVybWVkaWFyaWVzLg1XaG8gaXMgaW52 b2x2ZWQgd2l0aCB0aGUgUW9TIGRlY2lzaW9uPw1XaG8gYXJlIHRoZXNlIG5ldyBtYW5hZ2Vy cyBvZiBkYXRhIGRlbGl2ZXJ5PyBDb250ZW50aW9uIG1hbmFnZW1lbnQgaXMgbmVlZGVkIHdo ZXJldmVyIHRoZXJlIGlzIGNvbnRlbnRpb24uICBTdXBwb3NlIHRoYXQgYSBzdWJzY3JpYmVy knMgUEMgb3Igc2V0LXRvcCBib3ggaW5pdGlhdGVzIHRoZSBkb3dubG9hZCBvZiBhbiBpdGVt IG9mIGNvbnRlbnQuICBJZiB0aGUgUEMgaXMgY29ubmVjdGVkIHRvIGEgaG9tZS9vZmZpY2Ug bmV0d29yayBhbmQgYWNjZXNzIGRldmljZSB0aGF0IGlzIHNoYXJlZCB3aXRoIG90aGVyIGVu ZCBlcXVpcG1lbnQsIHRoZXJlIG1heSBiZSBjb250ZW50aW9uIHdpdGhpbiB0aGlzIGJ1aWxk aW5nIGFjY2VzcyBzeXN0ZW0uIEZyb20gdGhlIHByZW1pc2UgbmV0d29yaywgdGhlIHNlc3Np b24gaXMgaGFuZGVkIG9mZiB0byBhbiBhY2Nlc3MgdGVjaG5vbG9neTsgZS5nLiBjYWJsZSwg RFNMLCBFdGhlcm5ldCwgb3Igd2lyZWxlc3MuIFRoZSBhY2Nlc3MgbmV0d29yayBjb3VsZCB0 YWtlIHRoZSBmb3JtIG9mIGEgc2hhcmVkIG1lZGl1bSwgd2hlcmUgdGhlcmUgaXMgY29udGVu dGlvbiBiZXR3ZWVuIHN1YnNjcmliZXJzLCBvciBhIGRlZGljYXRlZCBjb25uZWN0aW9uLg0N TmV4dCwgdGhlcmUgd2lsbCB0eXBpY2FsbHkgYmUgYW4gk2FjY2VzcyBub2RllCBhZ2dyZWdh dGlvbiBkZXZpY2UsIGVnIGNhYmxlIG1vZGVtIGhlYWQtZW5kLCBEU0xBTSwgZGF0YSBzd2l0 Y2ggb3Igd2lyZWxlc3MgY2VsbCB0aGF0IHdpbGwgYWdncmVnYXRlIG1hbnkgc3Vic2NyaWJl cnMgaW50byBvbmUgb3IgbW9yZSB1cGxpbmtzIHRvIGFuIGFjY2VzcyBjb25jZW50cmF0aW9u IHBvaW50LCBvciCTc2VydmljZSBub2RllCBsb2NhdGVkIGF0IGFuIJNlZGdlIGNlbnRlcpQu ICBUaGUgZWRnZSBjZW50ZXIgbWF5IGFwcGx5IHNvbWUga2luZCBvZiBzZXJ2aWNlIHN1Y2gg YXMgYXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRpb24gYW5kIGFjY291bnRpbmcgKEFBQSks IGZpcmV3YWxsLCB0cmFmZmljIGNvbmRpdGlvbmluZyBldGMgYW5kIGNhbiBkaXN0cmlidXRl IGFuZCByZWFnZ3JlZ2F0ZSB0aGUgdHJhZmZpYyBpbnRvIGFuIGFjY2VzcyBjb3JlLCB3aGlj aCB0aGVuIGNvbm5lY3RzIHRvIGFuIEludGVybmV0IFNlcnZpY2UgUHJvdmlkZXIgdG8gcHJv dmlkZSBhY2Nlc3MgdG8gdGhlIGdsb2JhbCBJbnRlcm5ldC4gIEFzIGFuIGFsdGVybmF0aXZl IHRvIEludGVybmV0IHRyYW5zcG9ydCwgdGhlIGVkZ2UgY2VudGVyIG1heSBoYXZlIGxvY2Fs IGNhY2hlcyBhbmQgc2VydmVycywgc2F0ZWxsaXRlIGZlZWRzLCBhbmQgYWNjZXNzIHRvIHNw ZWNpYWxpemVkIG5ldHdvcmtzIHRoYXQgcHJvdmlkZSBwYXJ0aWN1bGFyIHBlcmZvcm1hbmNl IGNoYXJhY3RlcmlzdGljcy4NDUZpbmFsbHksIHRoZSBwcmltYXJ5IGhvc3RpbmcgY2VudGVy IGZvciB0aGUgY29udGVudCBvciBhcHBsaWNhdGlvbiBjb3VsZCBiZSBlaXRoZXIgYSBjZW50 cmFsaXplZCBkYXRhIGNlbnRlciBvciBhIGRpc3RyaWJ1dGVkIGhvc3RpbmcgcmVzb3VyY2Us IGluIGVpdGhlciBjYXNlIG1ha2luZyB1c2Ugb2Ygc29waGlzdGljYXRlZCBsb2FkIGJhbGFu Y2luZyBhbmQgY29udGVudGlvbiBtYW5hZ2VtZW50IHRlY2huaXF1ZXMgdGhyb3VnaCBkYXRh IHN3aXRjaGVzIGFuZCBpbnRlbGxpZ2VudCBzdG9yYWdlLWFyZWEgbmV0d29ya3MuDQ1GaWd1 cmVzIDMgliA4IGRlc2NyaWJlIHNvbWUgb2YgdGhlIGtleSBRb1MgaXNzdWVzIGludm9sdmVk IGluIGVhY2ggc3RhZ2Ugb2YgZGF0YSBkZWxpdmVyeS4NV2hpY2ggZGV2aWNlcyBrbm93IHRo ZSBkYXRhIGRlbGl2ZXJ5IHJlcXVpcmVtZW50cz8NVGhlIFFvUyByZXF1aXJlbWVudHMgb2Yg YSBkYXRhIHNlc3Npb24gYXJlIHR5cGljYWxseSBkZXRlcm1pbmVkIGF0IHRoZSBlbmRwb2lu dHMgb2YgdGhlIHNlc3Npb24uICBGb3IgZXhhbXBsZSwgd2hlbiBhIHJlcXVlc3QgaXMgbWFk ZSB0byBkb3dubG9hZCBzb21lIHN0cmVhbWVkIGJyb2FkYmFuZCBjb250ZW50LCB0aGUgYmFu ZHdpZHRoIHJlcXVpcmVtZW50IG1heSBiZSBkZXRlcm1pbmVkIHNvbGVseSBieSB0aGUgZW5j b2RpbmcgdHlwZSBvZiB0aGUgZGVzaXJlZCBjb250ZW50LiBUaGlzIGVuY29kaW5nIHR5cGUg aXMgc2lnbmFsZWQgdG8gdGhlIGNsaWVudCByZWFkZXIgKGVnIFJlYWxQbGF5ZXIpIGJ5IHdh eSBvZiB0aGUgc3RyZWFtaW5nIHNpZ25hbGluZyBwcm90b2NvbC4gSW4gbW9yZSBjb21wbGlj YXRlZCBzaXR1YXRpb25zLCB0aGUgUW9TIHJlcXVpcmVtZW50cyBtYXkgYmUgZGV0ZXJtaW5l ZCBqb2ludGx5IGJ5IHRoZSBuYXR1cmUgb2YgdGhlIGFwcGxpY2F0aW9uLCB0aGUgY2FwYWJp bGl0aWVzIG9mIGVhY2ggZW5kcG9pbnQgZGV2aWNlLCB0aGUgY29udGVudCBwcm92aWRlcpJz IHF1YWxpdHkgYXNzdXJhbmNlIHBvbGljaWVzLCBhbmQgdGhlIHdpbGxpbmduZXNzIG9mIHRo ZSBjbGllbnQgYW5kIGNvbnRlbnQgcHJvdmlkZXIgdG8gcGF5IGZvciBwcmVtaXVtIGRlbGl2 ZXJ5LiAgQnV0IGl0IGlzIHN0aWxsIHRoZSBjb250ZW50IHNvdXJjZSBhbmQgdGhlIHJlcXVl c3RpbmcgY2xpZW50IHRoYXQgZGV0ZXJtaW5lIHRoZSB1bmNvbnN0cmFpbmVkIHJlcXVpcmVt ZW50cyBmb3IgZGF0YSBkZWxpdmVyeSCWIGkuZS4gdGhlIFFvUyBiZXN0IHN1aXRlZCB0byB0 aGUgZGF0YSBzZXNzaW9uLg0NT3RoZXIgcGFydHMgb2YgdGhlIGRhdGEgZGVsaXZlcnkgcGF0 aCBtdXN0IGhhdmUgdGhlIGNhcGFiaWxpdGllcyB0aGF0IG1ha2UgdGhlIGRlc2lyZWQgUW9T IGF0dGFpbmFibGUuICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudJJzIGFkYXB0ZWQgbGluZSBy YXRlIChhY2Nlc3MgbmV0d29yaykgbXVzdCBzdXBwb3J0IHRoZSCTcmVxdWlyZWSUIGJhbmR3 aWR0aC4gIEhpZ2ggY29uY3VycmVudCBkZW1hbmQgZm9yIHRoZSBjb250ZW50IG1heSByZXF1 aXJlIG11bHRpY2FzdCAoYWNjZXNzIGFuZCB3aWRlLWFyZWEgbmV0d29ya3MpIG9yIGNhY2hp bmcgKGVkZ2UgY2VudGVyKSB0byBtZWV0IHRoZSCTcmVxdWlyZW1lbnRzLpQgIEV2ZW4gd2l0 aGluIHRoZSBlbmQgbm9kZXMsIHRoZSBjYXBhYmlsaXRpZXMgYW5kIGNvbnN0cmFpbnRzIG9m IHRoZSBwcmVtaXNlIExBTiBhbmQgc3RvcmFnZS1hcmVhIG5ldHdvcmsgcGxheSBhIHJvbGUg aW4gZGV0ZXJtaW5pbmcgdGhlIGRlbGl2ZXJhYmxlIFFvUy4NDVFvUyBzcGVjaWZpY2F0aW9u IHdpbGwgcmVxdWlyZSBuZWdvdGlhdGlvbiBhbW9uZyBhbGwgb2YgdGhlc2UgZWxlbWVudHMs IGFuZCBRb1MgZGVsaXZlcnkgd2lsbCByZXF1aXJlIHRoZWlyIGNvb3JkaW5hdGVkIGFjdGlv bi4gIEluc3RlYWQgb2YgZnVubmVsbGluZyBkYXRhIHRocm91Z2ggYSBzaW1wbGUgaG91cmds YXNzLCB0aGUgZW5kLWNsaWVudCBhbmQgZW5kLXNlcnZlciBub3cgZmFjZSBhIGNvbXBsZXgg cHJvYmxlbSBpbiBzdXBwbHkgY2hhaW4gbWFuYWdlbWVudC4NSG93IGRvIHRoZSBuZXR3b3Jr IGVsZW1lbnRzIHByb3ZpZGUgUW9TPw1PbmUgbWVhc3VyZSBvZiB0aGUgZ3Jvd2luZyBpbXBv cnRhbmNlIG9mIHByb3ZpZGluZyBtdWx0aXBsZSBRb1MgY2hhcmFjdGVyaXN0aWNzIGluIHNo YXJlZCBuZXR3b3JrcyBpcyB0aGUgbGFyZ2Ugc2V0IG9mIHRvb2xzIHRoYXQgaGF2ZSBiZWVu IGRldmVsb3BlZCBhbmQgZGVwbG95ZWQgZm9yIHRoaXMgcHVycG9zZS4gIFRoZXkgaW5jbHVk ZToNDVByb3Bvc2VkIHVuaXZlcnNhbCBzb2x1dGlvbnMNDUludFNlcnYgd2l0aCBSU1ZQIGFu ZCBBVE0gU1ZDIHNpZ25hbGxpbmcgd2VyZSBlYWNoIHN1cHBvc2VkIHRvIHByb3ZpZGUgIHVu aXZlcnNhbCBtZWNoYW5pc21zIGZvciBzZXR0aW5nIHVwIGNvbm5lY3Rpb25zIHdpdGggRW5k LXRvLUVuZCBRb1MgZ3VhcmFudGVlcy4gIE5laXRoZXIgcHJvcG9zYWwgaGFzIGFjaGlldmVk IHRoaXMgZ29hbCwgYmVjYXVzZSBvZiBzY2FsaW5nIHByb2JsZW1zIGFuZCB0aGUgZGlmZmlj dWx0eSBvZiBpbXBsZW1lbnRpbmcgYWxsIG9mIHRoZSBjb21wb25lbnRzIGVuZC10by1lbmQu ICANDZNVbml2ZXJzYWwgc29sdXRpb26UIGh5YnJpZHMNDUFUTSBoYXMgYmVlbiB3aWRlbHkg ZGVwbG95ZWQgYXMgYSB0cmFmZmljLWVuZ2luZWVyaW5nIGxheWVyIGZvciBJUCBuZXR3b3Jr cy4gIA0NUlNWUC1URSBhbmQgQ1ItTERQIGFyZSBldm9sdmluZyBhcyBhIHNpZ25hbGxpbmcg aW50ZXJmYWNlIGZvciB0cmFmZmljIGVuZ2luZWVyaW5nIG9mIGFnZ3JlZ2F0ZXMgaW4gTVBM UywgR01QTFMgYW5kIE1QIExhbWJkYSBTIG5ldHdvcmtzLiAgVGhlc2UgdHJhZmZpYy1lbmdp bmVlcmluZyBtZWNoYW5pc21zIGNhbiBiZSBhcHBsaWVkIHdpdGhpbiBhIG5ldHdvcmsgYW5k IGF0IHRoZSBuZXR3b3JrLXRvLW5ldHdvcmsgaW50ZXJmYWNlLg0NQmFuZHdpZHRoIHJlc2Vy dmF0aW9uIGFuZCB2aXJ0dWFsIHRydW5raW5nDQ1EZXRlcm1pbmlzdGljIHJlc2VydmF0aW9u IG9mIGJhbmR3aWR0aCBwcm92aWRlcyB0aGUgc3Ryb25nZXN0IGd1YXJhbnRlZSBvZiBRb1Ms IGJ1dCBpdCBpcyBhbHNvIHRoZSBtb3N0IGRpZmZpY3VsdCB0byBhY2hpZXZlLiAgUlNWUCAo SVApLCBDQlIgYW5kIFZCUiAoQVRNKSwgYW5kIENvbW1pdHRlZCBJbmZvcm1hdGlvbiBSYXRl IChmcmFtZSByZWxheSkgZWFjaCBwcm92aWRlIGEgZGF0YSBzZXNzaW9uIG9yIGdyb3VwIG9m IHNlc3Npb25zIHdpdGggYSBndWFyYW50ZWVkIG1pbmltdW0gYmFuZHdpZHRoLCBidXQgaXQg aXMgZGlmZmljdWx0IHRvIGltcG9zc2libGUgdG8gZXN0YWJsaXNoIHRoZXNlIHJlc2VydmF0 aW9ucyBvbiBkZW1hbmQuICBSU1ZQIGlzIGhhcmQgdG8gc2NhbGUgdG8gY29tcGxleCBuZXR3 b3JrcywgQVRNIFNWQ3MgZG9uknQgc3VwcG9ydCBhIGhpZ2ggY2FsbCBzZXQtdXAgcmF0ZSwg YW5kIGZyYW1lIHJlbGF5IHdhc26SdCBkZXNpZ25lZCBmb3IgcmVhbC10aW1lIGNvbmZpZ3Vy YXRpb24uIA0NV2hpbGUgcmVzZXJ2YXRpb24gbWV0aG9kcyBhcmUgZGlmZmljdWx0IHRvIHNl dCB1cCBvbiBhIGNhbGwtYnktY2FsbCBiYXNpcywgdGhleSBjYW4gcHJvdmlkZSBsYXJnZSwg c2hhcmVkIGRhdGEgcGF0aHMgYmV0d2VlbiBuZXR3b3JrIGVkZ2Ugbm9kZXMgd2l0aCBndWFy YW50ZWVkIGFnZ3JlZ2F0ZSBiYW5kd2lkdGguICBCeSBtYW5hZ2luZyB0aGUgYWRtaXNzaW9u IG9mIGRhdGEgc2Vzc2lvbnMgaW50byB0aGVzZSB2aXJ0dWFsIHRydW5rcyAoaS5lLiBtYXJr aW5nIHRoZSBkYXRhIHBhdGggk2Z1bGyUIHdoZW4gdGhlIHRvdGFsIHJlcXVlc3RlZCBiYW5k d2lkdGggb2YgdGhlIHNlc3Npb25zIGl0IGlzIGNhcnJ5aW5nIGV4Y2VlZHMgc29tZSBsaW1p dCksIGluZGl2aWR1YWwgZGF0YSBzZXNzaW9ucyBjYW4gYmUgcHJvdmlkZWQgd2l0aCBhIGZv cm0gb2Ygc3RhdGlzdGljYWwgYmFuZHdpZHRoIJNyZXNlcnZhdGlvbiyUIGluIHdoaWNoIHRo ZSBwcm9iYWJpbGl0eSBvZiBmYWxsaW5nIGJlbG93IGEgc2Vzc2lvbpJzIHNwZWNpZmllZCBt aW5pbXVtIGJhbmR3aWR0aCBvciBtYXhpbXVtIGRlbGF5IGlzIHF1aXRlIGxvdy4gIE1QTFMg YW5kIEFUTSB2aXJ0dWFsIHBhdGhzIGNhbiBiZSB1c2VkIGluIHRoaXMgd2F5Lg0NUHJpb3Jp dHkNDUluc3RlYWQgb2YgYXR0ZW1wdGluZyB0byBndWFyYW50ZWUgdGhlIGJhbmR3aWR0aCBh bmQgZGVsYXkgY2hhcmFjdGVyaXN0aWNzIG9mIGEgc2Vzc2lvbiwgcHJpb3JpdHkgc2NoZW1l cyBzdWNoIGFzIERpZmZTZXJ2IGdpdmUgUW9TLXNlbnNpdGl2ZSBzZXNzaW9ucyAoZS5nLiB2 b2ljZSBjYWxscykgcHJlZmVyZW50aWFsIHRyZWF0bWVudCBvdmVyIGxlc3Mgc2Vuc2l0aXZl IGFwcGxpY2F0aW9ucyAoc3VjaCBhcyBmaWxlIHRyYW5zZmVycykuICBBcyBsb25nIGFzIHRo ZXJlIGlzIGVub3VnaCBsb3ctcHJpb3JpdHkgdHJhZmZpYyB0byCTcHVzaCBhc2lkZSyUIHRo aXMgY2FuIHByb3ZpZGUgdGhlIGhpZ2gtcHJpb3JpdHkgdHJhZmZpYyB3aXRoIGhpZ2ggdGhy b3VnaHB1dCBhbmQgbG93IGRlbGF5LiAgQXMgdGhlIHZvbHVtZSBvZiBoaWdoLXByaW9yaXR5 IHRyYWZmaWMgaW5jcmVhc2VzIGluIHJlbGF0aW9uIHRvIHRoZSB0b3RhbCBhdmFpbGFibGUg Y2FwYWNpdHksIHRoZSBRb1MgZm9yIHRoZSBoaWdoLXByaW9yaXR5IHRyYWZmaWMgZ3JhZHVh bGx5IGRlZ3JhZGVzLiAgSW4gcHJhY3RpY2UsIHRoZXJlIG1heSBiZSBhIFFvUyB0aHJlc2hv bGQgYmVsb3cgd2hpY2ggdGhlIHNlc3Npb24gbm8gbG9uZ2VyIHN1cHBvcnRzIGl0cyBhcHBs aWNhdGlvbiBhZGVxdWF0ZWx5LCBhbmQgc3RyYXRlZ2llcyBhcmUgbmVlZGVkIHRvIGF2b2lk IHRoaXMgc2l0dWF0aW9uIChzZXNzaW9uIGFkbWlzc2lvbiBjb250cm9sKSBhbmQgdG8gbWFu YWdlIGl0IHdoZW4gaXQgb2NjdXJzIChkeW5hbWljIHJlY29uZmlndXJhdGlvbikuDQ1Mb2Nh bCBkZWxpdmVyeQ0NVHJhZmZpYyBjb25nZXN0aW9uIGluIHRoZSBXQU4gYW5kIHByaW1hcnkg aG9zdGluZyBjZW50ZXIgY2FuIGJlIGJ5cGFzc2VkIGJ5IGRlbGl2ZXJpbmcgY29udGVudCBk aXJlY3RseSBmcm9tIGEgbG9jYWwgc291cmNlIHN1Y2ggYXMgdGhlIGVkZ2UgY2VudGVyLiAg U2V2ZXJhbCBlcXVpcG1lbnQgdmVuZG9ycyBwcm92aWRlIGRlbWFuZCBjYWNoaW5nIHN5c3Rl bXMgdGhhdCBtYWludGFpbiBsb2NhbCBjb3BpZXMgb2YgdGhlIG1vc3QgcmVjZW50bHkgcmVx dWVzdGVkIGRhdGEsIHNvIHRoYXQgcmVwZWF0IHJlcXVlc3RzIGZvciB0aGUgZGF0YSBjYW4g YmUgc2VydmVkIGRpcmVjdGx5IGZyb20gdGhlIGNhY2hlLiAgQ29udGVudCBkZWxpdmVyeSBu ZXR3b3JrcyBwcm92aWRlIG1hbmFnZWQgY2FjaGluZyBzeXN0ZW1zIHRoYXQgZW5hYmxlIGNv bnRlbnQgcHJvdmlkZXJzIHRvIHByZS1wb3NpdGlvbiBjcml0aWNhbCBkYXRhIGFzIHdlbGwg YXMgZHluYW1pY2FsbHkgaW5jcmVhc2luZyB0aGVpciBsb2NhbCBzZXJ2aWNlIGNhcGFjaXR5 IGluIHJlc3BvbnNlIHRvIGRlbWFuZC4gIERpc3RyaWJ1dGVkIGRhdGEgc291cmNpbmcgcGxh Y2VzIHByaW1hcnkgc2VydmVycyBhbmQvb3Igc3RvcmFnZSByZXNvdXJjZXMgaW4gb3IgbmVh ciBlZGdlIGNlbnRlcnMgYW5kIGtleSBJbnRlcm5ldCBsb2NhdGlvbnMsIHRvIHJlZHVjZSB0 aGUgY29zdCBhbmQgcGVyZm9ybWFuY2UgaW1wYWN0cyBvZiB3aWRlLWFyZWEgZGF0YSB0cmFu c3BvcnQuDQ1OZXR3b3JrIHNlbGVjdGlvbg0NQXQgYW4gZWRnZSBjZW50ZXIgKG9yIG90aGVy IHBvaW50IG9mIGZsZXhpYmlsaXR5IGluIHRoZSBkYXRhIHBhdGgpLCB0aGVyZSBtYXkgYmUg bW9yZSB0aGFuIG9uZSBXQU4gYXZhaWxhYmxlIHRvIGNhcnJ5IHRyYWZmaWMgdG8gcmVtb3Rl IGxvY2F0aW9ucy4gIElmIHRoZXNlIFdBTnMgaGF2ZSBkaWZmZXJlbnQgUW9TIGNoYXJhY3Rl cmlzdGljcyAoZWl0aGVyIG92ZXJhbGwgb3IgYXQgYSBwYXJ0aWN1bGFyIHRpbWUpLCByb3V0 aW5nIHRyYWZmaWMgdG8gZGlmZmVyZW50IFdBTnMgcHJvdmlkZXMgYW5vdGhlciB0b29sIHRv IG1hbmFnZSBRb1MuICBUaGlzIGFwcHJvYWNoIGNhbiBhbHNvIGJlIHVzZWQgYnkgdGhlIHBy ZW1pc2UgbmV0d29yaywgaWYgaXQgaGFzIG11bHRpcGxlIGFjY2VzcyBuZXR3b3JrIGNvbm5l Y3Rpb25zLg0NTXVsdGljYXN0DQ1EYXRhIHRoYXQgaXMgdHJhbnNtaXR0ZWQgY29uY3VycmVu dGx5IGZyb20gYSBzbWFsbCBudW1iZXIgb2Ygc291cmNlcyB0byBhIGxhcmdlIG51bWJlciBv ZiB1c2VycyBjYW4gYmVuZWZpdCBmcm9tIG11bHRpY2FzdCB0ZWNobm9sb2d5LCB3aGljaCBy ZXBsaWNhdGVzIHRoZSBkYXRhIG9uIGRlbWFuZCBpbiB2YXJpb3VzIG5ldHdvcmsgZWxlbWVu dHMuICBUaGlzIGltcHJvdmVzIFFvUyBieSByZWR1Y2luZyBjb250ZW50aW9uIHRocm91Z2hv dXQgdGhlIGRhdGEgZGVsaXZlcnkgY2hhaW4uDQ1WYXJpYXRpb25zIGluIHRoZSBhY2Nlc3Mg bmV0d29yaw0NVGhlIGFjY2VzcyBuZXR3b3JrIGhhcyBtb3JlIGxlbmllbnQgc2NhbGFiaWxp dHkgcmVxdWlyZW1lbnRzIHRoYW4gd2lkZS1hcmVhIG5ldHdvcmtzLCBhbmQgdGhleSBjYW4g dGFrZSBhZHZhbnRhZ2Ugb2YgdGVjaG5vbG9neS1zcGVjaWZpYyBhcHByb2FjaGVzLiAgRE9D U0lTIDEuMSAoY2FibGUgbW9kZW0gc3lzdGVtcyksIElFRUUgODAyLjEgUC9RIChGVFRDL0gg d2l0aCBzd2l0Y2hlZCBFdGhlcm5ldCksIGFuZCB0aGUgdXNlIG9mIEFUTSBRb1MgaW4gc29t ZSB4RFNMIGFjY2VzcyBuZXR3b3JrcyBhcmUgdGhyZWUgZGlmZmVyZW50IHdheXMgdG8gbWFu YWdlIGNvbnRlbnRpb24gaW4gdGhlIGFjY2VzcyBuZXR3b3JrLiAgVGhlIFJTVlAgSVAgUW9T IG1lY2hhbmlzbSwgd2hpY2ggaGFzIHNjYWxpbmcgbGltaXRhdGlvbnMgYXMgYW4gZW5kLXRv LWVuZCBzb2x1dGlvbiwgbWlnaHQgYmUgbW9yZSBlZmZlY3RpdmUgYXMgYSBzdWJzeXN0ZW0g bWFuYWdlbWVudCB0b29sLg0NSW50ZXJmYWNlcyBldmVyeXdoZXJlDQ1FYXJseSBRb1MgY29u dHJvbCBtZWNoYW5pc21zIHByb3ZpZGVkIHR3byBiYXNpYyB0eXBlcyBvZiBpbnRlcmZhY2U6 IGEgdXNlciB0byBuZXR3b3JrIGludGVyZmFjZSAoVU5JKSwgYW5kIGEgbmV0d29yay10by1u ZXR3b3JrIGludGVyZmFjZSAoTk5JKS4gIFByb3ZpZGluZyBRb1MgdGhyb3VnaCB0aGUgY3Vy cmVudCBlbnZpcm9ubWVudCBvZiBtdWx0aXBsZSBuZXR3b3JrIHByb3ZpZGVycywgQ0ROcywg ZWRnZSBkZWxpdmVyeSBwcm92aWRlcnMsIHN0b3JhZ2UtYXJlYSBuZXR3b3JrcywgYW5kIHNl cnZlciBjYXBhYmlsaXRpZXMsIG5vdyBpbnZvbHZlcyBhIGxhcmdlIG51bWJlciBvZiBkaWZm ZXJlbnQgaW50ZXJmYWNlcyAgLS0gZXZlbiBpZiBhbGwgb2YgdGhlIHN5c3RlbXMgY29uZm9y bSB0byB2YXJpb3VzIGluZHVzdHJ5IJNzdGFuZGFyZHMulA0NQ2hhb3MgYW5kIENyZWF0aXZp dHkNRWFjaCBzZWdtZW50IG9mIHRoZSBkYXRhIGRlbGl2ZXJ5IGNoYWluIGlzIGRyYXduIGZy b20gYSBzZXQgb2YgY29tcGV0aW5nIHNlcnZpY2UgcHJvdmlkZXJzLiAgRWFjaCBzZXJ2aWNl IHByb3ZpZGVyIHVzZXMgb25lIG9yIG1vcmUgb2YgYSBudW1iZXIgb2YgZGlmZmVyZW50IHRl Y2hub2xvZ2llcyBhbmQgY29udGVudGlvbiBtYW5hZ2VtZW50IHN0cmF0ZWdpZXMuICBBdCBm aXJzdCBnbGFuY2UsIHRoaXMgaXMgYSByZWNpcGUgZm9yIGNoYW9zLg0NV2hhdCBoYXMgaGFw cGVuZWQgaXMgdGhhdCB0aGUgdHlwZSBvZiBmcmVlLW1hcmtldCBjcmVhdGl2aXR5IGFuZCBp bm5vdmF0aW9uIHRoYXQgdGhlIG9yaWdpbmFsIEludGVybmV0IHN1cHBvcnRlZCBhdCB0aGUg bmV0d29yayBlbmRwb2ludHMgaGFzIG5vdyBiZWNvbWUgcGFydCBvZiB0aGUgbmV0d29yayBp dHNlbGYuICCTVGhlIG5ldHdvcmuUIGhhcyBhbHdheXMgYmVlbiBhIGZyZWUgbWFya2V0IGlu IGJ1c2luZXNzIHRlcm1zLCBidXQgd2hlbiBpdCB3YXMgZW50aXJlbHkgZGVmaW5lZCBieSBj b21tb24sIGJhc2ljIHNldCBvZiBwcm90b2NvbHMsIGl0IHJlYWxseSBkaWRuknQgbWF0dGVy IGlmIG9uZZJzIGRhdGEgZ290IGhhbmRlZCBvZmYgZnJvbSBCZWxsU291dGggdG8gTWluZHNw cmluZyB0byBVVU5ldCB0byBTcHJpbnRMaW5rIHRvIEdsb2JhbCBDcm9zc2luZyB0byBNU04g dG8gVS5TLiBXZXN0IGJlZm9yZSByZWFjaGluZyBpdHMgZGVzdGluYXRpb24uICBOZXcgdGVj aG5vbG9naWVzIHdlcmUgc2ltaWxhcmx5IGhpZGRlbiBiZWhpbmQgdGhlIHByb3RvY29sIGN1 cnRhaW4uICAoVGhlIGlubmVyIHdvcmtpbmdzIG9mIGFuIGVhcmx5IHJvdXRlciBoYWQgbGl0 dGxlIGluIGNvbW1vbiB3aXRoIHRoZSBzd2l0Y2hpbmcgZmFicmljcyBpbiBvdXIgcm91dGVy cyB0b2RheSwgYnV0IGEgVENQL0lQIHNlc3Npb24ganVzdCBydW5zIHRocm91Z2ggdGhlIG5l dyBzeXN0ZW0gZmFzdGVyLikNDUJlc3QtZWZmb3J0IG5ldHdvcmtzIGFyZSBzdWl0YWJsZSBv bmx5IGZvciBiZXN0LWVmZm9ydCBzZXJ2aWNlcy4gIEJlY2F1c2UgZnVuZGFtZW50YWwgaW5u b3ZhdGlvbnMgYXJlIG5vdyBhZGRpbmcgdXNlci12aXNpYmxlIGZ1bmN0aW9ucyB0byCTdGhl IG5ldHdvcmuUIGl0c2VsZiwgdGhlIEludGVybmV0IGlzIHN0YXJ0aW5nIHRvIGxvb2sgbGVz cyBsaWtlIGFuIGhvdXJnbGFzcyBhbmQgbW9yZSBsaWtlIGEgY29tcGxleCBjb25zdHJ1Y3Rp b24gcHJvamVjdCwgd2hlcmUgYW4gYXJteSBvZiBzdWJjb250cmFjdG9ycyBtdXN0IGJlIG1h cnNoYWxsZWQgZnJvbSBhIGRpdmVyc2UgbWFya2V0cGxhY2UgYW5kIGZvY3VzZWQgb24gYSBj b21tb24gZ29hbC4gIFdoYXQgaXMgbmVlZGVkIGlzIGEgcHJpbWUgY29udHJhY3Rvciwgd2hv IGNhbiBwcmVzZW50IGEgc2luZ2xlIGZhY2UgdG8gdGhlIGVuZCB1c2VyIGFuZCBzdWJjb250 cmFjdCBkYXRhIGRlbGl2ZXJ5IGNvbXBvbmVudHMgb24gdGhlIHVzZXKScyBiZWhhbGYuICBG dW5jdGlvbmFsbHksIHRoaXMgk3ByaW1lIGNvbnRyYWN0b3KUIGlzIGEgcG9saWN5IG1hbmFn ZXIsIGRlc2lnbmF0ZWQgYnkgdGhlIHVzZXIgdG8gcHJvdmlkZSBhIHZpcnR1YWwgcmVwbGFj ZW1lbnQgZm9yIHRoZSBuZWNrIG9mIHRoZSBJbnRlcm5ldCBob3VyZ2xhc3MuICANDUEgRGF0 YSBTZXNzaW9uIGFzIGEgQ29uc3RydWN0aW9uIENvbnRyYWN0DQ1JbiBvcmRlciBmb3IgTEFO IG1hbmFnZXJzLCBhY2Nlc3MgbmV0d29yayBwcm92aWRlcnMsIGVkZ2Ugc2VydmljZSBwcm92 aWRlcnMsIHdpZGUtYXJlYSBuZXR3b3JrcywgYW5kIGNvbnRlbnQgaG9zdGluZyBzeXN0ZW1z IHRvIHdvcmsgYXMgc3ViY29udHJhY3RvcnMgaW4gYnVpbGRpbmcgZGF0YSBkZWxpdmVyeSB0 byBhIFFvUyBzcGVjLCB0aGV5IHJlcXVpcmUgcG9saWN5IGNvbnRyb2wgdmVoaWNsZXMgKFBD VnMpIG9mIHRoZWlyIG93biB0aGF0IGNhbiBtYXAgdGhlaXIgUW9TIGltcGxlbWVudGF0aW9u cyB0byB0aGUgcGVyZm9ybWFuY2UgdGhleSBkZWxpdmVyLCBlLmcuIGluIHRlcm1zIG9mIGJh bmR3aWR0aCBhbmQgZGVsYXkgYXMgYSBmdW5jdGlvbiBvZiBwcmljZS4NDVRoZSB1c2VyknMg k3ByaW1lIGNvbnRyYWN0b3KUIG9wZXJhdGVzIHdoYXQgaXMsIGZvciB0aGF0IHVzZXIsIHRo ZSBwcmltYXJ5IHBvbGljeSBjb250cm9sIHZlaGljbGUgKFBQQ1YpLCB3aGljaCBpbnRlcmFj dHMgd2l0aCB0aGUgY29tcG9uZW50IHByb3ZpZGVyc5IgUENWcyB0byBtYWludGFpbiBuZXR3 b3JrIHN0YXRlIGluZm9ybWF0aW9uLCBwdXJjaGFzZSBzZXNzaW9uIGRlbGl2ZXJ5IGNvbXBv bmVudHMgb24gYSBwcm92aXNpb25lZCBiYXNpcyAod2l0aCBTTEFzKSwgYW5kIGV4Y2hhbmdl IHNpZ25hbGxpbmcgdG8gc2V0IHVwIHRyYW5zcG9ydCBzZWdtZW50cyB3aXRoIHNwZWNpZmll ZCBRb1MgaW4gcmVhbCB0aW1lLiAgVGhlIFBQQ1Ygd2lsbCBtYWludGFpbiBhIHVzZXIgcHJv ZmlsZSB3aXRoIHN0YXRpYyBpbmZvcm1hdGlvbiBvbiB0aGUgdXNlcpJzIGdlbmVyYWwgcHJl ZmVyZW5jZXMsIGF2YWlsYWJsZSBuZXR3b3JrIHNlZ21lbnQgcHJvdmlkZXJzLCBwcmVtaXNl IExBTiBjYXBhYmlsaXRpZXMsIGFuZCBhdmFpbGFibGUgYWNjZXNzIHNwZWVkIHVwc3RyZWFt IGFuZCBkb3duc3RyZWFtLiAgQXQgdGhlIHRpbWUgb2Ygc2Vzc2lvbiBlc3RhYmxpc2htZW50 LCB0aGUgUFBDViB3aWxsIGFsc28gbmVlZCB0byBrbm93IHRoZSBkZXNpcmVkIGFuZCBtaW5p bXVtIGFjY2VwdGFibGUgUW9TIHBhcmFtZXRlcnMgb2YgdGhlIHJlcXVlc3RlZCBkYXRhIHNl c3Npb24sIHRoZSBhY2NlcHRhYmxlIGNvc3QgbGltaXQsIGFuZCB0aGUgY2FwYWJpbGl0aWVz IG9mIHRoZSBhY2Nlc3MgZGV2aWNlIHRvIHdoaWNoIHRoZSBzZXNzaW9uIGlzIGJlaW5nIGVz dGFibGlzaGVkIChlLmcuIFBDLCBzZXQtdG9wIGJveCwgbW9iaWxlIHBob25lIG9yIFBEQSku ICBGaW5hbGx5LCBzb21lIGluZm9ybWF0aW9uIHdpbGwgYmUgbmVlZGVkIGFib3V0IHRoZSBy ZXF1aXJlbWVudHMgb2YgdGhlIGNvbnRlbnQgaXRzZWxmLCBwcm92aWRlZCBhcyBtZXRhZGF0 YSBieSB0aGUgY29udGVudCBwcm92aWRlciAoZS5nLiB2aWRlbyByZXF1aXJpbmcgYXQgbGVh c3QgNDAwIEticHMpLg0NV2hlbiB0aGUgdXNlciByZXF1ZXN0cyBhIHNlc3Npb24gYXQgYSBz cGVjaWZpZWQgc2VydmljZSBjbGFzcywgdGhlIFBQQ1YgaW50ZXJhY3RzIHdpdGggdGhlIGF2 YWlsYWJsZSCTc3ViY29udHJhY3RvcpQgUENWcyBpbiByZWFsIHRpbWUsIHF1aWNrbHkgYXJy aXZpbmcgYXQgb25lIG9mIHRoZSBmb2xsb3dpbmcgcmVzdWx0czoNDUEgZGF0YSBzZXNzaW9u IGlzIGVzdGFibGlzaGVkIGFjcm9zcyBzb21lIHNldCBvZiBuZXR3b3JrIHN1YmNvbnRyYWN0 b3JzLCBtZWV0aW5nIHRoZSBzZXNzaW9uIHNwZWNpZmljYXRpb25zIHdpdGhpbiBhY2NlcHRh YmxlIHRvbGVyYW5jZS4NSXQgaXMgZGV0ZXJtaW5lZCB0aGF0IG5vIHN1Y2ggc2Vzc2lvbiBj YW4gYmUgc2V0IHVwLCBhbmQgdGhlIHVzZXIgaXMgZ2l2ZW4gdGhlIGVxdWl2YWxlbnQgb2Yg YSBidXN5IHNpZ25hbC4NTm8gc2Vzc2lvbiBjYW4gYmUgc2V0IHVwIHRoYXQgbWVldHMgdGhl IHNwZWNzLCBidXQgYSBzZXQgb2YgIJNuZWFyLW1pc3OUIGFsdGVybmF0aXZlcyBhcmUgaWRl bnRpZmllZCBhbmQgcHJlc2VudGVkIHRvIHRoZSB1c2VyIGZvciBhIGRlY2lzaW9uLg0NSW4g dGhpcyBtb2RlbCwgdGhlIGRlbGl2ZXJ5IGNoYWluIHNlZ21lbnRzIHNob3duIGluIEZpZ3Vy ZSAyIG9wZXJhdGUgYXMgZm9sbG93czoNDQ1QcmVtaXNlIG5ldHdvcmsNTWFwcyBlYWNoIHNl c3Npb24gdG8gYSBRb1MgcmVxdWVzdCBpbiB0ZXJtcyBvZiBhIHN0YW5kYXJkLCBmaW5pdGUg c2V0IG9mIHNlcnZpY2UgY2xhc3NlcyAoUW9TIHBhY2thZ2VzKQ1JbnRlcmFjdHMgd2l0aCB0 aGUgUFBDVg1SZXF1ZXN0cyB0aGUgY2xhc3Mgb2Ygc2VydmljZSBmcm9tIFBQQ1YNUmVjZWl2 ZXMgZnJvbSB0aGUgUFBDViBlaXRoZXIgYSBjb25maXJtYXRpb24gb2YgdGhlIGNsYXNzIG9m IHNlcnZpY2Ugb3IgYSBtZXNzYWdlIHRoYXQgdGhlIG5lZWRlZCBjbGFzcyBvZiBzZXJ2aWNl IGlzIHVuYXZhaWxhYmxlLg1JZiB0aGUgcmVxdWVzdGVkIHNlcnZpY2UgY2xhc3MgaXMgdW5h dmFpbGFibGUsIHRoZSBQUENWIG1heSBvZmZlciBhIHNldCBvZiBhbHRlcm5hdGl2ZXM7IGku ZS4gbmVnb3RpYXRlIGEgZmVhc2libGUgc2VydmljZSBjb250cmFjdCB3aXRoIHRoZSBlbmQt dXNlci4gDVRoZSBwcmVtaXNlIG5ldHdvcmsgY29ubmVjdHMgZGlyZWN0bHkgdG8gYW4gQWNj ZXNzIE5vZGUgbG9jYXRlZCBpbiB0aGUgQWNjZXNzIE5ldHdvcmsNDUFjY2VzcyBOZXR3b3Jr DVdpdGhpbiB0aGUgQWNjZXNzIE5ldHdvcmssIEFjY2VzcyBOb2RlcyBwcm92aWRlIHRoZSBw aHlzaWNhbCBjb25uZWN0aW9uIHRvIHRoZSBjdXN0b21lciBwcmVtaXNlIG5ldHdvcmsuICBJ biB0aGUgYWNjZXNzIG5ldHdvcmssIGRhdGEgaXMgdHJhbnNwb3J0ZWQgdGhyb3VnaCBvbmUg b3IgbW9yZSBUcmFuc2l0IE5vZGVzLCB0byBhIFNlcnZpY2UgTm9kZSBsb2NhdGVkIGF0IGFu IEVkZ2UgQ2VudGVyLg1UaGUgYWNjZXNzIG5ldHdvcmsgaXMgcmVzcG9uc2libGUgZm9yIHRy YW5zcG9ydGluZyB0aGUgZGF0YSBmcm9tIHRoZSBBY2Nlc3MgTm9kZSB0byB0aGUgU2Vydmlj ZSBOb2RlLCB3aGlsZSBtZWV0aW5nIEFjY2VzcyBOZXR3b3JrIFFvUyByZXF1aXJlbWVudHMu DVRoZSBhY2Nlc3MgbmV0d29yayBtYXkgcHJvdmlkZSBwZXItc2Vzc2lvbiB0dW5uZWxsaW5n IGZyb20gdGhlIHByZW1pc2UgbmV0d29yayB0byB0aGUgU2VydmljZSBOb2RlLiAgVHVubmVs cyBpc29sYXRlIHRyYWZmaWMgZnJvbSBzZXNzaW9ucyB3aXRoIGRpZmZlcmVudCByZXF1aXJl bWVudHMgYW5kL29yIGZyb20gZGlmZmVyZW50IHVzZXJzLCBmb3IgUW9TIGVuZm9yY2VtZW50 IGFuZCBiaWxsaW5nIHB1cnBvc2VzLg1UdW5uZWxzIG1heSBiZSBhZ2dyZWdhdGVkIHVzaW5n IGVpdGhlciBUaW1lLURpdmlzaW9uLU11bHRpcGxleGluZyAoVERNKSBvciBRb1MgYXdhcmUg cGFja2V0L2NlbGwgbXVsdGlwbGV4aW5nLg1BIHNpbmdsZSBlbmQtdXNlciBtYXkgYmUgY29u bmVjdGVkIHRvIG11bHRpcGxlIGFjY2VzcyBuZXR3b3JrcyAoZS5nLiBBRFNMIGFuZCBEQlMp LCB3aGljaCBtYXkgaGF2ZSBkaWZmZXJlbnQgcHJvdmlkZXJzIGFuZCByZXF1aXJlIHRyYW5z cG9ydCB0byBkaWZmZXJlbnQgU2VydmljZSBOb2RlcyBwb3NzaWJseSBhdCBkaWZmZXJlbnQg RWRnZSBDZW50ZXJzLiAgVGhlIFBQQ1Ygd2lsbCBpZGVhbGx5IG9wdGltaXplIHRoZSB1c2Ug b2YgdGhlc2UgYWNjZXNzIG5ldHdvcmtzLCBiYXNlZCBvbiB0aGUgdXNlcpJzIHByb2ZpbGUu ICBBcHByb3ByaWF0ZSBzaWduYWxsaW5nIG1ldGhvZHMgd2lsbCBiZSByZXF1aXJlZCB0byBz ZXQgdXAgYW5kIGFja25vd2xlZGdlIHRoZSByZXF1aXJlZCBRb1MuDQ1FZGdlIGNlbnRlcg1U aGUgRWRnZSBDZW50ZXIgaXMgYSBTZXJ2aWNlIFBlZXJpbmcgUG9pbnQuICBTZXJ2aWNlIE5v ZGVzIGxvY2F0ZWQgYXQgdGhlIEVkZ2UgQ2VudGVyIHBlZXIgd2l0aCBzZXJ2aWNlIGRlbGl2 ZXJ5IGVudGl0aWVzIGluIHRoZSBBY2Nlc3MgTm9kZS4NVGhlIEVkZ2UgQ2VudGVyIGlzIGEg ZGF0YSBhZ2dyZWdhdGlvbiBwb2ludCB0aGF0IG1heSBzZXJ2ZSBtdWx0aXBsZSBhY2Nlc3Mg bmV0d29ya3MgYW5kIGhhdmUgY29ubmVjdGlvbnMgdG8gbXVsdGlwbGUgd2lkZS1hcmVhIG5l dHdvcmtzLg1Rb1MtcmVsYXRlZCBmdW5jdGlvbnMgdGhhdCBjYW4gYmUgcGVyZm9ybWVkIGF0 IHRoaXMgbmV0d29yayBjb21wb25lbnQgaW5jbHVkZSBpbnRlbGxpZ2VudCBzZXNzaW9uIGFn Z3JlZ2F0aW9uIGFuZCBmaWx0ZXJpbmcsIGxvYWQgYmFsYW5jaW5nLCBzZWxlY3Rpb24gb2Yg ZGF0YSBzb3VyY2UgYW1vbmcgbG9jYWwgY2FjaGVzLCBzZXJ2ZXJzLCBldGMuIGFuZCBtdWx0 aXBsZSBXQU5zLg1TZXJ2aWNlIE1hbmFnZW1lbnQgaW5jbHVkaW5nIGF1dGhlbnRpY2F0aW9u LCBhdXRob3JpemF0aW9uIGFuZCBhY2NvdW50aW5nIChBQUEpIGNhbiBiZSBjYXJyaWVkIG91 dCBhdCB0aGUgRWRnZSBDZW50ZXIuICANVGhlIEVkZ2UgQ2VudGVyIG1heSBhbHNvIHByb3Zp ZGUgdGhlIE5vcnRoIEJvdW5kIEludGVyZmFjZSB0byB0aGUgT3BlcmF0aW9ucyBTdXBwb3J0 IFN5c3RlbXMgKE9TUykgcmVxdWlyZWQgdG8gbWFuYWdlIHRoZSBBY2Nlc3MgTmV0d29yay4g DUEgU2VydmljZSBOb2RlIGF0IGFuIEVkZ2UgQ2VudGVyIG1heSBkaXN0cmlidXRlIGFuZCBy ZWFnZ3JlZ2F0ZSBkYXRhIGZvciBvbmUgb3IgbW9yZSB3aWRlIGFyZWEsIG1ldHJvIGNvcmUg b3Igc3BlY2lhbCBzZXJ2aWNlIG5ldHdvcmtzLiAgRm9yIGV4YW1wbGUgdGhlIFNlcnZpY2Ug Tm9kZSBtYXkgaW50ZXJmYWNlIHdpdGggdGhlIEludGVybmV0LCBwcml2YXRlIGludHJhbmV0 cyAoVlBOcyksIHRoZSBQU1ROIG5ldHdvcmssIEFUTSBuZXR3b3JrcyBhbmQgTVBMUyBuZXR3 b3Jrcy4NVGhlIFNlcnZpY2UgTm9kZSBhdCB0aGUgRWRnZSBDZW50ZXIgY2FuIHByb3ZpZGUg dHJhZmZpYyBlbmdpbmVlcmluZyBvZiBhZ2dyZWdhdGVzIHRvIG1lZXQgdGhlIEVuZC10by1F bmQgUW9TIG5lZWRzIGZvciB0aGUgY29tcG9uZW50IGZsb3dzLiAgTmVnb3RpYXRpb24gd2l0 aCB0aGUgV0FOIG1heSBiZSBhY2NvbXBsaXNoZWQgdXNpbmcgZWl0aGVyIHNpZ25hbGxpbmcg b3IgdGhlIG1hbmFnZW1lbnQgaW50ZXJmYWNlLg0NV2lkZS1hcmVhIG5ldHdvcmtzDU11bHRp cGxlIFdBTnMgYW5kIFdBTiBzZXJ2aWNlIGNvbnRyYWN0cyBtYXkgYmUgYXZhaWxhYmxlIGZv ciBkYXRhIGRlbGl2ZXJ5DVFvUyBpbXBsZW1lbnRhdGlvbnMgYXQgdGhpcyBsZXZlbCBpbmNs dWRlIHRoZSBzZWxlY3Rpb24gb2YgYSBzdGF0aWMgV0FOIGludGVyZmFjZSB3aXRoIGtub3du IFFvUyBjaGFyYWN0ZXJpc3RpY3MgYW5kIGxvYWRpbmcsIHNpZ25hbGxpbmcgdG8gV0FOcyB3 aXRoIGR5bmFtaWMgUW9TIGNhcGFiaWxpdGllcywgYW5kIHRoZSBpbXBsZW1lbnRhdGlvbiBv ZiBsb2FkIGxpbWl0cyBvbiBzcGVjaWZpYyBXQU4gY29ubmVjdGlvbnMuDVRoZSBJbnRlcm5l dCBpcyBvbmx5IG9uZSBvZiB0aGUgV0FOIG9wdGlvbnMuICBPdGhlciB0eXBlcyBvZiBkYXRh IG5ldHdvcmsgbWF5IGJlIGVtcGxveWVkLCBvciB0aGUgZGF0YSBjYW4gYmUgY2FycmllZCBv biBhIHByaXZhdGUgbGluZS4gIEluIHRoZSBzaW1wbGVzdCBjYXNlLCB0aGUgZGF0YSBpcyBh dmFpbGFibGUgZnJvbSBhIGxvY2FsIGNhY2hlIG9yIHNlcnZlciBhbmQgbm8gV0FOIGlzIGVt cGxveWVkLg0NUHJpbWFyeSBob3N0aW5nIHN5c3RlbQ1JbiBhIHRyYWRpdGlvbmFsIGhvc3Rp bmcgY29uZmlndXJhdGlvbiwgdHJhZmZpYyBpcyBsb2FkLWJhbGFuY2VkIGFtb25nIHNlcnZl cnMgd2l0aCBkaXJlY3RseSBhdHRhY2hlZCBzdG9yYWdlLg1JbiBhbiBpbnRlbGxpZ2VudCBz dG9yYWdlLWFyZWEgbmV0d29yayAoU0FOKSwgYSBwb29sIG9mIHN0b3JhZ2UgZGV2aWNlcyBp cyBpbnRlcmNvbm5lY3RlZCBvbiBhIGZhc3QgY29ubmVjdGlvbiBzeXN0ZW0sIGFuZCB0aGUg k3NlcnZlcnOUIGFyZSBzaW1wbGUgZGV2aWNlcyB0aGF0IHByb3ZpZGUgcG9ydCBjb25uZWN0 aW9ucyB0byB0aGUgc3lzdGVtLg1Cb3RoIGZvcm1zIG9mIHByaW1hcnkgc3RvcmFnZSBjb3Vs ZCBiZSBlaXRoZXIgY2VudHJhbGl6ZWQgaW4gYSBzaW5nbGUgZGF0YSBjZW50ZXIgb3IgbWFp bnRhaW4gbWlycm9yZWQgY29waWVzIG9mIHRoZSBkYXRhIGF0IG11bHRpcGxlIGdlb2dyYXBo aWMgbG9jYXRpb25zLCBvbiBtdWx0aXBsZSBXQU5zIChvciwgaW4gc29tZSBjYXNlcywgYXQg ZWRnZSBjZW50ZXJzKS4NDVRoZSByZWxhdGlvbnNoaXAgb2YgdGhlc2UgZGVsaXZlcnkgY2hh aW4gc2VnbWVudHMgdG8gdGhlIFBQQ1YgaXMgc2hvd24gaW4gRmlndXJlIDkuDQ0NDQ0NDVdo YXQgU3RhbmRhcmRzIEFyZSBOZWVkZWQgdG8gRW5hYmxlIFRoaXMgTW9kZWw/DVNlcnZpY2Ug Y2xhc3MgZGVmaW5pdGlvbnMgYW5kIHNwZWNpZmljYXRpb24gcHJvdG9jb2wNDUl0IHdvdWxk IGJlIGluZmVhc2libGUgdG8gbWFuYWdlIHRoZSBwcm9jZXNzIGRlc2NyaWJlZCBhYm92ZSB3 aXRoIGFuIGluZmluaXRlIHJhbmdlIG9mIFFvUyBwYXJhbWV0ZXJzLCBzbyB0aGVyZSBpcyBj bGVhcmx5IGEgbmVlZCBmb3IgYSBmaW5pdGUgc2V0IG9mIHN0YW5kYXJkIHNlcnZpY2UgY2xh c3Nlcywgb3IgUW9TIHBhcmFtZXRlciBwYWNrYWdlcywgZm9yIHRoZSBQUENWIHRvIGNvbnN0 cnVjdC4gIFRoZSBlbmQgdXNlciAob3IgdGhlIGVuZCB1c2VyknMgc29mdHdhcmUpIHNob3Vs ZCBiZSByZXNwb25zaWJsZSBmb3Igc2VsZWN0aW5nIHRoZSBzZXJ2aWNlIGNsYXNzIHJlcXVl c3QsIGUuZy4gYmFzZWQgb24gdGhlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgYXBwbGljYXRp b24gYW5kIGEgcHJlZmVyZW5jZSBwcm9maWxlLiAgVGhlIHJlcXVlc3Qgc2hvdWxkIHNwZWNp ZnkgYSBkZXNpcmVkIGFuZCBtaW5pbXVtLWFjY2VwdGFibGUgc2VydmljZSBjbGFzcywgc28g dGhhdCB0aGUgUFBDViBjYW4gcnVuIGEgY29uc2lzdGVuY3kgY2hlY2sgb2YgdGhlIHJlcXVl c3QgYWdhaW5zdCBhdmFpbGFibGUgbmV0d29yayBpbmZvcm1hdGlvbiBhbmQgdGhlIGNvbnRl bnQgbWV0YWRhdGEsIHRvIHJlc29sdmUgdGhlIHNlcnZpY2UgY2xhc3MgcmVxdWVzdCB0byBh IGZlYXNpYmxlIGFsdGVybmF0aXZlIG9yIGVsc2UgcmVwb3J0IGNvbm5lY3Rpb24gZmFpbHVy ZSB0byB0aGUgdXNlci4NDVBhcmFtZXRlcnMgc3BlY2lmaWVkIGJ5IHRoZSBzdGFuZGFyZCBl bmQtdG8tZW5kIHNlcnZpY2UgY2xhc3NlcyAoaS5lLiB0aGUgc3BlY2lmaWNhdGlvbnMgcHJv dmlkZWQgYnkgdGhlIGVuZC11c2VyIHdoZW4gc3Vic2NyaWJpbmcgdG8gYW4gU0xBIG9yIHNp Z25hbGxpbmcgZm9yIGEgc2Vzc2lvbiBpbiByZWFsIHRpbWUpIG1heSBpbmNsdWRlIGFueSBv ZiB0aGUgZm9sbG93aW5nOg0NQmFuZHdpZHRoDUNvbW1pdHRlZCBtaW5pbXVtIGJhbmR3aWR0 aA1BbGxvd2FibGUgYnVyc3QgcmF0ZQ1EZWxheSBDaGFyYWN0ZXJpc3RpY3MNTWF4aW11bSBz ZXQtdXAgdGltZQ1NYXhpbXVtIGRlbGF5DU1heGltdW0gZGVsYXkgdmFyaWFuY2UNUHJpb3Jp dHkNW1N0YW5kYXJkIHNldCBvZiBwcmlvcml0eSBsZXZlbHNdDQ1Qb2xpY3kgQ29udHJvbCBW ZWhpY2xlIHN0YW5kYXJkcyBmb3IgZWFjaCBkYXRhIGRlbGl2ZXJ5IHNlZ21lbnQNDVRoZSBQ Q1YgZm9yIGVhY2ggc2VnbWVudCBtdXN0IHByb3ZpZGU6DQ1NZWNoYW5pc21zIHRvIGVzdGFi bGlzaCBRb1MgbWFuYWdlZCBwYXRocyB3aXRoaW4gdGhlIGRvbWFpbg0NTWVjaGFuaXNtcyB0 byBleGNoYW5nZSBwYXRoIGluZm9ybWF0aW9uIHdpdGggb3RoZXJzIG91dHNpZGUgdGhlIGRv bWFpbiAob3RoZXIgbmV0d29ya3Mgb3Igb3RoZXIgk3Nlc3Npb24gb3duZXJzlCkNSWYgcmVh bC10aW1lLCB2aWEgYSBzaWduYWxsaW5nIHByb3RvY29sIHRoYXQgc3VwcG9ydHMgc2Vzc2lv biBzZXQtdXAsIGFja25vd2xlZGdlbWVudCwgYW5kIHRha2UtZG93bg0NQSBtZWFzdXJlbWVu dCBtZXRob2QgdG8gdmFsaWRhdGUgdGhhdCB0aGUgY29tbWl0dGVkIFFvUyBpcyBkZWxpdmVy ZWQuDVJlcXVpcmVkIGZvciBTTEFzDURlc2lyYWJsZSBhdCB0aGUgc2Vzc2lvbiBsZXZlbA0N U2Vzc2lvbiBkZXRhaWwgYWNjb3VudGluZywgdG8gc3VwcG9ydCBiaWxsaW5nIGFuZCBzZXR0 bGVtZW50cw1EZXNpcmFibGUgdG8gaGF2ZSBhbiBhdWRpdGluZyBtZWNoYW5pc20gdG8gbWFr ZSBiaWxsaW5nIG5vbi1yZWZ1dGFibGUNDVRoZSBQUENWIGFsc28gcmVxdWlyZXMgc3RhbmRh cmQgcHJvdG9jb2xzIGZvciBpbnRlcmFjdGlvbiB3aXRoIHRoZSBlbmQtdXNlciBhbmQgdmFs aWRhdGlvbiBvZiBlbmQtdG8tZW5kIFFvUyBjb21taXRtZW50cy4NDVNvbWUgSW1wbGVtZW50 YXRpb24gSXNzdWVzDUhvdyBjYW4gd2Ugc2lnbmFsIGJhbmR3aWR0aCByZXF1ZXN0cyBpbiBh biBJUCBuZXR3b3JrPw1UaGUgUlNWUCBhbmQgKGV4KSBpbnRzZXJ2IFdHIGluIHRoZSBJRVRG IGRldmVsb3BlZCBwcm90b2NvbHMgZm9yIHJlc2VydmluZyBiYW5kd2lkdGggZm9yIGEgZ2l2 ZW4gSVAgZmxvdy4gRHVyaW5nIGZsb3cgc2V0dXAsIHRoZSBiYW5kd2lkdGggcmVxdWlyZW1l bnRzIGFyZSBzaWduYWxlZCBhbmQgZWFjaCBpbnRlcnZlbmluZyBub2RlIHJlc2VydmVzIHN1 ZmZpY2llbnQgcmVzb3VyY2VzIGluIG9yZGVyIHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50Lg0N SG93IGRvIG5vbi1JUCBkZXZpY2VzIChlZyBEU0xBTXMpIGtub3cgaG93IG11Y2ggYmFuZHdp ZHRoIHRvIHJlc2VydmU/DUFsbCBvZiB0aGUgYWJvdmUgZGVzY3JpYmVzIGFuIGVuZC10by1l bmQgcmVzZXJ2YXRpb24gc29sdXRpb24sIGJ1dCB0eXBpY2FsbHkgdGhlIHN1YnNjcmliZXIg J2VuZCcgaXMgbm90IHRoZSBzdWJzY3JpYmVyIFBDIGJ1dCB0aGUgYWNjZXNzIG5vZGUgdG8g d2hpY2ggaGUgaXMgY29ubmVjdGVkLiBUaHVzIHdlIG5lZWQgc29tZSB3YXkgb2YgcmVzZXJ2 aW5nIGJhbmR3aWR0aCBpbiB0aGUgJ2xhc3QgbWlsZScgdG8gdGhlIHN1YnNjcmliZXIuIFR5 cGljYWxseSB0aGlzIG1lYW5zIGNvbnRyb2xsaW5nIGJhbmR3aWR0aCBpbiBhIERTTEFNIG9y IENNIEhlYWQtRW5kLCBhbmQgcG90ZW50aWFsbHkgbWFuYWdpbmcgY29udGVudGlvbiBiZXR3 ZWVuIGRldmljZXMgb24gc2hhcmVkIG1lZGlhLCBzdWNoIGFzIGEgY2FibGUgbW9kZW0gb3Ig ZXRoZXJuZXQgaW5mcmFzdHJ1Y3R1cmUuIEluIHRoZSBmb3JtZXIgY2FzZSBRb1MgbWVjaGFu aXNtcyBhcmUgb2Z0ZW4gYXZhaWxhYmxlLCBidXQgdGhleSBuZWVkIHRvIGJlIGR5bmFtaWNh bGx5IGNvbnRyb2xsZWQgYXMgZGVzY3JpYmVkIGFib3ZlIGZvciB0aGUgb3RoZXIgY29tcG9u ZW50cy4gSW4gdGhlIGxhdHRlciBjYXNlLCB0aGUgc29sdXRpb24gbWF5IGJlIHRvIHVzZSB1 cC1zdHJlYW0gc2hhcGluZyB0byBjb250cm9sIHBhY2tldCBhZ2dyZWdhdGlvbiBvciB0byBs aW1pdCB0aGUgdXNlIG9mIHNoYXJlZCBzZWdtZW50cy4gVXAtc3RyZWFtIGFkbWlzc2lvbiBj b250cm9sIGFuZCBzaGFwaW5nIG1heSBiZSBzdWZmaWNpZW50IHRvIHNlZ3JlZ2F0ZSB0cmFm ZmljIGluIHNvbWUgY2FzZXM7IGluIG90aGVyIGNhc2VzLCBsaW1pdGluZyBjb250ZW50aW9u IGFuZCBvdmVyIHByb3Zpc2lvbmluZyBvZiBiYW5kd2lkdGggbWF5IHRoZSBvbmx5IHNvbHV0 aW9uLg0NV2hhdCBkbyB3ZSBkbyBpZiB0aGUgYmFuZHdpZHRoIHJlcXVlc3QgY2Fubm90IGJl IHNhdGlzZmllZD8NICBJZiB0aGVyZSBpcyBubyBzdWl0YWJsZSBwYXRoIHRocm91Z2ggdGhl IG5ldHdvcmsgdGhhdCBjYW4gc2F0aXNmeSB0aGUgYmFuZHdpZHRoIHJlcXVlc3QsIHRoZW4g dGhlIG9yaWdpbmF0aW5nIGRldmljZSB3aWxsIGJlIHVuYWJsZSB0byBjb21wbGV0ZSB0aGUg cmVzZXJ2YXRpb24gcmVxdWVzdC4gSW4gYSBjb250ZW50IGRlbGl2ZXJ5IHNjZW5hcmlvLCB0 aGlzIGluZm9ybWF0aW9uIG5lZWRzIHRvIGJlIGNvbW11bmljYXRlZCB0byB0aGUgdXNlciwg YW5kIGEgZGVjaXNpb24gbWFkZSBhYm91dCBob3cgdG8gcHJvY2VlZC4gT3B0aW9ucyBtYXkg YmUgdG8gY2FuY2VsIHRoZSBhdHRlbXB0LCBvciB0byBhY2NlcHQgYSBsb3dlci1ncmFkZSBj b3B5IG9mIHRoZSBjb250ZW50IHRoYXQgaGFzIGxvd2VyIGJhbmR3aWR0aCByZXF1aXJlbWVu dHMuIFRoaXMgbmVjZXNzaXRhdGVzIHNvbWUgaW50ZWxsaWdlbmNlIGluIHRoZSBvcmlnaW5h dGluZyBkZXZpY2UgdG8ga25vdyB3aGF0IGFsdGVybmF0aXZlcyBhcmUgYXZhaWxhYmxlIGFu ZCB0byBjb21tdW5pY2F0ZSB0aGlzIGluZm9ybWF0aW9uIHRvIHRoZSB1c2VyLiANV2hhdCBp ZiBzdWJzY3JpYmVyIG5lZWRzIHRvIGNoYW5nZSBoaXMgc3Vic2NyaXB0aW9uIGZvciB0aGlz IHNlc3Npb24/DUluIHNvbWUgY2FzZXMsIHRoZSBzdWJzY3JpYmVyIG1heSBoYXZlIGEgYmFu ZHdpZHRoIGNvbnRyYWN0IHdpdGggaGlzL2hlciBBY2Nlc3MgUHJvdmlkZXIgdGhhdCBjYW5u b3Qgc3VwcG9ydCBkZWxpdmVyeSBvZiB0aGUgY29udGVudCB3aXRoIGFwcHJvcHJpYXRlIFFv Uy4gSW4gdGhpcyBjYXNlLCB0aGUgY2xpZW50IHNob3VsZCBiZSBpbmZvcm1lZCBvZiB0aGlz IGFuZCBvbmUgb2YgdGhlIGZvbGxvd2luZyBtYXkgaGFwcGVuOg0NMS4gVGhlIHN1YnNjcmli ZXIgYWJvcnRzIHRoZSBkb3dubG9hZA0yLiBUaGUgc3Vic2NyaWJlciB0ZW1wb3JhcmlseSBv ciBwZXJtYW5lbnRseSBpbmNyZWFzZXMgaGlzIGNvbnRyYWN0IHdpdGggdGhlIGFjY2VzcyBw cm92aWRlcg0zLiBUaGUgc3Vic2NyaWJlciBhY2NlcHRzIGEgbG93ZXIgZ3JhZGUgdmVyc2lv biBvZiB0aGUgY29udGVudA00LiBFaXRoZXIgb2YgICgyKSBvciAoMykgaGFwcGVucyBhdXRv bWF0aWNhbGx5Lg0NSW4gYW55IGNhc2UsIHRoZXJlIGlzIGFnYWluIGEgcmVxdWlyZW1lbnQg dG8gaGF2ZSBzb21lIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgYmFuZHdpZHRoIHJlc2Vy dmF0aW9uIGVuZHBvaW50IGFuZCB0aGUgdXNlciBhbmQgaXQgaXMgZXhwZWN0ZWQgdGhhdCB0 aGlzIHdvdWxkIGJlIHZpYSBhbiBpbnRlbGxpZ2VudCBhY2Nlc3MgY29uY2VudHJhdG9yLg0M CAgICAgMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgMCAgICAgMCAgICAwI CAgIDAgICAgMCAgICAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgI DQIgIEl0IGlzIG5vdCB1bnVzdWFsIGZvciBwcml2YXRlIG5ldHdvcmtzIHRoYXQgYXJlIGRl c2lnbmVkIHdpdGggYSBnb29kIG1hcmdpbiBmb3IgcGVhayB0cmFmZmljIGxvYWRzIHRvIG9w ZXJhdGUgYXQgYW4gYXZlcmFnZSBvY2N1cGFuY3kgYXJvdW5kIDUlLg0NQkNEIEZvcnVtIElu ZnJhc3RydWN0dXJlIFdvcmtpbmcgR3JvdXAgZHJhZnQgZG9jdW1lbnQgliAxOSBGZWJydWFy eSAyMDAxDQ0NRmlndXJlIDINDUtub3dsZWRnZSBvZiBzZXNzaW9uIHJlcXVpcmVtZW50cyBp cyBvbmx5IGd1YXJhbnRlZWQgdG8gYmUgYXZhaWxhYmxlIGF0IHRoZSB1c2VyIGRldmljZSAm IHByaW1hcnkgaG9zdC4NDUNvbG9yIEtleToNIHBvc3NpYmxlIGNvbnRlbnRpb24NIG1hbmFn ZWQgY29udGVudGlvbg0gdHlwaWNhbGx5IHVubWFuYWdlZCBjb250ZW50aW9uDQ1XaWRlLUFy ZWEgTmV0d29yayAmIEhvc3RpbmcNDVByZW1pc2UgTmV0d29yaw0NQWNjZXNzIE5ldHdvcmsN DUVkZ2UgQ2VudGVyDQ1Mb2NhbCBDb250ZW50IFNlcnZlcg0NSW50ZXJuZXQNDVByaW1hcnkg Q29udGVudC9TZXJ2aWNlIEhvc3RpbmcNDVNlc3Npb24gQWdncmVnYXRvcg0NVHJ1bmsvTUFO DQ1BY2Nlc3MgQ29uY2VudHJhdGlvbiBOb2RlDQ1BY2Nlc3MgTWVkaXVtDQ1JQUQNDUhvbWUv T2ZmaWNlIExBTg0NVXNlciBEZXZpY2UNDURlbGl2ZXJ5IENoYWluDQ0qIE5vdGU6ICBPdmVy LWNhcGFjaXR5IGlzIGEgdW5pdmVyc2FsIJNRb1Mgb3B0aW9ulCB0aGF0IGlzIGltcGxpY2l0 IGluIHRoaXMgYW5kIHRoZSBmb2xsb3dpbmcgdGFibGVzLg0NS2V5IGlzc3VlczoNbWFwcGlu ZyBhcHBsaWNhdGlvbnMgdG8gYXBwcm9wcmlhdGUgUW9TDW1hcHBpbmcgUW9TIHRvIHByZW1p c2UgdHJhbnNwb3J0IGNvbnRyb2wNbWFwcGluZyBiZXR3ZWVuIHByZW1pc2UgUW9TIGNvbnRy b2wgYW5kIFdBTiBRb1MgY29udHJvbA0NQ29uZmlndXJhdGlvbg0NQ29udGVudGlvbg0NUW9T IE9wdGlvbnMqDQ1Db250cm9sIEluZm8gQXQNDVN0YXINDUNvbmN1cnJlbnQgcHJvY2Vzc2Vz IGZyb20gZGV2aWNlDQ1JUCBwb3J0IG1hcHBpbmcsIFZMQU4sIEFUTSwgSVAgUW9TIChlLmcu IERpZmZTZXJ2LCBNUExTKQ0NRW5kIGRldmljZSAmIElBRA0NTEFODQ1NdWx0aXBsZSBkZXZp Y2VzDQ1MQU4gcHJpb3JpdHk7IElQIHBvcnQgbWFwcGluZywgVkxBTiwgSVAgUW9TLCBvciBB VE0gYXQgSUFEDQ1FbmQgZGV2aWNlLCBMQU4gY29udHJvbGxlciwgJiBJQUQNDVByZW1pc2Ug TmV0d29yaw0NRmlndXJlIDMNDUZpZ3VyZSA0DQ1LZXkgaXNzdWU6DUNvbW11bmljYXRpbmcg UW9TIGNvbnRyb2wgdG8gYWNjZXNzIGNvbmNlbnRyYXRpb24gbm9kZSBvciBkYXRhIHN3aXRj aA0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1BY2Nlc3MgTmV0d29yaw0NRmlndXJlIDUNDUtleSBp c3N1ZXM6DUNvbW11bmljYXRpbmcgUW9TIGNvbnRyb2wgdG8gYWdncmVnYXRpb24gZGV2aWNl DU1hcHBpbmcgZGlmZmVyZW50IFFvUyBtZWNoYW5pc21zIGFtb25nIGFjY2VzcyBuZXR3b3Jr cyBhbmQgV0FOcw0NQ29uZmlndXJhdGlvbg0NQ29udGVudGlvbg0NUW9TIE9wdGlvbnMNDUNv bnRyb2wgSW5mbyBBdA0NU2ltcGxlIGRhdGEgY29uY2VudHJhdG9yDQ1EYXRhIGNvbmNlbnRy YXRvciAmIEludGVybmV0IHRydW5rcw0NUW9TIG1lY2hhbmlzbXMgaW4gY29uY2VudHJhdG9y IChlLmcuIE1QTFMpDQ1EYXRhIGNvbmNlbnRyYXRvcg0NU2Vzc2lvbiBhZ2dyZWdhdG9yIHdp dGggbG9jYWwgcmVzb3VyY2VzIChlLmcuIENETnMpDQ1TZXNzaW9uIGFnZ3JlZ2F0b3I7IGxv Y2FsIHNlcnZlcnM7IHBvcnRzIHRvIEludGVybmV0DQ1TZXNzaW9uIGFnZ3JlZ2F0b3IgbWVj aGFuaXNtczsgQ0ROIG1hbmFnZW1lbnQ7IGNvbnRlbnQgcGVlcmluZyBwcm90b2NvbHMNDVNl c3Npb24gYWdncmVnYXRvciAmIENETnMNDURhdGEgc3dpdGNoIG9yIHNlc3Npb24gYWdncmVn YXRvciB3aXRoIG1hbmFnZWQgV0FOcw0NU3dpdGNoIG9yIHNlc3Npb24gYWdncmVnYXRvcjsg V0FODQ1Rb1MgbWVjaGFuaXNtcyBpbiBjb25jZW50cmF0b3Igb3Igc2Vzc2lvbiBhZ2dyZWdh dG9yOyBXQU4gc2VsZWN0aW9uICYgbWd0Lg0NU3dpdGNoIG9yIHNlc3Npb24gYWdncmVnYXRv cg0NRWRnZSBDZW50ZXINDUZpZ3VyZSA2DQ1LZXkgaXNzdWU6DUNvb3JkaW5hdGlvbiBvZiBR b1MgbWFuYWdlbWVudCBhbW9uZyBtdWx0aXBsZSBuZXR3b3JrcyB3aGljaCBtYXkgdXNlIGRp ZmZlcmVudCBzdGFuZGFyZHMNDUNvbmZpZ3VyYXRpb24NDUNvbnRlbnRpb24NDVFvUyBPcHRp b25zDQ1Db250cm9sIEluZm8gQXQNDUludGVybmV0IJYgc2luZ2xlIGJhY2tib25lIGNhcnJp ZXINDUJhY2tib25lIG5ldHdvcmsNDUlQIFFvUzsgY2FjaGluZyBvciBtaXJyb3JpbmcgYXQg YmFja2JvbmUgbm9kZXMNDUJhY2tib25lIGNhcnJpZXI7IGFmZmlsaWF0ZWQgb3IgY29sbG9j YXRlZCBob3N0aW5nIGNlbnRlcnMgJiBDRE5zDQ1JbnRlcm5ldCCWIG11bHRpcGxlIGJhY2ti b25lIGNhcnJpZXJzDQ1CYWNrYm9uZSAgbmV0d29ya3M7IGV4Y2hhbmdlIHBvaW50cw0NQ29v cmRpbmF0ZWQgSVAgUW9TIG1lY2hhbmlzbXMgYW1vbmcgY2FycmllcnMgJiBleGNoYW5nZSBw b2ludHM7IHNlcnZlciByZXBsaWNhdGlvbiAmIENETnMNDU11bHRpcGxlIGNhcnJpZXJzOyBl eGNoYW5nZSBwb2ludHM7IGRpc3RyaWJ1dGVkIGhvc3Rpbmcgc2VydmljZXM7IENETnMNDUV4 dHJhbmV0DQ1FeHRyYW5ldCBmYWNpbGl0aWVzDQ1BbnkgY29tYmluYXRpb24gb2YgbGF5ZXIg MyBRb1MgbWVjaGFuaXNtcyAmIHNlcnZlciByZXBsaWNhdGlvbiBpbiBiYWNrYm9uZQ0NRXh0 cmFuZXQgY2FycmllcjsgYWZmaWxpYXRlZCBvciBjb2xsb2NhdGVkIGhvc3RpbmcgY2VudGVy cyAmIENETnMNDVdpZGUtQXJlYSBOZXR3b3Jrcw0NRmlndXJlIDcNDUtleSBpc3N1ZXM6DVF1 ZXJ5aW5nIGhvc3QgZGF0YSBmb3IgY29udGVudC1kcml2ZW4gUW9TIHJlcXVpcmVtZW50cw1Q cm92aWRpbmcgUW9TIGNvbnRyb2wgc2lnbmFsaW5nIHRvIGhvc3Rpbmcgc3lzdGVtDQ1Db25m aWd1cmF0aW9uDQ1Db250ZW50aW9uDQ1Rb1MgT3B0aW9ucw0NQ29udHJvbCBJbmZvIEF0DQ1T ZXJ2ZXIgRmFybQ0NTG9hZCBiYWxhbmNlciAoZS5nLiBMNCBzd2l0Y2gpOyBzZXJ2ZXIgcG9y dHMsIHNlcnZlcnM7IGF0dGFjaGVkIHN0b3JhZ2UNDVNlcnZlciByZXBsaWNhdGlvbiBvciBy ZXZlcnNlIHByb3h5IGNhY2hlcyAoY2VudHJhbCBvciBkaXN0cmlidXRlZCkNDUxvYWQgYmFs YW5jZXINDUludGVsbGlnZW50IFN0b3JhZ2UtQXJlYSBOZXR3b3JrDQ1TQU4gY29udHJvbCBz eXN0ZW0sIGNvbm5lY3Rpb24gbmV0d29yayhzKSwgYW5kIHN0b3JhZ2UgZGV2aWNlcw0NRXhw YW5zaW9uIGFuZC9vciBkaXN0cmlidXRpb24gb2YgU0FODQ1TQU4gY29udHJvbCBzeXN0ZW0N DUhvc3RpbmcgU3lzdGVtDQ1GaWd1cmUgOA0NV2lkZS1BcmVhIE5ldHdvcmsgJiBIb3N0aW5n DQ1Fc3RhYmxpc2ggcmVxdWlyZWQgUW9TIGFjcm9zcyBleHRyYW5ldCwgIHNpbmdsZS1jYXJy aWVyIGJhY2tib25lLCBvciBtdWx0aXBsZSBjYXJyaWVycyAmIGV4Y2hhbmdlIHBvaW50czsg bWFuYWdlIFFvUyBjYXBhYmlsaXRpZXMgb2YgaG9zdGluZyBzeXN0ZW0NDVRyYWNrIFFvUyBm b3IgZWFjaCBzZXNzaW9uOyBwZXJzb25hbGl6ZSBRb1MgY29udHJvbCBmb3IgZWFjaCB1c2Vy knMgYWNjZXNzIG5ldHdvcms7IHNlbGVjdCBXQU4gJiBXQU4gUW9TDQ1Qcm92aWRlIFFvUyBh dCBhY2Nlc3MgY29uY2VudHJhdGlvbiBub2RlOyBjb29yZGluYXRlIHdpdGggIGVkZ2UgY2Vu dGVyIG9yIHByZW1pc2UgbmV0d29yaw0NTWFwIGFwcGxpY2F0aW9ucyB0byBRb1M7IGNvbW11 bmljYXRlIHJlcXVpcmVtZW50cywgYnkgc2Vzc2lvbiwgdG8gdXBzdHJlYW0gZWxlbWVudHMu DQ1QcmVtaXNlIE5ldHdvcmsNDUFjY2VzcyBOZXR3b3JrDQ1FZGdlIENlbnRlcg0NTG9jYWwg Q29udGVudCBTZXJ2ZXINDUludGVybmV0DQ1QcmltYXJ5IENvbnRlbnQvU2VydmljZSBIb3N0 aW5nDQ1TZXNzaW9uIEFnZ3JlZ2F0b3INDVRydW5rL01BTg0NQWNjZXNzIENvbmNlbnRyYXRp b24gTm9kZQ0NQWNjZXNzIE1lZGl1bQ0NSUFEDQ1Ib21lL09mZmljZSBMQU4NDVVzZXIgRGV2 aWNlDQ1LZXkgSXNzdWVzIGFsb25nIHRoZSBDaGFpbg0NRmlndXJlIDkNDUNvbmZpZ3VyYXRp b24NDUNvbnRlbnRpb24NDVFvUyBPcHRpb25zDQ1Db250cm9sIEluZm8gQXQNDUNhYmxlIE1v ZGVtDQ1NdWx0aXBsZSB1c2VycyBvbiBjYWJsZSBzZWdtZW50DQ1ET0NTSVMgMS4xIGZvciBj dXJyZW50IHN5c3RlbXM7IDgwMi4xLCBJUCBRb1MsIEFUTSBwb3NzaWJsZQ0NUHJlbWlzZSBu ZXR3b3JrICYgYWNjZXNzIGNvbmNlbnRyYXRpb24gbm9kZQ0NeERTTA0NTXVsdGlwbGUgbGlu ZXMgb24gYWNjZXNzIGNvbmNlbnRyYXRpb24gbm9kZQ0NQVRNIGZvciBjdXJyZW50IHN5c3Rl bXM7IDgwMi4xIG9yIElQIFFvUyBwb3NzaWJsZQ0NUHJlbWlzZSBuZXR3b3JrICYgYWNjZXNz IGNvbmNlbnRyYXRpb24gbm9kZQ0NRml4ZWQgV2lyZWxlc3MNDU11bHRpcGxlIHVzZXJzIGlu IGNlbGwNDURPQ1NJUyAxLjE7IDgwMi4xOyBJUCBRb1MNDVRhYmxlIDENDVByZW1pc2UgbmV0 d29yaw1FdGhlcm5ldCAoQ2F0ZWdvcnkgNSBvciBIUE5BKQ1XaXJlbGVzcyBMQU4NQWNjZXNz IG5ldHdvcmsNSEZDOyBjb25jZW50cmF0aW9uIGF0IGZpYmVyIGFjY2VzcyBub2RlDXhEU0w7 IGNvbmNlbnRyYXRpb24gYXQgRFNMQU0NRml4ZWQgd2lyZWxlc3M7IGNvbmNlbnRyYXRpb24g YXQgdG93ZXINRlRUQy9IOyBjb25jZW50cmF0aW9uIGF0IGRhdGEgc3dpdGNoDUVkZ2UgY2Vu dGVyDUNhYmxlIGhlYWRlbmQgd2l0aCBsb2NhbCBjYWNoZXMgJiBzZXJ2ZXJzDU11bHRpc2Vy dmljZSBzZXNzaW9uIGFnZ3JlZ2F0b3Igd2l0aCBsb2NhbCBjYWNoZXMgJiBzZXJ2ZXJzIGFu ZCBtdWx0aXBsZSBXQU4gY29ubmVjdGlvbnMNU2ltcGxlIGRhdGEgYWdncmVnYXRpb247IGUu Zy4gd2l0aCBhbiBBVE0gc3dpdGNoDVdBTg1JbnRlcm5ldCAob25lIG9yIG1vcmUgYmFja2Jv bmUgY2FycmllcnMpDURpcmVjdCBjb25uZWN0aW9uIG9yIG1hbmFnZWQgZXh0cmFuZXQNUHJp bWFyeSBkYXRhIHNvdXJjZSBtYXkgb3IgbWF5IG5vdCBiZSBkaXN0cmlidXRlZA0NRXhhbXBs ZXMgb2YgTmV0d29yayBFbGVtZW50cw0NRmlndXJlIDENDVVuaXZlcnNhbCB0cmFuc3BvcnQg d2l0aCBhIGZsZXhpYmxlIGludGVyZmFjZSCWIElQIJYgdGhhdCBpcyBrZXB0IHNpbXBsZSBi eSBsaW1pdGluZyBpdHMgZmVhdHVyZXMgdG8gcHVyZSB0cmFuc3BvcnQgDQ1NYW55IGRpZmZl cmVudCB0eXBlcyBvZiBjbGllbnQgZGV2aWNlcywgZWFjaCBlcXVpcHBlZCB0byBkZWFsIHdp dGggYW55IHNwZWNpYWxpemVkIHNlcnZpY2VzIGl0IHJlcXVpcmVzDQ1NYW55IGRpZmZlcmVu dCB0eXBlcyBvZiBob3N0IGNvbXB1dGVycywgZGF0YSBzb3VyY2VzLCBhcHBsaWNhdGlvbnMs IGFuZCBzZXJ2aWNlcywgZWFjaCB3aXRoIGl0cyBvd24gY3VzdG9tIGZlYXR1cmVzDQ1JbnRl cm5ldA0Nk0hvdXJnbGFzc5QgbW9kZWwgb2YgdGhlIEludGVybmV0DQ1QcmVtaXNlIG5ldHdv cmsgJiBhY2Nlc3MgY29uY2VudHJhdGlvbiBub2RlDQ1GVFRDL0ggd2l0aCBkYXRhIHN3aXRj aA0NQXQgZGF0YSBzd2l0Y2ggYW5kIGl0cyB0cnVua3MNDTgwMi4xOyBBVE07IElQIFFvUzsg cHJvcHJpZXRhcnkgcHJvdG9jb2xzDQ1QcmVtaXNlIG5ldHdvcmsgJiBkYXRhIHN3aXRjaA0N DQ0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAADZFQAA2hUAAKMwAACkMAAA 1TMAANYzAADYNgAA2TYAAIE4AACCOAAAujkAALs5AADpYQAAJWIAACZiAACXYgAAQ2MAAERj AAB2YwAAs2MAABBvAAAVbwAAFm8AADVvAAA2bwAAOW8AADpvAAA/bwAAQG8AAERvAABFbwAA SW8AAEpvAABObwAAT28AAFNvAABUbwAAeW8AAHpvAAB8bwAAfW8AAH5vAAAScAAASnAAAFpw AABbcAAAXXAAAGZwAABncAAAz3AAANBwAADacAAA8HAAAARxAAAkcQAAJXEAAAD4APQA9AD0 APQA9ADyAPIA8ADyAOMA4wDjAOMA4wDjAOMA4wDjAOMA+ADh2+EAzQC+AK+mnZQAAAAAAAAA AAAAAAAAEUIqBkNKKABhSigAcGj/AAAAEUIqAkNKKABhSigAcGgzM8wAEUIqAUNKKABhSigA cGgAAAAAHTUIgTYIgUIqAUNKKABcCIFdCIFhSigAcGgAAAAAHTUIgTYIgUIqAUNKJABcCIFd CIFhSiQAcGgAAAAAGjUIgT4qAUIqAUNKMABcCIFhSjAAcGgAAAAAAAs2CIFtSAkEc0gJBAM2 CIEYA2oAAAAAVQgBbUgABG5IAARzSAkEdQgBAAM+KgEDPioABjYIgV0IgQANA2oAAAAAMEoT AFUIAQA4AAQAACcEAAB8BAAA6AQAAPEEAACnBQAAqAUAALcGAAC4BgAA5AcAAOUHAADrCAAA 7AgAAOoJAADrCQAAvAsAAMQLAADZCwAAKA4AACkOAABMEAAATRAAAGURAABmEQAApBQAAKUU AACaFwAAmxcAAE4YAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAA AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAA AAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA9wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQMAAAECAAABAAAAAQEAABwABAAAfW8AABJwAABdcAAA3YUAAP7+ /v4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AgEBBE4YAABPGAAAphoAAM0aAAA3HQAAOB0AAD4gAAA/IAAAayEAAGwhAADHIQAA+iEAAE0l AABOJQAARicAAEcnAABUKAAAfSgAAEEpAABCKQAAXykAAGApAACFKgAAhioAAKMqAACkKgAA 8yoAAPQqAADsKwAA7SsAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAAAAABFwAAAQMAAAEAAAAd7SsAABgsAAAZLAAAIC4AACEuAACZMAAA mjAAAKMwAACkMAAAxTMAAMYzAADVMwAA1jMAAMU2AADGNgAA2DYAANk2AAB2OAAAdzgAAIE4 AACCOAAAmDkAAJk5AAC6OQAAuzkAAKk7AACqOwAAwDsAAME7AAD9AAAAAAAAAAAAAAAA+wAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRQACiYAC0YAAAABAAAAARcA ABzBOwAAaz0AAGw9AACBPQAAfz4AAIA+AABcQQAAXUEAAAJEAAADRAAALUQAAC5EAACsRQAA rUUAAMhJAADJSQAAg0oAAIRKAAANSwAAeUsAAAhMAAAJTAAAWkwAAFtMAABcTAAAbEwAANRM AADsTAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA6gAAAAAA AAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAAAAABFAAAARcABQAACiYAC0YHAAUU AAomAAtGBwAAAQMABRQACiYAC0YAAAABAAAAG+xMAAAUTQAAl00AAC9OAACFTgAAhk4AAJVO AAB6TwAAD1AAAP1QAABsUQAA9FIAAPVSAAABUwAAj1MAABhUAADzVAAAbFUAAPdVAAAKVwAA +VcAAPpXAAANWAAAWFgAAEtZAAA2WgAAN1oAAE5aAAC9WgAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAARcACRQACiYAC0YAAA+EaAFehGgBAAEUAAAc vVoAAIZbAABZXAAAWlwAAK5cAACvXAAAsFwAALFcAACyXAAAs1wAALRcAADkXAAAGV0AABpd AADvXwAA8F8AAMlgAADKYAAA1GAAAPBgAAAFYQAAG2EAAC9hAAA9YQAAVGEAAF1hAAB/YQAA gGEAAMBhAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAA AAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA +wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADzAAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAA AAEFAAABEgAAAQMAAAECAAABAAAAARQAABzAYQAAwWEAAOhhAADpYQAAJWIAACZiAACYYgAA /WIAAP5iAABEYwAAVmMAAHVjAAB2YwAAtGMAAPpjAAD7YwAAdWQAAHZkAACRZAAAyGQAAMdl AADIZQAADmYAAJlpAACaaQAA1mkAABZsAABcbAAAUG0AAP0AAAAAAAAAAAAAAAD7AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8wAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAQMAAAECAAABFAAAAQUAAAEXAAABAAAAHFBt AABRbQAAd20AANRtAAATbgAAQ24AAERuAAAPbwAAEG8AAH1vAAARcAAAEnAAAFtwAABccAAA XXAAAGZwAABncAAAz3AAANBwAADbcAAA8HAAAARxAAAkcQAAJXEAAEFxAABCcQAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACQAACiYAC0YBADckADgkAEgkAAYAADckADgkAEgkAAkAAAMkATckADgkAEgk AGEkAQAEEQADJAFhJAEAARIAAAEAAAAZJXEAAEFxAABCcQAAUnEAAFNxAABicQAAY3EAAG9x AABwcQAAhXEAAIZxAACPcQAAkHEAALBxAACxcQAAxHEAAMVxAADPcQAA0HEAAOpxAADrcQAA +XEAAPpxAAD+cQAA/3EAAA9yAAAQcgAAHHIAAB1yAAAscgAALXIAAJNyAACUcgAAoHIAAClz AAAqcwAAOHMAADlzAABEcwAARXMAAFBzAADzAPMA8wDzAOoA3gDPAOoAxgDGAL0A6gC9AK4A nwCTAINzAGYAZgBmGUIqAUNKKABPSgQAUUoEAGFKKABwaAAAAAAfNgiBQioBQ0owAE9KBABR SgQAXQiBYUowAHBoAAAAAB82CIFCKgFDSjgAT0oEAFFKBABdCIFhSjgAcGgAAAAAFzYIgUIq AUNKIABdCIFhSiAAcGgAAAAAHDkIgUIqBkNKSABPSgMAUUoDAGFKSABwaMwAAAAAHTUIgTYI gUIqAUNKHABcCIFdCIFhShwAcGgAAAAAEUIqAUNKHABhShwAcGgAAAAAEUIqBkNKHABhShwA cGj/AAAAHTUIgTYIgUIqAkNKHABcCIFdCIFhShwAcGgzM8wAFzUIgUIqBkNKIABcCIFhSiAA cGj/AAAAEUIqAkNKHABhShwAcGgzM8wAFzUIgUIqBENKKABcCIFhSigAcGgzmTMAAChCcQAA UnEAAFNxAABicQAAY3EAAG9xAABwcQAAhXEAAIZxAACPcQAAkHEAALBxAACxcQAAxHEAAMVx AADPcQAA0HEAAOpxAADrcQAA+XEAAPpxAAD+cQAA/3EAAA9yAAAQcgAAHHIAAB1yAAAscgAA 9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAADckADgkAEgkAAAB AAAJAAADJAE3JAA4JABIJABhJAEAGyxyAAAtcgAAk3IAAJRyAACgcgAAyHIAAPFyAAApcwAA KnMAADhzAAA5cwAARHMAAEVzAABScwAAU3MAAGNzAABkcwAAaXMAAGpzAACLcwAAjHMAAMVz AADGcwAA13MAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAOUAAAAA AAAAAAAAAADTAAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAAygAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADKAAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAMoAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAygAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAyQB NyQAOCQASCQAYSQBABEAAAomAAtGAwAPhJIEEYQ+/jckADgkAEgkAF6EkgRghD7+ABEAAAom AAtGAgAPhBwCEYTk/TckADgkAEgkAF6EHAJghOT9BgAANyQAOCQASCQAAAEAAAAXUHMAAFFz AABScwAAU3MAAGNzAABkcwAAaXMAAGpzAACLcwAAjHMAAMVzAADGcwAA13MAANhzAADccwAA 3XMAAO5zAADvcwAAKnQAACt0AABNdAAATnQAAF50AABfdAAAaHQAAGl0AABydAAAc3QAAH50 AADEdAAA2XQAAOh0AADpdAAA8nQAAPN0AAD/dAAAb3UAAHB1AAB+dQAAf3UAAIp1AACLdQAA l3UAAJh1AACodQAAqXUAAMJ1AADDdQAA53UAAOh1AAATdgAAFHYAACZ2AAAndgAAW3YAAFx2 AACRdgAAknYAANt2AADcdgAA9nYAAPHkAOQA1wDXANcA1wDXANcA1wDXAMgAugC6AKqaAMgA ugCqmgDkAOQA5ADkANcA1wDXANcA1wDXANcA1wAAAAAfNgiBQioBQ0owAE9KBABRSgQAXQiB YUowAHBoAAAAAB82CIFCKgFDSjgAT0oEAFFKBABdCIFhSjgAcGgAAAAAGjUIgT4qAUIqAUNK MABcCIFhSjAAcGgAAAAAABw5CIFCKgZDSkgAT0oDAFFKAwBhSkgAcGjMAAAAABlCKgFDSiQA T0oEAFFKBABhSiQAcGgAAAAAGUIqAUNKKABPSgQAUUoEAGFKKABwaAAAAAAcQioBQ0ooAEgq AU9KBABRSgQAYUooAHBoAAAAADzXcwAA2HMAANxzAADdcwAA7nMAAO9zAAAqdAAAK3QAAE10 AABOdAAAXnQAAF90AABodAAAaXQAAHJ0AABzdAAAfnQAAMR0AADFdAAAxnQAAMd0AADIdAAA yXQAAMp0AAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA ygAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAKJgAL RgMAD4SSBBGEPv43JAA4JABIJABehJIEYIQ+/gARAAAKJgALRgIAD4QcAhGE5P03JAA4JABI JABehBwCYITk/QkAAAMkATckADgkAEgkAGEkAQYAADckADgkAEgkAAABAAAAF8p0AADLdAAA zHQAAM10AADOdAAAz3QAANB0AADRdAAA0nQAANN0AADUdAAA1XQAANZ0AADXdAAA2HQAANl0 AADodAAA6XQAAPJ0AADzdAAA/3QAAC91AABvdQAAcHUAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAADcAAAAAAAAAAAAAAAAygAAAAAAAAAAAAAAAMoAAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAAAAAAAAAAAAAAABEAAAomAAtGAwAPhJIEEYQ+/jckADgkAEgkAF6EkgRghD7+ ABEAAAomAAtGAgAPhBwCEYTk/TckADgkAEgkAF6EHAJghOT9CQAAAyQBNyQAOCQASCQAYSQB BgAANyQAOCQASCQAAAEAAAAXcHUAAH51AAB/dQAAinUAAIt1AACXdQAAmHUAAKh1AACpdQAA wnUAAMN1AADndQAA6HUAABN2AAAUdgAAJnYAACd2AABbdgAAXHYAAJF2AACSdgAA23YAANx2 AAD2dgAA93YAACt3AAAsdwAATncAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADuAAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAGAAA3JAA4JABIJAAAAQAACQAAAyQBNyQAOCQASCQAYSQBABv2dgAA93YAACt3 AAAsdwAATncAAE93AACadwAAm3cAALh3AAC5dwAAxXcAAMZ3AADPdwAA0HcAANt3AAA0eAAA NXgAAEN4AABEeAAAT3gAAFB4AABceAAAXXgAAG14AABueAAAkXgAAJJ4AACjeAAApHgAANN4 AADUeAAAFnkAABd5AAA9eQAAPnkAAGJ5AABjeQAAvXkAAL55AAAFegAABnoAAA96AAAQegAA JHoAACV6AABwegAAcXoAALN6AAC0egAAx3oAAMh6AADRegAA0noAAN56AABHewAASHsAAFZ7 AABXewAAYnsAAGN7AABvewAAcHsAAIB7AACBewAAjXsAAI57AADWewAAAPIA8gDyAPIA4wDV AMW1AKgAqACoAKgA8gDyAPIA8gDyAPIA8gDyAPIA8gDyAPIA4wDVAMW1AKgAqACoAKgA8gDy AAAZQioBQ0ooAE9KBABRSgQAYUooAHBoAAAAAB82CIFCKgFDSjAAT0oEAFFKBABdCIFhSjAA cGgAAAAAHzYIgUIqAUNKOABPSgQAUUoEAF0IgWFKOABwaAAAAAAaNQiBPioBQioBQ0owAFwI gWFKMABwaAAAAAAAHDkIgUIqBkNKSABPSgMAUUoDAGFKSABwaMwAAAAAGUIqAUNKJABPSgQA UUoEAGFKJABwaAAAAAAAQk53AABPdwAAmncAAJt3AAC4dwAAuXcAAMV3AADGdwAAz3cAANB3 AADbdwAANHgAADV4AABDeAAARHgAAE94AABQeAAAXHgAAF14AABteAAAbngAAJF4AACSeAAA o3gAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADKAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAAomAAtGAwAP hJIEEYQ+/jckADgkAEgkAF6EkgRghD7+ABEAAAomAAtGAgAPhBwCEYTk/TckADgkAEgkAF6E HAJghOT9CQAAAyQBNyQAOCQASCQAYSQBBgAANyQAOCQASCQAAAEAAAAXo3gAAKR4AADTeAAA 1HgAABZ5AAAXeQAAPXkAAD55AABieQAAY3kAAL15AAC+eQAABXoAAAZ6AAAPegAAEHoAACR6 AAAlegAAcHoAAHF6AACzegAAtHoAAMd6AADIegAA0XoAANJ6AAD9AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAADJAE3JAA4JABIJABhJAEGAAA3 JAA4JABIJAAAAQAAABnSegAA3noAABV7AABHewAASHsAAFZ7AABXewAAYnsAAGN7AABvewAA cHsAAIB7AACBewAAjXsAAI57AADWewAA13sAABt8AAAcfAAAKnwAACt8AABMfAAATXwAAIx8 AADtAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA 0AAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANAA AAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA0AAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADKAAAA AAAAAAAAAAAA2QAAAAAAAAAAAAAAAMoAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAAygAAAAAA AAAAAAAAANkAAAAAAAAAAAAAAADKAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAAMoAAAAAAAAA AAAAAADZAAAAAAAAAAAAAAAAygAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAADckADgkAEgkAAkA AAMkATckADgkAEgkAGEkAQABAAAAEQAACiYAC0YDAA+EkgQRhD7+NyQAOCQASCQAXoSSBGCE Pv4AEQAACiYAC0YCAA+EHAIRhOT9NyQAOCQASCQAXoQcAmCE5P0AF9Z7AADXewAAG3wAABx8 AAAqfAAAK3wAAEx8AABNfAAAjHwAAI18AACyfAAAs3wAAMZ8AADHfAAA1nwAANd8AADgfAAA 4XwAAP18AAD+fAAAQ30AAGZ9AABvfQAAcn0AAHN9AACSfQAAk30AAPx9AAD9fQAAJ34AAFd+ AABYfgAAcX4AAK1+AACufgAAvn4AAL9+AADOfgAAz34AANt+AADcfgAA8X4AAPJ+AAD7fgAA /H4AABx/AAAdfwAAMH8AADF/AAAA8gDyAPIA8gDyAPIA4wDVAMkAuqm6qbqpAKkAuqkAuqkA yQDJAMkAoACUAIUAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHTUIgTYIgUIqAkNKHABcCIFd CIFhShwAcGgzM8wAFzUIgUIqBkNKIABcCIFhSiAAcGj/AAAAEUIqAkNKHABhShwAcGgzM8wA IDUIgTYIgT4qAUIqBkNKHABcCIFdCIFhShwAcGjMAAAAAB01CIE2CIFCKgZDShwAXAiBXQiB YUocAHBozAAAABc1CIFCKgRDSigAXAiBYUooAHBoM5kzABo1CIE+KgFCKgFDSjAAXAiBYUow AHBoAAAAAAAcOQiBQioGQ0pIAE9KAwBRSgMAYUpIAHBozAAAAAAZQioBQ0okAE9KBABRSgQA YUokAHBoAAAAAAAwjHwAAI18AACyfAAAs3wAAMZ8AADHfAAA1nwAANd8AADgfAAA4XwAAP18 AAD+fAAAkn0AAJN9AAD8fQAA/X0AAFd+AABYfgAArX4AAK5+AAC+fgAAv34AAM5+AADPfgAA 234AANx+AADxfgAA8n4AAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADu AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAJAAADJAE3JAA4JABIJABhJAEGAAA3JAA4JABIJAAAAQAAABvyfgAA+34AAPx+AAAcfwAA HX8AADB/AAAxfwAAO38AADx/AABWfwAAV38AAGV/AABmfwAAan8AAGt/AAB7fwAAfH8AAIh/ AACJfwAApH8AAKV/AACufwAAr38AAL1/AAC+fwAAyX8AAMp/AADWfwAA9gAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA7gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAADckADgkAEgkAAABAAAJAAADJAE3JAA4 JABIJABhJAEAGzF/AAA7fwAAPH8AAFZ/AABXfwAAZX8AAGZ/AABqfwAAa38AAHt/AAB8fwAA iH8AAIl/AACkfwAApX8AAK5/AACvfwAAvX8AAL5/AADJfwAAyn8AANZ/AADXfwAA538AAOh/ AAD0fwAA9X8AABWAAAAWgAAAUoAAAFOAAAB/gAAAgIAAAIWAAACGgAAAsoAAALOAAADlgAAA 5oAAABKBAAATgQAAIoEAACOBAAA6gQAAO4EAAFWBAABWgQAAXoEAAF+BAABvgQAAmoEAAKmB AAA6ggAARoIAAPqCAAD+ggAAf4MAAICDAAD2APYA7QDkAO0A1QDGALgAqwCrAKsAqwCeAJ4A ngCeAJ4AngCeAJ4AngCeAJ4AuACRq5GrkauRqwAAGUIqAUNKMABPSgQAUUoEAGFKMABwaAAA AAAZQioBQ0okAE9KBABRSgQAYUokAHBoAAAAABlCKgFDSigAT0oEAFFKBABhSigAcGgAAAAA GjUIgT4qAUIqAUNKMABcCIFhSjAAcGgAAAAAABw5CIFCKgZDSkgAT0oDAFFKAwBhSkgAcGjM AAAAAB01CIE2CIFCKgFDShwAXAiBXQiBYUocAHBoAAAAABFCKgJDShwAYUocAHBoMzPMABFC KgFDShwAYUocAHBoAAAAABFCKgZDShwAYUocAHBo/wAAAAA51n8AANd/AADnfwAA6H8AAPR/ AAD1fwAAFYAAABaAAABSgAAAU4AAAH+AAACAgAAAhYAAAIaAAACygAAAs4AAAOWAAADmgAAA EoEAABOBAAAigQAAI4EAADqBAAA7gQAAVYEAAFaBAABegQAAX4EAAP0AAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAA3JAA4JABIJAAJAAADJAE3JAA4JABIJABh JAEAAQAAABtfgQAAb4EAAI2BAACagQAAqYEAANGBAADugQAAFYIAADqCAABGggAAcIIAAMmC AAD6ggAA/oIAACeDAABNgwAAf4MAAICDAACdgwAAnoMAAKeDAACogwAAHYQAAB6EAADtAAAA AAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA2wAAAAAA AAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAAO0AAAAAAAAA AAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADtAAAAAAAAAAAA AAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAA ANMAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAAygAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADK AAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMkATckADgkAEgkAGEkAQYA ADckADgkAEgkAAABAAAAEQAACiYAC0YFAA+EkgQRhD7+NyQAOCQASCQAXoSSBGCEPv4AEQAA CiYAC0YEAA+EHAIRhOT9NyQAOCQASCQAXoQcAmCE5P0AF4CDAACdgwAAnoMAAKeDAACogwAA HYQAAB6EAACGhAAAh4QAAPuEAAD8hAAABYUAAAaFAAAohQAAKYUAAFWFAABWhQAAboUAAG+F AACNhQAAjoUAALiFAAC5hQAA14UAAN6FAADxAOMA2gDRAMgAvADxAK8ArwCvAK8ArwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGUIqAUNKJABPSgQAUUoEAGFKJABwaAAAAAAXNQiBQioMQ0okAFwIgWFKJABwaKUA IQARQioCQ0okAGFKJABwaBJDzgARQioLQ0okAGFKJABwaAAzAAARQioMQ0okAGFKJABwaKUA IQAaNQiBPioBQioLQ0owAFwIgWFKMABwaAAzAAAAHDkIgUIqBkNKSABPSgMAUUoDAGFKSABw aMwAAAAYHoQAAIaEAACHhAAA+4QAAPyEAAAFhQAABoUAACiFAAAphQAAVYUAAFaFAABuhQAA b4UAAI2FAACOhQAAuIUAALmFAADXhQAA2IUAANmFAADahQAA24UAANyFAADdhQAA3oUAAPYA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADuAAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA7gAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAO4AAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADuAAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAA3 JAA4JABIJAAAAQAACQAAAyQBNyQAOCQASCQAYSQBABgcAB+wgi4gsMZBIbAIByKwCAcjkKAF JJCgBSWwAAAjACZQCQAdMAIfsMZBILCCLiGwoAUisKAFI5AIBySQCAclsAAA//////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8A AAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAAAAQABCAAAAYAAAAEA0AIA AAAAAP8DAAEIAAABgAAAAQDQAgAAAAAA/wAAAQgAAAGAAAABANACAAAAAAD/BAABCAAAAYAA AAEA0AIAAAAAAP8AAQEIAAABgAAAAQDQAgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEB CAAAAYAAAAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAA AAD/AAAAAC4ALgAuACkAKAApACgAKQAoACkAKAApACgAKQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAmUAkAHTACH7DGQSCwgi4hsKAFIrCgBSOQCAckkAgHJbAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAA9gICYAAA7F7WMDM3jDA4DdkBAQAA AHzcEgZUDdkBIAAAAO8DAAACAAAADk/WMAAAAAD02xIGAQAAAAAAAAAAAAAAAAAAAPjaEgYQ ABQGQwAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAQwAAAOTaEgYAAAAA3P8S BkS583dYyvN3/////zzbEgYZCbR3bAIAABAAFAZDAAAAnN0SBgAAAAAYSPYCAQAAAJDdEgaL nQswGP8WABAAFAZDAAAAnN0SBkMAAAAAphsDQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABtw/Z30HX6d27D9ndYxhYA0ABSAwAAAAAAAAAAAAAAANzbEgbULPl3ANL5d//////s 2xIGAM32dzjGFgDUAFID0ABSAyAAAADvAwAAZgWOMDgN2QEHAAAA8gaOMAhB1jAk+PYC0ABS AwjcEgaPLaAwWOt8MGALTgPRAAAAHNwSBgAAAAAAAAAAFAzZAXzcEgb2GrIw0QAAAAAAAAAA AAAAAAAAABhyAgY4DdkB/NwSBhAAAAAAAAAAAAAAACj49gIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKPj2AjzcEgYo+PYCPNwSBkPoAAAAAAAAziHxdwEAAAAwC9kBkBAAAPTjvjCQ 3BIGAQAAAHxxAgagcQIGBN0SBl68kjCdAQAA8HECBowL2QGMC9kBAQAAAP////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////AAAA AAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAAAAEAAQgAAAGAAAABANACAAAA AAD/AwABCAAAAYAAAAEA0AIAAAAAAP8AAAEIAAABgAAAAQDQAgAAAAAA/wQAAQgAAAGAAAAB ANACAAAAAAD/AAEBCAAAAYAAAAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgA AAGAAAABANACAAAAAAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQAgAAAAAA /wAAAAAuAC4ALgApACgAKQAoACkAKAApACgAKQAoACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAJlAJAB0wAh+wxkEgsIIuIbCgBSKwoAUjkAgHJJAIByWwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAPYCAmAAAOxe1jAzN4wwOA3ZAQEAAAB8 3BIGVA3ZASAAAADvAwAAAgAAAA5P1jAAAAAA9NsSBgEAAAAAAAAAAAAAAAAAAAD42hIGEAAU BkMAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAADOAAAAAAAAAAAAAEMAAADk2hIGAAAAANz/EgZE ufN3WMrzd/////882xIGGQm0d2wCAAAQABQGQwAAAJzdEgYAAAAAGEj2AgEAAACQ3RIGi50L MBj/FgAQABQGQwAAAJzdEgZDAAAAAKYbA0MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAbcP2d9B1+nduw/Z3WMYWANAAUgMAAAAAAAAAAAAAAADc2xIG1Cz5dwDS+Xf/////7NsS BgDN9nc4xhYA1ABSA9AAUgMgAAAA7wMAAGYFjjA4DdkBBwAAAPIGjjAIQdYwJPj2AtAAUgMI 3BIGjy2gMFjrfDBgC04D0QAAABzcEgYAAAAAAAAAABQM2QF83BIG9hqyMNEAAAAAAAAAAAAA AAAAAAAYcgIGOA3ZAfzcEgYQAAAAAAAAAAAAAAAo+PYCAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACj49gI83BIGKPj2AjzcEgZD6AAAAAAAAM4h8XcBAAAAMAvZAZAQAAD0474wkNwS BgEAAAB8cQIGoHECBgTdEgZevJIwnQEAAPBxAgaMC9kBjAvZAQEAAAD///////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////wAAAAAA AAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAAABAAEIAAABgAAAAQDQAgAAAAAA /wMAAQgAAAGAAAABANACAAAAAAD/AAABCAAAAYAAAAEA0AIAAAAAAP8EAAEIAAABgAAAAQDQ AgAAAAAA/wABAQgAAAGAAAABANACAAAAAAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAAB gAAAAQDQAgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAAAAEA0AIAAAAAAP8A AAAALgAuAC4AKQAoACkAKAApACgAKQAoACkAKAApAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACZQCQAdMAIfsMZBILCCLiGwoAUisKAFI5AIBySQCAclsAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAD2AgJgAADsXtYwMzeMMDgN2QEBAAAAfNwS BlQN2QEgAAAA7wMAAAIAAAAOT9YwAAAAAPTbEgYBAAAAAAAAAAAAAAAAAAAA+NoSBhAAFAZD AAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAzgAAAAAAAAAAAABDAAAA5NoSBgAAAADc/xIGRLnz d1jK83f/////PNsSBhkJtHdsAgAAEAAUBkMAAACc3RIGAAAAABhI9gIBAAAAkN0SBoudCzAY /xYAEAAUBkMAAACc3RIGQwAAAACmGwNDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AG3D9nfQdfp3bsP2d1jGFgDQAFIDAAAAAAAAAAAAAAAA3NsSBtQs+XcA0vl3/////+zbEgYA zfZ3OMYWANQAUgPQAFIDIAAAAO8DAABmBY4wOA3ZAQcAAADyBo4wCEHWMCT49gLQAFIDCNwS Bo8toDBY63wwYAtOA9EAAAAc3BIGAAAAAAAAAAAUDNkBfNwSBvYasjDRAAAAAAAAAAAAAAAA AAAAGHICBjgN2QH83BIGEAAAAAAAAAAAAAAAKPj2AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAo+PYCPNwSBij49gI83BIGQ+gAAAAAAADOIfF3AQAAADAL2QGQEAAA9OO+MJDcEgYB AAAAfHECBqBxAgYE3RIGXrySMJ0BAADwcQIGjAvZAYwL2QEBAAAA//////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////8AAAAAAAAA /wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAAAAQABCAAAAYAAAAEA0AIAAAAAAP8D AAEIAAABgAAAAQDQAgAAAAAA/wAAAQgAAAGAAAABANACAAAAAAD/BAABCAAAAYAAAAEA0AIA AAAAAP8AAQEIAAABgAAAAQDQAgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAA AAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAAAAD/AAAA AC4ALgAuACkAKAApACgAKQAoACkAKAApACgAKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAmUAkAHTACH7DGQSCwgi4hsKAFIrCgBSOQCAckkAgHJbAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAA9gICYAAA7F7WMDM3jDA4DdkBAQAAAHzcEgZU DdkBIAAAAO8DAAACAAAADk/WMAAAAAD02xIGAQAAAAAAAAAAAAAAAAAAAPjaEgYQABQGQwAA AAAAAAAAAAAAAQAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAQwAAAOTaEgYAAAAA3P8SBkS583dY yvN3/////zzbEgYZCbR3bAIAABAAFAZDAAAAnN0SBgAAAAAYSPYCAQAAAJDdEgaLnQswGP8W ABAAFAZDAAAAnN0SBkMAAAAAphsDQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABt w/Z30HX6d27D9ndYxhYA0ABSAwAAAAAAAAAAAAAAANzbEgbULPl3ANL5d//////s2xIGAM32 dzjGFgDUAFID0ABSAyAAAADvAwAAZgWOMDgN2QEHAAAA8gaOMAhB1jAk+PYC0ABSAwjcEgaP LaAwWOt8MGALTgPRAAAAHNwSBgAAAAAAAAAAFAzZAXzcEgb2GrIw0QAAAAAAAAAAAAAAAAAA ABhyAgY4DdkB/NwSBhAAAAAAAAAAAAAAACj49gIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKPj2AjzcEgYo+PYCPNwSBkPoAAAAAAAAziHxdwEAAAAwC9kBkBAAAPTjvjCQ3BIGAQAA AHxxAgagcQIGBN0SBl68kjCdAQAA8HECBowL2QGMC9kBAQAAAP////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////AAAAAAAAAP8A AAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAAAAEAAQgAAAGAAAABANACAAAAAAD/AwAB CAAAAYAAAAEA0AIAAAAAAP8AAAEIAAABgAAAAQDQAgAAAAAA/wQAAQgAAAGAAAABANACAAAA AAD/AAEBCAAAAYAAAAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAAB ANACAAAAAAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQAgAAAAAA/wAAAAAu AC4ALgApACgAKQAoACkAKAApACgAKQAoACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAJlAJAB0wAh+wxkEgsIIuIbCgBSKwoAUjkAgHJJAIByWwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAPYCAmAAAOxe1jAzN4wwOA3ZAQEAAAB83BIGVA3Z ASAAAADvAwAAAgAAAA5P1jAAAAAA9NsSBgEAAAAAAAAAAAAAAAAAAAD42hIGEAAUBkMAAAAA AAAAAAAAAAEAAAAAAAAAAAAAAADOAAAAAAAAAAAAAEMAAADk2hIGAAAAANz/EgZEufN3WMrz d/////882xIGGQm0d2wCAAAQABQGQwAAAJzdEgYAAAAAGEj2AgEAAACQ3RIGi50LMBj/FgAQ ABQGQwAAAJzdEgZDAAAAAKYbA0MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbcP2 d9B1+nduw/Z3WMYWANAAUgMAAAAAAAAAAAAAAADc2xIG1Cz5dwDS+Xf/////7NsSBgDN9nc4 xhYA1ABSA9AAUgMgAAAA7wMAAGYFjjA4DdkBBwAAAPIGjjAIQdYwJPj2AtAAUgMI3BIGjy2g MFjrfDBgC04D0QAAABzcEgYAAAAAAAAAABQM2QF83BIG9hqyMNEAAAAAAAAAAAAAAAAAAAAY cgIGOA3ZAfzcEgYQAAAAAAAAAAAAAAAo+PYCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACj49gI83BIGKPj2AjzcEgZD6AAAAAAAAM4h8XcBAAAAMAvZAZAQAAD0474wkNwSBgEAAAB8 cQIGoHECBgTdEgZevJIwnQEAAPBxAgaMC9kBjAvZAQEAAAD///////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////wAAAAAAAAD/AAAA AAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAAABAAEIAAABgAAAAQDQAgAAAAAA/wMAAQgA AAGAAAABANACAAAAAAD/AAABCAAAAYAAAAEA0AIAAAAAAP8EAAEIAAABgAAAAQDQAgAAAAAA /wABAQgAAAGAAAABANACAAAAAAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQ AgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAAAAEA0AIAAAAAAP8AAAAALgAu AC4AKQAoACkAKAApACgAKQAoACkAKAApAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACZQCQAdMAIfsMZBILCCLiGwoAUisKAFI5AIBySQCAclsAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAgAAAAAAD2AgJgAADsXtYwMzeMMDgN2QEBAAAAfNwSBlQN2QEg AAAA7wMAAAIAAAAOT9YwAAAAAPTbEgYBAAAAAAAAAAAAAAAAAAAA+NoSBhAAFAZDAAAAAAAA AAAAAAABAAAAAAAAAAAAAAAAzgAAAAAAAAAAAABDAAAA5NoSBgAAAADc/xIGRLnzd1jK83f/ ////PNsSBhkJtHdsAgAAEAAUBkMAAACc3RIGAAAAABhI9gIBAAAAkN0SBoudCzAY/xYAEAAU BkMAAACc3RIGQwAAAACmGwNDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG3D9nfQ dfp3bsP2d1jGFgDQAFIDAAAAAAAAAAAAAAAA3NsSBtQs+XcA0vl3/////+zbEgYAzfZ3OMYW ANQAUgPQAFIDIAAAAO8DAABmBY4wOA3ZAQcAAADyBo4wCEHWMCT49gLQAFIDCNwSBo8toDBY 63wwYAtOA9EAAAAc3BIGAAAAAAAAAAAUDNkBfNwSBvYasjDRAAAAAAAAAAAAAAAAAAAAGHIC BjgN2QH83BIGEAAAAAAAAAAAAAAAKPj2AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo +PYCPNwSBij49gI83BIGQ+gAAAAAAADOIfF3AQAAADAL2QGQEAAA9OO+MJDcEgYBAAAAfHEC BqBxAgYE3RIGXrySMJ0BAADwcQIGjAvZAYwL2QEBAAAA//////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////8AAAAAAAAA/wAAAAAA AAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAAAAQABCAAAAYAAAAEA0AIAAAAAAP8DAAEIAAAB gAAAAQDQAgAAAAAA/wAAAQgAAAGAAAABANACAAAAAAD/BAABCAAAAYAAAAEA0AIAAAAAAP8A AQEIAAABgAAAAQDQAgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAAAAEA0AIA AAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAAAAD/AAAAAC4ALgAu ACkAKAApACgAKQAoACkAKAApACgAKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAmUAkAHTACH7DGQSCwgi4hsKAFIrCgBSOQCAckkAgHJbAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAIAAAAAAA9gICYAAA7F7WMDM3jDA4DdkBAQAAAHzcEgZUDdkBIAAA AO8DAAACAAAADk/WMAAAAAD02xIGAQAAAAAAAAAAAAAAAAAAAPjaEgYQABQGQwAAAAAAAAAA AAAAAQAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAQwAAAOTaEgYAAAAA3P8SBkS583dYyvN3//// /zzbEgYZCbR3bAIAABAAFAZDAAAAnN0SBgAAAAAYSPYCAQAAAJDdEgaLnQswGP8WABAAFAZD AAAAnN0SBkMAAAAAphsDQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABtw/Z30HX6 d27D9ndYxhYA0ABSAwAAAAAAAAAAAAAAANzbEgbULPl3ANL5d//////s2xIGAM32dzjGFgDU AFID0ABSAyAAAADvAwAAZgWOMDgN2QEHAAAA8gaOMAhB1jAk+PYC0ABSAwjcEgaPLaAwWOt8 MGALTgPRAAAAHNwSBgAAAAAAAAAAFAzZAXzcEgb2GrIw0QAAAAAAAAAAAAAAAAAAABhyAgY4 DdkB/NwSBhAAAAAAAAAAAAAAACj49gIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKPj2 AjzcEgYo+PYCPNwSBkPoAAAAAAAAziHxdwEAAAAwC9kBkBAAAPTjvjCQ3BIGAQAAAHxxAgag cQIGBN0SBl68kjCdAQAA8HECBowL2QGMC9kBAQAAAP////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAAAAAAAP8AAAAAAAAA /wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAAAAEAAQgAAAGAAAABANACAAAAAAD/AwABCAAAAYAA AAEA0AIAAAAAAP8AAAEIAAABgAAAAQDQAgAAAAAA/wQAAQgAAAGAAAABANACAAAAAAD/AAEB CAAAAYAAAAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAA AAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQAgAAAAAA/wAAAAAuAC4ALgAp ACgAKQAoACkAKAApACgAKQAoACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAJlAJAB0wAh+wxkEgsIIuIbCgBSKwoAUjkAgHJJAIByWwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACAAAAAAAPYCAmAAAOxe1jAzN4wwOA3ZAQEAAAB83BIGVA3ZASAAAADv AwAAAgAAAA5P1jAAAAAA9NsSBgEAAAAAAAAAAAAAAAAAAAD42hIGEAAUBkMAAAAAAAAAAAAA AAEAAAAAAAAAAAAAAADOAAAAAAAAAAAAAEMAAADk2hIGAAAAANz/EgZEufN3WMrzd/////88 2xIGGQm0d2wCAAAQABQGQwAAAJzdEgYAAAAAGEj2AgEAAACQ3RIGi50LMBj/FgAQABQGQwAA AJzdEgZDAAAAAKYbA0MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbcP2d9B1+ndu w/Z3WMYWANAAUgMAAAAAAAAAAAAAAADc2xIG1Cz5dwDS+Xf/////7NsSBgDN9nc4xhYA1ABS A9AAUgMgAAAA7wMAAGYFjjA4DdkBBwAAAPIGjjAIQdYwJPj2AtAAUgMI3BIGjy2gMFjrfDBg C04D0QAAABzcEgYAAAAAAAAAABQM2QF83BIG9hqyMNEAAAAAAAAAAAAAAAAAAAAYcgIGOA3Z AfzcEgYQAAAAAAAAAAAAAAAo+PYCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACj49gI8 3BIGKPj2AjzcEgZD6AAAAAAAAM4h8XcBAAAAMAvZAZAQAAD0474wkNwSBgEAAAB8cQIGoHEC BgTdEgZevJIwnQEAAPBxAgaMC9kBjAvZAQEAAAD///////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wAAAAAAAAD/AAAAAAAAAP8A AAAAAAAA/wAAAAAAAAD/AAAAAAAAAAABAAEIAAABgAAAAQDQAgAAAAAA/wMAAQgAAAGAAAAB ANACAAAAAAD/AAABCAAAAYAAAAEA0AIAAAAAAP8EAAEIAAABgAAAAQDQAgAAAAAA/wABAQgA AAGAAAABANACAAAAAAD/BAEBCAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQAgAAAAAA /wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAAAAEA0AIAAAAAAP8AAAAALgAuAC4AKQAo ACkAKAApACgAKQAoACkAKAApAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACZQCQAdMAIfsMZBILCCLiGwoAUisKAFI5AIBySQCAclsAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAgAAAAAAD2AgJgAADsXtYwMzeMMDgN2QEBAAAAfNwSBlQN2QEgAAAA7wMA AAIAAAAOT9YwAAAAAPTbEgYBAAAAAAAAAAAAAAAAAAAA+NoSBhAAFAZDAAAAAAAAAAAAAAAB AAAAAAAAAAAAAAAAzgAAAAAAAAAAAABDAAAA5NoSBgAAAADc/xIGRLnzd1jK83f/////PNsS BhkJtHdsAgAAEAAUBkMAAACc3RIGAAAAABhI9gIBAAAAkN0SBoudCzAY/xYAEAAUBkMAAACc 3RIGQwAAAACmGwNDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG3D9nfQdfp3bsP2 d1jGFgDQAFIDAAAAAAAAAAAAAAAA3NsSBtQs+XcA0vl3/////+zbEgYAzfZ3OMYWANQAUgPQ AFIDIAAAAO8DAABmBY4wOA3ZAQcAAADyBo4wCEHWMCT49gLQAFIDCNwSBo8toDBY63wwYAtO A9EAAAAc3BIGAAAAAAAAAAAUDNkBfNwSBvYasjDRAAAAAAAAAAAAAAAAAAAAGHICBjgN2QH8 3BIGEAAAAAAAAAAAAAAAKPj2AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo+PYCPNwS Bij49gI83BIGQ+gAAAAAAADOIfF3AQAAADAL2QGQEAAA9OO+MJDcEgYBAAAAfHECBqBxAgYE 3RIGXrySMJ0BAADwcQIGjAvZAYwL2QEBAAAA//////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8AAAAAAAAA/wAAAAAAAAD/AAAA AAAAAP8AAAAAAAAA/wAAAAAAAAAAAQABCAAAAYAAAAEA0AIAAAAAAP8DAAEIAAABgAAAAQDQ AgAAAAAA/wAAAQgAAAGAAAABANACAAAAAAD/BAABCAAAAYAAAAEA0AIAAAAAAP8AAQEIAAAB gAAAAQDQAgAAAAAA/wQBAQgAAAGAAAABANACAAAAAAD/AgEBCAAAAYAAAAEA0AIAAAAAAP8E AQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAAAAD/AAAAAC4ALgAuACkAKAAp ACgAKQAoACkAKAApACgAKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAm UAkAHTACH7DGQSCwgi4hsKAFIrCgBSOQCAckkAgHJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAIAAAAAAA9gICYAAA7F7WMDM3jDA4DdkBAQAAAHzcEgZUDdkBIAAAAO8DAAAC AAAADk/WMAAAAAD02xIGAQAAAAAAAAAAAAAAAAAAAPjaEgYQABQGQwAAAAAAAAAAAAAAAQAA AAAAAAAAAAAAAM4AAAAAAAAAAAAAQwAAAOTaEgYAAAAA3P8SBkS583dYyvN3/////zzbEgYZ CbR3bAIAABAAFAZDAAAAnN0SBgAAAAAYSPYCAQAAAJDdEgaLnQswGP8WABAAFAZDAAAAnN0S BkMAAAAAphsDQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABtw/Z30HX6d27D9ndY xhYA0ABSAwAAAAAAAAAAAAAAANzbEgbULPl3ANL5d//////s2xIGAM32dzjGFgDUAFID0ABS AyAAAADvAwAAZgWOMDgN2QEHAAAA8gaOMAhB1jAk+PYC0ABSAwjcEgaPLaAwWOt8MGALTgPR AAAAHNwSBgAAAAAAAAAAFAzZAXzcEgb2GrIw0QAAAAAAAAAAAAAAAAAAABhyAgY4DdkB/NwS BhAAAAAAAAAAAAAAACj49gIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKPj2AjzcEgYo +PYCPNwSBkPoAAAAAAAAziHxdwEAAAAwC9kBkBAAAPTjvjCQ3BIGAQAAAHxxAgagcQIGBN0S Bl68kjCdAQAA8HECBowL2QGMC9kBAQAAAP////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////AAAAAAAAAP8AAAAAAAAA/wAAAAAA AAD/AAAAAAAAAP8AAAAAAAAAAAEAAQgAAAGAAAABANACAAAAAAD/AwABCAAAAYAAAAEA0AIA AAAAAP8AAAEIAAABgAAAAQDQAgAAAAAA/wQAAQgAAAGAAAABANACAAAAAAD/AAEBCAAAAYAA AAEA0AIAAAAAAP8EAQEIAAABgAAAAQDQAgAAAAAA/wIBAQgAAAGAAAABANACAAAAAAD/BAEB CAAAAYAAAAEA0AIAAAAAAP8CAQEIAAABgAAAAQDQAgAAAAAA/wAAAAAuAC4ALgApACgAKQAo ACkAKAApACgAKQAoACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJlAJ AB0wAh+wxkEgsIIuIbCgBSKwoAUjAAAAAAAAAAAAAAAAAAAAAAAUABgACgABAGkADwADAAAA AAAAAAAAMAAAQPH/AgAwAAwABgBOAG8AcgBtAGEAbAAAAAIAAAAQAF9IAQRtSAkMc0gJDHRI CQRIAAFAAQACAEgADAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAAEAABAAYkAROk8AAUpDwAQCYA EwA1CIFDShwAS0gcAE9KAgBRSgIAAEoAAkABAAIASgAMAAkASABlAGEAZABpAG4AZwAgADIA AAAQAAIABiQBE6TwABSkPABAJgEVADUIgTYIgT4qAUNKGABPSgIAUUoCAABGAANAAQACAEYA DAAJAEgAZQBhAGQAaQBuAGcAIAAzAAAAEAADAAYkAROk8AAUpDwAQCYCEgA1CIFDShgAT0oC AFFKAgBcCIEyAAQAAQACADIADAAJAEgAZQBhAGQAaQBuAGcAIAA0AAAACAAEAAYkAUAmAwYA NgiBXQiBMAAFQAEAAgAwAAwACQBIAGUAYQBkAGkAbgBnACAANQAAAAgABQAGJAFAJgQDAD4q AQAAAAAAAAAAADwAQUDy/6EAPAAMABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEA cABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAwAFoAAQDyADAADAAKAFAAbABhAGkAbgAgAFQA ZQB4AHQAAAACAA8ACABPSgUAUUoFACwAHwABAAIBLAAMAAYASABlAGEAZABlAHIAAAANABAA DcYIAALgEMAhAQIAAAAsACBAAQASASwADAAGAEYAbwBvAHQAZQByAAAADQARAA3GCAAC4BDA IQECAAAALgAdQAEAIgEuAAwADQBGAG8AbwB0AG4AbwB0AGUAIABUAGUAeAB0AAAAAgASAAAA OAAmQKIAMQE4AAwAEgBGAG8AbwB0AG4AbwB0AGUAIABSAGUAZgBlAHIAZQBuAGMAZQAAAAMA SCoBACYA/k8BAEIBJgAMAAUATABpAHMAdAAxAAAACQAUAAomAAtGCgAAAAAAACIA/g9BAWIB IgANAAUATABpAHMAdAAyAAAAAgAWAAMAPioBADIA/k8BAHIBMgAMAAoASQB0AGUAbQBIAGUA YQBkAGUAcgAAAAIAFwAJADUIgTYIgVwIgQDZEQAA3oEAAAEAAAAAAJQAAACXAAAAAAAAAAoA AABzAAAAyAAAAOUAAAD2AAAABgEAABMBAAApAQAAMwEAAFQBAABoAQAAcwEAAI4BAACdAQAA ogEAALMBAADAAQAA0AEAADcCAADNAgAA3AIAAOgCAAD2AgAABwMAAA0DAAAvAwAAaQMAAHsD AACAAwAAkgMAAM4DAADxAwAAAgQAAAwEAAAWBAAAaAQAAGkEAABqBAAAawQAAGwEAABtBAAA bgQAAG8EAABwBAAAcQQAAHIEAABzBAAAdAQAAHUEAAB2BAAAdwQAAHgEAAB5BAAAegQAAHsE AAB8BAAAjAQAAJYEAAATBQAAIgUAAC4FAAA7BQAATAUAAGYFAACLBQAAtwUAAMoFAAD/BQAA NQYAAH8GAACaBgAAzwYAAPIGAAA+BwAAXAcAAGkHAABzBwAA2AcAAOcHAADzBwAAAAgAABEI AAA1CAAARwgAAHcIAAC6CAAA4QgAAAYJAABhCQAAqQkAALMJAADICQAAFAoAAFcKAABrCgAA dQoAAOsKAAD6CgAABgsAABMLAAAkCwAAMQsAAHoLAAC/CwAAzgsAAPALAAAwDAAAVgwAAGoM AAB6DAAAhAwAAKEMAAA2DQAAoA0AAPsNAABRDgAAYg4AAHIOAAB/DgAAlQ4AAJ8OAADADgAA 1A4AAN8OAAD6DgAACQ8AAA4PAAAfDwAALA8AAEgPAABSDwAAYQ8AAG0PAAB6DwAAiw8AAJgP AAC5DwAA9g8AACMQAAApEAAAVhAAAIkQAAC2EAAAxhAAAN4QAAD5EAAAAhEAACMTAABBEwAA SxMAAMETAAAqFAAAnxQAAKkUAADMFAAA+RQAABIVAAAxFQAAXBUAAHsVAAB8FQAAfRUAAH4V AAB/FQAA3oEAAAEAAAAAAAAAAAD/////PwQAAAAAAAABAAAAAAAAAAAA/////z4EAAAAAAAA AQAAAAAAAAAAAP////89BAAAAAAAAAEAAAAAAAAAAAD/////OwQAAAAAAAABAAAAAAAAAAAA /////zkEAAAAAAAAAQAAAAAAAAAAAP////83BAAAAAAAAAEAAAAAAAAAAAD/////NQQAAAAA AAABAAAAAAAAAAAA/////y8EAAAAAAAAAQAAAAAAAAAAAP////8uBAAAAAAAAAEAAAAAAAAA AAD/////LAQAAAAAAAABAAAAAAAAAAAA/////ysEAAAAAAAAAQAAAAAAAAAAAP////8qBAAA AAAAAAEAAAAAAAAAAAD/////KAQAAAAAAAABAAAAAAAAAAAA/////ycEAAAAAAAAAQAAAAAA AAAAAP////8lBAAAAAAAAAEAAAAAAAAAAAD/////JAQAAAAAAAABAAAAAAAAAAAA/////yIE AAAAAAAAAQAAAAAAAAAAAP////8hBAAAAAAAAAEAAAAAAAAAAAD/////WAQAAAAAAAABAAAA AAAAAAAA/////1cEAAAAAAAAAQAAAAAAAAAAAP////9wBQAAAAAAAAEAAAAAAAAAAAD///// bwUAAAAAAAABAAAAAAAAAAAA/////24FAAAAAAAAAQAAAAAAAAAAAP////9tBQAAAAAAAAEA AAAAAAAAAAD/////bAUAAAAAAAABAAAAAAAAAAAA/////2sFAAAAAAAAAQAAAAAAAAAAAP// //9qBQAAAAAAAAEAAAAAAAAAAAD/////aQUAAAAAAAABAAAAAAAAAAAA/////2gFAAAAAAAA AQAAAAAAAAAAAP////9nBQAAAAAAAAEAAAAAAAAAAAD/////ZgUAAAAAAAABAAAAAAAAAAAA /////2UFAAAAAAAAAQAAAAAAAAAAAP////9ABAAAAAAAAAEAAAAAAAAAAAD/////WQQAAAAA AAABAAAAAAAAAAAA/////3wEAAAAAAAAAQAAAAAAAAAAAP////97BAAAAAAAAP////8AAAAA AQD/////AAAAAAAAAAAkAAAAAQAAAAEA/////wAAAAAAAAAAJQAAAAIAAAABAP////8AAAAA AAAAACYAAAADAAAAAQD/////AAAAAAAAAAAnAAAABAAAAAEA/////wAAAAAAAAAAKAAAAAUA AAABAP////8AAAAAAAAAACkAAAAGAAAAAQD/////AAAAAAAAAAAqAAAABwAAAAEA/////wAA AAAAAAAAKwAAAAgAAAABAP////8AAAAAAAAAACwAAAAJAAAAAQD/////AAAAAAAAAAAtAAAA CgAAAAEA/////wAAAAAAAAAALgAAAAsAAAABAP////8AAAAAAAAAAC8AAAAMAAAAAQD///// AAAAAAAAAAAwAAAADQAAAAEA/////wAAAAAAAAAAMQAAAA4AAAABAP////8AAAAAAAAAADIA AAAPAAAAAQD/////AAAAAAAAAAAzAAAAEAAAAAEA/////wAAAAAAAAAANAAAABEAAAABAP// //8AAAAAAAAAADUAAAASAAAAAQD/////AAAAAAAAAAA2AAAAEwAAAAEA/////wAAAAAAAAAA AQAAAAAAAAAAAP////9aBAAAAAAAAAEAAAAAAAAAAAD/////mgQAAAAAAAABAAAAAAAAAAAA /////5kEAAAAAAAAAQAAAAAAAAAAAP////+OBAAAAAAAAAEAAAAAAAAAAAD/////jQQAAAAA AAABAAAAAAAAAAAA/////4wEAAAAAAAAAQAAAAAAAAAAAP////+LBAAAAAAAAAEAAAAAAAAA AAD/////igQAAAAAAAABAAAAAAAAAAAA/////4kEAAAAAAAAAQAAAAAAAAAAAP////+IBAAA AAAAAAEAAAAAAAAAAAD/////hwQAAAAAAAABAAAAAAAAAAAA/////4YEAAAAAAAAAQAAAAAA AAAAAP////+FBAAAAAAAAAEAAAAAAAAAAAD/////hAQAAAAAAAABAAAAAAAAAAAA/////4ME AAAAAAAAAQAAAAAAAAAAAP////+CBAAAAAAAAAEAAAAAAAAAAAD/////gQQAAAAAAAABAAAA AAAAAAAA/////4AEAAAAAAAAAQAAAAAAAAAAAP////9/BAAAAAAAAAEAAAAAAAAAAAD///// fQQAAAAAAAABAAAAAAAAAAAA/////7gEAAAAAAAAAQAAAAAAAAAAAP////+3BAAAAAAAAAEA AAAAAAAAAAD/////ygUAAAAAAAABAAAAAAAAAAAA/////8kFAAAAAAAAAQAAAAAAAAAAAP// ///IBQAAAAAAAAEAAAAAAAAAAAD/////xwUAAAAAAAABAAAAAAAAAAAA/////8YFAAAAAAAA AQAAAAAAAAAAAP/////FBQAAAAAAAAEAAAAAAAAAAAD/////xAUAAAAAAAABAAAAAAAAAAAA /////8MFAAAAAAAAAQAAAAAAAAAAAP/////CBQAAAAAAAAEAAAAAAAAAAAD/////wQUAAAAA AAABAAAAAAAAAAAA/////8AFAAAAAAAAAQAAAAAAAAAAAP////+/BQAAAAAAAAEAAAAAAAAA AAD/////vgUAAAAAAAABAAAAAAAAAAAA/////70FAAAAAAAAAQAAAAAAAAAAAP////+8BQAA AAAAAAEAAAAAAAAAAAD/////uwUAAAAAAAABAAAAAAAAAAAA/////5sEAAAAAAAAAQAAAAAA AAAAAP/////RBAAAAAAAAAEAAAAAAAAAAAD/////0AQAAAAAAAABAAAAAAAAAAAA/////8YE AAAAAAAAAQAAAAAAAAAAAP/////FBAAAAAAAAAEAAAAAAAAAAAD/////xAQAAAAAAAABAAAA AAAAAAAA/////8MEAAAAAAAAAQAAAAAAAAAAAP/////CBAAAAAAAAAEAAAAAAAAAAAD///// wQQAAAAAAAABAAAAAAAAAAAA/////8AEAAAAAAAAAQAAAAAAAAAAAP////+/BAAAAAAAAAEA AAAAAAAAAAD/////vgQAAAAAAAABAAAAAAAAAAAA/////70EAAAAAAAAAQAAAAAAAAAAAP// //+8BAAAAAAAAAEAAAAAAAAAAAD/////uwQAAAAAAAABAAAAAAAAAAAA/////7kEAAAAAAAA AQAAAAAAAAAAAP/////2BAAAAAAAAAEAAAAAAAAAAAD/////9QQAAAAAAAABAAAAAAAAAAAA //////MEAAAAAAAAAQAAAAAAAAAAAP/////xBAAAAAAAAAEAAAAAAAAAAAD/////8AQAAAAA AAABAAAAAAAAAAAA/////+0EAAAAAAAAAQAAAAAAAAAAAP/////qBAAAAAAAAAEAAAAAAAAA AAD/////6AQAAAAAAAABAAAAAAAAAAAA/////+YEAAAAAAAAAQAAAAAAAAAAAP/////gBAAA AAAAAAEAAAAAAAAAAAD/////3wQAAAAAAAABAAAAAAAAAAAA/////90EAAAAAAAAAQAAAAAA AAAAAP/////cBAAAAAAAAAEAAAAAAAAAAAD/////2wQAAAAAAAABAAAAAAAAAAAA/////9kE AAAAAAAAAQAAAAAAAAAAAP/////YBAAAAAAAAAEAAAAAAAAAAAD/////1gQAAAAAAAABAAAA AAAAAAAA/////9UEAAAAAAAAAQAAAAAAAAAAAP/////TBAAAAAAAAAEAAAAAAAAAAAD///// 0gQAAAAAAAABAAAAAAAAAAAA/////yQFAAAAAAAAAQAAAAAAAAAAAP////+OBQAAAAAAAAEA AAAAAAAAAAD/////jQUAAAAAAAABAAAAAAAAAAAA/////4wFAAAAAAAAAQAAAAAAAAAAAP// //+LBQAAAAAAAAEAAAAAAAAAAAD/////igUAAAAAAAABAAAAAAAAAAAA/////4kFAAAAAAAA AQAAAAAAAAAAAP////+IBQAAAAAAAAEAAAAAAAAAAAD/////hwUAAAAAAAABAAAAAAAAAAAA /////4YFAAAAAAAAAQAAAAAAAAAAAP////+FBQAAAAAAAAEAAAAAAAAAAAD/////hAUAAAAA AAABAAAAAAAAAAAA/////4MFAAAAAAAAAQAAAAAAAAAAAP////+CBQAAAAAAAAEAAAAAAAAA AAD/////gQUAAAAAAAABAAAAAAAAAAAA/////4AFAAAAAAAAAQAAAAAAAAAAAP////9jBQAA AAAAAAEAAAAAAAAAAAD/////YgUAAAAAAAABAAAAAAAAAAAA/////2EFAAAAAAAAAQAAAAAA AAAAAP////9gBQAAAAAAAAEAAAAAAAAAAAD/////XQUAAAAAAAABAAAAAAAAAAAA/////1wF AAAAAAAAAQAAAAAAAAAAAP////9ZBQAAAAAAAAEAAAAAAAAAAAD/////WAUAAAAAAAABAAAA AAAAAAAA/////1MFAAAAAAAAAQAAAAAAAAAAAP////9/BQAAAAAAAAEAAAAAAAAAAAD///// fgUAAAAAAAABAAAAAAAAAAAA/////30FAAAAAAAAAQAAAAAAAAAAAP////98BQAAAAAAAAEA AAAAAAAAAAD/////ewUAAAAAAAA3AAAAFAAAAAEA/////wAAAAAAAAAAoAAAABUAAAABAP// //8AAAAAAAAAAKEAAAAWAAAAAQD/////AAAAAAAAAACiAAAAFwAAAAEA/////wAAAAAAAAAA owAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAAcwAAAMgAAADlAAAA9gAAAAYBAAATAQAA KQEAADMBAABUAQAAaAEAAHMBAACOAQAAnQEAAKIBAACzAQAAwAEAANABAAA3AgAAzQIAANwC AADoAgAA9gIAAAcDAAANAwAALwMAAGkDAAB7AwAAgAMAAJIDAADOAwAA8QMAAAIEAAAMBAAA FgQAAGgEAABpBAAAagQAAGsEAABsBAAAbQQAAG4EAABvBAAAcAQAAHEEAAByBAAAcwQAAHQE AAB1BAAAdgQAAHcEAAB4BAAAeQQAAHoEAAB7BAAAfAQAAIwEAACWBAAAEwUAACIFAAAuBQAA OwUAAEwFAABmBQAAiwUAALcFAADKBQAA/wUAADUGAAB/BgAAmgYAAM8GAADyBgAAPgcAAFwH AABpBwAAcwcAANgHAADnBwAA8wcAAAAIAAARCAAANQgAAEcIAAB3CAAAuggAAOEIAAAGCQAA YQkAAKkJAACzCQAAyAkAABQKAABXCgAAawoAAHUKAADrCgAA+goAAAYLAAATCwAAJAsAADEL AAB6CwAAvwsAAM4LAADwCwAAMAwAAFYMAABqDAAAegwAAIQMAAChDAAANg0AAKANAAD7DQAA UQ4AAGIOAAByDgAAfw4AAJUOAACfDgAAwA4AANQOAADfDgAA+g4AAAkPAAAODwAAHw8AACwP AABIDwAAUg8AAGEPAABtDwAAeg8AAIsPAACYDwAAuQ8AAPYPAAAjEAAAKRAAAFYQAACJEAAA thAAAMYQAADeEAAA+RAAAAIRAAAjEwAAQRMAAEsTAADBEwAAKhQAAJ8UAACpFAAAzBQAAPkU AAASFQAAMRUAAFwVAAB7FQAAfBUAAH0VAAB+FQAAfxUAAIIVAAAAAAAAAAgBAAAAAAgCAAAA AAgDAAAAAAgEAAAAAAgFAAAAAAgGAAAAAAgHAAAAAAgIAAAAAAgJAAAAAAgKAAAAAAgLAAAA AAgMAAAAAAgNAAAAAAgOAAAAAAgPAAAAAAgQAAAAAAgRAAAAAAgSAAAAAAgTAAAAAAgUAAAA AAgVAAAAAAgWAAAAAAgXAAAAAAgYAAAAAAgZAAAAAAgaAAAAAAgbAAAAAAgcAAAAAAgdAAAA AAgeAAAAAAgfAAAAAAggAAAAAAghAAAAAAgiAAAAAAgjAAAAAAgkAAAAAAglAAAAAAgmAAAA AAgnAAAAAAgoAAAAAAgpAAAAAAgqAAAAAAgrAAAAAAgsAAAAAAgtAAAAAAguAAAAAAgvAAAA AAgwAAAAAAgxAAAAAAgyAAAAAAgzAAAAAAg0AAAAAAg1AAAAAAg2AAAAAAg3AAAAAAg4AAAA AAg5AAAAAAg6AAAAAAg7AAAAAAg8AAAAAAg9AAAAAAg+AAAAAAg/AAAAAAhAAAAAAAhBAAAA AAhCAAAAAAhDAAAAAAhEAAAAAAhFAAAAAAhGAAAAAAhHAAAAAAhIAAAAAAhJAAAAAAhKAAAA AAhLAAAAAAhMAAAAAAhNAAAAAAhOAAAAAAhPAAAAAAhQAAAAAAhRAAAAAAhSAAAAAAhTAAAA AAhUAAAAAAhVAAAAAAhWAAAAAAhXAAAAAAhYAAAAAAhZAAAAAAhaAAAAAAhbAAAAAAhcAAAA AAhdAAAAAAheAAAAAAhfAAAAAAhgAAAAAAhhAAAAAAhiAAAAAAhjAAAAAAhkAAAAAAhlAAAA AAhmAAAAAAhnAAAAAAhoAAAAAAhpAAAAAAhqAAAAAAhrAAAAAAhsAAAAAAhtAAAAAAhuAAAA AAhvAAAAAAhwAAAAAAhxAAAAAAhyAAAAAAhzAAAAAAh0AAAAAAh1AAAAAAh2AAAAAAh3AAAA AAh4AAAAAAh5AAAAAAh6AAAAAAh7AAAAAAh8AAAAAAh9AAAAAAh+AAAAAAh/AAAAAAiAAAAA AAiBAAAAAAiCAAAAAAiDAAAAAAiEAAAAAAiFAAAAAAiGAAAAAAiHAAAAAAiIAAAAAAiJAAAA AAiKAAAAAAiLAAAAAAiMAAAAAAiNAAAAAAiOAAAAAAiPAAAAAAiQAAAAAAiRAAAAAAiSAAAA AAiTAAAAAAiUAAAAAAiVAAAAAAiWAAAAAAiXAAAAAAiYAAAAAAiZAAAAAAiaAAAAAAibAAAA AAicAAAAAAidAAAAAAieAAAAAAifAAAAAAigAAAAAAihAAAAAAiiAAAAAAijAAAAAAj//wAA AAAAAAAAEGsAAN6BAAAGAADMAAAAAP////8GAB7MAAAAAP////8AAAAAJwAAAHwAAADoAAAA 8QAAAKcBAACoAQAAtwIAALgCAADkAwAA5QMAAOsEAADsBAAA6gUAAOsFAAC8BwAAxAcAANkH AAAoCgAAKQoAAEwMAABNDAAAZQ0AAGYNAACkEAAApRAAAJoTAACbEwAAThQAAE8UAACmFgAA zRYAADcZAAA4GQAAPhwAAD8cAABrHQAAbB0AAMcdAAD6HQAATSEAAE4hAABGIwAARyMAAFQk AAB9JAAAQSUAAEIlAABfJQAAYCUAAIUmAACGJgAAoyYAAKQmAADzJgAA9CYAAOwnAADtJwAA GCgAABkoAAAgKgAAISoAAJksAACaLAAAoywAAKQsAADFLwAAxi8AANUvAADWLwAAxTIAAMYy AADYMgAA2TIAAHY0AAB3NAAAgTQAAII0AACYNQAAmTUAALo1AAC7NQAAqTcAAKo3AADANwAA wTcAAGs5AABsOQAAgTkAAH86AACAOgAAXD0AAF09AAACQAAAA0AAAC1AAAAuQAAArEEAAK1B AADIRQAAyUUAAINGAACERgAADUcAAHlHAAAISAAACUgAAFpIAABbSAAAXEgAAGxIAADUSAAA 7EgAABRJAACXSQAAL0oAAIVKAACGSgAAlUoAAHpLAAAPTAAA/UwAAGxNAAD0TgAA9U4AAAFP AACPTwAAGFAAAPNQAABsUQAA91EAAApTAAD5UwAA+lMAAA1UAABYVAAAS1UAADZWAAA3VgAA TlYAAL1WAACGVwAAWVgAAFpYAACuWAAAr1gAALBYAACxWAAAslgAALNYAAC0WAAA5FgAABlZ AAAaWQAA71sAAPBbAADJXAAAylwAANRcAADwXAAABV0AABtdAAAvXQAAPV0AAFRdAABdXQAA f10AAIBdAADAXQAAwV0AAOhdAADpXQAAJV4AACZeAACYXgAA/V4AAP5eAABEXwAAVl8AAHVf AAB2XwAAtF8AAPpfAAD7XwAAdWAAAHZgAACRYAAAyGAAAMdhAADIYQAADmIAAJllAACaZQAA 1mUAABZoAABcaAAAUGkAAFFpAAB3aQAA1GkAABNqAABDagAARGoAAA9rAAAQawAAfWsAABFs AAASbAAAW2wAAFxsAABdbAAAZmwAAGdsAADPbAAA0GwAANtsAADwbAAABG0AACRtAAAlbQAA QW0AAEJtAABSbQAAU20AAGJtAABjbQAAb20AAHBtAACFbQAAhm0AAI9tAACQbQAAsG0AALFt AADEbQAAxW0AAM9tAADQbQAA6m0AAOttAAD5bQAA+m0AAP5tAAD/bQAAD24AABBuAAAcbgAA HW4AACxuAAAtbgAAk24AAJRuAACgbgAAyG4AAPFuAAApbwAAKm8AADhvAAA5bwAARG8AAEVv AABSbwAAU28AAGNvAABkbwAAaW8AAGpvAACLbwAAjG8AAMVvAADGbwAA128AANhvAADcbwAA 3W8AAO5vAADvbwAAKnAAACtwAABNcAAATnAAAF5wAABfcAAAaHAAAGlwAABycAAAc3AAAH5w AADEcAAAxXAAAMZwAADHcAAAyHAAAMlwAADKcAAAy3AAAMxwAADNcAAAznAAAM9wAADQcAAA 0XAAANJwAADTcAAA1HAAANVwAADWcAAA13AAANhwAADZcAAA6HAAAOlwAADycAAA83AAAP9w AAAvcQAAb3EAAHBxAAB+cQAAf3EAAIpxAACLcQAAl3EAAJhxAACocQAAqXEAAMJxAADDcQAA 53EAAOhxAAATcgAAFHIAACZyAAAncgAAW3IAAFxyAACRcgAAknIAANtyAADccgAA9nIAAPdy AAArcwAALHMAAE5zAABPcwAAmnMAAJtzAAC4cwAAuXMAAMVzAADGcwAAz3MAANBzAADbcwAA NHQAADV0AABDdAAARHQAAE90AABQdAAAXHQAAF10AABtdAAAbnQAAJF0AACSdAAAo3QAAKR0 AADTdAAA1HQAABZ1AAAXdQAAPXUAAD51AABidQAAY3UAAL11AAC+dQAABXYAAAZ2AAAPdgAA EHYAACR2AAAldgAAcHYAAHF2AACzdgAAtHYAAMd2AADIdgAA0XYAANJ2AADedgAAFXcAAEd3 AABIdwAAVncAAFd3AABidwAAY3cAAG93AABwdwAAgHcAAIF3AACNdwAAjncAANZ3AADXdwAA G3gAABx4AAAqeAAAK3gAAEx4AABNeAAAjHgAAI14AACyeAAAs3gAAMZ4AADHeAAA1ngAANd4 AADgeAAA4XgAAP14AAD+eAAAknkAAJN5AAD8eQAA/XkAAFd6AABYegAArXoAAK56AAC+egAA v3oAAM56AADPegAA23oAANx6AADxegAA8noAAPt6AAD8egAAHHsAAB17AAAwewAAMXsAADt7 AAA8ewAAVnsAAFd7AABlewAAZnsAAGp7AABrewAAe3sAAHx7AACIewAAiXsAAKR7AAClewAA rnsAAK97AAC9ewAAvnsAAMl7AADKewAA1nsAANd7AADnewAA6HsAAPR7AAD1ewAAFXwAABZ8 AABSfAAAU3wAAH98AACAfAAAhXwAAIZ8AACyfAAAs3wAAOV8AADmfAAAEn0AABN9AAAifQAA I30AADp9AAA7fQAAVX0AAFZ9AABefQAAX30AAG99AACNfQAAmn0AAKl9AADRfQAA7n0AABV+ AAA6fgAARn4AAHB+AADJfgAA+n4AAP5+AAAnfwAATX8AAH9/AACAfwAAnX8AAJ5/AACnfwAA qH8AAB2AAAAegAAAhoAAAIeAAAD7gAAA/IAAAAWBAAAGgQAAKIEAACmBAABVgQAAVoEAAG6B AABvgQAAjYEAAI6BAAC4gQAAuYEAANeBAADfgQAACAAAAAEwAAAAAAAAAIAAAACACAAAAAEw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAnAAAAGAAAAAIwAAAAAAAAAIAnAAAAmAAAAAAw AAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAw AAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAw AAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAmAAAAAAw AAAAAAAAAIDoAAAAmAAAAAAwAAAAAAAAAIDoAAAAGAAAAAIwAAAAAAAAAIAnAAAAKAAAAAMw AAAAAAAAAIC8BwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAw AAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAw AAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAw AAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAmAAAAAAw AAAAAAAAAIDEBwAAmAAAAAAwAAAAAAAAAIDEBwAAKAAAAAMwAAAAAAAAAIC8BwAAmAAAAAAw AAAAAAAAAICmFgAAmAAAAAAwAAAAAAAAAICmFgAAmAAAAAAwAAAAAAAAAICmFgAAmAAAAAAw AAAAAAAAAICmFgAAmAAAAAAwAAAAAAAAAICmFgAAmAAAAAAwAAAAAAAAAICmFgAAmAAAAAAw AAAAAAAAAICmFgAAKAAAAAMwAAAAAAAAAIC8BwAAmAAAAAAwAAAAAAAAAIDHHQAAmAAAAAAw AAAAAAAAAIDHHQAAmAAAAAAwAAAAAAAAAIDHHQAAmAAAAAAwAAAAAAAAAIDHHQAAmAAAAAAw AAAAAAAAAIDHHQAAKAAAAAMwAAAAAAAAAIC8BwAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAAAAwAAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABcw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABcw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAmAAAABQw AAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAABcwAAAAAAAAAIBUJAAAmAAAAAAw AAAAAAAAAIBUJAAAmAAAABQwAAAAAAAAAIBUJAAAKAAAAAMwAAAAAAAAAIC8BwAAmAAAAAAw AAAAAAAAAIBsOQAAmAAAAAAwAAAAAAAAAIBsOQAAmAAAAAAwAAAAAAAAAIBsOQAAmAAAAAAw AAAAAAAAAIBsOQAAmAAAAAAwAAAAAAAAAIBsOQAAmAAAAAAwAAAAAAAAAIBsOQAAKAAAAAMw AAAAAAAAAIC8BwAAmAAAAAAwAAAAAAAAAIADQAAAmAAAAAAwAAAAAAAAAIADQAAAmAAAAAAw AAAAAAAAAIADQAAAmAAAAAAwAAAAAAAAAIADQAAAmAAAAAAwAAAAAAAAAIADQAAAmAAAAAAw AAAAAAAAAIADQAAAmAAAAAAwAAAAAAAAAIADQAAAmAAHIBQwAAAAAAAAAIADQAAAmAAHIAAw AQAAAAAAAIADQAAAmAAHIAAwAgAAAAAAAIADQAAAmAAAAAAwAAAAAAAAAIAqQAAAmAAAAAAw AAAAAAAAAIAqQAAAmAAAAAAwAAAAAAAAAIAqQAAAmAAAAAAwAAAAAAAAAIAqQAAAmAAAABcw AAAAAAAAAIAqQAAAmAAKIBQwAAAAAAAAAIAqQAAAmAAKIBQwAQAAAAAAAIAqQAAAmAAKIBQw AgAAAAAAAIAqQAAAmAAKIBQwAwAAAAAAAIAqQAAAmAAKIBQwBAAAAAAAAIAqQAAAmAAKIBQw BQAAAAAAAIAqQAAAmAAAABQwAAAAAAAAAIAqQAAAmAAAABcwAAAAAAAAAIAqQAAAmAAKIBQw BgAAAAAAAIAqQAAAmAAKIBQwBwAAAAAAAIAqQAAAmAAKIBQwCAAAAAAAAIAqQAAAmAAKIBQw CQAAAAAAAIAqQAAAmAAKIBQwCgAAAAAAAIAqQAAAmAAAABcwAAAAAAAAAIAAAACAmAAAABcw AAAAAAAAAIAAAACAmAAKIBQwCwAAAAAAAIAqQAAAmAAKIBQwDAAAAAAAAIAqQAAAmAAKIBQw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAAABcwAAAAAAAAAIAAAACAmAAAABcw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACAmAAAABcwAAAAAAAAAIAAAACAmAAAABcwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAGAAAAAIwAAAAAAAAAIAAAACAKAAAAAMw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAABIw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACASAAAAAUw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACASAAAAAUw AAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACASAAAAAUwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAKAAAAAMwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAABcw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACASAAAAAUwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACASAAAAAUwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAKIBQwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACASAAAAAUwAAAAAAAAAIAAAACAmAAKIBQw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAABcwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAGAAAAAIwAAAAAAAAAIAAAACAKAAAAAMwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAKAAAAAMwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAKAAAAAMwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAKAAAAAMwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAYAAwAAAAAAAAAIBeSQAAmAAAAAAwAAAAAAAAAIAAAACAmkAAABIw AAAAAAAAAIAAAACACgAAAAAwAAAAAAAAAAAAAAAAmkAAABEwAAAAAAAAAIAAAACAmkAAAAAw AAAAAAAAAIAAAACACgAAAAAwAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAABIAAwAAAAAAAAAIAAAACAmAABIAAwAAAAAAAAAIAAAACAmAABIAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAACIAAwAAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmAADIAAw AAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAACIAAw AAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAACIAAw AAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAACIAAwAAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAACIAAwAAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmAADIAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAEIAAw AAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAEIAAw AAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAw AAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAEIAAwAAAAAAAAAIAAAACAmAAFIAAw AAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAEIAAw AAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAwAAAAAAAAAIAAAACAmAAFIAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmkAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmkAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmkAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmgAAAAAQAAAAAAAAAIAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEoAAABKAAAASgAAAEoAAABKAAAASgAAAEoAAABKAAAASgAAAE0A AAAABAAAJXEAAFBzAAD2dgAA1nsAADF/AACAgwAA3oUAAEkAAABTAAAAVgAAAFoAAABeAAAA YQAAAGQAAAAABAAAThgAAO0rAADBOwAA7EwAAL1aAADAYQAAUG0AAEJxAAAscgAA13MAAMp0 AABwdQAATncAAKN4AADSegAAjHwAAPJ+AADWfwAAX4EAAB6EAADehQAASgAAAEwAAABNAAAA TgAAAE8AAABQAAAAUQAAAFIAAABUAAAAVQAAAFcAAABYAAAAWQAAAFsAAABcAAAAXQAAAF8A AABgAAAAYgAAAGMAAABlAAAAAAQAAN2FAABLAAAADwAA8PAAAAAAAAbwGAAAAAIIAAACAAAA XwIAAAEAAAABAAAAYAIAAE8AAfCwAAAAMgAH8CQAAAADBDMoq1PW1VeuUPa6P6QBBe7/ABEh AAAAAAAA/////wAA2QEiAAfwJAAAAAIEECZOG/62P+cvPsLqfs6HoP8AtzsAAAAAAAD///// AADZASIAB/AkAAAAAgQ9rp+f9zQwyvI+N7qhOV4A/wBcOwAAAAAAAP////8AANkBIgAH8CQA AAACBCprq3vTPBrQfEOD1PcaHCn/AKwpAAABAAAAQ8wAAAAA2QFAAB7xEAAAAP//AAAAAP8A gICAAPcAABAADwAC8NxtAAAQAAjwCAAAAOoAAABfBgAADwAD8HptAAAPAATwKAAAAAEACfAQ AAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwZgAAABIACvAIAAAAIQQA AAAKAABzAAvwKgAAAH8AAQAFAIAAAAASAIcAAQAAAIEBAMyZAL8BAAARAP8BAAAJAAECAAAA AAAAEPAEAAAAIwAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAASAA8ABPBmAAAAogwK8AgAAAAi BAAAAAoAAHMAC/AqAAAAfwAAAAQAgAAAABEAvwACAAIAgQEAzJkAvwEAABAA/wEIAAgAAQIA AAAAAAAQ8AQAAAAiAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAABEADwAE8GYAAABCAQrwCAAA ACMEAAAACgAAkwAL8DYAAAB/AAAABABEAQQAAAB/AQAAAQC/AQAAEADLAT7fAADQAQEAAADR AQEAAAD/ARgAGAABAgAAAAAAABDwBAAAACEAAAAAABHwBAAAAAMAAAAPAATwZgAAAKIMCvAI AAAAJAQAAAAKAABzAAvwKgAAAH8AAAAEAIAAAAAQAL8AAgACAIEBAMyZAL8BAAAQAP8BAAAI AAECAAAAAAAAEPAEAAAAIAAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAAQAA8ABPBsAAAAogwK 8AgAAAAlBAAAAAoAAIMAC/AwAAAAfwAAAAQAgAAAAA8AvwACAAIAgQEAzJkAvwEAABAAwAEz M8wA/wEIAAgAAQIAAAAAAAAQ8AQAAAAfAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAA8ADwAE 8GYAAABCAQrwCAAAACYEAAAACgAAkwAL8DYAAAB/AAAABABEAQQAAAB/AQAAAQC/AQAAEADL AT7fAADQAQEAAADRAQEAAAD/ARgAGAABAgAAAAAAABDwBAAAAB4AAAAAABHwBAAAAAMAAAAP AATwZgAAAKIMCvAIAAAAJwQAAAAKAABzAAvwKgAAAH8AAAAEAIAAAAAOAL8AAgACAIEBAMyZ AL8BAAAQAP8BAAAIAAECAAAAAAAAEPAEAAAAHQAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAAO AA8ABPBsAAAAogwK8AgAAAAoBAAAAAoAAIMAC/AwAAAAfwAAAAQAgAAAAA0AvwACAAIAgQEA zJkAvwEAABAAwAH/AAAA/wEIAAgAAQIAAAAAAAAQ8AQAAAAcAAAAAAAR8AQAAAADAAAAAAAN 8AQAAAAAAA0ADwAE8GwAAABCAQrwCAAAACkEAAAACgAAowAL8DwAAAB/AAAABABEAQQAAAB/ AQAAAQC/AQAAEADAAf8AAADLAT7fAADQAQEAAADRAQEAAAD/ARgAGAABAgAAAAAAABDwBAAA ABsAAAAAABHwBAAAAAMAAAAPAATwZgAAAKIMCvAIAAAAKgQAAAAKAABzAAvwKgAAAH8AAAAE AIAAAAAMAL8AAgACAIEBAMyZAL8BAAAQAP8BAAAIAAECAAAAAAAAEPAEAAAAGgAAAAAAEfAE AAAAAwAAAAAADfAEAAAAAAAMAA8ABPBsAAAAogwK8AgAAAArBAAAAAoAAIMAC/AwAAAAfwAA AAQAgAAAAAsAvwACAAIAgQEAzJkAvwEAABAAwAEzM8wA/wEIAAgAAQIAAAAAAAAQ8AQAAAAZ AAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAAsADwAE8GwAAACiDArwCAAAACwEAAAACgAAgwAL 8DAAAAB/AAAABACAAAAACgC/AAIAAgCBAQDMmQC/AQAAEADAATMzzAD/AQgACAABAgAAAAAA ABDwBAAAABgAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAACgAPAATwZgAAADIACvAIAAAALQQA AAAKAACTAAvwNgAAAH8AAAAEAIUAAgAAAIcAAQAAAIEBAMyZAL8BAAAQAMAB/wAAAMsBakoA AP8BCAAIAAECAAAAAAAAEPAEAAAAFwAAAAAAEfAEAAAAAwAAAA8ABPBsAAAAogwK8AgAAAAu BAAAAAoAAIMAC/AwAAAAfwAAAAQAgAAAAAkAvwACAAIAgQEAzJkAvwEAABAAwAEzM8wA/wEA AAgAAQIAAAAAAAAQ8AQAAAAWAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAAkADwAE8GwAAACi DArwCAAAAC8EAAAACgAAgwAL8DAAAAB/AAAABACAAAAACAC/AAIAAgCBAQDMmQC/AQAAEADA ATMzzAD/AQgACAABAgAAAAAAABDwBAAAABUAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAACAAP AATwbAAAAEIBCvAIAAAAMAQAAAAKAACjAAvwPAAAAH8AAAAEAEQBBAAAAH8BAAABAL8BAAAQ AMABMzPMAMsBPt8AANABAQAAANEBAQAAAP8BGAAYAAECAAAAAAAAEPAEAAAAFAAAAAAAEfAE AAAAAwAAAA8ABPByAAAAQgEK8AgAAAAxBAAAAAoAALMAC/BCAAAABAAnGjEAfwAAAAQARAEE AAAAfwEAAAEAvwEAABAAwAH/AAAAywE+3wAA0AEBAAAA0QEBAAAA/wEYABgAAQIAAAAAAAAQ 8AQAAAATAAAAAAAR8AQAAAADAAAADwAE8HIAAABCAQrwCAAAADIEAAAACgAAswAL8EIAAAAE AKNRxP9/AAAABABEAQQAAAB/AQAAAQC/AQAAEADAAf8AAADLAT7fAADQAQEAAADRAQEAAAD/ ARgAGAABAgAAAAAAABDwBAAAABIAAAAAABHwBAAAAAMAAAAPAATwcgAAAEIBCvAIAAAAMwQA AEAKAACzAAvwQgAAAAQA2eXO/38AAAAEAEQBBAAAAH8BAAABAL8BAAAQAMAB/wAAAMsBPt8A ANABAQAAANEBAQAAAP8BGAAYAAECAAAAAAAAEPAEAAAAEQAAAAAAEfAEAAAAAwAAAA8ABPBs AAAAEgAK8AgAAAA0BAAAAAoAAKMAC/A8AAAAfwAAAAQAhQACAAAAhwABAAAAgQEAzJkAvwEA ABAAwAEzmTMAywHUlAAAzgEIAAAA/wEIAAgAAQIAAAAAAAAQ8AQAAAAQAAAAAAAR8AQAAAAD AAAADwAE8GwAAACiDArwCAAAADUEAAAACgAAgwAL8DAAAAB/AAAABACAAAAABwC/AAIAAgCB AQDMmQC/AQAAEADAATOZMwD/AQAACAABAgAAAAAAABDwBAAAAA8AAAAAABHwBAAAAAMAAAAA AA3wBAAAAAAABwAPAATwbAAAABIACvAIAAAANgQAAAAKAACjAAvwPAAAAH8AAAAEAIUAAgAA AIcAAQAAAIEBAMyZAL8BAAAQAMABM5kzAMsB1JQAAM4BCAAAAP8BCAAIAAECAAAAAAAAEPAE AAAADgAAAAAAEfAEAAAAAwAAAA8ABPBsAAAAogwK8AgAAAA3BAAAAAoAAIMAC/AwAAAAfwAA AAQAgAAAAAYAvwACAAIAgQEAzJkAvwEAABAAwAEzmTMA/wEAAAgAAQIAAAAAAAAQ8AQAAAAN AAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAAYADwAE8GwAAAASAArwCAAAADgEAAAACgAAowAL 8DwAAAB/AAAABACFAAIAAACHAAEAAACBAQDMmQC/AQAAEADAATOZMwDLAdSUAADOAQgAAAD/ AQgACAABAgAAAAAAABDwBAAAAAwAAAAAABHwBAAAAAMAAAAPAATwbAAAAKIMCvAIAAAAOQQA AAAKAACDAAvwMAAAAH8AAAAEAIAAAAAFAL8AAgACAIEBAMyZAL8BAAAQAMABM5kzAP8BAAAI AAECAAAAAAAAEPAEAAAACwAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAAFAA8ABPBsAAAAEgAK 8AgAAAA6BAAAAAoAAKMAC/A8AAAAfwAAAAQAhQACAAAAhwABAAAAgQEAzJkAvwEAABAAwAEz mTMAywHUlAAAzgEIAAAA/wEIAAgAAQIAAAAAAAAQ8AQAAAAKAAAAAAAR8AQAAAADAAAADwAE 8GwAAACiDArwCAAAADsEAAAACgAAgwAL8DAAAAB/AAAABACAAAAABAC/AAIAAgCBAQDMmQC/ AQAAEADAATOZMwD/AQAACAABAgAAAAAAABDwBAAAAAkAAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAABAAPAATwBAEAAAIACvAIAAAAPAQAAAAKAABzAQvwwAAAAH8AAAAEAEIBBgUAAEMB7gYA AEQBBAAAAEXBHAAAAEbBFAAAAH8BAQABAIEBAMyZAIMB////AL8BAAAQAMABMzPMAMQBAAAA AMsB1JQAAM0BAAAAANABAQAAANEBAQAAANIBAQAAANMBAQAAANQBAQAAANUBAQAAAP8BGAAY AAECAAAAAIgDAAAAAAcABwDw/6QAAABSAHACAADgBLsA5wV2Ae4GPgOMBgYFKgYHAAgAAgAA QACtASAArQEgAKwAgCMAIvEMAAAAjwMAAAAAkQMAAAAAAAAQ8AQAAAAIAAAAAAAR8AQAAAAD AAAADwAE8GYAAACiDArwCAAAAD0EAAAACgAAcwAL8CoAAAB/AAAABACAAAAAAwC/AAIAAgCB AQDMmQC/AQAAEAD/AQgACAABAgAAAAAAABDwBAAAAAcAAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAAAwAPAATwZgAAAKIMCvAIAAAAPgQAAAAKAABzAAvwKgAAAH8AAAAEAIAAAAACAL8AAgAC AIEBAMyZAL8BAAAQAP8BAAAIAAECAAAAAAAAEPAEAAAABQAAAAAAEfAEAAAABAAAAAAADfAE AAAAAAACAA8ABPBmAAAAogwK8AgAAAA/BAAAAAoAAHMAC/AqAAAAfwAAAAQAgAAAAAEAvwAC AAIAgQEAzJkAvwEAABAA/wEAAAgAAQIAAAAAAAAQ8AQAAAAGAAAAAAAR8AQAAAAEAAAAAAAN 8AQAAAAAAAEADwAE8GYAAAASAArwCAAAAEAEAAAACgAAcwAL8CoAAAB/AAEABQCAAAAAIQCH AAEAAACBAQDMmQC/AQAAEQD/AQAACQABAgAAAAAAABDwBAAAACoAAAAAABHwBAAAAAIAAAAA AA3wBAAAAAAAIQAPAATwYAAAABIACvAIAAAAVwQAAAAKAABjAAvwJAAAAH8AAAAFAIAAAAAU AIEBAMyZAL8BAAARAP8BAAAJAAECAAAAAAAAEPAEAAAAKQAAAAAAEfAEAAAAAgAAAAAADfAE AAAAAAAUAA8ABPBmAAAAogwK8AgAAABYBAAAAAoAAHMAC/AqAAAAfwAAAAQAgAAAABMAvwAC AAIAgQEAzJkAvwEAABAA/wEAAAgAAQIAAAAAAAAQ8AQAAAArAAAAAAAR8AQAAAACAAAAAAAN 8AQAAAAAABMADwAE8GYAAACiDArwCAAAAFkEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAIgC/ AAIAAgCBAQDMmQC/AQAAEAD/AQAACAABAgAAAAAAABDwBAAAACgAAAAAABHwBAAAAAIAAAAA AA3wBAAAAAAAIgAPAATwZgAAABIACvAIAAAAWgQAAAAKAABzAAvwKgAAAH8AAQAFAIAAAAA5 AIcAAQAAAIEBAMyZAL8BAAARAP8BAAAJAAECAAAAAAAAEPAEAAAALwAAAAAAEfAEAAAAAwAA AAAADfAEAAAAAAA5AA8ABPBgAAAAEgAK8AgAAAB7BAAAAAoAAGMAC/AkAAAAfwAAAAUAgAAA ACQAgQEAzJkAvwEAABEA/wEAAAkAAQIAAAAAAAAQ8AQAAAAuAAAAAAAR8AQAAAADAAAAAAAN 8AQAAAAAACQADwAE8GYAAACiDArwCAAAAHwEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAIwC/ AAIAAgCBAQDMmQC/AQAAEAD/AQAACAABAgAAAAAAABDwBAAAAC0AAAAAABHwBAAAAAMAAAAA AA3wBAAAAAAAIwAPAATwZgAAABIACvAIAAAAfQQAAAAKAABzAAvwKgAAAH8AAQAFAIAAAABM AIcAAQAAAIEBAMyZAL8BAAARAP8BAAAJAAECAAAAAAAAEPAEAAAAMwAAAAAAEfAEAAAAAwAA AAAADfAEAAAAAABMAA8AA/C6DAAADwAE8IoAAAABAAnwEAAAAJEDAADAAgAAqBUAAHALAAAC AArwCAAAAH4EAAABAgAAIwAL8AwAAAB/AAAABACIAwAAAABDACLxLgAAAI8DAAAAAJEDAAAA AJ8DAwAAAKDDFgAAAAQACAAEAKsAAAALAgAA0wIAAKMCAAAAABDwBAAAADEAAAAAABHwBAAA AAEAAAAPAATweAAAABIACvAIAAAAfwQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABLAL8AAAAC AIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAqBAAAKcIAACoFQAAcAsA AAAAEfAEAAAABQAAAAAADfAEAAAAAABLAA8ABPB4AAAAEgAK8AgAAACABAAAAgoAAIMAC/Aw AAAAfwAAAAQAgAAAAEoAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP 8BAAAACyCwAApwgAAKgQAABwCwAAAAAR8AQAAAAFAAAAAAAN8AQAAAAAAEoADwAE8HgAAAAS AArwCAAAAIEEAAACCgAAgwAL8DAAAAB/AAAABACAAAAASQC/AAAAAgCBAQDMmQC/AQEAFQD/ AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAHQHAACnCAAAsgsAAHALAAAAABHwBAAAAAUAAAAA AA3wBAAAAAAASQAPAATweAAAABIACvAIAAAAggQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABI AL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAkQMAAKcIAAB0 BwAAcAsAAAAAEfAEAAAABQAAAAAADfAEAAAAAABIAA8ABPB4AAAAEgAK8AgAAACDBAAAAgoA AIMAC/AwAAAAfwAAAAQAgAAAAEcAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIA AAIAAAAP8BAAAACoEAAA1AUAAKgVAACnCAAAAAAR8AQAAAAFAAAAAAAN8AQAAAAAAEcADwAE 8HgAAAASAArwCAAAAIQEAAACCgAAgwAL8DAAAAB/AAAABACAAAAARgC/AAAAAgCBAQDMmQC/ AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAALILAADUBQAAqBAAAKcIAAAAABHwBAAA AAUAAAAAAA3wBAAAAAAARgAPAATweAAAABIACvAIAAAAhQQAAAIKAACDAAvwMAAAAH8AAAAE AIAAAABFAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAdAcA ANQFAACyCwAApwgAAAAAEfAEAAAABQAAAAAADfAEAAAAAABFAA8ABPB4AAAAEgAK8AgAAACG BAAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAEQAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIA AAAAPwIAAAIAAAAP8BAAAACRAwAA1AUAAHQHAACnCAAAAAAR8AQAAAAFAAAAAAAN8AQAAAAA AEQADwAE8HgAAAASAArwCAAAAIcEAAACCgAAgwAL8DAAAAB/AAAABACAAAAAQwC/AAAAAgCB AQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAKgQAACvAwAAqBUAANQFAAAA ABHwBAAAAAUAAAAAAA3wBAAAAAAAQwAPAATweAAAABIACvAIAAAAiAQAAAIKAACDAAvwMAAA AH8AAAAEAIAAAABCAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQ AAAAsgsAAK8DAACoEAAA1AUAAAAAEfAEAAAABQAAAAAADfAEAAAAAABCAA8ABPB4AAAAEgAK 8AgAAACJBAAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAEEAvwAAAAIAgQEAzJkAvwEBABUA/wEA AAgAAQIAAAAAPwIAAAIAAAAP8BAAAAB0BwAArwMAALILAADUBQAAAAAR8AQAAAAFAAAAAAAN 8AQAAAAAAEEADwAE8HgAAAASAArwCAAAAIoEAAACCgAAgwAL8DAAAAB/AAAABACAAAAAQAC/ AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAJEDAACvAwAAdAcA ANQFAAAAABHwBAAAAAUAAAAAAA3wBAAAAAAAQAAPAATweAAAABIACvAIAAAAiwQAAAIKAACD AAvwMAAAAH8AAAAEAIAAAAA/AL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAAC AAAAD/AQAAAAqBAAAMACAACoFQAArwMAAAAAEfAEAAAABQAAAAAADfAEAAAAAAA/AA8ABPB4 AAAAEgAK8AgAAACMBAAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAD4AvwAAAAIAgQEAzJkAvwEB ABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAACyCwAAwAIAAKgQAACvAwAAAAAR8AQAAAAF AAAAAAAN8AQAAAAAAD4ADwAE8HgAAAASAArwCAAAAI0EAAACCgAAgwAL8DAAAAB/AAAABACA AAAAPQC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAHQHAADA AgAAsgsAAK8DAAAAABHwBAAAAAUAAAAAAA3wBAAAAAAAPQAPAATweAAAABIACvAIAAAAjgQA AAIKAACDAAvwMAAAAH8AAAAEAIAAAAA8AL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAAkQMAAMACAAB0BwAArwMAAAAAEfAEAAAABQAAAAAADfAEAAAAAAA8 AA8ABPBmAAAAQgEK8AgAAACPBAAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEBAAAA/wEI AAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAACRAwAAwAIAAKgVAADAAgAAAAAR8AQAAAAF AAAADwAE8GAAAABCAQrwCAAAAJAEAAACCgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/AQgACgAB AgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAJEDAACvAwAAqBUAAK8DAAAAABHwBAAAAAUAAAAP AATwZgAAAEIBCvAIAAAAkQQAAAIKAABzAAvwKgAAAL8BAAAQAMsBn28AANcBAQAAAP8BCAAK AAECAAAAAD8CAAACAL8CAAAIAAAAD/AQAAAAkQMAAHALAACoFQAAcAsAAAAAEfAEAAAABQAA AA8ABPBmAAAAQgEK8AgAAACSBAAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEBAAAA/wEI AAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAACRAwAAwAIAAJEDAABwCwAAAAAR8AQAAAAF AAAADwAE8GAAAABCAQrwCAAAAJMEAAACCgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/AQgACgAB AgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAHQHAADAAgAAdAcAAHALAAAAABHwBAAAAAUAAAAP AATwYAAAAEIBCvAIAAAAlAQAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAA AD8CAAACAL8CAAAIAAAAD/AQAAAAsgsAAMACAACyCwAAcAsAAAAAEfAEAAAABQAAAA8ABPBg AAAAQgEK8AgAAACVBAAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIA AAIAvwIAAAgAAAAP8BAAAACoEAAAwAIAAKgQAABwCwAAAAAR8AQAAAAFAAAADwAE8GYAAABC AQrwCAAAAJYEAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgABAgAAAAA/ AgAAAgC/AgAACAAAAA/wEAAAAKgVAADAAgAAqBUAAHALAAAAABHwBAAAAAUAAAAPAATwYAAA AEIBCvAIAAAAlwQAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAAC AL8CAAAIAAAAD/AQAAAAkQMAANQFAACoFQAA1AUAAAAAEfAEAAAABQAAAA8ABPBgAAAAQgEK 8AgAAACYBAAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIA AAgAAAAP8BAAAACRAwAApwgAAKgVAACnCAAAAAAR8AQAAAAFAAAADwAE8GAAAAASAArwCAAA AJkEAAAACgAAYwAL8CQAAAB/AAAABQCAAAAAOwCBAQDMmQC/AQAAEQD/AQAACQABAgAAAAAA ABDwBAAAADAAAAAAABHwBAAAAAUAAAAAAA3wBAAAAAAAOwAPAATwZgAAAKIMCvAIAAAAmgQA AAAKAABzAAvwKgAAAH8AAAAEAIAAAAA6AL8AAgACAIEBAMyZAL8BAAAQAP8BAAAIAAECAAAA AAAAEPAEAAAAMgAAAAAAEfAEAAAABQAAAAAADfAEAAAAAAA6AA8ABPBmAAAAEgAK8AgAAACb BAAAAAoAAHMAC/AqAAAAfwABAAUAgAAAAF8AhwABAAAAgQEAzJkAvwEAABEA/wEAAAkAAQIA AAAAAAAQ8AQAAAA3AAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAF8ADwAE8GAAAAASAArwCAAA ALcEAAAACgAAYwAL8CQAAAB/AAAABQCAAAAATgCBAQDMmQC/AQAAEQD/AQAACQABAgAAAAAA ABDwBAAAADYAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAATgAPAATwZgAAAKIMCvAIAAAAuAQA AAAKAABzAAvwKgAAAH8AAAAEAIAAAABNAL8AAgACAIEBAMyZAL8BAAAQAP8BAAAIAAECAAAA AAAAEPAEAAAANQAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAABNAA8ABPBmAAAAEgAK8AgAAAC5 BAAAAAoAAHMAC/AqAAAAfwABAAUAgAAAAG4AhwABAAAAgQEAzJkAvwEAABEA/wEAAAkAAQIA AAAAAAAQ8AQAAAA7AAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAG4ADwAD8E4KAAAPAATwhgAA AAEACfAQAAAAygIAAPkCAADKFQAAOgoAAAIACvAIAAAAugQAAAECAAAjAAvwDAAAAH8AAAAE AIgDAAAAAEMAIvEqAAAAjwMAAAAAkQMAAAAAnwMDAAAAoMMSAAAAAwAEAAQAUQEAAAsCAADT AgAAAAAQ8AQAAAA6AAAAAAAR8AQAAAABAAAADwAE8HgAAAASAArwCAAAALsEAAACCgAAgwAL 8DAAAAB/AAAABACAAAAAbQC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAA AA/wEAAAAPoSAABnBwAAyhUAADoKAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAbQAPAATweAAA ABIACvAIAAAAvAQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABsAL8AAAACAIEBAMyZAL8BAQAV AP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAUQ4AAGcHAAD6EgAAOgoAAAAAEfAEAAAAAwAA AAAADfAEAAAAAABsAA8ABPB4AAAAEgAK8AgAAAC9BAAAAgoAAIMAC/AwAAAAfwAAAAQAgAAA AGsAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAACxBgAAZwcA AFEOAAA6CgAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAGsADwAE8HgAAAASAArwCAAAAL4EAAAC CgAAgwAL8DAAAAB/AAAABACAAAAAagC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/ AgAAAgAAAA/wEAAAAMoCAABnBwAAsQYAADoKAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAagAP AATweAAAABIACvAIAAAAvwQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABpAL8AAAACAIEBAMyZ AL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAA+hIAAJ4EAADKFQAAZwcAAAAAEfAE AAAAAwAAAAAADfAEAAAAAABpAA8ABPB4AAAAEgAK8AgAAADABAAAAgoAAIMAC/AwAAAAfwAA AAQAgAAAAGgAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAABR DgAAngQAAPoSAABnBwAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAGgADwAE8HgAAAASAArwCAAA AMEEAAACCgAAgwAL8DAAAAB/AAAABACAAAAAZwC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAAB AgAAAAA/AgAAAgAAAA/wEAAAALEGAACeBAAAUQ4AAGcHAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAAZwAPAATweAAAABIACvAIAAAAwgQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABmAL8AAAAC AIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAygIAAJ4EAACxBgAAZwcA AAAAEfAEAAAAAwAAAAAADfAEAAAAAABmAA8ABPB4AAAAEgAK8AgAAADDBAAAAgoAAIMAC/Aw AAAAfwAAAAQAgAAAAGUAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP 8BAAAAD6EgAA+QIAAMoVAACeBAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAGUADwAE8HgAAAAS AArwCAAAAMQEAAACCgAAgwAL8DAAAAB/AAAABACAAAAAZAC/AAAAAgCBAQDMmQC/AQEAFQD/ AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAFEOAAD5AgAA+hIAAJ4EAAAAABHwBAAAAAMAAAAA AA3wBAAAAAAAZAAPAATweAAAABIACvAIAAAAxQQAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABj AL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAsQYAAPkCAABR DgAAngQAAAAAEfAEAAAAAwAAAAAADfAEAAAAAABjAA8ABPB4AAAAEgAK8AgAAADGBAAAAgoA AIMAC/AwAAAAfwAAAAQAgAAAAGIAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIA AAIAAAAP8BAAAADKAgAA+QIAALEGAACeBAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAGIADwAE 8GYAAABCAQrwCAAAAMcEAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgAB AgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAMoCAAD5AgAAyhUAAPkCAAAAABHwBAAAAAMAAAAP AATwYAAAAEIBCvAIAAAAyAQAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAA AD8CAAACAL8CAAAIAAAAD/AQAAAAygIAAJ4EAADKFQAAngQAAAAAEfAEAAAAAwAAAA8ABPBm AAAAQgEK8AgAAADJBAAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEBAAAA/wEIAAoAAQIA AAAAPwIAAAIAvwIAAAgAAAAP8BAAAADKAgAAOgoAAMoVAAA6CgAAAAAR8AQAAAADAAAADwAE 8GYAAABCAQrwCAAAAMoEAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgAB AgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAMoCAAD5AgAAygIAADoKAAAAABHwBAAAAAMAAAAP AATwYAAAAEIBCvAIAAAAywQAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAA AD8CAAACAL8CAAAIAAAAD/AQAAAAsQYAAPkCAACxBgAAOgoAAAAAEfAEAAAAAwAAAA8ABPBg AAAAQgEK8AgAAADMBAAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIA AAIAvwIAAAgAAAAP8BAAAABRDgAA+QIAAFEOAAA6CgAAAAAR8AQAAAADAAAADwAE8GAAAABC AQrwCAAAAM0EAAACCgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/AQgACgABAgAAAAA/AgAAAgC/ AgAACAAAAA/wEAAAAPoSAAD5AgAA+hIAADoKAAAAABHwBAAAAAMAAAAPAATwZgAAAEIBCvAI AAAAzgQAAAIKAABzAAvwKgAAAL8BAAAQAMsBn28AANcBAQAAAP8BCAAKAAECAAAAAD8CAAAC AL8CAAAIAAAAD/AQAAAAyhUAAPkCAADKFQAAOgoAAAAAEfAEAAAAAwAAAA8ABPBgAAAAQgEK 8AgAAADPBAAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIA AAgAAAAP8BAAAADKAgAAZwcAAMoVAABnBwAAAAAR8AQAAAADAAAADwAE8GAAAAASAArwCAAA ANAEAAAACgAAYwAL8CQAAAB/AAAABQCAAAAAYQCBAQDMmQC/AQAAEQD/AQAACQABAgAAAAAA ABDwBAAAADkAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAYQAPAATwZgAAAKIMCvAIAAAA0QQA AAAKAABzAAvwKgAAAH8AAAAEAIAAAABgAL8AAgACAIEBAMyZAL8BAAAQAP8BAAAIAAECAAAA AAAAEPAEAAAAOAAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAABgAA8ABPBmAAAAEgAK8AgAAADS BAAAAAoAAHMAC/AqAAAAfwABAAUAgAAAAIIAhwABAAAAgQEAzJkAvwEAABEA/wEAAAkAAQIA AAAAAAAQ8AQAAABgAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAIIADwAE8GYAAACiDArwCAAA ANMEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAgQC/AAIAAgCBAQDMmQC/AQAAEAD/AQgACAAB AgAAAAAAABDwBAAAAF8AAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAgQAPAATwZgAAAEIBCvAI AAAA1AQAAAAKAACTAAvwNgAAAH8AAAAEAEQBBAAAAH8BAAABAL8BAAAQAMsBPt8AANABAQAA ANEBAQAAAP8BGAAYAAECAAAAAAAAEPAEAAAAXgAAAAAAEfAEAAAAAwAAAA8ABPBmAAAAogwK 8AgAAADVBAAAAAoAAHMAC/AqAAAAfwAAAAQAgAAAAIAAvwACAAIAgQEAzJkAvwEAABAA/wEA AAgAAQIAAAAAAAAQ8AQAAABdAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAIAADwAE8GwAAACi DArwCAAAANYEAAAACgAAgwAL8DAAAAB/AAAABACAAAAAfwC/AAIAAgCBAQDMmQC/AQAAEADA ATMzzAD/AQgACAABAgAAAAAAABDwBAAAAFwAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAfwAP AATwZgAAAEIBCvAIAAAA1wQAAAAKAACTAAvwNgAAAH8AAAAEAEQBBAAAAH8BAAABAL8BAAAQ AMsBPt8AANABAQAAANEBAQAAAP8BGAAYAAECAAAAAAAAEPAEAAAAWwAAAAAAEfAEAAAAAwAA AA8ABPBmAAAAogwK8AgAAADYBAAAAAoAAHMAC/AqAAAAfwAAAAQAgAAAAH4AvwACAAIAgQEA zJkAvwEAABAA/wEAAAgAAQIAAAAAAAAQ8AQAAABaAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAA AH4ADwAE8GwAAACiDArwCAAAANkEAAAACgAAgwAL8DAAAAB/AAAABACAAAAAfQC/AAIAAgCB AQDMmQC/AQAAEADAAf8AAAD/AQgACAABAgAAAAAAABDwBAAAAFkAAAAAABHwBAAAAAMAAAAA AA3wBAAAAAAAfQAPAATwbAAAAEIBCvAIAAAA2gQAAAAKAACjAAvwPAAAAH8AAAAEAEQBBAAA AH8BAAABAL8BAAAQAMAB/wAAAMsBPt8AANABAQAAANEBAQAAAP8BGAAYAAECAAAAAAAAEPAE AAAAWAAAAAAAEfAEAAAAAwAAAA8ABPBmAAAAogwK8AgAAADbBAAAAAoAAHMAC/AqAAAAfwAA AAQAgAAAAHwAvwACAAIAgQEAzJkAvwEAABAA/wEAAAgAAQIAAAAAAAAQ8AQAAABXAAAAAAAR 8AQAAAADAAAAAAAN8AQAAAAAAHwADwAE8GwAAACiDArwCAAAANwEAAAACgAAgwAL8DAAAAB/ AAAABACAAAAAewC/AAIAAgCBAQDMmQC/AQAAEADAATMzzAD/AQgACAABAgAAAAAAABDwBAAA AFYAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAewAPAATwbAAAAKIMCvAIAAAA3QQAAAAKAACD AAvwMAAAAH8AAAAEAIAAAAB6AL8AAgACAIEBAMyZAL8BAAAQAMABMzPMAP8BCAAIAAECAAAA AAAAEPAEAAAAVQAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAB6AA8ABPBmAAAAMgAK8AgAAADe BAAAAAoAAJMAC/A2AAAAfwAAAAQAhQACAAAAhwABAAAAgQEAzJkAvwEAABAAwAH/AAAAywFq SgAA/wEIAAgAAQIAAAAAAAAQ8AQAAABUAAAAAAAR8AQAAAADAAAADwAE8GwAAACiDArwCAAA AN8EAAAACgAAgwAL8DAAAAB/AAAABACAAAAAeQC/AAIAAgCBAQDMmQC/AQAAEADAATMzzAD/ AQAACAABAgAAAAAAABDwBAAAAFMAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAeQAPAATwbAAA AKIMCvAIAAAA4AQAAAAKAACDAAvwMAAAAH8AAAAEAIAAAAB4AL8AAgACAIEBAMyZAL8BAAAQ AMABMzPMAP8BCAAIAAECAAAAAAAAEPAEAAAAUgAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAB4 AA8ABPBsAAAAQgEK8AgAAADhBAAAAAoAAKMAC/A8AAAAfwAAAAQARAEEAAAAfwEAAAEAvwEA ABAAwAEzM8wAywE+3wAA0AEBAAAA0QEBAAAA/wEYABgAAQIAAAAAAAAQ8AQAAABRAAAAAAAR 8AQAAAADAAAADwAE8HIAAABCAQrwCAAAAOIEAAAACgAAswAL8EIAAAAEACcaMQB/AAAABABE AQQAAAB/AQAAAQC/AQAAEADAAf8AAADLAT7fAADQAQEAAADRAQEAAAD/ARgAGAABAgAAAAAA ABDwBAAAAFAAAAAAABHwBAAAAAMAAAAPAATwcgAAAEIBCvAIAAAA4wQAAAAKAACzAAvwQgAA AAQAo1HE/38AAAAEAEQBBAAAAH8BAAABAL8BAAAQAMAB/wAAAMsBPt8AANABAQAAANEBAQAA AP8BGAAYAAECAAAAAAAAEPAEAAAATwAAAAAAEfAEAAAAAwAAAA8ABPByAAAAQgEK8AgAAADk BAAAQAoAALMAC/BCAAAABADZ5c7/fwAAAAQARAEEAAAAfwEAAAEAvwEAABAAwAH/AAAAywE+ 3wAA0AEBAAAA0QEBAAAA/wEYABgAAQIAAAAAAAAQ8AQAAABOAAAAAAAR8AQAAAADAAAADwAE 8GwAAAASAArwCAAAAOUEAAAACgAAowAL8DwAAAB/AAAABACFAAIAAACHAAEAAACBAQDMmQC/ AQAAEADAATOZMwDLAdSUAADOAQgAAAD/AQgACAABAgAAAAAAABDwBAAAAE0AAAAAABHwBAAA AAMAAAAPAATwbAAAAKIMCvAIAAAA5gQAAAAKAACDAAvwMAAAAH8AAAAEAIAAAAB3AL8AAgAC AIEBAMyZAL8BAAAQAMABM5kzAP8BAAAIAAECAAAAAAAAEPAEAAAATAAAAAAAEfAEAAAAAwAA AAAADfAEAAAAAAB3AA8ABPBsAAAAEgAK8AgAAADnBAAAAAoAAKMAC/A8AAAAfwAAAAQAhQAC AAAAhwABAAAAgQEAzJkAvwEAABAAwAEzmTMAywHUlAAAzgEIAAAA/wEIAAgAAQIAAAAAAAAQ 8AQAAABLAAAAAAAR8AQAAAADAAAADwAE8GwAAACiDArwCAAAAOgEAAAACgAAgwAL8DAAAAB/ AAAABACAAAAAdgC/AAIAAgCBAQDMmQC/AQAAEADAATOZMwD/AQAACAABAgAAAAAAABDwBAAA AEoAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAdgAPAATwbAAAABIACvAIAAAA6QQAAAAKAACj AAvwPAAAAH8AAAAEAIUAAgAAAIcAAQAAAIEBAMyZAL8BAAAQAMABM5kzAMsB1JQAAM4BCAAA AP8BCAAIAAECAAAAAAAAEPAEAAAASQAAAAAAEfAEAAAAAwAAAA8ABPBsAAAAogwK8AgAAADq BAAAAAoAAIMAC/AwAAAAfwAAAAQAgAAAAHUAvwACAAIAgQEAzJkAvwEAABAAwAEzmTMA/wEA AAgAAQIAAAAAAAAQ8AQAAABIAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAHUADwAE8GwAAAAS AArwCAAAAOsEAAAACgAAowAL8DwAAAB/AAAABACFAAIAAACHAAEAAACBAQDMmQC/AQAAEADA ATOZMwDLAdSUAADOAQgAAAD/AQgACAABAgAAAAAAABDwBAAAAEcAAAAAABHwBAAAAAMAAAAP AATwBAEAAAIACvAIAAAA7AQAAAAKAABzAQvwwAAAAH8AAAAEAEIBBgUAAEMB7gYAAEQBBAAA AEXBHAAAAEbBFAAAAH8BAQABAIEBAMyZAIMB////AL8BAAAQAMABMzPMAMQBAAAAAMsB1JQA AM0BAAAAANABAQAAANEBAQAAANIBAQAAANMBAQAAANQBAQAAANUBAQAAAP8BGAAYAAECAAAA AIgDAAAAAAcABwDw/6QAAABSAHACAADgBLsA5wV2Ae4GPgOMBgYFKgYHAAgAAgAAQACtASAA rQEgAKwAgCMAIvEMAAAAjwMAAAAAkQMAAAAAAAAQ8AQAAABGAAAAAAAR8AQAAAADAAAADwAE 8GwAAACiDArwCAAAAO0EAAAACgAAgwAL8DAAAAB/AAAABACAAAAAdAC/AAIAAgCBATOZMwC/ AQAAEADAAcwAAAD/AQgACAABAgAAAAAAABDwBAAAAEUAAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAAdAAPAATwYAAAAEIBCvAIAAAA7gQAAEAKAACDAAvwMAAAAH8AAAAEAEQBBAAAAH8BAAAB AL8BAAAQAMABzAAAAMsBakoAAP8BGAAYAAECAAAAAAAAEPAEAAAARAAAAAAAEfAEAAAAAwAA AA8ABPBgAAAAQgEK8AgAAADvBAAAQAoAAIMAC/AwAAAAfwAAAAQARAEEAAAAfwEAAAEAvwEA ABAAwAHMAAAAywFqSgAA/wEYABgAAQIAAAAAAAAQ8AQAAABDAAAAAAAR8AQAAAADAAAADwAE 8GYAAACiDArwCAAAAPAEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAcwC/AAIAAgC/ARAAEADA AcwAAAD/AQgACAABAgAAAAAAABDwBAAAAEIAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAcwAP AATwZgAAAKIMCvAIAAAA8QQAAAAKAABzAAvwKgAAAH8AAAAEAIAAAAByAL8AAgACAL8BEAAQ AMABzAAAAP8BCAAIAAECAAAAAAAAEPAEAAAAQQAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAABy AA8ABPBgAAAAQgEK8AgAAADyBAAAQAoAAIMAC/AwAAAAfwAAAAQARAEEAAAAfwEAAAEAvwEA ABAAwAHMAAAAywFqSgAA/wEYABgAAQIAAAAAAAAQ8AQAAABAAAAAAAAR8AQAAAADAAAADwAE 8GYAAACiDArwCAAAAPMEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAcQC/AAIAAgC/ARAAEADA AcwAAAD/AQgACAABAgAAAAAAABDwBAAAAD8AAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAcQAP AATwYAAAAEIBCvAIAAAA9AQAAEAKAACDAAvwMAAAAH8AAAAEAEQBBAAAAH8BAAABAL8BAAAQ AMABzAAAAMsBakoAAP8BGAAYAAECAAAAAAAAEPAEAAAAPgAAAAAAEfAEAAAAAwAAAA8ABPBs AAAAogwK8AgAAAD1BAAAAAoAAIMAC/AwAAAAfwAAAAQAgAAAAHAAvwACAAIAgQEAzJkAvwEA ABAAwAEzmTMA/wEAAAgAAQIAAAAAAAAQ8AQAAAA9AAAAAAAR8AQAAAADAAAAAAAN8AQAAAAA AHAADwAE8GYAAACiDArwCAAAAPYEAAAACgAAcwAL8CoAAAB/AAAABACAAAAAbwC/AAIAAgCB AQDMmQC/AQAAEAD/AQAACAABAgAAAAAAABDwBAAAADwAAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAAbwAPAATwZgAAAKIMCvAIAAAAJAUAAAAKAABzAAvwKgAAAH8AAAAEAIAAAACDAL8AAgAC AIEBAMyZAL8BAAAQAP8BAAAIAAECAAAAAAAAEPAEAAAAYgAAAAAAEfAEAAAAAwAAAAAADfAE AAAAAACDAA8ABPBsAAAAEgAK8AgAAABTBQAAAAoAAIMAC/AwAAAAfwABAAUAgAAAAJsAhwAB AAAAgQEAzJkAvwEAABEAwAEAAP8A/wEAAAkAAQIAAAAAAAAQ8AQAAAACAAAAAAAR8AQAAAAD AAAAAAAN8AQAAAAAAJsADwAD8JIFAAAPAATwaAAAAAEACfAQAAAAEAMAANADAAD4EwAAmQ4A AAIACvAIAAAAVAUAAAECAAAjAAvwDAAAAH8AAAAEAIgDAAAAACMAIvEMAAAAjwMAAAAAkQMA AAAAAAAQ8AQAAAABAAAAAAAR8AQAAAABAAAADwAE8IQAAABCAQrwCAAAAFUFAAACCgAAwwAL 8EgAAABEAQQAAAB/AQAAAQC/AQAAEADAARJDzgDLAdSUAADSAQAAAADTAQAAAADUAQAAAADV AQAAAAD/ARgAGAABAgAAAAA/AgAAAgAAAA/wEAAAAJgDAAC4BAAASAgAALAIAAAAABHwBAAA AAMAAAAPAATwhAAAAEIBCvAIAAAAVgUAAIIKAADDAAvwSAAAAEQBBAAAAH8BAAABAL8BAAAQ AMABEkPOAMsBn28AANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BGAAYAAECAAAAAD8CAAAC AAAAD/AQAAAAGAoAAIgEAAAoDwAAkAgAAAAAEfAEAAAAAwAAAA8ABPCKAAAAMgAK8AgAAABX BQAAAgoAANMAC/BOAAAAhQACAAAAhwABAAAAgQEAzJkAvwEAABAAwAGlACEAywGfbwAA0gEA AAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEIAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAC4BwAAaAgA AJAKAAAACgAAAAAR8AQAAAADAAAADwAE8JAAAACiDArwCAAAAFgFAAACCgAAwwAL8EgAAACA AAAAmgC/AAIAAgCBAQDMmQC/AQAAEADAAQAA/wDSAQAAAADTAQAAAADUAQAAAADVAQAAAAD/ AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAACgIAACoCAAAoAoAAI8JAAAAABHwBAAAAAMAAAAA AA3wBAAAAAAAmgAPAATwkAAAAKIMCvAIAAAAWQUAAAIKAADDAAvwSAAAAIAAAACZAL8AAgAC AIEBAMyZAL8BAAAQAMABAAD/ANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAAgAQAANADAAAwDgAAEQYAAAAAEfAEAAAAAwAAAAAADfAEAAAAAACZ AA8ABPCEAAAAQgEK8AgAAABaBQAAQgoAAMMAC/BIAAAARAEEAAAAfwEAAAEAvwEAABAAwAEA MwAAywGfbwAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEYABgAAQIAAAAAPwIAAAIAAAAP 8BAAAAAQAwAA0AkAACAIAAAYDQAAAAAR8AQAAAADAAAADwAE8IQAAABCAQrwCAAAAFsFAAAC CgAAwwAL8EgAAABEAQQAAAB/AQAAAQC/AQAAEADAAQAzAADLAZ9vAADSAQAAAADTAQAAAADU AQAAAADVAQAAAAD/ARgAGAABAgAAAAA/AgAAAgAAAA/wEAAAADAKAADACQAAiA8AAGANAAAA ABHwBAAAAAMAAAAPAATwkAAAAKIMCvAIAAAAXAUAAAIKAADDAAvwSAAAAIAAAACYAL8AAgAC AIEBAMyZAL8BAAAQAMABAAD/ANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAASAQAAFgMAAD4DQAAmQ4AAAAAEfAEAAAAAwAAAAAADfAEAAAAAACY AA8ABPCQAAAAogwK8AgAAABdBQAAAgoAAMMAC/BIAAAAgAAAAJcAvwACAAIAgQEAzJkAvwEA ABAAwAEAAP8A0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEAAAgAAQIAAAAAPwIAAAIAAAAP 8BAAAABICgAA+AcAAPgTAAA5CgAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAJcADwAE8IoAAABC AQrwCAAAAF4FAAAACgAA8wAL8FoAAAB/AAAABABEAQQAAAB/AQAAAQC/AQAAEADAARJDzgDL AZ9vAADOAQYAAADRAQEAAADSAQAAAADTAQAAAADUAQAAAADVAQAAAAD/ARgAGAABAgAAAAA/ AgAAAgAAABDwBAAAAAAAAAAAABHwBAAAAAMAAAAPAATwigAAAEIBCvAIAAAAXwUAAAAKAADz AAvwWgAAAH8AAAAEAEQBBAAAAH8BAAABAL8BAAAQAMABADMAAMsBn28AAM4BBgAAANEBAQAA ANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BGAAYAAECAAAAAD8CAAACAAAAEPAEAAAABAAA AAAAEfAEAAAAAwAAAA8ABPBsAAAAogwK8AgAAABgBQAAAAoAAIMAC/AwAAAAfwAAAAQAgAAA AJYAvwACAAIAgQEAzJkAvwEAABAAwAEAAP8A/wEAAAgAAQIAAAAAAAAQ8AQAAAADAAAAAAAR 8AQAAAADAAAAAAAN8AQAAAAAAJYADwAE8GYAAAASAArwCAAAAGEFAAAACgAAcwAL8CoAAAB/ AAEABQCAAAAAlQCHAAEAAACBAQDMmQC/AQAAEQD/AQAACQABAgAAAAAAABDwBAAAACYAAAAA ABHwBAAAAAUAAAAAAA3wBAAAAAAAlQAPAATwYAAAABIACvAIAAAAYgUAAAAKAABjAAvwJAAA AH8AAQAFAIAAAACUAIEBAMyZAL8BAAARAP8BAAAJAAECAAAAAAAAEPAEAAAAJQAAAAAAEfAE AAAACwAAAAAADfAEAAAAAACUAA8ABPBmAAAAogwK8AgAAABjBQAAAAoAAHMAC/AqAAAAfwAA AAQAgAAAAJMAvwACAAIAgQEAzJkAvwEAABAA/wEAAAgAAQIAAAAAAAAQ8AQAAAAkAAAAAAAR 8AQAAAACAAAAAAAN8AQAAAAAAJMADwAD8E4KAAAPAATwhgAAAAEACfAQAAAAvAIAAJMDAAC3 EwAAzAgAAAIACvAIAAAAZAUAAAECAAAjAAvwDAAAAH8AAAAEAIgDAAAAAEMAIvEqAAAAjwMA AAAAkQMAAAAAnwMDAAAAoMMSAAAAAwAEAAQAsQAAANEBAADpAQAAAAAQ8AQAAAAnAAAAAAAR 8AQAAAABAAAADwAE8HgAAAASAArwCAAAAGUFAAACCgAAgwAL8DAAAAB/AAAABACAAAAAIAC/ AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAE4PAACnBgAAtxMA AMwIAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAIAAPAATweAAAABIACvAIAAAAZgUAAAIKAACD AAvwMAAAAH8AAAAEAIAAAAAfAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAAC AAAAD/AQAAAATgoAAKcGAABODwAAzAgAAAAAEfAEAAAABAAAAAAADfAEAAAAAAAfAA8ABPB4 AAAAEgAK8AgAAABnBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAB4AvwAAAAIAgQEAzJkAvwEB ABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAB6BgAApwYAAE4KAADMCAAAAAAR8AQAAAAE AAAAAAAN8AQAAAAAAB4ADwAE8HgAAAASAArwCAAAAGgFAAACCgAAgwAL8DAAAAB/AAAABACA AAAAHQC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAALwCAACn BgAAegYAAMwIAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAHQAPAATweAAAABIACvAIAAAAaQUA AAIKAACDAAvwMAAAAH8AAAAEAIAAAAAcAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAATg8AAIIEAAC3EwAApwYAAAAAEfAEAAAABAAAAAAADfAEAAAAAAAc AA8ABPB4AAAAEgAK8AgAAABqBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAABsAvwAAAAIAgQEA zJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAABOCgAAggQAAE4PAACnBgAAAAAR 8AQAAAAEAAAAAAAN8AQAAAAAABsADwAE8HgAAAASAArwCAAAAGsFAAACCgAAgwAL8DAAAAB/ AAAABACAAAAAGgC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAA AHoGAACCBAAATgoAAKcGAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAGgAPAATweAAAABIACvAI AAAAbAUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAAAZAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAI AAECAAAAAD8CAAACAAAAD/AQAAAAvAIAAIIEAAB6BgAApwYAAAAAEfAEAAAABAAAAAAADfAE AAAAAAAZAA8ABPB4AAAAEgAK8AgAAABtBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAABgAvwAA AAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAABODwAAkwMAALcTAACC BAAAAAAR8AQAAAAEAAAAAAAN8AQAAAAAABgADwAE8HgAAAASAArwCAAAAG4FAAACCgAAgwAL 8DAAAAB/AAAABACAAAAAFwC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAA AA/wEAAAAE4KAACTAwAATg8AAIIEAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAFwAPAATweAAA ABIACvAIAAAAbwUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAAAWAL8AAAACAIEBAMyZAL8BAQAV AP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAegYAAJMDAABOCgAAggQAAAAAEfAEAAAABAAA AAAADfAEAAAAAAAWAA8ABPB4AAAAEgAK8AgAAABwBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAA ABUAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAC8AgAAkwMA AHoGAACCBAAAAAAR8AQAAAAEAAAAAAAN8AQAAAAAABUADwAE8GYAAABCAQrwCAAAAHEFAAAC CgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgABAgAAAAA/AgAAAgC/AgAACAAA AA/wEAAAALwCAACTAwAAtxMAAJMDAAAAABHwBAAAAAQAAAAPAATwYAAAAEIBCvAIAAAAcgUA AAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQ AAAAvAIAAIIEAAC3EwAAggQAAAAAEfAEAAAABAAAAA8ABPBmAAAAQgEK8AgAAABzBQAAAgoA AHMAC/AqAAAAvwEAABAAywGfbwAA1wEBAAAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP 8BAAAAC8AgAAzAgAALcTAADMCAAAAAAR8AQAAAAEAAAADwAE8GYAAABCAQrwCAAAAHQFAAAC CgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgABAgAAAAA/AgAAAgC/AgAACAAA AA/wEAAAALwCAACTAwAAvAIAAMwIAAAAABHwBAAAAAQAAAAPAATwYAAAAEIBCvAIAAAAdQUA AAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQ AAAAegYAAJMDAAB6BgAAzAgAAAAAEfAEAAAABAAAAA8ABPBgAAAAQgEK8AgAAAB2BQAAAgoA AGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAABO CgAAkwMAAE4KAADMCAAAAAAR8AQAAAAEAAAADwAE8GAAAABCAQrwCAAAAHcFAAACCgAAYwAL 8CQAAAC/AQAAEADLAZwxAAD/AQgACgABAgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAE4PAACT AwAATg8AAMwIAAAAABHwBAAAAAQAAAAPAATwZgAAAEIBCvAIAAAAeAUAAAIKAABzAAvwKgAA AL8BAAAQAMsBn28AANcBAQAAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQAAAAtxMA AJMDAAC3EwAAzAgAAAAAEfAEAAAABAAAAA8ABPBgAAAAQgEK8AgAAAB5BQAAAgoAAGMAC/Ak AAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAAC8AgAApwYA ALcTAACnBgAAAAAR8AQAAAAEAAAADwAD8CYPAAAPAATwjgAAAAEACfAQAAAALQIAALgCAABE FAAAoQwAAAIACvAIAAAAegUAAAECAAAjAAvwDAAAAH8AAAAEAIgDAAAAAEMAIvEyAAAAjwMA AAAAkQMAAAAAnwMDAAAAoMMaAAAABQAIAAQAqwAAAAsCAAA9AgAAHQIAAM8BAAAAABDwBAAA ACwAAAAAABHwBAAAAAEAAAAPAATweAAAABIACvAIAAAAewUAAAIKAACDAAvwMAAAAH8AAAAE AIAAAACgAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAARA8A ANIKAABEFAAAoQwAAAAAEfAEAAAAAgAAAAAADfAEAAAAAACgAA8ABPB4AAAAEgAK8AgAAAB8 BQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAJ8AvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIA AAAAPwIAAAIAAAAP8BAAAABOCgAA0goAAEQPAAChDAAAAAAR8AQAAAACAAAAAAAN8AQAAAAA AJ8ADwAE8HgAAAASAArwCAAAAH0FAAACCgAAgwAL8DAAAAB/AAAABACAAAAAngC/AAAAAgCB AQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAK8FAADSCgAATgoAAKEMAAAA ABHwBAAAAAIAAAAAAA3wBAAAAAAAngAPAATweAAAABIACvAIAAAAfgUAAAIKAACDAAvwMAAA AH8AAAAEAIAAAACdAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQ AAAALQIAANIKAACvBQAAoQwAAAAAEfAEAAAAAgAAAAAADfAEAAAAAACdAA8ABPB4AAAAEgAK 8AgAAAB/BQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAJwAvwAAAAIAgQEAzJkAvwEBABUA/wEA AAgAAQIAAAAAPwIAAAIAAAAP8BAAAABEDwAArQgAAEQUAADSCgAAAAAR8AQAAAACAAAAAAAN 8AQAAAAAAJwADwAE8HgAAAASAArwCAAAAIAFAAACCgAAgwAL8DAAAAB/AAAABACAAAAAkgC/ AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAE4KAACtCAAARA8A ANIKAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAkgAPAATweAAAABIACvAIAAAAgQUAAAIKAACD AAvwMAAAAH8AAAAEAIAAAACRAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAAC AAAAD/AQAAAArwUAAK0IAABOCgAA0goAAAAAEfAEAAAAAgAAAAAADfAEAAAAAACRAA8ABPB4 AAAAEgAK8AgAAACCBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAJAAvwAAAAIAgQEAzJkAvwEB ABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAAtAgAArQgAAK8FAADSCgAAAAAR8AQAAAAC AAAAAAAN8AQAAAAAAJAADwAE8HgAAAASAArwCAAAAIMFAAACCgAAgwAL8DAAAAB/AAAABACA AAAAjwC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAEQPAABw BgAARBQAAK0IAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAjwAPAATweAAAABIACvAIAAAAhAUA AAIKAACDAAvwMAAAAH8AAAAEAIAAAACOAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAATgoAAHAGAABEDwAArQgAAAAAEfAEAAAAAgAAAAAADfAEAAAAAACO AA8ABPB4AAAAEgAK8AgAAACFBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAI0AvwAAAAIAgQEA zJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAACvBQAAcAYAAE4KAACtCAAAAAAR 8AQAAAACAAAAAAAN8AQAAAAAAI0ADwAE8HgAAAASAArwCAAAAIYFAAACCgAAgwAL8DAAAAB/ AAAABACAAAAAjAC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAA AC0CAABwBgAArwUAAK0IAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAjAAPAATweAAAABIACvAI AAAAhwUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAACLAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAI AAECAAAAAD8CAAACAAAAD/AQAAAARA8AAKcDAABEFAAAcAYAAAAAEfAEAAAAAgAAAAAADfAE AAAAAACLAA8ABPB4AAAAEgAK8AgAAACIBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAIoAvwAA AAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAABOCgAApwMAAEQPAABw BgAAAAAR8AQAAAACAAAAAAAN8AQAAAAAAIoADwAE8HgAAAASAArwCAAAAIkFAAACCgAAgwAL 8DAAAAB/AAAABACAAAAAiQC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAA AA/wEAAAAK8FAACnAwAATgoAAHAGAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAiQAPAATweAAA ABIACvAIAAAAigUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAACIAL8AAAACAIEBAMyZAL8BAQAV AP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAALQIAAKcDAACvBQAAcAYAAAAAEfAEAAAAAgAA AAAADfAEAAAAAACIAA8ABPB4AAAAEgAK8AgAAACLBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAA AIcAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAABEDwAAuAIA AEQUAACnAwAAAAAR8AQAAAACAAAAAAAN8AQAAAAAAIcADwAE8HgAAAASAArwCAAAAIwFAAAC CgAAgwAL8DAAAAB/AAAABACAAAAAhgC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/ AgAAAgAAAA/wEAAAAE4KAAC4AgAARA8AAKcDAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAhgAP AATweAAAABIACvAIAAAAjQUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAACFAL8AAAACAIEBAMyZ AL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAArwUAALgCAABOCgAApwMAAAAAEfAE AAAAAgAAAAAADfAEAAAAAACFAA8ABPB4AAAAEgAK8AgAAACOBQAAAgoAAIMAC/AwAAAAfwAA AAQAgAAAAIQAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAAt AgAAuAIAAK8FAACnAwAAAAAR8AQAAAACAAAAAAAN8AQAAAAAAIQADwAE8GYAAABCAQrwCAAA AI8FAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgABAgAAAAA/AgAAAgC/ AgAACAAAAA/wEAAAAC0CAAC4AgAARBQAALgCAAAAABHwBAAAAAIAAAAPAATwYAAAAEIBCvAI AAAAkAUAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAI AAAAD/AQAAAALQIAAKcDAABEFAAApwMAAAAAEfAEAAAAAgAAAA8ABPBmAAAAQgEK8AgAAACR BQAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEBAAAA/wEIAAoAAQIAAAAAPwIAAAIAvwIA AAgAAAAP8BAAAAAtAgAAoQwAAEQUAAChDAAAAAAR8AQAAAACAAAADwAE8GYAAABCAQrwCAAA AJIFAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgABAgAAAAA/AgAAAgC/ AgAACAAAAA/wEAAAAC0CAAC4AgAALQIAAKEMAAAAABHwBAAAAAIAAAAPAATwYAAAAEIBCvAI AAAAkwUAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAI AAAAD/AQAAAArwUAALgCAACvBQAAoQwAAAAAEfAEAAAAAgAAAA8ABPBgAAAAQgEK8AgAAACU BQAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP 8BAAAABOCgAAuAIAAE4KAAChDAAAAAAR8AQAAAACAAAADwAE8GAAAABCAQrwCAAAAJUFAAAC CgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/AQgACgABAgAAAAA/AgAAAgC/AgAACAAAAA/wEAAA AEQPAAC4AgAARA8AAKEMAAAAABHwBAAAAAIAAAAPAATwZgAAAEIBCvAIAAAAlgUAAAIKAABz AAvwKgAAAL8BAAAQAMsBn28AANcBAQAAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQ AAAARBQAALgCAABEFAAAoQwAAAAAEfAEAAAAAgAAAA8ABPBgAAAAQgEK8AgAAACXBQAAAgoA AGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAAAt AgAAcAYAAEQUAABwBgAAAAAR8AQAAAACAAAADwAE8GAAAABCAQrwCAAAAJgFAAACCgAAYwAL 8CQAAAC/AQAAEADLAZwxAAD/AQgACgABAgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAC0CAACt CAAARBQAAK0IAAAAABHwBAAAAAIAAAAPAATwYAAAAEIBCvAIAAAAmQUAAAIKAABjAAvwJAAA AL8BAAAQAMsBnDEAAP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQAAAALQIAANIKAABE FAAA0goAAAAAEfAEAAAAAgAAAA8AA/C6DAAADwAE8IoAAAABAAnwEAAAAL8CAADkAQAAFxYA ADQMAAACAArwCAAAALoFAAABAgAAIwAL8AwAAAB/AAAABACIAwAAAABDACLxLgAAAI8DAAAA AJEDAAAAAJ8DAwAAAKDDFgAAAAQACAAEAFEBAAALAgAA0wIAAKMCAAAAABDwBAAAADQAAAAA ABHwBAAAAAEAAAAPAATweAAAABIACvAIAAAAuwUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABe AL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAA4hEAAGsJAAAX FgAANAwAAAAAEfAEAAAAAgAAAAAADfAEAAAAAABeAA8ABPB4AAAAEgAK8AgAAAC8BQAAAgoA AIMAC/AwAAAAfwAAAAQAgAAAAF0AvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIAAAAAPwIA AAIAAAAP8BAAAACvDAAAawkAAOIRAAA0DAAAAAAR8AQAAAACAAAAAAAN8AQAAAAAAF0ADwAE 8HgAAAASAArwCAAAAL0FAAACCgAAgwAL8DAAAAB/AAAABACAAAAAXAC/AAAAAgCBAQDMmQC/ AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAPwGAABrCQAArwwAADQMAAAAABHwBAAA AAIAAAAAAA3wBAAAAAAAXAAPAATweAAAABIACvAIAAAAvgUAAAIKAACDAAvwMAAAAH8AAAAE AIAAAABbAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQAAAAvwIA AGsJAAD8BgAANAwAAAAAEfAEAAAAAgAAAAAADfAEAAAAAABbAA8ABPB4AAAAEgAK8AgAAAC/ BQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAFoAvwAAAAIAgQEAzJkAvwEBABUA/wEAAAgAAQIA AAAAPwIAAAIAAAAP8BAAAADiEQAA/gUAABcWAABrCQAAAAAR8AQAAAACAAAAAAAN8AQAAAAA AFoADwAE8HgAAAASAArwCAAAAMAFAAACCgAAgwAL8DAAAAB/AAAABACAAAAAWQC/AAAAAgCB AQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAK8MAAD+BQAA4hEAAGsJAAAA ABHwBAAAAAIAAAAAAA3wBAAAAAAAWQAPAATweAAAABIACvAIAAAAwQUAAAIKAACDAAvwMAAA AH8AAAAEAIAAAABYAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAACAAAAD/AQ AAAA/AYAAP4FAACvDAAAawkAAAAAEfAEAAAAAgAAAAAADfAEAAAAAABYAA8ABPB4AAAAEgAK 8AgAAADCBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAFcAvwAAAAIAgQEAzJkAvwEBABUA/wEA AAgAAQIAAAAAPwIAAAIAAAAP8BAAAAC/AgAA/gUAAPwGAABrCQAAAAAR8AQAAAACAAAAAAAN 8AQAAAAAAFcADwAE8HgAAAASAArwCAAAAMMFAAACCgAAgwAL8DAAAAB/AAAABACAAAAAVgC/ AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAOIRAAA1AwAAFxYA AP4FAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAVgAPAATweAAAABIACvAIAAAAxAUAAAIKAACD AAvwMAAAAH8AAAAEAIAAAABVAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAAAD8CAAAC AAAAD/AQAAAArwwAADUDAADiEQAA/gUAAAAAEfAEAAAAAgAAAAAADfAEAAAAAABVAA8ABPB4 AAAAEgAK8AgAAADFBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAFQAvwAAAAIAgQEAzJkAvwEB ABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAAD8BgAANQMAAK8MAAD+BQAAAAAR8AQAAAAC AAAAAAAN8AQAAAAAAFQADwAE8HgAAAASAArwCAAAAMYFAAACCgAAgwAL8DAAAAB/AAAABACA AAAAUwC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAAAL8CAAA1 AwAA/AYAAP4FAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAUwAPAATweAAAABIACvAIAAAAxwUA AAIKAACDAAvwMAAAAH8AAAAEAIAAAABSAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAIAAECAAAA AD8CAAACAAAAD/AQAAAA4hEAAOQBAAAXFgAANQMAAAAAEfAEAAAAAgAAAAAADfAEAAAAAABS AA8ABPB4AAAAEgAK8AgAAADIBQAAAgoAAIMAC/AwAAAAfwAAAAQAgAAAAFEAvwAAAAIAgQEA zJkAvwEBABUA/wEAAAgAAQIAAAAAPwIAAAIAAAAP8BAAAACvDAAA5AEAAOIRAAA1AwAAAAAR 8AQAAAACAAAAAAAN8AQAAAAAAFEADwAE8HgAAAASAArwCAAAAMkFAAACCgAAgwAL8DAAAAB/ AAAABACAAAAAUAC/AAAAAgCBAQDMmQC/AQEAFQD/AQAACAABAgAAAAA/AgAAAgAAAA/wEAAA APwGAADkAQAArwwAADUDAAAAABHwBAAAAAIAAAAAAA3wBAAAAAAAUAAPAATweAAAABIACvAI AAAAygUAAAIKAACDAAvwMAAAAH8AAAAEAIAAAABPAL8AAAACAIEBAMyZAL8BAQAVAP8BAAAI AAECAAAAAD8CAAACAAAAD/AQAAAAvwIAAOQBAAD8BgAANQMAAAAAEfAEAAAAAgAAAAAADfAE AAAAAABPAA8ABPBmAAAAQgEK8AgAAADLBQAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEB AAAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAAC/AgAA5AEAABcWAADkAQAAAAAR 8AQAAAACAAAADwAE8GAAAABCAQrwCAAAAMwFAAACCgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/ AQgACgABAgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAL8CAAA1AwAAFxYAADUDAAAAABHwBAAA AAIAAAAPAATwZgAAAEIBCvAIAAAAzQUAAAIKAABzAAvwKgAAAL8BAAAQAMsBn28AANcBAQAA AP8BCAAKAAECAAAAAD8CAAACAL8CAAAIAAAAD/AQAAAAvwIAADQMAAAXFgAANAwAAAAAEfAE AAAAAgAAAA8ABPBmAAAAQgEK8AgAAADOBQAAAgoAAHMAC/AqAAAAvwEAABAAywGfbwAA1wEB AAAA/wEIAAoAAQIAAAAAPwIAAAIAvwIAAAgAAAAP8BAAAAC/AgAA5AEAAL8CAAA0DAAAAAAR 8AQAAAACAAAADwAE8GAAAABCAQrwCAAAAM8FAAACCgAAYwAL8CQAAAC/AQAAEADLAZwxAAD/ AQgACgABAgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAAPwGAADkAQAA/AYAADQMAAAAABHwBAAA AAIAAAAPAATwYAAAAEIBCvAIAAAA0AUAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAK AAECAAAAAD8CAAACAL8CAAAIAAAAD/AQAAAArwwAAOQBAACvDAAANAwAAAAAEfAEAAAAAgAA AA8ABPBgAAAAQgEK8AgAAADRBQAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIA AAAAPwIAAAIAvwIAAAgAAAAP8BAAAADiEQAA5AEAAOIRAAA0DAAAAAAR8AQAAAACAAAADwAE 8GYAAABCAQrwCAAAANIFAAACCgAAcwAL8CoAAAC/AQAAEADLAZ9vAADXAQEAAAD/AQgACgAB AgAAAAA/AgAAAgC/AgAACAAAAA/wEAAAABcWAADkAQAAFxYAADQMAAAAABHwBAAAAAIAAAAP AATwYAAAAEIBCvAIAAAA0wUAAAIKAABjAAvwJAAAAL8BAAAQAMsBnDEAAP8BCAAKAAECAAAA AD8CAAACAL8CAAAIAAAAD/AQAAAAvwIAAP4FAAAXFgAA/gUAAAAAEfAEAAAAAgAAAA8ABPBg AAAAQgEK8AgAAADUBQAAAgoAAGMAC/AkAAAAvwEAABAAywGcMQAA/wEIAAoAAQIAAAAAPwIA AAIAvwIAAAgAAAAP8BAAAAC/AgAAawkAABcWAABrCQAAAAAR8AQAAAACAAAADwAE8GAAAACy BArwCAAAAF8GAAAACgAAgwAL8DAAAAAEQQQAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQAACAABAgIAAAg/AgAAAgAAABDwBAAAAGEAAAAAABHwBAAAAAEAAAAPAATwQgAAABIACvAI AAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAE AAAAAQAAABBrAAARawAAEmsAABNrAAAUawAAFmsAABdrAAAYawAAGWsAABprAAAbawAAHGsA AB1rAAAeawAAH2sAACBrAAAhawAAImsAACNrAAAkawAAJWsAACZrAAAnawAAKGsAAClrAAAq awAAK2sAACxrAAAtawAALmsAAC9rAAAwawAAMWsAADJrAAAzawAANGsAADZrAAA3awAAOGsA ADprAAA7awAAPGsAAD1rAAA+awAAQGsAAEFrAABCawAAQ2sAAEVrAABGawAAR2sAAEhrAABK awAAS2sAAExrAABNawAAT2sAAFBrAABRawAAUmsAAFRrAABVawAAVmsAAFdrAABYawAAWWsA AFprAABbawAAXGsAAF1rAABeawAAX2sAAGBrAABhawAAYmsAAGNrAABkawAAZWsAAGZrAABn awAAaGsAAGlrAABqawAAa2sAAGxrAABtawAAbmsAAG9rAABwawAAcWsAAHJrAABzawAAdGsA AHVrAAB2awAAd2sAAHhrAAB6awAAe2sAAN6BAABeBQAAUxcAAB0NAABTFwAAqRIAAHQAAAAA AFQFAAArCAAAVAcAAG8yAABLIgAAdAAAAAAAUwUAACEDAAC4AAAAwzEAAF0GAAB0AAAAAABg BQAAViMAAMr9///BNwAAmgAAAHQAAAAAAF8FAABTFwAA4RYAAFMXAABsHAAAdAAAAAAAPgQA ABIIAACDGQAAvRsAAFwgAAB0AAAAAAA/BAAA4SQAAMz7//9MOQAAnP7//3QAAAAAAD0EAAC1 AAAAmBAAALcXAAC5GAAAdAAAAAAAPAQAAAgcAABBDgAAlygAAJQfAAB0AAAAAAA7BAAAFhoA AG0gAABOMAAAfyIAAHQAAAAAADoEAAArHAAAwBEAAB8wAADFHwAAdAAAAAAAOQQAALb///8P AwAALw4AAIAFAAB0AAAAAAA4BAAA4f///60FAAA4DAAAeQ8AAHQAAAAAADcEAABeDAAAlgMA ANcaAAAHBgAAdAAAAAAANgQAAHQMAABGBgAA2hoAABEQAAB0AAAAAAA1BAAAHh0AAHMGAACW KwAA5AgAAHQAAAAAADQEAAAnGwAAxggAAH4tAAB5EQAAdAAAAAAAMwQAAJcoAADPEwAAkykA ADAaAAB0AAAAAAAyBAAAZCcAAC0QAADAJwAAvxQAAHQAAAAAADEEAAC7IAAA0w0AALIhAADk EgAAdAAAAAAAMAQAAGkiAACNDAAAsCUAAHUOAAB0AAAAAAAvBAAAwiUAACIMAADFLAAArxAA AHQAAAAAAC4EAAB7HwAArBYAAH0mAAC9GAAAdAAAAAAALQQAAKgeAAC0EgAASCcAAN0cAAB0 AAAAAAAsBAAAnCgAAFEZAAA8LgAALR8AAHQAAAAAACsEAAB6GwAAAAsAAH0iAAA+DgAAdAAA AAAAKgQAAL0WAAAjCAAAehsAAFILAAB0AAAAAAApBAAAihcAAFcMAABoGwAAVwwAAHQAAAAA ACgEAADxDwAANgoAAHgXAADDDgAAdAAAAAAAJwQAAM0LAADMBwAA6RAAAPsKAAB0AAAAAAAm BAAAKgwAACAMAAAIEAAAIAwAAHQAAAAAACUEAABuCAAAKwsAABYMAAAaDQAAdAAAAAAAJAQA AFwEAACRBgAA0AgAAA8LAAB0AAAAAAAjBAAAggQAADYMAABgCAAANgwAAHQAAAAAACIEAADo ////mQoAAFwEAADXDQAAdAAAAAAAIQQAAOn+//+c/v//iy0AAI4CAAB0AAAAAABjBQAASSYA ABj7//+0OgAA6P3//3QAAAAAAGIFAAA9BQAA1AIAAPUxAADgIwAAdAAAAAAAYQUAACEDAADo /f//wjEAAIcCAAB0AAAAAABkBQAAIQMAAIgDAACULQAAmBEAAHQAAAAAAFkEAAB5IwAAGPv/ /+Q3AADo/f//dAAAAAAAVwQAACkDAADhEgAAVDAAAIEeAAB0AAAAAABABAAAuQEAAOj9//9b MAAA8AQAAHQAAAAAAFgEAACOBwAAQB4AAKosAADSIQAAdAAAAAAAegUAAD0DAACgAQAAdzAA AGcaAAB0AAAAAAB8BAAAxSIAAMz7//8wNwAAnP7//3QAAAAAAHsEAAB7BgAACBsAALkwAAAe IgAAdAAAAAAAWgQAAG0CAAA0/f//DzEAAHcBAAB0AAAAAACZBAAApQYAALwaAADlMAAA0yEA AHQAAAAAAH4EAAAhAwAAiAMAAFswAABAGQAAdAAAAAAAmgQAAOEkAAAY+///TDkAAOj9//90 AAAAAAB9BAAAbQIAAJz+//8PMQAApAUAAHQAAAAAALoFAACDAQAAewEAAN8xAABDGwAAdAAA AAAAuAQAAHkjAAAY+///5DcAAOj9//90AAAAAAC3BAAAbAYAAGIcAACqMAAAeSMAAHQAAAAA AJsEAAAFAQAANP3//6cvAADSAQAAdAAAAAAA0QQAAC0kAADM+///mDgAAJz+//90AAAAAADQ BAAAhAUAACYaAADCLwAAPSEAAHQAAAAAALoEAACPAQAAeAYAAA8xAACbGAAAdAAAAAAAuQQA ALkBAAAEAAAAWzAAAKIEAAB0AAAAAAD2BAAA4SQAABj7//9NOQAA6P3//3QAAAAAAPUEAADZ GgAAGyAAABAxAAAtIgAAdAAAAAAA9AQAAEoaAADFGwAATRwAACEfAAB0AAAAAADzBAAAxwYA AJEbAABIGgAAJiEAAHQAAAAAAPIEAAB6KQAAvAYAAJErAAAlCQAAdAAAAAAA8QQAAGAbAABK AgAApjEAAKMGAAB0AAAAAADwBAAAIw0AALwSAABYGQAAkBkAAHQAAAAAAO8EAABcEAAAYhAA AHMSAADLEgAAdAAAAAAA7gQAAMIEAAD0DwAA/wYAAIMSAAB0AAAAAADtBAAAJgAAAJwSAADX CwAAcBkAAHQAAAAAAOwEAABJHAAAcw4AANgoAADGHwAAdAAAAAAA6wQAAGwcAADyEQAAXzAA APgfAAB0AAAAAADqBAAA9////0IDAABvDgAAswUAAHQAAAAAAOkEAAAhAAAA4AUAAHkMAACs DwAAdAAAAAAA6AQAAJ8MAADJAwAAFxsAADoGAAB0AAAAAADnBAAAtQwAAHkGAAAaGwAARBAA AHQAAAAAAOYEAABeHQAApgYAANcrAAAXCQAAdAAAAAAA5QQAAGgbAAD4CAAAvy0AAKwRAAB0 AAAAAADkBAAA2CgAAAIUAADUKQAAYhoAAHQAAAAAAOMEAACkJwAAYBAAAAAoAADyFAAAdAAA AAAA4gQAAPsgAAAFDgAA8iEAABYTAAB0AAAAAADhBAAAqSIAAMAMAADxJQAAqA4AAHQAAAAA AOAEAAADJgAAVQwAAAUtAADhEAAAdAAAAAAA3wQAALsfAADeFgAAviYAAPAYAAB0AAAAAADe BAAA6R4AAOcSAACJJwAADx0AAHQAAAAAAN0EAADcKAAAhBkAAHwuAABfHwAAdAAAAAAA3AQA ALobAAAzCwAAvSIAAHEOAAB0AAAAAADbBAAA/hYAAFYIAAC6GwAAhQsAAHQAAAAAANoEAADL FwAAiQwAAKkbAACJDAAAdAAAAAAA2QQAADEQAABoCgAAuRcAAPUOAAB0AAAAAADYBAAADQwA AP4HAAApEQAALQsAAHQAAAAAANcEAABqDAAAUgwAAEgQAABSDAAAdAAAAAAA1gQAAK8IAABd CwAAVgwAAEwNAAB0AAAAAADVBAAAnQQAAMMGAAAQCQAAQQsAAHQAAAAAANQEAADCBAAAaAwA AKAIAABoDAAAdAAAAAAA0wQAACkAAADMCgAAnQQAAAoOAAB0AAAAAADSBAAABQEAADT9//+m LwAAVwIAAHQAAAAAAF8GAABGAgAAmvz//0E0AADSIwAAdAAAAAAAJAUAAJUlAABk+v//AToA ADT9//90AAAAAAAAAAAAfWsAABJsAABcbAAAXWwAANBsAADVbAAAK3cAADR3AAC/fQAAxH0A AN+BAAAHAAcABwACAAcAHAAHABwABwAcAAcAAAAAAJ8lAACxJQAAslgAALNYAAB9awAAEmwA AFxsAABdbAAA3GwAAORsAADxbAAA+GwAAAVtAAAObQAAoG4AAKduAADIbgAAz24AAPFuAAD4 bgAAPnUAAFB1AAAyegAAPHoAAN+BAAAHADMABwAEAAcABwAHAAIABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHAAAAAAAOEwAADxMAABATAAAcEwAAQhMAAEMTAAC4GQAAvBkA AA4cAAAgHAAA8SEAAPIhAACnJQAApyUAALslAAC8JQAAeUsAAHpLAAAiTAAAXUwAAHRMAAB0 TAAAjEwAANFMAAD7TAAA/EwAAP1MAAAETQAA2U0AADdOAACVTgAA804AAPROAAD1TgAAAU8A AJ5PAAAuUAAARFAAAPJQAAD4UwAA+VMAAPpTAACtWAAAslgAAJhiAACcYgAAbWQAAG1kAACB ZAAAwGQAANtkAAA9ZQAAfGsAAH1rAAB/awAAEGwAABJsAABabAAAXWwAAGRsAABlbAAAKm8A ADhvAAA5bwAARG8AAEVvAABSbwAAU28AAGNvAABkbwAAaW8AAGpvAACLbwAAjG8AAMVvAADG bwAA128AANhvAADcbwAA3W8AAO5vAADvbwAAKnAAACtwAABNcAAAZnAAAGdwAABwcAAAcXAA AMVwAADFcAAAxnAAAMZwAADHcAAAx3AAAMhwAADIcAAAyXAAAMlwAADKcAAAynAAAMtwAADL cAAAzHAAAMxwAADNcAAAzXAAAM5wAADOcAAAz3AAAM9wAADQcAAA0HAAANFwAADRcAAA0nAA ANJwAADTcAAA03AAANRwAADUcAAA1XAAANVwAADWcAAA1nAAANdwAADXcAAA2HAAANhwAADw cAAA8XAAAM1zAADOcwAA+nMAAAh0AAA1dAAAQ3QAAER0AABPdAAAUHQAAFx0AABddAAAbXQA AG50AACRdAAAknQAAKN0AACkdAAA03QAANR0AAAWdQAAF3UAAD11AAA+dQAAYnUAAGN1AAC9 dQAAvnUAAAV2AAAGdgAAD3YAABB2AAAkdgAAJXYAAHB2AABxdgAAs3YAAM92AADQdgAA3ngA AN94AAAVeQAAJHkAACd6AAA2egAArHsAAK17AACvewAAvXsAAL57AADJewAAynsAANZ7AADX ewAA53sAAOh7AAD0ewAA9XsAABV8AAAWfAAAUnwAAFN8AAB/fAAAgHwAAIV8AACGfAAAsnwA ALN8AADlfAAA5nwAABJ9AAATfQAAIn0AACN9AAA6fQAAO30AAFV9AABWfQAAXX0AAF59AABe fQAAX30AAH9/AACAfwAAnX8AAJ5/AACnfwAAqH8AAB2AAAAegAAAhoAAAIeAAAD7gAAA/IAA AAWBAAAGgQAAKIEAACmBAADcgQAA34EAAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAHAAMABAAHAAQAAgADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQABwD/ /xQAAAAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABN AHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBj AHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgB0AHgAdAAK AFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABNAHkAIABE AG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBjAHQAaQBv AG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgB0AHgAdAAKAFcAaQBs ACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABNAHkAIABEAG8AYwB1 AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJ AHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgBkAG8AYwAKAFcAaQBsACAAVwBh AGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABNAHkAIABEAG8AYwB1AG0AZQBu AHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBt AHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgBkAG8AYwAKAFcAaQBsACAAVwBhAGwAawBv AGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBc AEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBtAHMAXABF AG4AZABUAG8ARQBuAGQAUQBvAHMALgBkAG8AYwAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBD ADoAXABQAGUAcgBzAG8AbgBhAGwAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBE AEYAXABDAHUAcgByAGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABU AG8ARQBuAGQAUQBvAHMALgBkAG8AYwAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQ AGUAcgBzAG8AbgBhAGwAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABD AHUAcgByAGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBu AGQAUQBvAHMALgBkAG8AYwAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBz AG8AbgBhAGwAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgBy AGUAbgB0ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBv AHMALgBkAG8AYwAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBh AGwAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0 ACAAQQBjAHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgBk AG8AYwAKAFcAaQBsACAAVwBhAGwAawBvAGUAQgBDADoAXABQAGUAcgBzAG8AbgBhAGwAXABN AHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEIAQwBEAEYAXABDAHUAcgByAGUAbgB0ACAAQQBj AHQAaQBvAG4AIABJAHQAZQBtAHMAXABFAG4AZABUAG8ARQBuAGQAUQBvAHMALgBkAG8AYwAJ AH////++zEgC/w//D/8P/w//D/8P/w//D/8PAQD+////8NNoE/8PAAAAAAAAAAAAAAAAAAAA AAEABDxmCTbyzMP/DwAAAAAAAAAAAAAAAAAAAAABAG8d8R+GAZ7A/w//D/8P/w//D/8P/w// D/8PEAC4aHUj3PaoTv8P/w//D/8P/w//D/8P/w//DxAABHBGLg6Sfi0UAP8P/w//D/8P/w// D/8P/w8QAMUY3Vq6HAhc/w//D/8P/w//D/8P/w//D/8PEACuJBZqRg+QqP8P/w//D/8P/w// D/8P/w//DxAAxTKkc0TzDv7/D/8P/w//D/8P/w//D/8P/w8QAAEAAAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP4CAAAALgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQAqAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY /hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEALfABAAAAABABAAAAAAAAAAAAaAEAAAAA AAAAGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+AgAAAC4AAQAAAASQAQAAAAAAAAAAAGgB AAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAA AABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAA AAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQ AQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEA AAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUA LgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+ AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAW YISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkG XoRQGWCETP8CAAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAUGAAAD4Q4BBGEmP4VxgUA ATgEBl6EOARghJj+QioAT0oBAFFKAQBvKABwaAAAAP8BAKjwAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+ECAcRhJj+FcYFAAEIBwZehAgHYISY/k9KBQBRSgUAbygAAQBvAAEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSgYAUUoG AG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SoDBGEmP4VxgUAAagMBl6E qAxghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EeA8R hJj+FcYFAAF4DwZehHgPYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAA AAAAAAsYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4QYFRGEmP4VxgUAARgVBl6EGBVghJj+T0oBAFFKAQBv KAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E6BcRhJj+FcYFAAHoFwZehOgX YISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhLgaEYSY /hXGBQABuBoGXoS4GmCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAA AAAUGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+QioAT0oBAFFKAQBvKABwaAAAAP8BAKjw AQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ECAcRhJj+FcYFAAEIBwZehAgHYISY/k9K BQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB 2AkGXoTYCWCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAA D4SoDBGEmP4VxgUAAagMBl6EqAxghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAACxgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KBQBRSgUAbygAAQBvAAEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCEmP5PSgYA UUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QYFRGEmP4VxgUAARgV Bl6EGBVghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E 6BcRhJj+FcYFAAHoFwZehOgXYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABo AQAAAAAAAAsYAAAPhLgaEYSY/hXGBQABuBoGXoS4GmCEmP5PSgYAUUoGAG8oAAEAp/ABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+T0oGAFFK BgBvKAABANjwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EoAURhJj+FcYFAAGgBQZe hKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhHAI EYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBQBRSgUA bygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTg EGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SwExGE mP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgYAUUoGAG8o AAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARg hJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EoAURhJj+ FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAA AAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKAAB ALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY /k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOAQEYSY/hXG BQAB4BAGXoTgEGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAL GAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBv AAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5P SgYAUUoGAG8oAAEAp/ABAAAAFxAAAAAAAAAAAAAA0AIAAAAAAAALGAAAD4Q4BBGEmP4VxgUA ATgEBl6EOARghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAANACAAAAAAAACxgA AA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAA AADQAgAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAAEAp/AB AAAAF5AAAAAAAAAAAAAA0AIAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oB AFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAANACAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQ DgZehBAOYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAADQAgAAAAAAAAsYAAAP hOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAA 0AIAAAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAA ABeQAAAAAAAAAAAAANACAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBR SgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAADQAgAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkG XoRQGWCEmP5PSgYAUUoGAG8oAAEAp/AOAAAA/v///wAAAAA8r/YCAQAAAP7///8AAAAAkK/2 AgEAAAD+////AAAAAOSv9gIBAAAA/v///wAAAAA4sPYCAQAAAP7///8AAAAAjLD2AgEAAACu JBZqAAAAAAAAAAAAAAAAbx3xHwAAAAAAAAAAAAAAAH////8AAAAAAAAAAAAAAADFMqRzAAAA AAAAAAAAAAAABHBGLgAAAAAAAAAAAAAAAAQ8ZgkAAAAAAAAAAAAAAADFGN1aAAAAAAAAAAAA AAAAuGh1IwAAAAAAAAAAAAAAAARwRi4AAAAAAAAAAAAAAAD/////SK/2AiAAAAAAAAAAF0AA AAAAAAAAAAAAAAAAAAAAAAAPAAAAQ0ooAE9KAABRSgAAbygAAQAiIP////+cr/YCIABAQAAA AAAXQAAAAAAAAAAAAAAAAAAAAAAAAA8AAABDSioAT0oGAFFKBgBvKAABAG7w//////Cv9gIg AAAAAAAAABdAAAAAAAAAAAAAAAAAAAAAAAAADwAAAENKGABPSgYAUUoGAG8oAAEAbPD///// RLD2AiAAAAAAAAAAF0AAAAAAAAAAAAAAAAAAAAAAAAAPAAAAQ0okAE9KBgBRSgYAbygAAQBu 8P////+YsPYCIAAAAAAAAAAXQAAAAAAAAAAAAAAAAAAAAAAAAA8AAABDShQAT0oGAFFKBgBv KAABAGzw//////////////////////////////////////////////////8JAAAAAAAAAAAA AAAAAAAAAAAAAAAA//8JAAAAAAAAAAAAEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkE GQAJBBsACQQSAGaDLNIDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIAvsQKJgMA CQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgAYyKz+AwAJBAUACQQBAAkEAwAJBAUA CQQBAAkEAwAJBAUACQQSAAYYoDwDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIA BhigPAMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAQAAAAEACQwFAAIAQAAAAAAA WVgAAPpfAADfgQAAAAAAAAHdAAAB3QAA/0ADgAEAslgAALJYAABMCZcBAQABALJYAAAAAAAA rVgAAAAAAAACEAAAAAAAAADegQAAYAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8B AAgAAAAAAAAAAAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABwAAAEcWkAEA AAICBgMFBAUCAwSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAg AFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABT AHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABB AHIAaQBhAGwAAAA5AJABAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAQwBo AGEAcgBjAG8AYQBsAAAAQSaQAQAAAgsFBgICAgMCBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAA AEEAcgBpAGEAbAAgAE4AYQByAHIAbwB3AAAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACACAAA AAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADsGkAECAAUAAAAAAAAAAAAA AAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAACIABABxCIgYAPDQ AgAAaAEAAAAADTxUxh88VMZAbFJGCQASAAAAjA8AAKFYAAABAC0AAAAEAAMQvQAAABgDAACj EQAAAQAJAAAAJQAAAAAAAADBAgDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAClBsAHtAC0AIAAMjAAABAAGQBkAAAAGQAAANdsAAC7FAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAA AAAAAAAAAAwyg1EA8BAA3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAA AAAALQBQAG8AcwB0AC0ARABlAGwAaQB2AGUAcgB5ACAAQwBvAG4AdABlAG4AdAAgAE0AYQBu AGEAZwBlAG0AZQBuAHQAIABDAG8AbgB0AHIAaQBiAHUAdABpAG8AbgAAAAAAAAAMAFMAaQBt AG8AbgAgAEIAcgB5AGQAZQBuAAoAVwBpAGwAIABXAGEAbABrAG8AZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACgAQAA EQAAAAEAAACQAAAAAgAAAJgAAAADAAAA0AAAAAQAAADcAAAABQAAAPQAAAAHAAAAAAEAAAgA AAAUAQAACQAAACgBAAASAAAANAEAAAoAAABQAQAACwAAAFwBAAAMAAAAaAEAAA0AAAB0AQAA DgAAAIABAAAPAAAAiAEAABAAAACQAQAAEwAAAJgBAAACAAAA5AQAAB4AAAAuAAAAUG9zdC1E ZWxpdmVyeSBDb250ZW50IE1hbmFnZW1lbnQgQ29udHJpYnV0aW9uAC4wHgAAAAEAAAAAb3N0 HgAAAA0AAABTaW1vbiBCcnlkZW4AIENvHgAAAAEAAAAAaW1vHgAAAAsAAABOb3JtYWwuZG90 AG4eAAAACwAAAFdpbCBXYWxrb2UAbh4AAAACAAAAOQBsIB4AAAATAAAATWljcm9zb2Z0IFdv cmQgOS4wAG5AAAAAAOy6gwIAAABAAAAAAPBBTwiWwAFAAAAAANZMhqe/wAFAAAAAAMIHCqq/ wAEDAAAAAQAAAAMAAACMDwAAAwAAAKFYAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQA AgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAIAEAAAwAAAABAAAA aAAAAA8AAABwAAAABQAAAIgAAAAGAAAAkAAAABEAAACYAAAAFwAAAKAAAAALAAAAqAAAABAA AACwAAAAEwAAALgAAAAWAAAAwAAAAA0AAADIAAAADAAAAAIBAAACAAAA5AQAAB4AAAAQAAAA Tm9ydGVsIE5ldHdvcmtzAAMAAAC9AAAAAwAAAC0AAAADAAAA12wAAAMAAADtDgkACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAC4AAABQb3N0LURlbGl2ZXJ5IENv bnRlbnQgTWFuYWdlbWVudCBDb250cmlidXRpb24ADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQA AAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAA EgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8A AAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAA LQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoA AAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAA SAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUA AABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAA YwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAA AABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAA/v///3wAAAB9AAAA fgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsA AACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAA mQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYA AACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAA tAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEA AADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAA zwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwA AADdAAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA 6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA/v////EAAADyAAAA8wAAAPQAAAD1AAAA9gAAAPcA AAD+////+QAAAPoAAAD7AAAA/AAAAP0AAAD+AAAA/wAAAP7////9/////f////3///8EAQAA /v////7////+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAA AAAAAAAAAAAAANBGyyiqv8ABBgEAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB7AAAA9+gAAAAAAABXAG8A cgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGgACAQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADv9QAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8AAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4AAAAABAAAAAA AAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAADQRssoqr/AAdBGyyiqv8ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAAAA/v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////wEA/v8DCgAA/////wYJAgAAAAAA wAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAA V29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA --openmail-part-238944ed-00000001-- From owner-mpls@UU.NET Mon Apr 9 10:02:00 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07115 for ; Mon, 9 Apr 2001 10:02:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkaa05718; Mon, 9 Apr 2001 14:00:13 GMT Received: by mail-control.mail.uu.net id QQkjzz21481 for mpls-outgoing; Mon, 9 Apr 2001 13:59:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkjzz21476 for ; Mon, 9 Apr 2001 13:59:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjzz12582 for ; Mon, 9 Apr 2001 13:59:17 GMT Received: from PH01SRV02.photuris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [141.150.26.4]) id QQkjzz11167 for ; Mon, 9 Apr 2001 13:59:16 GMT Received: from photuris.com (SEUSS [192.168.1.179]) by PH01SRV02.photuris.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2A0A0N06; Mon, 9 Apr 2001 09:50:03 -0400 Message-ID: <3AD1C050.629F38BC@photuris.com> Date: Mon, 09 Apr 2001 09:59:44 -0400 From: Paul Bonenfant X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Heiles Juergen CC: "'curtis@avici.com'" , "Lazer, Monica A, NNAD" , "'neil.2.harrison@bt.com'" , raszuk@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org, "t1x1.5" Subject: Re: restoration time requirement (was Re: Last Call on RSVP LabelAllocation for Backup Tunnels) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeurgen, Can't resist (apologies to all for the long message)... You wrote: > > Stacked protection/restoration: > If you use protection/restoration at an optical network layer > (server) and a SONET/SDH network layer (client) the server layer > switching times should be faster than the client layer reaction > times, so that the server layer does the protection/restoration > and the client layer doesn't react. > But as you no doubt well know, by far all the installed legacy SONET/SDH kit (that the unfortunate carriers are yearning to get rid of, and which will disappear over time...sorry, I digress...) detects: - LOS/LOF on the order of 2.3-100 microseconds (LOS for SONET, thanks to Bellcore/Telcordia GR-253, unless it's been revised), or - 375 microseconds (LOF for SDH -- Maarten please correct me if I'm wrong, I know you're out there). So for the server (optical) layer switching time to be faster than the client (SONET/SDH) layer reaction time, the optical layer would have to restore well within, say, 1 millisecond. And, in this context, "switching time" may include (depending upon the particular flavour of optical layer protection/restoration implemented): detection-time + signaling-time (for 1+1 bidirectional or shared protection, or restoration) + bridging&switching-time. To do all that in less than 1 msec is a tall order for any layer. Maybe I'm beating a long dead horse here, but this now aging issue of "optical layer restoration occurring faster than the SONET/SDH reaction time" keeps cropping up...for a shameless plug thinly veiled as bit of history, see: - J. Manchester and P. Bonenfant, "Fiber Optic Network Survivability: SONET/Optical Protection Layer Interworking," Proc. of NFOEC'96, Denver, CO, 1996. (If interested, reply off-list to find out how to get a copy. I know, referenced material should be posted as either an IETF draft or T1X1 contribution to make it more readily available, sorry.) Juergen, I agree that this is an issue of concern (albeit not new). Potential solutions to the SONET/SDH-Optical protection layer inter- working problem include: - Do nothing (e.g., allow both the SONET/SDH & Optical & perhaps even other layers to react to the failure...not an attractive approach unless chaos is an option) - Implement appropriate holdoff time(s) in one or more of the layers (again not attractive as it delays restoration if the failure actually occurs at that layer...also, the holdoff times get progressively longer in the higher layers) - Inter-layer signaling (see, for example, ANSI T1X1.5/97-080, "Protected Domain Boundary Delineation," June 1997: ftp://ftp.t1.org/pub/t1x1/x15.97/7x150800.pdf -- an elegant solution, but never gained any traction thanks to the mess associated with inter-layer signaling) - Avoid direct overlay of survivability schemes with similar restoration time-scales (tends to be what is done in practice) - Coordinate protection layer interworking via a common control plane across all the network layers (e.g., GMPLS?), as discussed briefly (for example) in Sec 3.2.3 of: http://www.ietf.org/internet-drafts/draft-ghani-optical-rings-01.txt (again for the reference-minded the above discussion can be found in "Optical Layer Protection and Restoration," OFC'2001 Short Course SC113/153, Mar. 2001, or "Tutorial on Optical Layer Protection and Restoration," Proc. of OFC'1999, Paper FF-1, Feb. 1999). As for the appropriate restoration time requirement...for what it's worth, 50 msec, insofar as it remains an historical artifact, also continues to be the "psychological" bar that optical netwoking protection & restoration schemes have to meet, if for no other reason than the following, prevailing view -- "the new & improved (optical networking) technology should provide at least as good, if not better, performance than what preceded it (SONET/SDH)." Psychological bars notwithstanding, what then is the appropriate restoration time requirement? I for one would be interested in hearing from (even more) carriers regarding which latency-sensitive applications actually drive the 50msec-range protection/restoration requirements (my guess: it's not (only) voice). Regards, Paul Heiles Juergen wrote: > > Curtis > > >Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with .... > > you are completely wrong and I suggest you better make measurments and get familiar with SONET before making such statements.. SONET/SDH equipment will not shut down/drop connections. Today SONET connections are permanent connections setup via the management system. An automatic drop of a conneciton as it is the case for switched connections will not occur. What you will see is the insertion of AIS (alarm indication signal) after the detection of an defect. But as soon as the defect is gone the AIS is removed and the connection is running again. AIS is nothing harmful as due to the defect the connection is interupted in any case. Furthermore the AIS avoids downstream alarms (alarm storms). > > What could be of concern are the following points. I talk about a server layer for a SONET/SDH network (e.g. an Optical Network) providing protection/restoration: > > Stacked protection/restoration: > If you use protection/restoration at an optical network layer (server) and a SONET/SDH network layer (client) the server layer switching times should be faster than the client layer reaction times, so that the server layer does the protection/restoration and the client layer doesn't react. > > Automatic power reduction/automatic laser shutdown APR/ALS > APR is used for safety reasons in order to avoid harmful emission of laser light in case of a fiber cut. One implementation switches off the transmit laser in case of loss of signal at the receiver. A restart action which is triggered automatically in intervals of several seconds is required in order to test if the link is repaired. Normally the APR function can be switched off if not needed. The APR function needs some careful consideration in case of protection/restoration and automatic connection setup in all optical networks. > > Regards > > Juergen > > > -----Original Message----- > > From: Curtis Villamizar [SMTP:curtis@workhorse.fictitious.org] > > Sent: Monday, April 09, 2001 4:37 AM > > To: Lazer, Monica A, NNAD > > Cc: 'neil.2.harrison@bt.com'; raszuk@cisco.com; mpls@UU.NET; ccamp@ops.ietf.org > > Subject: restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels) > > > > > > In message <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com>, "L > > azer, Monica A, NNAD" writes: > > > Voice switches will drop the connections after 2.5 seconds. A large number > > > of dropped calls will cause FCC reportable events, which is something that > > > US carriers need to avoid. So restoration within this time frame is needed > > > for support of trunks carrying voice traffic. > > > > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > Monica, > > > > We're off topic, so I changed the subject. > > > > Thanks for providing the 2.5 second figure. > > > > I've heard carrier transport people grumble about SONET equipment > > they'd be please to get rid of that will shut down even when used as > > linear SONET with no protect path and as a result would require > > <100msec restoration. Since there is enough of this SONET gear, the > > carriers can't really get rid of it although it will probably > > disappear over time and so they will make fast restoration a > > requirement of people they buy from. To be safe, the request for > > <50msec has been made. > > > > If you are not blessed with such equipment or you are able to work > > around it when doing VoIP, then you are among the fortunate. > > > > Then again, this is second hand, so I could be completely wrong. This > > is not a measurement I've made myself and the SONET equipment is not > > something I'm familiar with such that I could say with confidence that > > it could not be configured to hold on longer or to not shut down at> > > all if there was no protect. > > > > OTOH there are those who (claim to) want to configure SONET on some > > links but not on others and don't want a fast restoration. They want > > to be assured that restoration will occur only after it is safe to > > assume that SONET restoration is not available. > > > > Curtis From owner-mpls@UU.NET Mon Apr 9 10:28:51 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07782 for ; Mon, 9 Apr 2001 10:28:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkjzs15712; Mon, 9 Apr 2001 12:14:49 GMT Received: by mail-control.mail.uu.net id QQkjzs27193 for mpls-outgoing; Mon, 9 Apr 2001 12:14:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkjzs27166 for ; Mon, 9 Apr 2001 12:14:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkjzs09000 for ; Mon, 9 Apr 2001 12:13:41 GMT Received: from cms1.etri.re.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cms1.etri.re.kr [129.254.16.11]) id QQkjzs11831 for ; Mon, 9 Apr 2001 12:13:41 GMT Received: from mhson (mhson.etri.re.kr [129.254.197.141]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 23LBWPNW; Mon, 9 Apr 2001 21:12:54 +0900 Message-ID: <002c01c0c0ee$92de5e50$8dc5fe81@etri.re.kr> From: "Myunghee Son" To: , Subject: TE link between PXCs Date: Mon, 9 Apr 2001 21:14:06 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C0C13A.02AF22F0" 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_0029_01C0C13A.02AF22F0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sIGFsbC4NCg0KT24gcGFnZSAxNSBpbiBkcmFmdC1pZXRmLW1wbHMtbG1wLTAyLnR4dCwg dGhlIFRFIGxpbmsgaXMgZGVmaW5lZCBhIG51bWJlciBvZiBkYXRhIGxpbmtzDQpiZXR3ZWVuIHR3 byBub2Rlcy4gDQoNClJlbGF0ZWQgdG8gdGhpcyBmYWN0IGkgaGF2ZSB0d28gcXVlc3Rpb25zLg0K MSkgSW4gQ2hhbm5lbEZhaWwgbXNnIGFuZCBDaGFubmVsQWN0aXZlIG1zZywgd2hhdCBpcyBsb2Nh bCBURSBsaW5rIGlkPw0KMikgSWYgdGhlcmUgYXJlIG1hbnkgZGF0YSBsaW5rcyBiZXR3ZWVuIHR3 byBQWENzLCAgaG93IGNhbiBpIGRpdmlkZSB0aGVtIGludG8gc29tZSBURSBsaW5rcyBvciBvbmUg VEUgbGluaz8gDQogICAgDQpCZXN0IHJlZ2FyZHMsDQpNeXVuZ2hlZS4NCg0KDQoNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk15dW5naGVlIFNvbg0KTVBMUyBTb2Z0d2FyZSBU ZWFtDQpJbnRlcm5ldCBUZWNobm9sb2d5IERlcGFydG1lbnQNCk5ldHdvcmsgVGVjaG5vbG9neSBM YWIuDQpFVFJJIChFbGVjLiAmIFRlbGVjb20uIFJlc2VhcmNoIEluc3QuKQ0KDQpPZmZpY2U6ICs4 Mi40Mi44NjAuNjQ3Mw0KTW9iaWxlOiArODIuMTYuMjU0LjY3MjYNCkZheDogKzgyLjQyLjg2MC41 NDQwDQpFLW1haWw6IG1oc29uQGV0cmkucmUua3INCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0K ------=_NextPart_000_0029_01C0C13A.02AF22F0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLCBhbGwu PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPk9uIHBh Z2UgMTUgaW4gZHJhZnQtaWV0Zi1tcGxzLWxtcC0wMi50eHQsIHRoZSBURSBsaW5rIGlzIA0KZGVm aW5lZCBhIG51bWJlciBvZiBkYXRhIGxpbmtzPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+YmV0d2VlbiB0d28gbm9kZXMuIDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5SZWxhdGVkIHRvIHRoaXMgZmFjdCBpIGhhdmUgdHdvIHF1ZXN0aW9u cy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4xKSBJbiBDaGFubmVsRmFpbCBtc2cg YW5kIENoYW5uZWxBY3RpdmUgbXNnLCB3aGF0IGlzIGxvY2FsIFRFIA0KbGluayBpZD88L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4yKSZuYnNwO0lmIHRoZXJlIGFyZSBtYW55IGRhdGEg bGlua3MmbmJzcDtiZXR3ZWVuIA0KdHdvJm5ic3A7UFhDcywmbmJzcDsmbmJzcDtob3cgY2FuIGkg ZGl2aWRlJm5ic3A7dGhlbSBpbnRvIHNvbWUgVEUgbGlua3Mgb3Igb25lIA0KVEUgbGluaz8gPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkJlc3QgcmVnYXJkcyw8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5NeXVuZ2hlZS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxCUj5NeXVuZ2hlZSBTb248QlI+TVBMUyANClNvZnR3YXJlIFRlYW08QlI+SW50 ZXJuZXQgVGVjaG5vbG9neSBEZXBhcnRtZW50PEJSPk5ldHdvcmsgVGVjaG5vbG9neSANCkxhYi48 QlI+RVRSSSAoRWxlYy4gJmFtcDsgVGVsZWNvbS4gUmVzZWFyY2ggSW5zdC4pPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPk9mZmljZTogKzgyLjQyLjg2 MC42NDczPEJSPk1vYmlsZTogKzgyLjE2LjI1NC42NzI2PEJSPkZheDogDQorODIuNDIuODYwLjU0 NDA8QlI+RS1tYWlsOiA8QSANCmhyZWY9Im1haWx0bzptaHNvbkBldHJpLnJlLmtyIj5taHNvbkBl dHJpLnJlLmtyPC9BPjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0ZPTlQ+PC9E SVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0029_01C0C13A.02AF22F0-- From owner-mpls@UU.NET Mon Apr 9 10:39:57 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07915 for ; Mon, 9 Apr 2001 10:39:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkac19542; Mon, 9 Apr 2001 14:37:40 GMT Received: by mail-control.mail.uu.net id QQkkac11796 for mpls-outgoing; Mon, 9 Apr 2001 14:37:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkac11783 for ; Mon, 9 Apr 2001 14:36:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkac11524 for ; Mon, 9 Apr 2001 14:34:15 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkac15156 for ; Mon, 9 Apr 2001 14:34:14 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA10511 for mpls@uu.net; Mon, 9 Apr 2001 10:34:14 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkac11402 for ; Mon, 9 Apr 2001 14:33:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkac16443 for ; Mon, 9 Apr 2001 14:31:47 GMT Received: from alemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQkkac27791 for ; Mon, 9 Apr 2001 14:31:46 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 KAA09351 for ; Mon, 9 Apr 2001 10:30:56 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA09337 for ; Mon, 9 Apr 2001 10:30:55 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA21104; Mon, 9 Apr 2001 16:30:39 +0200 (MET DST) Cc: "'curtis@avici.com'" , "Lazer, Monica A, NNAD" , raszuk@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org, "t1x1.5" Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA21070; Mon, 9 Apr 2001 16:30:33 +0200 (MET DST) Message-ID: <3AD1C788.91113189@lucent.com> Date: Mon, 09 Apr 2001 16:30:32 +0200 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Bonenfant Original-CC: "'curtis@avici.com'" , "Lazer, Monica A, NNAD" , raszuk@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org, "t1x1.5" Subject: Re: restoration time requirement (was Re: Last Call on RSVP LabelAllocation for Backup Tunnels) References: <3AD1C050.629F38BC@photuris.com> Content-Type: multipart/mixed; boundary="------------45CF9ABE6176ECF7B8CA71D5" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------45CF9ABE6176ECF7B8CA71D5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul, "I am out there"... STM-LOS defect detection time in SDH isn't specified. May take as long as e.g. 50 ms to detect the LOS defect. This isn't important as you already indicate; LOF will do the job to trigger protection switching. STM-LOF defect detection time is 3.625 ms (5 frames for OOF plus 24 frames for LOF). For the case of cable break, STM-LOF will not be reported, while STM-LOS will be detected before the 2.5+/-0.5 seconds defect-to-failure integration timer expires. Regards, Maarten Paul Bonenfant wrote: > > Jeurgen, > > Can't resist (apologies to all for the long message)... > > You wrote: > > > > Stacked protection/restoration: > > If you use protection/restoration at an optical network layer > > (server) and a SONET/SDH network layer (client) the server layer > > switching times should be faster than the client layer reaction > > times, so that the server layer does the protection/restoration > > and the client layer doesn't react. > > > > But as you no doubt well know, by far all the installed legacy > SONET/SDH kit (that the unfortunate carriers are yearning to get > rid of, and which will disappear over time...sorry, I digress...) > detects: > - LOS/LOF on the order of 2.3-100 microseconds (LOS for SONET, > thanks to Bellcore/Telcordia GR-253, unless it's been revised), > or > - 375 microseconds (LOF for SDH -- Maarten please correct me if > I'm wrong, I know you're out there). > > So for the server (optical) layer switching time to be faster > than the client (SONET/SDH) layer reaction time, the optical > layer would have to restore well within, say, 1 millisecond. > > And, in this context, "switching time" may include (depending > upon the particular flavour of optical layer protection/restoration > implemented): detection-time + signaling-time (for 1+1 bidirectional > or shared protection, or restoration) + bridging&switching-time. > To do all that in less than 1 msec is a tall order for any layer. > > Maybe I'm beating a long dead horse here, but this now aging > issue of "optical layer restoration occurring faster than the > SONET/SDH reaction time" keeps cropping up...for a shameless plug > thinly veiled as bit of history, see: > - J. Manchester and P. Bonenfant, "Fiber Optic Network Survivability: > SONET/Optical Protection Layer Interworking," Proc. of NFOEC'96, > Denver, CO, 1996. > (If interested, reply off-list to find out how to get a copy. I know, > referenced material should be posted as either an IETF draft or T1X1 > contribution to make it more readily available, sorry.) > > Juergen, I agree that this is an issue of concern (albeit not new). > Potential solutions to the SONET/SDH-Optical protection layer inter- > working problem include: > - Do nothing (e.g., allow both the SONET/SDH & Optical & perhaps even > other layers to react to the failure...not an attractive approach > unless chaos is an option) > - Implement appropriate holdoff time(s) in one or more of the layers > (again not attractive as it delays restoration if the failure > actually occurs at that layer...also, the holdoff times get > progressively longer in the higher layers) > - Inter-layer signaling (see, for example, ANSI T1X1.5/97-080, > "Protected Domain Boundary Delineation," June 1997: > ftp://ftp.t1.org/pub/t1x1/x15.97/7x150800.pdf > -- an elegant solution, but never gained any traction thanks to > the mess associated with inter-layer signaling) > - Avoid direct overlay of survivability schemes with similar > restoration time-scales (tends to be what is done in practice) > - Coordinate protection layer interworking via a common control plane > across all the network layers (e.g., GMPLS?), as discussed briefly > (for example) in Sec 3.2.3 of: > http://www.ietf.org/internet-drafts/draft-ghani-optical-rings-01.txt > (again for the reference-minded the above discussion can be found in > "Optical Layer Protection and Restoration," OFC'2001 Short Course > SC113/153, Mar. 2001, or "Tutorial on Optical Layer Protection and > Restoration," Proc. of OFC'1999, Paper FF-1, Feb. 1999). > > > As for the appropriate restoration time requirement...for what it's > worth, 50 msec, insofar as it remains an historical artifact, also > continues to be the "psychological" bar that optical netwoking > protection & restoration schemes have to meet, if for no other > reason than the following, prevailing view -- "the new & improved > (optical networking) technology should provide at least as good, > if not better, performance than what preceded it (SONET/SDH)." > > Psychological bars notwithstanding, what then is the appropriate > restoration time requirement? I for one would be interested in > hearing from (even more) carriers regarding which latency-sensitive > applications actually drive the 50msec-range protection/restoration > requirements (my guess: it's not (only) voice). > > Regards, > > Paul > > Heiles Juergen wrote: > > > > Curtis > > > > >Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with .... > > > > you are completely wrong and I suggest you better make measurments and get familiar with SONET before making such statements.. SONET/SDH equipment will not shut down/drop connections. Today SONET connections are permanent connections setup via the management system. An automatic drop of a conneciton as it is the case for switched connections will not occur. What you will see is the insertion of AIS (alarm indication signal) after the detection of an defect. But as soon as the defect is gone the AIS is removed and the connection is running again. AIS is nothing harmful as due to the defect the connection is interupted in any case. Furthermore the AIS avoids downstream alarms (alarm storms). > > > > What could be of concern are the following points. I talk about a server layer for a SONET/SDH network (e.g. an Optical Network) providing protection/restoration: > > > > Stacked protection/restoration: > > If you use protection/restoration at an optical network layer (server) and a SONET/SDH network layer (client) the server layer switching times should be faster than the client layer reaction times, so that the server layer does the protection/restoration and the client layer doesn't react. > > > > Automatic power reduction/automatic laser shutdown APR/ALS > > APR is used for safety reasons in order to avoid harmful emission of laser light in case of a fiber cut. One implementation switches off the transmit laser in case of loss of signal at the receiver. A restart action which is triggered automatically in intervals of several seconds is required in order to test if the link is repaired. Normally the APR function can be switched off if not needed. The APR function needs some careful consideration in case of protection/restoration and automatic connection setup in all optical networks. > > > > Regards > > > > Juergen > > > > > -----Original Message----- > > > From: Curtis Villamizar [SMTP:curtis@workhorse.fictitious.org] > > > Sent: Monday, April 09, 2001 4:37 AM > > > To: Lazer, Monica A, NNAD > > > Cc: 'neil.2.harrison@bt.com'; raszuk@cisco.com; mpls@UU.NET; ccamp@ops.ietf.org > > > Subject: restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels) > > > > > > > > > In message <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com>, "L > > > azer, Monica A, NNAD" writes: > > > > Voice switches will drop the connections after 2.5 seconds. A large number > > > > of dropped calls will cause FCC reportable events, which is something that > > > > US carriers need to avoid. So restoration within this time frame is needed > > > > for support of trunks carrying voice traffic. > > > > > > > > Monica A. Lazer > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > 908 234 8462 > > > > mlazer@att.com > > > > > > > > > Monica, > > > > > > We're off topic, so I changed the subject. > > > > > > Thanks for providing the 2.5 second figure. > > > > > > I've heard carrier transport people grumble about SONET equipment > > > they'd be please to get rid of that will shut down even when used as > > > linear SONET with no protect path and as a result would require > > > <100msec restoration. Since there is enough of this SONET gear, the > > > carriers can't really get rid of it although it will probably > > > disappear over time and so they will make fast restoration a > > > requirement of people they buy from. To be safe, the request for > > > <50msec has been made. > > > > > > If you are not blessed with such equipment or you are able to work > > > around it when doing VoIP, then you are among the fortunate. > > > > > > Then again, this is second hand, so I could be completely wrong. This > > > is not a measurement I've made myself and the SONET equipment is not > > > something I'm familiar with such that I could say with confidence that > > > it could not be configured to hold on longer or to not shut down at> > > > all if there was no protect. > > > > > > OTOH there are those who (claim to) want to configure SONET on some > > > links but not on others and don't want a fast restoration. They want > > > to be assured that restoration will occur only after it is safe to > > > assume that SONET restoration is not available. > > > > > > Curtis --------------45CF9ABE6176ECF7B8CA71D5 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------45CF9ABE6176ECF7B8CA71D5-- From owner-mpls@UU.NET Mon Apr 9 10:49:27 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08240 for ; Mon, 9 Apr 2001 10:49:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkad03477; Mon, 9 Apr 2001 14:47:42 GMT Received: by mail-control.mail.uu.net id QQkkad12750 for mpls-outgoing; Mon, 9 Apr 2001 14:47:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkad12745 for ; Mon, 9 Apr 2001 14:47:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkad24455 for ; Mon, 9 Apr 2001 14:46:54 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkad02314 for ; Mon, 9 Apr 2001 14:46:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA11950 for mpls@uu.net; Mon, 9 Apr 2001 10:46:53 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkad12689 for ; Mon, 9 Apr 2001 14:46:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkad16539 for ; Mon, 9 Apr 2001 14:46:11 GMT Received: from ogma.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQkkad19535 for ; Mon, 9 Apr 2001 14:46:11 GMT Received: from amsterdam.cisco.com (amsterdam.cisco.com [144.254.74.238]) by ogma.cisco.com (Postfix) with ESMTP id BAA84FE; Mon, 9 Apr 2001 16:46:10 +0200 (MET DST) Received: from WDEC-W2K.cisco.com (lon-sto4-lan-vlan112-dhcp11.cisco.com [144.254.104.142]) by amsterdam.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA05612; Mon, 9 Apr 2001 16:46:09 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010409163613.03c3cd50@amsterdam.cisco.com> X-Sender: wdec@amsterdam.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Apr 2001 16:45:52 +0200 To: ytr@123india.com, mpls@UU.NET From: Wojciech Dec Subject: Re: label allocation on shared media Cc: jleu@mindspring.com In-Reply-To: <20010409110424.15588.cpmta@c001.zsm.cp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Ytr, Label's are only local in significance - there is no ambiguity in the scenario you show. Although B and C can pass to A the same numerical value for a label and it might even be for the same FEC, it's A that checks for the FECs next hop(s) (in it's routing table) on the segment and from there determines the LSR(s) (B, C) that has that address bound to it (advertised in TDP/LDP). Following that, A selects for use the label advertised by the chosen LSR(s). Rgds, Woj. At 04:04 09/04/2001 -0700, ytr@123india.com wrote: >Hi all, > > I have a queastion on label allocation on shared (ethernet) media. If > u have already discussed pls provide pointers to mail archives. > > There is chance to have more than 1 same outgoing label at LSR 'A', > which are genearted by LSR B and LSR C in the following situation. > > > > A B > |-------| |-------| > | | | | > | |---------------| | > | | | | | > --------- | --------- > | > |---------|-------| > | | > | | > | | > --------- > C > > > If outgoing labels are diffrentiated on interface basic, this ambiguty > is not resloved. How to resolve this amibguty?. > >Regards >YTR > > >______________________________________________________ >123India.com - India's Premier Portal >Get your Free Email Account at http://www.123india.com _________________________________________________________ Wojciech Dec CCIE# 5563 Phone: +31 (0)20 342 3034 Network Consulting Engineer From owner-mpls@UU.NET Mon Apr 9 11:14:27 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08953 for ; Mon, 9 Apr 2001 11:14:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkae09034; Mon, 9 Apr 2001 15:12:35 GMT Received: by mail-control.mail.uu.net id QQkkae01407 for mpls-outgoing; Mon, 9 Apr 2001 15:12:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkae01396 for ; Mon, 9 Apr 2001 15:11:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkae27793 for ; Mon, 9 Apr 2001 15:10:22 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkkae06966 for ; Mon, 9 Apr 2001 15:10:22 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id D36CD94006; Mon, 9 Apr 2001 11:10:21 -0400 (EDT) Message-ID: <3AD1D0DD.896960F2@sandburst.com> Date: Mon, 09 Apr 2001 11:10:21 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy Cc: "Herbst, Bill" , mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <3.0.5.32.20010406162005.0081bd20@10.1.1.249> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mark, The rule that applies to stacking labels is the same, in one very important aspect, as the rules for using labels in any case: the label must be issued by the entity that is responsible for interpreting them (with one slightly broken exception). Because of this, the limitations you describe exist only in the simplest cases and are not especially relevant since - even in those cases - the labels must (almost always) be issued by the (next hop) receiving entity. Of course, the slighty broken case is the case in which a sender decides to use an explicit NULL label. This one case has the potential to complicate things and should have been explicitly forbidden. -- Eric Gray You wrote (in part): > Hi Bill, > > Your comment raises another question which I have been wondering about. > RFC 3036 sect. 2.1 gives very specific rules for what *packets may be sent* > on a particular LSP. But it doesn't say anything about what higher-level > *LSPs may be stacked* on the LSP. > > Presumably one stacks higher level LSPs whose next hop matches a FEC > element associated with the outer LSP. If one applied the rules of section > 2.1 to the stacking, it would (for example) require that an outer LSP with > a Host Address FEC be chosen in preference to any LSP with an Address > Prefix FEC. > > Was it the intent of the authors that the same rules for assigning packets > to an LSP also be used for assigning higher level LSPs into the LSP? > From owner-mpls@UU.NET Mon Apr 9 11:26:53 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09272 for ; Mon, 9 Apr 2001 11:26:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkaf24300; Mon, 9 Apr 2001 15:25:05 GMT Received: by mail-control.mail.uu.net id QQkkaf02604 for mpls-outgoing; Mon, 9 Apr 2001 15:24:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkaf02562 for ; Mon, 9 Apr 2001 15:24:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkaf25824 for ; Mon, 9 Apr 2001 15:23:51 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkkaf22652 for ; Mon, 9 Apr 2001 15:23:51 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 78D719400A; Mon, 9 Apr 2001 11:23:46 -0400 (EDT) Message-ID: <3AD1D401.B99F9470@sandburst.com> Date: Mon, 09 Apr 2001 11:23:45 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy Cc: mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <3.0.5.32.20010407123425.0082d550@10.1.1.249> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mark, The choice of using explicitly routed LSP tunnels (the term "TE tunnels" could be misleading in this case) for LSP setup for LSPs intended to carry other LSPs may not be as heinous as you seem to believe. First of all, it does address the problem. Second, it is only needed when LSR peers (with respect to some context in which tunneling might be needed) are not adjacent. Thirdly, even when it is needed, it is only needed for the length of a tunnel to that peer. Because of peering concerns in general (with the _dreaded_ "overlay model") this will generally not be very many hops. Finally, tunneling LSPs in other LSPs can only be used when MPLS is ubiquitous at least on links between LSR peers - in any other case, another tunneling mechanism may be used, or packets must be sent using IP routing. -- Eric Gray You wrote: > Thank you for the responses several of you have sent on this question. > After reading your comments, and rereading the various RFCs and I-D's, I > have arrived at a more fundamental issue. > > I had been under the mistaken impression that an LSP set up using LDP and > bound to a Host Address type FEC would fail to be established if it did not > reach all the way to the specified host (LSR). I now understand that these > behave just like LSPs bound to an Address Prefix type FEC, which is to say > that the ingress LSR does not have knowledge of how far the LSP extends. > > This type of behavior seems problematic to me when using LSPs set up by LDP > as tunnels in which to stack higher level LSPs. Since the labels of the > higher level LSPs are meaningless except at the LSRs that distributed them, > if the outer LSPs happen not to reach to the next hop of the inner LSPs > there will not be connectivity of the inner LSP. > > One could try to prevent this problem would from arising by making sure > that MPLS is deployed throughout the entire network connecting the end > points of the higher level LSPs (e.g. PE devices providing VPN services) > but that does not strike me as providing a robust and high confidence > solution. Using TE tunnels set up by RSVP-TE or CR-LDP would avoid the > problem, but that seems to present a different problem of ensuring that all > the required PE-PE tunnels are always present (as previously discussed on > this list). > > -Mark From owner-mpls@UU.NET Mon Apr 9 11:45:07 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09769 for ; Mon, 9 Apr 2001 11:45:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkag20460; Mon, 9 Apr 2001 15:43:13 GMT Received: by mail-control.mail.uu.net id QQkkag04165 for mpls-outgoing; Mon, 9 Apr 2001 15:42:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkag04149 for ; Mon, 9 Apr 2001 15:42:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkag17471 for ; Mon, 9 Apr 2001 15:40:53 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkag06533 for ; Mon, 9 Apr 2001 15:40:52 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA17927 for mpls@uu.net; Mon, 9 Apr 2001 11:40:51 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkag03671 for ; Mon, 9 Apr 2001 15:36:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkag04068 for ; Mon, 9 Apr 2001 15:34:16 GMT Received: from netmail.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail.alcatel.com [128.251.168.50]) id QQkkag23542 for ; Mon, 9 Apr 2001 15:34:16 GMT Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA25671; Mon, 9 Apr 2001 10:34:00 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f39FY7o06987; Mon, 9 Apr 2001 10:34:07 -0500 (CDT) Message-ID: <3AD1D62D.A154AF14@usa.alcatel.com> Date: Mon, 09 Apr 2001 10:33:01 -0500 From: sambasiva mantha Organization: Alcatel X-Mailer: Mozilla 4.73 [en]C-ANS 1.02 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Maarten Vissers CC: Paul Bonenfant , "'curtis@avici.com'" , "Lazer, Monica A, NNAD" , raszuk@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org, "t1x1.5" Subject: Re: restoration time requirement (was Re: Last Call on RSVP LabelAllocation for Backup Tunnels) References: <3AD1C050.629F38BC@photuris.com> <3AD1C788.91113189@lucent.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkkag20460 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA09769 The following is the requirement for LOS on SONET as in GR-253-CORE, Issue 3. R6-54 [416v2] A SONET NE shall monitor all incoming SONET signals (before descrambling) for an “all-zeros patterns,” where an all-zeros pattern corresponds to no light pulses for OC-N optical interfaces and no voltage transitions for STS-1 and STS-3 electrical interfaces. An LOS defect shall be detected when an all-zeros pattern on the incoming SONET signal lasts 100 µs or longer. If an all-zeros pattern lasts 2.3 µs or less, an LOS defect shall not be detected. The treatment of all-zeros patterns lasting between 2.3 µs and 100 µs for the purpose of LOS defect detection is not specified and is therefore left to the choice of the equipment designer. For testing conformance to the LOS detection requirement, it is sufficient to apply an all-zeros pattern lasting at most 2.3 µs, and to apply an all-zeros pattern lasting at least 100 µs. Sambu Maarten Vissers wrote: > Paul, > > "I am out there"... STM-LOS defect detection time in SDH isn't > specified. May take as long as e.g. 50 ms to detect the LOS defect. This > isn't important as you already indicate; LOF will do the job to trigger > protection switching. STM-LOF defect detection time is 3.625 ms (5 > frames for OOF plus 24 frames for LOF). > > For the case of cable break, STM-LOF will not be reported, while STM-LOS > will be detected before the 2.5+/-0.5 seconds defect-to-failure > integration timer expires. > > Regards, > > Maarten > > Paul Bonenfant wrote: > > > > Jeurgen, > > > > Can't resist (apologies to all for the long message)... > > > > You wrote: > > > > > > Stacked protection/restoration: > > > If you use protection/restoration at an optical network layer > > > (server) and a SONET/SDH network layer (client) the server layer > > > switching times should be faster than the client layer reaction > > > times, so that the server layer does the protection/restoration > > > and the client layer doesn't react. > > > > > > > But as you no doubt well know, by far all the installed legacy > > SONET/SDH kit (that the unfortunate carriers are yearning to get > > rid of, and which will disappear over time...sorry, I digress...) > > detects: > > - LOS/LOF on the order of 2.3-100 microseconds (LOS for SONET, > > thanks to Bellcore/Telcordia GR-253, unless it's been revised), > > or > > - 375 microseconds (LOF for SDH -- Maarten please correct me if > > I'm wrong, I know you're out there). > > > > So for the server (optical) layer switching time to be faster > > than the client (SONET/SDH) layer reaction time, the optical > > layer would have to restore well within, say, 1 millisecond. > > > > And, in this context, "switching time" may include (depending > > upon the particular flavour of optical layer protection/restoration > > implemented): detection-time + signaling-time (for 1+1 bidirectional > > or shared protection, or restoration) + bridging&switching-time. > > To do all that in less than 1 msec is a tall order for any layer. > > > > Maybe I'm beating a long dead horse here, but this now aging > > issue of "optical layer restoration occurring faster than the > > SONET/SDH reaction time" keeps cropping up...for a shameless plug > > thinly veiled as bit of history, see: > > - J. Manchester and P. Bonenfant, "Fiber Optic Network Survivability: > > SONET/Optical Protection Layer Interworking," Proc. of NFOEC'96, > > Denver, CO, 1996. > > (If interested, reply off-list to find out how to get a copy. I know, > > referenced material should be posted as either an IETF draft or T1X1 > > contribution to make it more readily available, sorry.) > > > > Juergen, I agree that this is an issue of concern (albeit not new). > > Potential solutions to the SONET/SDH-Optical protection layer inter- > > working problem include: > > - Do nothing (e.g., allow both the SONET/SDH & Optical & perhaps even > > other layers to react to the failure...not an attractive approach > > unless chaos is an option) > > - Implement appropriate holdoff time(s) in one or more of the layers > > (again not attractive as it delays restoration if the failure > > actually occurs at that layer...also, the holdoff times get > > progressively longer in the higher layers) > > - Inter-layer signaling (see, for example, ANSI T1X1.5/97-080, > > "Protected Domain Boundary Delineation," June 1997: > > ftp://ftp.t1.org/pub/t1x1/x15.97/7x150800.pdf > > -- an elegant solution, but never gained any traction thanks to > > the mess associated with inter-layer signaling) > > - Avoid direct overlay of survivability schemes with similar > > restoration time-scales (tends to be what is done in practice) > > - Coordinate protection layer interworking via a common control plane > > across all the network layers (e.g., GMPLS?), as discussed briefly > > (for example) in Sec 3.2.3 of: > > http://www.ietf.org/internet-drafts/draft-ghani-optical-rings-01.txt > > (again for the reference-minded the above discussion can be found in > > "Optical Layer Protection and Restoration," OFC'2001 Short Course > > SC113/153, Mar. 2001, or "Tutorial on Optical Layer Protection and > > Restoration," Proc. of OFC'1999, Paper FF-1, Feb. 1999). > > > > > > As for the appropriate restoration time requirement...for what it's > > worth, 50 msec, insofar as it remains an historical artifact, also > > continues to be the "psychological" bar that optical netwoking > > protection & restoration schemes have to meet, if for no other > > reason than the following, prevailing view -- "the new & improved > > (optical networking) technology should provide at least as good, > > if not better, performance than what preceded it (SONET/SDH)." > > > > Psychological bars notwithstanding, what then is the appropriate > > restoration time requirement? I for one would be interested in > > hearing from (even more) carriers regarding which latency-sensitive > > applications actually drive the 50msec-range protection/restoration > > requirements (my guess: it's not (only) voice). > > > > Regards, > > > > Paul > > > > Heiles Juergen wrote: > > > > > > Curtis > > > > > > >Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with .... > > > > > > you are completely wrong and I suggest you better make measurments and get familiar with SONET before making such statements.. SONET/SDH equipment will not shut down/drop connections. Today SONET connections are permanent connections setup via the management system. An automatic drop of a conneciton as it is the case for switched connections will not occur. What you will see is the insertion of AIS (alarm indication signal) after the detection of an defect. But as soon as the defect is gone the AIS is removed and the connection is running again. AIS is nothing harmful as due to the defect the connection is interupted in any case. Furthermore the AIS avoids downstream alarms (alarm storms). > > > > > > What could be of concern are the following points. I talk about a server layer for a SONET/SDH network (e.g. an Optical Network) providing protection/restoration: > > > > > > Stacked protection/restoration: > > > If you use protection/restoration at an optical network layer (server) and a SONET/SDH network layer (client) the server layer switching times should be faster than the client layer reaction times, so that the server layer does the protection/restoration and the client layer doesn't react. > > > > > > Automatic power reduction/automatic laser shutdown APR/ALS > > > APR is used for safety reasons in order to avoid harmful emission of laser light in case of a fiber cut. One implementation switches off the transmit laser in case of loss of signal at the receiver. A restart action which is triggered automatically in intervals of several seconds is required in order to test if the link is repaired. Normally the APR function can be switched off if not needed. The APR function needs some careful consideration in case of protection/restoration and automatic connection setup in all optical networks. > > > > > > Regards > > > > > > Juergen > > > > > > > -----Original Message----- > > > > From: Curtis Villamizar [SMTP:curtis@workhorse.fictitious.org] > > > > Sent: Monday, April 09, 2001 4:37 AM > > > > To: Lazer, Monica A, NNAD > > > > Cc: 'neil.2.harrison@bt.com'; raszuk@cisco.com; mpls@UU.NET; ccamp@ops.ietf.org > > > > Subject: restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels) > > > > > > > > > > > > In message <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com>, "L > > > > azer, Monica A, NNAD" writes: > > > > > Voice switches will drop the connections after 2.5 seconds. A large number > > > > > of dropped calls will cause FCC reportable events, which is something that > > > > > US carriers need to avoid. So restoration within this time frame is needed > > > > > for support of trunks carrying voice traffic. > > > > > > > > > > Monica A. Lazer > > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > > > 908 234 8462 > > > > > mlazer@att.com > > > > > > > > > > > > Monica, > > > > > > > > We're off topic, so I changed the subject. > > > > > > > > Thanks for providing the 2.5 second figure. > > > > > > > > I've heard carrier transport people grumble about SONET equipment > > > > they'd be please to get rid of that will shut down even when used as > > > > linear SONET with no protect path and as a result would require > > > > <100msec restoration. Since there is enough of this SONET gear, the > > > > carriers can't really get rid of it although it will probably > > > > disappear over time and so they will make fast restoration a > > > > requirement of people they buy from. To be safe, the request for > > > > <50msec has been made. > > > > > > > > If you are not blessed with such equipment or you are able to work > > > > around it when doing VoIP, then you are among the fortunate. > > > > > > > > Then again, this is second hand, so I could be completely wrong. This > > > > is not a measurement I've made myself and the SONET equipment is not > > > > something I'm familiar with such that I could say with confidence that > > > > it could not be configured to hold on longer or to not shut down at> > > > > all if there was no protect. > > > > > > > > OTOH there are those who (claim to) want to configure SONET on some > > > > links but not on others and don't want a fast restoration. They want > > > > to be assured that restoration will occur only after it is safe to > > > > assume that SONET restoration is not available. > > > > > > > > Curtis From owner-mpls@UU.NET Mon Apr 9 12:01:34 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10219 for ; Mon, 9 Apr 2001 12:01:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkah11629; Mon, 9 Apr 2001 15:59:39 GMT Received: by mail-control.mail.uu.net id QQkkah06049 for mpls-outgoing; Mon, 9 Apr 2001 15:59:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkah06038 for ; Mon, 9 Apr 2001 15:58:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkah05127 for ; Mon, 9 Apr 2001 15:58:16 GMT Received: from tomp.smb.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQkkah10054 for ; Mon, 9 Apr 2001 15:58:15 GMT Received: from utfors.se ([10.58.0.153]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GBJ8GO00.UX2; Mon, 9 Apr 2001 18:00:24 +0200 Message-ID: <3AD1DC15.9276F685@utfors.se> Date: Mon, 09 Apr 2001 17:58:13 +0200 From: "Loa Andersson" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: mpls@UU.NET Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels References: <200103282303.SAA15707@pilgrim.cisco.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkkah11629 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10219 All, while moving from one employer to another I've been out of contact with the IETF mailings lists, but here are my two cents on the RSVP backup tunnel. 1. To the discussion of ms requirements. All networks do not have SDH, or might even transport SDH in the MPLS network, either way an MPLS based ms reroute capability is beneficial, especially since it is cheaper than the SDH technology. 2. LSPs may be "concatenated" of segements using different LL technologies, this draft gives us the possibility to detect and reroute independent of the lower layers. 3. The draft fails to mention that the described technology is even more efficient and straightforward if the rerouted traffic is plain IP. No needs for identifying merging tunnels, just take the packet from R2 to R4 through the tunnel, pop and forward on L3. 4. this is a wg last call for a non-wg draft (correct?). Implications? Could I propose it is made a wg document? If appropriate I so move. 5. Neil might be right in saying that the failure modeling needs to be done, but it could be kept out of scope for the document. There are probably many more scenarios that needs to be taken care of than the ones that Neil mentions, e.g. what do R4 do with a label inside the tunnel that is not recognized ? In which cases is it allowed to pop and forward on L3 address? 6. further discussion on different types of failures ("link", "interface" or "node") and the actions to be taken according to failure type would also be useful, but could be done in independent drafts. 7, In the figure at page 4 R7 is the penultimate node (my reading), should the double lines be from R2 to R6 instead of from R7 to R4? 8. In the cases there "additional" labels are needed have any thought been given how much this affects the salability? 9. A thought: would it be possible to establish the backup tunnel (R2-R6-R7-R4), when that is done establish a LDP adjacency through the tunnel and use vanilla LDP DoD to request lables for the FECs representing the tunnels to be backuped? They would benaturally merged in R4, back to the original tunnel. 10. the draft fails to mention complications that comes with resource reservations associated with the backuped tunnels. We need to distinguish a situation where e.g. the same BW is merged back onto the original tunnel from the situation where two tunnels are merged each requiring the full BW that has been assigned to it. 11. in the introduction it is mentioned that this describes how to use RSVP (RFC 2205) to set up back tunnels, this is true but I would like and additional reference to the RSVP-TE: Extensions to RSVP for LSP Tunnels, since this is really what is needed/desscribed. BTW what is the state of that document? I can't see anything in what I mentioned above above or what has been in the responses to the last call, that would make necessary to stop progressing this document. /Loa George Swallow wrote: > This message commences a workgroup last call on "RSVP Label Allocation > for Backup Tunnels" . This > draft is informational. The last call closes April 11, 12 PM GMT. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Mon Apr 9 12:02:41 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10238 for ; Mon, 9 Apr 2001 12:02:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkai13877; Mon, 9 Apr 2001 16:00:56 GMT Received: by mail-control.mail.uu.net id QQkkai06176 for mpls-outgoing; Mon, 9 Apr 2001 16:00:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkah06090 for ; Mon, 9 Apr 2001 15:59:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkah24708 for ; Mon, 9 Apr 2001 15:59:26 GMT Received: from web13701.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13701.mail.yahoo.com [216.136.175.134]) id QQkkah11192 for ; Mon, 9 Apr 2001 15:59:25 GMT Message-ID: <20010409154621.15313.qmail@web13701.mail.yahoo.com> Received: from [203.197.74.150] by web13701.mail.yahoo.com; Mon, 09 Apr 2001 08:46:21 PDT Date: Mon, 9 Apr 2001 08:46:21 -0700 (PDT) From: N S S Kishore Kankipati Subject: MPLS Diffserv To: Shahram Davari Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk hi all DSCP contains 6 bits. Therefore number of PHBs possible is 64 (including default PHB). If an LSR has to support all PHBs it requires at least 8 E-LSPs. If only L-LSPs are used, it requires more than this. If we use both the types of LSPs, the number of LSPs required may be intermediate to the previous two cases. From this we can infer that for every FEC it requires at least 8 LSPs. A LSR may contain more number of FECs and in that case number of LSPs (and labels)required is very large. Isn't there any way to reduce number of LSPs and conserve label space in that case(LSR has to support all PHBs possible)? regards kk __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Mon Apr 9 13:09:54 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11970 for ; Mon, 9 Apr 2001 13:09:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkam18007; Mon, 9 Apr 2001 17:07:44 GMT Received: by mail-control.mail.uu.net id QQkkam14721 for mpls-outgoing; Mon, 9 Apr 2001 17:07:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkam14716 for ; Mon, 9 Apr 2001 17:07:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkam17162 for ; Mon, 9 Apr 2001 17:06:54 GMT Received: from pulsar.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 200-139.adsl6.netlojix.net [207.71.200.139] (may be forged)) id QQkkam18813 for ; Mon, 9 Apr 2001 17:06:54 GMT Received: by pulsar.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 10:04:19 -0700 Message-ID: From: Jonathan Lang To: "'Myunghee Son'" , mpls@UU.NET Cc: Jonathan Lang Subject: RE TE link between PXCs Date: Mon, 9 Apr 2001 10:04:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Myunghee, 1) A TE Link is assigned an Id by both nodes. If the link is numbered, these Ids must be unique within the Area; if the link is unnumbered, these Ids must be unique within the node. For example, if nodes A and B are connected by a single TE link, node A may assign the TE Link Id = 4 and node B may assign the TE Link Id=7. The Local TE Link Id is the Id assigned by the node sending the message. For example, if node A is sending a ChannelFail message to node B, the Local TE Link Id =4. 2) This is a local decision based on policy. LMP LinkSummary message can be used to ensure the assignment is consistent between the adjacent nodes. Jonathan -----Original Message----- From: Myunghee Son [mailto:mhson@etri.re.kr] Sent: Monday, April 09, 2001 5:14 AM To: ietf@ietf.org; mpls@UU.NET Subject: TE link between PXCs Hello, all. On page 15 in draft-ietf-mpls-lmp-02.txt, the TE link is defined a number of data links between two nodes. Related to this fact i have two questions. 1) In ChannelFail msg and ChannelActive msg, what is local TE link id? 2) If there are many data links between two PXCs, how can i divide them into some TE links or one TE link? Best regards, Myunghee. From owner-mpls@UU.NET Mon Apr 9 14:56:52 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14210 for ; Mon, 9 Apr 2001 14:56:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkat16788; Mon, 9 Apr 2001 18:54:16 GMT Received: by mail-control.mail.uu.net id QQkkat10887 for mpls-outgoing; Mon, 9 Apr 2001 18:53:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkat10876 for ; Mon, 9 Apr 2001 18:53:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkat11290 for ; Mon, 9 Apr 2001 18:52:49 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkat20439 for ; Mon, 9 Apr 2001 18:52:49 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA06594 for mpls@uu.net; Mon, 9 Apr 2001 14:52:48 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkat10806 for ; Mon, 9 Apr 2001 18:52:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkat00276 for ; Mon, 9 Apr 2001 18:51:39 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQkkat18892 for ; Mon, 9 Apr 2001 18:51:38 GMT Received: (qmail 27333 invoked by uid 104); 9 Apr 2001 18:51:38 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.424252 secs); 09/04/2001 11:51:37 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 9 Apr 2001 18:51:37 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f39IpnZ00070; Mon, 9 Apr 2001 11:51:49 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id <2NK1BXDN>; Mon, 9 Apr 2001 11:52:39 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BA8@BBY1EXM01> From: Shahram Davari To: "'Jayaram Beladakere'" , "'mpls@uu.net'" Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs Date: Mon, 9 Apr 2001 11:52:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Since this is very similar to what I quoted from RFC-2474, my understanding is that the outgoing EXP should be the same as the incoming EXP. Because from this node's point of view all EXPs mean DF-PHB, so leaving the EXP field unchanged still means DF-PHB to this node. Additionally leaving the EXP field unchanged causes the downstream nodes that have their EXP<=>PHB configured, to treat the packet properly (prevents malfunction). Yours, -Shahram > -----Original Message----- > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > Sent: Saturday, April 07, 2001 3:35 PM > To: Shahram Davari; 'mpls@uu.net' > Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs > > > Shahram, Thanks for this clarification. I have a follow-up > question on this > topic. > > Suppose that the preconfigured EXP<-->PHB table has not been > configured by > the network administrator; thus, all EXP values map to the > Default PHB. If > an E-LSP tunnel is now set up with no Diffserv Context, how > should the LSR > encode the outgoing PHBs? Obviously, the E-LSP tunnel would > only support > Default PHB. But, there are eight EXP field values that map > to that PHB. > Which value shall be used for outgoing EXP field? > > Otherwise, is it mandatory to specify a Diffserv Context for an E-LSP > tunnel? > > Regards, Jayaram > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, March 28, 2001 8:21 AM > To: 'Jayaram Beladakere'; 'mpls@uu.net' > Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs > > > Hi Jayaram, > > The intention of configured E-LSPs is to have the > MPLS+Diffserv network > behave the same as a Diffserv-only network. Since RFC-2474 > section 3 says: > > " > Packets received with an unrecognized codepoint SHOULD be forwarded > as if they were marked for the Default behavior (see Sec. 4), and > their codepoints should not be changed. Such packets MUST > NOT cause > the network node to malfunction. " > > So the answer to you question is that the EXP should be left > unchanged in > the normal swap operation. > > It is however, possible to push another label and have either > non-configured, configured or even signaled E-LSP for the new > LSP (which we > call tunnel-LSP). In that case depending on the type of the > tunnel (Uniform > or pipe), the top label could have its EXP set to the same > EXP, or to the > Default EXP or something else. > > In case the tunnel-LSP is a uniform tunnel that is a > non-configured (and > non-signaled) E-LSP, then the same behavior as explained in > the above quote > from RFC-2474 is the correct behavior (i.e., setting the EXP > of the pushed > label to the same EXP as the incoming label). > > Yours, > -Shahram > > > -----Original Message----- > > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > > Sent: Tuesday, March 27, 2001 2:06 PM > > To: 'mpls@uu.net' > > Subject: Preconfigured EXP<-->PHB mapping for E-LSPs > > > > > > The following is from "MPLS Support of Differentiated Services" > > (draft-ietf-mpls-diff-ext-08.txt). > > > > 3.2.1 Preconfigured EXP<-->PHB mapping > > .... > > In case, the preconfigured EXP<-->PHB mapping has not actually been > > configured by the Network Administrator, the LSR should use a > > default preconfigured EXP<-->PHB mapping which maps all EXP values > > to the Default PHB. > > > > In the above case, the LSR provides Default PHB treatment to > > all labeled > > packets (belonging to LSPs with preconfigured EXP<-->PHB > > mapping). What > > shall be the value of the outgoing EXP field for such labeled > > packets, both > > with label-swap and label-push operations at the LSR? In > > particular, shall > > the outgoing EXP match incoming EXP, or shall it be '000'? > Is there a > > difference if the label operation is swap rather than push? > > > > Regards, > > Jayaram Beladakere > > Mahi Networks, Inc. > > > From owner-mpls@UU.NET Mon Apr 9 15:19:01 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14520 for ; Mon, 9 Apr 2001 15:19:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkav19845; Mon, 9 Apr 2001 19:17:01 GMT Received: by mail-control.mail.uu.net id QQkkav00377 for mpls-outgoing; Mon, 9 Apr 2001 19:15:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkav00366 for ; Mon, 9 Apr 2001 19:15:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkau18597 for ; Mon, 9 Apr 2001 19:12:54 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkau04886 for ; Mon, 9 Apr 2001 19:12:52 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA09136 for mpls@uu.net; Mon, 9 Apr 2001 15:12:52 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkau29253 for ; Mon, 9 Apr 2001 19:08:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkau24165 for ; Mon, 9 Apr 2001 19:06:46 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQkkau26246 for ; Mon, 9 Apr 2001 19:06:46 GMT Received: (qmail 2819 invoked by uid 104); 9 Apr 2001 19:06:46 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.451467 secs); 09/04/2001 12:06:45 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 9 Apr 2001 19:06:45 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f39J6vZ02112; Mon, 9 Apr 2001 12:06:57 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id <2NK1BXPZ>; Mon, 9 Apr 2001 12:07:47 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BA9@BBY1EXM01> From: Shahram Davari To: "'N S S Kishore Kankipati'" Cc: mpls@UU.NET Subject: RE: MPLS Diffserv Date: Mon, 9 Apr 2001 12:07:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, Unfortunately not. Because to identify the PHB of an MPLS packet you need to look at its 4 byte MPLS label stack entry (20 bit label, 3 bit EXP, 1 bit stack, 8 bits TTL). If you don't want to consume MPLS label, then you are have to use 3-bits from TTL-field. I doubt anybody wants to change the semantics of TTL field (=> no backward compatibility). Yours, -Shahram > -----Original Message----- > From: N S S Kishore Kankipati [mailto:kishore_iitb@yahoo.com] > Sent: Monday, April 09, 2001 11:46 AM > To: Shahram Davari > Cc: mpls@uu.net > Subject: MPLS Diffserv > > > hi all > > DSCP contains 6 bits. Therefore number of PHBs > possible > is 64 (including default PHB). If an LSR has to > support all PHBs it requires at least 8 E-LSPs. If > only L-LSPs are used, it requires more than this. If > we use both the types of LSPs, the number of LSPs > required may be intermediate to the previous two > cases. > From this we can infer that for every FEC it requires > at least 8 LSPs. A LSR may contain more number of FECs > and in that case number of LSPs (and labels)required > is very large. > Isn't there any way to reduce number of LSPs and > conserve label space in that case(LSR has to support > all PHBs possible)? > > regards > kk > > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > From owner-mpls@UU.NET Mon Apr 9 15:41:35 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15029 for ; Mon, 9 Apr 2001 15:41:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkap23783; Mon, 9 Apr 2001 17:52:04 GMT Received: by mail-control.mail.uu.net id QQkkap19325 for mpls-outgoing; Mon, 9 Apr 2001 17:51:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkap19283 for ; Mon, 9 Apr 2001 17:51:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkap18977 for ; Mon, 9 Apr 2001 17:49:46 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkkap18746 for ; Mon, 9 Apr 2001 17:49:35 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA02941; Mon, 9 Apr 2001 13:46:14 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104091746.NAA02941@workhorse.fictitious.org> To: Heiles Juergen cc: "'curtis@avici.com'" , "Lazer, Monica A, NNAD" , "'neil.2.harrison@bt.com'" , raszuk@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org Reply-To: curtis@avici.com Subject: Re: restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels) In-reply-to: Your message of "Mon, 09 Apr 2001 09:52:20 +0200." Date: Mon, 09 Apr 2001 13:46:14 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Heiles Juergen writes: > Curtis > > >Then again, this is second hand, so I could be completely wrong. This > is not a measurement I've made myself and the SONET equipment is not somethin > g I'm familiar with .... > > you are completely wrong and I suggest you better make measurments and get fa > miliar with SONET before making such statements.. SONET/SDH equipment will no > t shut down/drop connections. Today SONET connections are permanent connectio > ns setup via the management system. An automatic drop of a conneciton as it i > s the case for switched connections will not occur. What you will see is the > insertion of AIS (alarm indication signal) after the detection of an defect. > But as soon as the defect is gone the AIS is removed and the connection is ru > nning again. AIS is nothing harmful as due to the defect the connection is in > terupted in any case. Furthermore the AIS avoids downstream alarms (alarm sto > rms). There was a similar problem encounterred when sending a packet over a POS link with the old short scrambling pattern in the body of the packet. My understanding was that there was a small chance that alignment with the scrambler could take a SONET link out of service, then take the protect out of service and manual intervention was required to bring them back into service. That is second hand too but someone from an ISP stood up at an IETF meeting and claimed to have tried it with spectacular (though not desireable) results and the statement wasn't challenged (and I know the person and he is a reliable source). This statement was made in response to the assertion that there was no need to change the scrambler pattern length. It was definitely not Siemen SONET gear (but you knew that) and AFAIK it is not called for in the SONET specs but I've been told that some other gear does exhibit this behaviour. US carriers in particular have lots of it which creates a requirement for MPLS restoration that must be met for some but not all networks and applications. My understanding is that this behavior is observed in a particular implementation, the same one that had the problem with DoS attack based on the short scrambler pattern. This SONET gear could not be configured to bring the segment back into service without intervention which was key to making the DoS attack effective. Note: The DoS problem was solved by lengthenning the POS scrambler pattern to be much longer than the MTU, requiring no change to the SONET gear. In pointing out that this is second hand I am noting that it is possible that the problematic implementation might have been upgraded since these two problems have been encountered and could allow a configuration option to change this behaviour. AFAIK this is not the case but I'd be pleased to hear that it has been corrected. We can continue this discussion offline if you like. > What could be of concern are the following points. I talk about a server laye > r for a SONET/SDH network (e.g. an Optical Network) providing protection/res > toration: > > Stacked protection/restoration: > If you use protection/restoration at an optical network layer (server) and a > SONET/SDH network layer (client) the server layer switching times should be f > aster than the client layer reaction times, so that the server layer does the > protection/restoration and the client layer doesn't react. I'm aware of this and I mentioned it below. See paragraph beginning with OTOH below. > Automatic power reduction/automatic laser shutdown APR/ALS > APR is used for safety reasons in order to avoid harmful emission of laser li > ght in case of a fiber cut. One implementation switches off the transmit lase > r in case of loss of signal at the receiver. A restart action which is trigge > red automatically in intervals of several seconds is required in order to tes > t if the link is repaired. Normally the APR function can be switched off if n > ot needed. The APR function needs some careful consideration in case of prote > ction/restoration and automatic connection setup in all optical networks. Thanks for the info. I hadn't heard this. > Regards > > Juergen Regards, Curtis > > -----Original Message----- > > From: Curtis Villamizar [SMTP:curtis@workhorse.fictitious.org] > > Sent: Monday, April 09, 2001 4:37 AM > > To: Lazer, Monica A, NNAD > > Cc: 'neil.2.harrison@bt.com'; raszuk@cisco.com; mpls@UU.NET; ccamp@ops.ietf > .org > > Subject: restoration time requirement (was Re: Last Call on RSVP Label A > llocation for Backup Tunnels) > > > > > > In message <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com> > , "L > > azer, Monica A, NNAD" writes: > > > Voice switches will drop the connections after 2.5 seconds. A large numbe > r > > > of dropped calls will cause FCC reportable events, which is something tha > t > > > US carriers need to avoid. So restoration within this time frame is neede > d > > > for support of trunks carrying voice traffic. > > > > > > Monica A. Lazer > > > Advanced Transport Technology and Architecture Planning > > > > > > 908 234 8462 > > > mlazer@att.com > > > > > > Monica, > > > > We're off topic, so I changed the subject. > > > > Thanks for providing the 2.5 second figure. > > > > I've heard carrier transport people grumble about SONET equipment > > they'd be please to get rid of that will shut down even when used as > > linear SONET with no protect path and as a result would require > > <100msec restoration. Since there is enough of this SONET gear, the > > carriers can't really get rid of it although it will probably > > disappear over time and so they will make fast restoration a > > requirement of people they buy from. To be safe, the request for > > <50msec has been made. > > > > If you are not blessed with such equipment or you are able to work > > around it when doing VoIP, then you are among the fortunate. > > > > Then again, this is second hand, so I could be completely wrong. This > > is not a measurement I've made myself and the SONET equipment is not > > something I'm familiar with such that I could say with confidence that > > it could not be configured to hold on longer or to not shut down at> > > all if there was no protect. > > > > OTOH there are those who (claim to) want to configure SONET on some > > links but not on others and don't want a fast restoration. They want > > to be assured that restoration will occur only after it is safe to > > assume that SONET restoration is not available. > > > > Curtis > From owner-mpls@UU.NET Mon Apr 9 16:01:39 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15502 for ; Mon, 9 Apr 2001 16:01:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkax18812; Mon, 9 Apr 2001 19:59:19 GMT Received: by mail-control.mail.uu.net id QQkkax04106 for mpls-outgoing; Mon, 9 Apr 2001 19:58:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkax04098 for ; Mon, 9 Apr 2001 19:58:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkax22354 for ; Mon, 9 Apr 2001 19:57:46 GMT Received: from exchange-west.photuris.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.3.135.228]) id QQkkax07099 for ; Mon, 9 Apr 2001 19:57:46 GMT Received: from PH0260739277U (PH02-60739277U [192.168.3.137]) by exchange-west.photuris.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2M6Q0NX9; Mon, 9 Apr 2001 12:44:18 -0700 Message-ID: <000601c0c12f$99d8a670$8903a8c0@PH0260739277U> Reply-To: "Xipeng Xiao" From: "Xipeng Xiao" To: "N S S Kishore Kankipati" , "Shahram Davari" Cc: References: <20010409154621.15313.qmail@web13701.mail.yahoo.com> Subject: Re: MPLS Diffserv Date: Mon, 9 Apr 2001 12:54:52 -0700 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.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Comments in line. > hi all > > DSCP contains 6 bits. Therefore number of PHBs > possible > is 64 (including default PHB). If an LSR has to > support all PHBs it requires at least 8 E-LSPs. If > only L-LSPs are used, it requires more than this. If > we use both the types of LSPs, the number of LSPs > required may be intermediate to the previous two > cases. But not all 64 PHBs are needed. In fact, 8 PHBs are likely to be more than sufficient in most cases. In that case, n<8 lsps (e-lsps and/or l-lsps) are enough. > >From this we can infer that for every FEC it requires > at least 8 LSPs. A LSR may contain more number of FECs > and in that case number of LSPs (and labels)required > is very large. > Isn't there any way to reduce number of LSPs and > conserve label space in that case(LSR has to support > all PHBs possible)? See above. Regards, XiPeng From owner-mpls@UU.NET Mon Apr 9 16:09:48 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15816 for ; Mon, 9 Apr 2001 16:09:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkay21314; Mon, 9 Apr 2001 20:07:50 GMT Received: by mail-control.mail.uu.net id QQkkay21837 for mpls-outgoing; Mon, 9 Apr 2001 20:07:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkay21824 for ; Mon, 9 Apr 2001 20:07:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkay18785 for ; Mon, 9 Apr 2001 20:06:46 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkkay29265 for ; Mon, 9 Apr 2001 20:06:44 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA04008; Mon, 9 Apr 2001 16:06:33 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104092006.QAA04008@workhorse.fictitious.org> To: Wil.Walkoe@mail.sprint.com cc: diffserv@ietf.org, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: EndToEndQos.doc In-reply-to: Your message of "Sun, 08 Apr 2001 18:47:05 CDT." Date: Mon, 09 Apr 2001 16:06:33 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Wil.Walkoe@mail.sprint.c om writes: > > --openmail-part-238944ed-00000001 > Content-Type: text/plain; charset=US-ASCII > Content-Disposition: inline > ;Creation-Date="Sun, 8 Apr 2001 18:47:03 -0500" > Content-Transfer-Encoding: 7bit > > Dear people, > > The attached document is a working draft from the Broadband Content > Delivery Forum's Infrastructure Working Group, addressing quality of > service in end-to-end data delivery. It addresses QoS from a > perspective that takes account of the many different intermediaries > that play a role in data delivery and contribute to end-to-end delay, > throughput, etc. > > I would be interested in your comments on this material, both on the > content itself (errors, omissions, material from your standards work > that should be addressed) and on where this topic could most > effectively be addressed in the IETF. > > We will be editing this draft at the BCD Forum meeting April 25 - 27 in > Las Vegas, and it would be very helpful to be able to include your > ideas in the process. > > Sincerely, > Wil Walkoe > Vice-Chair, BCD Forum Infrastructure Working Group Documents should not be sent to IETF mailing list in proprietary formats. MS-Word is not a open standard. Curtis From owner-mpls@UU.NET Mon Apr 9 16:44:43 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16732 for ; Mon, 9 Apr 2001 16:44:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkba28657; Mon, 9 Apr 2001 20:42:39 GMT Received: by mail-control.mail.uu.net id QQkkba25239 for mpls-outgoing; Mon, 9 Apr 2001 20:42:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkba25234 for ; Mon, 9 Apr 2001 20:42:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkba25293 for ; Mon, 9 Apr 2001 20:41:15 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkkba06992 for ; Mon, 9 Apr 2001 20:41:13 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA04125; Mon, 9 Apr 2001 16:40:57 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104092040.QAA04125@workhorse.fictitious.org> To: N S S Kishore Kankipati cc: Shahram Davari , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS Diffserv In-reply-to: Your message of "Mon, 09 Apr 2001 08:46:21 PDT." <20010409154621.15313.qmail@web13701.mail.yahoo.com> Date: Mon, 09 Apr 2001 16:40:57 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20010409154621.15313.qmail@web13701.mail.yahoo.com>, N S S Kishore Kankipati writes: > hi all > > DSCP contains 6 bits. Therefore number of PHBs > possible > is 64 (including default PHB). If an LSR has to > support all PHBs it requires at least 8 E-LSPs. If > only L-LSPs are used, it requires more than this. If > we use both the types of LSPs, the number of LSPs > required may be intermediate to the previous two > cases. > From this we can infer that for every FEC it requires > at least 8 LSPs. A LSR may contain more number of FECs > and in that case number of LSPs (and labels)required > is very large. > Isn't there any way to reduce number of LSPs and > conserve label space in that case(LSR has to support > all PHBs possible)? > > regards > kk If a network uses a subset of the possible 64 DSCP values, all unrecognized values are mapped to best effort service. In practice, a small set of DSCP values are used (often just one, BE). If all 64 values were in use there would be a need for lots of MPLS LSPs. Curtis From owner-mpls@UU.NET Mon Apr 9 19:25:28 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19056 for ; Mon, 9 Apr 2001 19:25:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkbl22337; Mon, 9 Apr 2001 23:23:31 GMT Received: by mail-control.mail.uu.net id QQkkbl00041 for mpls-outgoing; Mon, 9 Apr 2001 23:22:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkbl00036 for ; Mon, 9 Apr 2001 23:22:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkbl20362 for ; Mon, 9 Apr 2001 23:21:47 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQkkbl04380 for ; Mon, 9 Apr 2001 23:21:47 GMT Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQ3L4XDC; Mon, 9 Apr 2001 19:21:46 -0400 Message-Id: <3.0.5.32.20010409185117.008cae70@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 09 Apr 2001 18:51:17 -0400 To: curtis@avici.com From: Mark Duffy Subject: Re: Use of LDP for VPNs Cc: "Herbst, Bill" , mpls@UU.NET In-Reply-To: <200104090251.WAA00773@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, At 10:51 PM 4/8/01 -0400, Curtis Villamizar wrote: > >In message <3.0.5.32.20010406162005.0081bd20@10.1.1.249>, Mark Duffy writes: >> Hi Bill, >> >> Your comment raises another question which I have been wondering about. >> RFC 3036 sect. 2.1 gives very specific rules for what *packets may be sent* >> on a particular LSP. But it doesn't say anything about what higher-level >> *LSPs may be stacked* on the LSP. >> >> Presumably one stacks higher level LSPs whose next hop matches a FEC >> element associated with the outer LSP. If one applied the rules of section >> 2.1 to the stacking, it would (for example) require that an outer LSP with >> a Host Address FEC be chosen in preference to any LSP with an Address >> Prefix FEC. > > >For most usage of MPLS, the notion of FEC is a broken one. In >RSVP/TE, there is no FEC signalled which is a good thing. For a >hierarchical tunnel, you can carry any traffic that needs to pass that >way. A specific case would be a BGP VPN tunnel directly inside a TE >tunnel (which elsewhere could go directly inside another TE tunnel). I don't disagree with your statement, however I don't believe it addresses my question. The question related to the use of LDP for topology driven hop by hop LSP set up and the FEC elements that are assigned to LSPs when they are set up in this manner. RFC 3036 sect. 2.1 gives rules for what packets may be sent on these LSPs, depending what FEC elements are associated with the LSPs. These rules have to do with making the whole use of topology (routing) -driven LSPs "work" as a replacement for traditional hop-by-hop IP forwarding. So the question is, when stacking LSPs set up by other means into topology-driven-LDP-created-ones, what is one to make of those rules? May they be freely ignored? (I supposed you will tell me that the whole use of LDP for topology driven set up should be freely ignored :-) and I would not necessarily disagree with you.) > >If an outer tunnel will only accept inner tunnels with a specific >L3PID, then we set that L3PID on the outer tunnel. If it is allowed >to carry any L3PID, then the MPLS L3PID is used. If the MPLS L3PID is >used, this also indicates that there must be another label underneath >since there is no way to determine how to interpret the payload. > >Curtis > From owner-mpls@UU.NET Mon Apr 9 19:28:16 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19102 for ; Mon, 9 Apr 2001 19:28:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkbl14806; Mon, 9 Apr 2001 23:26:01 GMT Received: by mail-control.mail.uu.net id QQkkbl00132 for mpls-outgoing; Mon, 9 Apr 2001 23:25:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkbl00114 for ; Mon, 9 Apr 2001 23:25:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkbl25156 for ; Mon, 9 Apr 2001 23:24:42 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQkkbl07977 for ; Mon, 9 Apr 2001 23:24:41 GMT Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQ3L4XDM; Mon, 9 Apr 2001 19:24:40 -0400 Message-Id: <3.0.5.32.20010409192059.008c8370@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 09 Apr 2001 19:20:59 -0400 To: Eric Gray From: Mark Duffy Subject: Re: Use of LDP for VPNs Cc: mpls@UU.NET In-Reply-To: <3AD1D401.B99F9470@sandburst.com> References: <3.0.5.32.20010407123425.0082d550@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, A few more questions below, thanks. -Mark At 11:23 AM 4/9/01 -0400, Eric Gray wrote: >Mark, > > The choice of using explicitly routed LSP tunnels (the term >"TE tunnels" could be misleading in this case) for LSP setup >for LSPs intended to carry other LSPs may not be as heinous >as you seem to believe. First of all, it does address the problem. Well, I actually didn't call it heinous! I am pursuing this line of questioning because rfc 2547bis calls for the capability of using topology-driven LDP distribution of labels to set up the "outer" LSPs used to tunnel the VPN-specific LSPs. There were some emails exchanged on this list in January in support of that; more recently I've seen some messages opposed to the use of LDP for that. >Second, it is only needed when LSR peers (with respect to some >context in which tunneling might be needed) are not adjacent. >Thirdly, even when it is needed, it is only needed for the length >of a tunnel to that peer. Because of peering concerns in general >(with the _dreaded_ "overlay model") this will generally not be >very many hops. Finally, tunneling LSPs in other LSPs can only Would you explain why the overlay model would have anything to do with the number of hops? I think we're talking about a VPN scenario where VPN-specific LSPs are tunneled in other LSPs across some shared backbone; I don't see why the diameter of that backbone should have a scalability impact on this. Specifically, the number of adjacencies in the overlay network (i.e. the VPN) is constant regardless of the number of backbone LSR hops. >be used when MPLS is ubiquitous at least on links between LSR >peers - in any other case, another tunneling mechanism may be >used, or packets must be sent using IP routing. Ahh, and that was exactly what drove my original question. If MPLS is not ubiquitous between the LSRs that are adjacent at the higher level, then the higher level LSP is broken. And my question/complaint is (since 2547bis calls for the capability to use LDP to distribute the outer label) that the use of LDP does not provide knowledge of whether there is MPLS connectivity between the LSRs that are to be adjacent at the higher level. > >-- >Eric Gray > >You wrote: > >> Thank you for the responses several of you have sent on this question. >> After reading your comments, and rereading the various RFCs and I-D's, I >> have arrived at a more fundamental issue. >> >> I had been under the mistaken impression that an LSP set up using LDP and >> bound to a Host Address type FEC would fail to be established if it did not >> reach all the way to the specified host (LSR). I now understand that these >> behave just like LSPs bound to an Address Prefix type FEC, which is to say >> that the ingress LSR does not have knowledge of how far the LSP extends. >> >> This type of behavior seems problematic to me when using LSPs set up by LDP >> as tunnels in which to stack higher level LSPs. Since the labels of the >> higher level LSPs are meaningless except at the LSRs that distributed them, >> if the outer LSPs happen not to reach to the next hop of the inner LSPs >> there will not be connectivity of the inner LSP. >> >> One could try to prevent this problem would from arising by making sure >> that MPLS is deployed throughout the entire network connecting the end >> points of the higher level LSPs (e.g. PE devices providing VPN services) >> but that does not strike me as providing a robust and high confidence >> solution. Using TE tunnels set up by RSVP-TE or CR-LDP would avoid the >> problem, but that seems to present a different problem of ensuring that all >> the required PE-PE tunnels are always present (as previously discussed on >> this list). >> >> -Mark > From owner-mpls@UU.NET Mon Apr 9 19:41:06 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19465 for ; Mon, 9 Apr 2001 19:41:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkbm13185; Mon, 9 Apr 2001 23:39:29 GMT Received: by mail-control.mail.uu.net id QQkkbm00518 for mpls-outgoing; Mon, 9 Apr 2001 23:38:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkbm00512 for ; Mon, 9 Apr 2001 23:38:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkbm25643 for ; Mon, 9 Apr 2001 23:37:21 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkkbm24311 for ; Mon, 9 Apr 2001 23:37:20 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id A919294006; Mon, 9 Apr 2001 19:37:20 -0400 (EDT) Message-ID: <3AD247B0.CB3D8BED@sandburst.com> Date: Mon, 09 Apr 2001 19:37:20 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy Cc: mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <3.0.5.32.20010407123425.0082d550@10.1.1.249> <3.0.5.32.20010409192059.008c8370@10.1.1.249> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mark, Why don't we handle this off-line? -- Eric Gray You wrote: > Hi Eric, > A few more questions below, thanks. > -Mark > > At 11:23 AM 4/9/01 -0400, Eric Gray wrote: > >Mark, > > > > The choice of using explicitly routed LSP tunnels (the term > >"TE tunnels" could be misleading in this case) for LSP setup > >for LSPs intended to carry other LSPs may not be as heinous > >as you seem to believe. First of all, it does address the problem. > > Well, I actually didn't call it heinous! I am pursuing this line of > questioning because rfc 2547bis calls for the capability of using > topology-driven LDP distribution of labels to set up the "outer" LSPs used > to tunnel the VPN-specific LSPs. There were some emails exchanged on this > list in January in support of that; more recently I've seen some messages > opposed to the use of LDP for that. > > >Second, it is only needed when LSR peers (with respect to some > >context in which tunneling might be needed) are not adjacent. > >Thirdly, even when it is needed, it is only needed for the length > >of a tunnel to that peer. Because of peering concerns in general > >(with the _dreaded_ "overlay model") this will generally not be > >very many hops. Finally, tunneling LSPs in other LSPs can only > > Would you explain why the overlay model would have anything to do with the > number of hops? I think we're talking about a VPN scenario where > VPN-specific LSPs are tunneled in other LSPs across some shared backbone; I > don't see why the diameter of that backbone should have a scalability > impact on this. Specifically, the number of adjacencies in the overlay > network (i.e. the VPN) is constant regardless of the number of backbone LSR > hops. > > >be used when MPLS is ubiquitous at least on links between LSR > >peers - in any other case, another tunneling mechanism may be > >used, or packets must be sent using IP routing. > > Ahh, and that was exactly what drove my original question. If MPLS is not > ubiquitous between the LSRs that are adjacent at the higher level, then the > higher level LSP is broken. And my question/complaint is (since 2547bis > calls for the capability to use LDP to distribute the outer label) that the > use of LDP does not provide knowledge of whether there is MPLS connectivity > between the LSRs that are to be adjacent at the higher level. > > > > >-- > >Eric Gray > > > >You wrote: > > > >> Thank you for the responses several of you have sent on this question. > >> After reading your comments, and rereading the various RFCs and I-D's, I > >> have arrived at a more fundamental issue. > >> > >> I had been under the mistaken impression that an LSP set up using LDP and > >> bound to a Host Address type FEC would fail to be established if it did not > >> reach all the way to the specified host (LSR). I now understand that these > >> behave just like LSPs bound to an Address Prefix type FEC, which is to say > >> that the ingress LSR does not have knowledge of how far the LSP extends. > >> > >> This type of behavior seems problematic to me when using LSPs set up by LDP > >> as tunnels in which to stack higher level LSPs. Since the labels of the > >> higher level LSPs are meaningless except at the LSRs that distributed them, > >> if the outer LSPs happen not to reach to the next hop of the inner LSPs > >> there will not be connectivity of the inner LSP. > >> > >> One could try to prevent this problem would from arising by making sure > >> that MPLS is deployed throughout the entire network connecting the end > >> points of the higher level LSPs (e.g. PE devices providing VPN services) > >> but that does not strike me as providing a robust and high confidence > >> solution. Using TE tunnels set up by RSVP-TE or CR-LDP would avoid the > >> problem, but that seems to present a different problem of ensuring that all > >> the required PE-PE tunnels are always present (as previously discussed on > >> this list). > >> > >> -Mark > > From owner-mpls@UU.NET Mon Apr 9 21:21:19 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20814 for ; Mon, 9 Apr 2001 21:21:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkbt27474; Tue, 10 Apr 2001 01:19:31 GMT Received: by mail-control.mail.uu.net id QQkkbt08462 for mpls-outgoing; Tue, 10 Apr 2001 01:15:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkbt08457 for ; Tue, 10 Apr 2001 01:15:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkbs15913 for ; Tue, 10 Apr 2001 01:14:31 GMT Received: from zrtps06u.us.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) id QQkkbs07699 for ; Tue, 10 Apr 2001 01:14:31 GMT Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3A1D9J02398 for ; Mon, 9 Apr 2001 21:13:09 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 9 Apr 2001 21:14:29 -0400 Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2M6KPFHP; Mon, 9 Apr 2001 21:14:28 -0400 Received: from americasm01.nt.com (acart132.ca.nortel.com [47.129.8.145]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2FLVVHJC; Mon, 9 Apr 2001 21:14:31 -0400 Message-ID: <3AD25EDD.823E4AD1@americasm01.nt.com> Date: Mon, 09 Apr 2001 21:16:13 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Goguen , George Swallow CC: mpls@UU.NET Subject: Comments on Bypass Label draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert, George: Below are some comments on, and questions about, your bypass label draft. - Philip ---------------------- * Distinction between "Bypass" and "Backup" It seems to me that this draft tries to make a distinction between a "bypass tunnel" (the outer LSP in the many to one case) and a "backup tunnel" (the inner LSP in the many to one case, as well as the only LSP in the one to one case). However, there are some places where it seems to me that this distinction is not maintained. For example, in the discussion of the many-to-one case in section 2, the word "backup" is used in places where I think "bypass" is meant. Is this distinction intentional, or am I reading more into the draft than was meant? Am I correct in think that the draft confuses the two terms in some places? If this distinction was indeed intentional, then may I suggest the distinction be described more clearly in section 1? * SESSION_TEMPLATE for Backup tunnel Section 3 states "If the head-end of a tunnel is also acting as the PLR, it must choose an IP address different from the one used in the SENDER_TEMPLATE of the original LSP tunnel". Why? Choosing a different address means that the merge point must forward both Path messages on to the downstream LSR, rather than sending just one Path message. * Refreshing a backup tunnel riding a bypass tunnel I don't understand how the refresh works in this case. Section 2 states that the Path message for the backup tunnel is sent inside the bypass tunnel, while section 3 states that the SENDER_TEMPLATE object contains a sender address that differs from the address used for the primary LSP. So the merge point LSR will create a new Path State Block and try to send back a Resv message. But where does it send this Resv to? If the network is as shown in figure on page 4, then it can send the RESV message on either the link to R3 or the link to R7. However, in either case, R3 or R7 will intercept the Resv message, and because neither one is expecting a Resv message with this sender (because neither saw the corresponding Path message), problems ensue. * Second sentence in section 4 I don't understand the sentence "When using a bypass tunnel, the backed up tunnels are only one LSP hop from rejoining their primary LSPs". It seems to me that this section is addressing the case where the backup LSPs rejoin their corresponding primary LSP at a point 2 or more LSP hops away. (For example, in the figure on page 4, the bypass tunnel runs from R2 to R4, so the bypass tunnels rejoin after two LSP hops). * SESSION_TEMPLATE usage in Section 4 case When refreshing the backup tunnels in this case, are the SESSION_TEMPLATE objects updated as described in section 3? Or is the original SESSION_TEMPLATE used? ============= From owner-mpls@UU.NET Mon Apr 9 21:23:20 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20884 for ; Mon, 9 Apr 2001 21:23:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkbt16692; Tue, 10 Apr 2001 01:21:05 GMT Received: by mail-control.mail.uu.net id QQkkbt08544 for mpls-outgoing; Tue, 10 Apr 2001 01:18:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkbt08502 for ; Tue, 10 Apr 2001 01:18:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkbs29043 for ; Tue, 10 Apr 2001 01:14:51 GMT Received: from zrtps06u.us.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) id QQkkbs08136 for ; Tue, 10 Apr 2001 01:14:50 GMT Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3A1DSJ03552 for ; Mon, 9 Apr 2001 21:13:28 -0400 (EDT) Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 9 Apr 2001 21:14:48 -0400 Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2RM85XY2; Mon, 9 Apr 2001 21:14:43 -0400 Received: from americasm01.nt.com (acart132.ca.nortel.com [47.129.8.145]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2FLVVHJ1; Mon, 9 Apr 2001 21:14:43 -0400 Message-ID: <3AD25EE9.A4B03D3A@americasm01.nt.com> Date: Mon, 09 Apr 2001 21:16:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Goguen , George Swallow CC: mpls@UU.NET Subject: More comments on Bypass Label draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert, George: Below are some more comments on "RSVP Label Allocation for Backup Tunnels". These comments here are mainly editorial in nature. - Philip ------------ * "Global label space" In section 2, the draft states that, if the merge node uses a "global label space", then it will recognize and properly process packets arriving on an interface other than the one the LSP has been signalled on. Though I understand what the draft is trying to say, I think this point requires some clarification. A node could allocate RSVP labels from a platform-wide label space (in the sense that it would not reuse the same label on different interfaces), but only program the label on the expected ingress interface. In that case, the technique described here would not work. I suggest adding a paragraph describing exactly what behaviour you are assuming. * More on "global label space" Where does the term "global label space" come from? If I remember correctly, the MPLS Architecture document uses the term "platform-wide label space". Perhaps consistency with the Architecture doc might be a good thing. * "One to many" vs "Many to one" In some places, the draft uses the term "one to many" backup, and in other places, the term "many to one" backup. Could one term be used consistently? * Section 3.1 It is really necessary to repeat verbatum the definition of the fields in the SESSION and SENDER_TEMPLATE objects? Perhaps a pointer to [RSVP-TE] would suffice. * Missing double line In the figure on page 4, I believe the link between R2 and R6 should have a double line, not a single line. * "effecting global repair" Suggest using "achieving global repair" instead. * Typos - "repair to when" on page 3 - "if," (rather than "If,") on page 5 - "case the, an" on page 7 From owner-mpls@UU.NET Mon Apr 9 21:39:49 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21969 for ; Mon, 9 Apr 2001 21:39:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkbu22791; Tue, 10 Apr 2001 01:38:04 GMT Received: by mail-control.mail.uu.net id QQkkbu09300 for mpls-outgoing; Tue, 10 Apr 2001 01:37:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkbu09293 for ; Tue, 10 Apr 2001 01:37:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkbu12320 for ; Tue, 10 Apr 2001 01:35:00 GMT Received: from interceptor.mahinetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: 216-174-224-194.atgi.net [216.174.224.194]) id QQkkbu18660 for ; Tue, 10 Apr 2001 01:34:59 GMT Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Mon, 09 Apr 2001 18:39:47 -0700 (Pacific Daylight Time) Received: by main.mahinetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Apr 2001 18:36:27 -0700 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C992137F@main.mahinetworks.com> From: Jayaram Beladakere To: "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs Date: Mon, 9 Apr 2001 18:36:26 -0700 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 question, as I asked previously, may not have been completely clear. I will attempt to elaborate. I understand that many-to-one mapping of many EXP field values to one PHB is possible with the preconfigured EXP<-->PHB mapping. The following are two examples. i) When the preconfigured EXP<-->PHB mapping has not actually been configured by the Network Administrator, the LSR uses a default preconfigured EXP<-->PHB mapping which maps all EXP values to the Default PHB. ii) A network administrator may map 000, 001 and 010 to Default PHB and 110 and 111 to EF PHB. Consider an E-LSP that is tunneled in another E-LSP using the PIPE MODEL. Assume that neither LSP is specified with a Diffserv Context, so that both use the preconfigured EXP<-->PHB mapping. While the incoming PHB determination is clear (section 3.3 of draft 0.8), what is not clear is the encoding of outgoing EXP field (section 3.4.1). Specifically, I have the following question: With many-to-one mapping of EXP-to-PHB in the preconfigured EXP<-->PHB mapping, how shall the outgoing EXP be encoded for a PHB? There are many EXP field values that each correspond to the same PHB. I am not sure that using the same value as incoming EXP field is the intention with Pipe model. Is it mandatory to specify a Diffserv Context for the tunnel LSP (that maps a PHB to only one outgoing EXP field value)? Jayaram -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Monday, April 09, 2001 11:53 AM To: 'Jayaram Beladakere'; 'mpls@uu.net' Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs Hi, Since this is very similar to what I quoted from RFC-2474, my understanding is that the outgoing EXP should be the same as the incoming EXP. Because from this node's point of view all EXPs mean DF-PHB, so leaving the EXP field unchanged still means DF-PHB to this node. Additionally leaving the EXP field unchanged causes the downstream nodes that have their EXP<=>PHB configured, to treat the packet properly (prevents malfunction). Yours, -Shahram > -----Original Message----- > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > Sent: Saturday, April 07, 2001 3:35 PM > To: Shahram Davari; 'mpls@uu.net' > Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs > > > Shahram, Thanks for this clarification. I have a follow-up > question on this > topic. > > Suppose that the preconfigured EXP<-->PHB table has not been > configured by > the network administrator; thus, all EXP values map to the > Default PHB. If > an E-LSP tunnel is now set up with no Diffserv Context, how > should the LSR > encode the outgoing PHBs? Obviously, the E-LSP tunnel would > only support > Default PHB. But, there are eight EXP field values that map > to that PHB. > Which value shall be used for outgoing EXP field? > > Otherwise, is it mandatory to specify a Diffserv Context for an E-LSP > tunnel? > > Regards, Jayaram > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, March 28, 2001 8:21 AM > To: 'Jayaram Beladakere'; 'mpls@uu.net' > Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs > > > Hi Jayaram, > > The intention of configured E-LSPs is to have the > MPLS+Diffserv network > behave the same as a Diffserv-only network. Since RFC-2474 > section 3 says: > > " > Packets received with an unrecognized codepoint SHOULD be forwarded > as if they were marked for the Default behavior (see Sec. 4), and > their codepoints should not be changed. Such packets MUST > NOT cause > the network node to malfunction. " > > So the answer to you question is that the EXP should be left > unchanged in > the normal swap operation. > > It is however, possible to push another label and have either > non-configured, configured or even signaled E-LSP for the new > LSP (which we > call tunnel-LSP). In that case depending on the type of the > tunnel (Uniform > or pipe), the top label could have its EXP set to the same > EXP, or to the > Default EXP or something else. > > In case the tunnel-LSP is a uniform tunnel that is a > non-configured (and > non-signaled) E-LSP, then the same behavior as explained in > the above quote > from RFC-2474 is the correct behavior (i.e., setting the EXP > of the pushed > label to the same EXP as the incoming label). > > Yours, > -Shahram > > > -----Original Message----- > > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > > Sent: Tuesday, March 27, 2001 2:06 PM > > To: 'mpls@uu.net' > > Subject: Preconfigured EXP<-->PHB mapping for E-LSPs > > > > > > The following is from "MPLS Support of Differentiated Services" > > (draft-ietf-mpls-diff-ext-08.txt). > > > > 3.2.1 Preconfigured EXP<-->PHB mapping > > .... > > In case, the preconfigured EXP<-->PHB mapping has not actually been > > configured by the Network Administrator, the LSR should use a > > default preconfigured EXP<-->PHB mapping which maps all EXP values > > to the Default PHB. > > > > In the above case, the LSR provides Default PHB treatment to > > all labeled > > packets (belonging to LSPs with preconfigured EXP<-->PHB > > mapping). What > > shall be the value of the outgoing EXP field for such labeled > > packets, both > > with label-swap and label-push operations at the LSR? In > > particular, shall > > the outgoing EXP match incoming EXP, or shall it be '000'? > Is there a > > difference if the label operation is swap rather than push? > > > > Regards, > > Jayaram Beladakere > > Mahi Networks, Inc. > > > From owner-mpls@UU.NET Tue Apr 10 03:11:04 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09116 for ; Tue, 10 Apr 2001 03:11:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkcq15181; Tue, 10 Apr 2001 07:09:17 GMT Received: by mail-control.mail.uu.net id QQkkcq07467 for mpls-outgoing; Tue, 10 Apr 2001 07:08:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkcq07458 for ; Tue, 10 Apr 2001 07:08:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkcq07105 for ; Tue, 10 Apr 2001 07:07:44 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkkcq06754 for ; Tue, 10 Apr 2001 07:07:43 GMT Received: from chqlubnt02.lon.bt.com by gollum (local) with ESMTP; Tue, 10 Apr 2001 08:08:43 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <1TTJTF6Z>; Tue, 10 Apr 2001 08:07:01 +0100 Message-ID: To: eric.gray@sandburst.com, mduffy@quarrytech.com Cc: mpls@UU.NET Subject: RE: Use of LDP for VPNs Date: Tue, 10 Apr 2001 08:06:49 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I'd like to see the discussion, since I hold similar views to Mark that there are some disadvantages with vanilla LDP (as compared to ER LSPs) as the server LSPs for VPNs....so if you go off list then please copy me. thanks, neil > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: 10 April 2001 00:37 > To: Mark Duffy > Cc: mpls@UU.NET > Subject: Re: Use of LDP for VPNs > > > Mark, > > Why don't we handle this off-line? > > -- > Eric Gray > > You wrote: > > > Hi Eric, > > A few more questions below, thanks. > > -Mark > > > > At 11:23 AM 4/9/01 -0400, Eric Gray wrote: > > >Mark, > > > > > > The choice of using explicitly routed LSP tunnels (the term > > >"TE tunnels" could be misleading in this case) for LSP setup > > >for LSPs intended to carry other LSPs may not be as heinous > > >as you seem to believe. First of all, it does address the problem. > > > > Well, I actually didn't call it heinous! I am pursuing this line of > > questioning because rfc 2547bis calls for the capability of using > > topology-driven LDP distribution of labels to set up the > "outer" LSPs used > > to tunnel the VPN-specific LSPs. There were some emails > exchanged on this > > list in January in support of that; more recently I've seen > some messages > > opposed to the use of LDP for that. > > > > >Second, it is only needed when LSR peers (with respect to some > > >context in which tunneling might be needed) are not adjacent. > > >Thirdly, even when it is needed, it is only needed for the length > > >of a tunnel to that peer. Because of peering concerns in general > > >(with the _dreaded_ "overlay model") this will generally not be > > >very many hops. Finally, tunneling LSPs in other LSPs can only > > > > Would you explain why the overlay model would have anything > to do with the > > number of hops? I think we're talking about a VPN scenario where > > VPN-specific LSPs are tunneled in other LSPs across some > shared backbone; I > > don't see why the diameter of that backbone should have a > scalability > > impact on this. Specifically, the number of adjacencies in > the overlay > > network (i.e. the VPN) is constant regardless of the number > of backbone LSR > > hops. > > > > >be used when MPLS is ubiquitous at least on links between LSR > > >peers - in any other case, another tunneling mechanism may be > > >used, or packets must be sent using IP routing. > > > > Ahh, and that was exactly what drove my original question. > If MPLS is not > > ubiquitous between the LSRs that are adjacent at the higher > level, then the > > higher level LSP is broken. And my question/complaint is > (since 2547bis > > calls for the capability to use LDP to distribute the outer > label) that the > > use of LDP does not provide knowledge of whether there is > MPLS connectivity > > between the LSRs that are to be adjacent at the higher level. > > > > > > > >-- > > >Eric Gray > > > > > >You wrote: > > > > > >> Thank you for the responses several of you have sent on > this question. > > >> After reading your comments, and rereading the various > RFCs and I-D's, I > > >> have arrived at a more fundamental issue. > > >> > > >> I had been under the mistaken impression that an LSP set > up using LDP and > > >> bound to a Host Address type FEC would fail to be > established if it did not > > >> reach all the way to the specified host (LSR). I now > understand that these > > >> behave just like LSPs bound to an Address Prefix type > FEC, which is to say > > >> that the ingress LSR does not have knowledge of how far > the LSP extends. > > >> > > >> This type of behavior seems problematic to me when using > LSPs set up by LDP > > >> as tunnels in which to stack higher level LSPs. Since > the labels of the > > >> higher level LSPs are meaningless except at the LSRs > that distributed them, > > >> if the outer LSPs happen not to reach to the next hop of > the inner LSPs > > >> there will not be connectivity of the inner LSP. > > >> > > >> One could try to prevent this problem would from arising > by making sure > > >> that MPLS is deployed throughout the entire network > connecting the end > > >> points of the higher level LSPs (e.g. PE devices > providing VPN services) > > >> but that does not strike me as providing a robust and > high confidence > > >> solution. Using TE tunnels set up by RSVP-TE or CR-LDP > would avoid the > > >> problem, but that seems to present a different problem > of ensuring that all > > >> the required PE-PE tunnels are always present (as > previously discussed on > > >> this list). > > >> > > >> -Mark > > > > From owner-mpls@UU.NET Tue Apr 10 03:40:06 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09304 for ; Tue, 10 Apr 2001 03:40:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkcs10821; Tue, 10 Apr 2001 07:37:57 GMT Received: by mail-control.mail.uu.net id QQkkcs09500 for mpls-outgoing; Tue, 10 Apr 2001 07:37:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkcs09495 for ; Tue, 10 Apr 2001 07:37:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkcs28956 for ; Tue, 10 Apr 2001 07:36:36 GMT Received: from gorilla.mchh.siemens.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQkkcs14258 for ; Tue, 10 Apr 2001 07:36:35 GMT Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA05198; Tue, 10 Apr 2001 09:36:25 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA26025; Tue, 10 Apr 2001 09:36:22 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id <2TAH9KYZ>; Tue, 10 Apr 2001 09:36:24 +0200 Message-ID: From: Heiles Juergen To: "'Paul Bonenfant'" , Heiles Juergen Cc: "'curtis@avici.com'" , "Lazer, Monica A, NNAD" , "'neil.2.harrison@bt.com'" , raszuk@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org, "t1x1.5" Subject: RE: restoration time requirement (was Re: Last Call on RSVP Labe lAllocation for Backup Tunnels) Date: Tue, 10 Apr 2001 09:36:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Curtis, Paul, my original comment was based on the assumption that Curtis was talking about dropping a SDH/SONET connection as in the PSTN. If a connection is dropped in the PSTN you have to redial in order to establish the connection again. This is not the case for SONET/SDH networks with provisioned connections. I agree that the defect detction times are an issue for stacked proection/restoration. That is why I used the term "reaction time" and not "switching time". Regards Juergen > -----Original Message----- > From: Paul Bonenfant [SMTP:pbonenfant@photuris.com] > Sent: Monday, April 09, 2001 4:00 PM > To: Heiles Juergen > Cc: 'curtis@avici.com'; Lazer, Monica A, NNAD; 'neil.2.harrison@bt.com'; raszuk@cisco.com; mpls@UU.NET; ccamp@ops.ietf.org; t1x1.5 > Subject: Re: restoration time requirement (was Re: Last Call on RSVP LabelAllocation for Backup Tunnels) > > Jeurgen, > > Can't resist (apologies to all for the long message)... > > You wrote: > > > > Stacked protection/restoration: > > If you use protection/restoration at an optical network layer > > (server) and a SONET/SDH network layer (client) the server layer > > switching times should be faster than the client layer reaction > > times, so that the server layer does the protection/restoration > > and the client layer doesn't react. > > > > But as you no doubt well know, by far all the installed legacy > SONET/SDH kit (that the unfortunate carriers are yearning to get > rid of, and which will disappear over time...sorry, I digress...) > detects: > - LOS/LOF on the order of 2.3-100 microseconds (LOS for SONET, > thanks to Bellcore/Telcordia GR-253, unless it's been revised), > or > - 375 microseconds (LOF for SDH -- Maarten please correct me if > I'm wrong, I know you're out there). > > So for the server (optical) layer switching time to be faster > than the client (SONET/SDH) layer reaction time, the optical > layer would have to restore well within, say, 1 millisecond. > > And, in this context, "switching time" may include (depending > upon the particular flavour of optical layer protection/restoration > implemented): detection-time + signaling-time (for 1+1 bidirectional > or shared protection, or restoration) + bridging&switching-time. > To do all that in less than 1 msec is a tall order for any layer. > > Maybe I'm beating a long dead horse here, but this now aging > issue of "optical layer restoration occurring faster than the > SONET/SDH reaction time" keeps cropping up...for a shameless plug > thinly veiled as bit of history, see: > - J. Manchester and P. Bonenfant, "Fiber Optic Network Survivability: > SONET/Optical Protection Layer Interworking," Proc. of NFOEC'96, > Denver, CO, 1996. > (If interested, reply off-list to find out how to get a copy. I know, > referenced material should be posted as either an IETF draft or T1X1 > contribution to make it more readily available, sorry.) > > Juergen, I agree that this is an issue of concern (albeit not new). > Potential solutions to the SONET/SDH-Optical protection layer inter- > working problem include: > - Do nothing (e.g., allow both the SONET/SDH & Optical & perhaps even > other layers to react to the failure...not an attractive approach > unless chaos is an option) > - Implement appropriate holdoff time(s) in one or more of the layers > (again not attractive as it delays restoration if the failure > actually occurs at that layer...also, the holdoff times get > progressively longer in the higher layers) > - Inter-layer signaling (see, for example, ANSI T1X1.5/97-080, > "Protected Domain Boundary Delineation," June 1997: > ftp://ftp.t1.org/pub/t1x1/x15.97/7x150800.pdf > -- an elegant solution, but never gained any traction thanks to > the mess associated with inter-layer signaling) > - Avoid direct overlay of survivability schemes with similar > restoration time-scales (tends to be what is done in practice)> > - Coordinate protection layer interworking via a common control plane > across all the network layers (e.g., GMPLS?), as discussed briefly > (for example) in Sec 3.2.3 of: > http://www.ietf.org/internet-drafts/draft-ghani-optical-rings-01.txt > (again for the reference-minded the above discussion can be found in > "Optical Layer Protection and Restoration," OFC'2001 Short Course > SC113/153, Mar. 2001, or "Tutorial on Optical Layer Protection and > Restoration," Proc. of OFC'1999, Paper FF-1, Feb. 1999). > > > As for the appropriate restoration time requirement...for what it's > worth, 50 msec, insofar as it remains an historical artifact, also > continues to be the "psychological" bar that optical netwoking > protection & restoration schemes have to meet, if for no other > reason than the following, prevailing view -- "the new & improved > (optical networking) technology should provide at least as good, > if not better, performance than what preceded it (SONET/SDH)." > > Psychological bars notwithstanding, what then is the appropriate > restoration time requirement? I for one would be interested in > hearing from (even more) carriers regarding which latency-sensitive > applications actually drive the 50msec-range protection/restoration > requirements (my guess: it's not (only) voice). > > Regards, > > Paul > > Heiles Juergen wrote: > > > > Curtis > > > > >Then again, this is second hand, so I could be completely wrong. This is not a measurement I've made myself and the SONET equipment is not something I'm familiar with .... > > > > you are completely wrong and I suggest you better make measurments and get familiar with SONET before making such statements.. SONET/SDH equipment will not shut down/drop connections. Today SONET connections are permanent connections setup via the management system. An automatic drop of a conneciton as it is the case for switched connections will not occur. What you will see is the insertion of AIS (alarm indication signal) after the detection of an defect. But as soon as the defect is gone the AIS is removed and the connection is running again. AIS is nothing harmful as due to the defect the connection is interupted in any case. Furthermore the AIS avoids downstream alarms (alarm storms). > > > > What could be of concern are the following points. I talk about a server layer for a SONET/SDH network (e.g. an Optical Network) providing protection/restoration: > > > > Stacked protection/restoration: > > If you use protection/restoration at an optical network layer (server) and a SONET/SDH network layer (client) the server layer switching times should be faster than the client layer reaction times, so that the server layer does the protection/restoration and the client layer doesn't react. > > > > Automatic power reduction/automatic laser shutdown APR/ALS > > APR is used for safety reasons in order to avoid harmful emission of laser light in case of a fiber cut. One implementation switches off the transmit laser in case of loss of signal at the receiver. A restart action which is triggered automatically in intervals of several seconds is required in order to test if the link is repaired. Normally the APR function can be switched off if not needed. The APR function needs some careful consideration in case of protection/restoration and automatic connection setup in all optical networks. > > > > Regards > > > > Juergen > > > > > -----Original Message----- > > > From: Curtis Villamizar [SMTP:curtis@workhorse.fictitious.org] > > > Sent: Monday, April 09, 2001 4:37 AM > > > To: Lazer, Monica A, NNAD > > > Cc: 'neil.2.harrison@bt.com'; raszuk@cisco.com; mpls@UU.NET; ccamp@ops.ietf.org > > > Subject: restoration time requirement (was Re: Last Call on RSVP Label Allocation for Backup Tunnels) > > > > > > > > > In message <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com>, "L> > > > azer, Monica A, NNAD" w> rites: > > > > Voice switches will drop the connections after 2.5 seconds. A large number > > > > of dropped calls will cause FCC reportable events, which is something that > > > > US carriers need to avoid. So restoration within this time frame is needed > > > > for support of trunks carrying voice traffic. > > > > > > > > Monica A. Lazer > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > 908 234 8462 > > > > mlazer@att.com > > > > > > > > > Monica, > > > > > > We're off topic, so I changed the subject. > > > > > > Thanks for providing the 2.5 second figure. > > > > > > I've heard carrier transport people grumble about SONET equipment > > > they'd be please to get rid of that will shut down even when used as > > > linear SONET with no protect path and as a result would require > > > <100msec restoration. Since there is enough of this SONET gear, the > > > carriers can't really get rid of it although it will probably > > > disappear over time and so they will make fast restoration a > > > requirement of people they buy from. To be safe, the request for > > > <50msec has been made. > > > > > > If you are not blessed with such equipment or you are able to work > > > around it when doing VoIP, then you are among the fortunate. > > > > > > Then again, this is second hand, so I could be completely wrong. This > > > is not a measurement I've made myself and the SONET equipment is not > > > something I'm familiar with such that I could say with confidence that > > > it could not be configured to hold on longer or to not shut down at> > > > all if there was no protect. > > > > > > OTOH there are those who (claim to) want to configure SONET on some > > > links but not on others and don't want a fast restoration. They want > > > to be assured that restoration will occur only after it is safe to > > > assume that SONET restoration is not available. > > > > > > Curtis From owner-mpls@UU.NET Tue Apr 10 03:46:33 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09386 for ; Tue, 10 Apr 2001 03:46:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkcs25559; Tue, 10 Apr 2001 07:44:49 GMT Received: by mail-control.mail.uu.net id QQkkcs09843 for mpls-outgoing; Tue, 10 Apr 2001 07:44:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkcs09830 for ; Tue, 10 Apr 2001 07:44:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkcs15106 for ; Tue, 10 Apr 2001 07:43:55 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkcs24313 for ; Tue, 10 Apr 2001 07:43:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA20134 for mpls@uu.net; Tue, 10 Apr 2001 03:43:54 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkcs09547 for ; Tue, 10 Apr 2001 07:39:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkcs03729 for ; Tue, 10 Apr 2001 07:39:16 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkkcs18075 for ; Tue, 10 Apr 2001 07:39:16 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA06413 for ; Tue, 10 Apr 2001 03:39:15 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA06409 for ; Tue, 10 Apr 2001 03:39:15 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA12618; Tue, 10 Apr 2001 09:38:59 +0200 (MET DST) Cc: mpls@UU.NET, ccamp@ops.ietf.org, "t1x1.5" Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA12590; Tue, 10 Apr 2001 09:38:46 +0200 (MET DST) Message-ID: <3AD2B883.8C2DB3FA@lucent.com> Date: Tue, 10 Apr 2001 09:38:43 +0200 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sambasiva mantha Original-CC: mpls@UU.NET, ccamp@ops.ietf.org, "t1x1.5" Subject: Re: restoration time requirement (was Re: Last Call on RSVP LabelAllocation for Backup Tunnels) References: <3AD1C050.629F38BC@photuris.com> <3AD1C788.91113189@lucent.com> <3AD1D62D.A154AF14@usa.alcatel.com> Content-Type: multipart/mixed; boundary="------------CEE6CC99127E9C87B3DFC78E" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------CEE6CC99127E9C87B3DFC78E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sambu, Ever tried to detect an "all-zeroes pattern"? It's never present after a receiver circuit. If you cut/remove a fiber the receiver circuit enters maximum amplification and produces noice. The clock & data recovery circuit behind it interpretes this noise as a random pattern of "0"s and "1"s. Depending on the clock recovery technique, the recovered clock frequency might be as low as a few hundred kHz (SAW filter based clock recovery). Therefore alternative means are typically deployed to detect loss of signal; e.g. power level monitoring, loss of lock monitoring, loss of clock monitoring, ... = Power level monitoring may have a negative side effect; i.e. it may declare a LOS condition while there is still a valid input signal. As the STM-N signal is framed, and framing is required in every SDH equipment interface, loss of frame (LOF) can be used as deterministic defect indicator for protection switching and alarm suppression (AIS insertion). LOS isn't adding any real advantage; its most important contribution is to the fault localisation (LOS: cable break or transmitter fail). As such, there is no real requirement for microsecond LOS defect detection in SDH. --------- G.783 (10/2000) ------ 6.2.1.1 Loss Of Signal defect (dLOS) STM-N optical interfaces: This parameter should take on the value "incoming signal absent" when the incoming power level at the receiver has dropped to a level which corresponds to a high error condition. The purpose of monitoring this parameter is to indicate either: i) transmitter failure; ii) optical path break. NOTE - This is a functional specification referring only to the quality of the incoming signal. It does not necessarily imply either the measurement of optical power or BER. The timing requirements for detection of the LOS defect in the province of regional standards. One example is the following: An LOS defect occurs upon detection of no transitions on the incoming signal (before descrambling) for time T, where 2.3 <=3D T <=3D 100 us. The LOS defect is terminated after a time period equal to the greater of 125 ms or 2.5 T' containing no transition-free intervals of length T', where 2.3 <=3D T' <=3D 100 us. ---------------------------------- Regards, Maarten sambasiva mantha wrote: > = > The following is the requirement for LOS on SONET as in GR-253-CORE, Is= sue 3. > = > R6-54 [416v2] A SONET NE shall monitor all incoming SONET signals > (before descrambling) for an =93all-zeros patterns,=94 where an all= -zeros > pattern corresponds to no light pulses for OC-N optical interfaces > and no voltage transitions for STS-1 and STS-3 electrical interface= s. > An LOS defect shall be detected when an all-zeros pattern on the > incoming SONET signal lasts 100 =B5s or longer. If an all-zeros pat= tern > lasts 2.3 =B5s or less, an LOS defect shall not be detected. > = > The treatment of all-zeros patterns lasting between 2.3 =B5s and 100 =B5= s for the > purpose of LOS defect detection is not specified and is therefore left = to the choice > of the equipment designer. For testing conformance to the LOS detection= > requirement, it is sufficient to apply an all-zeros pattern lasting at = most 2.3 =B5s, and > to apply an all-zeros pattern lasting at least 100 =B5s. > = > Sambu > = > Maarten Vissers wrote: > = > > Paul, > > > > "I am out there"... STM-LOS defect detection time in SDH isn't > > specified. May take as long as e.g. 50 ms to detect the LOS defect. T= his > > isn't important as you already indicate; LOF will do the job to trigg= er > > protection switching. STM-LOF defect detection time is 3.625 ms (5 > > frames for OOF plus 24 frames for LOF). > > > > For the case of cable break, STM-LOF will not be reported, while STM-= LOS > > will be detected before the 2.5+/-0.5 seconds defect-to-failure > > integration timer expires. > > > > Regards, > > > > Maarten > > > > Paul Bonenfant wrote: > > > > > > Jeurgen, > > > > > > Can't resist (apologies to all for the long message)... > > > > > > You wrote: > > > > > > > > Stacked protection/restoration: > > > > If you use protection/restoration at an optical network layer > > > > (server) and a SONET/SDH network layer (client) the server layer > > > > switching times should be faster than the client layer reaction > > > > times, so that the server layer does the protection/restoration > > > > and the client layer doesn't react. > > > > > > > > > > But as you no doubt well know, by far all the installed legacy > > > SONET/SDH kit (that the unfortunate carriers are yearning to get > > > rid of, and which will disappear over time...sorry, I digress...) > > > detects: > > > - LOS/LOF on the order of 2.3-100 microseconds (LOS for SONET, > > > thanks to Bellcore/Telcordia GR-253, unless it's been revised), > > > or > > > - 375 microseconds (LOF for SDH -- Maarten please correct me if > > > I'm wrong, I know you're out there). > > > > > > So for the server (optical) layer switching time to be faster > > > than the client (SONET/SDH) layer reaction time, the optical > > > layer would have to restore well within, say, 1 millisecond. > > > > > > And, in this context, "switching time" may include (depending > > > upon the particular flavour of optical layer protection/restoration= > > > implemented): detection-time + signaling-time (for 1+1 bidirectiona= l > > > or shared protection, or restoration) + bridging&switching-time. > > > To do all that in less than 1 msec is a tall order for any layer. > > > > > > Maybe I'm beating a long dead horse here, but this now aging > > > issue of "optical layer restoration occurring faster than the > > > SONET/SDH reaction time" keeps cropping up...for a shameless plug > > > thinly veiled as bit of history, see: > > > - J. Manchester and P. Bonenfant, "Fiber Optic Network Survivabilit= y: > > > SONET/Optical Protection Layer Interworking," Proc. of NFOEC'96, > > > Denver, CO, 1996. > > > (If interested, reply off-list to find out how to get a copy. I kno= w, > > > referenced material should be posted as either an IETF draft or T1X= 1 > > > contribution to make it more readily available, sorry.) > > > > > > Juergen, I agree that this is an issue of concern (albeit not new).= > > > Potential solutions to the SONET/SDH-Optical protection layer inter= - > > > working problem include: > > > - Do nothing (e.g., allow both the SONET/SDH & Optical & perhaps ev= en > > > other layers to react to the failure...not an attractive approach= > > > unless chaos is an option) > > > - Implement appropriate holdoff time(s) in one or more of the layer= s > > > (again not attractive as it delays restoration if the failure > > > actually occurs at that layer...also, the holdoff times get > > > progressively longer in the higher layers) > > > - Inter-layer signaling (see, for example, ANSI T1X1.5/97-080, > > > "Protected Domain Boundary Delineation," June 1997: > > > ftp://ftp.t1.org/pub/t1x1/x15.97/7x150800.pdf > > > -- an elegant solution, but never gained any traction thanks to > > > the mess associated with inter-layer signaling) > > > - Avoid direct overlay of survivability schemes with similar > > > restoration time-scales (tends to be what is done in practice) > > > - Coordinate protection layer interworking via a common control pla= ne > > > across all the network layers (e.g., GMPLS?), as discussed briefl= y > > > (for example) in Sec 3.2.3 of: > > > http://www.ietf.org/internet-drafts/draft-ghani-optical-rings-01.= txt > > > (again for the reference-minded the above discussion can be found i= n > > > "Optical Layer Protection and Restoration," OFC'2001 Short Course > > > SC113/153, Mar. 2001, or "Tutorial on Optical Layer Protection and > > > Restoration," Proc. of OFC'1999, Paper FF-1, Feb. 1999). > > > > > > > > > As for the appropriate restoration time requirement...for what it's= > > > worth, 50 msec, insofar as it remains an historical artifact, also > > > continues to be the "psychological" bar that optical netwoking > > > protection & restoration schemes have to meet, if for no other > > > reason than the following, prevailing view -- "the new & improved > > > (optical networking) technology should provide at least as good, > > > if not better, performance than what preceded it (SONET/SDH)." > > > > > > Psychological bars notwithstanding, what then is the appropriate > > > restoration time requirement? I for one would be interested in > > > hearing from (even more) carriers regarding which latency-sensitive= > > > applications actually drive the 50msec-range protection/restoration= > > > requirements (my guess: it's not (only) voice). > > > > > > Regards, > > > > > > Paul > > > > > > Heiles Juergen wrote: > > > > > > > > Curtis > > > > > > > > >Then again, this is second hand, so I could be completel= y wrong. This is not a measurement I've made myself and the SONET equipme= nt is not something I'm familiar with .... > > > > > > > > you are completely wrong and I suggest you better make measurment= s and get familiar with SONET before making such statements.. SONET/SDH e= quipment will not shut down/drop connections. Today SONET connections are= permanent connections setup via the management system. An automatic drop= of a conneciton as it is the case for switched connections will not occu= r. What you will see is the insertion of AIS (alarm indication signal) af= ter the detection of an defect. But as soon as the defect is gone the AIS= is removed and the connection is running again. AIS is nothing harmful a= s due to the defect the connection is interupted in any case. Furthermore= the AIS avoids downstream alarms (alarm storms). > > > > > > > > What could be of concern are the following points. I talk about a= server layer for a SONET/SDH network (e.g. an Optical Network) providin= g protection/restoration: > > > > > > > > Stacked protection/restoration: > > > > If you use protection/restoration at an optical network layer (se= rver) and a SONET/SDH network layer (client) the server layer switching t= imes should be faster than the client layer reaction times, so that the s= erver layer does the protection/restoration and the client layer doesn't = react. > > > > > > > > Automatic power reduction/automatic laser shutdown APR/ALS > > > > APR is used for safety reasons in order to avoid harmful emission= of laser light in case of a fiber cut. One implementation switches off t= he transmit laser in case of loss of signal at the receiver. A restart ac= tion which is triggered automatically in intervals of several seconds is = required in order to test if the link is repaired. Normally the APR funct= ion can be switched off if not needed. The APR function needs some carefu= l consideration in case of protection/restoration and automatic connectio= n setup in all optical networks. > > > > > > > > Regards > > > > > > > > Juergen > > > > > > > > > -----Original Message----- > > > > > From: Curtis Villamizar [SMTP:curtis@workhorse.fictitious.org] > > > > > Sent: Monday, April 09, 2001 4:37 AM > > > > > To: Lazer, Monica A, NNAD > > > > > Cc: 'neil.2.harrison@bt.com'; raszuk@cisco.com; mpls@UU.NET; = ccamp@ops.ietf.org > > > > > Subject: restoration time requirement (was Re: Last Call o= n RSVP Label Allocation for Backup Tunnels) > > > > > > > > > > > > > > > In message <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04= =2Ebm.att.com>, "L > > > > > azer, Monica A, NNAD" writes: > > > > > > Voice switches will drop the connections after 2.5 seconds. A= large number > > > > > > of dropped calls will cause FCC reportable events, which is s= omething that > > > > > > US carriers need to avoid. So restoration within this time fr= ame is needed > > > > > > for support of trunks carrying voice traffic. > > > > > > > > > > > > Monica A. Lazer > > > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > > > > > 908 234 8462 > > > > > > mlazer@att.com > > > > > > > > > > > > > > > Monica, > > > > > > > > > > We're off topic, so I changed the subject. > > > > > > > > > > Thanks for providing the 2.5 second figure. > > > > > > > > > > I've heard carrier transport people grumble about SONET equipme= nt > > > > > they'd be please to get rid of that will shut down even when us= ed as > > > > > linear SONET with no protect path and as a result would require= > > > > > <100msec restoration. Since there is enough of this SONET gear= , the > > > > > carriers can't really get rid of it although it will probably > > > > > disappear over time and so they will make fast restoration a > > > > > requirement of people they buy from. To be safe, the request f= or > > > > > <50msec has been made. > > > > > > > > > > If you are not blessed with such equipment or you are able to w= ork > > > > > around it when doing VoIP, then you are among the fortunate. > > > > > > > > > > Then again, this is second hand, so I could be completely wrong= =2E This > > > > > is not a measurement I've made myself and the SONET equipment i= s not > > > > > something I'm familiar with such that I could say with confiden= ce that > > > > > it could not be configured to hold on longer or to not shut dow= n at> > > > > > all if there was no protect. > > > > > > > > > > OTOH there are those who (claim to) want to configure SONET on = some > > > > > links but not on others and don't want a fast restoration. The= y want > > > > > to be assured that restoration will occur only after it is safe= to > > > > > assume that SONET restoration is not available. > > > > > > > > > > Curtis --------------CEE6CC99127E9C87B3DFC78E Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------CEE6CC99127E9C87B3DFC78E-- From owner-mpls@UU.NET Tue Apr 10 07:11:01 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11325 for ; Tue, 10 Apr 2001 07:11:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkdg07669; Tue, 10 Apr 2001 11:09:08 GMT Received: by mail-control.mail.uu.net id QQkkdg00883 for mpls-outgoing; Tue, 10 Apr 2001 11:08:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkdg00862 for ; Tue, 10 Apr 2001 11:08:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkdg05580 for ; Tue, 10 Apr 2001 11:07:16 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkdg05621 for ; Tue, 10 Apr 2001 11:07:16 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA27607 for mpls@uu.net; Tue, 10 Apr 2001 07:07:15 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkdg00715 for ; Tue, 10 Apr 2001 11:06:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkdg08399 for ; Tue, 10 Apr 2001 11:05:57 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkkdg00891 for ; Tue, 10 Apr 2001 11:05:57 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11166; Tue, 10 Apr 2001 07:05:56 -0400 (EDT) Message-Id: <200104101105.HAA11166@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-tunnel-applicability-02.txt Date: Tue, 10 Apr 2001 07:05:55 -0400 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 : Applicability Statement for Extensions to RSVP for LSP-Tunnels Author(s) : D. Awduche, A. Hannan, X. Xiao Filename : draft-ietf-mpls-rsvp-tunnel-applicability-02.txt Pages : 8 Date : 09-Apr-01 This memo discusses the applicability of 'Extensions to RSVP for LSP Tunnels' [1]. It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of 'Extensions to RSVP for LSP Tunnels' onto the Internet standards track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-tunnel-applicability-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-rsvp-tunnel-applicability-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-rsvp-tunnel-applicability-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: <20010409145232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-tunnel-applicability-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-tunnel-applicability-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010409145232.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Apr 10 08:31:25 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13004 for ; Tue, 10 Apr 2001 08:31:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkdl25104; Tue, 10 Apr 2001 12:29:22 GMT Received: by mail-control.mail.uu.net id QQkkdl23478 for mpls-outgoing; Tue, 10 Apr 2001 12:28:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkdl23464 for ; Tue, 10 Apr 2001 12:28:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkdl11931 for ; Tue, 10 Apr 2001 12:25:52 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkkdl21486 for ; Tue, 10 Apr 2001 12:25:51 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 FAA17147; Tue, 10 Apr 2001 05:26:15 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id IAA04542; Tue, 10 Apr 2001 08:25:49 -0400 (EDT) Message-Id: <200104101225.IAA04542@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Mark Duffy cc: curtis@avici.com, "Herbst, Bill" , mpls@UU.NET Subject: Re: Use of LDP for VPNs In-reply-to: Your message of Mon, 09 Apr 2001 18:51:17 -0400. <3.0.5.32.20010409185117.008cae70@10.1.1.249> 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: Tue, 10 Apr 2001 08:25:49 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Mark> RFC 3036 sect. 2.1 gives rules for what packets may be sent on these Mark> LSPs, depending what FEC elements are associated with the LSPs. If you don't bother to implement the Host Address FEC, you don't have to worry about the precise interpretation of these rules. There is no reason why anybody should implement the Host Address FEC. Mark> (I supposed you [Curtis] will tell me that the whole use of LDP for Mark> topology driven set up should be freely ignored :-) and I would not Mark> necessarily disagree with you.) Just don't expect to interoperate with others, unless you are using MPLS only for traffic engineering. Mark> If MPLS is not ubiquitous between the LSRs that are adjacent at the Mark> higher level, then the higher level LSP is broken. Of all the ways in which connectivity might be broken, forgetting to turn MPLS on is pretty low on the list. From owner-mpls@UU.NET Tue Apr 10 09:20:40 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14208 for ; Tue, 10 Apr 2001 09:20:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkdp17190; Tue, 10 Apr 2001 13:18:53 GMT Received: by mail-control.mail.uu.net id QQkkdp15177 for mpls-outgoing; Tue, 10 Apr 2001 13:18:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkdp15171 for ; Tue, 10 Apr 2001 13:18:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkdp29507 for ; Tue, 10 Apr 2001 13:17:07 GMT Received: from samar.sasi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQkkdp18173 for ; Tue, 10 Apr 2001 13:17:01 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id SAA04151 for ; Tue, 10 Apr 2001 18:46:43 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Tue, 10 Apr 2001 18:46:38 +0000 (IST) Received: from localhost (soumen@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id RAA00876 for ; Tue, 10 Apr 2001 17:37:47 +0530 (IST) Date: Tue, 10 Apr 2001 17:37:47 +0530 (IST) From: Soumen Sarkar To: Subject: MPLS uncharted territory In-Reply-To: <20010409110424.15588.cpmta@c001.zsm.cp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I need small favour from the experts in this list. I am sure representatives of almost all the vendors are present here. I am looking for inputs on what the vendors are finding lacking in present MPLS framework. I agree this varies from vendor to vendor, but I guess we can expect a pattern on the features most sought. Possibly we might be able to identify the uncharted territories of MPLS which are important but somehow not addressed so far in MPLS forum. I will be grateful to all of you if you can find some time to complete this exercise by this week. -best regards, Soumen From owner-mpls@UU.NET Tue Apr 10 11:10:17 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17575 for ; Tue, 10 Apr 2001 11:10:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkdw20904; Tue, 10 Apr 2001 15:08:15 GMT Received: by mail-control.mail.uu.net id QQkkdw26407 for mpls-outgoing; Tue, 10 Apr 2001 15:07:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkdw26389 for ; Tue, 10 Apr 2001 15:07:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkdw18385 for ; Tue, 10 Apr 2001 15:06:50 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkkdw27626 for ; Tue, 10 Apr 2001 15:06:49 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 IAA08591 for ; Tue, 10 Apr 2001 08:07:13 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA04945 for mpls@uu.net; Tue, 10 Apr 2001 11:06:44 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkdt06307 for ; Tue, 10 Apr 2001 14:19:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkdt13547 for ; Tue, 10 Apr 2001 14:17:53 GMT Received: from thalia.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11]) id QQkkdt21210 for ; Tue, 10 Apr 2001 14:17:52 GMT Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id OAA22209 for ; Tue, 10 Apr 2001 14:17:52 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 10 Apr 2001 14:17:51 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2TSJQSRZ>; Tue, 10 Apr 2001 07:17:50 -0700 Message-ID: <10C8636AE359D4119118009027AE9987EBF22F@FMSMSX34> From: "Dua, Vivek" To: "'mpls@uu.net'" Cc: "Talla, Ramanjaneyulu" , "Dua, Vivek" Subject: Query regarding LSP Date: Tue, 10 Apr 2001 07:17:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi!, I have a query regarding MPLS LSPs: Consider a Scenario: | | In1 --------------- -----|----------- ----------------- In0 | | L1 | | L2 | | Out0 ->-- | LERA |------>------- | LSR |-------->----| LERB |---->---- | | | | | | -------------- ----------------- ----------------- If a LSP is configured between LERA and LERB with LERA as the ingress router and LERB as egress router for a particular FEC, from Ino to Out0. L1 is the incoming label for that FEC to LSR and L2 is the incoming label to LERB. Now consider a case that a IP packet arrives at interface In1 with the Destination IP address belonging to the above FEC, then the question is: SHOULD LSR PUSH label 'L2' to the IP Packet and forward it to the LERB ??? Thanks Vivek -------------------------------------------------------------- Vivek Dua Intel , Bangalore 5th Floor, Prestige Meridian I 29, M.G.Road,Bangalore-560 001 INDIA Phone: (+91)-(80)-5550888 Fax: (+91)-(80)-5550718 ------------------------------------------------------------ From owner-mpls@UU.NET Tue Apr 10 11:27:23 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18251 for ; Tue, 10 Apr 2001 11:27:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkdx17603; Tue, 10 Apr 2001 15:25:34 GMT Received: by mail-control.mail.uu.net id QQkkdx28439 for mpls-outgoing; Tue, 10 Apr 2001 15:25:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkdx28423 for ; Tue, 10 Apr 2001 15:25:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkdx17617 for ; Tue, 10 Apr 2001 15:23:16 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkdx20426 for ; Tue, 10 Apr 2001 15:23:11 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA15137 for mpls@uu.net; Tue, 10 Apr 2001 11:23:11 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkdx28146 for ; Tue, 10 Apr 2001 15:18:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkdx14841 for ; Tue, 10 Apr 2001 15:18:07 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQkkdx13377 for ; Tue, 10 Apr 2001 15:18:06 GMT Received: (qmail 23734 invoked by uid 104); 10 Apr 2001 15:18:05 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.603101 secs); 10/04/2001 08:18:05 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 10 Apr 2001 15:18:04 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f3AFI9Z00816; Tue, 10 Apr 2001 08:18:09 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id <2NK1CGLJ>; Tue, 10 Apr 2001 08:19:02 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BAC@BBY1EXM01> From: Shahram Davari To: "'Jayaram Beladakere'" , "'mpls@uu.net'" Cc: "'Diffserv@itef.org'" Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs Date: Tue, 10 Apr 2001 08:19:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I think what you are asking is not an MPLS-Diffserv question, rather it is a Diffserv specific question. Because it is equally applicable to DSCP<=>PHB mapping. So I suggest that you ask this from the Diffserv WG and then the answer will be equally applicable to MPLS-Diffserv. But here is my own opinion: If multiple DSCP/EXP map to the same PHB, the choice of outgoing DSCP/EXP is a local policy matter and does not need standardization. It all depends on the reasons for having multiple DSCP/EXP mappings to the same PHB. Is it because they refer to multiple instances of the same PHB or is it just for reducing the configuration time. In the former case the choice may depend on specific QoS requirements such as delay requirements, while in the latter case probably it should make no difference which DSCP/EXP is used for a particular outgoing PHB, the choice could be as simple as "the one that involves less packet processing operation", which may translate to: if the outgoing PHB is going to be the same as the incoming PHB, then it probably makes sense to use the same DSCP/EXP as the incoming packet. Yours, -Shahram > -----Original Message----- > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > Sent: Monday, April 09, 2001 9:36 PM > To: Shahram Davari; 'mpls@uu.net' > Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs > > > The question, as I asked previously, may not have been > completely clear. I > will attempt to elaborate. > > I understand that many-to-one mapping of many EXP field > values to one PHB is > possible with the preconfigured EXP<-->PHB mapping. The > following are two > examples. i) When the preconfigured EXP<-->PHB mapping has > not actually > been configured by the Network Administrator, the LSR uses a default > preconfigured EXP<-->PHB mapping which maps all EXP values to > the Default > PHB. ii) A network administrator may map 000, 001 and 010 to > Default PHB > and 110 and 111 to EF PHB. > > Consider an E-LSP that is tunneled in another E-LSP using the > PIPE MODEL. > Assume that neither LSP is specified with a Diffserv Context, > so that both > use the preconfigured EXP<-->PHB mapping. While the incoming PHB > determination is clear (section 3.3 of draft 0.8), what is > not clear is the > encoding of outgoing EXP field (section 3.4.1). > Specifically, I have the > following question: > > With many-to-one mapping of EXP-to-PHB in the preconfigured EXP<-->PHB > mapping, how shall the outgoing EXP be encoded for a PHB? > There are many > EXP field values that each correspond to the same PHB. > > I am not sure that using the same value as incoming EXP field is the > intention with Pipe model. Is it mandatory to specify a > Diffserv Context > for the tunnel LSP (that maps a PHB to only one outgoing EXP > field value)? > > Jayaram > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, April 09, 2001 11:53 AM > To: 'Jayaram Beladakere'; 'mpls@uu.net' > Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs > > > Hi, > > Since this is very similar to what I quoted from RFC-2474, my > understanding > is that the outgoing EXP should be the same as the incoming > EXP. Because > from this node's point of view all EXPs mean DF-PHB, so > leaving the EXP > field unchanged still means DF-PHB to this node. Additionally > leaving the > EXP field unchanged causes the downstream nodes that have > their EXP<=>PHB > configured, to treat the packet properly (prevents malfunction). > > Yours, > -Shahram > > > -----Original Message----- > > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > > Sent: Saturday, April 07, 2001 3:35 PM > > To: Shahram Davari; 'mpls@uu.net' > > Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs > > > > > > Shahram, Thanks for this clarification. I have a follow-up > > question on this > > topic. > > > > Suppose that the preconfigured EXP<-->PHB table has not been > > configured by > > the network administrator; thus, all EXP values map to the > > Default PHB. If > > an E-LSP tunnel is now set up with no Diffserv Context, how > > should the LSR > > encode the outgoing PHBs? Obviously, the E-LSP tunnel would > > only support > > Default PHB. But, there are eight EXP field values that map > > to that PHB. > > Which value shall be used for outgoing EXP field? > > > > Otherwise, is it mandatory to specify a Diffserv Context > for an E-LSP > > tunnel? > > > > Regards, Jayaram > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, March 28, 2001 8:21 AM > > To: 'Jayaram Beladakere'; 'mpls@uu.net' > > Subject: RE: Preconfigured EXP<-->PHB mapping for E-LSPs > > > > > > Hi Jayaram, > > > > The intention of configured E-LSPs is to have the > > MPLS+Diffserv network > > behave the same as a Diffserv-only network. Since RFC-2474 > > section 3 says: > > > > " > > Packets received with an unrecognized codepoint SHOULD > be forwarded > > as if they were marked for the Default behavior (see Sec. 4), and > > their codepoints should not be changed. Such packets MUST > > NOT cause > > the network node to malfunction. " > > > > So the answer to you question is that the EXP should be left > > unchanged in > > the normal swap operation. > > > > It is however, possible to push another label and have either > > non-configured, configured or even signaled E-LSP for the new > > LSP (which we > > call tunnel-LSP). In that case depending on the type of the > > tunnel (Uniform > > or pipe), the top label could have its EXP set to the same > > EXP, or to the > > Default EXP or something else. > > > > In case the tunnel-LSP is a uniform tunnel that is a > > non-configured (and > > non-signaled) E-LSP, then the same behavior as explained in > > the above quote > > from RFC-2474 is the correct behavior (i.e., setting the EXP > > of the pushed > > label to the same EXP as the incoming label). > > > > Yours, > > -Shahram > > > > > -----Original Message----- > > > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > > > Sent: Tuesday, March 27, 2001 2:06 PM > > > To: 'mpls@uu.net' > > > Subject: Preconfigured EXP<-->PHB mapping for E-LSPs > > > > > > > > > The following is from "MPLS Support of Differentiated Services" > > > (draft-ietf-mpls-diff-ext-08.txt). > > > > > > 3.2.1 Preconfigured EXP<-->PHB mapping > > > .... > > > In case, the preconfigured EXP<-->PHB mapping has not > actually been > > > configured by the Network Administrator, the LSR should use a > > > default preconfigured EXP<-->PHB mapping which maps all EXP values > > > to the Default PHB. > > > > > > In the above case, the LSR provides Default PHB treatment to > > > all labeled > > > packets (belonging to LSPs with preconfigured EXP<-->PHB > > > mapping). What > > > shall be the value of the outgoing EXP field for such labeled > > > packets, both > > > with label-swap and label-push operations at the LSR? In > > > particular, shall > > > the outgoing EXP match incoming EXP, or shall it be '000'? > > Is there a > > > difference if the label operation is swap rather than push? > > > > > > Regards, > > > Jayaram Beladakere > > > Mahi Networks, Inc. > > > > > > From owner-mpls@UU.NET Tue Apr 10 11:45:48 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18904 for ; Tue, 10 Apr 2001 11:45:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkdy25805; Tue, 10 Apr 2001 15:43:51 GMT Received: by mail-control.mail.uu.net id QQkkdy29879 for mpls-outgoing; Tue, 10 Apr 2001 15:43:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkdy29874 for ; Tue, 10 Apr 2001 15:42:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkdy12552 for ; Tue, 10 Apr 2001 15:41:27 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkkdy22327 for ; Tue, 10 Apr 2001 15:41:25 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA07780; Tue, 10 Apr 2001 11:38:37 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104101538.LAA07780@workhorse.fictitious.org> To: andy.bd.reid@bt.com cc: curtis@avici.com, Juergen.Heiles@icn.siemens.de, mlazer@att.com, neil.2.harrison@bt.com, raszuk@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org Reply-To: curtis@avici.com Subject: Re: restoration time requirement (was Re: Last Call on RSVP Labe l Allocation for Backup Tunnels) In-reply-to: Your message of "Tue, 10 Apr 2001 11:51:50 BST." <5F54BE0116BCD2118C9400606DD614ED07BE78A5@mclmsent02.lon.bt.com> Date: Tue, 10 Apr 2001 11:38:37 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5F54BE0116BCD2118C9400606DD614ED07BE78A5@mclmsent02.lon.bt.com>, an dy.bd.reid@bt.com writes: > Curtis, > > I not sure I understand what point your trying to make - other that make > implicit critcism of the body of engineers who put together SONET/SDH > technology. I was not trying to implicit critcism of the body of engineers who put together SONET/SDH technology. There are two separate but similar issues. What level of restoration is imposed by existing L2 equipment on MPLS when providing L2 emulation over MPLS. What requirements does existing SONET equipment impose on a lower optical layer (potentially an issue for GMPLS). We can continue this offline if you like. Curtis From owner-mpls@UU.NET Tue Apr 10 12:43:09 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20348 for ; Tue, 10 Apr 2001 12:43:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkec07626; Tue, 10 Apr 2001 16:41:04 GMT Received: by mail-control.mail.uu.net id QQkkec21865 for mpls-outgoing; Tue, 10 Apr 2001 16:40:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkec21853 for ; Tue, 10 Apr 2001 16:40:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkec09511 for ; Tue, 10 Apr 2001 16:40:15 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkkec06204 for ; Tue, 10 Apr 2001 16:40:14 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24621 for ; Tue, 10 Apr 2001 12:40:12 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA08178 for ; Tue, 10 Apr 2001 12:40:13 -0400 (EDT) Message-ID: <3AD33790.7DDE9EA7@marconi.com> Date: Tue, 10 Apr 2001 12:40:48 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <200104090251.WAA00773@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > For most usage of MPLS, the notion of FEC is a broken one. In > RSVP/TE, there is no FEC signalled which is a good thing. Or you can think of RSVP/TE as supporting a restricted subset of LDP's definition of a FEC. Specifically, only accepting a single /32 prefix. Which is used as the tunnel endpoint address in the SESSION object. Just like an LDP-signaled /32 FEC, an RSVP-TE-signaled LSP may carry all traffic that passes through the endpoint address. -- David From owner-mpls@UU.NET Tue Apr 10 12:53:50 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20881 for ; Tue, 10 Apr 2001 12:53:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkked27732; Tue, 10 Apr 2001 16:51:55 GMT Received: by mail-control.mail.uu.net id QQkked22529 for mpls-outgoing; Tue, 10 Apr 2001 16:51:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkked22524 for ; Tue, 10 Apr 2001 16:51:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkked12293 for ; Tue, 10 Apr 2001 16:50:07 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkked22743 for ; Tue, 10 Apr 2001 16:50:06 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA24167 for mpls@uu.net; Tue, 10 Apr 2001 12:50:05 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkked22460 for ; Tue, 10 Apr 2001 16:49:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkked03656 for ; Tue, 10 Apr 2001 16:48:15 GMT Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQkked19631 for ; Tue, 10 Apr 2001 16:48:14 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21) id <2GWQR6FK>; Tue, 10 Apr 2001 12:43:24 -0400 Message-ID: <87009604743AD411B1F600508BA0F9598AD7ED@XOVER.dedham.mindspeed.com> From: "Kullberg, Alan" To: "'mpls@uu.net'" Subject: GMPLS LabelSet question Date: Tue, 10 Apr 2001 12:43:22 -0400 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 In draft-ietf-mpls-generalized-rsvp-te-01.txt, within the section describing the Label Set object, the Label Type field is described as follows: Label Type: 8 bits Indicates the type and format of the labels carried in the object. Values match the C-Type of the appropriate Label object. It seems that the only valid value for this field is 2 as defined by the Generalized Label in section 2.2. What is the point of this field since G-MPLS will ALWAYS use the Generalized Label? Was the intention to allow a label object with C-Type 1 to be signaled using G-MPLS? Also, when will the updated GMPLS drafts be submitted? Alan From owner-mpls@UU.NET Tue Apr 10 16:16:15 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25371 for ; Tue, 10 Apr 2001 16:16:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkeq10321; Tue, 10 Apr 2001 20:14:22 GMT Received: by mail-control.mail.uu.net id QQkkeq19132 for mpls-outgoing; Tue, 10 Apr 2001 20:13:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkeq19127 for ; Tue, 10 Apr 2001 20:13:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkeq11926 for ; Tue, 10 Apr 2001 20:12:31 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkeq07824 for ; Tue, 10 Apr 2001 20:12:30 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA11244 for mpls@uu.net; Tue, 10 Apr 2001 16:12:29 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkeq18960 for ; Tue, 10 Apr 2001 20:11:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkeq08720 for ; Tue, 10 Apr 2001 20:09:42 GMT Received: from viva.vivacenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.132]) id QQkkeq00913 for ; Tue, 10 Apr 2001 20:09:42 GMT Received: from viva1.vivacenetworks.com [10.2.0.198] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id A887103C027A; Tue, 10 Apr 2001 13:09:43 -0700 Received: by viva1.vivacenetworks.com with Internet Mail Service (5.5.2653.19) id <2CCXQ6T5>; Tue, 10 Apr 2001 13:09:40 -0700 Message-ID: From: Jack Shaio To: "'afarrel@movaz.com'" Cc: "'mpls@UU.NET '" Subject: RE: Last Call on LDP Fault Tolerance Date: Tue, 10 Apr 2001 13:09:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk hi Adrian, I had one comment regarding the LDP fault tolerance draft. This draft makes fault tolerance (ft) a property of an individual label rather than a property of the LDP session and requires special care for all LDP messages that affect ft labels. However, these procedures simplify if instead all the labels in an ft LDP session were fault tolerant. One can have 2 parallel LDP sessions if needed to allow for a mix of fault tolerant and non-fault tolerant labels to an LDP peer. If all labels of an ft session are fault tolerant, then you can keep the FT Protection, FT Ack and FT sequence numbers as in the draft, but each LDP peer sends both TLV's in LDP KeepAlives. An FT Ack means that the FT Protection TLV with that FT sequence has been saved by the LDP peer, and because of the underlying TCP transport, also all earlier LDP messages. In case the TCP session is lost, as in a card failure, the ft LDP session only needs to preserve all the LDP messages sent since the last acked FT Protection TLV, and replay them when reconnected (when the FT session reconnect flag is set). This simply makes the TCP failure transparent and exchanges all LDP messages that would have been sent had that session not been lost, without modifying the message processing for LDP or CR-LDP. Changes in topology or label withdraws are handled after the replay is complete, much as if, for example, they had occured while waiting for TCP to retransmit after a lost frame. --jack From owner-mpls@UU.NET Tue Apr 10 16:38:30 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25718 for ; Tue, 10 Apr 2001 16:38:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkes21326; Tue, 10 Apr 2001 20:36:44 GMT Received: by mail-control.mail.uu.net id QQkkes21041 for mpls-outgoing; Tue, 10 Apr 2001 20:36:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkes21023 for ; Tue, 10 Apr 2001 20:36:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkes06327 for ; Tue, 10 Apr 2001 20:35:54 GMT Received: from johnson.mail.mindspring.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: johnson.mail.mindspring.net [207.69.200.177]) id QQkkes29619 for ; Tue, 10 Apr 2001 20:35:54 GMT Received: from mindspring.com (user-2ive3a9.dialup.mindspring.com [165.247.13.73]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA31112; Tue, 10 Apr 2001 16:35:46 -0400 (EDT) Message-ID: <3AD36E80.83AC6510@mindspring.com> Date: Tue, 10 Apr 2001 16:35:12 -0400 From: Eric W Gray X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jack Shaio CC: Adrian Farrel , MPLS Mailing List Subject: Re: Last Call on LDP Fault Tolerance References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jack, This was the way that one of the original drafts was written to work, so this was looked at, believe it or not. Unfortunately, it is not as simple as having either a FT session or a non-FT session (as opposed to FT labels). Fault Tolerance is a property of (at least a segment of) LSPs, rather than (typically) the LSR peers involved in establishing a single link of these LSPs (or LSP segments). As you point out, having parallel sessions could address this, but there are complexities attendant on using this approach as well. Very early on in the process, we opted for one set of complexities over the other. I believe this is a reasonable design choice. -- Eric Gray Jack Shaio wrote: > hi Adrian, > > I had one comment regarding the LDP fault tolerance draft. > > This draft makes fault tolerance (ft) a property of an individual label > rather than a property of the LDP session and requires special care for > all LDP messages that affect ft labels. > > However, these procedures simplify if instead all the labels in an > ft LDP session were fault tolerant. One can have 2 parallel LDP sessions > if needed to allow for a mix of fault tolerant and non-fault tolerant > labels to an LDP peer. > > If all labels of an ft session are fault tolerant, then you can keep the > FT Protection, FT Ack and FT sequence numbers as in the draft, but each > LDP peer sends both TLV's in LDP KeepAlives. An FT Ack means that the > FT Protection TLV with that FT sequence has been saved by the LDP peer, > and because of the underlying TCP transport, also all earlier LDP > messages. > > In case the TCP session is lost, as in a card failure, the ft LDP session > only needs to preserve all the LDP messages sent since the last acked > FT Protection TLV, and replay them when reconnected (when the FT session > reconnect flag is set). > > This simply makes the TCP failure transparent and exchanges all LDP > messages that would have been sent had that session not been lost, without > modifying the message processing for LDP or CR-LDP. > > Changes in topology or label withdraws are handled after the replay > is complete, much as if, for example, they had occured while waiting > for TCP to retransmit after a lost frame. > > --jack From owner-mpls@UU.NET Tue Apr 10 18:18:37 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27255 for ; Tue, 10 Apr 2001 18:18:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkez03785; Tue, 10 Apr 2001 22:16:52 GMT Received: by mail-control.mail.uu.net id QQkkez04058 for mpls-outgoing; Tue, 10 Apr 2001 22:15:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkey03929 for ; Tue, 10 Apr 2001 22:14:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkey27757 for ; Tue, 10 Apr 2001 22:14:41 GMT Received: from uniwest1.redstonecom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.194.140.130]) id QQkkey19701 for ; Tue, 10 Apr 2001 22:14:41 GMT Received: by UNIWEST1 with Internet Mail Service (5.5.2653.19) id <2A5CFNHV>; Tue, 10 Apr 2001 18:14:31 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C015260BB@UNIWEST1> From: "Wadhwa, Sanjay" To: "'mpls@UU.NET'" Subject: Comments on Bypass Label draft Date: Tue, 10 Apr 2001 18:14:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk >Robert, George: >Below are some comments on, and questions about, your bypass label draft. >- Philip >* Refreshing a backup tunnel riding a bypass tunnel > I don't understand how the refresh works in this case. > Section 2 states that the Path message for the backup tunnel is sent inside the bypass > tunnel, while section 3 states that the SENDER_TEMPLATE object contains a sender address > that differs from the address used for the primary LSP. So the merge point LSR will create > a new Path State Block and try to send back a Resv message. But where does it send this > Resv to? If the network is as shown in figure on page 4, then it can send the RESV message > on either the link to R3 or the link to R7. However, in either case, R3 or R7 will intercept > the Resv message, and because neither one is expecting a Resv message with this sender > (because neither saw the corresponding Path message), problems ensue. Philip My understanding is that the PHOP in the path message (for the backup tunnel) sent on the bypass tunnel would be one of PLR's (R2's) addresses. Since the interface on which the path arrived on R4 is uni-directional, R4 will have to just unicast route the resv back to the PHOP. So rsvp on R3 or R7 will not be seeing it. Maybe the draft should be more explicit about signalling for backup tunnels. -Sanjay From owner-mpls@UU.NET Tue Apr 10 19:39:03 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28061 for ; Tue, 10 Apr 2001 19:39:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkdg29188; Tue, 10 Apr 2001 11:01:05 GMT Received: by mail-control.mail.uu.net id QQkkdg15769 for mpls-outgoing; Tue, 10 Apr 2001 11:00:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkdg15365 for ; Tue, 10 Apr 2001 11:00:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkdf28403 for ; Tue, 10 Apr 2001 10:58:05 GMT From: andy.bd.reid@bt.com Received: from gollum.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkkdf02829 for ; Tue, 10 Apr 2001 10:58:04 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Tue, 10 Apr 2001 11:53:22 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Tue, 10 Apr 2001 11:51:48 +0100 Message-ID: <5F54BE0116BCD2118C9400606DD614ED07BE78A5@mclmsent02.lon.bt.com> To: curtis@avici.com, Juergen.Heiles@icn.siemens.de Cc: mlazer@att.com, neil.2.harrison@bt.com, raszuk@cisco.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: restoration time requirement (was Re: Last Call on RSVP Labe l Allocation for Backup Tunnels) Date: Tue, 10 Apr 2001 11:51:50 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Curtis, I not sure I understand what point your trying to make - other that make implicit critcism of the body of engineers who put together SONET/SDH technology. Generally speaking, the specs and parameters that go to make up SONET/SDH are there for good technical and economic reasons and, while some of these may now be historical, it would seem to me more helpful to work from an assumption that a set of good engineers were solving a real problem. I can try and give you my understanding and memory of the problems that resulted in some of the SONET/SDH features you "AFAIK" comment on. I'm sure Heiles, Maarten, and others will comment where their memory differs. 50ms restoration This figure has a very long history. My memory is that this started as time the SONET/SDH payload should wait before assuming a failure in the payload. The figure was chosen somewhat randomly as that were many implementation specific factors which would affect the time including detection of LOS, detection of LOF, any protection mechanism (MSP or internal equipment card protection) and we made a conscious decision not to specify any details of these - they are open to different vendor implementation for good economic reasons. It general use now, it includes any failure detection time, any protection signalling time, any protection switching time, and any time for signals to reacquire and stablise. In practise some implementations with simple 1+1 MSP protection over short distances will switch in a few millisecs while implementations of more complex shared ring MSP protection on geographically large rings struggle to meet the 50ms. This is simply the transmission time required to pass the MSP signalling around the ring. As a broad summary, SONET/SDH is generally designed to go as fast as possible - unless you are goning to invent a new speed for the speed of light, you are unlikely to usefully go faster than SONET/SDH protection schemes. I draw three conclusions from this - lambda optical systems can and should just use the current SONET/SDH specs as this is now the "bottom of the network" - some small modifications are probably needed to reflect the analogue nature of DWDM - SONET/SDH systems deployed over lambda optical systems should understand they are no longer at the bottom of the network and do something about the potential interactions, eg don't use SONET/SDH MSP or use a holdoff timer - all out equipment is specced to have a programmable delay of 0-100ms and the spec was written 10 years ago. - packet based layers must be designed to cope with either SONET/SDH or lambda optical protection switching underneath. Scramblers This is a good example of IETFers not asking the experts in the field. No-one bothered to ask anyone who knew about SONET/SDH before writing the PoS spec and just got it wrong. The x43 + 1 scrambler was specced for non-byte interleaved SONET/SDH payloads in around 1990. There was/is nothing wrong with SONET/SDH only some IETFers not knowing what they don't know. Bi-directional fibre working It has been know for a long time that bi-directional fibre working can cause a problem with detecting fibre breaks - a transmit signal reflects off the break and is received and a perfectly framed signal. This is why the J0 byte was recoded (it was orginally called C1) so that each transmitter can send a different signal label and detect if it receives it own signal label. My guess is the anacdote you refer to was a problem in setting the J0 signal label. Hope this answer some of the "issues" people raise with SONET/SDH. I'm convinced good engineers can work together but it takes a level of mutual respect. Andy > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: 09 April 2001 18:46 > To: Heiles Juergen > Cc: 'curtis@avici.com'; Lazer, Monica A, NNAD; > 'neil.2.harrison@bt.com'; > raszuk@cisco.com; mpls@UU.NET; ccamp@ops.ietf.org > Subject: Re: restoration time requirement (was Re: Last Call on RSVP > Label Allocation for Backup Tunnels) > > > > In message > , Heiles Juergen > writes: > > Curtis > > > > >Then again, this is second hand, so I could be > completely wrong. This > > is not a measurement I've made myself and the SONET > equipment is not somethin > > g I'm familiar with .... > > > > you are completely wrong and I suggest you better make > measurments and get fa > > miliar with SONET before making such statements.. SONET/SDH > equipment will no > > t shut down/drop connections. Today SONET connections are > permanent connectio > > ns setup via the management system. An automatic drop of a > conneciton as it i > > s the case for switched connections will not occur. What > you will see is the > > insertion of AIS (alarm indication signal) after the > detection of an defect. > > But as soon as the defect is gone the AIS is removed and > the connection is ru > > nning again. AIS is nothing harmful as due to the defect > the connection is in > > terupted in any case. Furthermore the AIS avoids downstream > alarms (alarm sto > > rms). > > There was a similar problem encounterred when sending a packet over a > POS link with the old short scrambling pattern in the body of the > packet. My understanding was that there was a small chance that > alignment with the scrambler could take a SONET link out of service, > then take the protect out of service and manual intervention was > required to bring them back into service. That is second hand too but > someone from an ISP stood up at an IETF meeting and claimed to have > tried it with spectacular (though not desireable) results and the > statement wasn't challenged (and I know the person and he is a > reliable source). This statement was made in response to the > assertion that there was no need to change the scrambler pattern > length. > > It was definitely not Siemen SONET gear (but you knew that) and AFAIK > it is not called for in the SONET specs but I've been told that some > other gear does exhibit this behaviour. US carriers in particular > have lots of it which creates a requirement for MPLS restoration that > must be met for some but not all networks and applications. > > My understanding is that this behavior is observed in a particular > implementation, the same one that had the problem with DoS attack > based on the short scrambler pattern. This SONET gear could not be > configured to bring the segment back into service without intervention > which was key to making the DoS attack effective. Note: The DoS > problem was solved by lengthenning the POS scrambler pattern to be > much longer than the MTU, requiring no change to the SONET gear. > > In pointing out that this is second hand I am noting that it is > possible that the problematic implementation might have been upgraded > since these two problems have been encountered and could allow a > configuration option to change this behaviour. AFAIK this is not the > case but I'd be pleased to hear that it has been corrected. We can > continue this discussion offline if you like. > > > What could be of concern are the following points. I talk > about a server laye > > r for a SONET/SDH network (e.g. an Optical Network) > providing protection/res > > toration: > > > > Stacked protection/restoration: > > If you use protection/restoration at an optical network > layer (server) and a > > SONET/SDH network layer (client) the server layer switching > times should be f > > aster than the client layer reaction times, so that the > server layer does the > > protection/restoration and the client layer doesn't react. > > I'm aware of this and I mentioned it below. See paragraph beginning > with OTOH below. > > > Automatic power reduction/automatic laser shutdown APR/ALS > > APR is used for safety reasons in order to avoid harmful > emission of laser li > > ght in case of a fiber cut. One implementation switches off > the transmit lase > > r in case of loss of signal at the receiver. A restart > action which is trigge > > red automatically in intervals of several seconds is > required in order to tes > > t if the link is repaired. Normally the APR function can be > switched off if n > > ot needed. The APR function needs some careful > consideration in case of prote > > ction/restoration and automatic connection setup in all > optical networks. > > Thanks for the info. I hadn't heard this. > > > Regards > > > > Juergen > > Regards, > > Curtis > > > > > -----Original Message----- > > > From: Curtis Villamizar [SMTP:curtis@workhorse.fictitious.org] > > > Sent: Monday, April 09, 2001 4:37 AM > > > To: Lazer, Monica A, NNAD > > > Cc: 'neil.2.harrison@bt.com'; raszuk@cisco.com; > mpls@UU.NET; ccamp@ops.ietf > > .org > > > Subject: restoration time requirement (was Re: Last Call > on RSVP Label A > > llocation for Backup Tunnels) > > > > > > > > > In message > <31236E6272C7D2119F1C0000C0A8E4F40324083D@nj0200po04.bm.att.com> > > , "L > > > azer, Monica A, NNAD" writes: > > > > Voice switches will drop the connections after 2.5 > seconds. A large numbe > > r > > > > of dropped calls will cause FCC reportable events, > which is something tha > > t > > > > US carriers need to avoid. So restoration within this > time frame is neede > > d > > > > for support of trunks carrying voice traffic. > > > > > > > > Monica A. Lazer > > > > Advanced Transport Technology and Architecture Planning > > > > > > > > 908 234 8462 > > > > mlazer@att.com > > > > > > > > > Monica, > > > > > > We're off topic, so I changed the subject. > > > > > > Thanks for providing the 2.5 second figure. > > > > > > I've heard carrier transport people grumble about SONET equipment > > > they'd be please to get rid of that will shut down even > when used as > > > linear SONET with no protect path and as a result would require > > > <100msec restoration. Since there is enough of this > SONET gear, the > > > carriers can't really get rid of it although it will probably > > > disappear over time and so they will make fast restoration a > > > requirement of people they buy from. To be safe, the request for > > > <50msec has been made. > > > > > > If you are not blessed with such equipment or you are able to work > > > around it when doing VoIP, then you are among the fortunate. > > > > > > Then again, this is second hand, so I could be completely > wrong. This > > > is not a measurement I've made myself and the SONET > equipment is not > > > something I'm familiar with such that I could say with > confidence that > > > it could not be configured to hold on longer or to not > shut down at> > > > all if there was no protect. > > > > > > OTOH there are those who (claim to) want to configure > SONET on some > > > links but not on others and don't want a fast > restoration. They want > > > to be assured that restoration will occur only after it is safe to > > > assume that SONET restoration is not available. > > > > > > Curtis > > > From owner-mpls@UU.NET Tue Apr 10 21:29:48 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29792 for ; Tue, 10 Apr 2001 21:29:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkfl06545; Wed, 11 Apr 2001 01:27:53 GMT Received: by mail-control.mail.uu.net id QQkkfl05385 for mpls-outgoing; Wed, 11 Apr 2001 01:27:20 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkfl05376 for ; Wed, 11 Apr 2001 01:27:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkfl15974 for ; Wed, 11 Apr 2001 01:26:49 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQkkfl07970 for ; Wed, 11 Apr 2001 01:26:49 GMT Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQ3L4ZPZ; Tue, 10 Apr 2001 21:26:47 -0400 Message-Id: <3.0.5.32.20010410211927.008a14c0@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 10 Apr 2001 21:19:27 -0400 To: erosen@cisco.com, Mark Duffy From: Mark Duffy Subject: Re: Use of LDP for VPNs Cc: curtis@avici.com, "Herbst, Bill" , mpls@UU.NET In-Reply-To: <200104101225.IAA04542@erosen-sun.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 08:25 AM 4/10/01 -0400, Eric Rosen wrote: > >Mark> RFC 3036 sect. 2.1 gives rules for what packets may be sent on these >Mark> LSPs, depending what FEC elements are associated with the LSPs. > >If you don't bother to implement the Host Address FEC, you don't have to >worry about the precise interpretation of these rules. There is no reason Good point, agreed. >why anybody should implement the Host Address FEC. > >Mark> (I supposed you [Curtis] will tell me that the whole use of LDP for >Mark> topology driven set up should be freely ignored :-) and I would not >Mark> necessarily disagree with you.) > >Just don't expect to interoperate with others, unless you are using MPLS >only for traffic engineering. Interoperability is certainly an important goal for me. 2547bis specifies LDP as a common point of interoperability, however I have heard some dissenting voices on this list speaking in favor of using TE tunnels. Outside of 2547, I'm also interested in the use of hierarchical LSPs to interconnect virtual routers, where pretty much the same considerations apply. For all these reasons therefore I'm trying to probe the sentiment of this list. > >Mark> If MPLS is not ubiquitous between the LSRs that are adjacent at the >Mark> higher level, then the higher level LSP is broken. > >Of all the ways in which connectivity might be broken, forgetting to turn >MPLS on is pretty low on the list. Yet there could be other reasons, besides not turning MPLS on, that the outer (set up by LDP) LSPs might not provide the needed MPLS connectivity from PE-PE. Although the same could also be said for explicitly provisioned TE tunnels used in this role, so I suppose this is not really a persuasive argument against the use of LDP in this case. But then again if using explicitly provisioned TE tunnels, it would be more obvious if the connectivity were not there, and we would therefore be less likely to be sending VPN packets off into the void when there is not connectivity to the remote PE. Thanks for your comments, -Mark From owner-mpls@UU.NET Wed Apr 11 06:10:19 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19420 for ; Wed, 11 Apr 2001 06:10:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkgu09803; Wed, 11 Apr 2001 10:08:34 GMT Received: by mail-control.mail.uu.net id QQkkgu27548 for mpls-outgoing; Wed, 11 Apr 2001 10:07:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkgu27523 for ; Wed, 11 Apr 2001 10:07:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkgu21444 for ; Wed, 11 Apr 2001 10:07:37 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQkkgu08254 for ; Wed, 11 Apr 2001 10:07:32 GMT Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP; Wed, 11 Apr 2001 10:56:21 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 11 Apr 2001 10:56:29 +0100 Message-ID: To: mduffy@quarrytech.com, erosen@cisco.com Cc: curtis@avici.com, billh@netplane.com, mpls@UU.NET Subject: RE: Use of LDP for VPNs Date: Wed, 11 Apr 2001 10:56:19 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Mark Duffy [mailto:mduffy@quarrytech.com] wrote 11 April 2001 02:19 > >ER=>Of all the ways in which connectivity might be broken, > forgetting to turn > >MPLS on is pretty low on the list. > > MD=>Yet there could be other reasons, besides not turning MPLS > on, that the > outer (set up by LDP) LSPs might not provide the needed MPLS > connectivity > from PE-PE. Although the same could also be said for explicitly > provisioned TE tunnels used in this role, so I suppose this > is not really a > persuasive argument against the use of LDP in this case. > > But then again if using explicitly provisioned TE tunnels, it > would be more > obvious if the connectivity were not there, and we would > therefore be less > likely to be sending VPN packets off into the void when there is not > connectivity to the remote PE. NH=> In our MPLS OAM draft we defined the CV (Connectivity Verification) OAM packet. This is like a 1s keepalive that goes from LSP source to LSP sink and passes all peer-level LSRs and all server-layer LSPs transparently. It goes in the data-plane and does not rely on the control-plane. Since the CV pkt contains a unique source identifier it will detect all forms of connectivity failure, ie besides below/within MPLS fabric breaks, it will also detect misrouted/leaking traffic (across CV LSP population). So this would provide a tool to verify that your connectivity was indeed OK. We also provided algorithms for determining availability of both near-end and far-end directions....the latter for the case of wanting to measure the availability of both directions (assuming bi-directional LSPs) from a single end (useful in inter-domain/international case). Simple availability measurements are possible with this tool since (i) the CV rate is deterministic and consistent and (ii) the availability entry/exit criteria is based on a harmonised set of underpinning defect entry/exit criteria. > From owner-mpls@UU.NET Wed Apr 11 06:37:34 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19664 for ; Wed, 11 Apr 2001 06:37:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkgw15941; Wed, 11 Apr 2001 10:35:24 GMT Received: by mail-control.mail.uu.net id QQkkgw28789 for mpls-outgoing; Wed, 11 Apr 2001 10:34:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkgw28775 for ; Wed, 11 Apr 2001 10:34:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkgw10460 for ; Wed, 11 Apr 2001 10:33:54 GMT Received: from ntexgswp02.DMZ by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.kpnqwest.com [193.242.92.8]) id QQkkgw23405 for ; Wed, 11 Apr 2001 10:33:53 GMT Received: from ntexghub01.kpnqwest.com (unverified) by ntexgswp02.DMZ (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 11 Apr 2001 12:37:32 +0200 Received: by ntexghub01 with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Apr 2001 12:29:54 +0200 Message-ID: <3F3B952383E8D311A9FC0008C7E61402027A05B5@ntexgdhg02> From: "Metz, Eduard" To: "'neil.2.harrison@bt.com'" , mduffy@quarrytech.com, erosen@cisco.com Cc: curtis@avici.com, billh@netplane.com, mpls@UU.NET Subject: RE: Use of LDP for VPNs Date: Wed, 11 Apr 2001 12:32:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk This assumes you know where the LSP is supposed to end, where do you get this knowledge? cheers, Eduard > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: 11 April 2001 11:56 > To: mduffy@quarrytech.com; erosen@cisco.com > Cc: curtis@avici.com; billh@netplane.com; mpls@UU.NET > Subject: RE: Use of LDP for VPNs > > > Mark Duffy [mailto:mduffy@quarrytech.com] wrote 11 April 2001 02:19 > > > >ER=>Of all the ways in which connectivity might be broken, > > forgetting to turn > > >MPLS on is pretty low on the list. > > > > MD=>Yet there could be other reasons, besides not turning MPLS > > on, that the > > outer (set up by LDP) LSPs might not provide the needed MPLS > > connectivity > > from PE-PE. Although the same could also be said for explicitly > > provisioned TE tunnels used in this role, so I suppose this > > is not really a > > persuasive argument against the use of LDP in this case. > > > > But then again if using explicitly provisioned TE tunnels, it > > would be more > > obvious if the connectivity were not there, and we would > > therefore be less > > likely to be sending VPN packets off into the void when there is not > > connectivity to the remote PE. > NH=> In our MPLS OAM draft we defined the CV (Connectivity > Verification) OAM > packet. This is like a 1s keepalive that goes from LSP > source to LSP sink > and passes all peer-level LSRs and all server-layer LSPs > transparently. It > goes in the data-plane and does not rely on the > control-plane. Since the CV > pkt contains a unique source identifier it will detect all forms of > connectivity failure, ie besides below/within MPLS fabric > breaks, it will > also detect misrouted/leaking traffic (across CV LSP > population). So this > would provide a tool to verify that your connectivity was > indeed OK. We > also provided algorithms for determining availability of both > near-end and > far-end directions....the latter for the case of wanting to > measure the > availability of both directions (assuming bi-directional > LSPs) from a single > end (useful in inter-domain/international case). Simple availability > measurements are possible with this tool since (i) the CV rate is > deterministic and consistent and (ii) the availability > entry/exit criteria > is based on a harmonised set of underpinning defect > entry/exit criteria. > > > From owner-mpls@UU.NET Wed Apr 11 10:02:44 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24335 for ; Wed, 11 Apr 2001 10:02:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkhk13375; Wed, 11 Apr 2001 14:00:52 GMT Received: by mail-control.mail.uu.net id QQkkhk03230 for mpls-outgoing; Wed, 11 Apr 2001 14:00:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkhk02206 for ; Wed, 11 Apr 2001 14:00:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkhj06140 for ; Wed, 11 Apr 2001 13:59:26 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQkkhj10766 for ; Wed, 11 Apr 2001 13:59:26 GMT Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQ3L45F8; Wed, 11 Apr 2001 09:59:24 -0400 Message-Id: <3.0.5.32.20010411095538.008e7d80@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 11 Apr 2001 09:55:38 -0400 To: neil.2.harrison@bt.com, mduffy@quarrytech.com, erosen@cisco.com From: Mark Duffy Subject: RE: Use of LDP for VPNs Cc: curtis@avici.com, billh@netplane.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 At 10:56 AM 4/11/01 +0100, neil.2.harrison@bt.com wrote: >Mark Duffy [mailto:mduffy@quarrytech.com] wrote 11 April 2001 02:19 > >> >ER=>Of all the ways in which connectivity might be broken, >> forgetting to turn >> >MPLS on is pretty low on the list. >> >> MD=>Yet there could be other reasons, besides not turning MPLS >> on, that the >> outer (set up by LDP) LSPs might not provide the needed MPLS >> connectivity >> from PE-PE. Although the same could also be said for explicitly >> provisioned TE tunnels used in this role, so I suppose this >> is not really a >> persuasive argument against the use of LDP in this case. >> >> But then again if using explicitly provisioned TE tunnels, it >> would be more >> obvious if the connectivity were not there, and we would >> therefore be less >> likely to be sending VPN packets off into the void when there is not >> connectivity to the remote PE. >NH=> In our MPLS OAM draft we defined the CV (Connectivity Verification) OAM >packet. This is like a 1s keepalive that goes from LSP source to LSP sink >and passes all peer-level LSRs and all server-layer LSPs transparently. It >goes in the data-plane and does not rely on the control-plane. Since the CV >pkt contains a unique source identifier it will detect all forms of >connectivity failure, ie besides below/within MPLS fabric breaks, it will >also detect misrouted/leaking traffic (across CV LSP population). So this >would provide a tool to verify that your connectivity was indeed OK. We >also provided algorithms for determining availability of both near-end and >far-end directions....the latter for the case of wanting to measure the >availability of both directions (assuming bi-directional LSPs) from a single >end (useful in inter-domain/international case). Simple availability >measurements are possible with this tool since (i) the CV rate is >deterministic and consistent and (ii) the availability entry/exit criteria >is based on a harmonised set of underpinning defect entry/exit criteria. MD=> Neil, My concern is that with topology-driven LSPs set up by LDP, the LSP (i.e. MPLS connectivity) may or may not extend all the way from the sender to the device that distributed the next higher layer label. The LSP corresponds to a FEC, not to a particular egress point. This is just normal operation of LDP. Although I'm not familiar with your OAM draft, I wouldn't expect it to detect this type of condition which after all is not an "error" from the point of view of LDP and the outer layer LSP. (However, it is a serious problem for any inner (client) LSPs.) -Mark From owner-mpls@UU.NET Wed Apr 11 10:23:03 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24706 for ; Wed, 11 Apr 2001 10:23:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkhl17461; Wed, 11 Apr 2001 14:21:02 GMT Received: by mail-control.mail.uu.net id QQkkhl21087 for mpls-outgoing; Wed, 11 Apr 2001 14:20:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkhl21067 for ; Wed, 11 Apr 2001 14:20:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkhl03843 for ; Wed, 11 Apr 2001 14:16:56 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkkhl29353 for ; Wed, 11 Apr 2001 14:16:56 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 HAA15403 for ; Wed, 11 Apr 2001 07:17:19 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA05866 for mpls@uu.net; Wed, 11 Apr 2001 10:16:54 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkgb22536 for ; Wed, 11 Apr 2001 05:28:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkgb16962 for ; Wed, 11 Apr 2001 05:28:03 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQkkgb15602 for ; Wed, 11 Apr 2001 05:28:02 GMT Received: from gayatri.hclt.com (GAYATRI [192.168.232.199]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2ST66P2M; Wed, 11 Apr 2001 11:08:54 +0530 Received: from VIJAYC ([192.168.232.145]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 24KQ9XFT; Wed, 11 Apr 2001 11:02:31 +0530 From: "Vijayanand C" To: Cc: Subject: CR-LDP tuneel egress Date: Wed, 14 Mar 2001 10:57:00 +0530 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, The TE-MIB specifies the Egress LSRID of a tunnel as one of the indices of the tunnel tunnel table. When CR-LDP is used for establishing the tunnels, should we always use the last hop of the ER-TLV as a strict Hop with prefix length of 32? Otherwise, how will the tunnel egress be known to the other nodes of the tunnel. If an IPv4 prefix FEC address element is used then it may not be possible to identify the tunnel egress as CR-LSP establishment may proceed after the last hop specified by the ER-HOP TLV. How is the tunnel egress determined in this case? Thanks in advance, Vijay From owner-mpls@UU.NET Wed Apr 11 10:43:16 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25129 for ; Wed, 11 Apr 2001 10:43:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkhm06245; Wed, 11 Apr 2001 14:41:27 GMT Received: by mail-control.mail.uu.net id QQkkhm23967 for mpls-outgoing; Wed, 11 Apr 2001 14:40:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkhm23949 for ; Wed, 11 Apr 2001 14:40:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkhm20065 for ; Wed, 11 Apr 2001 14:40:31 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkkhm04390 for ; Wed, 11 Apr 2001 14:40:30 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 HAA29005; Wed, 11 Apr 2001 07:40:29 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA05951; Wed, 11 Apr 2001 10:40:28 -0400 (EDT) Message-Id: <200104111440.KAA05951@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Mark Duffy cc: mpls@UU.NET Subject: Re: Use of LDP for VPNs In-reply-to: Your message of Tue, 10 Apr 2001 21:19:27 -0400. <3.0.5.32.20010410211927.008a14c0@10.1.1.249> 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: Wed, 11 Apr 2001 10:40:27 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Mark> Interoperability is certainly an important goal for me. 2547bis Mark> specifies LDP as a common point of interoperability, however I have Mark> heard some dissenting voices on this list speaking in favor of using Mark> TE tunnels. Well, what you need in order to interoperate is a matter of what the common implementations do, which is a matter of fact rather than a matter of opinion. The use of multipoint-to-point non-explicitly-signaled LSPs is so much more efficient than the use of TE tunnels that no one would really use TE tunnels for this unless they needed the explicit path setup in order to do traffic engineering. (Or unless they had neglected to implement LDP ;-)) There have been some folks claiming that the specs should be altered so that non-interoperable implementations could individually claim compliance to the specs. One can see the advantage of this from a vendor perspective, but I'm not sure how this advantage could be explained to the Service Providers ;-) Mark> Yet there could be other reasons, besides not turning MPLS on, that Mark> the outer (set up by LDP) LSPs might not provide the needed MPLS Mark> connectivity from PE-PE. Although the same could also be said for Mark> explicitly provisioned TE tunnels used in this role, so I suppose this Mark> is not really a persuasive argument against the use of LDP in this Mark> case. Indeed. If you're thinking of the type of failure in which the control plane says everything is okay, but the data plane is broken, there is no reason to think that LDP-controlled topology-driven LSPs are any more vulnerable than TE tunnels. Mark> But then again if using explicitly provisioned TE tunnels, it would be Mark> more obvious if the connectivity were not there, and we would Mark> therefore be less likely to be sending VPN packets off into the void Mark> when there is not connectivity to the remote PE. I don't see why this would be the case. If you're worried about this sort of thing, you need some sort of edge-to-edge keepalive, the control protocol that is used to set up the LSPs is not really germane. From owner-mpls@UU.NET Wed Apr 11 11:34:12 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26267 for ; Wed, 11 Apr 2001 11:34:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkhq11334; Wed, 11 Apr 2001 15:32:03 GMT Received: by mail-control.mail.uu.net id QQkkhq16184 for mpls-outgoing; Wed, 11 Apr 2001 15:31:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkhq16165 for ; Wed, 11 Apr 2001 15:31:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkhq28979 for ; Wed, 11 Apr 2001 15:30:52 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQkkhq17239 for ; Wed, 11 Apr 2001 15:30:51 GMT Received: from chqlubnt02.lon.bt.com by marvin (local) with ESMTP; Wed, 11 Apr 2001 16:04:12 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <1TTJWZAT>; Wed, 11 Apr 2001 16:04:09 +0100 Message-ID: To: mduffy@quarrytech.com, erosen@cisco.com Cc: curtis@avici.com, billh@netplane.com, mpls@UU.NET Subject: RE: Use of LDP for VPNs Date: Wed, 11 Apr 2001 16:03:56 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Mark Duffy [mailto:mduffy@quarrytech.com] commented on 11 April 2001 14:56 > To: neil.2.harrison@bt.com; mduffy@quarrytech.com; erosen@cisco.com > Cc: curtis@avici.com; billh@netplane.com; mpls@UU.NET > Subject: RE: Use of LDP for VPNs > > > At 10:56 AM 4/11/01 +0100, neil.2.harrison@bt.com wrote: > >Mark Duffy [mailto:mduffy@quarrytech.com] wrote 11 April 2001 02:19 > > > >> >ER=>Of all the ways in which connectivity might be broken, > >> forgetting to turn > >> >MPLS on is pretty low on the list. > >> > >> MD=>Yet there could be other reasons, besides not turning MPLS > >> on, that the > >> outer (set up by LDP) LSPs might not provide the needed MPLS > >> connectivity > >> from PE-PE. Although the same could also be said for explicitly > >> provisioned TE tunnels used in this role, so I suppose this > >> is not really a > >> persuasive argument against the use of LDP in this case. > >> > >> But then again if using explicitly provisioned TE tunnels, it > >> would be more > >> obvious if the connectivity were not there, and we would > >> therefore be less > >> likely to be sending VPN packets off into the void when > there is not > >> connectivity to the remote PE. > >NH=> In our MPLS OAM draft we defined the CV (Connectivity > Verification) OAM > >packet. This is like a 1s keepalive that goes from LSP > source to LSP sink > >and passes all peer-level LSRs and all server-layer LSPs > transparently. It > >goes in the data-plane and does not rely on the > control-plane. Since the CV > >pkt contains a unique source identifier it will detect all forms of > >connectivity failure, ie besides below/within MPLS fabric > breaks, it will > >also detect misrouted/leaking traffic (across CV LSP > population). So this > >would provide a tool to verify that your connectivity was > indeed OK. We > >also provided algorithms for determining availability of > both near-end and > >far-end directions....the latter for the case of wanting to > measure the > >availability of both directions (assuming bi-directional > LSPs) from a single > >end (useful in inter-domain/international case). Simple availability > >measurements are possible with this tool since (i) the CV rate is > >deterministic and consistent and (ii) the availability > entry/exit criteria > >is based on a harmonised set of underpinning defect > entry/exit criteria. > > MD=> Neil, My concern is that with topology-driven LSPs set > up by LDP, the > LSP (i.e. MPLS connectivity) may or may not extend all the > way from the > sender to the device that distributed the next higher layer > label. The LSP > corresponds to a FEC, not to a particular egress point. This is just > normal operation of LDP. Although I'm not familiar with your > OAM draft, I > wouldn't expect it to detect this type of condition which > after all is not > an "error" from the point of view of LDP and the outer layer LSP. > (However, it is a serious problem for any inner (client) LSPs.) > NH=> (And also as response to Eduard Metz who asked 'how does one know where the LSP sink is?'). Sorry if I was not clear on this....in our work we are *not* considering any form of LSP other than ER pt-pt LSPs (eg RSVP-TE or CR-LDP set-up LSPs....though in principle I guess it could (should?) apply to BGP4 set-up LSPs). So, by definition, the signalling knows where the sink point of the LSP is supposed to be when setting the LSP up. There are 3 ways that the sink point could be told the value of the TTSI (Trail Termination Source Identifier = router IP address + tunnel ID) it should be expected to see; - by manual config - by 'self-learning' of what it sees in the user-plane directly after set-up as the 1st CV flow it sees (though this has some obvious slight risk with it) - by being told of this during LSP set-up by the signalling protocol. The latter one would be the ideal way IMO. One can have a CV on any pt-pt LSP. And when LSPs are nested, and especially if the higher LSP straddles several lower LSPs (eg a transit LSP service over several domains say), then this might be deemed as quite important. This way each of the domains could verify/measure their own connectivity/availability, and so could the larger higher level LSP span. Further, under failure the FDI pkts (which would be originally sourced at the lowest LSP level affected) would (i) stop all higher level alarms and (ii) allow higher level LSPs affected to know where the failure was from (at least to domain....there is no intention of providing any detailed nodal location information). From owner-mpls@UU.NET Wed Apr 11 12:27:58 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27704 for ; Wed, 11 Apr 2001 12:27:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkht22664; Wed, 11 Apr 2001 16:25:54 GMT Received: by mail-control.mail.uu.net id QQkkht08567 for mpls-outgoing; Wed, 11 Apr 2001 16:25:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkht08531 for ; Wed, 11 Apr 2001 16:25:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkht26518 for ; Wed, 11 Apr 2001 16:24:13 GMT Received: from tomp.smb.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQkkht01355 for ; Wed, 11 Apr 2001 16:24:12 GMT Received: from utfors.se ([10.58.0.153]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GBMYZW00.A56; Wed, 11 Apr 2001 18:26:20 +0200 Message-ID: <3AD48529.23DA841D@utfors.se> Date: Wed, 11 Apr 2001 18:24:09 +0200 From: "Loa Andersson" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Sharma Prem" CC: "'Don Fedyk'" , manoj juneja , mpls@UU.NET Subject: Re: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQkkht22664 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27704 All, Manojs question is valid, and the answers are less than satisfactory. Actions in case of next hop changes needs to be specified, some are in the LDP spec, others ae specific for CR-LDP. There are some cases (list not complete). - with loosely routed LSP and a better route is found, because of a next hop change. In this case I can't see a problem the procedures are specified in the LDP specification (p 113), assuming that a loosely routed CR-LSP is roughly equivalent to a DoD ordered LSP in it lose parts. - equipment failure leading to that LDP peering is lost in a loosely routed part of an LSP. The outstanding Label Request is by definition lost. The actions needed here is very similar to what is done in the situation described above. But this needs to be specified. - equipment failure in a strictly routed part of an LSP. My feeling is that this should be NAKed and responsibility to clear up the situation should be left to the application requesting the explicitly routed LSP. Question here is what a loosely routed node does when it receives the NAK? Chances are that the next hop has changed for this node. Also needs to be specified. Test to this effect should be added to the CR-LDP specification. Haven't checked but do we have the same problem for RSVP-TE? BTW, Don's statement that next hop changes do not affect explicitly routed LSP is only partly true. In some known cases the LSDB is used to calculate the explicit LSP, the information that lead to next hop changing will be reflected in the LSDB used to calculate the explicit route(s). /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Wed Apr 11 12:37:18 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28150 for ; Wed, 11 Apr 2001 12:37:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkhu19740; Wed, 11 Apr 2001 16:35:24 GMT Received: by mail-control.mail.uu.net id QQkkhu09030 for mpls-outgoing; Wed, 11 Apr 2001 16:34:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkhu09023 for ; Wed, 11 Apr 2001 16:34:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkhu21660 for ; Wed, 11 Apr 2001 16:33:00 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkkhu01135 for ; Wed, 11 Apr 2001 16:32:58 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA17255; Wed, 11 Apr 2001 12:32:30 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104111632.MAA17255@workhorse.fictitious.org> To: Mark Duffy cc: erosen@cisco.com, curtis@avici.com, "Herbst, Bill" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Use of LDP for VPNs In-reply-to: Your message of "Tue, 10 Apr 2001 21:19:27 EDT." <3.0.5.32.20010410211927.008a14c0@10.1.1.249> Date: Wed, 11 Apr 2001 12:32:30 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3.0.5.32.20010410211927.008a14c0@10.1.1.249>, Mark Duffy writes: > > > >Mark> (I supposed you [Curtis] will tell me that the whole use of LDP for > >Mark> topology driven set up should be freely ignored :-) and I would not > >Mark> necessarily disagree with you.) > > > >Just don't expect to interoperate with others, unless you are using MPLS > >only for traffic engineering. > > Interoperability is certainly an important goal for me. 2547bis specifies > LDP as a common point of interoperability, however I have heard some > dissenting voices on this list speaking in favor of using TE tunnels. > Outside of 2547, I'm also interested in the use of hierarchical LSPs to > interconnect virtual routers, where pretty much the same considerations > apply. For all these reasons therefore I'm trying to probe the sentiment > of this list. Let me be clear about what I said. Interoperability is goodness. We do LDP for RFC2547 and it works with both Cisco and Juniper (interoperability testing has occurred in out lab, UNH, and GMU). We also allow the LDP tunnel to ride inside a RSVP/TE tunnel. This offers benefits (which I won't enumerate again). If this feature is used, we still interoperate with others running LDP and others running RSVP/TE in the same network, although afaik we have not checked an Avici router on one end of the TE tunnel and another router on the other end (but we should get there). If the TE tunnels go all the way to the edge and if this is done in a way that scales well, then the need for LDP disappears. My understanding of the real reason why we are using LDP for VPN is that it had more to do with the scalability of a particular RSVP/TE implementation rather than an issue of protocol scalability (though authors would never admit this). If RSVP/TE does prove to be very scalable, particularly with multi-area support and hierarchical tunnels, then the need for LDP in some networks (the "in some networks" is an important qualifier) may go away. As long as there are routers in a network which have a scaling problem with RSVP/TE are in a network (older routers tend to migrate toward the edge) there will be a need to support LDP (possibly just near the edge). Curtis From owner-mpls@UU.NET Wed Apr 11 13:04:59 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28974 for ; Wed, 11 Apr 2001 13:04:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkhw22595; Wed, 11 Apr 2001 17:03:18 GMT Received: by mail-control.mail.uu.net id QQkkhw15476 for mpls-outgoing; Wed, 11 Apr 2001 17:02:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkhw15441 for ; Wed, 11 Apr 2001 17:02:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkhw16378 for ; Wed, 11 Apr 2001 17:02:06 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkkhw21182 for ; Wed, 11 Apr 2001 17:02: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 KAA04254; Wed, 11 Apr 2001 10:02:28 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA06269; Wed, 11 Apr 2001 13:02:03 -0400 (EDT) Message-Id: <200104111702.NAA06269@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: curtis@avici.com cc: Mark Duffy , "Herbst, Bill" , mpls@UU.NET Subject: Re: Use of LDP for VPNs In-reply-to: Your message of Wed, 11 Apr 2001 12:32:30 -0400. <200104111632.MAA17255@workhorse.fictitious.org> 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: Wed, 11 Apr 2001 13:02:02 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Curtis> My understanding of the real reason why we are using LDP for VPN is Curtis> that it had more to do with the scalability of a particular RSVP/TE Curtis> implementation If you are speculating about the reason Cisco uses LDP in support of RFC2547 VPNs, then I can state authoritatively that this has nothing whatsoever to do with any characteristic of any RSVP/TE implementation. From owner-mpls@UU.NET Wed Apr 11 13:56:05 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29837 for ; Wed, 11 Apr 2001 13:56:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkhz12478; Wed, 11 Apr 2001 17:54:15 GMT Received: by mail-control.mail.uu.net id QQkkhz01827 for mpls-outgoing; Wed, 11 Apr 2001 17:53:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkhz01800 for ; Wed, 11 Apr 2001 17:53:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkhz06377 for ; Wed, 11 Apr 2001 17:53:06 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkhz20869 for ; Wed, 11 Apr 2001 17:53:05 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA25248 for mpls@uu.net; Wed, 11 Apr 2001 13:53:04 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkhz01746 for ; Wed, 11 Apr 2001 17:52:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkhz19203 for ; Wed, 11 Apr 2001 17:52:15 GMT Received: from ns02.newbridge.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: ns02.newbridge.com [192.75.23.75]) id QQkkhz09131 for ; Wed, 11 Apr 2001 17:52:15 GMT Received: (qmail 14275 invoked from network); 11 Apr 2001 17:50:28 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 11 Apr 2001 17:50:28 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Wed, 11 Apr 2001 13:50:36 -0400 Received: from alcatel.com ([138.120.51.119]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA41DD; Wed, 11 Apr 2001 13:50:34 -0400 Message-Id: <3AD4992B.99164E9B@alcatel.com> Date: Wed, 11 Apr 2001 13:49:31 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: erosen@cisco.com CC: curtis@avici.com, Mark Duffy , "Herbst, Bill" , mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <200104111702.NAA06269@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, Then mind telling us what are the reasons? I have been hearing LDP is used to achieve maximum degree of interoperability with other vendors. However, I find it difficult to accept as there're probably much more vendors supporting RSVP-TE than LDP. Cheers, Hansen Eric Rosen wrote: > Curtis> My understanding of the real reason why we are using LDP for VPN is > Curtis> that it had more to do with the scalability of a particular RSVP/TE > Curtis> implementation > > If you are speculating about the reason Cisco uses LDP in support of RFC2547 > VPNs, then I can state authoritatively that this has nothing whatsoever to > do with any characteristic of any RSVP/TE implementation. From owner-mpls@UU.NET Wed Apr 11 14:07:09 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00155 for ; Wed, 11 Apr 2001 14:07:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkia01510; Wed, 11 Apr 2001 18:05:21 GMT Received: by mail-control.mail.uu.net id QQkkia10642 for mpls-outgoing; Wed, 11 Apr 2001 18:04:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkia10139 for ; Wed, 11 Apr 2001 18:04:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkia01443 for ; Wed, 11 Apr 2001 18:04:22 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkkia02796 for ; Wed, 11 Apr 2001 18:04:21 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 LAA18348 for ; Wed, 11 Apr 2001 11:04:45 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA06456 for mpls@uu.net; Wed, 11 Apr 2001 14:04:20 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkhz01495 for ; Wed, 11 Apr 2001 17:49:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkhz06497 for ; Wed, 11 Apr 2001 17:48:11 GMT Received: from mapleoptical.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host202.razafoundries.com [63.111.208.202] (may be forged)) id QQkkhz15567 for ; Wed, 11 Apr 2001 17:48:10 GMT Received: from morphius.mapleoptical.com (localhost [127.0.0.1]) by mapleoptical.com (8.11.0/8.11.0) with ESMTP id f3BHmWx17314 for ; Wed, 11 Apr 2001 10:48:32 -0700 (PDT) Received: by morphius.mapleoptical.com with Internet Mail Service (5.5.2653.19) id <2TD0RJK1>; Wed, 11 Apr 2001 10:48:06 -0700 Message-ID: From: Vic Nowoslawski To: "'mpls@uu.net'" Subject: Has anyone heard of the IETF PWOT proposed working group and what they are upto? Date: Wed, 11 Apr 2001 10:47:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Has anyone heard of the IETF PWOT proposed working group and what they are upto? It might have a focus on ATM and MPLS interworking? Thank You very much! Vic Nowoslawski Maple Optical Systems 724-575-1305 vnowo@mapleoptical.com From owner-mpls@UU.NET Wed Apr 11 14:08:59 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00181 for ; Wed, 11 Apr 2001 14:08:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkia05380; Wed, 11 Apr 2001 18:07:18 GMT Received: by mail-control.mail.uu.net id QQkkia12509 for mpls-outgoing; Wed, 11 Apr 2001 18:06:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkia12496 for ; Wed, 11 Apr 2001 18:06:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkia06309 for ; Wed, 11 Apr 2001 18:06:15 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host200.pluris.com [208.227.9.200]) id QQkkia04715 for ; Wed, 11 Apr 2001 18:06:14 GMT Received: from localhost (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA02689; Wed, 11 Apr 2001 11:05:20 -0700 (PDT) Date: Wed, 11 Apr 2001 11:05:14 -0700 (PDT) From: Bora Akyol To: HANSEN CHAN cc: , , Mark Duffy , "Herbst, Bill" , Subject: Re: Use of LDP for VPNs In-Reply-To: <3AD4992B.99164E9B@alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk For MPLS based VPNs, LDP scales better than RSVP-TE and requires less configuration as the network evolves. What happens is that egress routers advertise /32 FECs to themselves in Downstream-Unsolicited mode with liberal label retention. iBGP with "advertise-self" is used to set the NH attribute to the iBGP peer instead of the eBGP peer. This allows two things: 1) Only transit traffic gets sucked into the tunnels. This is what VPNs are about. 2) Core routers in the network know nothing about the BGP peering and they don't run BGP. As an added benefit, with liberal retention, LDP is able to heal much faster when routers in the middle of the network become unreachable. Makes sense? Bora Who thinks that someone should write a BCP on MPLS based VPN usage. On Wed, 11 Apr 2001, HANSEN CHAN wrote: > Eric, > > Then mind telling us what are the reasons? I have been hearing LDP is used to > achieve maximum degree of interoperability with other vendors. However, I find > it difficult to accept as there're probably much more vendors supporting RSVP-TE > than LDP. > > Cheers, > Hansen > > Eric Rosen wrote: > > > Curtis> My understanding of the real reason why we are using LDP for VPN is > > Curtis> that it had more to do with the scalability of a particular RSVP/TE > > Curtis> implementation > > > > If you are speculating about the reason Cisco uses LDP in support of RFC2547 > > VPNs, then I can state authoritatively that this has nothing whatsoever to > > do with any characteristic of any RSVP/TE implementation. > From owner-mpls@UU.NET Wed Apr 11 14:45:19 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00884 for ; Wed, 11 Apr 2001 14:45:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkic25597; Wed, 11 Apr 2001 18:43:29 GMT Received: by mail-control.mail.uu.net id QQkkic23740 for mpls-outgoing; Wed, 11 Apr 2001 18:42:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkic23726 for ; Wed, 11 Apr 2001 18:42:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkic24015 for ; Wed, 11 Apr 2001 18:42:18 GMT Received: from qtech1.quarrytech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQkkic24269 for ; Wed, 11 Apr 2001 18:42:18 GMT Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQ3L46DC; Wed, 11 Apr 2001 14:42:17 -0400 Message-Id: <3.0.5.32.20010411143836.008ba100@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 11 Apr 2001 14:38:36 -0400 To: erosen@cisco.com From: Mark Duffy Subject: Re: Use of LDP for VPNs Cc: mpls@UU.NET In-Reply-To: <200104111440.KAA05951@erosen-sun.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, At 10:40 AM 4/11/01 -0400, Eric Rosen wrote: >The use of multipoint-to-point non-explicitly-signaled LSPs is so much more >efficient than the use of TE tunnels that no one would really use TE tunnels >for this unless they needed the explicit path setup in order to do traffic >engineering. (Or unless they had neglected to implement LDP ;-)) Aside from standards and implementations of BGP-MPLS VPNs, I am interested in the separate but technically similar issue of how 2-level LSPs should be established for Virtual Router VPNs. So I would like to understand a little more about your point above. Do you consider the use of LDP more efficient because of the multipoint-to-point nature, so that fewer LSPs might be required? Or because you believe use of LDP requires less provisioning? (I would think point-to-point TE tunnels could be *automatically* set up between participating PEs, if using normal shortest path routing.) Or for some other reason? Depending on what labels are being requested (or distributed unsolicited) LDP might cause a great deal more signaling, while it distributes labels for many FECs that might well be unnecessary to support the VPN application. Thanks, Mark From owner-mpls@UU.NET Wed Apr 11 14:58:44 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01093 for ; Wed, 11 Apr 2001 14:58:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkid10497; Wed, 11 Apr 2001 18:56:22 GMT Received: by mail-control.mail.uu.net id QQkkid25341 for mpls-outgoing; Wed, 11 Apr 2001 18:55:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkid25324 for ; Wed, 11 Apr 2001 18:55:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkid28080 for ; Wed, 11 Apr 2001 18:55:09 GMT Received: from newdev.harvard.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQkkid03231 for ; Wed, 11 Apr 2001 18:55:08 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id OAA06419; Wed, 11 Apr 2001 14:55:03 -0400 (EDT) Date: Wed, 11 Apr 2001 14:55:03 -0400 (EDT) From: Scott Bradner Message-Id: <200104111855.OAA06419@newdev.harvard.edu> To: mpls@UU.NET, Vic.Nowoslawski@mapleoptical.com Subject: Re: Has anyone heard of the IETF PWOT proposed working group and what they are upto? Sender: owner-mpls@UU.NET Precedence: bulk > Has anyone heard of the IETF PWOT proposed working group and what they are > upto? pwot is now called pwe3 and a draft charter was posted on the IETF list last last week Scott From owner-mpls@UU.NET Wed Apr 11 15:11:04 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01360 for ; Wed, 11 Apr 2001 15:11:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkie26526; Wed, 11 Apr 2001 19:08:56 GMT Received: by mail-control.mail.uu.net id QQkkie12240 for mpls-outgoing; Wed, 11 Apr 2001 19:08:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkie11781 for ; Wed, 11 Apr 2001 19:08:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkie05940 for ; Wed, 11 Apr 2001 19:07:45 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkkie12430 for ; Wed, 11 Apr 2001 19:07:43 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA18084; Wed, 11 Apr 2001 15:07:22 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104111907.PAA18084@workhorse.fictitious.org> To: erosen@cisco.com cc: curtis@avici.com, Mark Duffy , "Herbst, Bill" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Use of LDP for VPNs In-reply-to: Your message of "Wed, 11 Apr 2001 13:02:02 EDT." <200104111702.NAA06269@erosen-sun.cisco.com> Date: Wed, 11 Apr 2001 15:07:22 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200104111702.NAA06269@erosen-sun.cisco.com>, Eric Rosen writes: > > Curtis> My understanding of the real reason why we are using LDP for VPN is > Curtis> that it had more to do with the scalability of a particular RSVP/TE > Curtis> implementation > > If you are speculating about the reason Cisco uses LDP in support of RFC2547 > VPNs, then I can state authoritatively that this has nothing whatsoever to > do with any characteristic of any RSVP/TE implementation. Rather than vendor bashing, I've taken this offline. Any historical reason for using LDP is not important. RSVP/TE has advantages and if scaling is not an issue, there are some that would prefer to have the TE advantages and if TE extends to the edges not have an extra protocol and label with no clear purpose. Curtis From owner-mpls@UU.NET Wed Apr 11 15:12:16 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01383 for ; Wed, 11 Apr 2001 15:12:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkie28918; Wed, 11 Apr 2001 19:10:06 GMT Received: by mail-control.mail.uu.net id QQkkie12336 for mpls-outgoing; Wed, 11 Apr 2001 19:08:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkie11787 for ; Wed, 11 Apr 2001 19:08:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkie24687 for ; Wed, 11 Apr 2001 19:07:53 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkie12604 for ; Wed, 11 Apr 2001 19:07:52 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA04222 for mpls@uu.net; Wed, 11 Apr 2001 15:07:52 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkie09305 for ; Wed, 11 Apr 2001 19:07:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkie07238 for ; Wed, 11 Apr 2001 19:05:44 GMT Received: from ns02.newbridge.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: ns02.newbridge.com [192.75.23.75]) id QQkkie21534 for ; Wed, 11 Apr 2001 19:05:44 GMT Received: (qmail 19435 invoked from network); 11 Apr 2001 19:03:59 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 11 Apr 2001 19:03:59 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Wed, 11 Apr 2001 15:04:57 -0400 Received: from alcatel.com ([138.120.51.119]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA158A; Wed, 11 Apr 2001 15:04:55 -0400 Message-Id: <3AD4AA97.B9A67685@alcatel.com> Date: Wed, 11 Apr 2001 15:03:52 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Bora Akyol CC: erosen@cisco.com, curtis@avici.com, Mark Duffy , "Herbst, Bill" , mpls@UU.NET Subject: Re: Use of LDP for VPNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora, > For MPLS based VPNs, LDP scales better than RSVP-TE and requires less > configuration as the network evolves. I must have missed something here. Why is LDP requires less configuration and scale better? The BGP explanation below confuses me more. The way I understand is that BGP is used to setup the inner label. It has nothing to do with the outer label negotiation by LDP between PEs. Cheers, Hansen > > > What happens is that egress routers advertise /32 FECs to themselves in > Downstream-Unsolicited mode with liberal label retention. iBGP with > "advertise-self" is used to set the NH attribute to the iBGP peer instead > of the eBGP peer. This allows two things: > > 1) Only transit traffic gets sucked into the tunnels. This is what VPNs > are about. > > 2) Core routers in the network know nothing about the BGP peering and they > don't run BGP. > > As an added benefit, with liberal retention, LDP is able to heal much > faster when routers in the middle of the network become unreachable. > > Makes sense? > > Bora > Who thinks that someone should write a BCP on MPLS based VPN usage. > > On Wed, 11 Apr 2001, HANSEN CHAN wrote: > > > Eric, > > > > Then mind telling us what are the reasons? I have been hearing LDP is used to > > achieve maximum degree of interoperability with other vendors. However, I find > > it difficult to accept as there're probably much more vendors supporting RSVP-TE > > than LDP. > > > > Cheers, > > Hansen > > > > Eric Rosen wrote: > > > > > Curtis> My understanding of the real reason why we are using LDP for VPN is > > > Curtis> that it had more to do with the scalability of a particular RSVP/TE > > > Curtis> implementation > > > > > > If you are speculating about the reason Cisco uses LDP in support of RFC2547 > > > VPNs, then I can state authoritatively that this has nothing whatsoever to > > > do with any characteristic of any RSVP/TE implementation. > > From owner-mpls@UU.NET Wed Apr 11 15:28:48 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01623 for ; Wed, 11 Apr 2001 15:28:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkif26685; Wed, 11 Apr 2001 19:26:37 GMT Received: by mail-control.mail.uu.net id QQkkif16096 for mpls-outgoing; Wed, 11 Apr 2001 19:26:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkif16074 for ; Wed, 11 Apr 2001 19:25:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkif26329 for ; Wed, 11 Apr 2001 19:24:12 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host200.pluris.com [208.227.9.200]) id QQkkif22607 for ; Wed, 11 Apr 2001 19:24:12 GMT Received: from localhost (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA04643 for ; Wed, 11 Apr 2001 12:24:11 -0700 (PDT) Date: Wed, 11 Apr 2001 12:24:05 -0700 (PDT) From: Bora Akyol To: Subject: OSPF-TE vs ISIS-TE on broadcast media In-Reply-To: <200104111620.JAA20366@kummer.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk OSPF-TE and ISIS-TE drafts treat broadcast interfaces differently when advertising TE TLVs differently. OSPF uses links to the DR whereas ISIS-TE does not specify how these should be handled. This should not cause a huge problem but probably needs to be cleaned up. Bora From owner-mpls@UU.NET Wed Apr 11 17:26:25 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03654 for ; Wed, 11 Apr 2001 17:26:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkin08206; Wed, 11 Apr 2001 21:24:22 GMT Received: by mail-control.mail.uu.net id QQkkin29748 for mpls-outgoing; Wed, 11 Apr 2001 21:23:45 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkin29743 for ; Wed, 11 Apr 2001 21:23:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkin22763 for ; Wed, 11 Apr 2001 21:20:54 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkkin26161 for ; Wed, 11 Apr 2001 21:20:54 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17906 for ; Wed, 11 Apr 2001 17:20:51 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA14410 for ; Wed, 11 Apr 2001 17:20:54 -0400 (EDT) Message-ID: <3AD4CADD.EE6105D9@marconi.com> Date: Wed, 11 Apr 2001 17:21:33 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <3AD4AA97.B9A67685@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit HANSEN CHAN wrote: > > I must have missed something here. Why is LDP requires less > configuration and scale better? LDP doesn't need to be told what the tunnel endpoints are. It can simply look at the local routing table. In Bora's scenario, every router treats its own local addresses as /32 FECs and sends out unsolicited label mappings for these. They propagate to the rest of the MPLS cloud. Now, every router has a label for every address of every MPLS router. A full-mesh of LSPs has set itself up with no manual intervention. If the IGP's border matches the MPLS cloud's border, the edge routers will take unlabeled traffic, lookup the BGP remote next-hop, (which will be the router at the other side of the MPLS cloud), and label the packet with whatever label corresponds to that next-hop. The real nice thing about this is that this label distribution can happen as the IGP is converging. As soon as a router knows how to get to each /32 FEC, it can program its forwarder with the label it received. This can also be done with TE tunnels, but it's not as clean. With TE tunnels, the endpoints must be identified by the ingress nodes. This information can be gotten from BGP (the remote next-hops), but the path to those endpoints can't be determined until the network fully converges. In other words, it will take longer for everything to come up - labels won't be distirbuted until the label requests can get from the ingress nodes to the egress nodes, and that won't happen until the IGP converges. > The BGP explanation below confuses me more. The way I understand is > that BGP is used to setup the inner label. It has nothing to do with > the outer label negotiation by LDP between PEs. With Bora's model, an ingress router uses BGP information to determine what LSP to put traffic onto. Matching a destination address against an FEC is useless, because each FEC is the /32 address of an interface in the MPLS cloud. Traffic not destined for the routers will never match any of these. Instead, BGP is used to determine the egress router, and the FEC corresponding to that router is used to determine the LSP. -- David From owner-mpls@UU.NET Wed Apr 11 18:48:16 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04543 for ; Wed, 11 Apr 2001 18:48:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkit27546; Wed, 11 Apr 2001 22:46:08 GMT Received: by mail-control.mail.uu.net id QQkkit22569 for mpls-outgoing; Wed, 11 Apr 2001 22:45:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkit22564 for ; Wed, 11 Apr 2001 22:45:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkit03415 for ; Wed, 11 Apr 2001 22:45:19 GMT Received: from zrtps06u.us.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) id QQkkit26106 for ; Wed, 11 Apr 2001 22:45:19 GMT Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3BMhtq02772 for ; Wed, 11 Apr 2001 18:43:55 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 11 Apr 2001 18:45:09 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Apr 2001 18:45:09 -0400 Message-ID: From: "Don Fedyk" To: Loa Andersson , Sharma Prem , manoj juneja Cc: mpls@UU.NET Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" Date: Wed, 11 Apr 2001 18:45:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C2D9.0F0213A0" 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_01C0C2D9.0F0213A0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkkit27546 Content-Transfer-Encoding: quoted-printable Loa, Sharma, Manoj: Let me see if I can clarify my position on this. My mail has been backed up lately. Sorry for the delay. > -----Original Message----- > From: Loa Andersson [mailto:loa.andersson@utfors.se] > Sent: Wednesday, April 11, 2001 12:24 PM > To: Sharma Prem > Cc: Fedyk, Don [BL60:2868:EXCH]; manoj juneja; mpls@UU.NET > Subject: Re: Valid Race Condition related to draft > "draft-ietf-mpls-crlsp -modify-03.txt" >=20 >=20 > All, >=20 > Manojs question is valid, and the answers are less than satisfactory. > Actions in case of next hop changes needs to be specified, some are=20 > in the LDP spec, others ae specific for CR-LDP.=20 >=20 > There are some cases (list not complete). >=20 The intent of the CR-LDP modification is to change LSPs that have constraints. (Constraints usually mean that loose routing is a bad idea because the=20 next hop may not satisfy the constraint.)=20 There are also a couple of reasons for modification. One is to get a new constraints the other is to get a new path with the same constraints. A Loose path is a degenerative case of the latter where there are no=20 constraints. In order to prevent race conditions the rules we have used was if the=20 original LSP changes in any way during a modification then the modificati= on was aborted. There is a point when you switchover to the new LSP that=20 changes in the original are irrelevant.=20 So there are three stages of modification. 1. Existing path up. New path request traveling.=20 During this phase should the Existing path change I would suggest=20 aborting the path modification. =20 2. Existing path up. New path mapping backwards.=20 During this phase If a label withdraw from the existing path reaches=20 the ingress of the LSP before the mapping I would again abort the modification. 3. Both paths up. During this stage traffic is atomically switched to the new LSP=20 and the existing path becomes redundant. At this point any change in the originally path is ignored. But if the new path changes due to a=20 label release switching back is not an option.=20 Finally if you were unlucky and you have aborted a modification in 1. or = 2.=20 above start again after a suitable sanity check on the existing path. These are the ways that I would deal with this but these are only suggest= ed. You can create a lot more complexity by specifying attempts to recover fr= om some of the situations. Personally, I would not suggest modify on loose routed paths I would have an option preventing it.=20 That said I don't think that there is a ambiguous race condition if you=20 followed the above rules as long as the implementation used two disjoint=20 paths that are not related to each other. In other words even if a loose path=20 reroutes a loose segment the outer ends are fixed and as long a there is not a release or withdraw to the head end who cares it the internal=20 path changed during a modify. That is why I thought I answered the questions before.=20 > - with loosely routed LSP and a better route is found, because of a > next hop change. In this case I can't see a problem the procedures=20 > are specified in the LDP specification (p 113), assuming that a=20 > loosely routed CR-LSP is roughly equivalent to a DoD ordered LSP=20 > in it lose parts. >=20 > - equipment failure leading to that LDP peering is lost in a loosely=20 > routed part of an LSP. The outstanding Label Request is by > definition > lost. The actions needed here is very similar to what is done in the > situation described above. But this needs to be specified. >=20 CR-LDP explicitly remove the labels when this happens. The behavior here is the same as LDP.=20 > - equipment failure in a strictly routed part of an LSP. My feeling is > that this should be NAKed and responsibility to clear up the=20 > situation should be left to the application requesting the > explicitly > routed LSP. > Question here is what a loosely routed node does when it receives=20 > the NAK? Chances are that the next hop has changed for this node. > Also needs to be specified. Loa you lost me here what are you referring to ? Do you expect a loose=20 segment to stay alive while the explicit part is down ? to what end? Modification is done at the head end only with independent paths. >=20 > Test to this effect should be added to the CR-LDP specification. > Haven't > checked but do we have the same problem for RSVP-TE? Is your comment on the modify draft ? >=20 > BTW, Don's statement that next hop changes do not affect explicitly=20 > routed LSP is only partly true. In some known cases the LSDB is used=20 > to calculate the explicit LSP, the information that lead to next hop > changing will be reflected in the LSDB used to calculate the=20 > explicit route(s). Actually my statement here was correct. The database may change but unles= s the LSP path breaks there is no need move a strict explicit route path. Now you might want to optimize a path after a LSDB change and using=20 the modify is a good way to do this. Sincerely, Don Fedyk=20 Nortel Networks dwfedyk@nortelnetworks.com Ph: 978-288-3041=20 >=20 > /Loa >=20 > --=20 > Loa Andersson > Chief Architect, > Utfors Research, Architecture and Future Lab (URAX) > Utfors AB > R=E5sundav=E4gen 12 > Box 525, 169 29 Solna > Office +46 8 5270 2000 > Office direct +46 8 5270 5038 > Mobile +46 70 848 5038 > Email loa.andersson@utfors.se > WWW www.utfors.se >=20 ------_=_NextPart_001_01C0C2D9.0F0213A0 Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkkit27546 Content-Transfer-Encoding: quoted-printable RE: Valid Race Condition related to draft "draft-ietf-mpls-cr= lsp -modify-03.txt"

Loa, Sharma, Manoj:

Let me see if I can clarify my position on this.
My mail has been backed up lately. Sorry for the delay= .

> -----Original Message-----
> From: Loa Andersson [mailto:loa.andersson@utfors.se]
> Sent: Wednesday, April 11, 2001 12:24 PM
> To: Sharma Prem
> Cc: Fedyk, Don [BL60:2868:EXCH]; manoj juneja; mp= ls@UU.NET
> Subject: Re: Valid Race Condition related to draf= t
> "draft-ietf-mpls-crlsp -modify-03.txt"<= /FONT>
>
>
> All,
>
> Manojs question is valid, and the answers are les= s than satisfactory.
> Actions in case of next hop changes needs to be s= pecified, some are
> in the LDP spec, others ae specific for CR-LDP. <= /FONT>
>
> There are some cases (list not complete).
>
The intent of the CR-LDP modification is to change LSP= s that have constraints.
(Constraints usually mean that loose routing is a bad = idea because the
next hop may not satisfy the constraint.)

There are also a couple of reasons for modification. On= e is to get a
new constraints the other is to get a new path with th= e same constraints.
A Loose path is a degenerative case of the latter wher= e there are no
constraints.

In order to prevent race conditions the rules we have u= sed was if the
original LSP changes in any way during a modification = then the modification
was aborted. There is a point when you switchover to t= he new LSP that
changes in the original are irrelevant.

So there are three stages of modification.

1. Existing path up. New path request traveling.

During this phase should the Existing path change I wou= ld suggest
aborting the path modification.
 
2. Existing path up. New path mapping backwards.

During this phase If a label withdraw from the existing= path reaches
the ingress of the LSP before the mapping I would agai= n abort the modification.

3. Both paths up.
During this stage traffic is atomically switched to th= e new LSP
and the existing path becomes redundant. At this point= any change in
the originally path is ignored. But if the new path ch= anges due to a
label release switching back is not an option.

Finally if you were unlucky and you have aborted a modi= fication in 1. or 2.
above start again after a suitable sanity check on the= existing path.

These are the ways that I would deal with this but thes= e are only suggested.
You can create a lot more complexity by specifying att= empts to recover from
some of the situations. Personally, I would not sugges= t modify on loose
routed paths I would have an option preventing it.

That said I don't think that there is a ambiguous race = condition if you
followed the above rules as long as the implementation= used two disjoint
paths that are not related to each other. In other wor= ds even if a loose path
reroutes a loose segment the outer ends are fixed and = as long a there
is not a release or withdraw to the head end who cares= it the internal
path changed during a modify.

That is why I thought I answered the questions before. =

> - with loosely routed LSP and a better route is fo= und, because of a
>   next hop change. In this case I can't= see a problem the procedures
>   are  specified in the LDP specif= ication (p 113), assuming that a
>   loosely routed  CR-LSP is roughl= y equivalent  to a DoD ordered LSP
>   in it lose parts.
>
> - equipment failure leading to that LDP peering i= s lost in a loosely
>   routed part of an LSP. The outstandin= g Label Request is by
> definition
>   lost. The actions needed here is very= similar to what is done in the
>   situation described above. But this n= eeds to be specified.
>
CR-LDP explicitly remove the labels when this happens.= The behavior here
is the same as LDP.

> - equipment failure in a strictly routed part of a= n LSP. My feeling is
>   that this should be NAKed and respons= ibility to clear up the
>   situation should be left to the appli= cation requesting the
> explicitly
>   routed LSP.
>   Question here is what a loosely route= d node does when it receives
>   the NAK? Chances are that the next ho= p has changed for this node.
>   Also needs to be specified.

Loa you lost me here what are you referring to ? Do you= expect a loose
segment to stay alive while the explicit part is down = ? to what end?
Modification is done at the head end only with indepen= dent paths.

>
> Test to this effect should be added to the CR-LDP= specification.
> Haven't
> checked but do we have the same problem for RSVP-= TE?

Is your comment on the modify draft ?

>
> BTW, Don's statement that next hop changes do not= affect explicitly
> routed LSP is only partly true. In some known cas= es the LSDB is used
> to calculate the explicit LSP, the information th= at lead to next hop
> changing will be reflected in the LSDB used to ca= lculate the
> explicit route(s).

Actually my statement here was correct. The database ma= y change but unless
the LSP path breaks there is no need move a strict exp= licit route path.
Now you might want to optimize a path after a LSDB cha= nge and using
the modify is a good way to do this.


Sincerely,
Don Fedyk
Nortel Networks
dwfedyk@nortelnetworks.com
Ph: 978-288-3041


>
> /Loa
>
> --
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URA= X)
> Utfors AB
> R=E5sundav=E4gen 12
> Box 525, 169 29 Solna
> Office       &= nbsp;  +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile       &= nbsp;  +46 70 848 5038
> Email       &n= bsp;   loa.andersson@utfors.se
> WWW       &nbs= p;     www.utfors.se
>

------_=_NextPart_001_01C0C2D9.0F0213A0-- From owner-mpls@UU.NET Thu Apr 12 07:42:50 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26821 for ; Thu, 12 Apr 2001 07:42:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkks01235; Thu, 12 Apr 2001 11:40:29 GMT Received: by mail-control.mail.uu.net id QQkkks18954 for mpls-outgoing; Thu, 12 Apr 2001 11:39:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkks18949 for ; Thu, 12 Apr 2001 11:39:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkks11549 for ; Thu, 12 Apr 2001 11:39:26 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQkkks29438 for ; Thu, 12 Apr 2001 11:39:26 GMT Received: from zcard00n.ca.nortel.com by zcars04e.nortelnetworks.com; Thu, 12 Apr 2001 07:38:24 -0400 Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2RM9G2VA; Thu, 12 Apr 2001 07:38:25 -0400 Received: from americasm01.nt.com (philipma-1.ca.nortel.com [47.129.70.233]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2FLVVLBV; Thu, 12 Apr 2001 07:38:26 -0400 Message-ID: <3AD51303.1047B147@americasm01.nt.com> Date: Wed, 11 Apr 2001 22:29:23 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: mpls@UU.NET Subject: Re: LDP remote peer question References: <3ACCE057.2C4A2C27@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David: I don't see how one can support targetted LDP sessions without using a platform-wide label space, unless you can ensure that the packets only arrive on one interface. If you have hardware restrictions (for example, ATM hardware) that begs for interface-specific labels, then one solution might be to reserve a small portion of the range and allocate it in a platform-wide manner. - Philip David Charlap wrote: > > I've a question regarding remote peers and the LDP protocol. > > Remote peers are managed using unicast UDP messages for Hello and TCP > session. These peers are not (I think) bound to an interface. Which > means that if the local routing table should change, then the interface > associated with the remote peer may also change. > > If per-platform label spaces are used, this is not a problem. > > On routers with per-interface label spaces, however, this might be a > real problem. Once the TCP socket moves to a different interface, all > of its labels must also move. This may not be possible, since there may > be conflicting label assignments on the new interface. But to release > all of the remote peer's labels before the move, and then re-request > them afterwards is a lot of overhead. And it will cause service > interruptions during this reconvergence period. > > Is this correct? Is there a solution to this problem? > > Obviously, the best way is to implement per-platform label spaces, but > this is may not be possible (or efficient) on all hardware platforms. > > -- David From owner-mpls@UU.NET Thu Apr 12 07:44:31 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26845 for ; Thu, 12 Apr 2001 07:44:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkks27261; Thu, 12 Apr 2001 11:42:06 GMT Received: by mail-control.mail.uu.net id QQkkks19134 for mpls-outgoing; Thu, 12 Apr 2001 11:41:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkks18971 for ; Thu, 12 Apr 2001 11:40:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkks19492 for ; Thu, 12 Apr 2001 11:38:54 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQkkks14472 for ; Thu, 12 Apr 2001 11:38:54 GMT Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 12 Apr 2001 07:38:23 -0400 Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2M6K54PV; Thu, 12 Apr 2001 07:38:22 -0400 Received: from americasm01.nt.com (philipma-1.ca.nortel.com [47.129.70.233]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2FLVVLBT; Thu, 12 Apr 2001 07:38:25 -0400 Message-ID: <3AD50F25.5AB3E0DC@americasm01.nt.com> Date: Wed, 11 Apr 2001 22:12:53 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jack Shaio CC: Eric Gray , Paul Brittain , Adrian Farrel , mpls@UU.NET Subject: Re: Last Call on LDP Fault Tolerance References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jack: My original FT proposal draft-matthews-mpls-ldp-ibb-00.txt required all labels to be fault-tolerant. As you state, the procedures were indeed a bit simpler. But when we produced a combined draft, my co-authors wanted the ability to make some labels FT and other not FT. They argued that some LSPs would be more important than other LSPs, and people might want to protect only the important LSPs. Hence the procedures in the draft today. I do _not_ think we should go back and revisit this decision now. It would reset the entire effort back to square one, and I think it is way too late for this now. - Philip Jack Shaio wrote: > > hi Adrian, > > I had one comment regarding the LDP fault tolerance draft. > > This draft makes fault tolerance (ft) a property of an individual label > rather than a property of the LDP session and requires special care for > all LDP messages that affect ft labels. > > However, these procedures simplify if instead all the labels in an > ft LDP session were fault tolerant. One can have 2 parallel LDP sessions > if needed to allow for a mix of fault tolerant and non-fault tolerant > labels to an LDP peer. > > If all labels of an ft session are fault tolerant, then you can keep the > FT Protection, FT Ack and FT sequence numbers as in the draft, but each > LDP peer sends both TLV's in LDP KeepAlives. An FT Ack means that the > FT Protection TLV with that FT sequence has been saved by the LDP peer, > and because of the underlying TCP transport, also all earlier LDP > messages. > > In case the TCP session is lost, as in a card failure, the ft LDP session > only needs to preserve all the LDP messages sent since the last acked > FT Protection TLV, and replay them when reconnected (when the FT session > reconnect flag is set). > > This simply makes the TCP failure transparent and exchanges all LDP > messages that would have been sent had that session not been lost, without > modifying the message processing for LDP or CR-LDP. > > Changes in topology or label withdraws are handled after the replay > is complete, much as if, for example, they had occured while waiting > for TCP to retransmit after a lost frame. > > --jack From owner-mpls@UU.NET Thu Apr 12 08:13:53 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27496 for ; Thu, 12 Apr 2001 08:13:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkku22186; Thu, 12 Apr 2001 12:11:55 GMT Received: by mail-control.mail.uu.net id QQkkku08348 for mpls-outgoing; Thu, 12 Apr 2001 12:11:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkku08299 for ; Thu, 12 Apr 2001 12:11:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkku00052 for ; Thu, 12 Apr 2001 12:10:06 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkku19495 for ; Thu, 12 Apr 2001 12:10:05 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA23519 for mpls@uu.net; Thu, 12 Apr 2001 08:10:05 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkku08210 for ; Thu, 12 Apr 2001 12:09:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkku10959 for ; Thu, 12 Apr 2001 12:09:20 GMT Received: from ns02.newbridge.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: ns02.newbridge.com [192.75.23.75]) id QQkkku05538 for ; Thu, 12 Apr 2001 12:09:20 GMT Received: (qmail 24074 invoked from network); 12 Apr 2001 12:07:31 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 12 Apr 2001 12:07:31 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Thu, 12 Apr 2001 08:08:28 -0400 Received: from alcatel.com ([138.120.51.119]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA3E04 for ; Thu, 12 Apr 2001 08:08:27 -0400 Message-Id: <3AD59A7D.D6020942@alcatel.com> Date: Thu, 12 Apr 2001 08:07:25 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <3AD4AA97.B9A67685@alcatel.com> <3AD4CADD.EE6105D9@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dave, > In Bora's scenario, every router treats its own local addresses as /32 > FECs and sends out unsolicited label mappings for these. They propagate > to the rest of the MPLS cloud. Now, every router has a label for every > address of every MPLS router. A full-mesh of LSPs has set itself up > with no manual intervention. Your explanation is interesting. In other word, the full-mesh of LSP is topology-driven. I thought the idea of topology-driven is abandonned. Is topology-driven the actual way used to establish those PE-to-PE LSPs in real implementation or real network today? Cheers, Hansen From owner-mpls@UU.NET Thu Apr 12 09:10:17 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28967 for ; Thu, 12 Apr 2001 09:10:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkky08953; Thu, 12 Apr 2001 13:07:53 GMT Received: by mail-control.mail.uu.net id QQkkky22163 for mpls-outgoing; Thu, 12 Apr 2001 13:07:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkky22144 for ; Thu, 12 Apr 2001 13:06:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkky19993 for ; Thu, 12 Apr 2001 13:06:16 GMT Received: from malmo.trab.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQkkky06085 for ; Thu, 12 Apr 2001 13:06:16 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f3CD5wu27947; Thu, 12 Apr 2001 15:05:59 +0200 (MEST) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Thu, 12 Apr 2001 15:05:57 +0200 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D022543FD@trab-hermes.haninge.trab.se> From: Nhat Thanh Hoang To: "'HANSEN CHAN'" , mpls@UU.NET Subject: RE: Use of LDP for VPNs Date: Thu, 12 Apr 2001 15:05:57 +0200 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 Hej, Hansen I'm quite sure that most of the BGP/MPLS VPNs that are deployed in operators' networks todays, have implemeted topology-driven PE-to-PE LSPs, at least in Europe. /Nhat Thanh Telia Reserach AB -----Original Message----- From: HANSEN CHAN [mailto:hansen.chan@alcatel.com] Sent: den 12 april 2001 14:07 To: mpls@UU.NET Subject: Re: Use of LDP for VPNs Dave, > In Bora's scenario, every router treats its own local addresses as /32 > FECs and sends out unsolicited label mappings for these. They propagate > to the rest of the MPLS cloud. Now, every router has a label for every > address of every MPLS router. A full-mesh of LSPs has set itself up > with no manual intervention. Your explanation is interesting. In other word, the full-mesh of LSP is topology-driven. I thought the idea of topology-driven is abandonned. Is topology-driven the actual way used to establish those PE-to-PE LSPs in real implementation or real network today? Cheers, Hansen From owner-mpls@UU.NET Thu Apr 12 09:15:11 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29079 for ; Thu, 12 Apr 2001 09:15:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkky18081; Thu, 12 Apr 2001 13:13:04 GMT Received: by mail-control.mail.uu.net id QQkkky29470 for mpls-outgoing; Thu, 12 Apr 2001 13:12:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkky29370 for ; Thu, 12 Apr 2001 13:12:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkky20738 for ; Thu, 12 Apr 2001 13:11:04 GMT Received: from ntexgswp02.DMZ by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.kpnqwest.com [193.242.92.8]) id QQkkky22723 for ; Thu, 12 Apr 2001 13:11:04 GMT Received: from ntexghub01.kpnqwest.com (unverified) by ntexgswp02.DMZ (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 12 Apr 2001 15:14:44 +0200 Received: by ntexghub01 with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Apr 2001 15:07:04 +0200 Message-ID: <3F3B952383E8D311A9FC0008C7E61402027A05C9@ntexgdhg02> From: "Metz, Eduard" To: "'HANSEN CHAN'" Cc: mpls@UU.NET Subject: RE: Use of LDP for VPNs Date: Thu, 12 Apr 2001 15:10:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Yes, in most cases there is no need for contraint routed paths. In these cases I do not see the point of (potentially manually) creating LSP through RSVP/TE or CR-LDP between PEs, when LDP does this automatically. Contraint routed LSPs only add to operational complexity here (maintaining LSPs, adding PEs), with no further added value ... cheers, Eduard > -----Original Message----- > From: HANSEN CHAN [mailto:hansen.chan@alcatel.com] > Sent: 12 April 2001 14:07 > To: mpls@UU.NET > Subject: Re: Use of LDP for VPNs > > > Dave, > > > In Bora's scenario, every router treats its own local > addresses as /32 > > FECs and sends out unsolicited label mappings for these. > They propagate > > to the rest of the MPLS cloud. Now, every router has a > label for every > > address of every MPLS router. A full-mesh of LSPs has set itself up > > with no manual intervention. > > Your explanation is interesting. In other word, the full-mesh > of LSP is > topology-driven. I thought the idea of topology-driven is abandonned. > > Is topology-driven the actual way used to establish those > PE-to-PE LSPs in > real implementation or real network today? > > Cheers, > Hansen > > From owner-mpls@UU.NET Thu Apr 12 10:05:38 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00589 for ; Thu, 12 Apr 2001 10:05:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkklc13946; Thu, 12 Apr 2001 14:03:14 GMT Received: by mail-control.mail.uu.net id QQkklc07013 for mpls-outgoing; Thu, 12 Apr 2001 14:02:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkklc06978 for ; Thu, 12 Apr 2001 14:02:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkklc19543 for ; Thu, 12 Apr 2001 14:02:17 GMT Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQkklc12956 for ; Thu, 12 Apr 2001 14:02:16 GMT Received: from tomp.smb.utfors.se ([127.0.0.1]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GBON3D00.V6U; Thu, 12 Apr 2001 16:04:25 +0200 From: "Loa Andersson" To: "Don Fedyk" Cc: Sharma Prem , manoj juneja , mpls@UU.NET Message-ID: <47edd4313d.4313d47edd@tomp.smb.utfors.se> Date: Thu, 12 Apr 2001 16:04:24 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA00589 Don, do I understand you correctly that the draft is applicable only in the situation where you have a strictly routed LSP ingress to egress? If so I rest my case, but I also fail to see why we need the draft. Just "locally" set up your alternate paths, signal that the traffic will be sent on the new path, switch over the traffic and tear the old path down. Nothing modificational (is ther such a word?) about it. /Loa ----- Original Message ----- > Loa, Sharma, Manoj: > > Let me see if I can clarify my position on this. > My mail has been backed up lately. Sorry for the delay. > > -- > > Loa Andersson > > Chief Architect, > > Utfors Research, Architecture and Future Lab (URAX) > > Utfors AB > > Råsundavägen 12 > > Box 525, 169 29 Solna > > Office +46 8 5270 2000 > > Office direct +46 8 5270 5038 > > Mobile +46 70 848 5038 > > Email loa.andersson@utfors.se > > WWW www.utfors.se > > > From owner-mpls@UU.NET Thu Apr 12 10:17:24 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01046 for ; Thu, 12 Apr 2001 10:17:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkld25947; Thu, 12 Apr 2001 14:15:06 GMT Received: by mail-control.mail.uu.net id QQkklc20636 for mpls-outgoing; Thu, 12 Apr 2001 14:14:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkklc20621 for ; Thu, 12 Apr 2001 14:14:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkklc09536 for ; Thu, 12 Apr 2001 14:13:33 GMT Received: from malmo.trab.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQkklc13199 for ; Thu, 12 Apr 2001 14:13:33 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f3CEDLu18762; Thu, 12 Apr 2001 16:13:22 +0200 (MEST) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Thu, 12 Apr 2001 16:13:21 +0200 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D022543FF@trab-hermes.haninge.trab.se> From: Nhat Thanh Hoang To: "'Metz, Eduard'" , "'HANSEN CHAN'" Cc: mpls@UU.NET Subject: RE: Use of LDP for VPNs Date: Thu, 12 Apr 2001 16:13:20 +0200 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 Hi, Eduard In a simple VPN topology, RSVP-TE and CR-LDP between PEs might be good enough to provide traffic engineering, path protection and tunneling mechanism for building a reliable MPLS-VPN. In a complex and large number of PEs, RSVP-TE and CR-LDP between PEs is too messy thereby hard to manage and not scalable. A good management tool can mitigate these problems, I think. Today, RSVP-TE and CR-LDP can never replace LDP and vice versa. Cheers, /Nhat Thanh -----Original Message----- From: Metz, Eduard [mailto:Eduard.Metz@KPNQwest.com] Sent: den 12 april 2001 15:10 To: 'HANSEN CHAN' Cc: mpls@UU.NET Subject: RE: Use of LDP for VPNs Yes, in most cases there is no need for contraint routed paths. In these cases I do not see the point of (potentially manually) creating LSP through RSVP/TE or CR-LDP between PEs, when LDP does this automatically. Contraint routed LSPs only add to operational complexity here (maintaining LSPs, adding PEs), with no further added value ... cheers, Eduard > -----Original Message----- > From: HANSEN CHAN [mailto:hansen.chan@alcatel.com] > Sent: 12 April 2001 14:07 > To: mpls@UU.NET > Subject: Re: Use of LDP for VPNs > > > Dave, > > > In Bora's scenario, every router treats its own local > addresses as /32 > > FECs and sends out unsolicited label mappings for these. > They propagate > > to the rest of the MPLS cloud. Now, every router has a > label for every > > address of every MPLS router. A full-mesh of LSPs has set itself up > > with no manual intervention. > > Your explanation is interesting. In other word, the full-mesh > of LSP is > topology-driven. I thought the idea of topology-driven is abandonned. > > Is topology-driven the actual way used to establish those > PE-to-PE LSPs in > real implementation or real network today? > > Cheers, > Hansen > > From owner-mpls@UU.NET Thu Apr 12 10:43:47 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01742 for ; Thu, 12 Apr 2001 10:43:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkle04840; Thu, 12 Apr 2001 14:41:20 GMT Received: by mail-control.mail.uu.net id QQkkle23283 for mpls-outgoing; Thu, 12 Apr 2001 14:40:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkle23275 for ; Thu, 12 Apr 2001 14:40:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkle07156 for ; Thu, 12 Apr 2001 14:39:32 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkkle22947 for ; Thu, 12 Apr 2001 14:39:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23351 for ; Thu, 12 Apr 2001 10:39:29 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16832 for ; Thu, 12 Apr 2001 10:39:31 -0400 (EDT) Message-ID: <3AD5BE4D.DA7B00DE@marconi.com> Date: Thu, 12 Apr 2001 10:40:13 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <778DFE9B4E3BD111A74E08002BA3DC0D022543FF@trab-hermes.haninge.trab.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nhat Thanh Hoang wrote: > > In a simple VPN topology, RSVP-TE and CR-LDP between PEs might be > good enough to provide traffic engineering, path protection and > tunneling mechanism for building a reliable MPLS-VPN. In a complex > and large number of PEs, RSVP-TE and CR-LDP between PEs is too messy > thereby hard to manage and not scalable. A good management tool can > mitigate these problems, I think. CR-LDP and RSVP-TE do not mandate the use of explicit route objects. If they are not used, then the LSP setup follows the routing table, just like LDP. The only difference being that the ingress nodes must know the endpoints of the LSPs. This overhead is rather minor, since the addresses of the endpoints can be fetched directly from routing protocols (like BGP). LDP is no different on systems where unsolicited label distribution is not configured. Unsolicited operation makes things setup faster, but it doesn't really affect the overall complexity of the network. IMO, it makes things more complex for transit and egress routers. ERO computation only adds complexity to ingress routers. -- David From owner-mpls@UU.NET Thu Apr 12 10:53:25 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01960 for ; Thu, 12 Apr 2001 10:53:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkklf14387; Thu, 12 Apr 2001 14:50:52 GMT Received: by mail-control.mail.uu.net id QQkklf24811 for mpls-outgoing; Thu, 12 Apr 2001 14:50:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkklf24791 for ; Thu, 12 Apr 2001 14:50:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkklf24629 for ; Thu, 12 Apr 2001 14:48:45 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkklf12561 for ; Thu, 12 Apr 2001 14:48:45 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 HAA05290; Thu, 12 Apr 2001 07:48:48 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA09621; Thu, 12 Apr 2001 10:48:39 -0400 (EDT) Message-Id: <200104121448.KAA09621@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: David Charlap cc: mpls@UU.NET Subject: Re: Use of LDP for VPNs In-reply-to: Your message of Thu, 12 Apr 2001 10:40:13 -0400. <3AD5BE4D.DA7B00DE@marconi.com> 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, 12 Apr 2001 10:48:38 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk David> CR-LDP and RSVP-TE do not mandate the use of explicit route objects. David> If they are not used, then the LSP setup follows the routing table, David> just like LDP. The only difference being that the ingress nodes must David> know the endpoints of the LSPs. I believe that RSVP-TE will only set up point-to-point LSPs, whereas LDP sets up multipoint-to-point LSPs. The difference in state at the transit nodes would thus seem to be considerable. David> Unsolicited operation makes things setup faster, but it doesn't David> really affect the overall complexity of the network. IMO, it makes David> things more complex for transit and egress routers. The notion that a router should set up routes automatically, without waiting for path setup signalling, is not exactly a novel notion in IP networks. From owner-mpls@UU.NET Thu Apr 12 10:58:28 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02114 for ; Thu, 12 Apr 2001 10:58:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkklf29947; Thu, 12 Apr 2001 14:56:05 GMT Received: by mail-control.mail.uu.net id QQkklf25419 for mpls-outgoing; Thu, 12 Apr 2001 14:55:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkklf25405 for ; Thu, 12 Apr 2001 14:55:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkklf25935 for ; Thu, 12 Apr 2001 14:54:58 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkklf27952 for ; Thu, 12 Apr 2001 14:54:58 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 5FBB694006; Thu, 12 Apr 2001 10:54:54 -0400 (EDT) Message-ID: <3AD5C1BE.1BC354E9@sandburst.com> Date: Thu, 12 Apr 2001 10:54:54 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <778DFE9B4E3BD111A74E08002BA3DC0D022543FF@trab-hermes.haninge.trab.se> <3AD5BE4D.DA7B00DE@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, With respect to the differences between LDP and CR-LDP, your analysis is accurate, but slightly misleading. CR-LDP, if used with a /32 FEC and no ERO _is_ LDP with ordered control and downstream on demand (unless you are also using traffic parameters - which is not practical without ERO). Thus, the observation that "LDP is no different" is unsurprising. :-) -- Eric Gray You wrote: > Nhat Thanh Hoang wrote: > > > > In a simple VPN topology, RSVP-TE and CR-LDP between PEs might be > > good enough to provide traffic engineering, path protection and > > tunneling mechanism for building a reliable MPLS-VPN. In a complex > > and large number of PEs, RSVP-TE and CR-LDP between PEs is too messy > > thereby hard to manage and not scalable. A good management tool can > > mitigate these problems, I think. > > CR-LDP and RSVP-TE do not mandate the use of explicit route objects. If > they are not used, then the LSP setup follows the routing table, just > like LDP. The only difference being that the ingress nodes must know > the endpoints of the LSPs. This overhead is rather minor, since the > addresses of the endpoints can be fetched directly from routing > protocols (like BGP). > > LDP is no different on systems where unsolicited label distribution is > not configured. > > Unsolicited operation makes things setup faster, but it doesn't really > affect the overall complexity of the network. IMO, it makes things more > complex for transit and egress routers. ERO computation only adds > complexity to ingress routers. > > -- David From owner-mpls@UU.NET Thu Apr 12 11:00:54 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02171 for ; Thu, 12 Apr 2001 11:00:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkklf22098; Thu, 12 Apr 2001 14:59:34 GMT Received: by mail-control.mail.uu.net id QQkklf25785 for mpls-outgoing; Thu, 12 Apr 2001 14:59:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkklf25759 for ; Thu, 12 Apr 2001 14:58:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkklf14903 for ; Thu, 12 Apr 2001 14:58:22 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkklf12855 for ; Thu, 12 Apr 2001 14:58:21 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25466 for ; Thu, 12 Apr 2001 10:58:18 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22195 for ; Thu, 12 Apr 2001 10:58:21 -0400 (EDT) Message-ID: <3AD5C2B6.2268BD31@marconi.com> Date: Thu, 12 Apr 2001 10:59:02 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Use of LDP for VPNs References: <200104121448.KAA09621@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 Rosen wrote: >> >> CR-LDP and RSVP-TE do not mandate the use of explicit route >> objects. If they are not used, then the LSP setup follows the >> routing table, just like LDP. The only difference being that the >> ingress nodes must know the endpoints of the LSPs. > > I believe that RSVP-TE will only set up point-to-point LSPs, whereas > LDP sets up multipoint-to-point LSPs. The difference in state at > the transit nodes would thus seem to be considerable. RSVP-TE can do multipoint-to-point. If the extended tunnel ID is zero, then all senders using the same endpoint and tunnel ID will be in the same session. If SE style reservations are used, all paths in the session (from the ingress routers to the egress router) will share resources. A router that is capable of label-merging can choose to send the same label to all previous-hop routers in the session, effectively combining two (or more) RSVP paths into a single LSP. -- David From owner-mpls@UU.NET Thu Apr 12 12:43:54 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04398 for ; Thu, 12 Apr 2001 12:43:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkklm09268; Thu, 12 Apr 2001 16:40:58 GMT Received: by mail-control.mail.uu.net id QQkklm09877 for mpls-outgoing; Thu, 12 Apr 2001 16:40:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkklm09858 for ; Thu, 12 Apr 2001 16:40:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkklm27757 for ; Thu, 12 Apr 2001 16:39:29 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkklm08945 for ; Thu, 12 Apr 2001 16:39:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA17579 for mpls@uu.net; Thu, 12 Apr 2001 12:39:28 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkklm09779 for ; Thu, 12 Apr 2001 16:38:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkklm21984 for ; Thu, 12 Apr 2001 16:37:36 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkklm07389 for ; Thu, 12 Apr 2001 16:37:35 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA29851; Thu, 12 Apr 2001 09:37:34 -0700 (PDT) Message-ID: <3AD5D9C8.760EFE64@juniper.net> Date: Thu, 12 Apr 2001 09:37:29 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls-list , ccamp-list Subject: [Fwd: I-D ACTION:draft-gan-fast-reroute-00.txt] Content-Type: multipart/mixed; boundary="------------5BB6FEDF1DBCD70B748BA81F" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------5BB6FEDF1DBCD70B748BA81F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This is the LSP restoration mechanism that Juniper have developed and deployed. One of the main advantage is that the backup tunnels can be initiated at head-end routers, thus there is no manual configuration at intermediate routers. We have proposed two RSVP objects that are backward compatible. Also since the detour paths are individually established, there is no need to force labels to be globally assigned at neighboring routers. Please provide comments. Thanks! -- Ping Pan --------------5BB6FEDF1DBCD70B748BA81F Content-Type: message/rfc822 Content-Disposition: inline Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by orion.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA11517; Thu, 12 Apr 2001 08:12:11 -0400 (EDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA04159; Thu, 12 Apr 2001 08:12:10 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA08106 for ietf-123-outbound.06@ietf.org; Thu, 12 Apr 2001 07:25:00 -0400 (EDT) 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 HAA07914 for ; Thu, 12 Apr 2001 07:05:43 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25934 for ; Thu, 12 Apr 2001 07:05:43 -0400 (EDT) Message-Id: <200104121105.HAA25934@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-gan-fast-reroute-00.txt Date: Thu, 12 Apr 2001 07:05:43 -0400 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 : A Method for MPLS LSP Fast-Reroute Using RSVP Detours Author(s) : D. Gan, P. Pan, A. Ayyangar, K. Kompella Filename : draft-gan-fast-reroute-00.txt Pages : 12 Date : 11-Apr-01 In this document, we introduce a method to establish backup LSP tunnels in large-scale networks. Two additional RSVP objects are proposed. These objects together make possible for routers using RSVP to create detours that can route around downstream links and nodes. As a result, an LSP can quickly and automatically repair itself, while redirecting the user traffic to the pre-computed and pre- established detour routes in event of network link and node failures. Packet loss is therefore minimized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gan-fast-reroute-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-gan-fast-reroute-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-gan-fast-reroute-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: <20010411124325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gan-fast-reroute-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-gan-fast-reroute-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010411124325.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------5BB6FEDF1DBCD70B748BA81F-- From owner-mpls@UU.NET Thu Apr 12 13:03:50 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04927 for ; Thu, 12 Apr 2001 13:03:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkklo27433; Thu, 12 Apr 2001 17:01:15 GMT Received: by mail-control.mail.uu.net id QQkklo14108 for mpls-outgoing; Thu, 12 Apr 2001 17:00:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkklo13864 for ; Thu, 12 Apr 2001 17:00:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkklo01306 for ; Thu, 12 Apr 2001 17:00:14 GMT From: wesam.alanqar@mail.sprint.com Received: from kcmgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker1.sprint.com [208.18.122.165]) id QQkklo20280 for ; Thu, 12 Apr 2001 17:00:13 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f3CGxt411665; Thu, 12 Apr 2001 11:59:55 -0500 (CDT) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f3CGxsQ16006; Thu, 12 Apr 2001 11:59:54 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id LAA04699; Thu, 12 Apr 2001 11:22:48 -0500 (CDT) X-OpenMail-Hops: 1 Date: Thu, 12 Apr 2001 11:22:47 -0500 Message-Id: Subject: Clarifications on EERO-draft-akyol-mpls-exp-ero-00 MIME-Version: 1.0 TO: akyol@akyol.org, akyol@pluris.com CC: mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-201bd82f-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-201bd82f-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Thu, 12 Apr 2001 11:22:47 -0500" Content-Transfer-Encoding: 8bit Hi Bora, In the last IETF, you presented your draft "draft-akyol-mpls-exp-ero-00" In the presentation, you mentioned the following: 1|---------|2 3|---------| ---------|2 2 2 1 |---------|2 2 2 2 | |-------- | |-------- | ERO1: {1,2} ERO2: {1,2,3} EERO: { {1,2.2.2.1,2},{3,2.2.2.2,}} Result: Clarity in definition and processing of the ERO for both numbered and unnumbered interfaces. What EERO is trying to achieve? Can you clarify on the following points mentioned in your presentation? -Uniqueness of interface identifiers for unnumbered interfaces -No abstract node lookup for most common EROs. -Easy to establish a common specification of EROs across multiple vendor implementations. As far as I know, your comments on the router_ID were included in the un-numbered drafts. Any relation between this and your draft? Thanks. ---------------------------------------------------- Wesam Alanqar Member of Technical Staff Technology Research Group (TR) Technology Planning & Integration Dept. (TP&I) Sprint 9300 Metcalf Avenue, KS 66212 Phone: 913-534-5623 Work, Fax: 913-534-3485 ---------------------------------------------------- --openmail-part-201bd82f-00000001-- From owner-mpls@UU.NET Thu Apr 12 15:38:30 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08655 for ; Thu, 12 Apr 2001 15:38:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkly16398; Thu, 12 Apr 2001 19:35:46 GMT Received: by mail-control.mail.uu.net id QQkkly14810 for mpls-outgoing; Thu, 12 Apr 2001 19:35:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkly14789 for ; Thu, 12 Apr 2001 19:34:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkly06427 for ; Thu, 12 Apr 2001 19:34:09 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkkly14602 for ; Thu, 12 Apr 2001 19:34:08 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA22568; Thu, 12 Apr 2001 15:33:47 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104121933.PAA22568@workhorse.fictitious.org> To: dhg@juniper.net, pingpan@juniper.net, arthi@juniper.net, kireeti@juniper.net cc: curtis@avici.com, mpls@UU.NET, ccamp@ops.ietf.org Reply-To: curtis@avici.com Subject: draft-gan-fast-reroute-00.txt Date: Thu, 12 Apr 2001 15:33:47 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk Der-Hwa, Ping, Arthi, Kireeti, Please consider merging this capability with the bandwdith sharing capability described in draft-kini-*. This would allow the bandwidth on backup paths to be shared where possible. See additional comments on this below. Comments mixed with some text from your draft. Curtis > 3.2 DETOUR Object > > DETOUR Object > > Class = 63 (to conform 0bbbbbbb format for compatibility) > C-Type = 7 > > 0 1 2 3 > +-------------+-------------+-------------+-------------+ > | Length (bytes) | Class-Num | C-Type | > +-------------+-------------+-------------+-------------+ > | Source ID | > +-------------+-------------+-------------+-------------+ > | Downstream Node ID | > +-------------+-------------+-------------+-------------+ > > > Source ID > > IPv4 address identifying the beginning point of detour. > Any address on the branching node can be used. > > Downstream Node ID > > IP address identifying the downstream node that source > is trying to avoid. Router ID of downstream node is preferred. This seems to assume node disjoint paths. A more general approach would be to provide a list of SRLG that the detour need to avoid. A special case is one where an SRLG contains all links terminated at a given node, which covers the node disjoint case above. Another special case is link disjoint, in which the link is the only member of an SRLG. One would use this if it was thought that the nodes were sufficiently reliable but the links were not. It should be fine to provide a object that names a specific node as a special case of the detour object, and may be (is) needed to accommodate existing code. It might be useful to have a form of the detour object that covered the link disjoint special case. There should also be a form of the detour object that allows the more general list of SRLG. SRLG should also be considered in the "Detour Path Computation Algorithm" section. Note that the draft does not say what intermediate nodes are supposed to do with the "Downstream Node ID". I can see that one potential use would be in allowing loose hops in the backup path or hops across areas where incomplete topology information is exchanged and constraints must be provided. Another potential use that was discussed on the MPLS mailing list a very long time ago was to put the link, node, or SRLG that you were trying to protect in an object in the backup path, and use that information to determine if bandwidth could be shared. If you also can flood information about the bandwidth being used for backup and what SRLG are being backed up, this is referred to as "having complete information" in the papers listed below. Lakshman, T.V., Kodialam, M., "Dynamic Routing of Bandwidth Guaranteed Tunnels with Restoration", Proceedings of INFOCOM 2000, April 2000. Lakshman, T.V., Kodialam, M., "Dynamic Routing of Bandwidth Guaranteed Tunnels Using Aggregated Link Usage Information", To be published in Proceedings of INFOCOM 2001. The draft-kini-* simply provides a means to exchange the information described in the above papers, draft-kini-restoration-shared-backup-00 providing the overview of the technique and the other providing the TLVs needed for isis, ospf, and objects needed for rsvp. The approach in draft-kini-* provides for limited flooding that is capable of bandwidth sharing for backup tunnels almost as efficiently as having complete information. > 6 Intellectual Property Considerations > > Juniper Networks, Inc. is seeking patent protection on technology > described in this Internet-Draft. If technology in this Internet- > Draft is adopted as a standard, Juniper Networks agrees to license, > on reasonable and non-discriminatory terms, any patent rights it > obtains covering such technology to the extent necessary to comply > with the standard. Could you please point out exactly what you think is new and unique about this proposal? From owner-mpls@UU.NET Thu Apr 12 17:13:22 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11152 for ; Thu, 12 Apr 2001 17:13:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkme22731; Thu, 12 Apr 2001 21:11:01 GMT Received: by mail-control.mail.uu.net id QQkkme22576 for mpls-outgoing; Thu, 12 Apr 2001 21:10:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkme22104 for ; Thu, 12 Apr 2001 21:10:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkme06777 for ; Thu, 12 Apr 2001 21:09:12 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkme21180 for ; Thu, 12 Apr 2001 21:09:11 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA11269 for mpls@uu.net; Thu, 12 Apr 2001 17:09:11 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkme20510 for ; Thu, 12 Apr 2001 21:08:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkme02559 for ; Thu, 12 Apr 2001 21:07:21 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkkme27447 for ; Thu, 12 Apr 2001 21:07:21 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA21008; Thu, 12 Apr 2001 14:07:12 -0700 (PDT) Message-ID: <3AD618F9.56BC0655@juniper.net> Date: Thu, 12 Apr 2001 14:07:05 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: dhg@juniper.net, arthi@juniper.net, kireeti@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: draft-gan-fast-reroute-00.txt References: <200104121933.PAA22568@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > Please consider merging this capability with the bandwdith sharing > capability described in draft-kini-*. This would allow the bandwidth > on backup paths to be shared where possible. See additional comments > on this below. > Sure. I have read the INFOCOM papers before. Let me take a look at them again. Just curious, has anyone implemented the proposed routing (OSPF/ISIS) extensions? > > 3.2 DETOUR Object > > > > 0 1 2 3 > > +-------------+-------------+-------------+-------------+ > > | Length (bytes) | Class-Num | C-Type | > > +-------------+-------------+-------------+-------------+ > > | Source ID | > > +-------------+-------------+-------------+-------------+ > > | Downstream Node ID | > > +-------------+-------------+-------------+-------------+ > > > This seems to assume node disjoint paths. A more general approach > would be to provide a list of SRLG that the detour need to avoid. > > A special case is one where an SRLG contains all links terminated at a > given node, which covers the node disjoint case above. > My editing goof: the downstream node ID is the first downstream router to avoid. It is used in the CSPF computation, which is to provide the shortest detour path between the current router to a downstream merging router. We will consider your comment of having a list for protecting nodes. > It should be fine to provide a object that names a specific node as a > special case of the detour object, and may be (is) needed to > accommodate existing code. It might be useful to have a form of the > detour object that covered the link disjoint special case. There > should also be a form of the detour object that allows the more > general list of SRLG. > > SRLG should also be considered in the "Detour Path Computation > Algorithm" section. > Sure. Thanks! > > > 6 Intellectual Property Considerations > > > > Juniper Networks, Inc. is seeking patent protection on technology > > described in this Internet-Draft. If technology in this Internet- > > Draft is adopted as a standard, Juniper Networks agrees to license, > > on reasonable and non-discriminatory terms, any patent rights it > > obtains covering such technology to the extent necessary to comply > > with the standard. > > Could you please point out exactly what you think is new and unique > about this proposal? It's up to the lawyers to decide. ;-) Look, it seems everyone has used the similar paragraph for their restoration mechanism. We really have no choice. BTW, what's the status of that restoration patent application from Bell Labs which your drafts are based on? ;-) Take care and thanks! - Ping From owner-mpls@UU.NET Thu Apr 12 18:58:35 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13022 for ; Thu, 12 Apr 2001 18:58:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkml22977; Thu, 12 Apr 2001 22:55:54 GMT Received: by mail-control.mail.uu.net id QQkkml27708 for mpls-outgoing; Thu, 12 Apr 2001 22:55:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkml27692 for ; Thu, 12 Apr 2001 22:55:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkml24011 for ; Thu, 12 Apr 2001 22:53:38 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkkml01444 for ; Thu, 12 Apr 2001 22:53:36 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA23921; Thu, 12 Apr 2001 18:53:22 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104122253.SAA23921@workhorse.fictitious.org> To: Ping Pan cc: curtis@avici.com, dhg@juniper.net, arthi@juniper.net, kireeti@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Reply-To: curtis@avici.com Subject: Re: draft-gan-fast-reroute-00.txt In-reply-to: Your message of "Thu, 12 Apr 2001 14:07:05 PDT." <3AD618F9.56BC0655@juniper.net> Date: Thu, 12 Apr 2001 18:53:22 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3AD618F9.56BC0655@juniper.net>, Ping Pan writes: > Curtis Villamizar wrote: > > > > Please consider merging this capability with the bandwdith sharing > > capability described in draft-kini-*. This would allow the bandwidth > > on backup paths to be shared where possible. See additional comments > > on this below. > > > > Sure. I have read the INFOCOM papers before. Let me take a look at them > again. Just curious, has anyone implemented the proposed routing > (OSPF/ISIS) extensions? Not quite yet but RSN. > > > 3.2 DETOUR Object > > > > > > 0 1 2 3 > > > +-------------+-------------+-------------+-------------+ > > > | Length (bytes) | Class-Num | C-Type | > > > +-------------+-------------+-------------+-------------+ > > > | Source ID | > > > +-------------+-------------+-------------+-------------+ > > > | Downstream Node ID | > > > +-------------+-------------+-------------+-------------+ > > > > > This seems to assume node disjoint paths. A more general approach > > would be to provide a list of SRLG that the detour need to avoid. > > > > A special case is one where an SRLG contains all links terminated at a > > given node, which covers the node disjoint case above. > > My editing goof: the downstream node ID is the first downstream router > to avoid. It is used in the CSPF computation, which is to provide the > shortest detour path between the current router to a downstream merging > router. We will consider your comment of having a list for protecting > nodes. That was clear in the document. My point is that the "node disjoint path" case is a subset of what can be expressed with SRLG. > > It should be fine to provide a object that names a specific node as a > > special case of the detour object, and may be (is) needed to > > accommodate existing code. It might be useful to have a form of the > > detour object that covered the link disjoint special case. There > > should also be a form of the detour object that allows the more > > general list of SRLG. > > > > SRLG should also be considered in the "Detour Path Computation > > Algorithm" section. > > Sure. Thanks! So you'll add one or two Objects to cover SRLG, and possible the link disjoint special case. > > 6 Intellectual Property Considerations > > > > > > Juniper Networks, Inc. is seeking patent protection on technology > > > described in this Internet-Draft. If technology in this Internet- > > > Draft is adopted as a standard, Juniper Networks agrees to license, > > > on reasonable and non-discriminatory terms, any patent rights it > > > obtains covering such technology to the extent necessary to comply > > > with the standard. > > > > Could you please point out exactly what you think is new and unique > > about this proposal? > > It's up to the lawyers to decide. ;-) Look, it seems everyone has used > the similar paragraph for their restoration mechanism. We really have no > choice. BTW, what's the status of that restoration patent application > from Bell Labs which your drafts are based on? ;-) I don't think it is up to the lawyers to decide what is original unless they among the inventors. I'm not a lawyer so its possible that I can't say that. I also wonder how many of these patent applications if awarded would stand up if challenged. Lets continue offline. > Take care and thanks! > > - Ping Good to hear from you again, Curtis From owner-mpls@UU.NET Thu Apr 12 19:13:12 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13269 for ; Thu, 12 Apr 2001 19:13:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkmm08146; Thu, 12 Apr 2001 23:10:54 GMT Received: by mail-control.mail.uu.net id QQkkmm16121 for mpls-outgoing; Thu, 12 Apr 2001 23:10:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkmm16096 for ; Thu, 12 Apr 2001 23:10:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkmm27781 for ; Thu, 12 Apr 2001 23:10:00 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkkmm22347 for ; Thu, 12 Apr 2001 23:09:58 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id TAA23957; Thu, 12 Apr 2001 19:09:48 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104122309.TAA23957@workhorse.fictitious.org> To: Ping Pan cc: curtis@avici.com, dhg@juniper.net, arthi@juniper.net, kireeti@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Reply-To: curtis@avici.com Subject: Re: draft-gan-fast-reroute-00.txt In-reply-to: Your message of "Thu, 12 Apr 2001 14:07:05 PDT." <3AD618F9.56BC0655@juniper.net> Date: Thu, 12 Apr 2001 19:09:48 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3AD618F9.56BC0655@juniper.net>, Ping Pan writes: > Curtis Villamizar wrote: > > > 6 Intellectual Property Considerations > > > > > > Juniper Networks, Inc. is seeking patent protection on technology > > > described in this Internet-Draft. If technology in this Internet- > > > Draft is adopted as a standard, Juniper Networks agrees to license, > > > on reasonable and non-discriminatory terms, any patent rights it > > > obtains covering such technology to the extent necessary to comply > > > with the standard. > > > > Could you please point out exactly what you think is new and unique > > about this proposal? > > It's up to the lawyers to decide. ;-) Look, it seems everyone has used > the similar paragraph for their restoration mechanism. We really have no > choice. BTW, what's the status of that restoration patent application > from Bell Labs which your drafts are based on? ;-) It is not up to the lawyers to decide. The lawyers provide a service to the inventors who must indicate to the lawyers what is original and non-obvious that makes this a patentable invention. Of course, the law profession specifically disallows anyone who is not a lawyer from giving legal advice, so don't consider this legal advice, and go consult a lawyer. In my legally unprofessional and uninformed opinion, a lot of the patent claims we are seeing ar smoke screens and would not stand up on appeals. But you have to discount that comment too. As far as any Lucent patents, they may be negligent in not disclosing intellectual property claims if they are applying for a patent. I don't know of any patent application and I have been led to beleive that there is none. I will ask Lakshman. If the application of their algorithm to the problem of restoration becomes patented and is not licensed for a nominal fee, then I'd abandon the work and use an algorithm of my own design that I had considered prior to finding out about their work. It would involve more flooding, but anyone could use it. I wish we could get rid of this whole patent system. It is enormously counterproductive and hinders technical progress in so many fields. I hope networking isn't the next victim of the patent system choking innovation. Curtis From owner-mpls@UU.NET Thu Apr 12 19:16:26 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13354 for ; Thu, 12 Apr 2001 19:16:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkmm11650; Thu, 12 Apr 2001 23:14:07 GMT Received: by mail-control.mail.uu.net id QQkkmm16671 for mpls-outgoing; Thu, 12 Apr 2001 23:13:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkmm16641 for ; Thu, 12 Apr 2001 23:13:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkmm13093 for ; Thu, 12 Apr 2001 23:12:26 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkkmm09985 for ; Thu, 12 Apr 2001 23:12:26 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id TAA23978; Thu, 12 Apr 2001 19:12:20 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104122312.TAA23978@workhorse.fictitious.org> To: Ping Pan cc: curtis@avici.com, dhg@juniper.net, arthi@juniper.net, kireeti@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Reply-To: curtis@avici.com Subject: Re: draft-gan-fast-reroute-00.txt In-reply-to: Your message of "Thu, 12 Apr 2001 14:07:05 PDT." <3AD618F9.56BC0655@juniper.net> Date: Thu, 12 Apr 2001 19:12:20 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk People other that the Ping please ignore my last message. It was supposed to have the mailing lists trimmed off the Cc. Oops. Curtis From owner-mpls@UU.NET Thu Apr 12 19:46:26 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13657 for ; Thu, 12 Apr 2001 19:46:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkmo23739; Thu, 12 Apr 2001 23:43:18 GMT Received: by mail-control.mail.uu.net id QQkkmo19891 for mpls-outgoing; Thu, 12 Apr 2001 23:42:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkmo19866 for ; Thu, 12 Apr 2001 23:42:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkmo21764 for ; Thu, 12 Apr 2001 23:42:09 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkmo13921 for ; Thu, 12 Apr 2001 23:42:09 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA21879 for mpls@uu.net; Thu, 12 Apr 2001 19:42:08 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkmo19798 for ; Thu, 12 Apr 2001 23:41:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkmo04155 for ; Thu, 12 Apr 2001 23:41:19 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkkmo20473 for ; Thu, 12 Apr 2001 23:41:19 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id QAA04755; Thu, 12 Apr 2001 16:41:11 -0700 (PDT) Message-ID: <3AD63D0F.3ADAC139@juniper.net> Date: Thu, 12 Apr 2001 16:41:03 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: dhg@juniper.net, arthi@juniper.net, kireeti@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: draft-gan-fast-reroute-00.txt References: <200104122253.SAA23921@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > > > It should be fine to provide a object that names a specific node as a > > > special case of the detour object, and may be (is) needed to > > > accommodate existing code. It might be useful to have a form of the > > > detour object that covered the link disjoint special case. There > > > should also be a form of the detour object that allows the more > > > general list of SRLG. > > > > > > SRLG should also be considered in the "Detour Path Computation > > > Algorithm" section. > > > > Sure. Thanks! > > So you'll add one or two Objects to cover SRLG, and possible the link > disjoint special case. > Let me check with other folks here. We have shipped the restoration feature for a while, and providers have deployed it. So we have to be careful. Please understand. Thanks again! - Ping From owner-mpls@UU.NET Thu Apr 12 23:22:01 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17478 for ; Thu, 12 Apr 2001 23:22:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkknd28495; Fri, 13 Apr 2001 03:19:47 GMT Received: by mail-control.mail.uu.net id QQkknd20978 for mpls-outgoing; Fri, 13 Apr 2001 03:19:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkknd20958 for ; Fri, 13 Apr 2001 03:18:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkknd20392 for ; Fri, 13 Apr 2001 03:18:45 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkknd26805 for ; Fri, 13 Apr 2001 03:18:45 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f3D3GvB21006 for ; Thu, 12 Apr 2001 20:16:57 -0700 (PDT) Reply-To: From: "Anil Gunturu" To: Subject: RE: LSP intiator Date: Thu, 12 Apr 2001 20:17:16 -0700 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In case of LDP, how do you determine if the particular interface is Ingress or not? Do we statically configure this? For an FEC if the next hop is not MPLS we can say that it is an egress LER. But, can we infer this for an Ingress LER? Thanks, -Anil Anil Gunturu, Software Engineer Ericsson, Inc phone: (805) 562 6431 Datacom & IP Services email: anilg@acc.am.ericsson.se 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Thu Apr 12 23:24:05 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17514 for ; Thu, 12 Apr 2001 23:24:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkknd06281; Fri, 13 Apr 2001 03:21:52 GMT Received: by mail-control.mail.uu.net id QQkknd21132 for mpls-outgoing; Fri, 13 Apr 2001 03:21:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkknd21043 for ; Fri, 13 Apr 2001 03:20:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkknd21662 for ; Fri, 13 Apr 2001 03:19:19 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkknd27706 for ; Fri, 13 Apr 2001 03:19:19 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f3D3HVB21037 for ; Thu, 12 Apr 2001 20:17:31 -0700 (PDT) Reply-To: From: "Anil Gunturu" To: Subject: LDP Ingress Date: Thu, 12 Apr 2001 20:17:50 -0700 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In case of LDP, how do you determine if the particular interface is Ingress or not? Do we statically configure this? For an FEC if the next hop is not MPLS we can say that it is an egress LER. But, can we infer this for an Ingress LER? Thanks, -Anil Anil Gunturu, Software Engineer Ericsson, Inc phone: (805) 562 6431 Datacom & IP Services email: anilg@acc.am.ericsson.se 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Fri Apr 13 02:58:17 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02950 for ; Fri, 13 Apr 2001 02:58:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkknr08375; Fri, 13 Apr 2001 06:55:39 GMT Received: by mail-control.mail.uu.net id QQkknr29378 for mpls-outgoing; Fri, 13 Apr 2001 06:55:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkknr29370 for ; Fri, 13 Apr 2001 06:55:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkknr23519 for ; Fri, 13 Apr 2001 06:54:24 GMT Received: from ntexgswp02.DMZ by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.kpnqwest.com [193.242.92.8]) id QQkknr18702 for ; Fri, 13 Apr 2001 06:54:23 GMT Received: from ntexghub01.kpnqwest.com (unverified) by ntexgswp02.DMZ (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 13 Apr 2001 08:53:04 +0200 Received: by ntexghub01 with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 08:45:23 +0200 Message-ID: <3F3B952383E8D311A9FC0008C7E61402027A05D0@ntexgdhg02> From: "Metz, Eduard" To: "'Ping Pan'" , curtis@avici.com Cc: dhg@juniper.net, arthi@juniper.net, kireeti@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: draft-gan-fast-reroute-00.txt Date: Fri, 13 Apr 2001 08:48:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, haven't read the draft in detail yet, but adding support for SRLG to avoid detours to be routed over links that share the same risk seems very useful.Sometimes even a plain requirement to deploy fast re-route in a usefull way. As an example consider the situation described in section 2, when link 1-2 and link 1-3 run in the same cable both the main LSP and the potential detour are affected by a single cable-cut. Leaving you with regular re-route. Some other questions: - What will happen if the detour from Node1 to Node3 (picture section 2) passes Node4? Will the detour terminate at Node4, or will the traffic will pass link 3-4 two times? - Similar to the above, but now for the case where the detour passes the Egress? Thanks. cheers, Eduard > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: 13 April 2001 01:41 > To: curtis@avici.com > Cc: dhg@juniper.net; arthi@juniper.net; kireeti@juniper.net; > mpls@UU.NET; ccamp@ops.ietf.org > Subject: Re: draft-gan-fast-reroute-00.txt > > > Curtis Villamizar wrote: > > > > > > It should be fine to provide a object that names a > specific node as a > > > > special case of the detour object, and may be (is) needed to > > > > accommodate existing code. It might be useful to have > a form of the > > > > detour object that covered the link disjoint special > case. There > > > > should also be a form of the detour object that allows the more > > > > general list of SRLG. > > > > > > > > SRLG should also be considered in the "Detour Path Computation > > > > Algorithm" section. > > > > > > Sure. Thanks! > > > > So you'll add one or two Objects to cover SRLG, and > possible the link > > disjoint special case. > > > > Let me check with other folks here. We have shipped the restoration > feature for a while, and providers have deployed it. So we have to be > careful. Please understand. > > Thanks again! > > - Ping > From owner-mpls@UU.NET Fri Apr 13 03:16:03 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03054 for ; Fri, 13 Apr 2001 03:16:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkns09788; Fri, 13 Apr 2001 07:13:49 GMT Received: by mail-control.mail.uu.net id QQkkns17781 for mpls-outgoing; Fri, 13 Apr 2001 07:13:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkns17767 for ; Fri, 13 Apr 2001 07:13:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkns05381 for ; Fri, 13 Apr 2001 07:13:05 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkns16560 for ; Fri, 13 Apr 2001 07:13:00 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA13235 for mpls@uu.net; Fri, 13 Apr 2001 03:12:59 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkns17684 for ; Fri, 13 Apr 2001 07:12:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkns02665 for ; Fri, 13 Apr 2001 07:11:57 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkkns08740 for ; Fri, 13 Apr 2001 07:11:57 GMT Received: from juniper.net ([172.16.167.235]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id AAA24195; Fri, 13 Apr 2001 00:11:54 -0700 (PDT) Message-ID: <3AD6A6AE.EB48B0B7@juniper.net> Date: Fri, 13 Apr 2001 00:11:42 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Metz, Eduard" CC: mpls@UU.NET, ccamp@ops.ietf.org, Der-Hwa Gan , Arthi Ayyangar , Kireeti Kompella Subject: Re: draft-gan-fast-reroute-00.txt References: <3F3B952383E8D311A9FC0008C7E61402027A05D0@ntexgdhg02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Metz, Eduard" wrote: > > haven't read the draft in detail yet, but adding support for SRLG to avoid > detours to be routed over links that share the same risk seems very > useful.Sometimes even a plain requirement to deploy fast re-route in a > usefull way. As an example consider the situation described in section 2, > when link 1-2 and link 1-3 run in the same cable both the main LSP and the > potential detour are affected by a single cable-cut. Leaving you with > regular re-route. > Thanks for the input. Will get back to you asap. > Some other questions: > - What will happen if the detour from Node1 to Node3 (picture section 2) > passes Node4? Will the detour terminate at Node4, or will the traffic will > pass link 3-4 two times? I think that it is OK to have detour paths traversing through the same nodes that the main LSP goes through. This type of loops does not present problems in packet forwarding... except perhaps inefficient use of network resources. But we need to be careful with the loop detection mechanism described in the RSVP-TE draft. > - Similar to the above, but now for the case where the detour passes the > Egress? > No sure this can happen after CSPF computation. Thanks! - Ping From owner-mpls@UU.NET Fri Apr 13 03:25:01 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03078 for ; Fri, 13 Apr 2001 03:25:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkknt01757; Fri, 13 Apr 2001 07:22:41 GMT Received: by mail-control.mail.uu.net id QQkknt18839 for mpls-outgoing; Fri, 13 Apr 2001 07:22:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkknt18819 for ; Fri, 13 Apr 2001 07:21:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkknt07235 for ; Fri, 13 Apr 2001 07:20:55 GMT Received: from samar.sasi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQkknt01040 for ; Fri, 13 Apr 2001 07:20:49 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id MAA15243 for ; Fri, 13 Apr 2001 12:50:40 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Fri, 13 Apr 2001 12:50:39 +0000 (IST) Received: from pcc67 (pcc69.sasi.com [10.0.32.69]) by suns3.sasi.com (8.9.3/8.9.3) with SMTP id MAA11126 for ; Fri, 13 Apr 2001 12:49:44 +0530 (IST) Message-ID: <010401c0c3ea$8f4066e0$4520000a@sasi.com> From: "Rajesh P Jain" To: Subject: Does MPLS Require L3 Routing Table ? Date: Fri, 13 Apr 2001 12:52:55 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0101_01C0C418.A8E7DA00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0101_01C0C418.A8E7DA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "Hello", List, Well, I am very new to the MPLS domain. I just = wanted to check out whether MPLS domain neccesarily require the L3 = Routing Table (Maybe IP Routing Table) to build up it's label (using the = LDP Protocol). Or the LDP will take care of building the label = information automatically without the L3 Routing information? TIA Rajesh P Jain ------=_NextPart_000_0101_01C0C418.A8E7DA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
"Hello", List,
       =20             Well, I am very = new to=20 the MPLS domain. I just wanted to check out whether MPLS domain = neccesarily=20 require the L3 Routing Table (Maybe IP Routing Table) to build up it's = label=20 (using the LDP Protocol). Or the LDP will take care of building the = label=20 information automatically without the L3 Routing = information?
 
TIA
        = Rajesh P=20 Jain
------=_NextPart_000_0101_01C0C418.A8E7DA00-- From owner-mpls@UU.NET Fri Apr 13 03:40:57 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03142 for ; Fri, 13 Apr 2001 03:40:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkknu24673; Fri, 13 Apr 2001 07:38:49 GMT Received: by mail-control.mail.uu.net id QQkknu19994 for mpls-outgoing; Fri, 13 Apr 2001 07:38:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkknu19982 for ; Fri, 13 Apr 2001 07:38:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkknu28366 for ; Fri, 13 Apr 2001 07:38:05 GMT Received: from dharti.aplion.stpn.soft.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.10.199.46]) id QQkknu25759 for ; Fri, 13 Apr 2001 07:38:00 GMT Received: from bhartibatra (sys_test_1 [192.9.202.135]) by dharti.aplion.stpn.soft.net (8.8.7/8.8.4) with SMTP id MAA28278; Fri, 13 Apr 2001 12:48:43 +0530 Message-ID: <01de01c0c3ec$eb47e6f0$87ca09c0@dharti.aplion.stpn.soft.net> From: "Bharti Batra" To: "Rajesh P Jain" , References: <010401c0c3ea$8f4066e0$4520000a@sasi.com> Subject: Re: Does MPLS Require L3 Routing Table ? Date: Fri, 13 Apr 2001 13:09:49 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DB_01C0C41B.04E93F90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01DB_01C0C41B.04E93F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi ! Yes. LDP needs IP routing table to find out the route towards the egress = router to setup the LSP. LDP sends the LSP setup request message along = this path. Regds, Bharti ----- Original Message -----=20 From: Rajesh P Jain=20 To: mpls@UU.NET=20 Sent: Friday, April 13, 2001 12:52 PM Subject: Does MPLS Require L3 Routing Table ? "Hello", List, Well, I am very new to the MPLS domain. I just = wanted to check out whether MPLS domain neccesarily require the L3 = Routing Table (Maybe IP Routing Table) to build up it's label (using the = LDP Protocol). Or the LDP will take care of building the label = information automatically without the L3 Routing information? TIA Rajesh P Jain ------=_NextPart_000_01DB_01C0C41B.04E93F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi !
 
Yes. LDP needs IP routing table to find out the route towards the = egress=20 router to setup the LSP. LDP sends the LSP setup request message along = this=20 path.
 
Regds,
Bharti
----- Original Message -----
From:=20 Rajesh = P Jain=20
Sent: Friday, April 13, 2001 = 12:52=20 PM
Subject: Does MPLS Require L3 = Routing=20 Table ?

"Hello", List,
        =             Well, I am = very new=20 to the MPLS domain. I just wanted to check out whether MPLS domain = neccesarily=20 require the L3 Routing Table (Maybe IP Routing Table) to build up it's = label=20 (using the LDP Protocol). Or the LDP will take care of building the = label=20 information automatically without the L3 Routing = information?
 
TIA
        = Rajesh P=20 Jain
------=_NextPart_000_01DB_01C0C41B.04E93F90-- From owner-mpls@UU.NET Fri Apr 13 04:05:47 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03263 for ; Fri, 13 Apr 2001 04:05:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkknw08613; Fri, 13 Apr 2001 08:03:17 GMT Received: by mail-control.mail.uu.net id QQkknw27743 for mpls-outgoing; Fri, 13 Apr 2001 08:02:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkknw27067 for ; Fri, 13 Apr 2001 08:02:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkknw12677 for ; Fri, 13 Apr 2001 08:01:35 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkknw07681 for ; Fri, 13 Apr 2001 08:01:34 GMT Received: from oleary-lt (martin-csx.jnpr.net [172.24.249.50] (may be forged)) by red.juniper.net (8.9.3/8.9.3) with ESMTP id BAA25380; Fri, 13 Apr 2001 01:01:32 -0700 (PDT) Message-Id: <4.2.0.58.20010413005524.00962210@garnet.juniper.net> X-Sender: doleary@garnet.juniper.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 13 Apr 2001 01:02:48 -0700 To: Paul Bonenfant From: "dave o'leary" Subject: Re: restoration time requirement (was Re: Last Call on RSVP LabelAllocation for Backup Tunnels) Cc: mpls@UU.NET, ccamp@ops.ietf.org, "t1x1.5" In-Reply-To: <3AD1C050.629F38BC@photuris.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:59 AM 4/9/01 -0400, Paul Bonenfant wrote: >Psychological bars notwithstanding, what then is the appropriate >restoration time requirement? I for one would be interested in >hearing from (even more) carriers regarding which latency-sensitive >applications actually drive the 50msec-range protection/restoration >requirements (my guess: it's not (only) voice). While there is no strict requirement for IP (of course), a router can spill a lot of packets on the floor (or into the conduit or whatever) at 10's of millions of packets per second, so the faster the better, at least as long as network stability is preserved. dave From owner-mpls@UU.NET Fri Apr 13 04:17:01 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03333 for ; Fri, 13 Apr 2001 04:17:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkknw18589; Fri, 13 Apr 2001 08:14:49 GMT Received: by mail-control.mail.uu.net id QQkknw10159 for mpls-outgoing; Fri, 13 Apr 2001 08:14:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkknw10148 for ; Fri, 13 Apr 2001 08:14:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkknw21295 for ; Fri, 13 Apr 2001 08:14:07 GMT Received: from samar.sasi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQkknw17564 for ; Fri, 13 Apr 2001 08:14:00 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id NAA18392; Fri, 13 Apr 2001 13:43:54 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Fri, 13 Apr 2001 13:43:53 +0000 (IST) Received: from pcc67 (pcc69.sasi.com [10.0.32.69]) by suns3.sasi.com (8.9.3/8.9.3) with SMTP id NAA11778; Fri, 13 Apr 2001 13:43:07 +0530 (IST) Message-ID: <012a01c0c3f2$041d39a0$4520000a@sasi.com> From: "Rajesh P Jain" To: "Bharti Batra" , References: <010401c0c3ea$8f4066e0$4520000a@sasi.com> <01de01c0c3ec$eb47e6f0$87ca09c0@dharti.aplion.stpn.soft.net> Subject: Re: Does MPLS Require L3 Routing Table ? Date: Fri, 13 Apr 2001 13:46:18 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01C0C420.1DC4ACC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0127_01C0C420.1DC4ACC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "Hello", Thanks for the response. Well, if it requires L3 Routing table to build = up the Label information, then what is the advantage of MPLS??? Well, = Anyhow, it will require the building of L3 Routing Table (May be through = RIP/OSPF/BGP etc), then Lable info can be formed by using only L3. So, = Anyhow, MPLS is dependent on L3, please explain me what is the advantage = of using MPLS (in terms of efficiency and speed switching of the = packets). With Regards Rajesh P Jain ----- Original Message -----=20 From: Bharti Batra=20 To: Rajesh P Jain ; mpls@UU.NET=20 Sent: Friday, April 13, 2001 1:09 PM Subject: Re: Does MPLS Require L3 Routing Table ? Hi ! Yes. LDP needs IP routing table to find out the route towards the = egress router to setup the LSP. LDP sends the LSP setup request message = along this path. Regds, Bharti ----- Original Message -----=20 From: Rajesh P Jain=20 To: mpls@UU.NET=20 Sent: Friday, April 13, 2001 12:52 PM Subject: Does MPLS Require L3 Routing Table ? "Hello", List, Well, I am very new to the MPLS domain. I just = wanted to check out whether MPLS domain neccesarily require the L3 = Routing Table (Maybe IP Routing Table) to build up it's label (using the = LDP Protocol). Or the LDP will take care of building the label = information automatically without the L3 Routing information? TIA Rajesh P Jain ------=_NextPart_000_0127_01C0C420.1DC4ACC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
"Hello",
       =20             =    =20 Thanks for the response.
 
       =20             =    =20 Well, if it requires L3 Routing table to build up the Label information, = then=20 what is the advantage of MPLS??? Well, Anyhow, it will require the = building of=20 L3 Routing Table (May be through RIP/OSPF/BGP etc), then Lable info can = be=20 formed by using only L3. So, Anyhow, MPLS is dependent on L3, please = explain me=20 what is the advantage of using MPLS (in terms of efficiency and speed = switching=20 of the packets).
 
With Regards
          &nbs= p;        =20 Rajesh P Jain
----- Original Message -----
From:=20 Bharti Batra
Sent: Friday, April 13, 2001 = 1:09=20 PM
Subject: Re: Does MPLS Require = L3 Routing=20 Table ?

Hi !
 
Yes. LDP needs IP routing table to find out the route towards the = egress=20 router to setup the LSP. LDP sends the LSP setup request message along = this=20 path.
 
Regds,
Bharti
----- Original Message -----
From:=20 Rajesh P Jain=20
Sent: Friday, April 13, 2001 = 12:52=20 PM
Subject: Does MPLS Require L3 = Routing=20 Table ?

"Hello", List,
    =    =20             Well, I am = very new=20 to the MPLS domain. I just wanted to check out whether MPLS domain=20 neccesarily require the L3 Routing Table (Maybe IP Routing Table) to = build=20 up it's label (using the LDP Protocol). Or the LDP will take care of = building the label information automatically without the L3 Routing=20 information?
 
TIA
    =     Rajesh P=20 Jain
------=_NextPart_000_0127_01C0C420.1DC4ACC0-- From owner-mpls@UU.NET Fri Apr 13 04:57:43 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03684 for ; Fri, 13 Apr 2001 04:57:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkknz25919; Fri, 13 Apr 2001 08:55:26 GMT Received: by mail-control.mail.uu.net id QQkknz13541 for mpls-outgoing; Fri, 13 Apr 2001 08:54:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkknz13530 for ; Fri, 13 Apr 2001 08:54:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkknz22196 for ; Fri, 13 Apr 2001 08:54:14 GMT Received: from age06.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.109.72.154]) id QQkknz05132 for ; Fri, 13 Apr 2001 08:54:13 GMT Received: from age004 [61.169.77.195] by age06.com [202.109.72.154] with SMTP (MDaemon.v3.0.2.R) for ; Fri, 13 Apr 2001 16:49:24 +0800 Message-ID: <002601c0c3f6$f2748eb0$0601a8c0@age06.com> From: "JsDeng" To: "Rajesh P Jain" , "Bharti Batra" , References: <010401c0c3ea$8f4066e0$4520000a@sasi.com> <01de01c0c3ec$eb47e6f0$87ca09c0@dharti.aplion.stpn.soft.net> <012a01c0c3f2$041d39a0$4520000a@sasi.com> Subject: Re: Does MPLS Require L3 Routing Table ? Date: Fri, 13 Apr 2001 16:50:42 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C0C439.E0D94810" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDaemon-Deliver-To: mpls@UU.NET X-Return-Path: jsdeng@age06.com X-MDRcpt-To: mpls@UU.NET X-MDRemoteIP: 61.169.77.195 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C0C439.E0D94810 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCiAgICBGcm9tIHRoZSBpbnRlcm5ldCBkcmFmdHMgb2YgTVBMUyBmdW5kYW1lbnRh bCBpZGVhcywgeW91IGNhbiBmaW5kIG91dCB0aGUgbW9zdCBleGFjdCBhbnN3ZXIuIA0KDQogICAg SW4gc2hvcnQsIE1QTFMgY2FuIGRvIHNwZWVkeSBzd2l0Y2hpbmcgZnVuY3Rpb25zIGJ5IGEgY2hl YXAgaGFyZHdhcmUgYW5kIE1QTFMgaXMgZWFzeSB0byBidWlsZCB1cCBzdHJ1Y3R1cmVkIGFuZCBz Y2FsYWJsZSBuZXR3b3JrcyBpbiBnbG9iYWwgc2NvcGUgd2l0aCBpdHMgbGFiZWwgc3RhY2tpbmcg YW5kIGxhYmVsIHN3YXBwaW5nIG1lY2hhbmlzbXMuDQoNCiAgICBSZWdhcmRzLg0KDQpEZW5nIEpp c2hlbmcNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogUmFqZXNoIFAg SmFpbiANCiAgVG86IEJoYXJ0aSBCYXRyYSA7IG1wbHNAVVUuTkVUIA0KICBTZW50OiBGcmlkYXks IEFwcmlsIDEzLCAyMDAxIDQ6MTYgUE0NCiAgU3ViamVjdDogUmU6IERvZXMgTVBMUyBSZXF1aXJl IEwzIFJvdXRpbmcgVGFibGUgPw0KDQoNCiAgIkhlbGxvIiwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgV2VsbCwgaWYgaXQgcmVxdWlyZXMgTDMgUm91dGluZyB0YWJsZSB0byBidWlsZCB1cCB0aGUg TGFiZWwgaW5mb3JtYXRpb24sIHRoZW4gd2hhdCBpcyB0aGUgYWR2YW50YWdlIG9mIE1QTFM/Pz8g V2VsbCwgQW55aG93LCBpdCB3aWxsIHJlcXVpcmUgdGhlIGJ1aWxkaW5nIG9mIEwzIFJvdXRpbmcg VGFibGUgKE1heSBiZSB0aHJvdWdoIFJJUC9PU1BGL0JHUCBldGMpLCB0aGVuIExhYmxlIGluZm8g Y2FuIGJlIGZvcm1lZCBieSB1c2luZyBvbmx5IEwzLiBTbywgQW55aG93LCBNUExTIGlzIGRlcGVu ZGVudCBvbiBMMywgcGxlYXNlIGV4cGxhaW4gbWUgd2hhdCBpcyB0aGUgYWR2YW50YWdlIG9mIHVz aW5nIE1QTFMgKGluIHRlcm1zIG9mIGVmZmljaWVuY3kgYW5kIHNwZWVkIHN3aXRjaGluZyBvZiB0 aGUgcGFja2V0cykuDQoNCiAgV2l0aCBSZWdhcmRzDQogICAgICAgICAgICAgICAgICAgICAgUmFq ZXNoIFAgSmFpbg0KICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogICAgRnJvbTog QmhhcnRpIEJhdHJhIA0KICAgIFRvOiBSYWplc2ggUCBKYWluIDsgbXBsc0BVVS5ORVQgDQogICAg U2VudDogRnJpZGF5LCBBcHJpbCAxMywgMjAwMSAxOjA5IFBNDQogICAgU3ViamVjdDogUmU6IERv ZXMgTVBMUyBSZXF1aXJlIEwzIFJvdXRpbmcgVGFibGUgPw0KDQoNCiAgICBIaSAhDQoNCiAgICBZ ZXMuIExEUCBuZWVkcyBJUCByb3V0aW5nIHRhYmxlIHRvIGZpbmQgb3V0IHRoZSByb3V0ZSB0b3dh cmRzIHRoZSBlZ3Jlc3Mgcm91dGVyIHRvIHNldHVwIHRoZSBMU1AuIExEUCBzZW5kcyB0aGUgTFNQ IHNldHVwIHJlcXVlc3QgbWVzc2FnZSBhbG9uZyB0aGlzIHBhdGguDQoNCiAgICBSZWdkcywNCiAg ICBCaGFydGkNCiAgICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogICAgICBGcm9t OiBSYWplc2ggUCBKYWluIA0KICAgICAgVG86IG1wbHNAVVUuTkVUIA0KICAgICAgU2VudDogRnJp ZGF5LCBBcHJpbCAxMywgMjAwMSAxMjo1MiBQTQ0KICAgICAgU3ViamVjdDogRG9lcyBNUExTIFJl cXVpcmUgTDMgUm91dGluZyBUYWJsZSA/DQoNCg0KICAgICAgIkhlbGxvIiwgTGlzdCwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgV2VsbCwgSSBhbSB2ZXJ5IG5ldyB0byB0aGUgTVBMUyBkb21h aW4uIEkganVzdCB3YW50ZWQgdG8gY2hlY2sgb3V0IHdoZXRoZXIgTVBMUyBkb21haW4gbmVjY2Vz YXJpbHkgcmVxdWlyZSB0aGUgTDMgUm91dGluZyBUYWJsZSAoTWF5YmUgSVAgUm91dGluZyBUYWJs ZSkgdG8gYnVpbGQgdXAgaXQncyBsYWJlbCAodXNpbmcgdGhlIExEUCBQcm90b2NvbCkuIE9yIHRo ZSBMRFAgd2lsbCB0YWtlIGNhcmUgb2YgYnVpbGRpbmcgdGhlIGxhYmVsIGluZm9ybWF0aW9uIGF1 dG9tYXRpY2FsbHkgd2l0aG91dCB0aGUgTDMgUm91dGluZyBpbmZvcm1hdGlvbj8NCg0KICAgICAg VElBDQogICAgICAgICAgICAgIFJhamVzaCBQIEphaW4NCg== ------=_NextPart_000_0021_01C0C439.E0D94810 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuNTAuNDIwOC4xNzAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPkhlbGxvLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQz NTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZyb20gdGhlIGludGVybmV0IGRy YWZ0cyBvZiBNUExTIA0KZnVuZGFtZW50YWwgaWRlYXMsIHlvdSBjYW4gZmluZCBvdXQgdGhlIG1v c3QgZXhhY3QgYW5zd2VyLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBJbiBzaG9ydCwgTVBMUyBjYW4g ZG8gc3BlZWR5IA0Kc3dpdGNoaW5nIGZ1bmN0aW9ucyBieSBhIGNoZWFwIGhhcmR3YXJlIGFuZCBN UExTIGlzIGVhc3kgdG8gYnVpbGQgdXAgc3RydWN0dXJlZCANCmFuZCBzY2FsYWJsZSBuZXR3b3Jr cyBpbiBnbG9iYWwgc2NvcGUgd2l0aCBpdHMgbGFiZWwgc3RhY2tpbmcgYW5kIGxhYmVsIHN3YXBw aW5nIA0KbWVjaGFuaXNtcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+RGVuZyBKaXNo ZW5nPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJ R0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVG VDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0i Rk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g PC9ESVY+DQogIDxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCAmIzIz NDM1OyYjMjAzMDc7OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRs ZT1ycGphaW5Ac2Fza2VuLmNvbSBocmVmPSJtYWlsdG86cnBqYWluQHNhc2tlbi5jb20iPlJhamVz aCBQIEphaW48L0E+IA0KICA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7 JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9YmJhdHJhQGFwbGlvbi5zdHBuLnNvZnQubmV0 IA0KICBocmVmPSJtYWlsdG86YmJhdHJhQGFwbGlvbi5zdHBuLnNvZnQubmV0Ij5CaGFydGkgQmF0 cmE8L0E+IDsgPEEgDQogIHRpdGxlPW1wbHNAVVUuTkVUIGhyZWY9Im1haWx0bzptcGxzQFVVLk5F VCI+bXBsc0BVVS5ORVQ8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQz NTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IEZyaWRheSwgQXByaWwgMTMsIDIwMDEgNDoxNiBQTTwv RElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVj dDo8L0I+IFJlOiBEb2VzIE1QTFMgUmVxdWlyZSBMMyBSb3V0aW5nIA0KICBUYWJsZSA/PC9ESVY+ DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiJIZWxs byIsPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQogICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiAg VGhhbmtzIGZvciB0aGUgcmVzcG9uc2UuPC9GT05UPjwvRElWPg0KICA8RElWPiZuYnNwOzwvRElW Pg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgDQogICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiAgV2VsbCwgaWYgaXQgcmVx dWlyZXMgTDMgUm91dGluZyB0YWJsZSB0byBidWlsZCB1cCB0aGUgTGFiZWwgaW5mb3JtYXRpb24s IHRoZW4gDQogIHdoYXQgaXMgdGhlIGFkdmFudGFnZSBvZiBNUExTPz8/IFdlbGwsIEFueWhvdywg aXQgd2lsbCByZXF1aXJlIHRoZSBidWlsZGluZyBvZiANCiAgTDMgUm91dGluZyBUYWJsZSAoTWF5 IGJlIHRocm91Z2ggUklQL09TUEYvQkdQIGV0YyksIHRoZW4gTGFibGUgaW5mbyBjYW4gYmUgDQog IGZvcm1lZCBieSB1c2luZyBvbmx5IEwzLiBTbywgQW55aG93LCBNUExTIGlzIGRlcGVuZGVudCBv biBMMywgcGxlYXNlIGV4cGxhaW4gDQogIG1lIHdoYXQgaXMgdGhlIGFkdmFudGFnZSBvZiB1c2lu ZyBNUExTIChpbiB0ZXJtcyBvZiBlZmZpY2llbmN5IGFuZCBzcGVlZCANCiAgc3dpdGNoaW5nIG9m IHRoZSBwYWNrZXRzKS48L0ZPTlQ+PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+V2l0aCBSZWdhcmRzPC9GT05UPjwvRElWPg0KICA8RElW PjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIFJhamVzaCBQIEphaW48L0ZPTlQ+PC9E SVY+DQogIDxCTE9DS1FVT1RFIGRpcj1sdHIgDQogIHN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7 IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAw MCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElWIHN0eWxlPSJGT05UOiAx MHB0IGFyaWFsIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICAgIDxESVYg DQogICAgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgYXJpYWw7IGZvbnQt Y29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogICAgPEEgdGl0bGU9YmJhdHJhQGFwbGlvbi5z dHBuLnNvZnQubmV0IA0KICAgIGhyZWY9Im1haWx0bzpiYmF0cmFAYXBsaW9uLnN0cG4uc29mdC5u ZXQiPkJoYXJ0aSBCYXRyYTwvQT4gPC9ESVY+DQogICAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBh cmlhbCI+PEI+VG86PC9CPiA8QSB0aXRsZT1ycGphaW5Ac2Fza2VuLmNvbSANCiAgICBocmVmPSJt YWlsdG86cnBqYWluQHNhc2tlbi5jb20iPlJhamVzaCBQIEphaW48L0E+IDsgPEEgdGl0bGU9bXBs c0BVVS5ORVQgDQogICAgaHJlZj0ibWFpbHRvOm1wbHNAVVUuTkVUIj5tcGxzQFVVLk5FVDwvQT4g PC9ESVY+DQogICAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+U2VudDo8L0I+IEZy aWRheSwgQXByaWwgMTMsIDIwMDEgMTowOSANCiAgICBQTTwvRElWPg0KICAgIDxESVYgc3R5bGU9 IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlN1YmplY3Q6PC9CPiBSZTogRG9lcyBNUExTIFJlcXVpcmUg TDMgDQogICAgUm91dGluZyBUYWJsZSA/PC9ESVY+DQogICAgPERJVj48QlI+PC9ESVY+DQogICAg PERJVj5IaSAhPC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPlllcy4gTERQ IG5lZWRzIElQIHJvdXRpbmcgdGFibGUgdG8gZmluZCBvdXQgdGhlIHJvdXRlIHRvd2FyZHMgdGhl IA0KICAgIGVncmVzcyByb3V0ZXIgdG8gc2V0dXAgdGhlIExTUC4gTERQIHNlbmRzIHRoZSBMU1Ag c2V0dXAgcmVxdWVzdCBtZXNzYWdlIA0KICAgIGFsb25nIHRoaXMgcGF0aC48L0RJVj4NCiAgICA8 RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+UmVnZHMsPC9ESVY+DQogICAgPERJVj5CaGFydGk8 L0RJVj4NCiAgICA8QkxPQ0tRVU9URSBkaXI9bHRyIA0KICAgIHN0eWxlPSJQQURESU5HLVJJR0hU OiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDog IzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICAgIDxESVYgc3R5bGU9 IkZPTlQ6IDEwcHQgYXJpYWwiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQog ICAgICA8RElWIA0KICAgICAgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQg YXJpYWw7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogICAgICA8QSB0aXRsZT1y cGphaW5Ac2Fza2VuLmNvbSBocmVmPSJtYWlsdG86cnBqYWluQHNhc2tlbi5jb20iPlJhamVzaCBQ IA0KICAgICAgSmFpbjwvQT4gPC9ESVY+DQogICAgICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFy aWFsIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPW1wbHNAVVUuTkVUIA0KICAgICAgaHJlZj0ibWFpbHRv Om1wbHNAVVUuTkVUIj5tcGxzQFVVLk5FVDwvQT4gPC9ESVY+DQogICAgICA8RElWIHN0eWxlPSJG T05UOiAxMHB0IGFyaWFsIj48Qj5TZW50OjwvQj4gRnJpZGF5LCBBcHJpbCAxMywgMjAwMSAxMjo1 MiANCiAgICAgIFBNPC9ESVY+DQogICAgICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48 Qj5TdWJqZWN0OjwvQj4gRG9lcyBNUExTIFJlcXVpcmUgTDMgUm91dGluZyANCiAgICAgIFRhYmxl ID88L0RJVj4NCiAgICAgIDxESVY+PEJSPjwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj4iSGVsbG8iLCBMaXN0LDwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgICAgICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7IFdlbGwsIEkgYW0gdmVyeSANCiAgICAgIG5ldyB0byB0aGUgTVBMUyBkb21haW4uIEkg anVzdCB3YW50ZWQgdG8gY2hlY2sgb3V0IHdoZXRoZXIgTVBMUyBkb21haW4gDQogICAgICBuZWNj ZXNhcmlseSByZXF1aXJlIHRoZSBMMyBSb3V0aW5nIFRhYmxlIChNYXliZSBJUCBSb3V0aW5nIFRh YmxlKSB0byBidWlsZCANCiAgICAgIHVwIGl0J3MgbGFiZWwgKHVzaW5nIHRoZSBMRFAgUHJvdG9j b2wpLiBPciB0aGUgTERQIHdpbGwgdGFrZSBjYXJlIG9mIA0KICAgICAgYnVpbGRpbmcgdGhlIGxh YmVsIGluZm9ybWF0aW9uIGF1dG9tYXRpY2FsbHkgd2l0aG91dCB0aGUgTDMgUm91dGluZyANCiAg ICAgIGluZm9ybWF0aW9uPzwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQog ICAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlRJQTwvRk9OVD48L0RJVj4NCiAgICAg IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyBSYWplc2ggDQogICAgICBQIEphaW48L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RF PjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0021_01C0C439.E0D94810-- From owner-mpls@UU.NET Fri Apr 13 08:34:27 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06514 for ; Fri, 13 Apr 2001 08:34:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkoo23643; Fri, 13 Apr 2001 12:32:08 GMT Received: by mail-control.mail.uu.net id QQkkoo09933 for mpls-outgoing; Fri, 13 Apr 2001 12:31:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkoo09924 for ; Fri, 13 Apr 2001 12:31:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkoo26322 for ; Fri, 13 Apr 2001 12:31:16 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQkkoo22509 for ; Fri, 13 Apr 2001 12:31:15 GMT Received: (qmail 5218 invoked from network); 13 Apr 2001 12:26:44 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 13 Apr 2001 12:26:44 -0000 Received: from sharada.ee.iitb.ac.in (root@sharada.ee.iitb.ac.in [144.16.100.126]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id RAA13806; Fri, 13 Apr 2001 17:55:28 +0530 (IST) Received: from localhost (gabhijit@localhost) by sharada.ee.iitb.ac.in (8.9.3/8.11.1) with ESMTP id SAA21690; Fri, 13 Apr 2001 18:00:19 +0530 Date: Fri, 13 Apr 2001 18:00:19 +0530 (IST) From: Abhijit Gadgil To: Rajesh P Jain cc: Bharti Batra , Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <012a01c0c3f2$041d39a0$4520000a@sasi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk MPLS does require layer 3 routing information. It works together with Layer 3 routing information like OSPF / BGP etc. However the advantage of MPLS is in terms of being able to label switch after it has formed the LSPs. This is useful in case of hardware that cannot look into IP header like ATM switches. Another advantage of MPLS is in terms of creating explicitely routed label switched paths, which is useful in Traffic Engineering. The original motivation for MPLS of being able to outperform IP lookup is not the motivation for MPLS these days. Another advantage of MPLS is its better than IP over ATM. Thus the advantages of MPLS can be listed as follows. 1. Making use of network layer routing to create label switched paths. 2. No need to maintain 2 networks as in IP over ATM case. 3. Alleviating N^2 mesh problem common with ATM switches hope that helps -abhijit On Fri, 13 Apr 2001, Rajesh P Jain wrote: >"Hello", > Thanks for the response. > > Well, if it requires L3 Routing table to build up the Label information, then what is the advantage of MPLS??? Well, Anyhow, it will require the building of L3 Routing Table (May be through RIP/OSPF/BGP etc), then Lable info can be formed by using only L3. So, Anyhow, MPLS is dependent on L3, please explain me what is the advantage of using MPLS (in terms of efficiency and speed switching of the packets). > >With Regards > Rajesh P Jain > ----- Original Message ----- > From: Bharti Batra > To: Rajesh P Jain ; mpls@UU.NET > Sent: Friday, April 13, 2001 1:09 PM > Subject: Re: Does MPLS Require L3 Routing Table ? > > > Hi ! > > Yes. LDP needs IP routing table to find out the route towards the egress router to setup the LSP. LDP sends the LSP setup request message along this path. > > Regds, > Bharti > ----- Original Message ----- > From: Rajesh P Jain > To: mpls@UU.NET > Sent: Friday, April 13, 2001 12:52 PM > Subject: Does MPLS Require L3 Routing Table ? > > > "Hello", List, > Well, I am very new to Jthe MPLS domain. I >just wanted to check out whether MPLS domain neccesarily require the L3 Routing Table (Maybe IP Routing Table) to build up it's label (using the LDP Protocol). Or the LDP will take care of building the label information automatically without the L3 Routing information? > > TIA > Rajesh P Jain > From owner-mpls@UU.NET Fri Apr 13 10:02:29 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08833 for ; Fri, 13 Apr 2001 10:02:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkou13236; Fri, 13 Apr 2001 14:00:14 GMT Received: by mail-control.mail.uu.net id QQkkot06059 for mpls-outgoing; Fri, 13 Apr 2001 13:59:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkot06046 for ; Fri, 13 Apr 2001 13:59:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkot25833 for ; Fri, 13 Apr 2001 13:58:11 GMT Received: from albatross-ext.wise.edt.ericsson.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [194.237.142.116]) id QQkkot11802 for ; Fri, 13 Apr 2001 13:58:10 GMT Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f3DDw4I11635 for ; Fri, 13 Apr 2001 15:58:09 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 13 15:57:31 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 15:57:31 +0200 Message-ID: From: "Roberto Mameli (TEI)" To: "Lista Mpls (E-mail)" Subject: Comments on draft-ietf-mpls-lsp-tunnel-08 Date: Fri, 13 Apr 2001 15:57:30 +0200 X-MS-TNEF-Correlator: MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C421.AE2EEE50" 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_01C0C421.AE2EEE50 Content-Type: text/plain; charset="iso-8859-1" Hello all, I have some observations on draft-ietf-mpls-rsvp-lsp-tunnel-0.8. I have gone through the mailing list but I've not been able to find comments on it. So here is a list of my observations. Sorry in advance for the length of this message. I also apologize if some of my questions are straightforward and have been discussed yet. 1) Quoted from the beginning of section1.1: "Hosts and routers that support both RSVP and MPLS...". Please correct me if I'm wrong, but even if not explicitly stated elsewhere, my understanding about MPLS was that this framework was to be employed within the network (I mean NOT on user hosts). Am I missing something about that? 2) There should be a typo in sec. 2.2, at the beginning of page 11: "If a Path message is allowed to progress when there are insufficient resources, the there is a danger... ". I think "the" should be changed in "then". More generally, what does this statement stand for? It seems that upon the reception of a Path message the LSR should trigger an Admission Control decision (see also par. 4.7.3 - page 50: "When a Path message is considered for admission... "). As far as I know in the ordinary RSVP processing Admission Control is performed upon Resv reception, according to the receiver initiated approach. Is this changed in the RSVP-TE extension? If so, is admission performed on the basis of the Tspec value? What about writing it more explicitly elsewhere? 3) Sec. 2.3 (page 12) and par. 2.6 (page 15) refers to section 4.8, but there is no sec. 4.8 in the draft 4) Sec. 2.3 again refers to Class-of-Service service. I've never heard about it, any info/pointer/clarification? 5) Sec. 2.4 at the beginning states: "The receiver node can select from among...". "from" should be deleted 6) Sec. 4.2 at the beginning states: "The Label Request Class is 19. Currently there three...". "are" is missing between "... there three...". 7) Sec. 4.2 page 25. "... if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages...". The canonical way by which a RSVP router knows about a non-RSVP neighbor is by means of the TTL field in the common header of the RSVP message. This value is set equal to the IP TTL by the sender and decremented by every RSVP node along the path, while the IP TTL is decremented by every node along the path. In this way, if an RSVP router observes that the 2 TTL values are different, then it assumes that UPSTREAM there is at least a non-RSVP router. Now, the point is that a router can determine if the UPSTREAM node is non-RSVP capable, but as far I know it has no means to know if the DOWNSTREAM node is non-RSVP capable. Assuming this lack of knowledge about the DOWNSTREAM node I wonder how it can decide not to advertise the LABEL_REQUEST object DOWNSTREAM. Is some form of static configuration required? 8) Quoted from the beginning of page 28: "The path between a loose node and its preceding node MAY include other network nodes that are not part of the STRICT node or its preceding abstract node". Should "STRICT" in the sentence be substituted by loose? 9) In the description of IPv4 prefix and IPv6 prefix subobjs (sections 4.3.3.2 and 4.3.3.3) the Resvd field is called Padding in the description. I think it would be better to use of the same terminology in both the figure and the description below. 10) Referring to section 4.7.4 it seems to me that there are conflicting sentences. Specifically what happens if a link cannot be validated because one of the three tests reported is not passed? Page 51 reports: "If the test fails a PathErr with the code "Policy Control Failure" SHOULD be sent", while page 52 states:"If the test fails, the node SHOULD send a PathErr message with an error code of "Routing Problem" and ....". . Did I misunderstand something? Thanks for your kind attention! Best regards Roberto ------_=_NextPart_000_01C0C421.AE2EEE50 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiANAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcEAA0ADwA5AB4ABQBUAQEggAMADgAAANEHBAAN AA8AOQAeAAUAVAEBCYABACEAAABBQTNGMEQ4QkFCMjlENTExOEI0MDAwMDJBNTJDRUJGNAA+BwEE gAEAKgAAAENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbXBscy1sc3AtdHVubmVsLTA4AAYPAQ2ABAAC AAAAAgACAAEDkAYAdBoAADMAAAADAN4/r28AAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADw EwAAHgACgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsAA4AIIAYAAAAAAMAA AAAAAABGAAAAAAaFAAAAAAAAAwAEgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAAWACCAG AAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsABoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAA AwABgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAAR hQAAAAAAAAMACIAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgA2gAggBgAAAAAAwAAAAAAA AEYAAAAAg4UAAAEAAAATAAAAODEwMjYwMjEzLTA1MDQyMDAxAAALAAyACyAGAAAAAADAAAAAAAAA RgAAAAAAiAAAAAAAAAsADYALIAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAAAgEJEAEAAACGFAAA ghQAANJPAABMWkZ1omjKYwMACgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jBCsBz ZXQwIAcTAoD/EAMAUARWCFUHshHVDlEDAd0Q1zIGAAbDEdUzBEYQ2fkS72Y0EG8RdhHjCO8J97Y7 Gr8OMDUR0gxgYwBQcwsJAWQzNhFgC6UYQGNlATAgEAIqXA6yAZBnAR9gMyA8IURPQwBUWVBFIEhU TQBMIFBVQkxJQwAgIi0vL1czQ5EiYERURCF0NC4RYORUcgBydGkCIAdAImDwRU4iPhHjIBcgwAqj uSTMMTkg0CGCJL40JxH4RUFEJL0O8SXfKc8mpAI2DvA8TUVUQSDHBaACMAnwdD0iBeAhg2I1I3Aw LjIsgCNgMzI1LjAiICQwB4A9R4EkgEVSQVRPUiS9+jQskS8oryCBKz8gcS7AASDQQk9EWSBiZ/MI UBpRPSMBIDTSJLAgI0sAIQMwdgiQd2sLgGTqNR/UYgDQawnACGA2UOIgAABzaHAf8jexC4Csc3Q3 kTfRcwOgZgMQRmw0YwKRc3YgLHA3sTowMjE1GdA4mEY5Mf8JgDm1GdA8ITVWH70e4TKfiGc5NiDQ RElWNTnnAAA8hx/5NjQ/vzzfLoDCOCDQRk9OVDkQANCrL0AHEyAAkHovQDI/q78YMAOyAdADMEKf IFM4KHFwU1BBTi0AC2AEED0YODEwLmBJgDEzLcowLsA0AdAwMT+vR1P0SGU5QG8fzEaBPhMHQPxs LD5sFPAxEEiyNTk8b/UmhjU/QS9EQk8/QL4BwP81RwqiT+gKgCYsSiAxAT98/0/vPX8+jz+fUw9B v1gvQ9//RO9F/13/SB0Ko0kPSh9d3z9OL1cvZ19RX2lvYy0mbs5iOLACgDVYJ2EBQFvv/1PvVP9W D1cfbN9ZP1pPZo//XG94D16PX59gr2G/ev9IbydlP3fPf3NJIBEAdmXffVADcIRQTE92Qm9uUASQ nHZhJAIEIAIgIGQjsE0BgC0IkAAwLW0LUHNiLREgdnAth+CIQHSNN1BuS/CCEC44LoP2JmcCIIRQ dGg3MWdoP4oRhK92JADAAxALgGcgl4xgOHA0MHUFQEknhEHsbm+M4QnhIAGgO4CKEO9MIDkgN2EF oG0HgAIwhsP7I/CJQFNMIIqwGsCPoAQgumGMpG81wIrvi/N5htA9hikubT9uT29aj/BycteSoAuA jhBkhmBufNA5EP8FsYqiO4CMgIogkQKKIJBx9QeBcyCAZYlCB0CEcJE/9U1EcBpBZ31xj6A1wIRz +5ERkpFxClA4cIaTCsCEUbp0I7BpinAAMAWwdwsRL44QN2GEI43TZAQAY3XvBBAJgJnvdjN5EUCT jGh//3Rfap9rr3ivcK9xv3LPpe//pC91/3cPgv95L69Pe098X/99b35/sj9j74Ffgm+2b6I//6s/ pF+lb71/k9+U76/fp9//qO+p/7+/wM+tL64/un+wX//L/7J/s4+0n7Wvzu+An7kvc83f02IxKcEf wi/DOlH+dY2gn/EDUqAfyhOKoo3QX5uQiMCMcpERETBjJAIxyC4xOiIwSG84cJCBfzdhNzEtQBEg ihGGcNEwdT5wm1AAIDQwjaCKgFJTHFZQnpPbr8oiTVBM9FMu4zAioa+8j8hvvq//5O/Dr8S/xc/G 3+fvyP/KD//LH8wvzT/OT89f0G/Rf9KP/9Of1K/Vv/MvIcA7gPpAhFD/BaEawN4gmOGb0uGv70KN QK3bgHcDYIyALIzzZYRA54+RNcCNkmV4C1AN4CPwfmySoDhwhnCf8UvwETB3/5AiADCSkTdR37EM kDZQjHL/DKDfgf5P4qf/0PpA2A/ZH1/DOt/zmKMOcC8hd5eQa98GIo5ijdAAgIfBb6FwN3BfGICY oY4AiqKI0HQKMyifhACEkCPABI/vM05P9ZBXhuGfwBMxaN7iKYlAQf/bgAzxGJGMcoRyC9IEFt/y /j/jj+Sf+C/mvxOP6N/p7//q/+wPFo/uL+8/8E/xX/Jv//N/9I/1n/av97/4z7gP+p//H18nDxLf G98U/xYPLh8G7/8H/xdvGH8ZjxqfMF8cvx3P/x7fH+8g/ysfIx8kLyU/Jk8PJ1/53ynPPn8yKSBU 5ZAjcw9wdWyO0ArxkKB7DW/cs3mbUJbC3gGJQDL8LjIAMAlj3R0owJlA19Dt3pJJnHCQoFCGcIqA mPX1kGNsC1B3n/GOcUmfOoL6cP/wZ5BARZD/0IqwDAPvkEGdYpbQ4EBmjqABoI8x199gmQAEUHKX UHNL4Iqi21IUkHNklzCZQHLjMd6wX4lCT+/ctJbQCmAiiqEifUjJY+AAVUGO0JbRV8JufVXBTZeQ ibGYEN+wTzF550vgArDgEWRvmQCYlFYfvzqCAgOPIgHyjsGXgT+ZcPvgIY3gbd/V4FCG4Yqi/aF8 ZXCdApECTh2KogYAUv9b31zkSOSdsJ3gVVGekQ/g9mQQQ4bhQ4ngnbCbYIcA9/2wEFBgUihesZmU KMGJQIA0LjcuMyAtTTTPRnDeoGI/OoIiV1HSTh/7/WGdMGkDcdsil5GXAGTFv1WDD8IJwSjRCpGE AGuNkP53lsJoX9y1MX8yjzOal5D/A+Eo0Jaw4RNRMVPhEHNkr32QYnDfsJeBhJCO0F9jUr2ZAHZu XzpzX/dL4WP9cfcD445xX7ZphEAo4JbQAbDfQWACMptAUTFBAGiJQVt1j1jJiq+axuESLVRFAUH/ AjBrQYngXmGb8kvgkHJ0Z3t1qF+FYkWAkHGYc30QVN9xEP2wfS86c5cgbJzQXmD/abDgEQQ0/+B6 oYyBAbCY4P9aAgFZAncSDyzvOM8vD4lf/zQPNR82Lzc/jF85XzpvO3//PI89nz6vP79Az0HfQu9D //8oX0XPRt+c34ivka+Kz4vf/6PvcF9xb40/jk+PX5Bvpi//ko+Tn5Svlb+Wz6DvmO+Z/z+bD5wf p09FD5+ftE8gM+1IUFNLdGeAKE1Dgz+wYv4xSEHhYmbzS7CxgL7kpVB7SFBIoGbfs0/A3gVnMTh/ ADRUdwEQS1TDYW4v3Hpk+VqAZnShz6LfuU+k/8jP/6n/qw+sH60vy8+vT7BfsW//sn+zj7Sfta+2 v7fPuN+57/+eT7u/1J/cT8gf0R/KP8tP/+Nfp9+o78yvzb/Oz8/f5Z//0f/TD9Qf1S/WP+Bf2F/Z b7/af9uP3J+6/98P8780vjldBUBhxU93x8JmQ/qyLeVgkC2+UHJ2UxBIsQE0/XuhJ3pADFF6Qm/A 3hB7AfcRc4YgS+FuczD+r+/C/nCda9AvSwD+cF1gci/6of/2kFMBTAB/YuEv4j/4r+Rf/wif6V/q b+t/7I8Ln+6v77//8M/x3/Lv8//1D/Yf9y/4P//5T92v+x8UbxwfB+8Q7woP/wsfIy/nP+hPDH8N jw6fD6//JW8RzxLfE+8U/xYPIC8YL/8ZPxpPG18cb/pfHt8zj8IRf75VJ2BMBQQvL5JMeF0zc/9N sUhxeeht8GXAOmBkcUtg7mzC8WvAUUBthTCGUEzg+2yhVcEiQtJYCj6PL5JlwP9CgHrhIP8iDzh/ JC9IHykv/yo/K08sX0sfLn8vjzCfMa//Mr8zzzTfNe82/zgPOR8df/8671PvW59Hb1BvSY9Kn2Kv /ycPKB9L/00PTh9PL2TvUU//Ul9Tb1R/VY9fr1evWL9Zz99a31vvOi9eX3MPNr41xQBvYVA+Hz8v QD9MhUCHUCB4UmVxhLBAcACExEIx4jlDsEN1cofABfCHIX/D9H3Ah8ACAEODfg9vEiLtXWBlRCDE UW3EUHYwQEH5f1B0d4OgQkBDoEOAgw//YH9hj3f/Y6+Jz2ivab9qz/9r34zPbf9vD3AfcS9yP3NP /3RfdW92f3ePeJ9c/3pvlZ//nU+JH5Ifiz+MT6RfZo9nn/+Nr46/j8+Q36afkv+UD5Uf/5Yvlz+h X5lfmm+bf5yPnZ83ea+gD7S/N3zpwbMyNf+ED4UVhxIGgP4wQTADYQKyx7vAwZECgGlnaANQnyDX fcB9kYIBa0HQd0JAAGGHQdBCsESxUlNWUEIR/Z8AYkKAA8B9z/93wdOnv8Ooz6naTVVTVMd/yI/J qdpOT7cQYWRBkQbQA0JgxXNMQUJFTF8gUkVRVUXKcCBvNGJqQpJ3xZBCQm5kV3+yxc+wwm1AsHO/ UXM/Q3RBAkIhBvAGobfAd2HdBABiBADP4AFgaMGRxKO/wcXDosJRA1PCcQbwLcSj/9C/sMLCl4IB 1AHSAAPgAECjAPDFc1RUTLcgaUJw90SQ/nHFgmNC8EMxAtJB8P+fINmFxKPSBb+/sKRBAIIB/na3 sIFQgfJCYEKwgTG3sfsAYcWCScTQ2fLUAcWC0DLvArED4ESQQfBjQUDSAAXx/0SRBAACkgQPsKTE o0HTt7D/Q0HFc58AxYADwNQxQoDgKv+CAeIP4xLk+eNfsMLlpgIR/9qiggHTwQPAwXJCQNS6z3D/ AaJAsMMUxYKjANny3tPCUf+HgemPRfMGgAARgrHFY0JANwOg/jC70HXSAcMUVVDzynDO8EFNh0WC AX2RQoDfu8DWG8HE3R+wpE7DwMVk/wXDgfLDI8GnQiJB8AYBhgD/AoDBYsWC8udB04IB1l9+i73E 92LWAgBAtzCfIEnDk3/x0sIyQdDZFcQB/rTZlET4T1dO+o38D9fz+4bE9f1DsEHyIn+xyp/Lr6na 66O5u7Bja9lyw6JCgGS/Yb/V1AC/QfECL7DC/pB36UDP26JEUP7j+RRjaUHxxDL/xAHNv87PCfn1 rwv130FC8P0K4GbC8EMA2YFActRQ2vH6btowZ4KAE9HbQUFA37DyaUFAZD+iL6M/ua+lX/8XD6pf q2+sf62PGg+vr7C//7HPst+z77T/BV8GbyO/G7//HM8d3x7vJg8hDyIfJU8kP/8xP7XPtt+377j/ NC+7H7wvyzMfOKI4fOBRdcRA4pHfQtPFj37f2XK/RDiAVeXi94Z3waDlUG8O4eT04dHx4D3esHAV UDXw0GMBo01B3lk+Ty9T2pA6QHUBwcRA/4dhwoGGoMLwCHABovgWh4GfxDKfAf8Q2YXzAUlDNbD/ AaPYkkNBRK8vYkN4gNATsK8UkM+xAaLSsVMM4HXaYf4iSUSFsdqk4VH5cEYAPjD/xHHyMExx8eDB 4eKjSn8vYv9CQxWPFp8trxi/U58o7yn//ysPLB9Wny4/L08wXzFvMn//M480nzWvNr83zzjfnp86 r/87v2cfUu9b71UPVh9uLybP/yffV39Yj1mfWq9wb1zPXd//Xu9f/2EPay9jL2Q/ZU9mX/9xjznv ad9+j2v/bQ94728v/4nPit+AaWjTgR+CL4M/hE/3hV+Gb3ydOb6Q63M+MEdxueegaXAUs9mB4HB2 cnD3UI9LhdoweOGzmJF7wJo190+Rz3HesCjhUM+wFMHesL2/ADOc0YlA4cKcxDO+kHvcE9ywdj2h 2kRKX/z2bPkJASBQDnDQY9qVl6nrUfdxn3KvBz1uCHDx4QxwTZL/QaCi36Pvc7pBocdPp6+kzvfE EJ9PeqJ1DuHZhdIwEwH1+XRv5VBnUGDakcLgQXF/PhIUU0LUl26tHz9k5VB3/i6Ib4l/ki+Ln7W/ dD91T/92X3dvuL95j3qfe698v33P/4efjj+A/5Cvkb+Sz2iPlJ//wY/JP7UPvg+3L7g/0E+qj/+r n7mfuq+7v7zP0o++77///8EPwh/DL81Pyc/LL8w/4O//zl/Pb+WfxbrHL8gxyK/o7/fGS8eP67cx 4b/Kn+OP5J/t6/MwnfCeUGZGoMbQTDHHAAGcNZyxNy4006/Uv//VyuX/5w/4r9FP+r/7z/Df//Hv 8v/+T+zP7d/u7w0hTtD8ZW1HkQ5QrzJHwkaCQtHvsSGyn6BTFDFsE/AOwEwx9U7Wc01BcA2hnrCg klBg9ndHwkfAcAvAnJEL8EISX6XSoJA/4EhRT2F2xvBp/mQT0D2RCP8/ZKCQrmNG0H+ulj4QFVCv QhOwQ1AVUHD/RxA9gp8RSEQAsBVhoPFAkdQ1MRJlc0DhSa60Dz/n3LISEsZhaWxDUEIgoQD9FUBF 9QCmMAcQsIQKQEnR3CJQr8AMEFBgQ5yATJA5r8AgRhcxsRFOQFNIME9VTERPU07hIiz/FX/cowyA F0Cmv/dv+H/8T//9Xx+/+e8h7wNvBH8FjyU/3+JPAM8B3yjmQHM1I9Abr7/cskyADuEU0BUGFtgs Iv//JA8ozynfKu8r/zM4FTNEE/8alS4vLzNB8J6QF4ivMDVg90CCGCOdQCD08UoBGLOuoawiUk2A CrNQPIBioMB2bU5AnUIuPqFNMaKgRLcOwDkf3KNJB8CfEHVDAGdGoC9xQwFzb68wpbJn/1IvMh8z LyCPQ89E30XvuN//1p/Xr9i/2c9HL9vv3P/eD/9KT+AvT2/pT+pf629WLyb//ygPWT//nzVfNm9c n0LfTq//WV9I32OvZL9lz2bfHd8e7/9Kn0uvTL9Nz2kfT+9Q/1IP/1MfVC9hD1nfV19Yb3gvWo+/ W597PzRfXx9gL37nVAyQuw3AElBmPJE/f3MyeaZQfV7Aa6GAOqGpwQsgslEh/2HPYt9+32fPiG+J f4qPSd//bS9uP29PcF+Lz3J/c490n/+O73a/lA9433nvev+az30f/34vnd9eD4EPgh+hP4d/k0// jG+Nf6hPqV+qb6t/as9r3/+PP5BPkV+Sb62/lI+Vn5av/5e/mM+lr55/m/+dD7zPny+/oD+/34AP o7+kz8OGQhbil4Rvt8IR0GejQGRzpl//p2/Db6xfy8/M383vjm+xv/+yz7PftO/PL7cPuB+5L9JP /7tP12+9b75/v4/eL8Gvwr//4T+in8Wfxq/klz1QDmDT4P5vyl/Lb+SP0F/rn+yv7b//0c/S39Pv 1P/WD+7/2C/ZP//aT/If3G/3P69fsG/yb/N/L/SP9Z/2r/e6NeJhL0KYT0RZ44D3qzI3A/FQSFRN TAcdM/iFfQEKEAAAHgBwAAEAAAAqAAAAQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxzcC10 dW5uZWwtMDgAAAALAAIAAQAAAAMA/T/kBAAAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEA AAABAAAAAAAAAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAAuACCAG AAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAAgFxAAEAAAAWAAAAAcDEIa176N5D6y/u EdWXqgDA8DwoAAAAQAA5AFDuLq4hxMABAwDxPwkEAAAeADFAAQAAAAgAAABURUlSTUFNAAMAGkAA AAAAHgAwQAEAAAAIAAAAVEVJUk1BTQADABlAAAAAAAMAJgAAAAAAAwA2AAAAAAADAIAQ/////wsA 8hABAAAAAgFHAAEAAAA7AAAAYz1TRTthPTQwMG5ldDtwPWVyaWNzc29uO2w9RUlUUk1OVDEwNS0w MTA0MTMxMzU3MzBaLTEyOTM3MwAAAgH5PwEAAABIAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAA AAAAAC9PPUVSSUNTU09OL09VPUVVMS9DTj1SRUNJUElFTlRTL0NOPVRFSVJNQU0AHgD4PwEAAAAV AAAAUm9iZXJ0byBNYW1lbGkgKFRFSSkAAAAAHgA4QAEAAAAIAAAAVEVJUk1BTQACAfs/AQAAAEgA AAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089RVJJQ1NTT04vT1U9RVUxL0NOPVJFQ0lQ SUVOVFMvQ049VEVJUk1BTQAeAPo/AQAAABUAAABSb2JlcnRvIE1hbWVsaSAoVEVJKQAAAAAeADlA AQAAAAgAAABURUlSTUFNAEAABzCioQGuIcTAAUAACDAIeYKuIcTAAR4APQABAAAAAQAAAAAAAAAe AB0OAQAAACoAAABDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1wbHMtbHNwLXR1bm5lbC0wOAAAAB4A NRABAAAANAAAADxCM0JENjU1NDZERUNENDExOEIyODAwMDJBNTJDRUJGNDMxNEI3NkBFSVRSTU5U MTA1PgALACkAAAAAAAsAIwAAAAAAAwAGEAZkEIIDAAcQNwwAAAMAEBAAAAAAAwAREAAAAAAeAAgQ AQAAAGUAAABIRUxMT0FMTCxJSEFWRVNPTUVPQlNFUlZBVElPTlNPTkRSQUZULUlFVEYtTVBMUy1S U1ZQLUxTUC1UVU5ORUwtMDhJSEFWRUdPTkVUSFJPVUdIVEhFTUFJTElOR0xJU1RCVVRJAAAAAAIB fwABAAAANAAAADxCM0JENjU1NDZERUNENDExOEIyODAwMDJBNTJDRUJGNDMxNEI3NkBFSVRSTU5U MTA1PgAtyg== ------_=_NextPart_000_01C0C421.AE2EEE50-- From owner-mpls@UU.NET Fri Apr 13 10:05:51 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08923 for ; Fri, 13 Apr 2001 10:05:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkou10377; Fri, 13 Apr 2001 14:03:37 GMT Received: by mail-control.mail.uu.net id QQkkou11215 for mpls-outgoing; Fri, 13 Apr 2001 14:03:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkou10850 for ; Fri, 13 Apr 2001 14:02:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkou13630 for ; Fri, 13 Apr 2001 14:02:29 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f244.law14.hotmail.com [64.4.21.244]) id QQkkou14795 for ; Fri, 13 Apr 2001 14:02:29 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 13 Apr 2001 07:02:28 -0700 Received: from 212.153.183.58 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 13 Apr 2001 14:02:28 GMT X-Originating-IP: [212.153.183.58] From: "MP LS" To: MPLS@UU.NET Subject: 2 LSRs over normal ATM using VCID notification RFC 3038 Date: Fri, 13 Apr 2001 16:02:28 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Apr 2001 14:02:28.0944 (UTC) FILETIME=[6044FD00:01C0C422] Sender: owner-mpls@UU.NET Precedence: bulk Hello all I have some questions about 2 MPLS LSR's between a normal ATM network. Is this possible with VCID notification RFC 3038? They describe a mechanism to connect a VC identifier to vci/vpi. With the meaning when that the upper label which normaly is encoded in vpi/vci will arive at the other LSR clearly (without being switched) when there are some other ATM switches between it. Could anyone explain me some more about this?? Thanks for anwsering my question. With kind regards, Niels Sitters _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Fri Apr 13 10:56:30 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09927 for ; Fri, 13 Apr 2001 10:56:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkox04712; Fri, 13 Apr 2001 14:54:19 GMT Received: by mail-control.mail.uu.net id QQkkox27084 for mpls-outgoing; Fri, 13 Apr 2001 14:53:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkox27069 for ; Fri, 13 Apr 2001 14:52:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkox17688 for ; Fri, 13 Apr 2001 14:52:31 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkkox02969 for ; Fri, 13 Apr 2001 14:52:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12644; Fri, 13 Apr 2001 10:52:28 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21512; Fri, 13 Apr 2001 10:52:32 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <2G598T1G>; Fri, 13 Apr 2001 10:52:30 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5530955A@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'MP LS'" , MPLS@UU.NET Subject: RE: 2 LSRs over normal ATM using VCID notification RFC 3038 Date: Fri, 13 Apr 2001 10:52:30 -0400 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 Niel It is very much possible to negotiate MPLS ATM label when 2 ATM LSRs/LERs are connected (RFC3038 explains) in different scenarios: * If MPLS capable ATM LSRs are connected directly then you don't need VCID. Because local significant VPI/VCI are same at both ends of PVC/SVC. * If MPLS capable ATM LSRs are not connected directly (i.e., to a pure ATM cloud): - If VP switching is used, then VCI is used as MPLS label. Because intermediate ATM switches won't look at/modify VCI field. - VCID exchange is not required. VCI may be used as VCID. This is a common scenario used by most of the current implementers. - You can negotiate/configure VPID. - If VC switching is used, then VPI/VCI may not be same at both ends of LSRs. So you need to map VCID to a VC in both LSRs. Of course, we can use inband/outband notification of VPID/VCID. Thanks & Regards Venkata Subbaiah Naidu -- http://www.geocities.com/kvsnaidu > Hello all > > I have some questions about 2 MPLS LSR's between a normal ATM network. > Is this possible with VCID notification RFC 3038? They > describe a mechanism > to connect a VC identifier to vci/vpi. With the meaning when > that the upper > label which normaly is encoded in vpi/vci will arive at the other LSR > clearly (without being switched) when there are some other > ATM switches > between it. Could anyone explain me some more about this?? > > Thanks for anwsering my question. > > With kind regards, > > Niels Sitters From owner-mpls@UU.NET Fri Apr 13 11:04:42 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10060 for ; Fri, 13 Apr 2001 11:04:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkoy13295; Fri, 13 Apr 2001 15:02:33 GMT Received: by mail-control.mail.uu.net id QQkkoy02879 for mpls-outgoing; Fri, 13 Apr 2001 15:02:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkoy02468 for ; Fri, 13 Apr 2001 15:01:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkox03404 for ; Fri, 13 Apr 2001 14:59:51 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkkox09361 for ; Fri, 13 Apr 2001 14:59:50 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 IAA16183; Fri, 13 Apr 2001 08:00:13 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA13601; Fri, 13 Apr 2001 10:59:48 -0400 (EDT) Message-Id: <200104131459.KAA13601@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: David Charlap cc: mpls@UU.NET Subject: Re: Use of LDP for VPNs In-reply-to: Your message of Thu, 12 Apr 2001 10:59:02 -0400. <3AD5C2B6.2268BD31@marconi.com> 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: Fri, 13 Apr 2001 10:59:47 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk David> RSVP-TE can do multipoint-to-point. If the extended tunnel ID is David> zero, then all senders using the same endpoint and tunnel ID will be David> in the same session. If SE style reservations are used, all paths in David> the session (from the ingress routers to the egress router) will David> share resources. A router that is capable of label-merging can David> choose to send the same label to all previous-hop routers in the David> session, effectively combining two (or more) RSVP paths into a single David> LSP. Yes, good point. I overlooked that because, as far as I know, no one is actually doing this. Even used in this manner, though, RSVP cannot achieve the level of efficiency achievable with LDP, if Downstream Unsolicited and Liberal Label Retention are used. From owner-mpls@UU.NET Fri Apr 13 12:21:01 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12408 for ; Fri, 13 Apr 2001 12:21:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkpd04671; Fri, 13 Apr 2001 16:17:55 GMT Received: by mail-control.mail.uu.net id QQkkpd10893 for mpls-outgoing; Fri, 13 Apr 2001 16:17:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkpd10882 for ; Fri, 13 Apr 2001 16:17:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkpc12412 for ; Fri, 13 Apr 2001 16:14:24 GMT From: wesam.alanqar@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQkkpc01064 for ; Fri, 13 Apr 2001 16:14:24 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f3DGOIF00275; Fri, 13 Apr 2001 11:24:18 -0500 (CDT) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f3DGE6a16113; Fri, 13 Apr 2001 11:14:06 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id LAA25457; Fri, 13 Apr 2001 11:14:05 -0500 (CDT) X-OpenMail-Hops: 1 Date: Fri, 13 Apr 2001 11:14:04 -0500 Message-Id: Subject: Clarifications on draft-kompella-ospf-gmpls-extensions-01 MIME-Version: 1.0 TO: ccamp@ops.ietf.org, mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-20365843-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-20365843-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Fri, 13 Apr 2001 11:14:04 -0500" Content-Transfer-Encoding: 8bit All, In draft-kompella-ospf-gmpls-extensions-01, the incoming & outgoing interface identifiers are 32-bits. Does this refer to the 32-bit "interface-ID" define in: Draft-ietf-mpls-rsvp-unnum-01 Draft-ietf-mpls-crldp-unnum-01 I.e., do we assume that incoming & outgoing interfaces that are advertised by IGPs are unnumbered or they can carry IP addresses. Thanks. ------------------------------------------------------------------------ ----------- Wesam Alanqar Member of Technical Staff Technology Research Group (TR) Technology Planning & Integration Dept. (TP&I) Sprint 9300 Metcalf Avenue, KS 66212 Phone: 913-534-5623 Work, Fax: 913-534-3485 ------------------------------------------------------------------------ ----------- --openmail-part-20365843-00000001 Content-Type: application/octet-stream Content-Disposition: attachment; filename="Wesam Alanqar (E-mail).vcf" ;Creation-Date="Fri, 13 Apr 2001 11:14:04 -0500" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkFsYW5xYXI7V2VzYW0NCkZOOldlc2FtIEFs YW5xYXIgKEUtbWFpbCkNCk9SRzpUZWNobm9sb2d5IFBsYW5uaW5nICYgSW50ZWdyYXRpb24t U3ByaW50O1RlY2hub2xvZ3kgUGxhbm5pbmcgJiBJbnRlZ3JhdGlvbg0KVElUTEU6TWVtYmVy IG9mIFRlY2huaWNhbCBTdGFmZg0KVEVMO1dPUks7Vk9JQ0U6KDkxMykgNTM0LTU2MjMNClRF TDtXT1JLO0ZBWDooOTEzKSA1MzQtMzQ4NQ0KQURSO1dPUks6Ozg1MTs5MzAwIE1ldGNhbGYg QXZlbnVlO092ZXJsYW5kIFBhcms7S1M7NjYyMTItMTQ2MztVbml0ZWQgU3RhdGVzIG9mIEFt ZXJpY2ENCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo4NTE9MEQ9MEE5 MzAwIE1ldGNhbGYgQXZlbnVlPTBEPTBBT3ZlcmxhbmQgUGFyaywgS1MgNjYyMTItMTQ2Mz0w RD0wQVVuaXRlZCBTPQ0KdGF0ZXMgb2YgQW1lcmljYQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDp3 ZXNhbS5hbGFucWFyQG1haWwuc3ByaW50LmNvbQ0KUkVWOjIwMDEwMTI5VDE4MjEyN1oNCkVO RDpWQ0FSRA0K --openmail-part-20365843-00000001-- From owner-mpls@UU.NET Fri Apr 13 12:41:25 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13498 for ; Fri, 13 Apr 2001 12:41:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkpe27328; Fri, 13 Apr 2001 16:39:08 GMT Received: by mail-control.mail.uu.net id QQkkpe12379 for mpls-outgoing; Fri, 13 Apr 2001 16:38:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkpe12362 for ; Fri, 13 Apr 2001 16:38:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkpe17277 for ; Fri, 13 Apr 2001 16:38:06 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkkpe26550 for ; Fri, 13 Apr 2001 16:38:05 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA14971 for ; Fri, 13 Apr 2001 09:38:05 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id JAA01018 for mpls@UU.NET; Fri, 13 Apr 2001 09:38:05 -0700 (PDT) Date: Fri, 13 Apr 2001 09:38:05 -0700 (PDT) From: Kireeti Kompella Message-Id: <200104131638.JAA01018@kummer.juniper.net> To: mpls@UU.NET Subject: Re: Clarifications on draft-kompella-ospf-gmpls-extensions-01 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk > In draft-kompella-ospf-gmpls-extensions-01, the incoming & outgoing > interface identifiers are 32-bits. Does this refer to the 32-bit > "interface-ID" define in: > > Draft-ietf-mpls-rsvp-unnum-01 > Draft-ietf-mpls-crldp-unnum-01 If you mean, can the interface identifiers defined in the ospf and isis documents be used in unnumbered EROs, then the answer is yes. > I.e., do we assume that incoming & outgoing interfaces that are > advertised by IGPs are unnumbered or they can carry IP addresses. While one can question the utility of putting both IP addresses and assigning unnumbered interface indices to an interface, this is not disallowed; and an interface that has both an IP address and an interface index may be referred to by either in an ERO. I would expect, however, that an interface is either numbered or unnumbered, not both. Kireeti. From owner-mpls@UU.NET Fri Apr 13 15:09:31 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16321 for ; Fri, 13 Apr 2001 15:09:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkpo29251; Fri, 13 Apr 2001 19:07:04 GMT Received: by mail-control.mail.uu.net id QQkkpo11174 for mpls-outgoing; Fri, 13 Apr 2001 19:06:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkpo10738 for ; Fri, 13 Apr 2001 19:06:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkpo26952 for ; Fri, 13 Apr 2001 19:05:30 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkkpo27639 for ; Fri, 13 Apr 2001 19:05:30 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA04941 for ; Fri, 13 Apr 2001 15:05:27 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA12690 for ; Fri, 13 Apr 2001 15:05:29 -0400 (EDT) Message-ID: <3AD74E26.C1680E0C@marconi.com> Date: Fri, 13 Apr 2001 15:06:15 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? References: <010401c0c3ea$8f4066e0$4520000a@sasi.com> <01de01c0c3ec$eb47e6f0$87ca09c0@dharti.aplion.stpn.soft.net> <012a01c0c3f2$041d39a0$4520000a@sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Rajesh P Jain wrote: > Well, if it requires L3 Routing table to build up the Label > information, then what is the advantage of MPLS??? Well, Anyhow, it > will require the building of L3 Routing Table (May be through > RIP/OSPF/BGP etc), then Lable info can be formed by using only L3. So, > Anyhow, MPLS is dependent on L3, please explain me what is the > advantage of using MPLS (in terms of efficiency and speed switching of > the packets). There are two reasons. One is that label-switched forwarding engines may be simpler. It is easier to look at a single fixed-size label to determine next-hop than it is to do a best-match against an IP destination. While there are forwarding chips that will do best-match forwarding at very high speeds (even line-rate OC-192), the algorithm is still more complicated than a label lookup. A simpler algorithm means (all other things being equal, which they rarely are) that simpler forwarding chips may be used, resulting in several potential savings (including smaller chips, fewer chips per board, lower power consumption, etc.) The second reason for MPLS is traffic engineering. If explicit routes are used (in CR-LDP or RSVP-TE), then a transit/egress router does not require the entire routing table. It only needs to know the addresses of its immediately-attached neighbors. The only router that needs the entire table is the ingress router, and even it doesn't need the whole table if the explicit routes are not automatically generated. From owner-mpls@UU.NET Fri Apr 13 15:13:54 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16384 for ; Fri, 13 Apr 2001 15:13:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkpo06876; Fri, 13 Apr 2001 19:11:46 GMT Received: by mail-control.mail.uu.net id QQkkpo17742 for mpls-outgoing; Fri, 13 Apr 2001 19:11:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkpo17550 for ; Fri, 13 Apr 2001 19:10:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkpo03489 for ; Fri, 13 Apr 2001 19:10:50 GMT Received: from mailhost.bravidacorp.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost-ext.bravidacorp.com [38.168.15.229] (may be forged)) id QQkkpo28281 for ; Fri, 13 Apr 2001 19:10:50 GMT Received: from MSeerypc (user-2ivfk86.dialup.mindspring.com [165.247.209.6]) by mailhost.bravidacorp.com (Mirapoint) with ESMTP id AAD12615 (AUTH mark); Fri, 13 Apr 2001 12:09:13 -0700 (PDT) From: "Mark Seery" To: "Abhijit Gadgil" , "Rajesh P Jain" Cc: "Bharti Batra" , Subject: RE: Does MPLS Require L3 Routing Table ? Date: Fri, 13 Apr 2001 12:07:00 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit To make the statement that the only way to program an MPLS FIB is via an IP control plane is not strictly speaking true, though the intent of the statement is understood. It is true however to say that there will be many capabilities not achieved if a network layer control plane is not used, such as the ones stated below. On the issue of performance, it is true that it is possible to use technology that does longest prefix match at wire rate. It is also true that there are issues not related to performance in using such technology, and that these issues may or may not make a difference depending on the overall design goals and application of the system. It is also true that due to the continued evolution of silicon, even these differences may not exist at some point in the future. -mark.s. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Abhijit Gadgil Sent: Friday, April 13, 2001 5:30 AM To: Rajesh P Jain Cc: Bharti Batra; mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? MPLS does require layer 3 routing information. It works together with Layer 3 routing information like OSPF / BGP etc. However the advantage of MPLS is in terms of being able to label switch after it has formed the LSPs. This is useful in case of hardware that cannot look into IP header like ATM switches. Another advantage of MPLS is in terms of creating explicitely routed label switched paths, which is useful in Traffic Engineering. The original motivation for MPLS of being able to outperform IP lookup is not the motivation for MPLS these days. Another advantage of MPLS is its better than IP over ATM. Thus the advantages of MPLS can be listed as follows. 1. Making use of network layer routing to create label switched paths. 2. No need to maintain 2 networks as in IP over ATM case. 3. Alleviating N^2 mesh problem common with ATM switches hope that helps -abhijit On Fri, 13 Apr 2001, Rajesh P Jain wrote: >"Hello", > Thanks for the response. > > Well, if it requires L3 Routing table to build up the Label information, then what is the advantage of MPLS??? Well, Anyhow, it will require the building of L3 Routing Table (May be through RIP/OSPF/BGP etc), then Lable info can be formed by using only L3. So, Anyhow, MPLS is dependent on L3, please explain me what is the advantage of using MPLS (in terms of efficiency and speed switching of the packets). > >With Regards > Rajesh P Jain > ----- Original Message ----- > From: Bharti Batra > To: Rajesh P Jain ; mpls@UU.NET > Sent: Friday, April 13, 2001 1:09 PM > Subject: Re: Does MPLS Require L3 Routing Table ? > > > Hi ! > > Yes. LDP needs IP routing table to find out the route towards the egress router to setup the LSP. LDP sends the LSP setup request message along this path. > > Regds, > Bharti > ----- Original Message ----- > From: Rajesh P Jain > To: mpls@UU.NET > Sent: Friday, April 13, 2001 12:52 PM > Subject: Does MPLS Require L3 Routing Table ? > > > "Hello", List, > Well, I am very new to Jthe MPLS domain. I >just wanted to check out whether MPLS domain neccesarily require the L3 Routing Table (Maybe IP Routing Table) to build up it's label (using the LDP Protocol). Or the LDP will take care of building the label information automatically without the L3 Routing information? > > TIA > Rajesh P Jain > From owner-mpls@UU.NET Fri Apr 13 15:37:19 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16734 for ; Fri, 13 Apr 2001 15:37:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkpq27146; Fri, 13 Apr 2001 19:35:03 GMT Received: by mail-control.mail.uu.net id QQkkpq21298 for mpls-outgoing; Fri, 13 Apr 2001 19:34:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkpq21149 for ; Fri, 13 Apr 2001 19:34:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkpq14118 for ; Fri, 13 Apr 2001 19:33:05 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkkpq25911 for ; Fri, 13 Apr 2001 19:33:05 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06531; Fri, 13 Apr 2001 15:33:02 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17171; Fri, 13 Apr 2001 15:33:06 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <2G59899H>; Fri, 13 Apr 2001 15:33:04 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5530955C@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Mark Seery'" , Abhijit Gadgil , Rajesh P Jain , "Charlap, David" Cc: Bharti Batra , mpls@UU.NET Subject: RE: Does MPLS Require L3 Routing Table ? Date: Fri, 13 Apr 2001 15:33:00 -0400 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, I got a doubt (and to extend it more)... * Can we manually configure MPLS labels, just like PVCs in ATM, for any Layer 2. (call it Permanent LSPs) In that sense I hope we don't need any control plane (Signaling - LDP/RSVP or Routing OSPF/IS-IS etc) * Is it allowed or used in MPLS (forwarding plane) terminology? Because, in ATM, SVCs are expensive and rarely used where as PVC are feasible/preferable. Thanks & Regards Venkata Subbaiah Naidu -- http://www.geocities.com/kvsnaidu > -----Original Message----- > From: Mark Seery [mailto:mark@bravidacorp.com] > Sent: Friday, April 13, 2001 3:07 PM > To: Abhijit Gadgil; Rajesh P Jain > Cc: Bharti Batra; mpls@UU.NET > Subject: RE: Does MPLS Require L3 Routing Table ? > > > To make the statement that the only way to program an MPLS > FIB is via an IP > control plane is not strictly speaking true, though the intent of the > statement is understood. It is true however to say that there > will be many > capabilities not achieved if a network layer control plane is > not used, such > as the ones stated below. > > On the issue of performance, it is true that it is possible to use > technology that does longest prefix match at wire rate. It is > also true that > there are issues not related to performance in using such > technology, and > that these issues may or may not make a difference depending > on the overall > design goals and application of the system. It is also true > that due to the > continued evolution of silicon, even these differences may > not exist at some > point in the future. > > -mark.s. > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Abhijit > Gadgil > Sent: Friday, April 13, 2001 5:30 AM > To: Rajesh P Jain > Cc: Bharti Batra; mpls@UU.NET > Subject: Re: Does MPLS Require L3 Routing Table ? > > > > MPLS does require layer 3 routing information. It works together with > Layer 3 routing information like OSPF / BGP etc. However the > advantage of > MPLS is in terms of being able to label switch after it has formed the > LSPs. This is useful in case of hardware that cannot look > into IP header > like ATM switches. Another advantage of MPLS is in terms of creating > explicitely routed label switched paths, which is useful in Traffic > Engineering. The original motivation for MPLS of being able > to outperform > IP lookup is not the motivation for MPLS these days. Another > advantage of > MPLS is its better than IP over ATM. Thus the advantages of > MPLS can be > listed as follows. > 1. Making use of network layer routing to create label switched paths. > 2. No need to maintain 2 networks as in IP over ATM case. > 3. Alleviating N^2 mesh problem common with ATM switches > > hope that helps > > -abhijit > > On Fri, 13 Apr 2001, Rajesh P Jain wrote: > > >"Hello", > > Thanks for the response. > > > > Well, if it requires L3 Routing > table to build up > the Label information, then what is the advantage of MPLS??? > Well, Anyhow, > it will require the building of L3 Routing Table (May be through > RIP/OSPF/BGP etc), then Lable info can be formed by using only L3. So, > Anyhow, MPLS is dependent on L3, please explain me what is > the advantage of > using MPLS (in terms of efficiency and speed switching of the > packets). > > > >With Regards > > Rajesh P Jain > > ----- Original Message ----- > > From: Bharti Batra > > To: Rajesh P Jain ; mpls@UU.NET > > Sent: Friday, April 13, 2001 1:09 PM > > Subject: Re: Does MPLS Require L3 Routing Table ? > > > > > > Hi ! > > > > Yes. LDP needs IP routing table to find out the route > towards the egress > router to setup the LSP. LDP sends the LSP setup request > message along this > path. > > > > Regds, > > Bharti > > ----- Original Message ----- > > From: Rajesh P Jain > > To: mpls@UU.NET > > Sent: Friday, April 13, 2001 12:52 PM > > Subject: Does MPLS Require L3 Routing Table ? > > > > > > "Hello", List, > > Well, I am very new to Jthe MPLS domain. I > >just > wanted to check out whether MPLS domain neccesarily require > the L3 Routing > Table (Maybe IP Routing Table) to build up it's label (using the LDP > Protocol). Or the LDP will take care of building the label information > automatically without the L3 Routing information? > > > > TIA > > Rajesh P Jain > > > > From owner-mpls@UU.NET Fri Apr 13 15:51:14 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16851 for ; Fri, 13 Apr 2001 15:51:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkpr29994; Fri, 13 Apr 2001 19:49:03 GMT Received: by mail-control.mail.uu.net id QQkkpr23313 for mpls-outgoing; Fri, 13 Apr 2001 19:48:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkpr23303 for ; Fri, 13 Apr 2001 19:48:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkpr25069 for ; Fri, 13 Apr 2001 19:46:54 GMT Received: from mailhost.bravidacorp.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost-ext.bravidacorp.com [38.168.15.229] (may be forged)) id QQkkpr25062 for ; Fri, 13 Apr 2001 19:46:53 GMT Received: from MSeerypc (user-2ivfk86.dialup.mindspring.com [165.247.209.6]) by mailhost.bravidacorp.com (Mirapoint) with ESMTP id AAD12662 (AUTH mark); Fri, 13 Apr 2001 12:46:46 -0700 (PDT) From: "Mark Seery" To: "Naidu, Venkata" Cc: Subject: RE: Does MPLS Require L3 Routing Table ? Date: Fri, 13 Apr 2001 12:44:32 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <39469E08BD83D411A3D900204840EC5530955C@vie-msgusr-01.dc.fore.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Venkata, >> All, >> I got a doubt (and to extend it more)... >> >>* Can we manually configure MPLS labels, just like >> PVCs in ATM, for any Layer 2. (call it Permanent LSPs) >> In that sense I hope we don't need any control plane >> (Signaling - LDP/RSVP or Routing OSPF/IS-IS etc) There is no technological barrier to manual configuration. There are layer 2 VPN approaches that could work this way. There have been various discussions on a variety of emailers regarding which vendors do or do not support static LSPs. I would refer you to individual vendors for their own comments. So even given that static LSPs might be supported by your vendor of choice, there are still considerations about whether that approach is most suited to a) the application b) the operational mode of the network operator. -mark From owner-mpls@UU.NET Fri Apr 13 16:09:36 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17144 for ; Fri, 13 Apr 2001 16:09:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkps18887; Fri, 13 Apr 2001 20:07:19 GMT Received: by mail-control.mail.uu.net id QQkkps11922 for mpls-outgoing; Fri, 13 Apr 2001 20:06:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkps11904 for ; Fri, 13 Apr 2001 20:06:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkps28084 for ; Fri, 13 Apr 2001 20:05:17 GMT Received: from mailhost.bravidacorp.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost-ext.bravidacorp.com [38.168.15.229] (may be forged)) id QQkkps06249 for ; Fri, 13 Apr 2001 20:05:16 GMT Received: from MSeerypc (user-2ivfk86.dialup.mindspring.com [165.247.209.6]) by mailhost.bravidacorp.com (Mirapoint) with ESMTP id AAD12703 (AUTH mark); Fri, 13 Apr 2001 13:05:12 -0700 (PDT) From: "Mark Seery" To: "Aris Kyriakopoulos" Cc: Subject: RE: Does MPLS Require L3 Routing Table ? Date: Fri, 13 Apr 2001 13:02:59 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Aris, [snip] >>If there are benefits to using MPLS as a pure L2 switching mechanism (without any L3 routing integration) I would certainly like to know. To deny a network operator the ability to impose a static forwarding decision, in the context of either an IP or MPLS forwarding component, is to deny a network operator the ability to pre-influence network behavior based on the output of either their own grey matter, or that of a sophisticated network analysis tool. There are various well presented arguments for and against such approaches, but ultimately this is a decision that should remain with the network operator. -mark From owner-mpls@UU.NET Fri Apr 13 16:30:27 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17375 for ; Fri, 13 Apr 2001 16:30:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkpt04565; Fri, 13 Apr 2001 20:28:08 GMT Received: by mail-control.mail.uu.net id QQkkpt13951 for mpls-outgoing; Fri, 13 Apr 2001 20:27:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkpt13933 for ; Fri, 13 Apr 2001 20:27:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkpt02025 for ; Fri, 13 Apr 2001 20:26:57 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkkpt05203 for ; Fri, 13 Apr 2001 20:26:56 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09823; Fri, 13 Apr 2001 16:26:53 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25943; Fri, 13 Apr 2001 16:26:57 -0400 (EDT) Message-ID: <3AD7613F.3B73B9F@marconi.com> Date: Fri, 13 Apr 2001 16:27:43 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: anilg@acc.am.ericsson.se CC: mpls@UU.NET Subject: Re: LDP Ingress References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anil Gunturu wrote: > > In case of LDP, how do you determine if the particular interface is > Ingress or not? Do we statically configure this? Static configuration is certainly one possibility. In theory, any interface capable of receiving unlabeled traffic, classifying that traffic, and pushing a label, can be an ingress interface. This set may further be narrowed by applying heuristics, depending on the application. For instance, if the LSPs are used exclusively for sending traffic across an OSPF area, and no further, then only the area-border routers will have ingress interfaces. Of course, an operator may not be happy with any kind of automatic decision, so manual configuration must alwas be an option. > For an FEC if the next hop is not MPLS we can say that it is an > egress LER. But, can we infer this for an Ingress LER? Egress LERs that are chosen in this fashion can be said to be at the edge of the MPLS cloud. And they make nice candidates for selection as ingress routers. But this isn't necessarily all of them. -- David From owner-mpls@UU.NET Fri Apr 13 16:32:57 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17515 for ; Fri, 13 Apr 2001 16:32:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkpu04831; Fri, 13 Apr 2001 20:30:43 GMT Received: by mail-control.mail.uu.net id QQkkpu14286 for mpls-outgoing; Fri, 13 Apr 2001 20:30:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkpt14142 for ; Fri, 13 Apr 2001 20:29:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkpt09238 for ; Fri, 13 Apr 2001 20:29:20 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkkpt10750 for ; Fri, 13 Apr 2001 20:29:20 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA10012; Fri, 13 Apr 2001 16:29:10 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA26483; Fri, 13 Apr 2001 16:29:14 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <2G599BJ8>; Fri, 13 Apr 2001 16:29:12 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5530955D@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Aris Kyriakopoulos'" Cc: Bharti Batra , "Charlap, David" , Abhijit Gadgil , "'Mark Seery'" , mpls@UU.NET, Rajesh P Jain Subject: RE: Does MPLS Require L3 Routing Table ? Date: Fri, 13 Apr 2001 16:29:11 -0400 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 Aris, > There is nothing in the MPLS architecture that forbids the > use of static > LSPs. In fact, most major vendors do support configuration of static > LSPs, in addition to hop-by-hop or constraint-routed LSPs. > However, they > are not addressed in 3031 (or any other draft standards/IDs > that I know > of) because the stated goal of the MPLS WG is to develop a Layer 2 > switching technology controlled by a Layer 3 routing protocol. > > This, I believe, is the crux of the argument. If one chooses not to Yes! > implement the MPLS control plane, then one is reduced to yet > another L2 > switching protocol. In that case, why not juse use ATM? Or > Frame Relay? > If there are benefits to using MPLS as a pure L2 switching mechanism > (without any L3 routing integration) I would certainly like to know. Sorry for my unclear question... My question is not whether to implement MPLS control plane or not! But, If I would like to support MPLS, I don't need to have LDP/RSVP. I just want to make my traditional router (connected to different L2) MPLS enabled using static label configured MPLS forwarding plane. I can make it for dynamic LSPs if I like to. It is always an option for the network operator. The data after labels is still IP. Thanks & Regards Venkata Naidu -- http://www.geocities.com/kvsnaidu From owner-mpls@UU.NET Fri Apr 13 17:50:30 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19172 for ; Fri, 13 Apr 2001 17:50:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkpz07706; Fri, 13 Apr 2001 21:48:02 GMT Received: by mail-control.mail.uu.net id QQkkpz08291 for mpls-outgoing; Fri, 13 Apr 2001 21:47:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkpz08283 for ; Fri, 13 Apr 2001 21:47:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkpz07406 for ; Fri, 13 Apr 2001 21:47:09 GMT Received: from hoemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkkpz05948 for ; Fri, 13 Apr 2001 21:47:08 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA14898 for ; Fri, 13 Apr 2001 17:47:08 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA14892; Fri, 13 Apr 2001 17:47:07 -0400 (EDT) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA00951; Fri, 13 Apr 2001 17:47:06 -0400 (EDT) To: "Naidu, Venkata" Cc: mpls@UU.NET Subject: RE: Does MPLS Require L3 Routing Table ? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Aris Kyriakopoulos" Date: Fri, 13 Apr 2001 17:41:47 -0400 X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 04/13/2001 17:41:50, Serialize complete at 04/13/2001 17:41:50 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Venkata, Your explanation below was excellent, and I thank you for your efforts. Again, let me make it clear that I am NOT opposed to an MPLS implementation allowing static LSPs; giving the operator a choice is a good idea for the reasons you mention. Let me add another application: manually set-up traffic engineered LSPs. Cheers! -Aris -- Aris Kyriakopoulos Interoperability Test Engineering, PSAX CO Products Lucent Technologies Landover, MD mobile: (301) 332-2840 office: (301) 809-4509 mailto:aris@lucent.com "Naidu, Venkata" 04/13/2001 05:34 PM To: "'Aris Kyriakopoulos'" cc: Subject: RE: Does MPLS Require L3 Routing Table ? Hi Aris Glad that we are in sync... > Hi Venkata, > > Thanks for the clarification. My answer for you is that how > well static > LSPs will work in an IP world will depend on the > implementation. If you > treat your static LSPs as a routing adjacency for OSPF (or > whatever your > favorite routing protocol is), then they will work just fine. Exactly! > However, if you associate static labels with FECs, that's > when you lose > your ability to really use your L3 routing protocol! Because > what happens > if your routing table changes? But Aris, we can least expect from static LSPs, if the routing table changes. Consider "static LSPs (for IP switching)" similar to "static routing table (for IP routing)" or "static VCs (in ATM switching)". It is difficult to have static LSPs work along with dynamic routing changes. To compare well, even traditional dynamic routing protocols (like OSPF/IS-IS etc) allow room for "static" routing configuration and expose them as external LSAs. Finally we are more intelligent than machines - because we do them. So do we expect "static" LSP configuration as an option. > Just as an aside, I have been struggling with the concept of > static LSPs > myself. I'm trying very hard to find out what their true > utility is, and > I have seen very little discussion on the subject, either on > the list or > in the standards. I've talked to a couple of people about > the subject. > Most of the responses, however, have come from the L2 point of view > (static LSP = ATM PVC, etc). For the reasons discussed in my > previous > e-mail, I'm not comfortable with that analogy. Your query gave me an > opportunity to ask the experts! Good luck! Venkata Naidu -- http://www.geocities.com/kvsnaidu From owner-mpls@UU.NET Fri Apr 13 19:48:19 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20722 for ; Fri, 13 Apr 2001 19:48:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkqh22452; Fri, 13 Apr 2001 23:45:55 GMT Received: by mail-control.mail.uu.net id QQkkqh22202 for mpls-outgoing; Fri, 13 Apr 2001 23:45:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkqg22065 for ; Fri, 13 Apr 2001 23:44:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkqg12267 for ; Fri, 13 Apr 2001 23:44:54 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkqg20173 for ; Fri, 13 Apr 2001 23:44:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA14313 for mpls@uu.net; Fri, 13 Apr 2001 19:44:53 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkqg21619 for ; Fri, 13 Apr 2001 23:40:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkqg28027 for ; Fri, 13 Apr 2001 23:40:16 GMT Received: from ganymede.or.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns01.or.intel.com [134.134.248.3]) id QQkkqg17495 for ; Fri, 13 Apr 2001 23:40:15 GMT Received: from SMTP (orsmsx226.jf.intel.com [192.168.65.226]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id XAA25388; Fri, 13 Apr 2001 23:39:18 GMT Received: from orsmsx228.JF.INTEL.COM ([192.168.70.228]) by 192.168.70.226 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 13 Apr 2001 23:39:18 0000 (GMT) Received: by ORSMSX228 with Internet Mail Service (5.5.2653.19) id <27AV1XFZ>; Fri, 13 Apr 2001 16:39:15 -0700 Message-ID: From: "Sharma, Prem" To: "'Don Fedyk'" , Loa Andersson Cc: "Sharma, Prem" , manoj juneja , mpls@UU.NET Subject: RE: RE: Valid Race Condition related to draft "draft-ietf-mpls-cr lsp -modify-03.txt" Date: Fri, 13 Apr 2001 14:33:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C461.5CD1F7B0" 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_01C0C461.5CD1F7B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Don, =20 I feel, the requirement that CRLSP modification procedures described in = the=20 draft, are applicable to strictly routed LSPs only, is a MAJOR = requirement. This is just not there in the draft. Do you folks want to address this = in the=20 next revision of the draft? =20 One more thing, in my opinion, nothing precludes that modifications = should not be=20 allowed on loosely routed hops. There could be a requirement. This is a different case that current draft doesn't address that. =20 Thanks. Prem -----Original Message----- From: Don Fedyk [mailto:dwfedyk@nortelnetworks.com] Sent: Friday, April 13, 2001 8:21 AM To: Loa Andersson Cc: Sharma Prem; manoj juneja; mpls@UU.NET Subject: RE: RE: Valid Race Condition related to draft = "draft-ietf-mpls-cr lsp -modify-03.txt" Loa=20 The draft was targeted for strictly routed LSP ingress to egress=20 that are generated by constraints. The function it provide is=20 defining the behavior of TLVs defined to correlate the paths=20 attributes. The downstream nodes recognize this as a path=20 request for the same LSP, with changed attributes, allowing path=20 processing to continue where it might otherwise be aborted.=20 Your solution below yields non optimal paths in many cases=20 and provides the motive for the draft. The paths share LSPid.=20 Don=20 > -----Original Message-----=20 > From: Loa Andersson [ mailto:loa.andersson@utfors.se ]=20 > Sent: Thursday, April 12, 2001 10:04 AM=20 > To: Fedyk, Don [BL60:2868:EXCH]=20 > Cc: Sharma Prem; manoj juneja; mpls@UU.NET=20 > Subject: Re: RE: Valid Race Condition related to draft=20 > "draft-ietf-mpls-crlsp -modify-03.txt"=20 >=20 >=20 > Don,=20 >=20 > do I understand you correctly that the draft is applicable only in=20 > the situation where you have a strictly routed LSP ingress to egress? = > If so I rest my case, but I also fail to see why we need the draft.=20 > Just "locally" set up your alternate paths, signal that the traffic=20 > will be sent on the new path, switch over the traffic and tear the=20 > old path down. Nothing modificational (is ther such a word?) about=20 > it.=20 >=20 > /Loa=20 >=20 > ----- Original Message -----=20 > > Loa, Sharma, Manoj:=20 > >=20 > > Let me see if I can clarify my position on this.=20 > > My mail has been backed up lately. Sorry for the delay.=20 >=20 > > > --=20 > > > Loa Andersson=20 > > > Chief Architect,=20 > > > Utfors Research, Architecture and Future Lab (URAX)=20 > > > Utfors AB=20 > > > R=E5sundav=E4gen 12=20 > > > Box 525, 169 29 Solna=20 > > > Office +46 8 5270 2000=20 > > > Office direct +46 8 5270 5038=20 > > > Mobile +46 70 848 5038=20 > > > Email loa.andersson@utfors.se=20 > > > WWW www.utfors.se=20 > > >=20 > >=20 >=20 >=20 ------_=_NextPart_001_01C0C461.5CD1F7B0 Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkkqh22452 Content-Transfer-Encoding: quoted-printable RE: RE: Valid Race Condition related to draft "draft-ietf-mpls-crl= sp -modify-03.txt"
Hi=20 Don,
 
I=20 feel, the requirement that CRLSP modification procedures described in=20 the 
draft,=20 are applicable to strictly routed LSPs only, is a MAJOR=20 requirement.
This=20 is just not there in the draft. Do you folks want to = address=20 this in the
next=20 revision of the draft?
 
One=20 more thing, in my opinion, nothing precludes that modifications should no= t be=20
allowed on loosely routed hops. There could be= a=20 requirement. This is a different
case=20 that current draft doesn't address that.
 
Thanks.
Prem
-----Original Message-----
From: Don Fedyk=20 [mailto:dwfedyk@nortelnetworks.com]
Sent: Friday, April 13, 2= 001=20 8:21 AM
To: Loa Andersson
Cc: Sharma Prem; manoj ju= neja;=20 mpls@UU.NET
Subject: RE: RE: Valid Race Condition related to = draft=20 "draft-ietf-mpls-cr lsp -modify-03.txt"

Loa

The draft was targeted for strictly routed LSP ingres= s to=20 egress
that are generated by constraints. The= function=20 it provide is
defining the behavior of TLVs d= efined to=20 correlate the paths
attributes. The downstrea= m nodes=20 recognize this as a path
request for the same= LSP,=20 with changed attributes, allowing path
proces= sing to=20 continue where it might otherwise be aborted.
Your=20 solution below yields non optimal paths in many cases
and provides the motive for the draft. The paths share LSPid.<= /FONT>=20

Don

> -----Original Message-----
>=20 From: Loa Andersson [mailto:loa.andersson@utfors.se<= /A>]=20
> Sent: Thursday, April 12, 2001 10:04 AM =
> To: Fedyk, Don [BL60:2868:EXCH]
> Cc:=20 Sharma Prem; manoj juneja; mpls@UU.NET
> S= ubject:=20 Re: RE: Valid Race Condition related to draft
>=20 "draft-ietf-mpls-crlsp -modify-03.txt"
>=20
>
> Don,=20
>
> do I understand = you=20 correctly that the draft is applicable only in
>=20 the situation where you have a strictly routed LSP ingress to egress?=20
> If so I rest my case, but I also fail to see wh= y we need=20 the draft.
> Just "locally" set up your al= ternate=20 paths, signal that the traffic
> will be s= ent on=20 the new path, switch over the traffic and tear the
> old path down. Nothing modificational (is ther such a wor= d?)=20 about
> it.
>= =20
> /Loa
>=20
> ----- Original Message -----
= > > Loa, Sharma, Manoj:
> &= gt;=20
> > Let me see if I can clarify my posi= tion on=20 this.
> > My mail has been backed up la= tely.=20 Sorry for the delay.
>
>=20 > > --
> > > Loa Andersson=20
> > > Chief Architect,
>=20 > > Utfors Research, Architecture and Future Lab (URAX) > > > Utfors AB
> > &= gt;=20 R=E5sundav=E4gen 12
> > > Box 525, 1= 69 29=20 Solna
> > >=20 Office          +46 8 5270= =20 2000
> > > Office direct  = +46 8=20 5270 5038
> > >=20 Mobile          +46 70 848= =20 5038
> > >=20 Email          =20 loa.andersson@utfors.se
> > >=20 WWW           &n= bsp;=20 www.utfors.se
> > >
> >
>
>=20

------_=_NextPart_001_01C0C461.5CD1F7B0-- From owner-mpls@UU.NET Fri Apr 13 19:56:10 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20821 for ; Fri, 13 Apr 2001 19:56:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkqh09941; Fri, 13 Apr 2001 23:53:43 GMT Received: by mail-control.mail.uu.net id QQkkqh23231 for mpls-outgoing; Fri, 13 Apr 2001 23:53:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkqh23209 for ; Fri, 13 Apr 2001 23:53:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkqh13296 for ; Fri, 13 Apr 2001 23:53:07 GMT Received: from hebe.or.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns02.or.intel.com [134.134.248.4]) id QQkkqh17662 for ; Fri, 13 Apr 2001 23:53:07 GMT Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id XAA28533 for ; Fri, 13 Apr 2001 23:53:06 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 13 Apr 2001 23:31:35 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id <27G0BDVQ>; Fri, 13 Apr 2001 16:31:34 -0700 Message-ID: From: "Bakshi, Sanjay" To: mpls@UU.NET Subject: A question. Date: Fri, 13 Apr 2001 13:49:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello, I have a simple question for which I think I know the answer but cannot find the reference in the RFCs to de certain. What happens when a unlabeled packet is received by a LER and there is no FEC entry corresponding to the packet? I know this falls under the data-driven label binding operation, in which LDP is trigerred by the arriving packet. But I have not found a reference to it in any RFC to back my assumption up. Any pointers? thanks sanjay From owner-mpls@UU.NET Sat Apr 14 04:35:30 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10101 for ; Sat, 14 Apr 2001 04:35:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkoz10368; Fri, 13 Apr 2001 15:24:05 GMT Received: by mail-control.mail.uu.net id QQkkoz17850 for mpls-outgoing; Fri, 13 Apr 2001 15:23:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkoz17820 for ; Fri, 13 Apr 2001 15:23:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkoz22059 for ; Fri, 13 Apr 2001 15:21:23 GMT Received: from zcars04e.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQkkoz07686 for ; Fri, 13 Apr 2001 15:21:23 GMT Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Fri, 13 Apr 2001 11:21:09 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 11:21:11 -0400 Message-ID: From: "Don Fedyk" To: Loa Andersson Cc: Sharma Prem , manoj juneja , mpls@UU.NET Subject: RE: RE: Valid Race Condition related to draft "draft-ietf-mpls-cr lsp -modify-03.txt" Date: Fri, 13 Apr 2001 11:21:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C42D.5C8F9520" 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_01C0C42D.5C8F9520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Loa The draft was targeted for strictly routed LSP ingress to egress that are generated by constraints. The function it provide is=20 defining the behavior of TLVs defined to correlate the paths=20 attributes. The downstream nodes recognize this as a path=20 request for the same LSP, with changed attributes, allowing path=20 processing to continue where it might otherwise be aborted.=20 Your solution below yields non optimal paths in many cases=20 and provides the motive for the draft. The paths share LSPid. Don > -----Original Message----- > From: Loa Andersson [mailto:loa.andersson@utfors.se] > Sent: Thursday, April 12, 2001 10:04 AM > To: Fedyk, Don [BL60:2868:EXCH] > Cc: Sharma Prem; manoj juneja; mpls@UU.NET > Subject: Re: RE: Valid Race Condition related to draft > "draft-ietf-mpls-crlsp -modify-03.txt" >=20 >=20 > Don, >=20 > do I understand you correctly that the draft is applicable only in > the situation where you have a strictly routed LSP ingress to egress? > If so I rest my case, but I also fail to see why we need the draft. > Just "locally" set up your alternate paths, signal that the traffic > will be sent on the new path, switch over the traffic and tear the > old path down. Nothing modificational (is ther such a word?) about > it. >=20 > /Loa >=20 > ----- Original Message ----- > > Loa, Sharma, Manoj: > >=20 > > Let me see if I can clarify my position on this. > > My mail has been backed up lately. Sorry for the delay. >=20 > > > --=20 > > > Loa Andersson > > > Chief Architect, > > > Utfors Research, Architecture and Future Lab (URAX) > > > Utfors AB > > > R=E5sundav=E4gen 12 > > > Box 525, 169 29 Solna > > > Office +46 8 5270 2000 > > > Office direct +46 8 5270 5038 > > > Mobile +46 70 848 5038 > > > Email loa.andersson@utfors.se > > > WWW www.utfors.se > > >=20 > >=20 >=20 >=20 ------_=_NextPart_001_01C0C42D.5C8F9520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE: Valid Race Condition related to draft = "draft-ietf-mpls-crlsp -modify-03.txt"

Loa

The draft was targeted for strictly routed LSP = ingress to egress
that are generated by constraints. The function it = provide is
defining the behavior of TLVs defined to correlate = the paths
attributes. The downstream nodes recognize this as a = path
request for the same LSP, with changed attributes, = allowing path
processing to continue where it might otherwise be = aborted.
Your solution below yields non optimal paths in many = cases
and provides the motive for the draft. The paths = share LSPid.

Don

> -----Original Message-----
> From: Loa Andersson [mailto:loa.andersson@utfors.se]
> Sent: Thursday, April 12, 2001 10:04 AM
> To: Fedyk, Don [BL60:2868:EXCH]
> Cc: Sharma Prem; manoj juneja; = mpls@UU.NET
> Subject: Re: RE: Valid Race Condition related = to draft
> "draft-ietf-mpls-crlsp = -modify-03.txt"
>
>
> Don,
>
> do I understand you correctly that the draft is = applicable only in
> the situation where you have a strictly routed = LSP ingress to egress?
> If so I rest my case, but I also fail to see = why we need the draft.
> Just "locally" set up your alternate = paths, signal that the traffic
> will be sent on the new path, switch over the = traffic and tear the
> old path down. Nothing modificational (is ther = such a word?) about
> it.
>
> /Loa
>
> ----- Original Message -----
> > Loa, Sharma, Manoj:
> >
> > Let me see if I can clarify my position on = this.
> > My mail has been backed up lately. Sorry = for the delay.
>
> > > --
> > > Loa Andersson
> > > Chief Architect,
> > > Utfors Research, Architecture and = Future Lab (URAX)
> > > Utfors AB
> > > R=E5sundav=E4gen 12
> > > Box 525, 169 29 Solna
> > > = Office          +46 8 5270 = 2000
> > > Office direct   +46 8 5270 = 5038
> > > = Mobile          +46 70 848 = 5038
> > > = Email           = loa.andersson@utfors.se
> > > = WWW           &nb= sp; www.utfors.se
> > >
> >
>
>

------_=_NextPart_001_01C0C42D.5C8F9520-- From owner-mpls@UU.NET Sat Apr 14 11:29:25 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13119 for ; Sat, 14 Apr 2001 11:29:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkpr08476; Fri, 13 Apr 2001 19:51:00 GMT Received: by mail-control.mail.uu.net id QQkkpr23514 for mpls-outgoing; Fri, 13 Apr 2001 19:50:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkpr23415 for ; Fri, 13 Apr 2001 19:49:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkpr03065; Fri, 13 Apr 2001 19:47:05 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQkkpr05452; Fri, 13 Apr 2001 19:47:04 GMT Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA18796; Fri, 13 Apr 2001 15:47:03 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA18773; Fri, 13 Apr 2001 15:47:02 -0400 (EDT) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA16014; Fri, 13 Apr 2001 15:47:00 -0400 (EDT) To: "Naidu, Venkata" Cc: Bharti Batra , "Charlap, David" , Abhijit Gadgil , "'Mark Seery'" , mpls@UU.NET, owner-mpls@UU.NET, Rajesh P Jain Subject: RE: Does MPLS Require L3 Routing Table ? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Aris Kyriakopoulos" Date: Fri, 13 Apr 2001 15:41:42 -0400 X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 04/13/2001 15:41:44, Serialize complete at 04/13/2001 15:41:44 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Responding to Venkata's question: There is nothing in the MPLS architecture that forbids the use of static LSPs. In fact, most major vendors do support configuration of static LSPs, in addition to hop-by-hop or constraint-routed LSPs. However, they are not addressed in 3031 (or any other draft standards/IDs that I know of) because the stated goal of the MPLS WG is to develop a Layer 2 switching technology controlled by a Layer 3 routing protocol. This, I believe, is the crux of the argument. If one chooses not to implement the MPLS control plane, then one is reduced to yet another L2 switching protocol. In that case, why not juse use ATM? Or Frame Relay? If there are benefits to using MPLS as a pure L2 switching mechanism (without any L3 routing integration) I would certainly like to know. Regards, Aris -- Aris Kyriakopoulos Interoperability Test Engineering, PSAX CO Products Lucent Technologies Landover, MD mobile: (301) 332-2840 office: (301) 809-4509 mailto:aris@lucent.com "Naidu, Venkata" Sent by: owner-mpls@UU.NET 04/13/2001 03:33 PM To: "'Mark Seery'" , Abhijit Gadgil , Rajesh P Jain , "Charlap, David" cc: Bharti Batra , mpls@UU.NET Subject: RE: Does MPLS Require L3 Routing Table ? All, I got a doubt (and to extend it more)... * Can we manually configure MPLS labels, just like PVCs in ATM, for any Layer 2. (call it Permanent LSPs) In that sense I hope we don't need any control plane (Signaling - LDP/RSVP or Routing OSPF/IS-IS etc) * Is it allowed or used in MPLS (forwarding plane) terminology? Because, in ATM, SVCs are expensive and rarely used where as PVC are feasible/preferable. Thanks & Regards Venkata Subbaiah Naidu -- http://www.geocities.com/kvsnaidu > -----Original Message----- > From: Mark Seery [mailto:mark@bravidacorp.com] > Sent: Friday, April 13, 2001 3:07 PM > To: Abhijit Gadgil; Rajesh P Jain > Cc: Bharti Batra; mpls@UU.NET > Subject: RE: Does MPLS Require L3 Routing Table ? > > > To make the statement that the only way to program an MPLS > FIB is via an IP > control plane is not strictly speaking true, though the intent of the > statement is understood. It is true however to say that there > will be many > capabilities not achieved if a network layer control plane is > not used, such > as the ones stated below. > > On the issue of performance, it is true that it is possible to use > technology that does longest prefix match at wire rate. It is > also true that > there are issues not related to performance in using such > technology, and > that these issues may or may not make a difference depending > on the overall > design goals and application of the system. It is also true > that due to the > continued evolution of silicon, even these differences may > not exist at some > point in the future. > > -mark.s. > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Abhijit > Gadgil > Sent: Friday, April 13, 2001 5:30 AM > To: Rajesh P Jain > Cc: Bharti Batra; mpls@UU.NET > Subject: Re: Does MPLS Require L3 Routing Table ? > > > > MPLS does require layer 3 routing information. It works together with > Layer 3 routing information like OSPF / BGP etc. However the > advantage of > MPLS is in terms of being able to label switch after it has formed the > LSPs. This is useful in case of hardware that cannot look > into IP header > like ATM switches. Another advantage of MPLS is in terms of creating > explicitely routed label switched paths, which is useful in Traffic > Engineering. The original motivation for MPLS of being able > to outperform > IP lookup is not the motivation for MPLS these days. Another > advantage of > MPLS is its better than IP over ATM. Thus the advantages of > MPLS can be > listed as follows. > 1. Making use of network layer routing to create label switched paths. > 2. No need to maintain 2 networks as in IP over ATM case. > 3. Alleviating N^2 mesh problem common with ATM switches > > hope that helps > > -abhijit > > On Fri, 13 Apr 2001, Rajesh P Jain wrote: > > >"Hello", > > Thanks for the response. > > > > Well, if it requires L3 Routing > table to build up > the Label information, then what is the advantage of MPLS??? > Well, Anyhow, > it will require the building of L3 Routing Table (May be through > RIP/OSPF/BGP etc), then Lable info can be formed by using only L3. So, > Anyhow, MPLS is dependent on L3, please explain me what is > the advantage of > using MPLS (in terms of efficiency and speed switching of the > packets). > > > >With Regards > > Rajesh P Jain > > ----- Original Message ----- > > From: Bharti Batra > > To: Rajesh P Jain ; mpls@UU.NET > > Sent: Friday, April 13, 2001 1:09 PM > > Subject: Re: Does MPLS Require L3 Routing Table ? > > > > > > Hi ! > > > > Yes. LDP needs IP routing table to find out the route > towards the egress > router to setup the LSP. LDP sends the LSP setup request > message along this > path. > > > > Regds, > > Bharti > > ----- Original Message ----- > > From: Rajesh P Jain > > To: mpls@UU.NET > > Sent: Friday, April 13, 2001 12:52 PM > > Subject: Does MPLS Require L3 Routing Table ? > > > > > > "Hello", List, > > Well, I am very new to Jthe MPLS domain. I > >just > wanted to check out whether MPLS domain neccesarily require > the L3 Routing > Table (Maybe IP Routing Table) to build up it's label (using the LDP > Protocol). Or the LDP will take care of building the label information > automatically without the L3 Routing information? > > > > TIA > > Rajesh P Jain > > > > From owner-mpls@UU.NET Sat Apr 14 13:15:14 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13808 for ; Sat, 14 Apr 2001 13:15:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkksy17905; Sat, 14 Apr 2001 17:13:21 GMT Received: by mail-control.mail.uu.net id QQkksy22633 for mpls-outgoing; Sat, 14 Apr 2001 17:12:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkksy22627 for ; Sat, 14 Apr 2001 17:12:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkksy03126 for ; Sat, 14 Apr 2001 17:12:20 GMT Received: from mason2.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQkksy03538 for ; Sat, 14 Apr 2001 17:12:20 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id NAA03776; Sat, 14 Apr 2001 13:12:20 -0400 (EDT) Date: Sat, 14 Apr 2001 13:12:20 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: Eric Rosen cc: David Charlap , mpls@UU.NET Subject: Re: Use of LDP for VPNs In-Reply-To: <200104131459.KAA13601@erosen-sun.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, Please read the inline: On Fri, 13 Apr 2001, Eric Rosen wrote: > > David> RSVP-TE can do multipoint-to-point. If the extended tunnel ID is > David> zero, then all senders using the same endpoint and tunnel ID will be > David> in the same session. If SE style reservations are used, all paths in > David> the session (from the ingress routers to the egress router) will > David> share resources. A router that is capable of label-merging can > David> choose to send the same label to all previous-hop routers in the > David> session, effectively combining two (or more) RSVP paths into a single > David> LSP. > >Eric> Yes, good point. I overlooked that because, as far as I know, Eric>no one is actually doing this. > >Eric> Even used in this manner, though, RSVP cannot achieve the Eric> level of efficiency achievable with LDP, if Downstream Eric> Unsolicited and Liberal Label Retention are used. Eric, Can you please elaborate the efficiency part. Thanks. Regards, -Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** From owner-mpls@UU.NET Sat Apr 14 15:44:10 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14364 for ; Sat, 14 Apr 2001 15:44:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkti00414; Sat, 14 Apr 2001 19:43:01 GMT Received: by mail-control.mail.uu.net id QQkkti08704 for mpls-outgoing; Sat, 14 Apr 2001 19:42:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkti08694 for ; Sat, 14 Apr 2001 19:42:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkti29356 for ; Sat, 14 Apr 2001 19:42:09 GMT From: sgong@gmu.edu Received: from portal.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: portalknot.gmu.edu [129.174.0.8]) id QQkkti24994 for ; Sat, 14 Apr 2001 19:42:08 GMT Received: from gmu.edu (mail01.gmu.edu [129.174.0.6]) by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id PAA30771 for ; Sat, 14 Apr 2001 15:42:13 -0400 (EDT) To: mpls@UU.NET Message-ID: <13579dc13512e8.13512e813579dc@gmu.edu> Date: Sat, 14 Apr 2001 15:42:04 -0400 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: Does MPLS Require L3 Routing Table ? X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit If a router uses MPLS labels to switch the packets, it is an LSR (Label Switching Router). If two LSR exchange the 'label/FEC binding information,' these two LSRs are known as 'label distribution peers.' LDP can be used to distribute the labels. During the LDP session setup, a 'basic discovery' procedure will be initiated to detect the adjacent nodes. 'Hello' messages are sent as UDP packets. At this time, no routing information is needed. However, you can only get the label/FEC binding information on the sub-network directly connected to you. Suppose you are the ingress of the LSP and the Egress LSR is more than one hop from you, you have to find the label/FEC binding to that destination. That means before the LSP is setup, you must first know from whom you can get the label/FEC binding. In this case, you must check in your L3 routing table based on the IP address and find the next hop so that you can send 'label request on demand' to your downstream node to get the binding information. Once the LSP is setup, you don't need the routing table for switching packets. *********************** Shujia GONG (Frank) Advanced Internet Lab George Mason University +1-703-993-3905 *********************** From owner-mpls@UU.NET Sun Apr 15 03:04:30 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02778 for ; Sun, 15 Apr 2001 03:04:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkvc18612; Sun, 15 Apr 2001 07:03:11 GMT Received: by mail-control.mail.uu.net id QQkkvc20563 for mpls-outgoing; Sun, 15 Apr 2001 07:02:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkvc20029 for ; Sun, 15 Apr 2001 07:02:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkvc17617 for ; Sun, 15 Apr 2001 07:02:03 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkvc24741 for ; Sun, 15 Apr 2001 07:02:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA14208 for mpls@uu.net; Sun, 15 Apr 2001 03:02:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkvc15609 for ; Sun, 15 Apr 2001 07:01:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkvc14744 for ; Sun, 15 Apr 2001 07:00:48 GMT Received: from lohi.eng.telia.fi by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQkkvc24236 for ; Sun, 15 Apr 2001 07:00:46 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3F70ih00596; Sun, 15 Apr 2001 10:00:44 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15065.18204.355287.636244@lohi.eng.telia.fi> Date: Sun, 15 Apr 2001 10:00:44 +0300 (EEST) To: sgong@gmu.edu Cc: mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <13579dc13512e8.13512e813579dc@gmu.edu> References: <13579dc13512e8.13512e813579dc@gmu.edu> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit sgong@gmu.edu writes: > Suppose you are the ingress of the LSP and the Egress LSR is more than > one hop from you, you have to find the label/FEC binding to that > destination. That means before the LSP is setup, you must first know > from whom you can get the label/FEC binding. In this case, you must > check in your L3 routing table based on the IP address and find the > next hop so that you can send 'label request on demand' to your > downstream node to get the binding information. or you can have labels to be setup automatically between all your edge routers after which the routers can use inarp to figure out who is behind each label. in that mode there is no need for any l3 information in the core lsrs. -- juha From owner-mpls@UU.NET Sun Apr 15 11:45:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10252 for ; Sun, 15 Apr 2001 11:45:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkwl20137; Sun, 15 Apr 2001 15:45:10 GMT Received: by mail-control.mail.uu.net id QQkkwk23130 for mpls-outgoing; Sun, 15 Apr 2001 15:44:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkwk23116 for ; Sun, 15 Apr 2001 15:44:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkwk29777 for ; Sun, 15 Apr 2001 15:43:35 GMT Received: from osf1.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQkkwk22209 for ; Sun, 15 Apr 2001 15:43:35 GMT Received: from vaio ([129.174.55.34]) by osf1.gmu.edu (8.8.8/8.8.8) with SMTP id LAA17849; Sun, 15 Apr 2001 11:43:23 -0400 (EDT) Message-ID: <002b01c0c5c3$9f2d13c0$2237ae81@gmu.edu> From: "Rajiv Papneja" To: "Juha Heinanen" Cc: References: <13579dc13512e8.13512e813579dc@gmu.edu> <15065.18204.355287.636244@lohi.eng.telia.fi> Subject: Re: Does MPLS Require L3 Routing Table ? Date: Sun, 15 Apr 2001 11:48:05 -0400 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Juha Heinanen" To: Cc: Sent: Sunday, April 15, 2001 3:00 AM Subject: Re: Does MPLS Require L3 Routing Table ? > sgong@gmu.edu writes: > > > Suppose you are the ingress of the LSP and the Egress LSR is more than > > one hop from you, you have to find the label/FEC binding to that > > destination. That means before the LSP is setup, you must first know > > from whom you can get the label/FEC binding. In this case, you must > > check in your L3 routing table based on the IP address and find the > > next hop so that you can send 'label request on demand' to your > > downstream node to get the binding information. > > or you can have labels to be setup automatically between all your edge > routers after which the routers can use inarp to figure out who is > behind each label. in that mode there is no need for any l3 information > in the core lsrs. > > -- juha > Hi Juha, I was just wondering that if this is a scalable approach. This might give rise to a large number of inarps in a large mesh network. Also, I am not really sure that anyone has yet implemented this feature over the unidirectional virtual circuits (for eg. MPLS LSPs). If possible can you provide some more insight into this topic, I will more than interested to know about this. Thanks. -Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** > From owner-mpls@UU.NET Sun Apr 15 12:14:57 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10392 for ; Sun, 15 Apr 2001 12:14:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkwm24827; Sun, 15 Apr 2001 16:13:41 GMT Received: by mail-control.mail.uu.net id QQkkwm13001 for mpls-outgoing; Sun, 15 Apr 2001 16:13:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkwm12990 for ; Sun, 15 Apr 2001 16:12:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkwm13382 for ; Sun, 15 Apr 2001 16:11:52 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkkwm18082 for ; Sun, 15 Apr 2001 16:11:52 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA00303 for mpls@uu.net; Sun, 15 Apr 2001 12:11:52 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkkwm12793 for ; Sun, 15 Apr 2001 16:11:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkwm03866 for ; Sun, 15 Apr 2001 16:11:05 GMT Received: from lohi.eng.telia.fi by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQkkwm18197 for ; Sun, 15 Apr 2001 16:11:02 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3FGB9E00836; Sun, 15 Apr 2001 19:11:09 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15065.51229.525081.686724@lohi.eng.telia.fi> Date: Sun, 15 Apr 2001 19:11:09 +0300 (EEST) To: "Rajiv Papneja" Cc: Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <002b01c0c5c3$9f2d13c0$2237ae81@gmu.edu> References: <13579dc13512e8.13512e813579dc@gmu.edu> <15065.18204.355287.636244@lohi.eng.telia.fi> <002b01c0c5c3$9f2d13c0$2237ae81@gmu.edu> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Rajiv Papneja writes: > Also, I am not really sure that anyone has yet implemented this feature over > the unidirectional virtual circuits (for eg. MPLS LSPs). If possible can you > provide some more insight into this topic, I will more than interested to > know about this. Thanks. see draft-heinanen-inarp-uni-01.txt, -- juha From owner-mpls@UU.NET Mon Apr 16 07:54:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02552 for ; Mon, 16 Apr 2001 07:54:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkzn28411; Mon, 16 Apr 2001 11:51:58 GMT Received: by mail-control.mail.uu.net id QQkkzn03567 for mpls-outgoing; Mon, 16 Apr 2001 11:51:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkkzn03499 for ; Mon, 16 Apr 2001 11:51:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkkzn21464 for ; Mon, 16 Apr 2001 11:48:35 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkkzn16598 for ; Mon, 16 Apr 2001 11:48:35 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 010EE94006; Mon, 16 Apr 2001 07:48:34 -0400 (EDT) Message-ID: <3ADADC12.A9F64146@sandburst.com> Date: Mon, 16 Apr 2001 07:48:34 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen Cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? References: <13579dc13512e8.13512e813579dc@gmu.edu> <15065.18204.355287.636244@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, With LSPs being fundamentally unidirectional, how would you make this work? Would you slowly strobe all of the LSPs going out and wait for a timeout on each INARP request, or are you assuming some other way to tie incoming to outgoing labels? -- Eric Gray You wrote: > sgong@gmu.edu writes: > > > Suppose you are the ingress of the LSP and the Egress LSR is more than > > one hop from you, you have to find the label/FEC binding to that > > destination. That means before the LSP is setup, you must first know > > from whom you can get the label/FEC binding. In this case, you must > > check in your L3 routing table based on the IP address and find the > > next hop so that you can send 'label request on demand' to your > > downstream node to get the binding information. > > or you can have labels to be setup automatically between all your edge > routers after which the routers can use inarp to figure out who is > behind each label. in that mode there is no need for any l3 information > in the core lsrs. > > -- juha From owner-mpls@UU.NET Mon Apr 16 07:57:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02583 for ; Mon, 16 Apr 2001 07:57:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkzn19036; Mon, 16 Apr 2001 11:54:45 GMT Received: by mail-control.mail.uu.net id QQkkzn03734 for mpls-outgoing; Mon, 16 Apr 2001 11:54:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkkzn03716 for ; Mon, 16 Apr 2001 11:53:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkkzn25593 for ; Mon, 16 Apr 2001 11:53:28 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkkzn00289 for ; Mon, 16 Apr 2001 11:53:28 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id A663894006; Mon, 16 Apr 2001 07:53:27 -0400 (EDT) Message-ID: <3ADADD37.A760C7A2@sandburst.com> Date: Mon, 16 Apr 2001 07:53:27 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Rajiv Papneja Cc: Eric Rosen , David Charlap , mpls@UU.NET Subject: Re: Use of LDP for VPNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Rajiv, Different Eric, but I'll take a whack at a short answer. RSVP-TE does not have a mechanism for 'independent control' LSP setup and - while you could use RSVP-TE to support a 'liberal retention' like mode of operation - nobody that I know of would contemplate doing so irrespective of their opinion of the scalability of RSVP in the general case. -- Eric Gray You wrote: > Hi Eric, > > Please read the inline: > > On Fri, 13 Apr 2001, Eric Rosen wrote: > > > > > David> RSVP-TE can do multipoint-to-point. If the extended tunnel ID is > > David> zero, then all senders using the same endpoint and tunnel ID will be > > David> in the same session. If SE style reservations are used, all paths in > > David> the session (from the ingress routers to the egress router) will > > David> share resources. A router that is capable of label-merging can > > David> choose to send the same label to all previous-hop routers in the > > David> session, effectively combining two (or more) RSVP paths into a single > > David> LSP. > > > >Eric> Yes, good point. I overlooked that because, as far as I know, > Eric>no one is actually doing this. > > > >Eric> Even used in this manner, though, RSVP cannot achieve the > Eric> level of efficiency achievable with LDP, if Downstream > Eric> Unsolicited and Liberal Label Retention are used. > > Eric, > > Can you please elaborate the efficiency part. Thanks. > > Regards, > -Rajiv > > ******************************** > Rajiv Papneja (GRA) > Advanced Internet Laboratory > George Mason University, > G10, Johnson Center, > Fairfax, VA 22030-4444 > Tel: 703.993.4703 > email: rpapneja@osf1.gmu.edu > ******************************** From owner-mpls@UU.NET Mon Apr 16 08:15:38 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02714 for ; Mon, 16 Apr 2001 08:15:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkkzo22595; Mon, 16 Apr 2001 12:13:15 GMT Received: by mail-control.mail.uu.net id QQkkzo22623 for mpls-outgoing; Mon, 16 Apr 2001 12:12:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkkzo22618 for ; Mon, 16 Apr 2001 12:12:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkkzo27891 for ; Mon, 16 Apr 2001 12:12:24 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkkzo16640 for ; Mon, 16 Apr 2001 12:12:24 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id B96DC94006; Mon, 16 Apr 2001 08:12:18 -0400 (EDT) Message-ID: <3ADAE1A2.D2067745@sandburst.com> Date: Mon, 16 Apr 2001 08:12:18 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Bakshi, Sanjay" Cc: mpls@UU.NET Subject: Re: A question. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sanjay, Your assumption is slightly faulty. :-) The term LER (label edge router) is somewhat misleading, because it seems to define a box (router) as opposed to a function (label edge routing) which a box may or may not support. People tend to think of an LER as a box that supports the edge routing functions of MPLS ingress and egress. That does not mean that it absolutely must find an LSP for every packet it receives - or that it absolutely must pop the last label off of every packet that it sends. It's behavior WRT any packet it receives or sends depends largely on the capabilities of the interfaces on which it was received or will be sent and the apriori existence of an FTN (or ILM) entry. There is no 'data-driven label binding operation' as you imply in your question. If an LER does not have a 'FEC entry' in its FTN (FEC to NHLFE) table, it either forwards the packet using IP routing (if it is able to do so) or it drops the packet (possibly returning a 'destination unreachable' error to the sender - again if it is able to do so). -- Eric Gray You wrote: > Hello, > I have a simple question for which I think I know the answer but cannot find > the reference in the RFCs to de certain. What happens when a unlabeled > packet is received by a LER and there is no FEC entry corresponding to the > packet? > I know this falls under the data-driven label binding operation, in which > LDP is trigerred by the arriving packet. But I have not found a reference to > it in any RFC to back my assumption up. > Any pointers? > thanks > sanjay From owner-mpls@UU.NET Mon Apr 16 11:33:30 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06542 for ; Mon, 16 Apr 2001 11:33:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklac25535; Mon, 16 Apr 2001 15:31:06 GMT Received: by mail-control.mail.uu.net id QQklac04601 for mpls-outgoing; Mon, 16 Apr 2001 15:30:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklac04595 for ; Mon, 16 Apr 2001 15:30:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklab25783 for ; Mon, 16 Apr 2001 15:29:02 GMT Received: from bgslc02.TBG.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQklab15198 for ; Mon, 16 Apr 2001 15:29:02 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Mon, 16 Apr 2001 09:16:11 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE70146D9DF@BGSLC02> From: Irwin Lazar To: "'mpls@uu.net'" Subject: VoMPLS mailing list Date: Mon, 16 Apr 2001 09:16:10 -0600 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 Integral Access used to run a VoMPLS mailing list at vompls-request@lists.integralaccess.com Does anyone know if this list is still operational? Thanks, Irwin From owner-mpls@UU.NET Mon Apr 16 11:44:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06903 for ; Mon, 16 Apr 2001 11:44:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklac00209; Mon, 16 Apr 2001 15:41:36 GMT Received: by mail-control.mail.uu.net id QQklac05646 for mpls-outgoing; Mon, 16 Apr 2001 15:41:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklac05568 for ; Mon, 16 Apr 2001 15:40:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklac21023 for ; Mon, 16 Apr 2001 15:36:17 GMT Received: from mail.integralaccess.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.160.25.239]) id QQklac18192 for ; Mon, 16 Apr 2001 15:36:17 GMT Received: from MTAM [192.168.100.235] by mail.integralaccess.com (SMTPD32-6.04) id A0802D800C2; Mon, 16 Apr 2001 11:32:16 -0400 From: "Mimi Tam" To: "Irwin Lazar" , "'mpls@uu.net'" Subject: RE: VoMPLS mailing list Date: Mon, 16 Apr 2001 11:32:27 -0400 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) Importance: Normal In-Reply-To: <0C875DC28791D21192CD00104B95BFE70146D9DF@BGSLC02> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This list is not operational at the moment. However, it can be brought back on-line if need be. Is there a purpose for your asking, Irwin? Thanks...Mimi Tam (Integral Access, Inc) -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Irwin Lazar Sent: Monday, April 16, 2001 11:16 AM To: 'mpls@uu.net' Subject: VoMPLS mailing list Integral Access used to run a VoMPLS mailing list at vompls-request@lists.integralaccess.com Does anyone know if this list is still operational? Thanks, Irwin From owner-mpls@UU.NET Mon Apr 16 17:09:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13842 for ; Mon, 16 Apr 2001 17:09:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklay00331; Mon, 16 Apr 2001 21:06:16 GMT Received: by mail-control.mail.uu.net id QQklay19249 for mpls-outgoing; Mon, 16 Apr 2001 21:05:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklay17068 for ; Mon, 16 Apr 2001 21:05:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklay20246 for ; Mon, 16 Apr 2001 21:03:26 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklay24202 for ; Mon, 16 Apr 2001 21:03:26 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA14207 for mpls@uu.net; Mon, 16 Apr 2001 17:03:25 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklay11708 for ; Mon, 16 Apr 2001 21:02:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklay18152 for ; Mon, 16 Apr 2001 21:02:30 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQklay23142 for ; Mon, 16 Apr 2001 21:02:30 GMT Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA04792; Mon, 16 Apr 2001 17:02:29 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA02459; Mon, 16 Apr 2001 17:02:29 -0400 (EDT) Message-Id: <200104162102.RAA02459@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: proceedings@ietf.org, mpls@UU.NET Subject: Final MPLS minutes Date: Mon, 16 Apr 2001 17:02:28 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk MPLS WG Meeting Thursday, March 22, 2001 ======================================== I. George provided document status on existing documents which are in or near last call. 1. Carrying Label Information in BGP-4 (awaiting publication) On RFC editor's queue 2. RSVP-TE (awaiting publication) Applicability Statement for Extensions to RSVP for LSP-Tunnels RSVP-TE: Extensions to RSVP for LSP Tunnels Note: the latter draft needs some final edits. This will be handled as part of the RFC editors last authors comments. 3. LDP "boxed set" (awaiting publication) LDP State Machine Applicability Statement for CR-LDP Constraint-Based LSP Setup using LDP LSP Modification Using CR-LDP These are awaiting a Table of Contents for LDP State machine. As of this writing, Eric Gray has supplied an updated draft. 4. MIBs (in IESG last call) Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) MPLS Label Switch Router Management Information Base Using SMIv2 Authors are in the process addressing comments from the IESG. Another round of last calls may be required. 5. Framework for IP Multicast in MPLS Will be sent to IESG for last call. 6. MPLS Support of Differentiated Services Francois needs to turn a new draft incorporating updates from the recent WG last call after which it will go for IESG last call. 7. Generalized MPLS Signaling drafts These drafts are nearly complete. They will be updated based on the results of CCAMP. Once updated they will be sent for joint CCAMP and MPLS WG last call. The sense of the room was that the drafts should go to a MPLS WG last call. 8. Unnumbered, Bundle, Hierarchy drafts After the "sub IP" re-org, these drafts remain in MPLS. Proposal: Accept draft-kompella-mpls-undle-05.txt as working group draft. Update the draft as draft-mpls-bundle-00.txt. Some of the other drafts will also be updated. Once updated a WG last call will be issued. II. MPLS Recovery Framework Fifi Hellstrand This document provides a high-level overview of protection mechanisms which could be employed by MPLS. The document was also presented to the TE wg. Many comments received on this document. Minor changes were required (editorial). Fifi requested that the document be sent to WG last call and move it to an informational RFC. No questions from crowd. Within the sub IP area, the TEWG has the charter to come up with an overall recovery framework. George therefore asked the ADs if a WG last call for this document could be done at this time. Scott: Wants to take a sense of the room, and then get comments from the mailing list for last call, but still wants the TE design team to make sure that they don't want to add to it. Don't want to wait for more than a month. George: Any objections on moving to last call within a month? None were voiced. The document will be sent to the TE WG mailing list for comments to facilitate the process outlined by Scott. III. RSVP Label Allocation for Backup Tunnels George Swallow Objective is to do FRR in MPLS to allow for temporary routing around a failed link or node while the head-end is reoptimizing the lsp. The technique uses a bypass tunnel to the node two hops down the path. All tunnels between the current node and that node may share the same bypass tunnel. Rerouting is done locally and thus can be done in < 50ms. In order to use this, a label needs be obtained for the hop across the bypass tunnel. Two mehanism are described in the draft. A separate RSVP Path message can be generated. This applies in all cases. If the tail of the bypass tunnel is a frame-based switch using the global label space, then labels can simply be recorded in the RRO. The draft has been available for the past 1.5 years. It is purely informational; doesn't propose anything new. Would like to publish as a WG informational draft. Scott (as chair): Is there support in the room for this. No objections. A WG last call will be issued after which it will be forwarded to Scott and Bert for IESG review. IV. LDP Fault Tolerance Philip Matthews Summarized draft. Discussed changes between last version and current version. Expect to ask for wg last call soon. Requested comments now or via mailing list. George: Consensus to put this draft to a wg last call. Luca Martini opposes wg last call; no other objections. Luca: Since ldp is not a controlling protocol, why bother making it fault tolerant? Matthews: Enhance software upgrades and you don't want to disrupt the LSPs that are running over the network. Luca: But other protocols need to be made redundant too. Matt: OSPF etc. are being made fault tolerant. We stole this proposal from IDR. A long discussion enused on the relationship of LDP recovery to recovery of information from other protocols. There is work in progress on this in OSPF and IDR. In fact the LDP recovery is based on BGP recovery. Details of this discussion can be found in the raw minutes sent by Tom Nadeau. The result of all the discussion was that the issue of the relationship of LDP recovery to other stateful recovery will be handled in the last call. Scott commented that the applicability section of the document should be enhanced to reflect this. George: We will do a last call, raise these issues and try to close them. If closed, then document is finished. V. An Expanded ERO for RSVP-TE Vishal Sharma Given the recent changes in the unnumber draft, the mechanism proposed in this draft is no longer necessary. The authors therefore propose to turn this draft into an informational document on how to form EROs and move it forward that way. VI. TTL Processing in MPLS networks Puneet Agarwal Draft covers different ways of processing TTL. Overview. Would like to update according to comments from list and move forward to last call. Matt: Document is useful and technical content is good. Figures would be useful. Document is difficult to read. Pipe/Hose model are mixed in document. Put them in a their own places in the document? Q1: I don't see how TTLs are specified in NTAPs draft. A: Some models are not described in that document. Q1: There might be some difficulty with your approach. Rosen: There is already a document that specifies how TTL processing works. Lets just put pipe model in here only, otherwise we duplicate things explained in RFC 3032. I think that we need to organize the discussion around the point of the organization of this document (what is not covered and what is). E: You don=92t need a separate procedure for nested procedure; already covered in 3032. Discussion did not complete on mailing list. There is a lot that needs to be clarified. A: What are you proposing? E: I think that you are proposing changes and additions (specified and unspecified). Need to specified which is which. Need to reach consensus on whether or not they are necessary. Do we need a document that obsoletes pieces of rfc3033. George: this is an information proposal. We cannot contradict something that is in a standard. Lets continue this discussion on the mailing list. Egray: I was going to say what george just said. Define something in a standard specification and explain something in an informational. George: Cannot contradict what was in the rfc. Take it to the list. VII. TTL Processing expansion for 1-hop LSP Satoru Matsushima Overview. Next steps: merge with Puneet's ttl draft. Would like to become a wg draft. Need signaling extensions for 1-hop lsp. George: Discussion? Eric Rosen: There are two schools of thought on TTL processing. Don't think there is a need to specify TTL on a per-lsp basis. I don't think that there is a problem that we need to solve here. Luca: I agree with Eric's comments. I don't see the use of specifying the behavior on a per-lsp basis. George: Continue discussion on mailing list. VIII. LDP End-to-end Authorization Olivier Paridaens Overview. Presented requirements. What we are asking is that this be adopted as a wg draft. This work is part of the charter, so it should be accepted. Scott: What operators have expressed interest in this technology and have the security geeks looked at this? A general discussion ensued on what was required and what had been discussed in San Diego. Several carriers and vendors spoke up saying that the proposal on the table was expensive and over-kill. This was counter with a statement that the method was not all that expensive and that the feature is optional. It was also claimed that carriers voiced support in San Diego. Another speaker pointed out that optional pertained to use and that vendors most likely would be required to implement. Before committing to such a course they would like to see the requirements document for this sort of work. George: We need to figure out what providers want first. We don't have any consensus at this point. Lets get some carriers to give us some contributions for what they would like to see in this space. Continue discussion on this mailing list. IX. Update on LDP Path MTU Ben Black Overview. Simple extension to ldp to allow automatic signaling of mtu detection. Allows proper fragmentation of packets within the MPLS domain. Support RFC1191 too. Version 00 has been out for some time. Lots of comments received. Asked that this be accepted as a wg document. George: discussion Curtis: What happens if along the way, one hop is inside a hierarchtical tunnel or if bypass tunnels are used. In both cases, the router negotiating a hop is not aware that somewhere in the middle that a bypass exists. Black: If hierarchtical, the outermost tunnel=92s mtu is used. There is an lsr somewhere that can see the bypass which can unsolicited signal the mtu change. It will pick the lesser of the two=92s path. George: Anything that causes an impulse into signaling during a failure is bad. Eric Rosen pointed out that in practice, firewalls often thwart Path MTU discovery by dropping ICMP messages. Ben Black said that simply because it wouldn't work in some cases, was no reason not to work on solving the problem where it would work. Curtis: There are places where this is necessary: no NATs and high performance IP. Matt: I haven't seen demands from the carriers for this functionality, eventhough I like it. Scott: Process point: is this in the charter? George: Gray area. We should work to get MPLS to work. Scott: WG can change charter if necessary. Charter is description of what we should be doing within a certain time period. Q1: Carriers are interested in this. Black: RSVP has this functionality. Discussion will be continued on the list. George: We now have three presentations that are not in the gray area. They are outside of the current charter. We are going into "BOF" mode to see if there is interest to expand the charter. X. Secure MPLS Tissa Senevirath Overview. Applications: Most metro applications use MPLS. Q1: In your first slide, you stated that most MPLS Metro carriers use MPLS. Which country are you talking about? Sen: US. Q1: Do you know which vendors are supporting MPLS in the metro area. Q2: Most operators use f/r links. The law prohibits them from monitoring authentications. Can authentications be monitored on MPLS. Even if we have mpls security on a backbone. MPLS is an end-to-end problem. This does not seem to be useful unless it is end to end. Bilel J: Where are you getting the requirements for this draft. Sen: These requirements are coming from the optical development going on in the world. George: Take the discussion to the mailing list. XI. Multicast Traffic Engineering Dirk Ooms Overview. Questions. George: This work was started a long time ago. There was no interest in this at that time. What has changed? Dirk: Now there is SSMulticast. George: Perhaps you should change the name of your document to "support for SSM". Dirk: this is an alternative to SSM. Rosen: As far as SSM, there are other solutions to the problem of knowing the source of a packet. Dirk: There are other solutions, but they are undocumented as of yet. Q1: I wasn't clear why SSM makes this more interesting. Also it isn't clear how you distribute the labels using TE. Where is the definition of TE is not clearly defined in the draft. Dirk: Traffic engineering allows you to construct a tree, which deviates from the shortest path tree. Which is the same as TE for unicast. George: Given the time, lets continue discussion on the mailing list. XII. MPLS OAM Shahram Davari Davari MPLS OAM draft-harrison-mpls-oam-00.txt Overview. Status of this document: ITU SG13-Q3. Requirements are defined. Availability is defined. OAM Packets are defined. Connectivity verification is worked out. Future work: LSP performance work. Summary: OAM is necessary for user-plane, independent of control-plane. This draft introduces OAM requirements and simple OAM functions. Determining connectivity/availability. What we have done is taken this from ATM and reduced most of what was there, and kept the best %1. MPLS OAM was previously defined in MPLS charter. If interested, it should be added to charter and document accepted as a work item. Q: I think this work is very useful. It will increase the performance of the MPLS network. Recovery framework is applicable. Performance benchmarking applies. This is useful for fault-tolerance. Curtis: How does this relate to the Bonica draft on tunnel trace? We should go to the TE Wg and see what there are requirements are for this. Rosen: I think that some of the stuff in the beginning is important. I think this document is not a good piece of work. There are many terms that are not defined in the IETF. It has a very ATM-flavor. It does not handle a lot of stuff like multi-point-to-point. Even if we were to add measurement to charter, lets not accept this document to the charter. Davari: This is optional. Carriers want this. Q2: I don't think that this is useful. I think that it is not useful in an LSR. I can see this to be useful if GSMP is being used. Useful in detecting configuration errors, otherwise lets assume that the LSR works okay. Q3: I second that. I don't buy the argument that software is broken, so we need to add more software. Scott: My problem with the document is that it mixes light requirements with lots of suggestions. It would be useful to have a clear requirements document that specifies what it is that you are trying to accomplish with this approach. The requirements document should be taken to the TE WG. Davari: is it in the charter of te? Scott: Thinking is in the charter of te. Management of this kind is not in the charter. However, if requirements can come forward and hint at which tools they could have would be a good thing. George: End of the agenda. See you in London. From owner-mpls@UU.NET Tue Apr 17 05:43:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04731 for ; Tue, 17 Apr 2001 05:43:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklcw25504; Tue, 17 Apr 2001 09:40:47 GMT Received: by mail-control.mail.uu.net id QQklcw18715 for mpls-outgoing; Tue, 17 Apr 2001 09:40:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklcw18706 for ; Tue, 17 Apr 2001 09:40:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklcw22969 for ; Tue, 17 Apr 2001 09:39:45 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQklcw23573 for ; Tue, 17 Apr 2001 09:39:44 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f3H9bmB14739; Tue, 17 Apr 2001 02:37:48 -0700 (PDT) Reply-To: From: "Anil Gunturu" To: , Subject: Explicit Null Label Date: Tue, 17 Apr 2001 02:36:51 -0700 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) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Is there any other purpose for an explicit null label other than preserving the Exp field for QoS purposes? Thanks, -Anil Anil Gunturu, Software Engineer Ericsson, Inc phone: (805) 562 6431 Datacom & IP Services email: anilg@acc.am.ericsson.se 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Tue Apr 17 08:20:22 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06022 for ; Tue, 17 Apr 2001 08:20:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldh18484; Tue, 17 Apr 2001 12:17:40 GMT Received: by mail-control.mail.uu.net id QQkldh22182 for mpls-outgoing; Tue, 17 Apr 2001 12:17:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkldh22177 for ; Tue, 17 Apr 2001 12:17:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkldh12692 for ; Tue, 17 Apr 2001 12:16:18 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkldh06880 for ; Tue, 17 Apr 2001 12:16:18 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id AAA9894006; Tue, 17 Apr 2001 08:16:17 -0400 (EDT) Message-ID: <3ADC3411.9F0FE2BA@sandburst.com> Date: Tue, 17 Apr 2001 08:16:17 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: anilg@acc.am.ericsson.se Cc: mpls@UU.NET Subject: Re: Explicit Null Label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anil, It is not necessary to preserve the value of the EXP bits using the explicit NULL label if the penultimate hop is able to map the bits to a corresponding DSCP in the IP header. But this is just one example of what the penultimate hop might not be able to do, thus creating a need for explicit NULL labels... -- Eric Gray You wrote: > Is there any other purpose for an explicit null label other than preserving > the Exp field for QoS purposes? > Thanks, > -Anil > > Anil Gunturu, Software Engineer > Ericsson, Inc phone: (805) 562 6431 > Datacom & IP Services email: anilg@acc.am.ericsson.se > 70 Castilian Dr, Santa Barbara, CA-93117 From owner-mpls@UU.NET Tue Apr 17 08:42:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06281 for ; Tue, 17 Apr 2001 08:42:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldi10667; Tue, 17 Apr 2001 12:39:20 GMT Received: by mail-control.mail.uu.net id QQkldi23913 for mpls-outgoing; Tue, 17 Apr 2001 12:38:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkldi23895 for ; Tue, 17 Apr 2001 12:38:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkldi19760 for ; Tue, 17 Apr 2001 12:38:07 GMT Received: from sutton.acbm.qc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.96.170.5]) id QQkldi09245 for ; Tue, 17 Apr 2001 12:38:06 GMT Received: from hermes.hyperchip.com ([216.249.11.203]) by sutton.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-69929U800L2S100V35) with ESMTP id ca for ; Tue, 17 Apr 2001 08:39:34 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id <2MWNYYLJ>; Tue, 17 Apr 2001 08:37:34 -0400 Message-ID: From: Eyad Saheb To: "'mpls@UU.NET'" Subject: RE: Explicit Null Label Date: Tue, 17 Apr 2001 08:37:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C73B.29474B70" 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_01C0C73B.29474B70 Content-Type: text/plain Hi, Forgive my ignorance, but Explicit Null can still be used for its initial purpose: identifying the L3 protocol type. Also, and I'm not too versed in ATM, but it might be useful for switches which cannot pop the stack. Thus the edges would send an Explicit Null mapping if they are the egress for an LSP. Eyad -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Eric Gray Sent: April 17, 2001 8:16 a To: anilg@acc.am.ericsson.se Cc: mpls@UU.NET Subject: Re: Explicit Null Label Anil, It is not necessary to preserve the value of the EXP bits using the explicit NULL label if the penultimate hop is able to map the bits to a corresponding DSCP in the IP header. But this is just one example of what the penultimate hop might not be able to do, thus creating a need for explicit NULL labels... -- Eric Gray You wrote: > Is there any other purpose for an explicit null label other than preserving > the Exp field for QoS purposes? > Thanks, > -Anil > > Anil Gunturu, Software Engineer > Ericsson, Inc phone: (805) 562 6431 > Datacom & IP Services email: anilg@acc.am.ericsson.se > 70 Castilian Dr, Santa Barbara, CA-93117 ------_=_NextPart_001_01C0C73B.29474B70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Explicit Null Label

Hi,

        Forgive my = ignorance, but Explicit Null can still be used for its initial purpose: = identifying the L3 protocol type.

        Also, and = I'm not too versed in ATM, but it might be useful for switches which = cannot pop the stack.  Thus the edges would send an Explicit Null = mapping  if they are the egress for an LSP.

Eyad

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of Eric Gray
Sent: April 17, 2001 8:16 a
To: anilg@acc.am.ericsson.se
Cc: mpls@UU.NET
Subject: Re: Explicit Null Label


Anil,

    It is not necessary to preserve = the value of the EXP bits
using the explicit NULL label if the penultimate hop = is able
to map the bits to a corresponding DSCP in the IP = header.
But this is just one example of what the penultimate = hop
might not be able to do, thus creating a need for = explicit
NULL labels...

--
Eric Gray

You wrote:

> Is there any other purpose for an explicit null = label other than preserving
> the Exp field for QoS purposes?
> Thanks,
> -Anil
>
> Anil Gunturu, Software Engineer
> Ericsson, = Inc           &nb= sp;           &nb= sp;   phone: (805) 562 6431
> Datacom & IP = Services          &nbs= p;        email: = anilg@acc.am.ericsson.se
> 70 Castilian Dr, Santa Barbara, CA-93117

------_=_NextPart_001_01C0C73B.29474B70-- From owner-mpls@UU.NET Tue Apr 17 08:43:21 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06330 for ; Tue, 17 Apr 2001 08:43:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldi12199; Tue, 17 Apr 2001 12:40:25 GMT Received: by mail-control.mail.uu.net id QQkldi23919 for mpls-outgoing; Tue, 17 Apr 2001 12:38:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkldi23900 for ; Tue, 17 Apr 2001 12:38:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkldi12211 for ; Tue, 17 Apr 2001 12:36:51 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkldi08013 for ; Tue, 17 Apr 2001 12:36:51 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA20512 for mpls@uu.net; Tue, 17 Apr 2001 08:36:50 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkldi23812 for ; Tue, 17 Apr 2001 12:36:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkldi13588 for ; Tue, 17 Apr 2001 12:35:59 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQkldi08114 for ; Tue, 17 Apr 2001 12:35:58 GMT Received: from flefauch-8kcdt.cisco.com (dhcp-nic-val-26-72.cisco.com [64.103.26.72]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA19938; Tue, 17 Apr 2001 14:35:41 +0200 (MET DST) Message-Id: <200104171235.OAA19938@cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 17 Apr 2001 14:29:47 +0200 To: Sandeep Sharma From: Francois Le Faucheur Subject: RE: WG Last call : Comment on COS service and TSPEC Cc: "'Francois Le Faucheur'" , David Charlap , lberger@movaz.com, swallow@cisco.com, mpls@UU.NET, bsd@cisco.com, flefauch@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, ram64@lucent.com ('Ram Krishnan'), Shahram_Davari@pmc-sierra.com (Shahram Davari), Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi In-Reply-To: <00D96DBEF03E924087EC1D1C0C719F5002804B@IRISNT1.iris.irisla bs.com> Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_22843789==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_22843789==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sandeep and all, At 11:17 08/03/2001 -0600, Sandeep Sharma wrote: >Francois, > >Your suggested changes are good! > >One comment: I think, in the context of E-LSP and L-LSP, there is a need to >clarify use of the RSVP DCLASS object (RFC 2996) as referenced in the NULL >service. > How about adding the following clarifying statement (in section 5.6, which will be reworded to talk about Null service)? Note also that this specification does not concerned itself with the DCLASS object defined in [DCLASS], since this object conveys information on DSCP values, which are not relevant inside the MPLS network.=20 Thanks Francois >Thanks, > >- Sandeep > >Sandeep Sharma > Iris Labs > >> -----Original Message----- >> From: Francois Le Faucheur [mailto:flefauch@cisco.com] >> Sent: Thursday, March 08, 2001 6:37 AM >> To: David Charlap; lberger@movaz.com; swallow@cisco.com >> Cc: mpls@UU.NET >> Subject: Re: WG Last call : Comment on COS service and TSPEC >> Based on the clarifications from George and Lou, I propose the=20 >> following resolution for David's two comments above: >>=20 >> * generally, "diff-ext" will be updated to simply align=20 >> to the RSVP-TE=20 >> draft with respect to signaling LSPs without bandwidth reservation.=20 >> "diff-ext" will refer to RSVP-TE for details of how=20 >> Null-Service/TSSPEC >> are used to signal LSP without bandwidth reservation. >>=20 >> * section 5.6 will be updated to reflect use of "Null-service"=20 >> instead of "COS service".=20 >>=20 >> * section 5.6 can probably be shortened (because parts=20 >> of it came about=20 >> simply because of the confusion that stemmed from the "COS=20 >> service" and=20 >> its associated COS field. I believe some of that confusion naturally >> goes away with the use of Null-Service). >>=20 >> * TSPEC will be made mandatory (in line with RSVP-TE-08) >>=20 >>=20 >> Any comments/issues with this resolution? >>=20 >> cheers >>=20 >> Francois >>=20 >> PS: David, thanks a lot for catching this.=20 >>=20 >=20 PLEASE NOTE NEW CONTACT DETAILS - See below _________________________________________________________________ Francois Le Faucheur =20 Development Engineer, IOS Layer 3 Services=20 Cisco Systems=20 Office Phone: +33 4 97 23 26 19 Mobile : +33 6 89 108 159 Fax: +33 4 97 23 26 26 Email: flefauch@cisco.com _________________________________________________________________ Cisco Systems Europe Domaine Green Side 400, Avenue de Roumanille B=E2timent T3 06 410 BIOT=20 SOPHIA ANTIPOLIS FRANCE _________________________________________________________________ =20 --=====================_22843789==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sandeep and all,

At 11:17 08/03/2001 -0600, Sandeep Sharma wrote:
>Francois,
>
>Your suggested changes are good!
>
>One comment: I think, in the context of E-LSP and L-LSP, there is a need to
>clarify use of the RSVP DCLASS object (RFC 2996) as referenced in the NULL
>service.
>

How about adding the following clarifying statement (in section 5.6, which will be reworded to talk about Null service)?

Note also that this specification does not concerned itself with the DCLASS object defined in [DCLASS], since this object conveys information on DSCP values, which are not relevant inside the MPLS network.

Thanks

Francois

>Thanks,
>
>- Sandeep
>
>Sandeep Sharma
>  Iris Labs
>
>> -----Original Message-----
>> From: Francois Le Faucheur [mailto:flefauch@cisco.com]
>> Sent: Thursday, March 08, 2001 6:37 AM
>> To: David Charlap; lberger@movaz.com; swallow@cisco.com
>> Cc: mpls@UU.NET
>> Subject: Re: WG Last call : Comment on COS service and TSPEC
>> Based on the clarifications from George and Lou, I propose the
>> following resolution for David's two comments above:
>>
>>      * generally, "diff-ext" will be updated to simply align
>> to the RSVP-TE
>> draft with respect to signaling LSPs without bandwidth reservation.
>> "diff-ext" will refer to RSVP-TE for details of how
>> Null-Service/TSSPEC
>> are used to signal LSP without bandwidth reservation.
>>
>>      * section 5.6 will be updated to reflect use of "Null-service"
>> instead of "COS service".
>>
>>      * section 5.6 can probably be shortened (because parts
>> of it came about
>> simply because of the confusion that stemmed from the "COS
>> service" and
>> its associated COS field. I believe some of that confusion naturally
>> goes away with the use of Null-Service).
>>
>>      * TSPEC will be made mandatory (in line with RSVP-TE-08)
>>
>>
>> Any comments/issues with this resolution?
>>
>> cheers
>>
>> Francois
>>
>> PS: David, thanks a lot for catching this.
>>
>
PLEASE NOTE NEW CONTACT DETAILS - See below

_________________________________________________________= ________
Francois Le Faucheur  
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :            &nb= sp;  +33 6 89 108 159
Fax:            =        +33 4 97 23 26 26
Email:           &nbs= p;      flefauch@cisco.com
_________________________________________________________________
Cisco Systems Europe
Domaine Green Side
400, Avenue de Roumanille
B=E2timent T3
06 410   BIOT
SOPHIA ANTIPOLIS
FRANCE
_________________________________________________________________ --=====================_22843789==_.ALT-- From owner-mpls@UU.NET Tue Apr 17 09:05:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06749 for ; Tue, 17 Apr 2001 09:05:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldk20206; Tue, 17 Apr 2001 13:02:59 GMT Received: by mail-control.mail.uu.net id QQkldk29806 for mpls-outgoing; Tue, 17 Apr 2001 13:02:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkldk29634 for ; Tue, 17 Apr 2001 13:02:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkldk23597 for ; Tue, 17 Apr 2001 13:01:33 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkldk19514 for ; Tue, 17 Apr 2001 13:01:33 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 8600694009; Tue, 17 Apr 2001 09:01:29 -0400 (EDT) Message-ID: <3ADC3EA9.46B234E8@sandburst.com> Date: Tue, 17 Apr 2001 09:01:29 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Eyad Saheb Cc: MPLS Mailing List Subject: Re: Explicit Null Label References: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eyad,

    Forgiven. :-)

    There is no need to identify the L3 protocol if the penultimate hop
has already done so.  Also, with the pointed exception of explicit
NULL labels, no label may be used that was not explicitly issued
by the LSR that receives them.  Therefore, only a very lame LSR
would issue a label which it will have to pop without knowing what
L3 will be underneath it.  In that sense, every LSR may create as
many 'explicit NULL' labels for as many underlying encapsulation
protocol/formats as it is capable of supporting.

    The inability of the penultimate hop to 'pop the stack' is exactly
one of the other examples implied in my earlier reply.  I believe in
trying the short answer first.

--
Eric Gray

You wrote:

 

Hi,

        Forgive my ignorance, but Explicit Null can still be used for its initial purpose: identifying the L3 protocol type.

        Also, and I'm not too versed in ATM, but it might be useful for switches which cannot pop the stack.  Thus the edges would send an Explicit Null mapping  if they are the egress for an LSP.

Eyad

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Eric Gray
Sent: April 17, 2001 8:16 a
To: anilg@acc.am.ericsson.se
Cc: mpls@UU.NET
Subject: Re: Explicit Null Label

Anil,

    It is not necessary to preserve the value of the EXP bits
using the explicit NULL label if the penultimate hop is able
to map the bits to a corresponding DSCP in the IP header.
But this is just one example of what the penultimate hop
might not be able to do, thus creating a need for explicit
NULL labels...

--
Eric Gray

You wrote:

> Is there any other purpose for an explicit null label other than preserving
> the Exp field for QoS purposes?
> Thanks,
> -Anil
>
> Anil Gunturu, Software Engineer
> Ericsson, Inc                           phone: (805) 562 6431
> Datacom & IP Services                   email: anilg@acc.am.ericsson.se
> 70 Castilian Dr, Santa Barbara, CA-93117

From owner-mpls@UU.NET Tue Apr 17 10:53:38 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09197 for ; Tue, 17 Apr 2001 10:53:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldr13668; Tue, 17 Apr 2001 14:51:13 GMT Received: by mail-control.mail.uu.net id QQkldr14476 for mpls-outgoing; Tue, 17 Apr 2001 14:50:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkldr14460 for ; Tue, 17 Apr 2001 14:50:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkldr05046 for ; Tue, 17 Apr 2001 14:48:45 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkldr29392 for ; Tue, 17 Apr 2001 14:48:44 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA39016; Tue, 17 Apr 2001 10:48:26 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104171448.KAA39016@workhorse.fictitious.org> To: Juha Heinanen cc: "Rajiv Papneja" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Does MPLS Require L3 Routing Table ? In-reply-to: Your message of "Sun, 15 Apr 2001 19:11:09 +0300." <15065.51229.525081.686724@lohi.eng.telia.fi> Date: Tue, 17 Apr 2001 10:48:26 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <15065.51229.525081.686724@lohi.eng.telia.fi>, Juha Heinanen writes: > Rajiv Papneja writes: > > > Also, I am not really sure that anyone has yet implemented this feature ov > er > > the unidirectional virtual circuits (for eg. MPLS LSPs). If possible can y > ou > > provide some more insight into this topic, I will more than interested to > > know about this. Thanks. > > see draft-heinanen-inarp-uni-01.txt, > > -- juha Looks worse than NHRP. Curtis From owner-mpls@UU.NET Tue Apr 17 11:32:40 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10251 for ; Tue, 17 Apr 2001 11:32:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldu18000; Tue, 17 Apr 2001 15:30:06 GMT Received: by mail-control.mail.uu.net id QQkldt07077 for mpls-outgoing; Tue, 17 Apr 2001 15:29:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkldt07060 for ; Tue, 17 Apr 2001 15:29:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkldt29912 for ; Tue, 17 Apr 2001 15:28:46 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkldt20767 for ; Tue, 17 Apr 2001 15:28:45 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA39248; Tue, 17 Apr 2001 11:28:29 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104171528.LAA39248@workhorse.fictitious.org> To: Eric Gray cc: anilg@acc.am.ericsson.se, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Explicit Null Label In-reply-to: Your message of "Tue, 17 Apr 2001 08:16:17 EDT." <3ADC3411.9F0FE2BA@sandburst.com> Date: Tue, 17 Apr 2001 11:28:29 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3ADC3411.9F0FE2BA@sandburst.com>, Eric Gray writes: > Anil, > > It is not necessary to preserve the value of the EXP bits > using the explicit NULL label if the penultimate hop is able > to map the bits to a corresponding DSCP in the IP header. > But this is just one example of what the penultimate hop > might not be able to do, thus creating a need for explicit > NULL labels... > > -- > Eric Gray That is only if the DSCP that is used outside the MPLS domain corresponds to the QoS treatment inside the MPLS domain. Any correlation between ingress into the MPLS domain and QoS at that point is lost. The explicit NULL just loses the LSP while preserving the EXP and is sufficient for unsignaled E-LSP where label is not considered. OTOH - One could make the argument that given the current state of QoS deployment, any arguments about whether some feature better supports QoS doesn't carry much weight. Curtis From owner-mpls@UU.NET Tue Apr 17 11:35:33 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10316 for ; Tue, 17 Apr 2001 11:35:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldu23616; Tue, 17 Apr 2001 15:33:18 GMT Received: by mail-control.mail.uu.net id QQkldu08034 for mpls-outgoing; Tue, 17 Apr 2001 15:32:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkldu08012 for ; Tue, 17 Apr 2001 15:32:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkldu13219 for ; Tue, 17 Apr 2001 15:31:47 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkldu24227 for ; Tue, 17 Apr 2001 15:31:45 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA39277; Tue, 17 Apr 2001 11:31:03 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104171531.LAA39277@workhorse.fictitious.org> To: Francois Le Faucheur cc: Sandeep Sharma , David Charlap , lberger@movaz.com, swallow@cisco.com, mpls@UU.NET, bsd@cisco.com, liwwu@europe.cisco.com, pasi.vaananen@nokia.com, ram64@lucent.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: WG Last call : Comment on COS service and TSPEC In-reply-to: Your message of "Tue, 17 Apr 2001 14:29:47 +0200." <200104171235.OAA19938@cisco.com> Date: Tue, 17 Apr 2001 11:31:03 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200104171235.OAA19938@cisco.com>, Francois Le Faucheur writes: > --=====================_22843789==_.ALT > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Sandeep and all, > > At 11:17 08/03/2001 -0600, Sandeep Sharma wrote: > >Francois, > > > >Your suggested changes are good! > > > >One comment: I think, in the context of E-LSP and L-LSP, there is a need to > >clarify use of the RSVP DCLASS object (RFC 2996) as referenced in the NULL > >service. > > > > How about adding the following clarifying statement (in section 5.6, which > will > be reworded to talk about Null service)? > > Note also that this specification does not concerned itself with the DCLASS > object defined in [DCLASS], since this object conveys information on DSCP > values, which are not relevant inside the MPLS network.=20 > > Thanks > > Francois That seems accurate and should cover it. Curtis From owner-mpls@UU.NET Tue Apr 17 11:51:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10629 for ; Tue, 17 Apr 2001 11:51:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldv27756; Tue, 17 Apr 2001 15:49:29 GMT Received: by mail-control.mail.uu.net id QQkldv10736 for mpls-outgoing; Tue, 17 Apr 2001 15:48:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkldv10717 for ; Tue, 17 Apr 2001 15:48:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkldv22040 for ; Tue, 17 Apr 2001 15:45:48 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkldv08944 for ; Tue, 17 Apr 2001 15:45:43 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 166C194006; Tue, 17 Apr 2001 11:45:43 -0400 (EDT) Message-ID: <3ADC6527.51AD9E56@sandburst.com> Date: Tue, 17 Apr 2001 11:45:43 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com Cc: anilg@acc.am.ericsson.se, mpls@UU.NET Subject: Re: Explicit Null Label References: <200104171528.LAA39248@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > In message <3ADC3411.9F0FE2BA@sandburst.com>, Eric Gray writes: > > Anil, > > > > It is not necessary to preserve the value of the EXP bits > > using the explicit NULL label if the penultimate hop is able > > to map the bits to a corresponding DSCP in the IP header. > > But this is just one example of what the penultimate hop > > might not be able to do, thus creating a need for explicit > > NULL labels... > > > > -- > > Eric Gray > > That is only if the DSCP that is used outside the MPLS domain > corresponds to the QoS treatment inside the MPLS domain. Any > correlation between ingress into the MPLS domain and QoS at that point > is lost. The explicit NULL just loses the LSP while preserving the > EXP and is sufficient for unsignaled E-LSP where label is not > considered. If the domain has also the ability to forward packets at the IP layer, then the domain boundary routers will know how to map an in-domain DSCP to an out-of-domain value. In this case, it is not necessary (however much simpler it may be) to pass the EXP to the egress (that is also a domain boundary router). > > > OTOH - One could make the argument that given the current state of QoS > deployment, any arguments about whether some feature better supports > QoS doesn't carry much weight. :-) > > > Curtis From owner-mpls@UU.NET Tue Apr 17 12:08:14 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10955 for ; Tue, 17 Apr 2001 12:08:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldw05579; Tue, 17 Apr 2001 16:05:59 GMT Received: by mail-control.mail.uu.net id QQkldw17646 for mpls-outgoing; Tue, 17 Apr 2001 16:05:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkldw17571 for ; Tue, 17 Apr 2001 16:05:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkldw07725 for ; Tue, 17 Apr 2001 16:04:56 GMT Received: from force10networks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQkldw29735 for ; Tue, 17 Apr 2001 16:04:56 GMT Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2653.19) id <243Z708T>; Tue, 17 Apr 2001 09:04:54 -0700 Message-ID: From: David Li To: "'MPLS@UU.NET'" Subject: A question on label next hop Date: Tue, 17 Apr 2001 09:04:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I wonder if it is possible for an upstream LSR to receive a label mapping from a downstream LSR such that the next hop ( the downstream LSR) for this label is NOT a directly connected peer of the upstream LSR, in other words, recursive resolution is needed on the upstream LSR to get the directly connected next hop to be used in forwarding. Thanks. ------------ David From owner-mpls@UU.NET Tue Apr 17 12:17:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11089 for ; Tue, 17 Apr 2001 12:17:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldx10863; Tue, 17 Apr 2001 16:15:07 GMT Received: by mail-control.mail.uu.net id QQkldw01170 for mpls-outgoing; Tue, 17 Apr 2001 16:14:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkldw01143 for ; Tue, 17 Apr 2001 16:14:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkldw28752 for ; Tue, 17 Apr 2001 16:12:00 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkldw09842 for ; Tue, 17 Apr 2001 16:11:59 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 JAA20334 for ; Tue, 17 Apr 2001 09:11:58 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA27279 for mpls@uu.net; Tue, 17 Apr 2001 12:11:57 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkksm16632 for ; Sat, 14 Apr 2001 14:09:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkksm13273 for ; Sat, 14 Apr 2001 14:09:48 GMT Received: from femail3.rdc1.on.home.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail3.rdc1.on.home.com [24.2.9.90]) id QQkksm27358 for ; Sat, 14 Apr 2001 14:09:47 GMT Received: from hotmail.com ([24.156.64.247]) by femail3.rdc1.on.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010414140910.BZOC19969.femail3.rdc1.on.home.com@hotmail.com>; Sat, 14 Apr 2001 07:09:10 -0700 Message-ID: <3AD85A04.D703909B@hotmail.com> Date: Sat, 14 Apr 2001 10:09:09 -0400 From: Gang Luo X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: junchen@site.uottawa.ca Subject: Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? We may prepare such a comparation article if there does not exist such one. the intial list of the drawbacks of compared with CR-LDP compared with RSVP-TE UNI ----------------------- * not so flexible to change the path properties once it was setup since there is not referesh mechanism. * ...? the intial list of the drawbacks of RSVP-TE UNI, compared with CR-LDP ----------------------- * there is no flow control, which results the waste of resources. * per-path based refreshment overhead, it is very substatial for big carriar networks. * message sized is limited by IP packet size, which may not be big enough for certain query services. * ....? Your help will be greatly appreciated. Best regards. Gang Luo. From owner-mpls@UU.NET Tue Apr 17 12:42:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11569 for ; Tue, 17 Apr 2001 12:42:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldy08865; Tue, 17 Apr 2001 16:39:26 GMT Received: by mail-control.mail.uu.net id QQkldy06433 for mpls-outgoing; Tue, 17 Apr 2001 16:38:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkldy06422 for ; Tue, 17 Apr 2001 16:38:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkldy16879 for ; Tue, 17 Apr 2001 16:38:19 GMT Received: from mail.disney.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.disney.com [204.128.192.15]) id QQkldy05633 for ; Tue, 17 Apr 2001 16:38:19 GMT Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f3HGblA20887 for ; Tue, 17 Apr 2001 09:37:47 -0700 (PDT) Received: from 1crp232.corp.disney.com by pain.corp.disney.com with ESMTP; Tue, 17 Apr 2001 09:39:02 -0700 Received: by 1crp232.corp.disney.com with Internet Mail Service (5.5.2653.19) id <2JC2FB7N>; Tue, 17 Apr 2001 09:38:18 -0700 Message-Id: From: "Holmes, David A." To: gluo88@hotmail.com, mpls@UU.NET Cc: junchen@site.uottawa.ca Subject: RE: Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? Date: Tue, 17 Apr 2001 09:38:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="GB2312" Sender: owner-mpls@UU.NET Precedence: bulk Gang, "MPLS Traffic Engineering: A Choice of Signaling Protocols" located at www.dataconnection.com is an overview presented by an MPLS software stack developer. Regards, David -----Original Message----- From: Gang Luo [mailto:gluo88@hotmail.com] Sent: Saturday, April 14, 2001 7:09 AM To: mpls@UU.NET Cc: junchen@site.uottawa.ca Subject: Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? Hi, Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? We may prepare such a comparation article if there does not exist such one. the intial list of the drawbacks of compared with CR-LDP compared with RSVP-TE UNI ----------------------- * not so flexible to change the path properties once it was setup since there is not referesh mechanism. * ...? the intial list of the drawbacks of RSVP-TE UNI, compared with CR-LDP ----------------------- * there is no flow control, which results the waste of resources. * per-path based refreshment overhead, it is very substatial for big carriar networks. * message sized is limited by IP packet size, which may not be big enough for certain query services. * ....? Your help will be greatly appreciated. Best regards. Gang Luo. From owner-mpls@UU.NET Tue Apr 17 12:44:59 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11630 for ; Tue, 17 Apr 2001 12:44:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldy12645; Tue, 17 Apr 2001 16:42:38 GMT Received: by mail-control.mail.uu.net id QQkldy06802 for mpls-outgoing; Tue, 17 Apr 2001 16:42:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkldy06760 for ; Tue, 17 Apr 2001 16:41:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkldy23214 for ; Tue, 17 Apr 2001 16:40:27 GMT From: Satish_Amara@3com.com Received: from topaz.3com.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: topaz.3com.com [192.156.136.158]) id QQkldy10212 for ; Tue, 17 Apr 2001 16:40:26 GMT Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3HGcGf27946; Tue, 17 Apr 2001 09:38:16 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f3HGdr913385; Tue, 17 Apr 2001 09:39:53 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A31.005B8823 ; Tue, 17 Apr 2001 09:39:46 -0700 X-Lotus-FromDomain: 3COM To: Gang Luo cc: mpls@UU.NET, junchen@site.uottawa.ca Message-ID: <88256A31.005B8450.00@hqoutbound.ops.3com.com> Date: Tue, 17 Apr 2001 11:36:57 -0500 Subject: Re: Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, Here is a link to white paper comparing RSVP-TE and CR-LDP ... http://www.dataconnection.com/mpls/mplsidx.htm Satish Amara. Gang Luo on 04/14/2001 09:09:09 AM Sent by: Gang Luo To: mpls@UU.NET cc: junchen@site.uottawa.ca (Satish Amara/MW/US/3Com) Subject: Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? Hi, Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? We may prepare such a comparation article if there does not exist such one. the intial list of the drawbacks of compared with CR-LDP compared with RSVP-TE UNI ----------------------- * not so flexible to change the path properties once it was setup since there is not referesh mechanism. * ...? the intial list of the drawbacks of RSVP-TE UNI, compared with CR-LDP ----------------------- * there is no flow control, which results the waste of resources. * per-path based refreshment overhead, it is very substatial for big carriar networks. * message sized is limited by IP packet size, which may not be big enough for certain query services. * ....? Your help will be greatly appreciated. Best regards. Gang Luo. From owner-mpls@UU.NET Tue Apr 17 12:55:09 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11726 for ; Tue, 17 Apr 2001 12:55:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldz23658; Tue, 17 Apr 2001 16:52:36 GMT Received: by mail-control.mail.uu.net id QQkldz08016 for mpls-outgoing; Tue, 17 Apr 2001 16:52:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkldz07957 for ; Tue, 17 Apr 2001 16:51:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkldz03479 for ; Tue, 17 Apr 2001 16:49:48 GMT From: djiang1@lucent.com Received: from hoemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQkldz29149 for ; Tue, 17 Apr 2001 16:49:47 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 MAA14679 for ; Tue, 17 Apr 2001 12:49:47 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA14672; Tue, 17 Apr 2001 12:49:47 -0400 (EDT) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA29143; Tue, 17 Apr 2001 12:49:46 -0400 (EDT) Subject: Re: A question on label next hop To: David Li Cc: "'MPLS@UU.NET'" Date: Tue, 17 Apr 2001 12:44:24 -0400 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 04/17/2001 12:44:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk HI David, I think what you said is possible. Check on section 3.27 of RFC3031 for detail. Regards, Jane D. Jiang David Li @UU.NET on 04/17/2001 12:04:46 PM Sent by: owner-mpls@UU.NET To: "'MPLS@UU.NET'" cc: Subject: A question on label next hop Hi, I wonder if it is possible for an upstream LSR to receive a label mapping from a downstream LSR such that the next hop ( the downstream LSR) for this label is NOT a directly connected peer of the upstream LSR, in other words, recursive resolution is needed on the upstream LSR to get the directly connected next hop to be used in forwarding. Thanks. ------------ David From owner-mpls@UU.NET Tue Apr 17 12:56:40 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11747 for ; Tue, 17 Apr 2001 12:56:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkldz22268; Tue, 17 Apr 2001 16:54:04 GMT Received: by mail-control.mail.uu.net id QQkldz08098 for mpls-outgoing; Tue, 17 Apr 2001 16:53:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkldz08075 for ; Tue, 17 Apr 2001 16:53:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkldz10506 for ; Tue, 17 Apr 2001 16:52:09 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkldz23154 for ; Tue, 17 Apr 2001 16:52:09 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA12773 for mpls@uu.net; Tue, 17 Apr 2001 12:52:08 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkldz07936 for ; Tue, 17 Apr 2001 16:51:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkldz26771 for ; Tue, 17 Apr 2001 16:51:24 GMT Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQkldz22337 for ; Tue, 17 Apr 2001 16:51:23 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3HGpXE26957; Tue, 17 Apr 2001 19:51:33 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15068.29845.396198.263942@lohi.eng.telia.fi> Date: Tue, 17 Apr 2001 19:51:33 +0300 (EEST) To: curtis@avici.com Cc: "Rajiv Papneja" , mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <200104171448.KAA39016@workhorse.fictitious.org> References: <15065.51229.525081.686724@lohi.eng.telia.fi> <200104171448.KAA39016@workhorse.fictitious.org> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar writes: > Looks worse than NHRP. i'm not sure if you understod the inarp draft. inarp is used over frame relay all over the world and the draft describes similar function for mpls. it's not very useful to send a message with the above contents without elaborating what is wrong with it. -- juha From owner-mpls@UU.NET Tue Apr 17 13:11:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11960 for ; Tue, 17 Apr 2001 13:11:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklea08248; Tue, 17 Apr 2001 17:08:32 GMT Received: by mail-control.mail.uu.net id QQklea26490 for mpls-outgoing; Tue, 17 Apr 2001 17:07:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklea26482 for ; Tue, 17 Apr 2001 17:07:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklea18723 for ; Tue, 17 Apr 2001 17:07:23 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQklea10265 for ; Tue, 17 Apr 2001 17:07:23 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 KAA15258 for ; Tue, 17 Apr 2001 10:07:47 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA27730 for mpls@uu.net; Tue, 17 Apr 2001 13:07:21 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklea17578 for ; Tue, 17 Apr 2001 17:02:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklea08496 for ; Tue, 17 Apr 2001 17:02:55 GMT Received: from mailroom.ecs.syr.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ecs.syr.edu [128.230.208.14]) id QQklea10069 for ; Tue, 17 Apr 2001 17:02:54 GMT Received: from apollo.ecs.syr.edu (apollo.ecs.syr.edu [128.230.208.46]) by mailroom.ecs.syr.edu (8.10.2/8.10.2) with ESMTP id f3HH2r819703; Tue, 17 Apr 2001 13:02:53 -0400 (EDT) Date: Tue, 17 Apr 2001 13:02:53 -0400 (EDT) From: Ibrahim Okumus To: gluo88@hotmail.com, mpls@UU.NET Subject: Does anyone know any article on advantage/drawback comparison Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk between RSVP-TE and CR-LDP? Data Connection has a white paper on this subject: "MPLS Traffic Engineering: A choice of Signalling protocols" analysis of the similarities and differences between the two primary MPLS label distribution protocols: RSVP and CR-LDP. From owner-mpls@UU.NET Tue Apr 17 13:32:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12205 for ; Tue, 17 Apr 2001 13:32:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklec18781; Tue, 17 Apr 2001 17:30:07 GMT Received: by mail-control.mail.uu.net id QQkleb28926 for mpls-outgoing; Tue, 17 Apr 2001 17:29:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkleb28902 for ; Tue, 17 Apr 2001 17:29:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkleb07251 for ; Tue, 17 Apr 2001 17:28:51 GMT Received: from auemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQkleb18386 for ; Tue, 17 Apr 2001 17:28:51 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA14528 for ; Tue, 17 Apr 2001 13:28:50 -0400 (EDT) Received: from md6370exch001p.wins.lucent.com (h135-114-206-50.lucent.com [135.114.206.50]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA14505 for ; Tue, 17 Apr 2001 13:28:50 -0400 (EDT) Received: by md6370exch001p.nse.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Apr 2001 13:28:50 -0400 Message-ID: From: "Natale, Robert C (Bob)" To: Gang Luo , mpls@UU.NET Cc: junchen@site.uottawa.ca Subject: RE: Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? Date: Tue, 17 Apr 2001 13:28:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Not an article, but a good ref all the same: Zheng Wang has a section (4.5.4) comparing CR-LDP and RSVP-TE (and a summary table on p. 174) in his book, "Internet QoS: Architectures and Mechanisms for Quality of Service". If he is reading the list, perhaps he can post a version of the table...? BobN From owner-mpls@UU.NET Tue Apr 17 13:55:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12408 for ; Tue, 17 Apr 2001 13:55:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkled24819; Tue, 17 Apr 2001 17:52:16 GMT Received: by mail-control.mail.uu.net id QQkled00957 for mpls-outgoing; Tue, 17 Apr 2001 17:51:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkled00941 for ; Tue, 17 Apr 2001 17:51:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkled26116 for ; Tue, 17 Apr 2001 17:50:04 GMT Received: from zcars04f.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQkled12109 for ; Tue, 17 Apr 2001 17:50:03 GMT Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 17 Apr 2001 13:49:26 -0400 Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JA4AB5BJ; Tue, 17 Apr 2001 13:49:27 -0400 Received: from americasm01.nt.com (philipma-1.ca.nortel.com [47.129.70.233]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2FLVVQLT; Tue, 17 Apr 2001 13:49:28 -0400 Message-ID: <3ADC209D.30F33335@americasm01.nt.com> Date: Tue, 17 Apr 2001 06:53:17 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wadhwa, Sanjay" , swallow@cisco.com CC: "'mpls@UU.NET'" Subject: Re: Comments on Bypass Label draft References: <49FF5C6DDBD8D311BBBD009027DE980C015260BB@UNIWEST1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sanjay: Sorry about the slow response. For some reason, both my original posting and your reply took nearly a week to reach me from the list server. "Wadhwa, Sanjay" wrote: > > >Robert, George: > > >Below are some comments on, and questions about, your bypass label draft. > > >- Philip > > >* Refreshing a backup tunnel riding a bypass tunnel > > I don't understand how the refresh works in this case. > > Section 2 states that the Path message for the backup tunnel is sent inside the bypass > > tunnel, while section 3 states that the SENDER_TEMPLATE object contains a sender address > > that differs from the address used for the primary LSP. So the merge point LSR will create > > a new Path State Block and try to send back a Resv message. But where does it send this > > Resv to? If the network is as shown in figure on page 4, then it can send the RESV message > > on either the link to R3 or the link to R7. However, in either case, R3 or R7 will intercept > > the Resv message, and because neither one is expecting a Resv message with this sender > > (because neither saw the corresponding Path message), problems ensue. > > Philip > My understanding is that the PHOP in the path message (for the backup tunnel) sent on > the bypass tunnel would be one of PLR's (R2's) addresses. Since the interface on which the > path arrived on R4 is uni-directional, R4 will have to just unicast route the resv back > to the PHOP. So rsvp on R3 or R7 will not be seeing it. > Maybe the draft should be more explicit about signalling for backup tunnels. > > -Sanjay Isn't this non-standard behavior? As I understand things, basic RSVP-TE (without any hierarchy extensions), requires neighbors to be adjacent. Path and Resv messages are addressed to the head end and tail end of the tunnel respectively, and are processed hop-by-hop as they proceed through the network. George claimed at the WG meeting in Minneapolis that no protocol extensions were required to implement this draft. The above seems to be in conflict with that claim. George: Any comments? - Philip From owner-mpls@UU.NET Tue Apr 17 15:45:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14910 for ; Tue, 17 Apr 2001 15:45:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklek26880; Tue, 17 Apr 2001 19:42:45 GMT Received: by mail-control.mail.uu.net id QQklek15338 for mpls-outgoing; Tue, 17 Apr 2001 19:42:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklek15329 for ; Tue, 17 Apr 2001 19:42:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklek02510 for ; Tue, 17 Apr 2001 19:40:38 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklek23717 for ; Tue, 17 Apr 2001 19:40:36 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA29118 for mpls@uu.net; Tue, 17 Apr 2001 15:40:36 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklek14800 for ; Tue, 17 Apr 2001 19:36:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklek19848 for ; Tue, 17 Apr 2001 19:35:01 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQklek29138 for ; Tue, 17 Apr 2001 19:35:01 GMT Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA14609; Tue, 17 Apr 2001 15:35:00 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA10962; Tue, 17 Apr 2001 15:35:00 -0400 (EDT) Message-Id: <200104171935.PAA10962@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: "Philip Matthews" cc: "Wadhwa, Sanjay" , swallow@cisco.com, "'mpls@UU.NET'" , swallow@cisco.com Subject: Re: Comments on Bypass Label draft In-reply-to: Your message of "Tue, 17 Apr 2001 06:53:17 EDT." <3ADC209D.30F33335@americasm01.nt.com> Date: Tue, 17 Apr 2001 15:35:00 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Isn't this non-standard behavior? As I understand things, basic RSVP-TE (without > any hierarchy extensions), requires neighbors to be adjacent. RSVP-TE builds on RFC2205. The assumption there was that a network may have a mix of RSVP capable and non-RSVP capable nodes. If a Path message is sent to a non-RSVP node, it simply passes through to the next node. If that node (or some subsequent node) is RSVP capable, then it does normal processing. When a Resv message comes, it will be forwarded back according to the PHOP. > Path and Resv messages > are addressed to the head end and tail end of the tunnel respectively, Path messages are addressed to the tail of the tunnel. Resv messages are address to the PHOP of the corresponding Path message. > and are processed hop-by-hop as they proceed through the network. They may or may not be processed hop-by-hop. > George claimed at the WG meeting in Minneapolis that no protocol > extensions were required to implement this draft. The above seems to > be in conflict with that claim. > > George: Any comments? I stand by my claim. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Apr 17 17:19:29 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16775 for ; Tue, 17 Apr 2001 17:19:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkler08656; Tue, 17 Apr 2001 21:17:14 GMT Received: by mail-control.mail.uu.net id QQkler29980 for mpls-outgoing; Tue, 17 Apr 2001 21:16:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkler29972 for ; Tue, 17 Apr 2001 21:16:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkleq12347 for ; Tue, 17 Apr 2001 21:14:28 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkleq20185 for ; Tue, 17 Apr 2001 21:14:27 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA06339 for mpls@uu.net; Tue, 17 Apr 2001 17:14:27 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkleq29232 for ; Tue, 17 Apr 2001 21:13:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkleq06982 for ; Tue, 17 Apr 2001 21:12:42 GMT Received: from exchange01.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.47.82.134]) id QQkleq17452 for ; Tue, 17 Apr 2001 21:12:42 GMT Received: from nfloat.movaz.com ([64.47.82.152]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 17 Apr 2001 17:10:23 -0400 Message-Id: <4.3.2.7.2.20010417170633.02440e90@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Apr 2001 17:12:17 -0400 To: ccamp@ops.ietf.org, mpls@UU.NET From: Lou Berger Subject: new rev of GMPLS signaling I-Ds Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Apr 2001 21:10:24.0663 (UTC) FILETIME=[D1D7CA70:01C0C782] Sender: owner-mpls@UU.NET Precedence: bulk All, It looks like the I-D folks are out (and not publishing) for a few days. For those interested updated versions of the generalized signaling docs, they are available at: http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-03.txt http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-02.txt http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-02.txt Per the last IETF, these drafts don't include SONET/SDH specifics. A new draft covering the specifics will be published in a few days. Lou (and co-authors) >Subject: Autoreply from Internet Draft Submission Manager >From: ietfauto@ietf.org (Internet Draft Submission Manager) > >Hello, > >This message is being sent to acknowledge receipt of your submission >or message to internet-drafts@ietf.org > >The I-D administrator will be out of the office until Monday, >April 23rd. All submissions will be processed. > >Thank you. We appreciate your understanding and patience. From owner-mpls@UU.NET Wed Apr 18 00:05:02 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22859 for ; Wed, 18 Apr 2001 00:05:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklfs01102; Wed, 18 Apr 2001 04:02:16 GMT Received: by mail-control.mail.uu.net id QQklfs21526 for mpls-outgoing; Wed, 18 Apr 2001 04:01:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklfs20494 for ; Wed, 18 Apr 2001 04:01:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklfs03997 for ; Wed, 18 Apr 2001 04:01:14 GMT From: ytr@123india.com Received: from c001.zsm.cp.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: c001-h000.c001.zsm.cp.net [209.228.56.114]) id QQklfs29953 for ; Wed, 18 Apr 2001 04:01:13 GMT Received: (cpmta 12887 invoked from network); 17 Apr 2001 21:01:12 -0700 Date: 17 Apr 2001 21:01:12 -0700 Message-ID: <20010418040112.12886.cpmta@c001.zsm.cp.net> X-Sent: 18 Apr 2001 04:01:12 GMT Received: from [132.233.247.5] by mail.123india.com with HTTP; 17 Apr 2001 21:01:12 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: djiang1@lucent.com Cc: dli@force10networks.com, MPLS@UU.NET X-Mailer: Web Mail 3.9.1.5 Subject: Re: A question on label next hop X-Sent-From: ytr@123india.com Sender: owner-mpls@UU.NET Precedence: bulk Hi, It is possible in Hirerachical scenarios.For more details refer section 3.27.5 of RFC 3031. Regards YTR On Tue, 17 April 2001, djiang1@lucent.com wrote: > > > HI David, > > I think what you said is possible. Check on section 3.27 of RFC3031 for > detail. > > Regards, > Jane D. Jiang > > > > > David Li @UU.NET on 04/17/2001 12:04:46 PM > > Sent by: owner-mpls@UU.NET > > > To: "'MPLS@UU.NET'" > cc: > Subject: A question on label next hop > > > Hi, > > I wonder if it is possible for an upstream LSR to receive a label mapping > from a downstream LSR such that the next hop ( the downstream LSR) for > this > label is NOT a directly connected peer of the upstream LSR, in other words, > recursive resolution is needed on the upstream LSR to get the directly > connected next hop to be used in forwarding. Thanks. > > ------------ > David ______________________________________________________ 123India.com - India's Premier Portal Get your Free Email Account at http://www.123india.com From owner-mpls@UU.NET Wed Apr 18 04:07:05 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07910 for ; Wed, 18 Apr 2001 04:07:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgi29464; Wed, 18 Apr 2001 08:04:03 GMT Received: by mail-control.mail.uu.net id QQklgi22908 for mpls-outgoing; Wed, 18 Apr 2001 08:03:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklgi21462 for ; Wed, 18 Apr 2001 08:03:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklgi00249 for ; Wed, 18 Apr 2001 08:02:31 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f29.law14.hotmail.com [64.4.21.29]) id QQklgi27920 for ; Wed, 18 Apr 2001 08:02:30 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 18 Apr 2001 01:02:30 -0700 Received: from 212.153.183.58 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 18 Apr 2001 08:02:29 GMT X-Originating-IP: [212.153.183.58] From: "MP LS" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Wed, 18 Apr 2001 10:02:29 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Apr 2001 08:02:30.0233 (UTC) FILETIME=[EA7FFC90:01C0C7DD] Sender: owner-mpls@UU.NET Precedence: bulk Hello all, I have some questions becasue something is verry strange to me. I just assumed that ATM-LSRS used an IP routing protocol (IGP) just for finding the topology of the network. But last i read an doccument and there they described that When you change an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. Can anyone make this clear for me?? Thanks a lot. Greetings, Niels Sitters. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Wed Apr 18 04:20:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07989 for ; Wed, 18 Apr 2001 04:20:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgj25552; Wed, 18 Apr 2001 08:17:49 GMT Received: by mail-control.mail.uu.net id QQklgj00028 for mpls-outgoing; Wed, 18 Apr 2001 08:17:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklgj00015 for ; Wed, 18 Apr 2001 08:17:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklgj14732 for ; Wed, 18 Apr 2001 08:15:40 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklgj20536 for ; Wed, 18 Apr 2001 08:15:40 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA05923 for mpls@uu.net; Wed, 18 Apr 2001 04:15:40 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklgj29854 for ; Wed, 18 Apr 2001 08:15:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklgi14275 for ; Wed, 18 Apr 2001 08:14:03 GMT Received: from dogwood.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dogwood.cisco.com [161.44.11.19]) id QQklgi01249 for ; Wed, 18 Apr 2001 08:14:03 GMT Received: from zhhong-W2K.cisco.com (beijing-dhcp-181-172.cisco.com [171.70.181.172]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA09453; Wed, 18 Apr 2001 04:13:47 -0400 (EDT) Message-Id: <5.0.2.1.0.20010418161031.03730f80@dogwood.cisco.com> X-Sender: zhhong@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 18 Apr 2001 16:11:22 +0800 To: "MP LS" , mpls-ops@mplsrc.com, mpls@UU.NET From: Zhi Hao Hong Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Cisco have OSPF support several years ago. Thanks. At 10:02 2001-4-18 +0200, MP LS wrote: >Hello all, > >I have some questions becasue something is verry strange to me. >I just assumed that ATM-LSRS used an IP routing protocol (IGP) just for finding the topology of the network. > >But last i read an doccument and there they described that When you change an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. Can anyone make this clear for me?? > >Thanks a lot. > >Greetings, > >Niels Sitters. > > >_________________________________________________________________________ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > From owner-mpls@UU.NET Wed Apr 18 04:30:22 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08059 for ; Wed, 18 Apr 2001 04:30:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgj10909; Wed, 18 Apr 2001 08:27:42 GMT Received: by mail-control.mail.uu.net id QQklgj00732 for mpls-outgoing; Wed, 18 Apr 2001 08:27:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklgj00721 for ; Wed, 18 Apr 2001 08:26:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklgj13006 for ; Wed, 18 Apr 2001 08:26:38 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklgj09198 for ; Wed, 18 Apr 2001 08:26:37 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA06814 for mpls@uu.net; Wed, 18 Apr 2001 04:26:37 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklgj00416 for ; Wed, 18 Apr 2001 08:22:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklgj26571 for ; Wed, 18 Apr 2001 08:21:22 GMT Received: from sj-msg-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQklgj16848 for ; Wed, 18 Apr 2001 08:21:21 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id BAA24926; Wed, 18 Apr 2001 01:19:59 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f3I8LGT07100; Wed, 18 Apr 2001 01:21:17 -0700 (PDT) Message-ID: <3ADD4E1F.D388E3C5@cisco.com> Date: Wed, 18 Apr 2001 01:19:43 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: MP LS CC: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. No way :). R. > MPLS wrote: > > Hello all, > > I have some questions becasue something is verry strange to me. > I just assumed that ATM-LSRS used an IP routing protocol (IGP) just for > finding the topology of the network. > > But last i read an doccument and there they described that When you change > an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. Can > anyone make this clear for me?? > > Thanks a lot. > > Greetings, > > Niels Sitters. > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Wed Apr 18 04:47:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08197 for ; Wed, 18 Apr 2001 04:47:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgl08349; Wed, 18 Apr 2001 08:45:06 GMT Received: by mail-control.mail.uu.net id QQklgk01875 for mpls-outgoing; Wed, 18 Apr 2001 08:44:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklgk01863 for ; Wed, 18 Apr 2001 08:44:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklgk24124 for ; Wed, 18 Apr 2001 08:44:14 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQklgk06949 for ; Wed, 18 Apr 2001 08:44:13 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 18 Apr 2001 14:22:02 +0530 Received: from abdulmk (abdulmk.future.futsoft.com [10.8.7.11]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f3I8imx06313; Wed, 18 Apr 2001 14:14:48 +0530 Message-Id: <000201c0c7e3$96c0df60$0b07080a@future.futsoft.com> Reply-To: "Abdul Malick" From: "Abdul Malick" To: Cc: References: <3AD85A04.D703909B@hotmail.com> Subject: Re: Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? Date: Wed, 18 Apr 2001 09:17:51 +0530 Organization: Future Software Ltd., MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Please visit http://www.dataconnection.com/mpls/mplsidx.htm Cheers Malick ----- Original Message ----- From: "Gang Luo" To: Cc: Sent: Saturday, April 14, 2001 7:39 PM Subject: Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? > Hi, > > Does anyone know any article on advantage/drawback comparison between > RSVP-TE and CR-LDP? > > We may prepare such a comparation article if there does not exist such > one. > > > the intial list of the drawbacks of compared with CR-LDP compared with > RSVP-TE UNI > ----------------------- > > * not so flexible to change the path properties once it was setup > since there is not referesh mechanism. > * ...? > > > the intial list of the drawbacks of RSVP-TE UNI, compared with CR-LDP > ----------------------- > > * there is no flow control, which results the waste of resources. > * per-path based refreshment overhead, it is very substatial for big > carriar networks. > * message sized is limited by IP packet size, which may not be big > enough for certain query services. > * ....? > > Your help will be greatly appreciated. > > > Best regards. > Gang Luo. > > > > From owner-mpls@UU.NET Wed Apr 18 05:10:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08381 for ; Wed, 18 Apr 2001 05:10:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgm20915; Wed, 18 Apr 2001 09:07:12 GMT Received: by mail-control.mail.uu.net id QQklgm20481 for mpls-outgoing; Wed, 18 Apr 2001 09:06:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklgm20469 for ; Wed, 18 Apr 2001 09:06:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklgm11245 for ; Wed, 18 Apr 2001 09:05:21 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQklgm10375 for ; Wed, 18 Apr 2001 09:05:20 GMT Received: from gayatri.hclt.com (GAYATRI [192.168.232.199]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 29YCAJCW; Wed, 18 Apr 2001 14:46:32 +0530 Received: from VIJAYC ([192.168.232.145]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 24KQ028J; Wed, 18 Apr 2001 14:39:41 +0530 From: "Vijayanand C" To: Cc: Subject: Label distribution mode Date: Wed, 18 Apr 2001 14:34:01 +0530 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have a question in LDP. Suppose, we have a per-platform label space entity bound to PPP and Ethernet interfaces. Assume that the entity has been configured for Downstream on demand and a session is already established with a peer. Now, while establishing a new session with another peer, if that peer says Unsiolicited mode in the Init message then the RFC says that we have to use Unsolicited only. However the entity has been configured for ON-DEMAND and a session with another entity is already running for that entity. How do we handle this situation? Should we have another enity for this session and have a one-to-one relationship between entity and session. Or can we treat this as mis-configuration and reject the session establishment attempt. Regards, Vijay From owner-mpls@UU.NET Wed Apr 18 05:13:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08454 for ; Wed, 18 Apr 2001 05:13:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgm24917; Wed, 18 Apr 2001 09:10:42 GMT Received: by mail-control.mail.uu.net id QQklgm20955 for mpls-outgoing; Wed, 18 Apr 2001 09:10:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklgm20853 for ; Wed, 18 Apr 2001 09:09:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklgm24383 for ; Wed, 18 Apr 2001 09:09:31 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklgm03889 for ; Wed, 18 Apr 2001 09:09:30 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA09451 for mpls@uu.net; Wed, 18 Apr 2001 05:09:30 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklgm20682 for ; Wed, 18 Apr 2001 09:08:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklgm11531 for ; Wed, 18 Apr 2001 09:08:25 GMT Received: from salamander.eu.fore.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: salamander.eu.fore.com [193.132.138.12]) id QQklgm02460 for ; Wed, 18 Apr 2001 09:08:07 GMT Received: from gbennett-pc.eu.fore.com (dhcp-170-38 [169.144.170.38]) by salamander.eu.fore.com (8.9.1/8.9.1) with SMTP id KAA21530; Wed, 18 Apr 2001 10:06:06 +0100 (BST) Message-Id: <200104180906.KAA21530@salamander.eu.fore.com> X-Sender: gbennett@salamander.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 18 Apr 2001 11:14:37 +0100 To: "MP LS" , mpls-ops@mplsrc.com, mpls@UU.NET From: Geoff Bennett Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Niels, There may be some confusion arising depending on how you configure the ATM switch. In effect there are three modes of operation for this device... 1. Pure ATM. In this case the switch will operate UNI and NNI interfaces, and will run PNNI as its routing protocol (PNNI is both an IGP and EGP). UNI and PNNI signalling will happen on VCI 5. 2. Pure MPLS. In this mode, there is no ATM signalling, and no PNNI. MPLS routing and signalling (OSPF, ISIS, CR-LDP, RSVP-TE, etc.) will pass over VCI 32 (note, please check the latest draft for the actual VCI number, it's a while since I read this info). 3. Ships in the Night (SIN). In this case, both ATM and MPLS Control Planes operate simultaneously. ATM signalling happens on VCI 5, and MPLS signalling on VCI 32. VCs that are set up as a result of signalling are "owned" by one or other of these control planes. SIN would allow an operator to continue to run high revenue voice services (and maybe existing Frame Relay or native ATM services...they make money too) over the ATM "character" of the switch. They can then run the loss-making Internet services over the MPLS character. I think there are ideas floating around about a more integrated control plane for ATM/MPLS switches based on PNNI, but I don't think these have made it to draft as yet. Cheers, Geoff At 10:02 18/04/01 +0200, MP LS wrote: >Hello all, > >I have some questions becasue something is verry strange to me. >I just assumed that ATM-LSRS used an IP routing protocol (IGP) just for >finding the topology of the network. > >But last i read an doccument and there they described that When you change >an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. Can >anyone make this clear for me?? > >Thanks a lot. > >Greetings, > >Niels Sitters. > > >_________________________________________________________________________ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > ================================================================ Geoff Bennett Tel: (33) 497 21 43 62 Director of Technology, OCTO Fax: (33) 497 21 43 50 Marconi Gaia - Bat. E email: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ From owner-mpls@UU.NET Wed Apr 18 05:50:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08634 for ; Wed, 18 Apr 2001 05:50:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgp00202; Wed, 18 Apr 2001 09:47:07 GMT Received: by mail-control.mail.uu.net id QQklgp24149 for mpls-outgoing; Wed, 18 Apr 2001 09:46:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklgp24112 for ; Wed, 18 Apr 2001 09:46:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklgp11223 for ; Wed, 18 Apr 2001 09:45:42 GMT Received: from nausicaa.coritel.it by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [193.205.242.5]) id QQklgp28742 for ; Wed, 18 Apr 2001 09:45:41 GMT Received: from kafka (kafka [141.137.43.37]) by nausicaa.coritel.it (8.11.2/8.11.2) with SMTP id f3I8ldu27881; Wed, 18 Apr 2001 10:47:39 +0200 Message-ID: <004801c0c7ec$769290e0$252b898d@kafka.coritel.it> From: "Alessio Botta" To: , Subject: Commentson OSPF Opaque LSA Option RFC 2370 Date: Wed, 18 Apr 2001 11:46:37 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C0C7FD.39845100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C0C7FD.39845100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have an observation on RFC 2370: "The OSPF Opaque LSA Option". In Sec. 3.0 it says: "The packet format of the Opaque LSA is given in = Appendix A. Section 7.0 describes Opaque Type allocation and = assignment." But Section 7.0 is "IANA Considerations" and is not about Opaque Type. = Where can I find any informations about the link-state ID of the Opaque = LSA? Thanks for your kindness Best Reguards, Alessio ------=_NextPart_000_0045_01C0C7FD.39845100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
I have an observation on RFC 2370: "The OSPF Opaque LSA = Option".
In Sec. 3.0 it says: "The packet format of the = Opaque LSA=20 is given in Appendix A. Section 7.0 describes Opaque Type allocation and = assignment."
But Section 7.0 is "IANA Considerations" = and is not=20 about Opaque Type. Where can I find any informations about the = link-state ID of=20 the Opaque LSA?
Thanks for your kindness
Best Reguards,
Alessio
------=_NextPart_000_0045_01C0C7FD.39845100-- From owner-mpls@UU.NET Wed Apr 18 06:08:37 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08754 for ; Wed, 18 Apr 2001 06:08:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgq18931; Wed, 18 Apr 2001 10:05:50 GMT Received: by mail-control.mail.uu.net id QQklgq12291 for mpls-outgoing; Wed, 18 Apr 2001 10:05:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklgq11971 for ; Wed, 18 Apr 2001 10:05:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklgq26672 for ; Wed, 18 Apr 2001 10:04:37 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklgq20048 for ; Wed, 18 Apr 2001 10:04:37 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA12751 for mpls@uu.net; Wed, 18 Apr 2001 06:04:37 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklgq10524 for ; Wed, 18 Apr 2001 10:04:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklgq04742 for ; Wed, 18 Apr 2001 10:03:21 GMT Received: from mail.korea.ac.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: korea.ac.kr [163.152.1.251]) id QQklgq17984 for ; Wed, 18 Apr 2001 10:03:20 GMT Received: from mail-virus (smtp.korea.ac.kr [163.152.1.128]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id SAA87772; Wed, 18 Apr 2001 18:53:25 +0900 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3IA2Uq32371; Wed, 18 Apr 2001 06:02:30 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-ID: <3ADD4E1F.D388E3C5@cisco.com> Date: Wed, 18 Apr 2001 01:19:43 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: MP LS CC: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Mailing-List: archive/latest/990 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit > an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. No way :). R. > MPLS wrote: > > Hello all, > > I have some questions becasue something is verry strange to me. > I just assumed that ATM-LSRS used an IP routing protocol (IGP) just for > finding the topology of the network. > > But last i read an doccument and there they described that When you change > an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. Can > anyone make this clear for me?? > > Thanks a lot. > > Greetings, > > Niels Sitters. > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Wed Apr 18 06:21:52 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08835 for ; Wed, 18 Apr 2001 06:21:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgr02708; Wed, 18 Apr 2001 10:18:59 GMT Received: by mail-control.mail.uu.net id QQklgr13977 for mpls-outgoing; Wed, 18 Apr 2001 10:18:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklgr13969 for ; Wed, 18 Apr 2001 10:18:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklgr18695 for ; Wed, 18 Apr 2001 10:18:06 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQklgr01795 for ; Wed, 18 Apr 2001 10:18:05 GMT Received: from goneto.net (unknown [195.167.134.116]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id B531F15F7E6; Wed, 18 Apr 2001 11:17:59 +0100 (BST) Message-ID: <3ADD76AD.106BBDFA@goneto.net> Date: Wed, 18 Apr 2001 12:12:45 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Philip Matthews Cc: David Charlap , mpls@UU.NET Subject: Re: LDP remote peer question References: <3ACCE057.2C4A2C27@marconi.com> <3AD51303.1047B147@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 Philip Matthews wrote: > > David: > > I don't see how one can support targetted LDP sessions without using > a platform-wide label space, unless you can ensure that the packets > only arrive on one interface. How about turning off PHP for the "outer" label established hop-by-hop? That way packets associated with a targetted LDP session would arrive with an explicit null label prepended to them. Then you could associate the labels established through the targetted session with a loopback interface. Probably a moot point in that interface-specific labels are mostly used whem there are hardware restrictions... > If you have hardware restrictions (for example, ATM hardware) that > begs for interface-specific labels, then one solution might be to reserve > a small portion of the range and allocate it in a platform-wide manner. Yes, that would work. But I'm not sure you'd need to "reserve" the label range? It is a case of ensuring that the label mapping is present on every interface that might receive a labelled packet. In the LDP/RSVP case (where the targetted LDP session is established between LSRs at either side of the RSVP-TE domain) you could probably just instantiate the mapping on all interfaces within the IGP area being used for TE? Giles > > - Philip > > David Charlap wrote: > > > > I've a question regarding remote peers and the LDP protocol. > > > > Remote peers are managed using unicast UDP messages for Hello and TCP > > session. These peers are not (I think) bound to an interface. Which > > means that if the local routing table should change, then the interface > > associated with the remote peer may also change. > > > > If per-platform label spaces are used, this is not a problem. > > > > On routers with per-interface label spaces, however, this might be a > > real problem. Once the TCP socket moves to a different interface, all > > of its labels must also move. This may not be possible, since there may > > be conflicting label assignments on the new interface. But to release > > all of the remote peer's labels before the move, and then re-request > > them afterwards is a lot of overhead. And it will cause service > > interruptions during this reconvergence period. > > > > Is this correct? Is there a solution to this problem? > > > > Obviously, the best way is to implement per-platform label spaces, but > > this is may not be possible (or efficient) on all hardware platforms. > > > > -- David -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Wed Apr 18 06:53:47 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09027 for ; Wed, 18 Apr 2001 06:53:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgt00256; Wed, 18 Apr 2001 10:50:58 GMT Received: by mail-control.mail.uu.net id QQklgt16546 for mpls-outgoing; Wed, 18 Apr 2001 10:50:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklgt16533 for ; Wed, 18 Apr 2001 10:50:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklgt10562 for ; Wed, 18 Apr 2001 10:49:23 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQklgt26560 for ; Wed, 18 Apr 2001 10:49:16 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3IAkWs14003; Wed, 18 Apr 2001 16:16:32 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A32.0039C88F ; Wed, 18 Apr 2001 16:01:08 +0530 X-Lotus-FromDomain: HSS To: "Vijayanand C" cc: mpls@UU.NET, loa.andersson@nortelnetworks.com Message-ID: <65256A32.0039C79D.00@sandesh.hss.hns.com> Date: Wed, 18 Apr 2001 16:01:05 +0530 Subject: Re: Label distribution mode Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi Vijay! as far as my understanding goes there is no harm in maintaining two diffrent modes of operation with two diffrent peer entities. The RFC does not state otherwise( neither in favour too!!!). I guess this has a definite value-add in terms of providing for a heterogenously configured network. But then again this would complicate the software in terms of its control and functioning. I guess it is up to the user to decide if its worth the effort. ;o) ciao sumit "Vijayanand C" on 04/18/2001 02:34:01 PM To: loa.andersson@nortelnetworks.com cc: mpls@UU.NET (bcc: Sumit Chauhan/HSS) Subject: Label distribution mode Hello, I have a question in LDP. Suppose, we have a per-platform label space entity bound to PPP and Ethernet interfaces. Assume that the entity has been configured for Downstream on demand and a session is already established with a peer. Now, while establishing a new session with another peer, if that peer says Unsiolicited mode in the Init message then the RFC says that we have to use Unsolicited only. However the entity has been configured for ON-DEMAND and a session with another entity is already running for that entity. How do we handle this situation? Should we have another enity for this session and have a one-to-one relationship between entity and session. Or can we treat this as mis-configuration and reject the session establishment attempt. Regards, Vijay From owner-mpls@UU.NET Wed Apr 18 08:16:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09810 for ; Wed, 18 Apr 2001 08:16:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgy10808; Wed, 18 Apr 2001 12:13:47 GMT Received: by mail-control.mail.uu.net id QQklgy26867 for mpls-outgoing; Wed, 18 Apr 2001 12:13:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklgy26859 for ; Wed, 18 Apr 2001 12:13:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklgy11492 for ; Wed, 18 Apr 2001 12:12:58 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQklgy25254 for ; Wed, 18 Apr 2001 12:12:58 GMT Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 18 Apr 2001 08:09:21 -0400 Received: from zcard04k.ca.nortel.com ([47.129.242.84]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JA4AFFFS; Wed, 18 Apr 2001 08:09:22 -0400 Received: from americasm01.nt.com (philipma-1.ca.nortel.com [47.129.70.233]) by zcard04k.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2FLVVRKT; Wed, 18 Apr 2001 08:09:22 -0400 Message-ID: <3ADD8456.777291BE@americasm01.nt.com> Date: Wed, 18 Apr 2001 08:11:02 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: "Wadhwa, Sanjay" , "'mpls@UU.NET'" Subject: Re: Comments on Bypass Label draft References: <200104171935.PAA10962@telescope.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George: Thanks for your reply. I think I understand the refresh mechanism in your draft now. I had mistakenly thought that a node implementing RSVP-TE needed to check that the PHOP and NHOP were directly adjacent (in order to ensure the LSP was not set up through a non-RSVP-TE node). However, from your reply, and a re-read of RFC2205, I now understand that the correct test is for the node receiving the Path message to check that the TTL field in the IP header against the Send_TTL in the common header. No check is necessary on received Resv messages. When refreshing over a bypass tunnel, the TTL will not be decremented inside the tunnel, so the Path message will still pass the TTL check at the merge node. As for the Resv message, it will be sent back over whatever path still exists between the merge node and the PLR. Its destination address is the PLR node, so the intervening nodes will forward it with any further processing. (While IGP routing is reconverging, the Resv messages may be lost, but assuming a generous refresh interval, the IGP should reconverge before the Path and Resv state times out). Thanks again. - Philip George Swallow wrote: > > > Isn't this non-standard behavior? As I understand things, basic RSVP-TE (without > > any hierarchy extensions), requires neighbors to be adjacent. > > RSVP-TE builds on RFC2205. The assumption there was that a network > may have a mix of RSVP capable and non-RSVP capable nodes. If a Path > message is sent to a non-RSVP node, it simply passes through to the > next node. If that node (or some subsequent node) is RSVP capable, > then it does normal processing. When a Resv message comes, it will be > forwarded back according to the PHOP. > > > Path and Resv messages > > are addressed to the head end and tail end of the tunnel respectively, > > Path messages are addressed to the tail of the tunnel. Resv messages > are address to the PHOP of the corresponding Path message. > > > and are processed hop-by-hop as they proceed through the network. > > They may or may not be processed hop-by-hop. > > > George claimed at the WG meeting in Minneapolis that no protocol > > extensions were required to implement this draft. The above seems to > > be in conflict with that claim. > > > > George: Any comments? > > I stand by my claim. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Apr 18 08:23:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09860 for ; Wed, 18 Apr 2001 08:23:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklgz17857; Wed, 18 Apr 2001 12:20:22 GMT Received: by mail-control.mail.uu.net id QQklgz27655 for mpls-outgoing; Wed, 18 Apr 2001 12:20:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklgz27579 for ; Wed, 18 Apr 2001 12:19:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklgz27220 for ; Wed, 18 Apr 2001 12:18:37 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQklgz03662 for ; Wed, 18 Apr 2001 12:18:37 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 FAA19669 for ; Wed, 18 Apr 2001 05:19:00 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA00329 for mpls@uu.net; Wed, 18 Apr 2001 08:18:35 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklgm16034 for ; Wed, 18 Apr 2001 09:03:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklgm07779 for ; Wed, 18 Apr 2001 09:03:47 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQklgm08025 for ; Wed, 18 Apr 2001 09:03:46 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id <2XLWL77T>; Wed, 18 Apr 2001 11:03:00 +0200 Message-ID: From: Javier Antich To: mpls@UU.NET Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Wed, 18 Apr 2001 11:02:59 +0200 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 IAA09860 > Hi > > If all ATM switches are MPLS capables, that is, they are able to run IP > routing protocols like OSPF/IS-IS then they behave like neighbouring > routers and use those routing protocols and LDP for label assignment and > therefore for LSP establishment. However if you have two ATM-LSR which > need to communicate accross a standar ATM cloud, you may have either aVP > established, what would lead us to the previous case, or use SVCs > established by normal ATM signalling (i.e. PNNI) and SVC-to-LSP binding by > using VCID Notification. In this case the ATM-LSRs would be using both > OSPF/IS-IS and PNNI. > > > ^ ^ > ==============ooo====(.)v(.)====ooo===== > Javier Antich Romaguera > Network Consultant > -------------------------------------------------------------------------- > - > TELINDUS > Pza. Ciudad de Viena, 6-2º > 28040 Madrid > -------------------------------------------------------------------------- > - > javier.antich@telindus.es > tel: +34 91 456 00 08 > fax: +34 91 536 10 74 > -------------------------------------------------------------------------- > - > For more information about our products and services, > please visit our website http://www.telindus.com > -------------------------------------------------------------------------- > - > Full connectivity & mobility > ==================ooo0===0ooo======== > > > > -----Mensaje original----- > De: MP LS [SMTP:stagempls@hotmail.com] > Enviado el: miércoles 18 de abril de 2001 10:02 > Para: mpls-ops@mplsrc.com; mpls@UU.NET > Asunto: ATM-LSR do they use OSPF/IS-IS or PNNI?? > > Hello all, > > I have some questions becasue something is verry strange to me. > I just assumed that ATM-LSRS used an IP routing protocol (IGP) just for > finding the topology of the network. > > But last i read an doccument and there they described that When you change > > an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. Can > anyone make this clear for me?? > > Thanks a lot. > > Greetings, > > Niels Sitters. > > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Wed Apr 18 09:06:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10478 for ; Wed, 18 Apr 2001 09:06:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklhc16392; Wed, 18 Apr 2001 13:03:20 GMT Received: by mail-control.mail.uu.net id QQklhc09984 for mpls-outgoing; Wed, 18 Apr 2001 13:02:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklhc09945 for ; Wed, 18 Apr 2001 13:02:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklhc03188 for ; Wed, 18 Apr 2001 13:01:08 GMT Received: from mail-blue.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQklhc12547 for ; Wed, 18 Apr 2001 13:01:03 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 84F8A4CEF8; Wed, 18 Apr 2001 09:01:03 -0400 (EDT) Received: from research.att.com (pc-halperin.research.att.com [135.207.27.244]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id JAA09415; Wed, 18 Apr 2001 09:01:02 -0400 (EDT) Message-ID: <3ADD882C.6CF43778@research.att.com> Date: Wed, 18 Apr 2001 08:27:24 -0400 From: Dongmei X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Alessio Botta Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Commentson OSPF Opaque LSA Option RFC 2370 References: <004801c0c7ec$769290e0$252b898d@kafka.coritel.it> Content-Type: multipart/alternative; boundary="------------27E9CF2C3C144C9560C0573D" Sender: owner-mpls@UU.NET Precedence: bulk --------------27E9CF2C3C144C9560C0573D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, You may find the information about the link-ID of the opaque-LSA in the draft: Traffic Engineering Extensions to OSPF Dongmei Alessio Botta wrote: > Hello,I have an observation on RFC 2370: "The OSPF Opaque LSA > Option".In Sec. 3.0 it says: "The packet format of the Opaque LSA is > given in Appendix A. Section 7.0 describes Opaque Type allocation and > assignment."But Section 7.0 is "IANA Considerations" and is not about > Opaque Type. Where can I find any informations about the link-state ID > of the Opaque LSA?Thanks for your kindnessBest Reguards,Alessio --------------27E9CF2C3C144C9560C0573D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
You may find the information about the link-ID of the opaque-LSA in the draft:
Traffic Engineering Extensions to OSPF
<draft-katz-yeung-spf-traffic-04.txt>
Dongmei

Alessio Botta wrote:

 Hello,I have an observation on RFC 2370: "The OSPF Opaque LSA Option".In Sec. 3.0 it says: "The packet format of the Opaque LSA is given in Appendix A. Section 7.0 describes Opaque Type allocation and assignment."But Section 7.0 is "IANA Considerations" and is not about Opaque Type. Where can I find any informations about the link-state ID of the Opaque LSA?Thanks for your kindnessBest Reguards,Alessio
--------------27E9CF2C3C144C9560C0573D-- From owner-mpls@UU.NET Wed Apr 18 10:41:40 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12055 for ; Wed, 18 Apr 2001 10:41:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklhi19045; Wed, 18 Apr 2001 14:38:24 GMT Received: by mail-control.mail.uu.net id QQklhi14766 for mpls-outgoing; Wed, 18 Apr 2001 14:37:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklhi14750 for ; Wed, 18 Apr 2001 14:37:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklhi26927 for ; Wed, 18 Apr 2001 14:37:30 GMT Received: from dnsmx1rrc.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQklhi24626 for ; Wed, 18 Apr 2001 14:37:30 GMT Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with SMTP id KAA28226; Wed, 18 Apr 2001 10:33:00 -0400 (EDT) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256A32.004FEC2F ; Wed, 18 Apr 2001 10:32:57 -0400 X-Lotus-FromDomain: TELCORDIA From: "Robert Streijl" To: Gang Luo cc: mpls@UU.NET Message-ID: <85256A32.004FEAF8.00@notes950.cc.telcordia.com> Date: Wed, 18 Apr 2001 10:32:41 -0400 Subject: Re: Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, As everybody already recommended DataCommunications, here is two others, one from Cisco (so very RSVP oriented). Anyway, maybe of some use. http://www.telecommagazine.com/issues/200011/tcs/signaling_in_mpls.html http://www.telecommagazine.com/issues/200011/tcs/cd-ldp_for_value.html Rob Gang Luo on 04/14/2001 10:09:09 AM To: mpls@UU.NET cc: junchen@site.uottawa.ca (bcc: Robert Streijl/Telcordia) Subject: Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? Hi, Does anyone know any article on advantage/drawback comparison between RSVP-TE and CR-LDP? We may prepare such a comparation article if there does not exist such one. the intial list of the drawbacks of compared with CR-LDP compared with RSVP-TE UNI ----------------------- * not so flexible to change the path properties once it was setup since there is not referesh mechanism. * ...? the intial list of the drawbacks of RSVP-TE UNI, compared with CR-LDP ----------------------- * there is no flow control, which results the waste of resources. * per-path based refreshment overhead, it is very substatial for big carriar networks. * message sized is limited by IP packet size, which may not be big enough for certain query services. * ....? Your help will be greatly appreciated. Best regards. Gang Luo. From owner-mpls@UU.NET Wed Apr 18 11:04:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12459 for ; Wed, 18 Apr 2001 11:04:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklhk21303; Wed, 18 Apr 2001 15:02:14 GMT Received: by mail-control.mail.uu.net id QQklhk21231 for mpls-outgoing; Wed, 18 Apr 2001 15:01:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklhk21004 for ; Wed, 18 Apr 2001 15:01:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklhk27497 for ; Wed, 18 Apr 2001 15:00:13 GMT Received: from mail.korea.ac.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: korea.ac.kr [163.152.1.251]) id QQklhk16452 for ; Wed, 18 Apr 2001 15:00:12 GMT Received: from mail-virus (smtp.korea.ac.kr [163.152.1.128]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id XAA124336; Wed, 18 Apr 2001 23:49:23 +0900 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3IEvx725788; Wed, 18 Apr 2001 10:57:59 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-ID: <3ADD882C.6CF43778@research.att.com> Date: Wed, 18 Apr 2001 08:27:24 -0400 From: Dongmei X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Alessio Botta Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Commentson OSPF Opaque LSA Option RFC 2370 References: <004801c0c7ec$769290e0$252b898d@kafka.coritel.it> Content-Type: multipart/alternative; boundary="------------27E9CF2C3C144C9560C0573D" X-Mailing-List: archive/latest/993 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk --------------27E9CF2C3C144C9560C0573D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, You may find the information about the link-ID of the opaque-LSA in the draft: Traffic Engineering Extensions to OSPF Dongmei Alessio Botta wrote: > Hello,I have an observation on RFC 2370: "The OSPF Opaque LSA > Option".In Sec. 3.0 it says: "The packet format of the Opaque LSA is > given in Appendix A. Section 7.0 describes Opaque Type allocation and > assignment."But Section 7.0 is "IANA Considerations" and is not about > Opaque Type. Where can I find any informations about the link-state ID > of the Opaque LSA?Thanks for your kindnessBest Reguards,Alessio --------------27E9CF2C3C144C9560C0573D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
You may find the information about the link-ID of the opaque-LSA in the draft:
Traffic Engineering Extensions to OSPF
<draft-katz-yeung-spf-traffic-04.txt>
Dongmei

Alessio Botta wrote:

 Hello,I have an observation on RFC 2370: "The OSPF Opaque LSA Option".In Sec. 3.0 it says: "The packet format of the Opaque LSA is given in Appendix A. Section 7.0 describes Opaque Type allocation and assignment."But Section 7.0 is "IANA Considerations" and is not about Opaque Type. Where can I find any informations about the link-state ID of the Opaque LSA?Thanks for your kindnessBest Reguards,Alessio
--------------27E9CF2C3C144C9560C0573D-- ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Wed Apr 18 12:57:52 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14287 for ; Wed, 18 Apr 2001 12:57:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklhr11502; Wed, 18 Apr 2001 16:55:17 GMT Received: by mail-control.mail.uu.net id QQklhr01573 for mpls-outgoing; Wed, 18 Apr 2001 16:54:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklhr01568 for ; Wed, 18 Apr 2001 16:54:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklhr08835 for ; Wed, 18 Apr 2001 16:54:18 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklhr05641 for ; Wed, 18 Apr 2001 16:54:18 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13334 for ; Wed, 18 Apr 2001 12:54:14 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24759 for ; Wed, 18 Apr 2001 12:54:16 -0400 (EDT) Message-ID: <3ADDC6BD.4A21D8F8@marconi.com> Date: Wed, 18 Apr 2001 12:54:21 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Questions about merge-capability in LDP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit A rereading of the LDP RFC brings to mind some questions about how different modes of operation (on-demand vs. unsolicited) work in conjunction with merge-capable and non-merge-capable routers. I've run through several scenarios. If any of my assumptions are wrong, please let me know. I think I've got everything right for the downstream-on-demand scenarios. I don't know if I've got things right for the downstream-unsolicited scenarios. All of these scenarios involve 5 routers in a straight-line topology. All routers are IP-lookup and push capable, and are therefore capable of acting as ingress rotuers. There is a single FEC, for which which R5 is egres.. -=-=-=-=- Scenario 1: [R1]---{R2]---[R3]---[R4]---[R5] All routers are merge-capable. They are configured for downstream-on- demand label distribution. R1 sends a Label-request to R2, and it propagates to R5. R5 sends a Label-mapping to R4, and it propagates back to R1. The resulting LSP looks like this: ->-\ ->-\ ->-\ ---------->------>------>------> [R1]---{R2]---[R3]---[R4]---[R5] R1 pushes the label for incoming packets. R2-R4 configure themselves both to push the label for unlabeled packets, and to swap the label for labeled packets. R5 pops the label for labeled packets and simply forwards unlabeled traffic -=-=-=-=- Scenario 2: [R1]---{R2]---[R3]---[R4]---[R5] No routers are merge-capable. Downstream-on-demand distribution. R1 sends a Label-request to R2. R2 sends two Label-requests to R3 (one for labeled traffic and one for unlabeled traffic). R3 sends three Label-requests to R4 (two for the two possible incoming labels and one for unlabeled traffic.) R4 sends four Label-requests to R5 (three for the three possible incoming labels and one for unlabeled traffic.) Label-mappings propagate back to satisfy all requests. The resulting LSPs look like: ----------> -----------------> ------------------------> -------------------------------> [R1]---{R2]---[R3]---[R4]---[R5] -=-=-=-=- Scenario 3: [R1]---{R2]---[R3]---[R4]---[R5] (M) (M) R2 and R4 are merge capable. R1, R3 and R5 are not. Downstream-on-demand distribution. R1 sends a Label-request to R2. Since R2 can merge this request with unlabeled traffic, it only sends one Label-request to R3. R3 can not merge this request with unlabeled traffic, so it sends two Label-requests to R4. R4 can merge both of these requests with each other and with unlabeled traffic, so it sends one Label-Request to R5. Label-mappings propagate back to satisfy all requests. The resulting LSP looks like: ->-\ ->--------\ ---------->------------->------> ->-/ [R1]---{R2]---[R3]---[R4]---[R5] -=-=-=-=- Scenario 4: [R1]---{R2]---[R3]---[R4]---[R5] All routers are merge-capable. They are configured for downstream- unsolicited label distribution. R5 sends a Label-mapping to R4, and it propagates to R1. The resulting LSP looks just like it would with on-demand distribution: ->-\ ->-\ ->-\ ---------->------>------>------> [R1]---{R2]---[R3]---[R4]---[R5] -=-=-=-=- Scenario 5: [R1]---{R2]---[R3]---[R4]---[R5] No routers are merge-capable. Downstream-unsolicited label distribution. - R5 sends a Label-mapping to R4. - R4 realizes that it needs two labels - one to send upstream and one to install for unlabeled traffic. It uses one label and sends a Label-request message to R5 in order to get a second. - R5 sends a second Label-mapping to R5 - R4 sends a Label-mapping message to R3. - R3 realizes that it needs two labels - one to send upstream and one to install for unlabeled traffic. It uses one label and sends a Label-request message to R4 in order to get a second. - R4 sends a Label-request downstream to R5, since it now needs a third label (in order to satisfy the new request). - R5 sends a third Label-mapping to R4 - R4 sends a second Label-mapping to R3 - R3 sends a Label-mapping to R2 - R2 realizes that it needs two labels - one to send upstream and one to install for unlabeled traffic. It uses one label and sends a Label-request message to R3 in order to get a second. - R3 sends a Label-request downstream to R4, since it now needs a third label (in order to satisfy the new request). - R4 sends a Label-request downstream to R5, since it now needs a fourth label (in order to satisfy the new request) - R5 sends a fourth Label-mapping to R4 - R4 sends a third Label-mapping to R3 - R3 sends a second Label-mapping to R2 - R2 sends a Label-mapping to R1 The resulting LSPs look just like they would with on-demand distribution: ----------> -----------------> ------------------------> -------------------------------> [R1]---{R2]---[R3]---[R4]---[R5] -=-=-=-=- Scenario 6: [R1]---{R2]---[R3]---[R4]---[R5] (M) (M) R2 and R4 are merge capable. R1, R3 and R5 are not. Downstream-unsolicited. - R5 sends a Label-mapping to R4 - R4 sends a Label-mapping to R3 - R3 realizes that it needs two labels - one to send upstream and one to install for unlabeled traffic. It uses one label and sends a Label-request message to R4 in order to get a second. - R4, being merge-capable, does not propagate the Label-request, but sends a Label-mapping to R3 - R3 sends a Label-mappng to R2 - R2 sends a Label-mapping to R1 The resulting LSp looks just like it does with on-demand distribution. ->-\ ->--------\ ---------->------------->------> ->-/ [R1]---{R2]---[R3]---[R4]---[R5] -=-=-=-=- Does all of this look right? It seems good to me. But I'm not certain about scenarios 5 and 6. The LDP RFC doesn't explicitly document the behavior of non-merge-capable routers receiving unsolicited label mappings. Comments? -- David From owner-mpls@UU.NET Wed Apr 18 14:28:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15259 for ; Wed, 18 Apr 2001 14:28:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklhx20385; Wed, 18 Apr 2001 18:26:05 GMT Received: by mail-control.mail.uu.net id QQklhx13711 for mpls-outgoing; Wed, 18 Apr 2001 18:25:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklhx13689 for ; Wed, 18 Apr 2001 18:25:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklhx18550 for ; Wed, 18 Apr 2001 18:22:14 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQklhx21508 for ; Wed, 18 Apr 2001 18:21:56 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA46342; Wed, 18 Apr 2001 14:20:26 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104181820.OAA46342@workhorse.fictitious.org> To: Juha Heinanen cc: curtis@avici.com, "Rajiv Papneja" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Does MPLS Require L3 Routing Table ? In-reply-to: Your message of "Tue, 17 Apr 2001 19:51:33 +0300." <15068.29845.396198.263942@lohi.eng.telia.fi> Date: Wed, 18 Apr 2001 14:20:25 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <15068.29845.396198.263942@lohi.eng.telia.fi>, Juha Heinanen writes: > Curtis Villamizar writes: > > > Looks worse than NHRP. > > i'm not sure if you understod the inarp draft. inarp is used over frame > relay all over the world and the draft describes similar function for > mpls. it's not very useful to send a message with the above contents > without elaborating what is wrong with it. > > -- juha Juha, The ATM LIS idea (rfc1577), NHRP, MPOA, are all poor choices for scalability and reliability. So is the FR LIS. The reason an ATM LIS or FR LIS is unreliable is that in practice one or more VC in the net doesn't come up for some reason. When this occurs, a persistent black hole results. Persistent black holes are best avoided. Curtis From owner-mpls@UU.NET Wed Apr 18 14:36:11 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15357 for ; Wed, 18 Apr 2001 14:36:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklhy20088; Wed, 18 Apr 2001 18:33:34 GMT Received: by mail-control.mail.uu.net id QQklhy14462 for mpls-outgoing; Wed, 18 Apr 2001 18:33:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklhy14454 for ; Wed, 18 Apr 2001 18:32:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklhy08053 for ; Wed, 18 Apr 2001 18:32:28 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQklhy18738 for ; Wed, 18 Apr 2001 18:32:28 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 8EF3294009; Wed, 18 Apr 2001 14:32:24 -0400 (EDT) Message-ID: <3ADDDDB8.A5B93DFC@sandburst.com> Date: Wed, 18 Apr 2001 14:32:24 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: Questions about merge-capability in LDP References: <3ADDC6BD.4A21D8F8@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Near as I can tell, these are all right. However, LDP does explicitly describe the handling of 'unsolicited label mappings' in procedures for receiving label mappings in Appendix A. Look into the behaviors with respect to getting a label mapping for which there is no outstanding request - that's pretty much what it's all about. There are a great many more scenarios to worry about, as well. You might want to enjoy a thought experiment in which some of these routers are using downstream on demand and other are using downstream unsolicited. Of course, that implies that one or more of the LSRs is able to deal with one mode at one interface and another at another. One of the good news items about this is that the scenario mostly applies to ATM where LSRs are effectively only required to support DoD mode. So, if the LSRs are ATM LSRs and none of them support dual control mode operation and at least one of them only supports the DoD mode, then label distribution will be all DoD. -- Eric Gray You wrote: > A rereading of the LDP RFC brings to mind some questions about how > different modes of operation (on-demand vs. unsolicited) work in > conjunction with merge-capable and non-merge-capable routers. > > I've run through several scenarios. If any of my assumptions are wrong, > please let me know. I think I've got everything right for the > downstream-on-demand scenarios. I don't know if I've got things right > for the downstream-unsolicited scenarios. > > All of these scenarios involve 5 routers in a straight-line topology. > All routers are IP-lookup and push capable, and are therefore capable of > acting as ingress rotuers. There is a single FEC, for which which R5 is > egres.. > > -=-=-=-=- > > Scenario 1: > > [R1]---{R2]---[R3]---[R4]---[R5] > > All routers are merge-capable. They are configured for downstream-on- > demand label distribution. R1 sends a Label-request to R2, and it > propagates to R5. R5 sends a Label-mapping to R4, and it propagates > back to R1. The resulting LSP looks like this: > > ->-\ ->-\ ->-\ > ---------->------>------>------> > [R1]---{R2]---[R3]---[R4]---[R5] > > R1 pushes the label for incoming packets. R2-R4 configure themselves > both to push the label for unlabeled packets, and to swap the label for > labeled packets. R5 pops the label for labeled packets and simply > forwards unlabeled traffic > > -=-=-=-=- > > Scenario 2: > > [R1]---{R2]---[R3]---[R4]---[R5] > > No routers are merge-capable. Downstream-on-demand distribution. > > R1 sends a Label-request to R2. R2 sends two Label-requests to R3 (one > for labeled traffic and one for unlabeled traffic). R3 sends three > Label-requests to R4 (two for the two possible incoming labels and one > for unlabeled traffic.) R4 sends four Label-requests to R5 (three for > the three possible incoming labels and one for unlabeled traffic.) > > Label-mappings propagate back to satisfy all requests. The resulting > LSPs look like: > > ----------> > -----------------> > ------------------------> > -------------------------------> > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 3: > > [R1]---{R2]---[R3]---[R4]---[R5] > (M) (M) > > R2 and R4 are merge capable. R1, R3 and R5 are not. > Downstream-on-demand distribution. > > R1 sends a Label-request to R2. Since R2 can merge this request with > unlabeled traffic, it only sends one Label-request to R3. R3 can not > merge this request with unlabeled traffic, so it sends two > Label-requests to R4. R4 can merge both of these requests with each > other and with unlabeled traffic, so it sends one Label-Request to R5. > > Label-mappings propagate back to satisfy all requests. The resulting > LSP looks like: > > ->-\ ->--------\ > ---------->------------->------> > ->-/ > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 4: > > [R1]---{R2]---[R3]---[R4]---[R5] > > All routers are merge-capable. They are configured for downstream- > unsolicited label distribution. R5 sends a Label-mapping to R4, and it > propagates to R1. The resulting LSP looks just like it would with > on-demand distribution: > > ->-\ ->-\ ->-\ > ---------->------>------>------> > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 5: > > [R1]---{R2]---[R3]---[R4]---[R5] > > No routers are merge-capable. Downstream-unsolicited label distribution. > > - R5 sends a Label-mapping to R4. > - R4 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R5 in order to get a second. > - R5 sends a second Label-mapping to R5 > - R4 sends a Label-mapping message to R3. > - R3 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R4 in order to get a second. > - R4 sends a Label-request downstream to R5, since it now needs a > third label (in order to satisfy the new request). > - R5 sends a third Label-mapping to R4 > - R4 sends a second Label-mapping to R3 > - R3 sends a Label-mapping to R2 > - R2 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R3 in order to get a second. > - R3 sends a Label-request downstream to R4, since it now needs a > third label (in order to satisfy the new request). > - R4 sends a Label-request downstream to R5, since it now needs a > fourth label (in order to satisfy the new request) > - R5 sends a fourth Label-mapping to R4 > - R4 sends a third Label-mapping to R3 > - R3 sends a second Label-mapping to R2 > - R2 sends a Label-mapping to R1 > > The resulting LSPs look just like they would with on-demand > distribution: > > ----------> > -----------------> > ------------------------> > -------------------------------> > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 6: > > [R1]---{R2]---[R3]---[R4]---[R5] > (M) (M) > > R2 and R4 are merge capable. R1, R3 and R5 are not. > Downstream-unsolicited. > > - R5 sends a Label-mapping to R4 > - R4 sends a Label-mapping to R3 > - R3 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R4 in order to get a second. > - R4, being merge-capable, does not propagate the Label-request, but > sends a Label-mapping to R3 > - R3 sends a Label-mappng to R2 > - R2 sends a Label-mapping to R1 > > The resulting LSp looks just like it does with on-demand distribution. > > ->-\ ->--------\ > ---------->------------->------> > ->-/ > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Does all of this look right? It seems good to me. But I'm not certain > about scenarios 5 and 6. The LDP RFC doesn't explicitly document the > behavior of non-merge-capable routers receiving unsolicited label > mappings. > > Comments? > > -- David From owner-mpls@UU.NET Wed Apr 18 14:52:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15825 for ; Wed, 18 Apr 2001 14:52:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklhz17822; Wed, 18 Apr 2001 18:50:22 GMT Received: by mail-control.mail.uu.net id QQklhz16411 for mpls-outgoing; Wed, 18 Apr 2001 18:49:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklhz16342 for ; Wed, 18 Apr 2001 18:49:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklhz00951 for ; Wed, 18 Apr 2001 18:49:35 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQklhz07369 for ; Wed, 18 Apr 2001 18:49:35 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 LAA05796 for ; Wed, 18 Apr 2001 11:49:34 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA02457 for mpls@uu.net; Wed, 18 Apr 2001 14:49:33 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklhy15507 for ; Wed, 18 Apr 2001 18:43:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklhy23927 for ; Wed, 18 Apr 2001 18:42:13 GMT Received: from mail2.orchestream.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [195.153.64.126]) id QQklhy11929 for ; Wed, 18 Apr 2001 18:42:13 GMT Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 18 Apr 2001 19:43:16 +0100 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id OAA20398; Wed, 18 Apr 2001 14:42:32 +0100 Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 19:38:30 +0100 Message-ID: From: "Donkin, Richard" To: "'Geoff Bennett'" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Wed, 18 Apr 2001 19:38:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Geoff Bennett [mailto:geoff.bennett@marconi.com] > Sent: 18 April 2001 11:15 > To: MP LS; mpls-ops@mplsrc.com; mpls@uu.net > Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? > > > Hi Niels, > > There may be some confusion arising depending on how you > configure the ATM > switch. In effect there are three modes of operation for > this device... > > 3. Ships in the Night (SIN). In this case, both ATM and MPLS Control > Planes operate simultaneously. ATM signalling happens on VCI > 5, and MPLS > signalling on VCI 32. VCs that are set up as a result of > signalling are > "owned" by one or other of these control planes. SIN would allow an > operator to continue to run high revenue voice services (and > maybe existing > Frame Relay or native ATM services...they make money too) > over the ATM > "character" of the switch. They can then run the loss-making Internet ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > services over the MPLS character. ^^^^^^^^^^ Very amusing... I'm sure this was just flame-bait, but first of all, MPLS supports IP services, not just Internet traffic, and you can of course run highly profitable IP VPN services over MPLS. Ultimately, ATM/FR services (as seen by the customer) may well be carried over an MPLS core, particularly as MPLS becomes one of the key signalling mechanisms for all-optical core networks, but since much of the traffic running over ATM/FR is actually IP, it may be simpler to deliver IP VPNs directly to the customer premises. > Cheers, > Geoff Richard Donkin T: +44 (0)20 7348 1507 Orchestream Avon House, Kensington Village, Avonmore Road, London W14 8TS T: +44 (0)20 7348 1500 F: +44 (0)20 7348 1501 www.orchestream.com -- This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited. If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents. Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated. From owner-mpls@UU.NET Wed Apr 18 14:56:40 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15926 for ; Wed, 18 Apr 2001 14:56:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklhz20803; Wed, 18 Apr 2001 18:54:12 GMT Received: by mail-control.mail.uu.net id QQklhz16901 for mpls-outgoing; Wed, 18 Apr 2001 18:53:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklhz16875 for ; Wed, 18 Apr 2001 18:53:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklhz12372 for ; Wed, 18 Apr 2001 18:53:17 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklhz22977 for ; Wed, 18 Apr 2001 18:53:16 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25620; Wed, 18 Apr 2001 14:53:10 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28304; Wed, 18 Apr 2001 14:53:12 -0400 (EDT) Message-ID: <3ADDE29E.627746B1@marconi.com> Date: Wed, 18 Apr 2001 14:53:18 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Eric Gray CC: mpls@UU.NET Subject: Re: Questions about merge-capability in LDP References: <3ADDC6BD.4A21D8F8@marconi.com> <3ADDDDB8.A5B93DFC@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > > Near as I can tell, these are all right. However, LDP does > explicitly describe the handling of 'unsolicited label mappings' in > procedures for receiving label mappings in Appendix A. Look into > the behaviors with respect to getting a label mapping for which > there is no outstanding request - that's pretty much what it's all > about. Yes, but the pseudocode there doesn't talk about non-merge-capable routers requesting additional labels. The only mention of merge- capable vs. non-merge-capable in Appendix A is in the context of whether or not to include a Path Vector TLV. -- David From owner-mpls@UU.NET Wed Apr 18 15:01:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16064 for ; Wed, 18 Apr 2001 15:01:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklhz02112; Wed, 18 Apr 2001 18:59:02 GMT Received: by mail-control.mail.uu.net id QQklhz17450 for mpls-outgoing; Wed, 18 Apr 2001 18:58:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklhz17439 for ; Wed, 18 Apr 2001 18:58:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklhz19429 for ; Wed, 18 Apr 2001 18:57:36 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQklhz15805 for ; Wed, 18 Apr 2001 18:57:35 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 LAA11748; Wed, 18 Apr 2001 11:57:38 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA02487; Wed, 18 Apr 2001 14:57:33 -0400 (EDT) Message-Id: <200104181857.OAA02487@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Juha Heinanen cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-reply-to: Your message of Sun, 15 Apr 2001 10:00:44 +0300. <15065.18204.355287.636244@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: Wed, 18 Apr 2001 14:57:33 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Juha> or you can have labels to be setup automatically between all your edge Juha> routers after which the routers can use inarp to figure out who is Juha> behind each label. in that mode there is no need for any l3 Juha> information in the core lsrs. How would you get the LSPs to be setup "automatically between all your edge routers" without having any L3 routing information in the core? From owner-mpls@UU.NET Wed Apr 18 15:09:24 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16282 for ; Wed, 18 Apr 2001 15:09:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklia25762; Wed, 18 Apr 2001 19:06:54 GMT Received: by mail-control.mail.uu.net id QQklia27635 for mpls-outgoing; Wed, 18 Apr 2001 19:06:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklia27611 for ; Wed, 18 Apr 2001 19:06:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklia19054 for ; Wed, 18 Apr 2001 19:05:05 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklia11782 for ; Wed, 18 Apr 2001 19:05:04 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27027 for ; Wed, 18 Apr 2001 15:05:02 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA02144 for ; Wed, 18 Apr 2001 15:05:04 -0400 (EDT) Message-ID: <3ADDE566.320F563E@marconi.com> Date: Wed, 18 Apr 2001 15:05:10 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? References: <200104181857.OAA02487@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 Rosen wrote: > Juha Heinanen wrote: >> >> or you can have labels to be setup automatically between all your >> edge routers after which the routers can use inarp to figure out >> who is behind each label. in that mode there is no need for any >> l3 information in the core lsrs. > > How would you get the LSPs to be setup "automatically between all > your edge routers" without having any L3 routing information in the > core? I think Juha meant that the core doesn't need _global_ L3 routing information (as it needs in a core using hop-by-hop routing). It would still need enough of an IGP to know how to get traffic to its own routers. If Juha actually meant no L3 information whatsoever, then I'll also be interested to hear how this could possibly work. -- David From owner-mpls@UU.NET Wed Apr 18 16:46:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17668 for ; Wed, 18 Apr 2001 16:46:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklig18191; Wed, 18 Apr 2001 20:44:14 GMT Received: by mail-control.mail.uu.net id QQklig02916 for mpls-outgoing; Wed, 18 Apr 2001 20:43:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklig02881 for ; Wed, 18 Apr 2001 20:43:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklig24840 for ; Wed, 18 Apr 2001 20:42:02 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQklig06543 for ; Wed, 18 Apr 2001 20:42:02 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 28ABB94009; Wed, 18 Apr 2001 16:42:02 -0400 (EDT) Message-ID: <3ADDFC1A.6D40B6E4@sandburst.com> Date: Wed, 18 Apr 2001 16:42:02 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Vijayanand C Cc: loa.andersson@nortelnetworks.com, mpls@UU.NET Subject: Re: Label distribution mode References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijay, This should not be a problem for a number of reasons. In the worst case (an implementer has interpreted the meaning of the per-platform label space to mean that all labels are treated the same regardless of whether or not they apply to the same pair of peers) the labels that have been given to the previous peer would (in at least some cases) have to be given to the new peer as well. The only difference that would come out of the label distribution mode (DU verses DoD) would be whether or not the LSR has to wait to be asked to distribute those labels. In some implementations, the prior use of labels is a complete non- issue because the scope of per-platform labels can be restricted to a pair of peers. See http://www.mindspring.com/~ewgray/faq.htm#PPLAT for a discussion of general issues relating to the per-platform label space. Is it possible that you have reversed the sense of how labels are distributed with repect to a label space? Advertising the per-platform label space restricts the labels you can distribute, not the labels you can receive in a distribution. The fact that an LSR may have gotten labels from another peer with whom it had advertised the per-platform label space, does not prevent it from getting and using the same labels from an entirely different peer. -- Eric Gray You wrote: > Hello, > I have a question in LDP. > > Suppose, we have a per-platform label space entity bound to PPP and Ethernet > interfaces. Assume that the entity has been configured for Downstream on > demand and a session is already established with a peer. Now, while > establishing a new session with another peer, if that peer says Unsiolicited > mode in the Init message then the RFC says that we have to use Unsolicited > only. However the entity has been configured for ON-DEMAND and a session > with another entity is already running for that entity. How do we handle > this situation? Should we have another enity for this session and have a > one-to-one relationship between entity and session. Or can we treat this as > mis-configuration and reject the session establishment attempt. > > Regards, > Vijay From owner-mpls@UU.NET Wed Apr 18 17:04:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17937 for ; Wed, 18 Apr 2001 17:04:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklii00835; Wed, 18 Apr 2001 21:01:48 GMT Received: by mail-control.mail.uu.net id QQklii09246 for mpls-outgoing; Wed, 18 Apr 2001 21:01:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklii08547 for ; Wed, 18 Apr 2001 21:00:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklih24021 for ; Wed, 18 Apr 2001 20:56:29 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQklih23061 for ; Wed, 18 Apr 2001 20:56:29 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 1B7D99400A; Wed, 18 Apr 2001 16:56:29 -0400 (EDT) Message-ID: <3ADDFF7D.549D8DE6@sandburst.com> Date: Wed, 18 Apr 2001 16:56:29 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: Questions about merge-capability in LDP References: <3ADDC6BD.4A21D8F8@marconi.com> <3ADDDDB8.A5B93DFC@sandburst.com> <3ADDE29E.627746B1@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, That's because - when the issue with handling merge capable and non-merge capable label distributions came up during the last call, the authors decided that the functionality required to handle this was not specific to non-merging LSRs. It is applicable to any LSP for which the upstream LSR chooses not to merge - whether or not it is merge capable. Therefore, if you were expecting there to be a call-out - of the sort "if the LSR is non-merge capable", then you will continue to be disappointed. :-) If you look at the procedures for handling label mappings, you will see that the notion of handling a requested label is dealt with irrespective of the label distribution mode (DU/DoD). You will also see that there is nothing in the procedures for handling a label request that prevents an LSR from responding to one even if the mode of operation is supposed to be DU. If I can request a label - and get a distinct one - whenever I want one (unless and until the peer runs out), then I can handle both the case where the peer is merge capable and the case when the peer is simply merge-averse. -- Eric Gray You wrote: > Eric Gray wrote: > > > > Near as I can tell, these are all right. However, LDP does > > explicitly describe the handling of 'unsolicited label mappings' in > > procedures for receiving label mappings in Appendix A. Look into > > the behaviors with respect to getting a label mapping for which > > there is no outstanding request - that's pretty much what it's all > > about. > > Yes, but the pseudocode there doesn't talk about non-merge-capable > routers requesting additional labels. The only mention of merge- > capable vs. non-merge-capable in Appendix A is in the context of whether > or not to include a Path Vector TLV. > > -- David From owner-mpls@UU.NET Wed Apr 18 17:14:50 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18015 for ; Wed, 18 Apr 2001 17:14:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklii29262; Wed, 18 Apr 2001 21:12:17 GMT Received: by mail-control.mail.uu.net id QQklii23457 for mpls-outgoing; Wed, 18 Apr 2001 21:11:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklii23410 for ; Wed, 18 Apr 2001 21:11:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklii26231 for ; Wed, 18 Apr 2001 21:08:19 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQklii09046 for ; Wed, 18 Apr 2001 21:08:19 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id C4FCE9400B; Wed, 18 Apr 2001 17:08:18 -0400 (EDT) Message-ID: <3ADE0242.43C41ADF@sandburst.com> Date: Wed, 18 Apr 2001 17:08:18 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap , mpls@UU.NET Subject: Re: Questions about merge-capability in LDP References: <3ADDC6BD.4A21D8F8@marconi.com> <3ADDDDB8.A5B93DFC@sandburst.com> <3ADDE29E.627746B1@marconi.com> <3ADDFF7D.549D8DE6@sandburst.com> Content-Type: multipart/alternative; boundary="------------B2C7232D48C43F245B16D584" Sender: owner-mpls@UU.NET Precedence: bulk --------------B2C7232D48C43F245B16D584 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David, The last sentence was supposed to read: " ... I can handle both the case where the peer is not merge capable and the case when the peer is simply merge-averse. -- Eric Gray Earlier I wrote: > David, > > That's because - when the issue with handling merge capable > and non-merge capable label distributions came up during the last > call, the authors decided that the functionality required to handle > this was not specific to non-merging LSRs. It is applicable to any > LSP for which the upstream LSR chooses not to merge - whether > or not it is merge capable. > > Therefore, if you were expecting there to be a call-out - of the > sort "if the LSR is non-merge capable", then you will continue to > be disappointed. :-) > > If you look at the procedures for handling label mappings, you > will see that the notion of handling a requested label is dealt with > irrespective of the label distribution mode (DU/DoD). You will > also see that there is nothing in the procedures for handling a > label request that prevents an LSR from responding to one even > if the mode of operation is supposed to be DU. > > If I can request a label - and get a distinct one - whenever I > want one (unless and until the peer runs out), then I can handle > both the case where the peer is merge capable and the case > when the peer is simply merge-averse. > > -- > Eric Gray > > You wrote: > > > Eric Gray wrote: > > > > > > Near as I can tell, these are all right. However, LDP does > > > explicitly describe the handling of 'unsolicited label mappings' in > > > procedures for receiving label mappings in Appendix A. Look into > > > the behaviors with respect to getting a label mapping for which > > > there is no outstanding request - that's pretty much what it's all > > > about. > > > > Yes, but the pseudocode there doesn't talk about non-merge-capable > > routers requesting additional labels. The only mention of merge- > > capable vs. non-merge-capable in Appendix A is in the context of whether > > or not to include a Path Vector TLV. > > > > -- David --------------B2C7232D48C43F245B16D584 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit David,

    The last sentence was supposed to read:

" ... I can handle both the case where the peer is not merge
capable and the case when the peer is simply merge-averse.

--
Eric Gray

Earlier I wrote:

David,

    That's because - when the issue with handling merge capable
and non-merge capable label distributions came up during the last
call, the authors decided that the functionality required to handle
this was not specific to non-merging LSRs.  It is applicable to any
LSP for which the upstream LSR chooses not to merge - whether
or not it is merge capable.

    Therefore, if you were expecting there to be a call-out - of the
sort "if the LSR is non-merge capable", then you will continue to
be disappointed.  :-)

    If you look at the procedures for handling label mappings, you
will see that the notion of handling a requested label is dealt with
irrespective of the label distribution mode (DU/DoD).  You will
also see that there is nothing in the procedures for handling a
label request that prevents an LSR from responding to one even
if the mode of operation is supposed to be DU.

    If I can request a label - and get a distinct one - whenever I
want one (unless and until the peer runs out), then I can handle
both the case where the peer is merge capable and the case
when the peer is simply merge-averse.

--
Eric Gray

You wrote:

> Eric Gray wrote:
> >
> >     Near as I can tell, these are all right.  However, LDP does
> > explicitly describe the handling of 'unsolicited label mappings' in
> > procedures for receiving label mappings in Appendix A.  Look into
> > the behaviors with respect to getting a label mapping for which
> > there is no outstanding request - that's pretty much what it's all
> > about.
>
> Yes, but the pseudocode there doesn't talk about non-merge-capable
> routers requesting additional labels.  The only mention of merge-
> capable vs. non-merge-capable in Appendix A is in the context of whether
> or not to include a Path Vector TLV.
>
> -- David

--------------B2C7232D48C43F245B16D584-- From owner-mpls@UU.NET Wed Apr 18 20:33:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19939 for ; Wed, 18 Apr 2001 20:33:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkliw24045; Thu, 19 Apr 2001 00:30:43 GMT Received: by mail-control.mail.uu.net id QQkliw02639 for mpls-outgoing; Thu, 19 Apr 2001 00:30:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkliw02634 for ; Thu, 19 Apr 2001 00:30:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkliv11868 for ; Thu, 19 Apr 2001 00:28:39 GMT Received: from sktelecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQkliv20511 for ; Thu, 19 Apr 2001 00:28:38 GMT Received: from mrchang (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f3J0WAb21203 for ; Thu, 19 Apr 2001 09:32:11 +0900 (KST) Message-ID: <005e01c0c867$658b7980$77131796@sktelecom.com> From: "Rae M. Chang" To: Subject: Questions on the DataConnection paper Date: Thu, 19 Apr 2001 09:26:36 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C0C8B2.D4E53960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C0C8B2.D4E53960 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 IA0KSGVsbG8sDQoNCkkndmUgcmVhZCB0aGUgRGF0YSBDb25uZWN0aW9uJ3Mgd2hpdGUgcGFwZXIs IA0KdGl0bGVkICJNUExTIFRFOiBBIENob2ljZSBvZiBTaWduYWxpbmcgUHJvdG9jb2xzIiBhbmQg DQpoYXZlIHNvbWUgd29uZGVycyB3aGF0IHRoZXkgcmVhbGx5IG1lYW50IGluIHRoZSBjb250ZXh0 Lg0KDQoxKSBJbiBzZWN0aW9uIDUuMiBTZWN1cml0eToNCml0IGlzIHdyaXR0ZW4sICJSU1ZQIHRh cmdldHMgaXRzIFBBVEggbWVzc2FnZXMgYXQgdGhlIGVncmVzcyBMU1Igc28gdGhhdCB0aGUgDQpp bnRlcm1lZGlhdGUgTFNScyBjYW5ub3QgYWNjZXNzIHRoZSBQQVRIIG1lc3NhZ2VzLiAoaW4gY2Fz ZSBvZiBJUFNFQyBhcHBsaWVkKSIgDQoNCkJ1dCwgaXNuJ3QgaXQgdHJ1ZSB0aGF0IHRoZSBJUCBw YWNrZXRzIGluY2x1ZGluZyB0aGUgUEFUSCBtZXNzYWdlIGhhdmUgdG8gYmUgYWRkcmVzc2VkDQp0 byBwZWVyIExTUiBub2RlIGFjcm9zcyB0aGUgdG8tYmUgTFNQIHJvdXRlPyANCkkgY2FuJ3QgdW5k ZXJzdGFuZCB3aHkgdGhlIFBBVEggbWVzc2FnZSBoYXMgdG8gYmUgdGFyZ2V0ZWQgYXQgdGhlIGVn cmVzcyBMU1INCndoZW4geW91IGVuY2Fwc3VsYXRlIHRoZSBQQVRIIG1lc3NhZ2Ugd2l0aCBJUFNF Qy4NCg0KDQoyKSBJbiBzZWN0aW9uIDUuMTMgTGF5ZXIgMyBQcm90b2NvbDoNCml0IGlzIHdyaXR0 ZW4sICJSU1ZQIGlkZW50aWZpZXMgYSBzaW5nbGUgcGF5bG9hZCBwcm90b2NvbCBkdXJpbmcgTFNQ IHNldHVwLCBidXQgdGhlcmUgaXMgDQpubyBzY29wZSB3aXRoaW4gdGhlIHByb3RvY29sIGZvciBD Ui1MRFAgdG8gZG8gdGhpcy4iDQoNCkknbSBzdGlsbCB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0 IHRoZXkgcmVhbGx5IG1lYW50LiAgRG8gdGhleSBtZWFuIHRoYXQ6DQp3aXRoIFJTVlAsIHlvdSBj YW4gb25seSBzZXR1cCBhbiBMU1AgZm9yIHRoZSB1c2FnZSBvZiBhIHNpbmdsZSBsYXllciAzIHBy b3RvY29sLCBhbmQNCndpdGggQ1ItTERQLCB5b3UgY2FuIHVzZSBvbmUgTFNQIHJvdXRlIGZvciB0 cmFuc21pdHRpbmcgYW55IG51bWJlciBvZiBsYXllciAzIHByb3RvY29scz8NCg0KTW9yZSBjbGVh ciBleHBsYW5hdGlvbiBjYW4gaGVscCBtZSB1bmRlcnN0YW5kIHRoZSBwYXBlci4gDQoNClJhZQ0K ------=_NextPart_000_005B_01C0C8B2.D4E53960 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOw0K PERJVj48Rk9OVCBzaXplPTI+SGVsbG8sPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSd2ZSByZWFkIHRoZSBEYXRh IENvbm5lY3Rpb24ncyB3aGl0ZSBwYXBlciwgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+dGl0bGVkICJNUExTIFRFOiBBIENob2ljZSBvZiBTaWduYWxpbmcgUHJvdG9jb2xzIiBhbmQg DQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5oYXZlIHNvbWUgd29uZGVycyB3aGF0 Jm5ic3A7dGhleSByZWFsbHkgbWVhbnQgaW4gdGhlIA0KY29udGV4dC48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4x KSBJbiBzZWN0aW9uIDUuMiBTZWN1cml0eTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5pdCBpcyB3cml0dGVuLCAiUlNWUCB0YXJnZXRzIGl0cyBQQVRIIG1lc3NhZ2VzIGF0IHRoZSBl Z3Jlc3MgDQpMU1Igc28gdGhhdCB0aGUgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ aW50ZXJtZWRpYXRlIExTUnMgY2Fubm90IGFjY2VzcyB0aGUgUEFUSCBtZXNzYWdlcy4gKGluIGNh c2Ugb2YgDQpJUFNFQyBhcHBsaWVkKSIgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QnV0LCBpc24ndCBpdCB0cnVl IHRoYXQgdGhlIElQIHBhY2tldHMgaW5jbHVkaW5nIHRoZSBQQVRIIA0KbWVzc2FnZSZuYnNwO2hh dmUgdG8gYmUgYWRkcmVzc2VkPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+dG8gcGVl ciBMU1Igbm9kZSBhY3Jvc3MgdGhlIHRvLWJlIExTUCANCnJvdXRlPyZuYnNwOzwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgY2FuJ3QgdW5kZXJzdGFuZCB3aHkgdGhlIFBBVEggbWVz c2FnZSA8L0ZPTlQ+PEZPTlQgDQpzaXplPTI+aGFzIHRvIGJlIHRhcmdldGVkIGF0IHRoZSBlZ3Jl c3MgTFNSPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+d2hlbiB5b3UgZW5jYXBzdWxh dGUgdGhlIFBBVEggbWVzc2FnZSB3aXRoIElQU0VDLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjIpIEluIHNlY3Rpb24gNS4xMyBMYXllciZuYnNw OzMgUHJvdG9jb2w6PC9GT05UPjwvRElWPg0KPERJVj5pdCBpcyB3cml0dGVuPEZPTlQgc2l6ZT0y PiwgIlJTVlAgaWRlbnRpZmllcyBhIHNpbmdsZSBwYXlsb2FkIHByb3RvY29sIA0KZHVyaW5nIExT UCBzZXR1cCwgYnV0IHRoZXJlIGlzIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPm5v IHNjb3BlIHdpdGhpbiB0aGUgcHJvdG9jb2wgZm9yIENSLUxEUCB0byBkbyANCnRoaXMuIjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkknbSBzdGlsbCB0cnlpbmcmbmJzcDt0byB1bmRlcnN0YW5kIHdoYXQmbmJzcDt0 aGV5IHJlYWxseSANCm1lYW50LiZuYnNwOyBEbyZuYnNwO3RoZXkgbWVhbiB0aGF0OjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPndpdGggUlNWUCwgeW91IGNhbiBvbmx5IHNldHVwIGFu IExTUCBmb3ImbmJzcDt0aGUgdXNhZ2Ugb2YgYSANCnNpbmdsZSBsYXllciAzIHByb3RvY29sLCBh bmQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj53aXRoIENSLUxEUCwgeW91IGNhbiB1 c2Ugb25lIExTUCByb3V0ZSBmb3IgdHJhbnNtaXR0aW5nIGFueSANCm51bWJlciBvZiBsYXllciAz IHByb3RvY29scz88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Nb3JlIGNsZWFyIGV4cGxhbmF0aW9uIGNhbiBoZWxw IG1lIHVuZGVyc3RhbmQmbmJzcDt0aGUgcGFwZXIuIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+UmFlPC9GT05U PjwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_005B_01C0C8B2.D4E53960-- From owner-mpls@UU.NET Wed Apr 18 20:41:50 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20003 for ; Wed, 18 Apr 2001 20:41:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkliw01569; Thu, 19 Apr 2001 00:39:32 GMT Received: by mail-control.mail.uu.net id QQkliw03235 for mpls-outgoing; Thu, 19 Apr 2001 00:38:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkliw03218 for ; Thu, 19 Apr 2001 00:38:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkliw15558 for ; Thu, 19 Apr 2001 00:37:03 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkliw00742 for ; Thu, 19 Apr 2001 00:37:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA20887 for mpls@uu.net; Wed, 18 Apr 2001 20:37:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkliw03101 for ; Thu, 19 Apr 2001 00:36:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkliw24898; Thu, 19 Apr 2001 00:34:46 GMT Received: from radiant.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radiant.calient.net [63.102.55.206]) id QQkliw00256; Thu, 19 Apr 2001 00:34:46 GMT Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 17:31:05 -0700 Message-ID: From: Praveen Vengalam To: "'mpls-request@uu.net'" Cc: "'mpls@uu.net'" Subject: subscribe Date: Wed, 18 Apr 2001 17:30:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Regards, Praveen Vengalam, Technical Marketing Manager, Calient Networks. Phone: 408 972 3833 Fax : 408 972 3800 From owner-mpls@UU.NET Wed Apr 18 21:09:37 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20119 for ; Wed, 18 Apr 2001 21:09:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkliy21878; Thu, 19 Apr 2001 01:07:16 GMT Received: by mail-control.mail.uu.net id QQkliy22789 for mpls-outgoing; Thu, 19 Apr 2001 01:06:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkliy22781 for ; Thu, 19 Apr 2001 01:06:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkliy28283 for ; Thu, 19 Apr 2001 01:04:53 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkliy19694 for ; Thu, 19 Apr 2001 01:04:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA23283 for mpls@uu.net; Wed, 18 Apr 2001 21:04:53 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkliy08107 for ; Thu, 19 Apr 2001 01:00:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkliy04740 for ; Thu, 19 Apr 2001 01:00:30 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f181.law10.hotmail.com [64.4.15.181]) id QQkliy15754 for ; Thu, 19 Apr 2001 01:00:30 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 18 Apr 2001 18:00:29 -0700 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Thu, 19 Apr 2001 01:00:28 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: lberger@movaz.com, ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: new rev of GMPLS signaling I-Ds Date: Wed, 18 Apr 2001 18:00:28 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2001 01:00:29.0692 (UTC) FILETIME=[20B1CBC0:01C0C86C] Sender: owner-mpls@UU.NET Precedence: bulk Hi Lou, I have gone through the draft-ietf-mpls-generalized-signaling-03.txt and draft-ietf-mpls-generalized-cr-ldp-02.txt drafts. I have certain clarifications on these drafts. Following are my doubts : 1. In draft "draft-ietf-mpls-generalized-signaling-03.txt", u mentioned that there will be a separate draft GMPLS-SONET for describing the technology specific details. U have removed just the TDM related details in that draft. The WDM specific label formats are still in the draft. Should not the waveband and lamda specific details and their label formats need to be in seprate draft like GMPLS-WDM. I mean to say why not put waveband label format in some other draft like GMPLS-WDM. 2. It is mentioned in the draft that label set may be either restricted to a single hop or the whole LSP path. Can u please clarify that this decision should be based on what criteria or it is just a local node decision. 3. It is mentioned that LSP characteristics may be used by transit nodes e.g. to support PHP (section 3.1). Can u please explain how ? Is this case only possible in PSC ? 4. In section 3.1.1, it is written that lambda encoding type refers to switching of wavelengths. Does it also include the waveband ? Why there is not a separate LSP encoding type as waveband ? How does a transit node can identify that a waveband label is requested instead of a lambda label ? 5. Are people more stressing on SDH/SONET in GMPLS area ? 6. In section 3.3.1, it is mentioned that waveband Id is selected by the sender and reused in all subsequent related messages. Can u please clarify that what are all those subsequent messages ? 7. In section 3.5, four different cases are explained where the label set concept may be useful. Can u please calrify the 4th case further ? 8. Is waveband Id locally signifcant i.e. between the two adjacent nodes or is it globally unique for whole LSP path ? 9. Can the generalized label TLV be present in Label Release/Withdraw messages ? 10. Is there any new draft coming on O-UNI ? 11. Is anybody defining the clear interworking on O-UNI and GMPLS ? 12. In section 5, it is mentioned that acceptable label set may be present in notification message to indicate what all labels are acceptable ? Can u please clarify what actions a node have to take once it receives the notification message with acceptable label set ? Please help me in understanding these drafts. Thanks, manoj. >From: Lou Berger >To: ccamp@ops.ietf.org,mpls@UU.NET >Subject: new rev of GMPLS signaling I-Ds >Date: Tue, 17 Apr 2001 17:12:17 -0400 > >All, > It looks like the I-D folks are out (and not publishing) for a few >days. For those interested updated versions of the generalized signaling >docs, they are available at: > >http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-03.txt >http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-02.txt >http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-02.txt > >Per the last IETF, these drafts don't include SONET/SDH specifics. A new >draft covering the specifics will be published in a few days. > >Lou (and co-authors) > >>Subject: Autoreply from Internet Draft Submission Manager >>From: ietfauto@ietf.org (Internet Draft Submission Manager) >> >>Hello, >> >>This message is being sent to acknowledge receipt of your submission >>or message to internet-drafts@ietf.org >> >>The I-D administrator will be out of the office until Monday, >>April 23rd. All submissions will be processed. >> >>Thank you. We appreciate your understanding and patience. > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Apr 18 22:36:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22509 for ; Wed, 18 Apr 2001 22:36:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklje27225; Thu, 19 Apr 2001 02:33:19 GMT Received: by mail-control.mail.uu.net id QQklje17773 for mpls-outgoing; Thu, 19 Apr 2001 02:32:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklje17758 for ; Thu, 19 Apr 2001 02:32:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklje28723 for ; Thu, 19 Apr 2001 02:31:45 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklje01386 for ; Thu, 19 Apr 2001 02:31:44 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA27483 for mpls@uu.net; Wed, 18 Apr 2001 22:31:44 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkljd17090 for ; Thu, 19 Apr 2001 02:27:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkljd14780 for ; Thu, 19 Apr 2001 02:27:05 GMT Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQkljd18264 for ; Thu, 19 Apr 2001 02:27:04 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3J2RIq28539; Thu, 19 Apr 2001 05:27:18 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15070.19718.716706.626667@lohi.eng.telia.fi> Date: Thu, 19 Apr 2001 05:27:18 +0300 (EEST) To: curtis@avici.com Cc: "Rajiv Papneja" , mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <200104181820.OAA46342@workhorse.fictitious.org> References: <15068.29845.396198.263942@lohi.eng.telia.fi> <200104181820.OAA46342@workhorse.fictitious.org> 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 ATM LIS idea (rfc1577), NHRP, MPOA, are all poor choices for > scalability and reliability. So is the FR LIS. The reason an ATM LIS > or FR LIS is unreliable is that in practice one or more VC in the net > doesn't come up for some reason. When this occurs, a persistent black > hole results. Persistent black holes are best avoided. curtis, fr pvcs have been used since 1991 to connect routers together. there are thousands of vpns build that way. this is the first time i hear about your black hole problem and i have been runnign these kind of vpns for ten years now. if a pvc doesn't come up, then there is a single point of failure link down somewhere and the situation is no different from a leased line between routers being down. -- juha From owner-mpls@UU.NET Wed Apr 18 22:41:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22542 for ; Wed, 18 Apr 2001 22:41:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklje16968; Thu, 19 Apr 2001 02:39:33 GMT Received: by mail-control.mail.uu.net id QQklje18192 for mpls-outgoing; Thu, 19 Apr 2001 02:39:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklje18179 for ; Thu, 19 Apr 2001 02:38:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklje16439 for ; Thu, 19 Apr 2001 02:38:04 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklje15497 for ; Thu, 19 Apr 2001 02:38:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA27977 for mpls@uu.net; Wed, 18 Apr 2001 22:38:04 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklje18134 for ; Thu, 19 Apr 2001 02:37:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklje00476 for ; Thu, 19 Apr 2001 02:37:26 GMT Received: from lohi.eng.telia.fi by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQklje14767 for ; Thu, 19 Apr 2001 02:37:26 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3J2bdj28550; Thu, 19 Apr 2001 05:37:39 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15070.20339.465963.876429@lohi.eng.telia.fi> Date: Thu, 19 Apr 2001 05:37:39 +0300 (EEST) To: David Charlap Cc: mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <3ADDE566.320F563E@marconi.com> References: <200104181857.OAA02487@erosen-sun.cisco.com> <3ADDE566.320F563E@marconi.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David Charlap writes: > If Juha actually meant no L3 information whatsoever, then I'll also be > interested to hear how this could possibly work. i tried to answer this in the previous message, but i would like to add that i don't advocate such a mode of operation and that that actually has nothing to do with inarp over unidicational vcs. the latter is used when the provider has one way or another created plsps connecting ce lsrs together. this reminds me of another thing. some time ago i proposed a way to signal soft lsps. i didn't follow up on it, because i thought that the generalized mpls thing would cover also that issue. apparently it didn't. my question is, if it didn't is there now a way to do it or should i come back with an enhanced proposal? -- juha From owner-mpls@UU.NET Wed Apr 18 22:44:43 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22560 for ; Wed, 18 Apr 2001 22:44:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklje09967; Thu, 19 Apr 2001 02:42:27 GMT Received: by mail-control.mail.uu.net id QQklje18465 for mpls-outgoing; Thu, 19 Apr 2001 02:41:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklje18438 for ; Thu, 19 Apr 2001 02:41:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklje18538 for ; Thu, 19 Apr 2001 02:38:49 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklje10537 for ; Thu, 19 Apr 2001 02:38:48 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA28042 for mpls@uu.net; Wed, 18 Apr 2001 22:38:48 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklje17835 for ; Thu, 19 Apr 2001 02:34:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklje13609 for ; Thu, 19 Apr 2001 02:31:18 GMT Received: from lohi.eng.telia.fi by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQklje09027 for ; Thu, 19 Apr 2001 02:31:17 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3J2VQb28542; Thu, 19 Apr 2001 05:31:26 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15070.19966.401856.384943@lohi.eng.telia.fi> Date: Thu, 19 Apr 2001 05:31:26 +0300 (EEST) To: erosen@cisco.com Cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <200104181857.OAA02487@erosen-sun.cisco.com> References: <15065.18204.355287.636244@lohi.eng.telia.fi> <200104181857.OAA02487@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 > How would you get the LSPs to be setup "automatically between all your edge > routers" without having any L3 routing information in the core? i'm not an ldp expert, but i assume that using the du mode, each egress router can advertise an lsp to itself to all its neighbors and so on. thus eventually every router in the system would have a path to every egress router. this assumes that each router adds itself to the advertisement in order to cut the loops. -- juha From owner-mpls@UU.NET Thu Apr 19 01:10:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24359 for ; Thu, 19 Apr 2001 01:10:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkljo13756; Thu, 19 Apr 2001 05:08:03 GMT Received: by mail-control.mail.uu.net id QQkljo22548 for mpls-outgoing; Thu, 19 Apr 2001 05:07:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkljo22517 for ; Thu, 19 Apr 2001 05:07:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkljo16815 for ; Thu, 19 Apr 2001 05:06:04 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkljo10970 for ; Thu, 19 Apr 2001 05:05:44 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3J56lp29298; Thu, 19 Apr 2001 10:36:48 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A33.001AAC69 ; Thu, 19 Apr 2001 10:21:20 +0530 X-Lotus-FromDomain: HSS To: Eric Gray cc: mpls@UU.NET Message-ID: <65256A33.001AA3B7.00@sandesh.hss.hns.com> Date: Thu, 19 Apr 2001 10:20:57 +0530 Subject: Re: A question. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi eric! Thanx a lot for the clarification. You made perfect sense here but I still have a few points that are embedded below as *****sumit**** regards sumit Eric Gray on 04/18/2001 08:13:45 PM To: Sumit Chauhan/HSS@HSS cc: Subject: Re: A question. Sumit, There are plenty of examples of ways in which you can establish LSPs (and therefore FECs) based on packets you receive. As you point out, the mechanisms exist to support creation of an LSP on pretty much any basis you care to imagine. But there are implications of doing what you suggest. A very similar suggestion was made about a year ago and it got mostly the silent treatment. Bad history and other things worked against it then and will undoubtedly work against it again. The fundamtental issue is that - at least for normal IP packets - you either use topology driven or flow driven path setup. There is no reason to have both. Look at it this way: if you are using topology based LSP setup and don't have a FEC for a packet, then you don't have a route for it either. Who are you going to ask for a label from? Are you going to ask for a label for a host address or 32 bit address prefix, or are you going to try to guess what an appropriate prefix length would be? If you did have a route, then you are waiting for a label from the next hop (either because you asked for it already, or because the next hop is supposed to send one without you asking) or you already know you are not going to get one - therefore, why would you ask for one just because you have a packet? What happens when you get another packet - do you send yet another request? ******sumit******** few points here are 1. this means that the actual setup of the LSP shall happen once the network(its routers ) come up and exchange the initial routes (using some IGP) and then reach their stable state. Till the point they have first echanged the routes and exchanged lables(set up the LSPs) there can be no MPLS based forwarding possible. That is perfectly all right. 2. From this it seems that "unsolicited downstream" seems to be the most logical solution as it is simpler for each LSR to generate lables to its directly-connected routes as I do not see any real value add in a upstream LSR asking for a label in this scenario. 3. The other point is that it is a pretty simple solution once we are considering the topology based forwarding but in case we have to do flow based forwarding and along with that we want to have resource reservation. In that scenario I always beleived it should be something like "label on demand only and when needed only" because else we may land up reserving resources we may no use later. But I am sure I might be missing something here. Please clarify. 4. The other problem that strikes me here is that almost all routers also maintain "default routes". As you suggested that "whom do we ask for a lable if we dont have an FEC?" so is there a concept of "default FEC as well". Maybe one with prefix "0"? ******************** Suppose you do know both the next hop and (AIBM) the correct prefix length (AIBM) and you send a request for a label. You've simply passed the problem on to the next hop. So, you might ask, what if I have a route entry and I know the next hop and the right FEC to ask for? Why can't I wait until I actually have a packet to request a label? The answer is real simple: there's absolutely no reason to do so and every reason not to do so. The topology based setup defined in MPLS is every bit as scalable as the routing it is based on - so you don't gain any advantage from not having to setup an LSP that you'll never use. Nor is it very likely, in most real network deployments, that there will be instances of such LSPs in the first place. Delaying LSP setup until a packet is received is one great way to place a strain on routing implementations and drop a lot of packets. However many packets may be dropped (for a particular stream) while I wait for the topology based setup to complete (for that stream) will be increased by the amount of time it takes me to get the first packet for that stream. And topology based setup can be even faster if using independent control. With topology based LSP setup, most streams will not see a single packet drop as a result of not having an LSP setup already. With flow based LSP setup, at least one stream for each FEC will see at least one packet drop. ******sumit***** Point well taken here. But again I think things should seem diffrently if we look at an FEC that has not just destiation address and prefix but things for QoS and CoS incl. resourse reservation. **************** -- Eric You wrote: > hi eric! > another solution here might be that, if we recieve a packet (at LER > ingress) for which there is no existing binding available to a FEC. It should be > considered as a control packet and a request (downstream on demand) should be > generated to the next hop(determined using L3 information) to give a binding and > the received packet(s) should be forwarded as normal IP forwarding till the > point the complete LSP is set up. am I missing something? > > regards > sumit > > Eric Gray on 04/16/2001 05:42:18 PM > > To: "Bakshi, Sanjay" > cc: mpls@UU.NET (bcc: Sumit Chauhan/HSS) > > Subject: Re: A question. > > Sanjay, > > Your assumption is slightly faulty. :-) > > The term LER (label edge router) is somewhat misleading, > because it seems to define a box (router) as opposed to a > function (label edge routing) which a box may or may not > support. People tend to think of an LER as a box that supports > the edge routing functions of MPLS ingress and egress. That > does not mean that it absolutely must find an LSP for every > packet it receives - or that it absolutely must pop the last > label off of every packet that it sends. It's behavior WRT any > packet it receives or sends depends largely on the capabilities > of the interfaces on which it was received or will be sent and > the apriori existence of an FTN (or ILM) entry. > > There is no 'data-driven label binding operation' as you imply > in your question. If an LER does not have a 'FEC entry' in its > FTN (FEC to NHLFE) table, it either forwards the packet using > IP routing (if it is able to do so) or it drops the packet (possibly > returning a 'destination unreachable' error to the sender - again > if it is able to do so). > > -- > Eric Gray > > You wrote: > > > Hello, > > I have a simple question for which I think I know the answer but cannot find > > the reference in the RFCs to de certain. What happens when a unlabeled > > packet is received by a LER and there is no FEC entry corresponding to the > > packet? > > I know this falls under the data-driven label binding operation, in which > > LDP is trigerred by the arriving packet. But I have not found a reference to > > it in any RFC to back my assumption up. > > Any pointers? > > thanks > > sanjay From owner-mpls@UU.NET Thu Apr 19 01:27:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26359 for ; Thu, 19 Apr 2001 01:27:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkljp24990; Thu, 19 Apr 2001 05:25:01 GMT Received: by mail-control.mail.uu.net id QQkljp24214 for mpls-outgoing; Thu, 19 Apr 2001 05:24:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkljp24206 for ; Thu, 19 Apr 2001 05:24:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkljp01285 for ; Thu, 19 Apr 2001 05:23:49 GMT Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQkljp24775 for ; Thu, 19 Apr 2001 05:23:44 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id LAA07069 for ; Thu, 19 Apr 2001 11:01:53 GMT Received: from soflt.alc.wipinfo.soft.net ([192.168.220.205]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GC0XX500.ABA for ; Thu, 19 Apr 2001 10:59:29 +0530 Date: Thu, 19 Apr 2001 10:59:28 +0530 (IST) From: "chetan kumar s" X-Sender: chetansk@soflt.alc.wipinfo.soft.net Reply-To: chetan.kumar@wipro.com To: mpls@UU.NET Subject: Label Aborting.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I was looking thro' the rfc 3036. At section 3.5.10 (page 73) it is mentioned If an LSR receives a Label Abort Request Message after it has responded to the Label Request in question with a Label Mapping message or a Notification message, it ignores the abort request. And in thge Appendix at Page 106 it is mentioned. LAbR.6 Generate Event: Received Label Release Message for FEC from MsgSource. (See Note 2.) Goto LAbR.11. I feel that we have to follow what is mentioned in the section 3.5.10, since it makes sense for the upstream(MsgSource) to release the Label explicitly based on its retention mode. Let me know how do U think ?? Thanks Chetan S ___________ The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw From owner-mpls@UU.NET Thu Apr 19 03:52:31 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08338 for ; Thu, 19 Apr 2001 03:52:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkljz17786; Thu, 19 Apr 2001 07:49:30 GMT Received: by mail-control.mail.uu.net id QQkljz11027 for mpls-outgoing; Thu, 19 Apr 2001 07:48:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkljz11019 for ; Thu, 19 Apr 2001 07:48:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkljz09148 for ; Thu, 19 Apr 2001 07:48:10 GMT Received: from cad.zju.edu.cn by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [210.32.131.2]) id QQkljz06578 for ; Thu, 19 Apr 2001 07:48:09 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 92; Wed, 18 Apr 2001 17:39:56 +0800 Message-ID: <3ADD60A9.879AC43D@cad.zju.edu.cn> Date: Wed, 18 Apr 2001 17:38:49 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Geoff Bennett CC: MP LS , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: <200104180906.KAA21530@salamander.eu.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > 1. Pure ATM. In this case the switch will operate UNI and NNI interfaces, > and will run PNNI as its routing protocol (PNNI is both an IGP and EGP). > UNI and PNNI signalling will happen on VCI 5. I don't think this will happen in real world , because MPLS integrate IP routing and switching mechanism. As it uses ATM switch as transit stage solution, it has to use SIN style equipments. While, it will go to pure MPLS in future. If PNNI is used as routing procedure, it should be the situation where ATM switch path is used as tunnel for MPLS. > > 2. Pure MPLS. In this mode, there is no ATM signalling, and no PNNI. > MPLS routing and signalling (OSPF, ISIS, CR-LDP, RSVP-TE, etc.) will pass > over VCI 32 (note, please check the latest draft for the actual VCI number, > it's a while since I read this info). > > 3. Ships in the Night (SIN). In this case, both ATM and MPLS Control > Planes operate simultaneously. ATM signalling happens on VCI 5, and MPLS > signalling on VCI 32. VCs that are set up as a result of signalling are > "owned" by one or other of these control planes. SIN would allow an > operator to continue to run high revenue voice services (and maybe existing > Frame Relay or native ATM services...they make money too) over the ATM > "character" of the switch. They can then run the loss-making Internet > services over the MPLS character. > > I think there are ideas floating around about a more integrated control > plane for ATM/MPLS switches based on PNNI, but I don't think these have > made it to draft as yet. > > Cheers, > Geoff > > At 10:02 18/04/01 +0200, MP LS wrote: > >Hello all, > > > >I have some questions becasue something is verry strange to me. > >I just assumed that ATM-LSRS used an IP routing protocol (IGP) just for > >finding the topology of the network. > > > >But last i read an doccument and there they described that When you change > >an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. Can > >anyone make this clear for me?? > > > >Thanks a lot. > > > >Greetings, > > > >Niels Sitters. > > > > > >_________________________________________________________________________ > >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > >------- > >The MPLS-OPS Mailing List > >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > > ================================================================ > Geoff Bennett Tel: (33) 497 21 43 62 > Director of Technology, OCTO Fax: (33) 497 21 43 50 > Marconi > Gaia - Bat. E email: geoff.bennett@marconi.com > BP 123 > 06903 SOPHIA ANTIPOLIS > FRANCE > ================================================================ From owner-mpls@UU.NET Thu Apr 19 04:07:17 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08486 for ; Thu, 19 Apr 2001 04:07:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklka20067; Thu, 19 Apr 2001 08:04:17 GMT Received: by mail-control.mail.uu.net id QQklka19757 for mpls-outgoing; Thu, 19 Apr 2001 08:03:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklka19211 for ; Thu, 19 Apr 2001 08:03:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklka13907 for ; Thu, 19 Apr 2001 08:03:13 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQklka09880 for ; Thu, 19 Apr 2001 08:03:05 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3J83Xb05161; Thu, 19 Apr 2001 13:33:33 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A33.002ADBC7 ; Thu, 19 Apr 2001 13:18:07 +0530 X-Lotus-FromDomain: HSS To: chetan.kumar@wipro.com cc: mpls@UU.NET Message-ID: <65256A33.002AD775.00@sandesh.hss.hns.com> Date: Thu, 19 Apr 2001 13:17:54 +0530 Subject: Re: Label Aborting.. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk absolutely corect i guess ;-) -sumit "chetan kumar s" on 04/19/2001 10:59:28 AM Please respond to chetan.kumar@wipro.com To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: Label Aborting.. Hi, I was looking thro' the rfc 3036. At section 3.5.10 (page 73) it is mentioned If an LSR receives a Label Abort Request Message after it has responded to the Label Request in question with a Label Mapping message or a Notification message, it ignores the abort request. And in thge Appendix at Page 106 it is mentioned. LAbR.6 Generate Event: Received Label Release Message for FEC from MsgSource. (See Note 2.) Goto LAbR.11. I feel that we have to follow what is mentioned in the section 3.5.10, since it makes sense for the upstream(MsgSource) to release the Label explicitly based on its retention mode. Let me know how do U think ?? Thanks Chetan S ___________ The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw From owner-mpls@UU.NET Thu Apr 19 04:17:47 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08584 for ; Thu, 19 Apr 2001 04:17:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklka18729; Thu, 19 Apr 2001 08:14:45 GMT Received: by mail-control.mail.uu.net id QQklka00524 for mpls-outgoing; Thu, 19 Apr 2001 08:14:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklka00509 for ; Thu, 19 Apr 2001 08:13:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklka09669 for ; Thu, 19 Apr 2001 08:12:07 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQklka20218 for ; Thu, 19 Apr 2001 08:11:58 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3J8Cl305564; Thu, 19 Apr 2001 13:42:47 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A33.002BB2E5 ; Thu, 19 Apr 2001 13:27:18 +0530 X-Lotus-FromDomain: HSS To: nagabhushana.ramaswamy@wipro.com cc: David Charlap , mpls@UU.NET Message-ID: <65256A33.002BB21B.00@sandesh.hss.hns.com> Date: Thu, 19 Apr 2001 13:27:14 +0530 Subject: Re: Questions about merge-capability in LDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi bhushana! a few points here from me! regards -sumit "Nagabhushana Ramaswamy Nadig" on 04/19/2001 05:27:06 PM Please respond to nagabhushana.ramaswamy@wipro.com To: David Charlap cc: mpls@UU.NET (bcc: Sumit Chauhan/HSS) Subject: Re: Questions about merge-capability in LDP Hello, I have a few observations from your mail. 1. Particularly the way you have mentioned of raising the internal label requests for the FECs. How far does it make sense to wait for a label request from a peer LSR and take the same as a trigger for learning a new FEC. What I think is, as each of these LSR's would be running a L3 routing protocol the moment I learn a new route at L3 should be the trigger for me to make a new request to the next hop peer (Ideally we will be populating our FTN table in this case and ILM in the former). Depending upon this I would say the sequence of message flow changes in your below discussions. 2. Scenario 5. I really doubt such a configuration will work for you. A non-merge capable LSR cofigured for Unsolicited distribution (there by to also to receive unsolicited messages). In this case if you receive an Unsolicited mapping msg, what will you do with that? To which upstream peer are you going to distribute this? I think because of this only the architecture has wisely avoided the DU mode for non-merge LSRs. ****sumit**** In this case would it not make sense to retain the label with you and you might be the start of that LSP then and above/before this upstream router, maybe we are getting either unlabeled packets or this can be an aggregating router for packets to same destination from multiple sources(interfaces or peers). I guess that is the idea behind merging. ************* regards Bhushana > A rereading of the LDP RFC brings to mind some questions abouthow > different modes of operation (on-demand vs. unsolicited) work in > conjunction with merge-capable and non-merge-capable routers. > > I've run through several scenarios. If any of my assumptions are wrong, > please let me know. I think I've got everything right for the > downstream-on-demand scenarios. I don't know if I've got things right > for the downstream-unsolicited scenarios. > > All of these scenarios involve 5 routers in a straight-line topology. > All routers are IP-lookup and push capable, and are therefore capable of > acting as ingress rotuers. There is a single FEC, for which which R5 is > egres.. > > -=-=-=-=- > > Scenario 1: > > [R1]---{R2]---[R3]---[R4]---[R5] > > All routers are merge-capable. They are configured for downstream-on- > demand label distribution. R1 sends a Label-request to R2, and it > propagates to R5. R5 sends a Label-mapping to R4, and it propagates > back to R1. The resulting LSP looks like this: > > ->-\ ->-\ ->-\ > ---------->------>------>------> > [R1]---{R2]---[R3]---[R4]---[R5] > > R1 pushes the label for incoming packets. R2-R4 configure themselves > both to push the label for unlabeled packets, and to swap the label for > labeled packets. R5 pops the label for labeled packets and simply > forwards unlabeled traffic > > -=-=-=-=- > > Scenario 2: > > [R1]---{R2]---[R3]---[R4]---[R5] > > No routers are merge-capable. Downstream-on-demand distribution. > > R1 sends a Label-request to R2. R2 sends two Label-requests to R3 (one > for labeled traffic and one for unlabeled traffic). R3 sends three > Label-requests to R4 (two for the two possible incoming labels and one > for unlabeled traffic.) R4 sends four Label-requests to R5 (three for > the three possible incoming labels and one for unlabeled traffic.) > > Label-mappings propagate back to satisfy all requests. The resulting > LSPs look like: > > ----------> > -----------------> > ------------------------> > -------------------------------> > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 3: > > [R1]---{R2]---[R3]---[R4]---[R5] > (M) (M) > > R2 and R4 are merge capable. R1, R3 and R5 are not. > Downstream-on-demand distribution. > > R1 sends a Label-request to R2. Since R2 can merge this request with > unlabeled traffic, it only sends one Label-request to R3. R3 can not > merge this request with unlabeled traffic, so it sends two > Label-requests to R4. R4 can merge both of these requests with each > other and with unlabeled traffic, so it sends one Label-Request to R5. > > Label-mappings propagate back to satisfy all requests. The resulting > LSP looks like: > > ->-\ ->--------\ > ---------->------------->------> > ->-/ > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 4: > > [R1]---{R2]---[R3]---[R4]---[R5] > > All routers are merge-capable. They are configured for downstream- > unsolicited label distribution. R5 sends a Label-mapping to R4, and it > propagates to R1. The resulting LSP looks just like it would with > on-demand distribution: > > ->-\ ->-\ ->-\ > ---------->------>------>------> > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 5: > > [R1]---{R2]---[R3]---[R4]---[R5] > > No routers are merge-capable. Downstream-unsolicited label distribution. > > - R5 sends a Label-mapping to R4. > - R4 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R5 in order to get a second. > - R5 sends a second Label-mapping to R5 > - R4 sends a Label-mapping message to R3. > - R3 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R4 in order to get a second. > - R4 sends a Label-request downstream to R5, since it now needs a > third label (in order to satisfy the new request). > - R5 sends a third Label-mapping to R4 > - R4 sends a second Label-mapping to R3 > - R3 sends a Label-mapping to R2 > - R2 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R3 in order to get a second. > - R3 sends a Label-request downstream to R4, since it now needs a > third label (in order to satisfy the new request). > - R4 sends a Label-request downstream to R5, since it now needs a > fourth label (in order to satisfy the new request) > - R5 sends a fourth Label-mapping to R4 > - R4 sends a third Label-mapping to R3 > - R3 sends a second Label-mapping to R2 > - R2 sends a Label-mapping to R1 > > The resulting LSPs look just like they would with on-demand > distribution: > > ----------> > -----------------> > ------------------------> > -------------------------------> > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 6: > > [R1]---{R2]---[R3]---[R4]---[R5] > (M) (M) > > R2 and R4 are merge capable. R1, R3 and R5 are not. > Downstream-unsolicited. > > - R5 sends a Label-mapping to R4 > - R4 sends a Label-mapping to R3 > - R3 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R4 in order to get a second. > - R4, being merge-capable, does not propagate the Label-request, but > sends a Label-mapping to R3 > - R3 sends a Label-mappng to R2 > - R2 sends a Label-mapping to R1 > > The resulting LSp looks just like it does with on-demand distribution. > > ->-\ ->--------\ > ---------->------------->------> > ->-/ > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Does all of this look right? It seems good to me. But I'm not certain > about scenarios 5 and 6. The LDP RFC doesn't explicitly document the > behavior of non-merge-capable routers receiving unsolicited label > mappings. > > Comments? > > -- David > From owner-mpls@UU.NET Thu Apr 19 05:00:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09016 for ; Thu, 19 Apr 2001 05:00:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkd11413; Thu, 19 Apr 2001 08:58:17 GMT Received: by mail-control.mail.uu.net id QQklkd04069 for mpls-outgoing; Thu, 19 Apr 2001 08:57:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklkd04061 for ; Thu, 19 Apr 2001 08:57:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklkd02178 for ; Thu, 19 Apr 2001 08:56:20 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQklkd04492 for ; Thu, 19 Apr 2001 08:56:20 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id <2XLWMA26>; Thu, 19 Apr 2001 10:55:33 +0200 Message-ID: From: Javier Antich To: mpls@UU.NET Subject: RV: Does MPLS Require L3 Routing Table ? Date: Thu, 19 Apr 2001 10:55:31 +0200 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 FAA09016 Well, I have been following the thread and I have not seen one basic thing. Of course you need IP routing table if you run MPLS in and IP network, but, you do not need to have the full Internet routing table in all the routers. You can remove BGP from the core so that BGP decisions and Next-hop BGP resolutions are done at the edge and the appropriate label is selected for reaching the right exit point from the cloud. Then, you need IP routing table, but if it is a core router and it is an Internet environment, the routing table can be much smaller than it would be if you were not running MPLS. Sorry if someone received the mail several times, I am having some problems with my subscription. ^ ^ ==============ooo====(.)v(.)====ooo===== Javier Antich Romaguera Network Consultant --------------------------------------------------------------------------- TELINDUS Pza. Ciudad de Viena, 6-2º 28040 Madrid --------------------------------------------------------------------------- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 --------------------------------------------------------------------------- For more information about our products and services, please visit our website http://www.telindus.com --------------------------------------------------------------------------- Full connectivity & mobility ==================ooo0===0ooo======== > -----Mensaje original----- > De: Rajesh P Jain [SMTP:rpjain@sasken.com] > Enviado el: viernes 13 de abril de 2001 10:16 > Para: Bharti Batra; mpls@UU.NET > Asunto: Re: Does MPLS Require L3 Routing Table ? > > "Hello", > Thanks for the response. > > Well, if it requires L3 Routing table to > build up the Label information, then what is the advantage of MPLS??? > Well, Anyhow, it will require the building of L3 Routing Table (May be > through RIP/OSPF/BGP etc), then Lable info can be formed by using only L3. > So, Anyhow, MPLS is dependent on L3, please explain me what is the > advantage of using MPLS (in terms of efficiency and speed switching of the > packets). > > With Regards > Rajesh P Jain > > ----- Original Message ----- > From: Bharti Batra > To: Rajesh P Jain ; mpls@UU.NET > > Sent: Friday, April 13, 2001 1:09 PM > Subject: Re: Does MPLS Require L3 Routing Table ? > > Hi ! > > Yes. LDP needs IP routing table to find out the route > towards the egress router to setup the LSP. LDP sends the LSP setup > request message along this path. > > Regds, > Bharti > > ----- Original Message ----- > From: Rajesh P Jain > To: mpls@UU.NET > Sent: Friday, April 13, 2001 12:52 PM > Subject: Does MPLS Require L3 Routing Table ? > > "Hello", List, > Well, I am very new to the MPLS > domain. I just wanted to check out whether MPLS domain neccesarily require > the L3 Routing Table (Maybe IP Routing Table) to build up it's label > (using the LDP Protocol). Or the LDP will take care of building the label > information automatically without the L3 Routing information? > > TIA > Rajesh P Jain > From owner-mpls@UU.NET Thu Apr 19 05:02:30 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09042 for ; Thu, 19 Apr 2001 05:02:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkd15311; Thu, 19 Apr 2001 08:59:51 GMT Received: by mail-control.mail.uu.net id QQklkd04115 for mpls-outgoing; Thu, 19 Apr 2001 08:59:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklkd04097 for ; Thu, 19 Apr 2001 08:59:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklkd27962 for ; Thu, 19 Apr 2001 08:57:40 GMT Received: from sanmiguel.telindus.es by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQklkd12556 for ; Thu, 19 Apr 2001 08:57:40 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id <2XLWMA29>; Thu, 19 Apr 2001 10:56:53 +0200 Message-ID: From: Javier Antich To: mpls@UU.NET Subject: RV: Does MPLS Require L3 Routing Table ? Date: Thu, 19 Apr 2001 10:56:47 +0200 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 FAA09042 > > How would you get the LSPs to be setup "automatically between all your edge > > routers" without having any L3 routing information in the core? >i'm not an ldp expert, but i assume that using the du mode, each egress >router can advertise an lsp to itself to all its neighbors and so on. >thus eventually every router in the system would have a path to every >egress router. this assumes that each router adds itself to the >advertisement in order to cut the loops. Yes, that is true, but how would the core router choose the right label towards the right next hop if it receives a label assignment from two or more neighbours for the same route? That might happen, and the core router must use its IGP routing table to select the right label and right nexthop/outgoing interface. ^ ^ ==============ooo====(.)v(.)====ooo===== Javier Antich Romaguera Network Consultant --------------------------------------------------------------------------- TELINDUS Pza. Ciudad de Viena, 6-2º 28040 Madrid --------------------------------------------------------------------------- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 --------------------------------------------------------------------------- For more information about our products and services, please visit our website http://www.telindus.com --------------------------------------------------------------------------- Full connectivity & mobility ==================ooo0===0ooo======== > -----Mensaje original----- > De: Juha Heinanen [SMTP:jh@lohi.eng.telia.fi] > Enviado el: jueves 19 de abril de 2001 4:31 > Para: erosen@cisco.com > CC: sgong@gmu.edu; mpls@UU.NET > Asunto: Re: Does MPLS Require L3 Routing Table ? > > > > How would you get the LSPs to be setup "automatically between all your > edge > > routers" without having any L3 routing information in the core? > > i'm not an ldp expert, but i assume that using the du mode, each egress > router can advertise an lsp to itself to all its neighbors and so on. > thus eventually every router in the system would have a path to every > egress router. this assumes that each router adds itself to the > advertisement in order to cut the loops. > > -- juha From owner-mpls@UU.NET Thu Apr 19 05:22:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09188 for ; Thu, 19 Apr 2001 05:22:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkf09703; Thu, 19 Apr 2001 09:20:05 GMT Received: by mail-control.mail.uu.net id QQklkf23287 for mpls-outgoing; Thu, 19 Apr 2001 09:19:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklkf23276 for ; Thu, 19 Apr 2001 09:19:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklkf10166 for ; Thu, 19 Apr 2001 09:18:54 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklkf08230 for ; Thu, 19 Apr 2001 09:18:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA19346 for mpls@uu.net; Thu, 19 Apr 2001 05:18:54 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklkf23247 for ; Thu, 19 Apr 2001 09:18:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklkf26663 for ; Thu, 19 Apr 2001 09:17:58 GMT Received: from dogwood.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dogwood.cisco.com [161.44.11.19]) id QQklkf23025 for ; Thu, 19 Apr 2001 09:17:57 GMT Received: from zhhong-W2K.cisco.com (beijing-dhcp-181-172.cisco.com [171.70.181.172]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA14255; Thu, 19 Apr 2001 05:17:54 -0400 (EDT) Message-Id: <5.0.2.1.0.20010419171234.00bd7078@dogwood.cisco.com> X-Sender: zhhong@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 19 Apr 2001 17:15:26 +0800 To: Javier Antich , mpls@UU.NET From: Zhi Hao Hong Subject: Re: RV: Does MPLS Require L3 Routing Table ? In-Reply-To: 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 FAA09188 I am just curious if any real SP network implemented MPLS network without BGP enabled in the core, even we all know this "BIG" benefits for mpls. I ever was involved in engineering several SP MPLS networks. Interesting, nobody talk about this, so I just keep this curiosity in my mind. Regards. At 10:55 2001-4-19 +0200, Javier Antich wrote: >Well, I have been following the thread and I have not seen one basic thing. >Of course you need IP routing table if you run MPLS in and IP network, but, >you do not need to have the full Internet routing table in all the routers. >You can remove BGP from the core so that BGP decisions and Next-hop BGP >resolutions are done at the edge and the appropriate label is selected for >reaching the right exit point from the cloud. Then, you need IP routing >table, but if it is a core router and it is an Internet environment, the >routing table can be much smaller than it would be if you were not running >MPLS. > >Sorry if someone received the mail several times, I am having some problems >with my subscription. > ^ ^ >==============ooo====(.)v(.)====ooo===== >Javier Antich Romaguera >Network Consultant >--------------------------------------------------------------------------- >TELINDUS >Pza. Ciudad de Viena, 6-2º >28040 Madrid >--------------------------------------------------------------------------- >javier.antich@telindus.es >tel: +34 91 456 00 08 >fax: +34 91 536 10 74 >--------------------------------------------------------------------------- >For more information about our products and services, >please visit our website http://www.telindus.com >--------------------------------------------------------------------------- >Full connectivity & mobility >==================ooo0===0ooo======== > > >> -----Mensaje original----- >> De: Rajesh P Jain [SMTP:rpjain@sasken.com] >> Enviado el: viernes 13 de abril de 2001 10:16 >> Para: Bharti Batra; mpls@UU.NET >> Asunto: Re: Does MPLS Require L3 Routing Table ? >> >> "Hello", >> Thanks for the response. >> >> Well, if it requires L3 Routing table to >> build up the Label information, then what is the advantage of MPLS??? >> Well, Anyhow, it will require the building of L3 Routing Table (May be >> through RIP/OSPF/BGP etc), then Lable info can be formed by using only L3. >> So, Anyhow, MPLS is dependent on L3, please explain me what is the >> advantage of using MPLS (in terms of efficiency and speed switching of the >> packets). >> >> With Regards >> Rajesh P Jain >> >> ----- Original Message ----- >> From: Bharti Batra >> To: Rajesh P Jain ; mpls@UU.NET >> >> Sent: Friday, April 13, 2001 1:09 PM >> Subject: Re: Does MPLS Require L3 Routing Table ? >> >> Hi ! >> >> Yes. LDP needs IP routing table to find out the route >> towards the egress router to setup the LSP. LDP sends the LSP setup >> request message along this path. >> >> Regds, >> Bharti >> >> ----- Original Message ----- >> From: Rajesh P Jain >> To: mpls@UU.NET >> Sent: Friday, April 13, 2001 12:52 PM >> Subject: Does MPLS Require L3 Routing Table ? >> >> "Hello", List, >> Well, I am very new to the MPLS >> domain. I just wanted to check out whether MPLS domain neccesarily require >> the L3 Routing Table (Maybe IP Routing Table) to build up it's label >> (using the LDP Protocol). Or the LDP will take care of building the label >> information automatically without the L3 Routing information? >> >> TIA >> Rajesh P Jain >> From owner-mpls@UU.NET Thu Apr 19 05:24:59 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09212 for ; Thu, 19 Apr 2001 05:24:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkf11559; Thu, 19 Apr 2001 09:22:38 GMT Received: by mail-control.mail.uu.net id QQklkf23522 for mpls-outgoing; Thu, 19 Apr 2001 09:22:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklkf23513 for ; Thu, 19 Apr 2001 09:21:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklkf03765 for ; Thu, 19 Apr 2001 09:21:12 GMT Received: from sanmiguel.telindus.es by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQklkf09839 for ; Thu, 19 Apr 2001 09:21:11 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id <2XLWMAKL>; Thu, 19 Apr 2001 11:20:24 +0200 Message-ID: From: Javier Antich To: Zhi Hao Hong , Javier Antich , mpls@UU.NET Subject: RE: RV: Does MPLS Require L3 Routing Table ? Date: Thu, 19 Apr 2001 11:20:19 +0200 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 FAA09212 I have seen it. This was a completely new network, but probably an operator which already has BGP implemented in the core will leave it running "just in case". ^ ^ ==============ooo====(.)v(.)====ooo===== Javier Antich Romaguera Network Consultant --------------------------------------------------------------------------- TELINDUS Pza. Ciudad de Viena, 6-2º 28040 Madrid --------------------------------------------------------------------------- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 --------------------------------------------------------------------------- For more information about our products and services, please visit our website http://www.telindus.com --------------------------------------------------------------------------- Full connectivity & mobility ==================ooo0===0ooo======== > -----Mensaje original----- > De: Zhi Hao Hong [SMTP:zhhong@cisco.com] > Enviado el: jueves 19 de abril de 2001 11:15 > Para: Javier Antich; mpls@UU.NET > Asunto: Re: RV: Does MPLS Require L3 Routing Table ? > > > I am just curious if any real SP network implemented MPLS network without > BGP enabled in the core, even we all know this "BIG" benefits for mpls. I > ever was involved in engineering several SP MPLS networks. Interesting, > nobody talk about this, so I just keep this curiosity in my mind. > > Regards. > > At 10:55 2001-4-19 +0200, Javier Antich wrote: > >Well, I have been following the thread and I have not seen one basic > thing. > >Of course you need IP routing table if you run MPLS in and IP network, > but, > >you do not need to have the full Internet routing table in all the > routers. > >You can remove BGP from the core so that BGP decisions and Next-hop BGP > >resolutions are done at the edge and the appropriate label is selected > for > >reaching the right exit point from the cloud. Then, you need IP routing > >table, but if it is a core router and it is an Internet environment, the > >routing table can be much smaller than it would be if you were not > running > >MPLS. > > > >Sorry if someone received the mail several times, I am having some > problems > >with my subscription. > > ^ ^ > >==============ooo====(.)v(.)====ooo===== > >Javier Antich Romaguera > >Network Consultant > >------------------------------------------------------------------------- > -- > >TELINDUS > >Pza. Ciudad de Viena, 6-2º > >28040 Madrid > >------------------------------------------------------------------------- > -- > >javier.antich@telindus.es > >tel: +34 91 456 00 08 > >fax: +34 91 536 10 74 > >------------------------------------------------------------------------- > -- > >For more information about our products and services, > >please visit our website http://www.telindus.com > >------------------------------------------------------------------------- > -- > >Full connectivity & mobility > >==================ooo0===0ooo======== > > > > > >> -----Mensaje original----- > >> De: Rajesh P Jain [SMTP:rpjain@sasken.com] > >> Enviado el: viernes 13 de abril de 2001 10:16 > >> Para: Bharti Batra; mpls@UU.NET > >> Asunto: Re: Does MPLS Require L3 Routing Table ? > >> > >> "Hello", > >> Thanks for the response. > >> > >> Well, if it requires L3 Routing table to > >> build up the Label information, then what is the advantage of MPLS??? > >> Well, Anyhow, it will require the building of L3 Routing Table (May be > >> through RIP/OSPF/BGP etc), then Lable info can be formed by using only > L3. > >> So, Anyhow, MPLS is dependent on L3, please explain me what is the > >> advantage of using MPLS (in terms of efficiency and speed switching of > the > >> packets). > >> > >> With Regards > >> Rajesh P Jain > >> > >> ----- Original Message ----- > >> From: Bharti Batra > >> To: Rajesh P Jain ; > mpls@UU.NET > >> > >> Sent: Friday, April 13, 2001 1:09 PM > >> Subject: Re: Does MPLS Require L3 Routing Table ? > >> > >> Hi ! > >> > >> Yes. LDP needs IP routing table to find out the route > >> towards the egress router to setup the LSP. LDP sends the LSP setup > >> request message along this path. > >> > >> Regds, > >> Bharti > >> > >> ----- Original Message ----- > >> From: Rajesh P Jain > >> To: mpls@UU.NET > >> Sent: Friday, April 13, 2001 12:52 PM > >> Subject: Does MPLS Require L3 Routing Table ? > >> > >> "Hello", List, > >> Well, I am very new to the > MPLS > >> domain. I just wanted to check out whether MPLS domain neccesarily > require > >> the L3 Routing Table (Maybe IP Routing Table) to build up it's label > >> (using the LDP Protocol). Or the LDP will take care of building the > label > >> information automatically without the L3 Routing information? > >> > >> TIA > >> Rajesh P Jain > >> From owner-mpls@UU.NET Thu Apr 19 06:10:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09585 for ; Thu, 19 Apr 2001 06:10:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklki06268; Thu, 19 Apr 2001 10:08:03 GMT Received: by mail-control.mail.uu.net id QQklki14186 for mpls-outgoing; Thu, 19 Apr 2001 10:07:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklki13962 for ; Thu, 19 Apr 2001 10:07:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklki03725 for ; Thu, 19 Apr 2001 10:06:41 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQklki04300 for ; Thu, 19 Apr 2001 10:06:32 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3JA7JG10428; Thu, 19 Apr 2001 15:37:24 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A33.00362F1C ; Thu, 19 Apr 2001 15:21:50 +0530 X-Lotus-FromDomain: HSS To: "Davide Careglio" cc: mpls@UU.NET Message-ID: <65256A33.00362C8D.00@sandesh.hss.hns.com> Date: Thu, 19 Apr 2001 15:21:42 +0530 Subject: Re: virus alert! Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=b2XfstveZ54S5QvFG91oF7PEk1aA9a5qUYt3pmReOeclCnrSgzS2eacb" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk --0__=b2XfstveZ54S5QvFG91oF7PEk1aA9a5qUYt3pmReOeclCnrSgzS2eacb Content-type: text/plain; charset=us-ascii Content-Disposition: inline hi! thanx a lot for the info. are u sure there is not a problem at your end as I have not seen any such problem here at my end. I have VirusScan 4.1.40 installed here. ciao sumit "Davide Careglio" on 04/19/2001 03:23:50 PM To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: virus alert! Dear All, I found a virus in a previous mail with subject: Re: Questions about merge-capability in LDP. I don't know who sent it. So, I notify all checking the mail before reading. Regards, Davide _______________________________________ Davide Careglio UPC Universitat Polit --0__=b2XfstveZ54S5QvFG91oF7PEk1aA9a5qUYt3pmReOeclCnrSgzS2eacb Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =E8cnica de Catalunya Departament d'Arquitectura de Computadores Jordi Girona, 1-3, D6 008 (Campus Nord) 08034 Barcelona (Spain) Phone: +34 93 4017182 Fax: +34 93 4017055 E-Mail: careglio@ac.upc.es ----- Original Message ----- From: To: Cc: "David Charlap" ; Sent: Thursday, April 19, 2001 9:57 AM Subject: Re: Questions about merge-capability in LDP > > > hi bhushana! > a few points here from me! > > regards > -sumit > > > > > "Nagabhushana Ramaswamy Nadig" on 04/19/2001 > 05:27:06 PM > > Please respond to nagabhushana.ramaswamy@wipro.com > > To: David Charlap > cc: mpls@UU.NET (bcc: Sumit Chauhan/HSS) > > Subject: Re: Questions about merge-capability in LDP > > > > > Hello, > I have a few observations from your mail. > 1. Particularly the way you have mentioned of raising the internal la= bel > requests for the FECs. How far does it make sense to wait for a label= > request from a peer LSR and take the same as a trigger for learning a= new > FEC. What I think is, as each of these LSR's would be running a L3 > routing protocol the moment I learn a new route at L3 should be the > trigger for me to make a new request to the next hop peer (Ideally we= will > be populating our FTN table in this case and ILM in the former). > Depending upon this I would say the sequence of message flow > changes in your below discussions. > > 2. Scenario 5. I really doubt such a configuration will work for you.= A > non-merge capable LSR cofigured for Unsolicited distribution (there b= y to > also to receive unsolicited messages). In this case if you receive an= > Unsolicited mapping msg, what will you do with that? To which upstrea= m > peer are you going to distribute this? I think because of this only t= he > architecture has wisely avoided the DU mode for non-merge LSRs. > ****sumit**** > In this case would it not make sense to retain the label with you and= you might > be the start of that LSP then and above/before this upstream router, = maybe we > are getting either unlabeled packets or this can be an aggregating ro= uter for > packets to same destination from multiple sources(interfaces or peers= ). I guess > that is the idea behind merging. > ************* > > regards > Bhushana > > > > A rereading of the LDP RFC brings to mind some questions abouthow > > different modes of operation (on-demand vs. unsolicited) work in > > conjunction with merge-capable and non-merge-capable routers. > > > > I've run through several scenarios. If any of my assumptions are w= rong, > > please let me know. I think I've got everything right for the > > downstream-on-demand scenarios. I don't know if I've got things ri= ght > > for the downstream-unsolicited scenarios. > > > > All of these scenarios involve 5 routers in a straight-line topolog= y. > > All routers are IP-lookup and push capable, and are therefore capab= le of > > acting as ingress rotuers. There is a single FEC, for which which = R5 is > > egres.. > > > > -=3D-=3D-=3D-=3D- > > > > Scenario 1: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > All routers are merge-capable. They are configured for downstream-= on- > > demand label distribution. R1 sends a Label-request to R2, and it > > propagates to R5. R5 sends a Label-mapping to R4, and it propagate= s > > back to R1. The resulting LSP looks like this: > > > > ->-\ ->-\ ->-\ > > ---------->------>------>------> > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > R1 pushes the label for incoming packets. R2-R4 configure themselv= es > > both to push the label for unlabeled packets, and to swap the label= for > > labeled packets. R5 pops the label for labeled packets and simply > > forwards unlabeled traffic > > > > -=3D-=3D-=3D-=3D- > > > > Scenario 2: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > No routers are merge-capable. Downstream-on-demand distribution. > > > > R1 sends a Label-request to R2. R2 sends two Label-requests to R3 = (one > > for labeled traffic and one for unlabeled traffic). R3 sends three= > > Label-requests to R4 (two for the two possible incoming labels and = one > > for unlabeled traffic.) R4 sends four Label-requests to R5 (three = for > > the three possible incoming labels and one for unlabeled traffic.) > > > > Label-mappings propagate back to satisfy all requests. The resulti= ng > > LSPs look like: > > > > ----------> > > -----------------> > > ------------------------> > > -------------------------------> > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > -=3D-=3D-=3D-=3D- > > > > Scenario 3: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > (M) (M) > > > > R2 and R4 are merge capable. R1, R3 and R5 are not. > > Downstream-on-demand distribution. > > > > R1 sends a Label-request to R2. Since R2 can merge this request wi= th > > unlabeled traffic, it only sends one Label-request to R3. R3 can n= ot > > merge this request with unlabeled traffic, so it sends two > > Label-requests to R4. R4 can merge both of these requests with eac= h > > other and with unlabeled traffic, so it sends one Label-Request to = R5. > > > > Label-mappings propagate back to satisfy all requests. The resulti= ng > > LSP looks like: > > > > ->-\ ->--------\ > > ---------->------------->------> > > ->-/ > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > -=3D-=3D-=3D-=3D- > > > > Scenario 4: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > All routers are merge-capable. They are configured for downstream-= > > unsolicited label distribution. R5 sends a Label-mapping to R4, an= d it > > propagates to R1. The resulting LSP looks just like it would with > > on-demand distribution: > > > > ->-\ ->-\ ->-\ > > ---------->------>------>------> > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > -=3D-=3D-=3D-=3D- > > > > Scenario 5: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > No routers are merge-capable. Downstream-unsolicited label distribu= tion. > > > > - R5 sends a Label-mapping to R4. > > - R4 realizes that it needs two labels - one to send upstream and o= ne > > to install for unlabeled traffic. It uses one label and sends a > > Label-request message to R5 in order to get a second. > > - R5 sends a second Label-mapping to R5 > > - R4 sends a Label-mapping message to R3. > > - R3 realizes that it needs two labels - one to send upstream and o= ne > > to install for unlabeled traffic. It uses one label and sends a > > Label-request message to R4 in order to get a second. > > - R4 sends a Label-request downstream to R5, since it now needs a > > third label (in order to satisfy the new request). > > - R5 sends a third Label-mapping to R4 > > - R4 sends a second Label-mapping to R3 > > - R3 sends a Label-mapping to R2 > > - R2 realizes that it needs two labels - one to send upstream and o= ne > > to install for unlabeled traffic. It uses one label and sends a > > Label-request message to R3 in order to get a second. > > - R3 sends a Label-request downstream to R4, since it now needs a > > third label (in order to satisfy the new request). > > - R4 sends a Label-request downstream to R5, since it now needs a > > fourth label (in order to satisfy the new request) > > - R5 sends a fourth Label-mapping to R4 > > - R4 sends a third Label-mapping to R3 > > - R3 sends a second Label-mapping to R2 > > - R2 sends a Label-mapping to R1 > > > > The resulting LSPs look just like they would with on-demand > > distribution: > > > > ----------> > > -----------------> > > ------------------------> > > -------------------------------> > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > -=3D-=3D-=3D-=3D- > > > > Scenario 6: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > (M) (M) > > > > R2 and R4 are merge capable. R1, R3 and R5 are not. > > Downstream-unsolicited. > > > > - R5 sends a Label-mapping to R4 > > - R4 sends a Label-mapping to R3 > > - R3 realizes that it needs two labels - one to send upstream and o= ne > > to install for unlabeled traffic. It uses one label and sends a > > Label-request message to R4 in order to get a second. > > - R4, being merge-capable, does not propagate the Label-request, bu= t > > sends a Label-mapping to R3 > > - R3 sends a Label-mappng to R2 > > - R2 sends a Label-mapping to R1 > > > > The resulting LSp looks just like it does with on-demand distributi= on. > > > > ->-\ ->--------\ > > ---------->------------->------> > > ->-/ > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > -=3D-=3D-=3D-=3D- > > > > Does all of this look right? It seems good to me. But I'm not cer= tain > > about scenarios 5 and 6. The LDP RFC doesn't explicitly document t= he > > behavior of non-merge-capable routers receiving unsolicited label > > mappings. > > > > Comments? > > > > -- David > > > > > > > > > = --0__=b2XfstveZ54S5QvFG91oF7PEk1aA9a5qUYt3pmReOeclCnrSgzS2eacb-- From owner-mpls@UU.NET Thu Apr 19 06:17:21 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09646 for ; Thu, 19 Apr 2001 06:17:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkj16065; Thu, 19 Apr 2001 10:16:00 GMT Received: by mail-control.mail.uu.net id QQklkj15947 for mpls-outgoing; Thu, 19 Apr 2001 10:15:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklkj15939 for ; Thu, 19 Apr 2001 10:15:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklki01994 for ; Thu, 19 Apr 2001 10:14:35 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklki12379 for ; Thu, 19 Apr 2001 10:14:33 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA23573 for mpls@uu.net; Thu, 19 Apr 2001 06:14:33 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklki15510 for ; Thu, 19 Apr 2001 10:13:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklki28897 for ; Thu, 19 Apr 2001 10:13:47 GMT Received: from coltrane.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQklki11784 for ; Thu, 19 Apr 2001 10:13:46 GMT Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Apr 2001 11:13:36 +0100 Message-ID: <37701240971DD31193970000F6CCB9F7027AFDAD@duke.datcon.co.uk> From: Ben Miller To: "'cmr@sktelecom.com'" Cc: mpls@UU.NET Subject: FW: Questions on your white paper Date: Thu, 19 Apr 2001 11:13:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C8B9.680050D0" 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_01C0C8B9.680050D0 Content-Type: text/plain; charset="ks_c_5601-1987" Rae I have interleaved some answers to your questions on our white paper below. Ben ----------------------------------------------- Ben Miller Business Unit Manager, Network Convergence Group Data Connection Ltd Tel: +44 (0) 20 8366 1177 Fax: +44 (0) 20 8363 1468 Email: bmm@dataconnection.com Web: http://www.dat aconnection.com -----Original Message----- From: Rae M. Chang [mailto:cmr@sktelecom.com] Sent: Wednesday, April 18, 2001 9:21 AM To: Ben Miller Subject: Questions on your white paper Hello, I've read your white paper, titled "MPLS TE: A Choice of Signaling Protocols" and have some wonders what you really mean. 1) In section 5.2 Security: you wrote, "RSVP targets its PATH messages at the egress LSR so that the intermediate LSRs cannot access the PATH messages. (in case of IPSEC applied)" But, isn't it true that the IP packets including the PATH message have to be addressed to peer LSR node across the to-be LSP route? I can't understand why the PATH message has to be targeted at the egress LSR when you encapsulate the PATH message with IPSEC. IPSEC relies on tokens known to the endpoints. Traditional RSVP (and therefore RSVP-TE for MPLS) requires that the destination for the PATH is the egress of the LSP. In order for intermediate nodes to spot the PATH message, the RouterAlert bit is set, informing intermediate nodes that they should check the contents of the packet. On seeing that it is an RSVP message, the intermediate node knows it should pass it to the RSVP/MPLS stack for processing. The intermediate nodes do not have the IPSEC tokens for the endpoints, and therefore they could not decode a PATH that the ingress had encrypted using the egress IPSEC token. Hence, IPSEC cannot be used for these packets. However, there is more to this story. Because some devices may not understand the RouterAlert bit, the RSVP spec effectively allows the PATH messages to be sent to the next hop. Although this is not 100% spec compliant, it is expected to work in most cases. (The intermediate nodes then learn the LSP destination from the Explicit Route Object.) If this processing were used, IPSEC could be used between each hop. Furthermore, the GMPLS extensions that require/allow out-of-band signalling introduce another option. When running GMPLS with out-of-band signalling, it is possible (and sometimes necessary) to address the RSVP packets to intermediate nodes. This would be the case if, for example, a network of optical cross-connects is exchanging signalling data by sending RSVP messages over the Internet. In this case, sending RSVP packets to the LSP destination and setting the RouterAlert bit would mean that every router in the Internet attempted to process the packet, whereas you only want the optical cross-connects on the path to do so. GMPLS therefore allows the RSVP packets to be encapsulated within another IP header. The RSVP packet will be addressed to the LSP destination, but the outer IP packet will be addressed to the next hop on that path. The Internet will then forward the double encapsulated packet to the next hop. If this method were used, the nodes on the path could use IPSEC. 2) In section 5.13 Layer 3 Protocol: you wrote, "RSVP identifies a single payload protocol during LSP setup, but there is no scope within the protocol for CR-LDP to do this." I'm still trying to understand what you really meant. Do you mean that: with RSVP, you can only setup an LSP for the usage of a single layer 3 protocol, and with CR-LDP, you can use one LSP route for transmitting any number of layer 3 protocols? It may be useful for egress LSR to know the layer 3 protocol. RSVP allows this (but only one L3 protocol per LSP). CR-LDP does not have this facility at all. In both cases, the nodes on the path can ignore the L3 protocol. More clear explanation can help me understand your paper. And if I have to read the other resources, could you please point those? Your help will be very appreciated. Thanks for your nice paper, again. Regards, Rae ------------------------------------------------- Myong-Rae Chang, Ph.D. cmr@sktelecom.com 4G R&D Team, SK Telecom R&D Center 9-1 Sunae-dong Pundang-gu Sungnam City Kyunggi-do 463-020, South Korea Mobile: +82-11-9874-3926 TEL +82-342-710-5201 FAX +82-31-710-5299 ------------------------------------------------- ------_=_NextPart_001_01C0C8B9.680050D0 Content-Type: text/html; charset="ks_c_5601-1987"
Rae
 
I have interleaved some answers to your questions on our white paper below.
 
Ben

-----------------------------------------------
Ben Miller
Business Unit Manager, Network Convergence Group
Data Connection Ltd
Tel:  +44 (0) 20 8366 1177      Fax:  +44 (0) 20 8363 1468
Email:  bmm@dataconnection.com  Web:  http://www.dataconnection.com

-----Original Message-----
From: Rae M. Chang [mailto:cmr@sktelecom.com]
Sent: Wednesday, April 18, 2001 9:21 AM
To: Ben Miller
Subject: Questions on your white paper

Hello,
 
I've read your white paper, titled "MPLS TE: A Choice of Signaling Protocols" and
have some wonders what you really mean.
 
1) In section 5.2 Security:
you wrote, "RSVP targets its PATH messages at the egress LSR so that the
intermediate LSRs cannot access the PATH messages. (in case of IPSEC applied)"
 
But, isn't it true that the IP packets including the PATH message have to be addressed
to peer LSR node across the to-be LSP route? 
I can't understand why the PATH message has to be targeted at the egress LSR
when you encapsulate the PATH message with IPSEC.
 
IPSEC relies on tokens known to the endpoints.   Traditional RSVP  (and therefore RSVP-TE for MPLS) requires that the destination for the PATH is the egress  of the LSP.  In order for intermediate nodes to spot the PATH message, the RouterAlert bit is set, informing intermediate nodes that they should check the contents of the packet.  On seeing that it is an RSVP message, the intermediate node knows it should pass it to the RSVP/MPLS stack for processing.  The intermediate nodes do not have the IPSEC tokens for the endpoints, and therefore they could not decode a PATH that the ingress had encrypted using the egress IPSEC token.  Hence, IPSEC cannot be used for these packets.
 
However, there is more to this story. 
 
Because some devices may not understand the RouterAlert bit, the RSVP spec effectively allows the PATH messages to be sent to the next hop.  Although this is not 100% spec compliant, it is expected to work in most cases.  (The intermediate nodes then learn the LSP destination from the Explicit Route Object.)  If this processing were used, IPSEC could be used between each hop.
 
Furthermore, the GMPLS extensions that require/allow out-of-band signalling introduce another option.  When running GMPLS with out-of-band signalling, it is possible (and sometimes necessary) to address the RSVP packets to intermediate nodes.  This would be the case if, for example, a network of optical cross-connects is exchanging signalling data by sending RSVP messages over the Internet.  In this case, sending RSVP packets to the LSP destination and setting the RouterAlert bit would mean that every router in the Internet attempted to process the packet, whereas you only want the optical cross-connects on the path to do so. 
 
GMPLS therefore allows the RSVP packets to be encapsulated within another IP header.  The RSVP packet will be addressed to the LSP destination, but the outer IP packet will be addressed to the next hop on that path.  The Internet will then forward the double encapsulated packet to the next hop.  If this method were used, the nodes on the path could use IPSEC.
 
2) In section 5.13 Layer 3 Protocol:
you wrote, "RSVP identifies a single payload protocol during LSP setup, but there is
no scope within the protocol for CR-LDP to do this."
 
I'm still trying to understand what you really meant.  Do you mean that:
with RSVP, you can only setup an LSP for the usage of a single layer 3 protocol, and
with CR-LDP, you can use one LSP route for transmitting any number of layer 3 protocols?
 
It may be useful for egress LSR to know the layer 3 protocol.  RSVP allows this (but only one L3 protocol per LSP).  CR-LDP does not have this facility at all.   In both cases, the nodes on the path can ignore the L3 protocol. 
 
More clear explanation can help me understand your paper. And if I have to read the other
resources, could you please point those?   Your help will be very appreciated. 
 
Thanks for your nice paper, again. 
 
Regards,
 
Rae
 
-------------------------------------------------
  Myong-Rae Chang, Ph.D. cmr@sktelecom.com
  4G R&D Team, SK Telecom R&D Center
  9-1 Sunae-dong Pundang-gu Sungnam City
  Kyunggi-do 463-020, South Korea
  Mobile: +82-11-9874-3926  
  TEL +82-342-710-5201  FAX +82-31-710-5299
-------------------------------------------------
------_=_NextPart_001_01C0C8B9.680050D0-- From owner-mpls@UU.NET Thu Apr 19 06:31:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09786 for ; Thu, 19 Apr 2001 06:31:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkh25946; Thu, 19 Apr 2001 09:56:06 GMT Received: by mail-control.mail.uu.net id QQklkh26643 for mpls-outgoing; Thu, 19 Apr 2001 09:55:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklkh26635 for ; Thu, 19 Apr 2001 09:55:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklkh13325 for ; Thu, 19 Apr 2001 09:54:02 GMT Received: from roura.ac.upc.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: roura.ac.upc.es [147.83.33.10]) id QQklkh24021 for ; Thu, 19 Apr 2001 09:53:56 GMT Received: from careglio (pccba13.ac.upc.es [147.83.35.92]) by roura.ac.upc.es (8.11.0/8.11.0) with SMTP id f3J9roI22955 for ; Thu, 19 Apr 2001 11:53:50 +0200 (MET DST) Message-ID: <001101c0c8b6$a3701a90$5c235393@ccaba.upc.es> From: "Davide Careglio" To: References: <65256A33.002BB21B.00@sandesh.hss.hns.com> Subject: virus alert! Date: Thu, 19 Apr 2001 11:53:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQklkh25946 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA09786 Dear All, I found a virus in a previous mail with subject: Re: Questions about merge-capability in LDP. I don't know who sent it. So, I notify all checking the mail before reading. Regards, Davide _______________________________________ Davide Careglio UPC Universitat Politècnica de Catalunya Departament d'Arquitectura de Computadores Jordi Girona, 1-3, D6 008 (Campus Nord) 08034 Barcelona (Spain) Phone: +34 93 4017182 Fax: +34 93 4017055 E-Mail: careglio@ac.upc.es ----- Original Message ----- From: To: Cc: "David Charlap" ; Sent: Thursday, April 19, 2001 9:57 AM Subject: Re: Questions about merge-capability in LDP > > > hi bhushana! > a few points here from me! > > regards > -sumit > > > > > "Nagabhushana Ramaswamy Nadig" on 04/19/2001 > 05:27:06 PM > > Please respond to nagabhushana.ramaswamy@wipro.com > > To: David Charlap > cc: mpls@UU.NET (bcc: Sumit Chauhan/HSS) > > Subject: Re: Questions about merge-capability in LDP > > > > > Hello, > I have a few observations from your mail. > 1. Particularly the way you have mentioned of raising the internal label > requests for the FECs. How far does it make sense to wait for a label > request from a peer LSR and take the same as a trigger for learning a new > FEC. What I think is, as each of these LSR's would be running a L3 > routing protocol the moment I learn a new route at L3 should be the > trigger for me to make a new request to the next hop peer (Ideally we will > be populating our FTN table in this case and ILM in the former). > Depending upon this I would say the sequence of message flow > changes in your below discussions. > > 2. Scenario 5. I really doubt such a configuration will work for you. A > non-merge capable LSR cofigured for Unsolicited distribution (there by to > also to receive unsolicited messages). In this case if you receive an > Unsolicited mapping msg, what will you do with that? To which upstream > peer are you going to distribute this? I think because of this only the > architecture has wisely avoided the DU mode for non-merge LSRs. > ****sumit**** > In this case would it not make sense to retain the label with you and you might > be the start of that LSP then and above/before this upstream router, maybe we > are getting either unlabeled packets or this can be an aggregating router for > packets to same destination from multiple sources(interfaces or peers). I guess > that is the idea behind merging. > ************* > > regards > Bhushana > > > > A rereading of the LDP RFC brings to mind some questions abouthow > > different modes of operation (on-demand vs. unsolicited) work in > > conjunction with merge-capable and non-merge-capable routers. > > > > I've run through several scenarios. If any of my assumptions are wrong, > > please let me know. I think I've got everything right for the > > downstream-on-demand scenarios. I don't know if I've got things right > > for the downstream-unsolicited scenarios. > > > > All of these scenarios involve 5 routers in a straight-line topology. > > All routers are IP-lookup and push capable, and are therefore capable of > > acting as ingress rotuers. There is a single FEC, for which which R5 is > > egres.. > > > > -=-=-=-=- > > > > Scenario 1: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > All routers are merge-capable. They are configured for downstream-on- > > demand label distribution. R1 sends a Label-request to R2, and it > > propagates to R5. R5 sends a Label-mapping to R4, and it propagates > > back to R1. The resulting LSP looks like this: > > > > ->-\ ->-\ ->-\ > > ---------->------>------>------> > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > R1 pushes the label for incoming packets. R2-R4 configure themselves > > both to push the label for unlabeled packets, and to swap the label for > > labeled packets. R5 pops the label for labeled packets and simply > > forwards unlabeled traffic > > > > -=-=-=-=- > > > > Scenario 2: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > No routers are merge-capable. Downstream-on-demand distribution. > > > > R1 sends a Label-request to R2. R2 sends two Label-requests to R3 (one > > for labeled traffic and one for unlabeled traffic). R3 sends three > > Label-requests to R4 (two for the two possible incoming labels and one > > for unlabeled traffic.) R4 sends four Label-requests to R5 (three for > > the three possible incoming labels and one for unlabeled traffic.) > > > > Label-mappings propagate back to satisfy all requests. The resulting > > LSPs look like: > > > > ----------> > > -----------------> > > ------------------------> > > -------------------------------> > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > -=-=-=-=- > > > > Scenario 3: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > (M) (M) > > > > R2 and R4 are merge capable. R1, R3 and R5 are not. > > Downstream-on-demand distribution. > > > > R1 sends a Label-request to R2. Since R2 can merge this request with > > unlabeled traffic, it only sends one Label-request to R3. R3 can not > > merge this request with unlabeled traffic, so it sends two > > Label-requests to R4. R4 can merge both of these requests with each > > other and with unlabeled traffic, so it sends one Label-Request to R5. > > > > Label-mappings propagate back to satisfy all requests. The resulting > > LSP looks like: > > > > ->-\ ->--------\ > > ---------->------------->------> > > ->-/ > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > -=-=-=-=- > > > > Scenario 4: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > All routers are merge-capable. They are configured for downstream- > > unsolicited label distribution. R5 sends a Label-mapping to R4, and it > > propagates to R1. The resulting LSP looks just like it would with > > on-demand distribution: > > > > ->-\ ->-\ ->-\ > > ---------->------>------>------> > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > -=-=-=-=- > > > > Scenario 5: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > No routers are merge-capable. Downstream-unsolicited label distribution. > > > > - R5 sends a Label-mapping to R4. > > - R4 realizes that it needs two labels - one to send upstream and one > > to install for unlabeled traffic. It uses one label and sends a > > Label-request message to R5 in order to get a second. > > - R5 sends a second Label-mapping to R5 > > - R4 sends a Label-mapping message to R3. > > - R3 realizes that it needs two labels - one to send upstream and one > > to install for unlabeled traffic. It uses one label and sends a > > Label-request message to R4 in order to get a second. > > - R4 sends a Label-request downstream to R5, since it now needs a > > third label (in order to satisfy the new request). > > - R5 sends a third Label-mapping to R4 > > - R4 sends a second Label-mapping to R3 > > - R3 sends a Label-mapping to R2 > > - R2 realizes that it needs two labels - one to send upstream and one > > to install for unlabeled traffic. It uses one label and sends a > > Label-request message to R3 in order to get a second. > > - R3 sends a Label-request downstream to R4, since it now needs a > > third label (in order to satisfy the new request). > > - R4 sends a Label-request downstream to R5, since it now needs a > > fourth label (in order to satisfy the new request) > > - R5 sends a fourth Label-mapping to R4 > > - R4 sends a third Label-mapping to R3 > > - R3 sends a second Label-mapping to R2 > > - R2 sends a Label-mapping to R1 > > > > The resulting LSPs look just like they would with on-demand > > distribution: > > > > ----------> > > -----------------> > > ------------------------> > > -------------------------------> > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > -=-=-=-=- > > > > Scenario 6: > > > > [R1]---{R2]---[R3]---[R4]---[R5] > > (M) (M) > > > > R2 and R4 are merge capable. R1, R3 and R5 are not. > > Downstream-unsolicited. > > > > - R5 sends a Label-mapping to R4 > > - R4 sends a Label-mapping to R3 > > - R3 realizes that it needs two labels - one to send upstream and one > > to install for unlabeled traffic. It uses one label and sends a > > Label-request message to R4 in order to get a second. > > - R4, being merge-capable, does not propagate the Label-request, but > > sends a Label-mapping to R3 > > - R3 sends a Label-mappng to R2 > > - R2 sends a Label-mapping to R1 > > > > The resulting LSp looks just like it does with on-demand distribution. > > > > ->-\ ->--------\ > > ---------->------------->------> > > ->-/ > > [R1]---{R2]---[R3]---[R4]---[R5] > > > > -=-=-=-=- > > > > Does all of this look right? It seems good to me. But I'm not certain > > about scenarios 5 and 6. The LDP RFC doesn't explicitly document the > > behavior of non-merge-capable routers receiving unsolicited label > > mappings. > > > > Comments? > > > > -- David > > > > > > > > > From owner-mpls@UU.NET Thu Apr 19 08:27:06 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10252 for ; Thu, 19 Apr 2001 08:27:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkr13020; Thu, 19 Apr 2001 12:24:22 GMT Received: by mail-control.mail.uu.net id QQklkr01031 for mpls-outgoing; Thu, 19 Apr 2001 12:23:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklkr01023 for ; Thu, 19 Apr 2001 12:23:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklkr18614 for ; Thu, 19 Apr 2001 12:22:19 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklkr10633 for ; Thu, 19 Apr 2001 12:22:18 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA29828 for mpls@uu.net; Thu, 19 Apr 2001 08:22:18 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklkr00529 for ; Thu, 19 Apr 2001 12:18:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklkr04644 for ; Thu, 19 Apr 2001 12:16:03 GMT Received: from lohi.eng.telia.fi by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQklkr06609 for ; Thu, 19 Apr 2001 12:16:02 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3JCGGC29119; Thu, 19 Apr 2001 15:16:16 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15070.55056.631300.669715@lohi.eng.telia.fi> Date: Thu, 19 Apr 2001 15:16:16 +0300 (EEST) To: Javier Antich Cc: erosen@cisco.com, sgong@gmu.edu, mpls@UU.NET Subject: RE: Does MPLS Require L3 Routing Table ? 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 Javier Antich writes: > Yes, that is true, but how would the core router choose the right label > towards the right next hop if it receives a label assignment from two or > more neighbours for the same route? if an lsr receives two advertisements for the same destination, it would pick one of them, for example, based on the length of the "traceroute" in the message and it could remember the other one. -- juha From owner-mpls@UU.NET Thu Apr 19 09:47:17 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11013 for ; Thu, 19 Apr 2001 09:47:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkw06550; Thu, 19 Apr 2001 13:44:46 GMT Received: by mail-control.mail.uu.net id QQklkw24797 for mpls-outgoing; Thu, 19 Apr 2001 13:44:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklkw24773 for ; Thu, 19 Apr 2001 13:44:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklkw26818 for ; Thu, 19 Apr 2001 13:43:15 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQklkw11460 for ; Thu, 19 Apr 2001 13:43:15 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 2FC6494009; Thu, 19 Apr 2001 09:43:15 -0400 (EDT) Message-ID: <3ADEEB73.CBE7AD32@sandburst.com> Date: Thu, 19 Apr 2001 09:43:15 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: chetan.kumar@wipro.com Cc: mpls@UU.NET Subject: Re: Label Aborting.. References: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Chetan S,

    A careful read of the procedures for receiving a label abort
results in the realization that - to get to LAbR.6 - the following
circumstances must apply:

        the message must match a previously received label
            request (LAbR.1)

        the LSR must not have responded to this request
            (LAbR.2)

        the LSR will have at least queued a notify message
            to the LSR that previously requested the label (and
            subsequently aborted the request) (LAbR.3)

        the LSR must itself not have an outstanding label
            request (that would be to a downstream next hop
            LSR) (LAbR.4) and

        the LSR must have a label mapping (again from a
            downstream next hop) (LAbR.5)

Otherwise, the step at LAbR.6 is skipped.  From this, you
can see that this step has nothing to do with the text you
point out in section 3.5.10.  The purpose of this step (as
indicated in note 2) is to ensure that any label mapping
the local LSR has received that is made irrelevant by the
label request abort message it has just received will be
correctly dealt with.

Step LAbR.2 (highlighted above) ensures that - in the
event that a label mapping crossed the label request
abort (in the mail, so to speak) - the local LSR ignores
the label request abort.  This is done - as you may know
- because the procedures for the receipt of the label
mapping at the upstream LSR will ensure that a label
release is subsequently sent - if that is what that LSR
wants to do at that time.

The procedures for dealing with the downstream label
mapping in this case just happen to be exactly the same
as they would be if a label mapping had been sent to the
upstream LSR - based on the prior label request and the
existing label mapping from the downstream LSR - and
subsequently released.

Does this clarify the issue for you?

--
Eric Gray

You wrote:

Hi,
        I was looking thro' the rfc 3036.

At section 3.5.10 (page 73) it is mentioned

   If an LSR receives a Label Abort Request Message after it has
   responded to the Label Request in question with a Label Mapping
   message or a Notification message, it ignores the abort request.

And in thge Appendix at Page 106 it is mentioned.

      LAbR.6  Generate Event: Received Label Release Message for FEC
      from MsgSource.  (See Note 2.)
      Goto LAbR.11.

I feel that we have to follow what is mentioned in the section  3.5.10,
since it makes sense for the upstream(MsgSource) to release the Label
explicitly based on its retention mode. Let me know how do U think ??

Thanks
Chetan S

___________
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself.  Therefore all
progress depends on the unreasonable man.
                -- George Bernard Shaw

From owner-mpls@UU.NET Thu Apr 19 09:52:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11075 for ; Thu, 19 Apr 2001 09:52:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkx08894; Thu, 19 Apr 2001 13:49:32 GMT Received: by mail-control.mail.uu.net id QQklkx25625 for mpls-outgoing; Thu, 19 Apr 2001 13:48:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklkx25613 for ; Thu, 19 Apr 2001 13:48:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklkx11289 for ; Thu, 19 Apr 2001 13:47:59 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQklkx07922 for ; Thu, 19 Apr 2001 13:47:58 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id <2XLWMAVG>; Thu, 19 Apr 2001 15:47:11 +0200 Message-ID: From: Javier Antich To: Juha Heinanen Cc: erosen@cisco.com, sgong@gmu.edu, mpls@UU.NET Subject: RE: Does MPLS Require L3 Routing Table ? Date: Thu, 19 Apr 2001 15:47:06 +0200 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 JAA11075 Length may not be the best routing metric. There are other parameters that a routing protocol would consider (metric configured for each interface, bandwidth, ...). Javier ^ ^ ==============ooo====(.)v(.)====ooo===== Javier Antich Romaguera Network Consultant --------------------------------------------------------------------------- TELINDUS Pza. Ciudad de Viena, 6-2º 28040 Madrid --------------------------------------------------------------------------- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 --------------------------------------------------------------------------- For more information about our products and services, please visit our website http://www.telindus.com --------------------------------------------------------------------------- Full connectivity & mobility ==================ooo0===0ooo======== > -----Mensaje original----- > De: Juha Heinanen [SMTP:jh@lohi.eng.telia.fi] > Enviado el: jueves 19 de abril de 2001 14:16 > Para: Javier Antich > CC: erosen@cisco.com; sgong@gmu.edu; mpls@UU.NET > Asunto: RE: Does MPLS Require L3 Routing Table ? > > Javier Antich writes: > > > Yes, that is true, but how would the core router choose the right label > > towards the right next hop if it receives a label assignment from two > or > > more neighbours for the same route? > > if an lsr receives two advertisements for the same destination, it would > pick one of them, for example, based on the length of the "traceroute" in > the message and it could remember the other one. > > -- juha From owner-mpls@UU.NET Thu Apr 19 10:13:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11326 for ; Thu, 19 Apr 2001 10:13:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklky18827; Thu, 19 Apr 2001 14:10:50 GMT Received: by mail-control.mail.uu.net id QQklky14600 for mpls-outgoing; Thu, 19 Apr 2001 14:10:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklky14587 for ; Thu, 19 Apr 2001 14:10:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklky08520 for ; Thu, 19 Apr 2001 14:09:46 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklky17294 for ; Thu, 19 Apr 2001 14:09:45 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08954; Thu, 19 Apr 2001 10:09:42 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29684; Thu, 19 Apr 2001 10:09:45 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Apr 2001 10:09:43 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5537DC78@vie-msgusr-01.dc.fore.com> From: "Ju, Yu" To: "'Eric Gray'" , "Charlap, David" Cc: mpls@UU.NET Subject: RE: Questions about merge-capability in LDP Date: Thu, 19 Apr 2001 10:09:42 -0400 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 Eric, A label mapping message can have a FEC with more than one FEC elements. However, a label request message can have only one FEC element. How should a non-merge capable or merge-averse LSR handle this case? Thanks, Yu -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] Sent: Wednesday, April 18, 2001 4:56 PM To: David Charlap Cc: mpls@UU.NET Subject: Re: Questions about merge-capability in LDP David, That's because - when the issue with handling merge capable and non-merge capable label distributions came up during the last call, the authors decided that the functionality required to handle this was not specific to non-merging LSRs. It is applicable to any LSP for which the upstream LSR chooses not to merge - whether or not it is merge capable. Therefore, if you were expecting there to be a call-out - of the sort "if the LSR is non-merge capable", then you will continue to be disappointed. :-) If you look at the procedures for handling label mappings, you will see that the notion of handling a requested label is dealt with irrespective of the label distribution mode (DU/DoD). You will also see that there is nothing in the procedures for handling a label request that prevents an LSR from responding to one even if the mode of operation is supposed to be DU. If I can request a label - and get a distinct one - whenever I want one (unless and until the peer runs out), then I can handle both the case where the peer is merge capable and the case when the peer is simply merge-averse. -- Eric Gray You wrote: > Eric Gray wrote: > > > > Near as I can tell, these are all right. However, LDP does > > explicitly describe the handling of 'unsolicited label mappings' in > > procedures for receiving label mappings in Appendix A. Look into > > the behaviors with respect to getting a label mapping for which > > there is no outstanding request - that's pretty much what it's all > > about. > > Yes, but the pseudocode there doesn't talk about non-merge-capable > routers requesting additional labels. The only mention of merge- > capable vs. non-merge-capable in Appendix A is in the context of whether > or not to include a Path Vector TLV. > > -- David From owner-mpls@UU.NET Thu Apr 19 10:19:43 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11464 for ; Thu, 19 Apr 2001 10:19:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkz06217; Thu, 19 Apr 2001 14:17:17 GMT Received: by mail-control.mail.uu.net id QQklkz15326 for mpls-outgoing; Thu, 19 Apr 2001 14:16:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklkz15321 for ; Thu, 19 Apr 2001 14:16:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklkz04757 for ; Thu, 19 Apr 2001 14:15:58 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQklkz25333 for ; Thu, 19 Apr 2001 14:15: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 HAA26742 for ; Thu, 19 Apr 2001 07:16:01 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA05296 for mpls@uu.net; Thu, 19 Apr 2001 10:15:34 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkljt16831 for ; Thu, 19 Apr 2001 06:26:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkljt12220 for ; Thu, 19 Apr 2001 06:25:50 GMT Received: from mail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQkljt03496 for ; Thu, 19 Apr 2001 06:25:46 GMT Received: by MAIL with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Apr 2001 12:01:50 +0500 Message-ID: <70EB682332F4D41187D6000629AE2C652BC8E1@MAIL> From: Prabhugouda To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: Regarding Label stack Date: Thu, 19 Apr 2001 12:01:49 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Dear All, > > I have the following questions: > 1. Does any one supports hierarchy in MPLS, label stacking? > 2. How does the ILM looks in case of label stacking? > > Prabhu > > ---------------------------------------------------------------- > Prabhugouda Biradar, > Huawei Technology India Pvt. Ltd. > Unit 10/11, Level 2, Innovator Block, > Whitefield Road, > Bangalore - 560 066. > > Office Tel. +91-80-8410061/753/755/1651. > Mobile : +91-98440-84691. > Res. Tel : +91-80-3520909. > > > > From owner-mpls@UU.NET Thu Apr 19 10:21:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11496 for ; Thu, 19 Apr 2001 10:21:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkz16593; Thu, 19 Apr 2001 14:18:44 GMT Received: by mail-control.mail.uu.net id QQklkz15356 for mpls-outgoing; Thu, 19 Apr 2001 14:16:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklkz15347 for ; Thu, 19 Apr 2001 14:16:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklkz07168 for ; Thu, 19 Apr 2001 14:15:57 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQklkz25768 for ; Thu, 19 Apr 2001 14:15:56 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 HAA26938 for ; Thu, 19 Apr 2001 07:16:22 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA05300 for mpls@uu.net; Thu, 19 Apr 2001 10:15:54 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkljy10013 for ; Thu, 19 Apr 2001 07:38:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkljy05514 for ; Thu, 19 Apr 2001 07:37:36 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQkljy04652 for ; Thu, 19 Apr 2001 07:37:32 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id <2XLWMAD6>; Thu, 19 Apr 2001 09:36:39 +0200 Message-ID: From: Javier Antich To: Juha Heinanen , erosen@cisco.com Cc: sgong@gmu.edu, mpls@UU.NET Subject: RE: Does MPLS Require L3 Routing Table ? Date: Thu, 19 Apr 2001 09:36:33 +0200 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 KAA11496 > > How would you get the LSPs to be setup "automatically between all your edge > > routers" without having any L3 routing information in the core? >i'm not an ldp expert, but i assume that using the du mode, each egress >router can advertise an lsp to itself to all its neighbors and so on. >thus eventually every router in the system would have a path to every >egress router. this assumes that each router adds itself to the >advertisement in order to cut the loops. Yes, that is true, but how would the core router choose the right label towards the right next hop if it receives a label assignment from two or more neighbours for the same route? That might happen, and the core router must use its IGP routing table to select the right label and right nexthop/outgoing interface. ^ ^ ==============ooo====(.)v(.)====ooo===== Javier Antich Romaguera Network Consultant --------------------------------------------------------------------------- TELINDUS Pza. Ciudad de Viena, 6-2º 28040 Madrid --------------------------------------------------------------------------- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 --------------------------------------------------------------------------- For more information about our products and services, please visit our website http://www.telindus.com --------------------------------------------------------------------------- Full connectivity & mobility ==================ooo0===0ooo======== > -----Mensaje original----- > De: Juha Heinanen [SMTP:jh@lohi.eng.telia.fi] > Enviado el: jueves 19 de abril de 2001 4:31 > Para: erosen@cisco.com > CC: sgong@gmu.edu; mpls@UU.NET > Asunto: Re: Does MPLS Require L3 Routing Table ? > > > > How would you get the LSPs to be setup "automatically between all your > edge > > routers" without having any L3 routing information in the core? > > i'm not an ldp expert, but i assume that using the du mode, each egress > router can advertise an lsp to itself to all its neighbors and so on. > thus eventually every router in the system would have a path to every > egress router. this assumes that each router adds itself to the > advertisement in order to cut the loops. > > -- juha From owner-mpls@UU.NET Thu Apr 19 10:22:47 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11510 for ; Thu, 19 Apr 2001 10:22:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkz18746; Thu, 19 Apr 2001 14:20:16 GMT Received: by mail-control.mail.uu.net id QQklkz15495 for mpls-outgoing; Thu, 19 Apr 2001 14:18:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklkz15448 for ; Thu, 19 Apr 2001 14:18:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklkz23077 for ; Thu, 19 Apr 2001 14:16:21 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQklkz26365 for ; Thu, 19 Apr 2001 14:16:19 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 HAA27198 for ; Thu, 19 Apr 2001 07:16:45 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA05306 for mpls@uu.net; Thu, 19 Apr 2001 10:16:18 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklkc02537 for ; Thu, 19 Apr 2001 08:39:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklkc16765 for ; Thu, 19 Apr 2001 08:38:19 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQklkc19258 for ; Thu, 19 Apr 2001 08:38:18 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id <2XLWMAHX>; Thu, 19 Apr 2001 10:37:31 +0200 Message-ID: From: Javier Antich To: Javier Antich , Rajesh P Jain , Bharti Batra , mpls@UU.NET Subject: RE: Does MPLS Require L3 Routing Table ? Date: Thu, 19 Apr 2001 10:37:26 +0200 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 KAA11510 Well, I have been following the thread and I have not seen one basic thing. Of course you need IP routing table if you run MPLS in and IP network, but, you do not need to have the full Internet routing table in all the routers. You can remove BGP from the core so that BGP decisions and Next-hop BGP resolutions are done at the edge and the appropriate label is selected for reaching the right exit point from the cloud. Then, you need IP routing table, but if it is a core router and it is an Internet environment, the routing table can be much smaller than it would be if you were not running MPLS. ^ ^ ==============ooo====(.)v(.)====ooo===== Javier Antich Romaguera Network Consultant --------------------------------------------------------------------------- TELINDUS Pza. Ciudad de Viena, 6-2º 28040 Madrid --------------------------------------------------------------------------- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 --------------------------------------------------------------------------- For more information about our products and services, please visit our website http://www.telindus.com --------------------------------------------------------------------------- Full connectivity & mobility ==================ooo0===0ooo======== > -----Mensaje original----- > De: Rajesh P Jain [SMTP:rpjain@sasken.com] > Enviado el: viernes 13 de abril de 2001 10:16 > Para: Bharti Batra; mpls@UU.NET > Asunto: Re: Does MPLS Require L3 Routing Table ? > > "Hello", > Thanks for the response. > > Well, if it requires L3 Routing table to > build up the Label information, then what is the advantage of MPLS??? > Well, Anyhow, it will require the building of L3 Routing Table (May be > through RIP/OSPF/BGP etc), then Lable info can be formed by using only L3. > So, Anyhow, MPLS is dependent on L3, please explain me what is the > advantage of using MPLS (in terms of efficiency and speed switching of the > packets). > > With Regards > Rajesh P Jain > > ----- Original Message ----- > From: Bharti Batra > To: Rajesh P Jain ; mpls@UU.NET > > Sent: Friday, April 13, 2001 1:09 PM > Subject: Re: Does MPLS Require L3 Routing Table ? > > Hi ! > > Yes. LDP needs IP routing table to find out the route > towards the egress router to setup the LSP. LDP sends the LSP setup > request message along this path. > > Regds, > Bharti > > ----- Original Message ----- > From: Rajesh P Jain > To: mpls@UU.NET > Sent: Friday, April 13, 2001 12:52 PM > Subject: Does MPLS Require L3 Routing Table ? > > "Hello", List, > Well, I am very new to the MPLS > domain. I just wanted to check out whether MPLS domain neccesarily require > the L3 Routing Table (Maybe IP Routing Table) to build up it's label > (using the LDP Protocol). Or the LDP will take care of building the label > information automatically without the L3 Routing information? > > TIA > Rajesh P Jain > From owner-mpls@UU.NET Thu Apr 19 10:22:51 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11521 for ; Thu, 19 Apr 2001 10:22:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkz09761; Thu, 19 Apr 2001 14:20:14 GMT Received: by mail-control.mail.uu.net id QQklkz15479 for mpls-outgoing; Thu, 19 Apr 2001 14:18:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklkz15444 for ; Thu, 19 Apr 2001 14:17:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklkz23658 for ; Thu, 19 Apr 2001 14:16:35 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQklkz26660 for ; Thu, 19 Apr 2001 14:16:35 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 HAA21262 for ; Thu, 19 Apr 2001 07:16:38 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA05310 for mpls@uu.net; Thu, 19 Apr 2001 10:16:33 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklkc02713 for ; Thu, 19 Apr 2001 08:40:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklkc15311 for ; Thu, 19 Apr 2001 08:40:49 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQklkc21451 for ; Thu, 19 Apr 2001 08:40:48 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id <2XLWMA2A>; Thu, 19 Apr 2001 10:40:01 +0200 Message-ID: From: Javier Antich To: mpls@UU.NET Subject: RE: Does MPLS Require L3 Routing Table ? Date: Thu, 19 Apr 2001 10:39:53 +0200 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 KAA11521 > > How would you get the LSPs to be setup "automatically between all your edge > > routers" without having any L3 routing information in the core? >i'm not an ldp expert, but i assume that using the du mode, each egress >router can advertise an lsp to itself to all its neighbors and so on. >thus eventually every router in the system would have a path to every >egress router. this assumes that each router adds itself to the >advertisement in order to cut the loops. Yes, that is true, but how would the core router choose the right label towards the right next hop if it receives a label assignment from two or more neighbours for the same route? That might happen, and the core router must use its IGP routing table to select the right label and right nexthop/outgoing interface. ^ ^ ==============ooo====(.)v(.)====ooo===== Javier Antich Romaguera Network Consultant --------------------------------------------------------------------------- TELINDUS Pza. Ciudad de Viena, 6-2º 28040 Madrid --------------------------------------------------------------------------- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 --------------------------------------------------------------------------- For more information about our products and services, please visit our website http://www.telindus.com --------------------------------------------------------------------------- Full connectivity & mobility ==================ooo0===0ooo======== > -----Mensaje original----- > De: Juha Heinanen [SMTP:jh@lohi.eng.telia.fi] > Enviado el: jueves 19 de abril de 2001 4:31 > Para: erosen@cisco.com > CC: sgong@gmu.edu; mpls@UU.NET > Asunto: Re: Does MPLS Require L3 Routing Table ? > > > > How would you get the LSPs to be setup "automatically between all your > edge > > routers" without having any L3 routing information in the core? > > i'm not an ldp expert, but i assume that using the du mode, each egress > router can advertise an lsp to itself to all its neighbors and so on. > thus eventually every router in the system would have a path to every > egress router. this assumes that each router adds itself to the > advertisement in order to cut the loops. > > -- juha From owner-mpls@UU.NET Thu Apr 19 10:31:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11692 for ; Thu, 19 Apr 2001 10:31:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklkz13332; Thu, 19 Apr 2001 14:28:45 GMT Received: by mail-control.mail.uu.net id QQklkz16949 for mpls-outgoing; Thu, 19 Apr 2001 14:28:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklkz16935 for ; Thu, 19 Apr 2001 14:28:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklkz16548 for ; Thu, 19 Apr 2001 14:26:43 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklkz10539 for ; Thu, 19 Apr 2001 14:26:43 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11039 for ; Thu, 19 Apr 2001 10:26:40 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05200 for ; Thu, 19 Apr 2001 10:26:44 -0400 (EDT) Message-ID: <3ADEF5AB.B2C8EDBD@marconi.com> Date: Thu, 19 Apr 2001 10:26:51 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Questions on the DataConnection paper References: <005e01c0c867$658b7980$77131796@sktelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Rae M. Chang" wrote: > > But, isn't it true that the IP packets including the PATH message > have to be addressed to peer LSR node across the to-be LSP route? You must remember the history involved. RSVP was designed for use across the internet, where it is likely that some routers along the path will not support RSVP. You can't send a Path message to your peer, because your peer may not be running RSVP, and if so, the message would get lost. The solution is to send it to the egress address and use the Router Alert option in the IP header to force transit routers to process the packet (and not blindly forward it.) Now, if a non-RSVP router gets the packet, it is forwarded. If an RSVP router gets the packet, it is processed. > I can't understand why the PATH message has to be targeted at the > egress LSR when you encapsulate the PATH message with IPSEC. Straight RSVP doesn't work with IPSEC. There are extensions to the protocol for that. See RFC 2207. > 2) In section 5.13 Layer 3 Protocol: > it is written, "RSVP identifies a single payload protocol during LSP > setup, but there is no scope within the protocol for CR-LDP to do > this." > > I'm still trying to understand what they really meant. Do they mean > that: > with RSVP, you can only setup an LSP for the usage of a single > layer 3 protocol, and with CR-LDP, you can use one LSP route for > transmitting any number of layer 3 protocols? The label-request object of RSVP-TE include an L3 protocol ID. The ingress router informs other routers along the path what the L3 protocol will be. This means that the egress router does not have to know in advance how to encapsulate the payload after popping the last label. CR-LDP and LDP do not have this and therefore must use other mechanisms to indicate that an LSP is carrying non-IP traffic. These mechanisms may include administrative configuration or use of an inner-label to carry L3PID information on a per-packet basis. -- David From owner-mpls@UU.NET Thu Apr 19 10:47:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11867 for ; Thu, 19 Apr 2001 10:47:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklla03472; Thu, 19 Apr 2001 14:44:23 GMT Received: by mail-control.mail.uu.net id QQklla19131 for mpls-outgoing; Thu, 19 Apr 2001 14:43:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklla19125 for ; Thu, 19 Apr 2001 14:43:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklla23971 for ; Thu, 19 Apr 2001 14:42:52 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQklla01836 for ; Thu, 19 Apr 2001 14:42:47 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 HAA08331; Thu, 19 Apr 2001 07:42:50 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA05457; Thu, 19 Apr 2001 10:42:44 -0400 (EDT) Message-Id: <200104191442.KAA05457@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Juha Heinanen cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-reply-to: Your message of Thu, 19 Apr 2001 05:31:26 +0300. <15070.19966.401856.384943@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, 19 Apr 2001 10:42:44 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Juha> i'm not an ldp expert, but i assume that using the du mode, each Juha> egress router can advertise an lsp to itself to all its neighbors and Juha> so on. thus eventually every router in the system would have a path Juha> to every egress router. this assumes that each router adds itself to Juha> the advertisement in order to cut the loops. Let me call your attention to section 3.5.7.1 of the LDP spec: An LSR receiving a Label Mapping message from a downstream LSR for a Prefix or Host Address FEC Element should not use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element. So one can't really do things the way you suggest. In fact, if one did distribution address prefix routing information in this manner using LDP, then LDP would be functioning as a L3 routing algorithm, so it would in any case be somewhat inaccurate to say that MPLS is being used without the need to maintain any L3 routing information. Juha> I would like to add that I don't advocate such a mode of operation and Juha> that that actually has nothing to do with inarp over unidicational Juha> vcs. The latter is used when the provider has one way or another Juha> created plsps connecting ce lsrs together. Given a pre-existing LSP connecting two CEs, it might well make sense to have a procedure for each to discover who is at the other end. The prior question here would be whether there is real value in having these pre-existing LSPs connecting the two CEs. I think what people have been objecting to is the suggestion (now apparently disavowed) that such a procedure somehow eliminates the need to have L3 routing in the core. That's what made it seems like there must be some MPOA-like stuff hiding beneath the surface. From owner-mpls@UU.NET Thu Apr 19 11:06:37 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12306 for ; Thu, 19 Apr 2001 11:06:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllc09429; Thu, 19 Apr 2001 15:03:21 GMT Received: by mail-control.mail.uu.net id QQkllc28905 for mpls-outgoing; Thu, 19 Apr 2001 15:02:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllc28350 for ; Thu, 19 Apr 2001 15:02:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllc09269 for ; Thu, 19 Apr 2001 15:02:19 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkllc07363 for ; Thu, 19 Apr 2001 15:02:19 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA16090 for mpls@uu.net; Thu, 19 Apr 2001 11:02:18 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkllb20858 for ; Thu, 19 Apr 2001 14:57:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllb07487 for ; Thu, 19 Apr 2001 14:56:17 GMT Received: from salamander.eu.fore.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: salamander.eu.fore.com [193.132.138.12]) id QQkllb06162 for ; Thu, 19 Apr 2001 14:56:16 GMT Received: from gbennett-pc (compuserve-45-92.pit.comms.marconi.com [169.144.45.92]) by salamander.eu.fore.com (8.9.1/8.9.1) with SMTP id PAA03433; Thu, 19 Apr 2001 15:54:59 +0100 (BST) Message-Id: <200104191454.PAA03433@salamander.eu.fore.com> X-Sender: gbennett@salamander.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Apr 2001 16:58:59 +0100 To: jshen@cad.zju.edu.cn From: Geoff Bennett Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? Cc: MP LS , mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <3ADD60A9.879AC43D@cad.zju.edu.cn> References: <200104180906.KAA21530@salamander.eu.fore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Actually Option 1 does, and will continue to happen in the real world. Apart from ATM's use as a Traffic Engineering plane in "conventional" IP networks, it is used in a number of other service architectures. The common factor for these services is that they provide high revenue to the Service Provider. Currently MPLS does not do this (actually this is unfair...MPLS may well provide high REVENUE, but it does not provide high EARNINGS). Note, that MPLS is beginning to offer "value-added IP services" such as VPNs, but it's not clear yet whether these services actually operate at a profit, or just at a lower loss than best effort (ie. Internet) IP services. For the near to mid-term future, the DSL market will ensure that bother the pure ATM and the SIN model will continue at the edge of the network. The DSL market is very dependent on local regulatory and market conditions, so I don't want to make specific comments, but in general the view is that ADSL specifically can generally demonstrate an ROI within 2 years, assuming the ADSL has an ATM network behind it in order to support high revenue voice services. Cheers, Geoff At 17:38 18/04/01 +0800, shen jing wrote: >> 1. Pure ATM. In this case the switch will operate UNI and NNI interfaces, >> and will run PNNI as its routing protocol (PNNI is both an IGP and EGP). >> UNI and PNNI signalling will happen on VCI 5. > >I don't think this will happen in real world , because MPLS integrate >IP routing and switching mechanism. As it uses ATM switch as transit stage >solution, it has to use SIN style equipments. While, it will go to pure MPLS in >future. If PNNI is used as routing procedure, it should be the situation where >ATM switch path is used as tunnel for MPLS. > > >> >> 2. Pure MPLS. In this mode, there is no ATM signalling, and no PNNI. >> MPLS routing and signalling (OSPF, ISIS, CR-LDP, RSVP-TE, etc.) will pass >> over VCI 32 (note, please check the latest draft for the actual VCI number, >> it's a while since I read this info). >> >> 3. Ships in the Night (SIN). In this case, both ATM and MPLS Control >> Planes operate simultaneously. ATM signalling happens on VCI 5, and MPLS >> signalling on VCI 32. VCs that are set up as a result of signalling are >> "owned" by one or other of these control planes. SIN would allow an >> operator to continue to run high revenue voice services (and maybe existing >> Frame Relay or native ATM services...they make money too) over the ATM >> "character" of the switch. They can then run the loss-making Internet >> services over the MPLS character. >> >> I think there are ideas floating around about a more integrated control >> plane for ATM/MPLS switches based on PNNI, but I don't think these have >> made it to draft as yet. >> >> Cheers, >> Geoff >> >> At 10:02 18/04/01 +0200, MP LS wrote: >> >Hello all, >> > >> >I have some questions becasue something is verry strange to me. >> >I just assumed that ATM-LSRS used an IP routing protocol (IGP) just for >> >finding the topology of the network. >> > >> >But last i read an doccument and there they described that When you change >> >an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. Can >> >anyone make this clear for me?? >> > >> >Thanks a lot. >> > >> >Greetings, >> > >> >Niels Sitters. >> > >> > >> >_________________________________________________________________________ >> >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. >> > >> >------- >> >The MPLS-OPS Mailing List >> >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >> >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >> > >> ================================================================ >> Geoff Bennett Tel: (33) 497 21 43 62 >> Director of Technology, OCTO Fax: (33) 497 21 43 50 >> Marconi >> Gaia - Bat. E email: geoff.bennett@marconi.com >> BP 123 >> 06903 SOPHIA ANTIPOLIS >> FRANCE >> ================================================================ > ================================================================ Geoff Bennett Tel: (33) 497 21 43 62 Director of Technology, OCTO Fax: (33) 497 21 43 50 Marconi Gaia - Bat. E email: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ From owner-mpls@UU.NET Thu Apr 19 11:09:01 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12349 for ; Thu, 19 Apr 2001 11:09:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllc15921; Thu, 19 Apr 2001 15:06:37 GMT Received: by mail-control.mail.uu.net id QQkllc07301 for mpls-outgoing; Thu, 19 Apr 2001 15:06:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllc06111 for ; Thu, 19 Apr 2001 15:05:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkllc16953 for ; Thu, 19 Apr 2001 15:05:32 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkllc15117 for ; Thu, 19 Apr 2001 15:05:32 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15370 for ; Thu, 19 Apr 2001 11:05:30 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16493 for ; Thu, 19 Apr 2001 11:05:32 -0400 (EDT) Message-ID: <3ADEFEC2.739EE8B@marconi.com> Date: Thu, 19 Apr 2001 11:05:38 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? References: <15065.18204.355287.636244@lohi.eng.telia.fi> <200104181857.OAA02487@erosen-sun.cisco.com> <15070.19966.401856.384943@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 Heinanen wrote: >> >> How would you get the LSPs to be setup "automatically between all >> your edge routers" without having any L3 routing information in >> the core? > > i'm not an ldp expert, but i assume that using the du mode, each > egress router can advertise an lsp to itself to all its neighbors > and so on. thus eventually every router in the system would have a > path to every egress router. this assumes that each router adds > itself to the advertisement in order to cut the loops. The problem with this isn't loop detection. LDP has two mechanisms for this (the hop-count and path-vector TLVs). The problem is that in some topologies, it will be possible (and even likely) that you'll receive the labels same FEC on multiple interfaces. The RFC states that the one you use must be the one that your local routing table says came from the next-hop to that FEC. You can't use any LDP-based metrics to determine this, because topologies can change over time, and label mappings are not periodically refreshed. If the shortest path to a FEC changes, LDP will have to start using the interface and label for the new next-hop. The IGP will know when this happens, LDP will not. -- David From owner-mpls@UU.NET Thu Apr 19 11:13:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12472 for ; Thu, 19 Apr 2001 11:13:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllc23460; Thu, 19 Apr 2001 15:10:21 GMT Received: by mail-control.mail.uu.net id QQkllc09160 for mpls-outgoing; Thu, 19 Apr 2001 15:09:42 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllc09109 for ; Thu, 19 Apr 2001 15:09:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkllc22352 for ; Thu, 19 Apr 2001 15:07:51 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkllc16270 for ; Thu, 19 Apr 2001 15:07:51 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA16761 for mpls@uu.net; Thu, 19 Apr 2001 11:07:50 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllc07368 for ; Thu, 19 Apr 2001 15:06:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllc17781 for ; Thu, 19 Apr 2001 15:05:53 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkllc19060 for ; Thu, 19 Apr 2001 15:05:53 GMT Received: from telescope.cisco.com ([161.44.128.68]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA17594; Thu, 19 Apr 2001 09:18:17 -0400 (EDT) Received: from localhost (rhthomas@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA07239; Thu, 19 Apr 2001 09:18:16 -0400 (EDT) Message-Id: <200104191318.JAA07239@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: rhthomas owned process doing -bs To: chetan.kumar@wipro.com cc: mpls@UU.NET Subject: Re: Label Aborting.. In-reply-to: Your message of "Thu, 19 Apr 2001 10:59:28 +0530." Date: Thu, 19 Apr 2001 09:18:16 -0400 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Chetan, > Hi, > I was looking thro' the rfc 3036. > > At section 3.5.10 (page 73) it is mentioned > > If an LSR receives a Label Abort Request Message after it has > responded to the Label Request in question with a Label Mapping > message or a Notification message, it ignores the abort request. > > And in thge Appendix at Page 106 it is mentioned. > > LAbR.6 Generate Event: Received Label Release Message for FEC > from MsgSource. (See Note 2.) > Goto LAbR.11. > > > I feel that we have to follow what is mentioned in the section 3.5.10, > since it makes sense for the upstream(MsgSource) to release the Label > explicitly based on its retention mode. Let me know how do U think ?? > > > Thanks > Chetan S LAbR.6 handles the following situation: MsgSource ------ LSR ------ R ... where: - LSR has received a label mapping for FEC from R; - LSR has not yet sent a label mapping for FEC to MsgSource; In this case LSR may need to release the label mapping it received from R. So far as LSR is concerned this situation is identical to one where it had sent a label mapping for FEC to MsgSource and subsequently received a label release for FEC from MsgSource. Therefore, this situation can be handled by LSR by behaving as if it has received a label release for FEC from MsgSource. Bob From owner-mpls@UU.NET Thu Apr 19 11:30:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12749 for ; Thu, 19 Apr 2001 11:30:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklld24348; Thu, 19 Apr 2001 15:27:06 GMT Received: by mail-control.mail.uu.net id QQklld11100 for mpls-outgoing; Thu, 19 Apr 2001 15:26:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklld11093 for ; Thu, 19 Apr 2001 15:26:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklld01181 for ; Thu, 19 Apr 2001 15:24:54 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklld23404 for ; Thu, 19 Apr 2001 15:24:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA19743 for mpls@uu.net; Thu, 19 Apr 2001 11:24:54 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklld10525 for ; Thu, 19 Apr 2001 15:20:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklld01880 for ; Thu, 19 Apr 2001 15:19:51 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQklld21508 for ; Thu, 19 Apr 2001 15:19:50 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA19618; Thu, 19 Apr 2001 11:17:47 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-206.cisco.com [161.44.134.206]) by bucket.cisco.com (Mirapoint) with ESMTP id AAR04608; Thu, 19 Apr 2001 11:18:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20010419111040.01eadcd0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Apr 2001 11:20:20 -0400 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: MPLS-TC-MIB Cc: swallow@cisco.com, "Wijnen, Bert (Bert)" , Mike MacFaden , cheenu Srinivasan , arun@force10networks.com, , hans@ipunplugged.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi all, As you may know, the MPLS-LSR, MPLS-LDP and MPLS-TE MIBs are currently under IESG review. One of the things which has resulted from the initial review of the MIBs is that the IESG requested that we pull out all of the common TCs from the MIBs and put them into a new draft. The reasoning was that there were several overlapping TCs that should be resolved. Furthermore, the MIBs (and future ones) should import these TCs from a common place to make the common TCs more uniform. The result now is that MIBs (and future ones like the FTN MIB) will hereby import the common TCs from the MPLS-TC-MIB. When the new versions of the MIBs currently under review are published and put under last call, the MPLS-TC-MIB will also undergo a last-call at that time. Please take a close look at the TC and provide us with your comments. The TC will appear soon on the MPLS WG's web page as: draft-ietf-mpls-tc-mib-00.txt. --Tom From owner-mpls@UU.NET Thu Apr 19 11:38:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12960 for ; Thu, 19 Apr 2001 11:38:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklle29467; Thu, 19 Apr 2001 15:35:36 GMT Received: by mail-control.mail.uu.net id QQklle11893 for mpls-outgoing; Thu, 19 Apr 2001 15:35:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklle11881 for ; Thu, 19 Apr 2001 15:34:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklle02751 for ; Thu, 19 Apr 2001 15:33:40 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklle27862 for ; Thu, 19 Apr 2001 15:33:40 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19089 for ; Thu, 19 Apr 2001 11:33:37 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27230 for ; Thu, 19 Apr 2001 11:33:41 -0400 (EDT) Message-ID: <3ADF055B.7CD961F3@marconi.com> Date: Thu, 19 Apr 2001 11:33:47 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Questions about merge-capability in LDP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nagabhushana Ramaswamy Nadig wrote: > > 1. Particularly the way you have mentioned of raising the internal > label requests for the FECs. How far does it make sense to wait for > a label request from a peer LSR and take the same as a trigger for > learning a new FEC. What I think is, as each of these LSR's would > be running a L3 routing protocol the moment I learn a new route at > L3 should be the trigger for me to make a new request to the next > hop peer (Ideally we will be populating our FTN table in this case > and ILM in the former). You should not assume that a switch will automatically use every prefix in its routing table as an LDP FEC. Depending on the topology, this could lead to excessive and unnecessary memory usage. Yes, the FEC might already be known at the time the unsolicited mapping arrives. Or it might not be. If a label-request/label-mapping message arrives with an unknown FEC that is in the IGP, it makes sense to use this as a "detected new FEC" trigger. > Depending upon this I would say the sequence of message flow > changes in your below discussions. Yes, but this doesn't change very much. I'm not trying to exhaustively decribe every possible combination of configurations. That would take several megabytes of documentation and would be of very little additional value. Take my examples as they are intended - as examples - and not as a complete enumeration of an implementation. > 2. Scenario 5. I really doubt such a configuration will work for > you. A non-merge capable LSR cofigured for Unsolicited distribution > (there by to also to receive unsolicited messages). In this case if > you receive an Unsolicited mapping msg, what will you do with that? > To which upstream peer are you going to distribute this? I think > because of this only the architecture has wisely avoided the DU > mode for non-merge LSRs. I don't see how it matters which upstream you distribute it to. If you have two, or twenty, or a million labels for a single FEC, they are all equivalent and should be interchangeable. The important thing is that the router needs more labels than it has. So it will use the ones it has and request any additional ones it may need. While the order may be of importance to an operator, it doesn't affect the protocol's operation. This can safely be a matter of local configuration. As for the architecutre, this is part of my question. Section 5.2.2 of RFC 3031 seems to state that unsolicited operation is illegal for non-merge-capable routers. But I'm not completely sure of that. I fail to see a reason for any such prohibition. As far as I can tell, label distribution works fine in this mode. -- David >> Scenario 5: >> >> [R1]---{R2]---[R3]---[R4]---[R5] >> >> No routers are merge-capable. Downstream-unsolicited label >> distribution. >> >> - R5 sends a Label-mapping to R4. >> - R4 realizes that it needs two labels - one to send upstream and >> one to install for unlabeled traffic. It uses one label and >> sends a Label-request message to R5 in order to get a second. >> - R5 sends a second Label-mapping to R5 >> - R4 sends a Label-mapping message to R3. >> - R3 realizes that it needs two labels - one to send upstream and >> one to install for unlabeled traffic. It uses one label and >> sends a Label-request message to R4 in order to get a second. >> - R4 sends a Label-request downstream to R5, since it now needs a >> third label (in order to satisfy the new request). >> - R5 sends a third Label-mapping to R4 >> - R4 sends a second Label-mapping to R3 >> - R3 sends a Label-mapping to R2 >> - R2 realizes that it needs two labels - one to send upstream and >> one to install for unlabeled traffic. It uses one label and >> sends a Label-request message to R3 in order to get a second. >> - R3 sends a Label-request downstream to R4, since it now needs a >> third label (in order to satisfy the new request). >> - R4 sends a Label-request downstream to R5, since it now needs a >> fourth label (in order to satisfy the new request) >> - R5 sends a fourth Label-mapping to R4 >> - R4 sends a third Label-mapping to R3 >> - R3 sends a second Label-mapping to R2 >> - R2 sends a Label-mapping to R1 >> >> The resulting LSPs look just like they would with on-demand >> distribution: >> >> ----------> >> -----------------> >> ------------------------> >> -------------------------------> >> [R1]---{R2]---[R3]---[R4]---[R5] From owner-mpls@UU.NET Thu Apr 19 11:42:54 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13054 for ; Thu, 19 Apr 2001 11:42:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklle12291; Thu, 19 Apr 2001 15:40:35 GMT Received: by mail-control.mail.uu.net id QQklle12652 for mpls-outgoing; Thu, 19 Apr 2001 15:40:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklle12630 for ; Thu, 19 Apr 2001 15:39:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklle09706 for ; Thu, 19 Apr 2001 15:36:09 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQklle29168 for ; Thu, 19 Apr 2001 15:36:08 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id E3E2A9400A; Thu, 19 Apr 2001 11:35:57 -0400 (EDT) Message-ID: <3ADF05DD.F483724B@sandburst.com> Date: Thu, 19 Apr 2001 11:35:57 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Ju, Yu" Cc: "Charlap, David" , mpls@UU.NET Subject: Re: Questions about merge-capability in LDP References: <39469E08BD83D411A3D900204840EC5537DC78@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yu, The ability to send a single label mapping with multiple FECs allows for an optimization that may make some sense if the predominant mode of operation is DU, ordered control for merging LSPs. There are those who think this optimization is of dubious value, even then. Use of this mechanism when a label is requested for a specific FEC makes even less sense. The implication is that an LSR waits for some period of time to accumulate FEC forwarding information where the forwarding for a set of FECs is coincidental. This requires upstream LSRs to merge traffic associated with all of the FECs for this downstream label. The interesting thing is that this behavior has heavier implications for downstream LSRs than for upstream LSRs since the upstream LSR - if it is merge capable - can simply send a label mapping to its own upstream peers with the same set of FECs (thus avoiding a need to perform the additional merge locally). The implications to dowstream LSRs are potentially much worse. At some downstream LSR, this LSP may need to split, so that routes to a proper subset of the set of FECs for this LSP can be observed. This would require termination of the existing LSP at that LSR and performing an IP header lookup to find the correct downstream LSP on which to further forward packets received on this LSP. If that is not acceptable to the LSR that would be required to do this, it will not issue a label mapping for this set of FECs (instead issuing multiple label mappings, possibly for each subset of FECs that requires different forwarding). This behavior would repeat until an LSR is reached that has no choice but to terminate the LSP and perform an IP lookup (this would be the domain egress). As you can see, this argues against using the multi-FEC approach with either DoD label distribution or independent control - since either would result in LSP setup thrashing. In the event that an LSR sends such a label mapping to an upstream peer that is not merge capable, the LSR receiving this label mapping would have no choice but to release (at least all but one of) the FECs associated with the label mapping and request additional labels for each of these FECs. Note that releasing a label releases the binding of that label to a FEC; the label may remain valid for other FECs. Following the procedures defined in LDP, this would result in distinct labels for each FEC. If this was being done for all such label mappings, the LSR that was attempting to be clever by using a single label for multiple FECs had best not be learning impaired or things could get pretty ugly. In the event that the upstream LSR is simply merge averse (for some reason and with respect to some LSPs), it can reduce the amount of merging it has to do by trying to push this set of FECs on its upstream peers. If that is not good enough (or doesn't work), it can do pretty much the same thing as the non-merge capable LSR behavior described in the paragraph above. But the case where you have non-merge capable LSRs using DU label distribution is self-cancelling because DU label distribution does not make a lot of sense when using conservative label retention. Since non-merging (and, to some extent at least, merge-averse) behavior makes the most sense in ATM LSRs, and ATM LSRs tend to use conservative label retention, the combination of non-merge capable LSRs using DU label distribution is a little off the beaten path. Hopefully, this makes some sense and clears things up. -- Eric Gray You wrote: > Eric, > > A label mapping message can have a FEC with more than one FEC elements. > However, a label request message can have only one FEC element. How should a > non-merge capable or merge-averse LSR handle this case? > > Thanks, > > Yu > > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Wednesday, April 18, 2001 4:56 PM > To: David Charlap > Cc: mpls@UU.NET > Subject: Re: Questions about merge-capability in LDP > > David, > > That's because - when the issue with handling merge capable > and non-merge capable label distributions came up during the last > call, the authors decided that the functionality required to handle > this was not specific to non-merging LSRs. It is applicable to any > LSP for which the upstream LSR chooses not to merge - whether > or not it is merge capable. > > Therefore, if you were expecting there to be a call-out - of the > sort "if the LSR is non-merge capable", then you will continue to > be disappointed. :-) > > If you look at the procedures for handling label mappings, you > will see that the notion of handling a requested label is dealt with > irrespective of the label distribution mode (DU/DoD). You will > also see that there is nothing in the procedures for handling a > label request that prevents an LSR from responding to one even > if the mode of operation is supposed to be DU. > > If I can request a label - and get a distinct one - whenever I > want one (unless and until the peer runs out), then I can handle > both the case where the peer is merge capable and the case > when the peer is simply merge-averse. > > -- > Eric Gray > > You wrote: > > > Eric Gray wrote: > > > > > > Near as I can tell, these are all right. However, LDP does > > > explicitly describe the handling of 'unsolicited label mappings' in > > > procedures for receiving label mappings in Appendix A. Look into > > > the behaviors with respect to getting a label mapping for which > > > there is no outstanding request - that's pretty much what it's all > > > about. > > > > Yes, but the pseudocode there doesn't talk about non-merge-capable > > routers requesting additional labels. The only mention of merge- > > capable vs. non-merge-capable in Appendix A is in the context of whether > > or not to include a Path Vector TLV. > > > > -- David From owner-mpls@UU.NET Thu Apr 19 12:06:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13555 for ; Thu, 19 Apr 2001 12:06:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllg19783; Thu, 19 Apr 2001 16:04:23 GMT Received: by mail-control.mail.uu.net id QQkllg24783 for mpls-outgoing; Thu, 19 Apr 2001 16:03:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkllg24705 for ; Thu, 19 Apr 2001 16:03:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkllg07151 for ; Thu, 19 Apr 2001 16:02:40 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkllg26501 for ; Thu, 19 Apr 2001 16:02:40 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA24704 for mpls@uu.net; Thu, 19 Apr 2001 12:02:40 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkllf14616 for ; Thu, 19 Apr 2001 15:58:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkllf13452 for ; Thu, 19 Apr 2001 15:56:34 GMT Received: from ns02.newbridge.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: ns02.newbridge.com [192.75.23.75]) id QQkllf18940 for ; Thu, 19 Apr 2001 15:56:33 GMT Received: (qmail 27562 invoked from network); 19 Apr 2001 15:54:42 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 19 Apr 2001 15:54:42 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Thu, 19 Apr 2001 11:54:33 -0400 Received: from alcatel.com ([138.120.51.119]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA43A3; Thu, 19 Apr 2001 11:54:32 -0400 Message-Id: <3ADF0A03.8BD22C57@alcatel.com> Date: Thu, 19 Apr 2001 11:53:39 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Geoff Bennett CC: "Donkin, Richard" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: <200104191511.QAA03690@salamander.eu.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > But as I understand it, the added value from IP VPNs either comes from > security (whether this is "isolational" in nature like an ATM or Frame > Relay VPN, or "truly secure" as in the case of an ecrypted ATM or IPSec VPN > is up to the user), or from "perceived service enhancement". The latter > could be via a CoS mechanism, which MPLS can potentially offer, or from a > hard QoS mechanism which can only be offered from... > > a: A TDM mechanism (like SONET/SDH, which is expensive). > b: A native ATM service. > c: An over-provisioned stat mux service (eg. IP), which is also expensive > in the long term. Geoff, I agree with your points above. However, I don't think there is anything stop MPLS implemented with a hard QoS mechanism like ATM has done. A good LSR with the necessary traffic management infrastructure (queuing and scheduling) can achieve the same level, if not better QoS. Cheers, Hansen From owner-mpls@UU.NET Thu Apr 19 12:14:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13747 for ; Thu, 19 Apr 2001 12:14:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllg00739; Thu, 19 Apr 2001 16:11:15 GMT Received: by mail-control.mail.uu.net id QQkllg03230 for mpls-outgoing; Thu, 19 Apr 2001 16:10:26 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllg03208 for ; Thu, 19 Apr 2001 16:10:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllg10876 for ; Thu, 19 Apr 2001 16:09:03 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkllg22844 for ; Thu, 19 Apr 2001 16:09:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA25584 for mpls@uu.net; Thu, 19 Apr 2001 12:09:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkllg02891 for ; Thu, 19 Apr 2001 16:08:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkllg14996 for ; Thu, 19 Apr 2001 16:07:36 GMT Received: from lohi.eng.telia.fi by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQkllg02826 for ; Thu, 19 Apr 2001 16:07:36 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3JG7p929351; Thu, 19 Apr 2001 19:07:51 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15071.3414.987617.351060@lohi.eng.telia.fi> Date: Thu, 19 Apr 2001 19:07:50 +0300 (EEST) To: Javier Antich Cc: erosen@cisco.com, sgong@gmu.edu, mpls@UU.NET Subject: RE: Does MPLS Require L3 Routing Table ? 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 Javier Antich writes: > Length may not be the best routing metric. There are other parameters that a > routing protocol would consider (metric configured for each interface, > bandwidth, ...). sure, nothing prevents adding those too in the "traceroute" if someone would like to use just ldp. the point was that mpls lsrs don't necessarily run a routing protocol and still the lsps can be set up. -- juha From owner-mpls@UU.NET Thu Apr 19 12:27:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13952 for ; Thu, 19 Apr 2001 12:27:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllh23438; Thu, 19 Apr 2001 16:24:47 GMT Received: by mail-control.mail.uu.net id QQkllh05257 for mpls-outgoing; Thu, 19 Apr 2001 16:24:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkllh05242 for ; Thu, 19 Apr 2001 16:24:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllh00981 for ; Thu, 19 Apr 2001 16:22:38 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQkllh18960 for ; Thu, 19 Apr 2001 16:22:35 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA06607; Thu, 19 Apr 2001 12:22:25 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200104191622.MAA06607@workhorse.fictitious.org> To: Juha Heinanen cc: curtis@avici.com, "Rajiv Papneja" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Does MPLS Require L3 Routing Table ? In-reply-to: Your message of "Thu, 19 Apr 2001 05:27:18 +0300." <15070.19718.716706.626667@lohi.eng.telia.fi> Date: Thu, 19 Apr 2001 12:22:25 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <15070.19718.716706.626667@lohi.eng.telia.fi>, Juha Heinanen writes: > Curtis Villamizar writes: > > > The ATM LIS idea (rfc1577), NHRP, MPOA, are all poor choices for > > scalability and reliability. So is the FR LIS. The reason an ATM LIS > > or FR LIS is unreliable is that in practice one or more VC in the net > > doesn't come up for some reason. When this occurs, a persistent black > > hole results. Persistent black holes are best avoided. > > curtis, > > fr pvcs have been used since 1991 to connect routers together. there > are thousands of vpns build that way. this is the first time i hear > about your black hole problem and i have been runnign these kind of vpns > for ten years now. if a pvc doesn't come up, then there is a single > point of failure link down somewhere and the situation is no different > from a leased line between routers being down. > > -- juha Since this came up on the "Does MPLS Require L3 Routing Table" I was assuming that you want to run without an IGP. The FR PVC must be configured as point to point or as NBMA for a partial mesh to exist. In NBMA, all of the PVC to the DR must come up or traffic to an address on the subnet with no PVC is blackholed rather than sent some other way if there is an alternate route. Misfeatures have been used in the past. Just because proxy-arp was used heavily in the late 1980s doesn't mean its a good replacement for an IGP either. Curtis From owner-mpls@UU.NET Thu Apr 19 12:29:37 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13993 for ; Thu, 19 Apr 2001 12:29:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllh20123; Thu, 19 Apr 2001 16:27:06 GMT Received: by mail-control.mail.uu.net id QQkllh05272 for mpls-outgoing; Thu, 19 Apr 2001 16:24:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkllh05256 for ; Thu, 19 Apr 2001 16:24:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkllh01070 for ; Thu, 19 Apr 2001 16:22:40 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkllh21340 for ; Thu, 19 Apr 2001 16:22:39 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA27288 for mpls@uu.net; Thu, 19 Apr 2001 12:22:38 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkllh04376 for ; Thu, 19 Apr 2001 16:18:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllh10013 for ; Thu, 19 Apr 2001 16:16:49 GMT Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQkllh09407 for ; Thu, 19 Apr 2001 16:16:48 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3JGH0L29370; Thu, 19 Apr 2001 19:17:00 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15071.3964.759117.255670@lohi.eng.telia.fi> Date: Thu, 19 Apr 2001 19:17:00 +0300 (EEST) To: erosen@cisco.com Cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <200104191442.KAA05457@erosen-sun.cisco.com> References: <15070.19966.401856.384943@lohi.eng.telia.fi> <200104191442.KAA05457@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: > An LSR receiving a Label Mapping message from a downstream LSR for a > Prefix or Host Address FEC Element should not use the label for > forwarding unless its routing table contains an entry that exactly > matches the FEC Element. > > So one can't really do things the way you suggest. "should not" is not the same as "must not". i was just trying to point out what CAN be done and not that it would be a good idea to do so. > Given a pre-existing LSP connecting two CEs, it might well make sense to > have a procedure for each to discover who is at the other end. The prior > question here would be whether there is real value in having these > pre-existing LSPs connecting the two CEs. there is a huge installed base of frame relay that is almost 100% based on the pvc paradigm. the fact is that operators don't like the idea of customers signaling dynamically frame relay svcs in their networks and the same will hold for mpls lsps. > I think what people have been objecting to is the suggestion (now apparently > disavowed) that such a procedure somehow eliminates the need to have L3 > routing in the core. That's what made it seems like there must be some > MPOA-like stuff hiding beneath the surface. the soft permanent lsps are setup using l3 routing protocol. there is no mpsl like stuff anywhere. frame pvcs connecting routers have been used years before mpoa appeared. -- juha From owner-mpls@UU.NET Thu Apr 19 12:45:05 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14235 for ; Thu, 19 Apr 2001 12:45:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklli14126; Thu, 19 Apr 2001 16:41:02 GMT Received: by mail-control.mail.uu.net id QQklli07003 for mpls-outgoing; Thu, 19 Apr 2001 16:40:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklli06986 for ; Thu, 19 Apr 2001 16:40:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklli03243 for ; Thu, 19 Apr 2001 16:40:04 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQklli15686 for ; Thu, 19 Apr 2001 16:40:03 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 JAA03521; Thu, 19 Apr 2001 09:40:06 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA05950; Thu, 19 Apr 2001 12:40:01 -0400 (EDT) Message-Id: <200104191640.MAA05950@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Juha Heinanen cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-reply-to: Your message of Thu, 19 Apr 2001 19:17:00 +0300. <15071.3964.759117.255670@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, 19 Apr 2001 12:40:01 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Juha> there is a huge installed base of frame relay that is almost 100% Juha> based on the pvc paradigm. the fact is that operators don't like the Juha> idea of customers signaling dynamically frame relay svcs in their Juha> networks and the same will hold for mpls lsps. I didn't mean to suggest that the SVC paradigm is better for CE-CE LSPs than the PVC paradigm; the question is whether MPLS as a CE-CE link layer is valuable. Of course, this is really far afield of the topic of this thread. From owner-mpls@UU.NET Thu Apr 19 13:05:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14474 for ; Thu, 19 Apr 2001 13:05:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllk07580; Thu, 19 Apr 2001 17:02:50 GMT Received: by mail-control.mail.uu.net id QQkllk13830 for mpls-outgoing; Thu, 19 Apr 2001 17:02:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkllk13654 for ; Thu, 19 Apr 2001 17:01:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkllk02208 for ; Thu, 19 Apr 2001 17:01:24 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkllk06085 for ; Thu, 19 Apr 2001 17:01:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA01501 for mpls@uu.net; Thu, 19 Apr 2001 13:01:23 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkllj09195 for ; Thu, 19 Apr 2001 16:57:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllj18241 for ; Thu, 19 Apr 2001 16:56:57 GMT Received: from mail.korea.ac.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: korea.ac.kr [163.152.1.251]) id QQkllj10041 for ; Thu, 19 Apr 2001 16:56:56 GMT Received: from mail-virus (smtp.korea.ac.kr [163.152.1.128]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id BAA121778; Fri, 20 Apr 2001 01:46:38 +0900 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3JGtoT10170; Thu, 19 Apr 2001 12:55:50 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-Id: <200104191454.PAA03433@salamander.eu.fore.com> X-Sender: gbennett@salamander.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Apr 2001 16:58:59 +0100 To: jshen@cad.zju.edu.cn From: Geoff Bennett Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? Cc: MP LS , mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <3ADD60A9.879AC43D@cad.zju.edu.cn> References: <200104180906.KAA21530@salamander.eu.fore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: archive/latest/1004 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk Actually Option 1 does, and will continue to happen in the real world. Apart from ATM's use as a Traffic Engineering plane in "conventional" IP networks, it is used in a number of other service architectures. The common factor for these services is that they provide high revenue to the Service Provider. Currently MPLS does not do this (actually this is unfair...MPLS may well provide high REVENUE, but it does not provide high EARNINGS). Note, that MPLS is beginning to offer "value-added IP services" such as VPNs, but it's not clear yet whether these services actually operate at a profit, or just at a lower loss than best effort (ie. Internet) IP services. For the near to mid-term future, the DSL market will ensure that bother the pure ATM and the SIN model will continue at the edge of the network. The DSL market is very dependent on local regulatory and market conditions, so I don't want to make specific comments, but in general the view is that ADSL specifically can generally demonstrate an ROI within 2 years, assuming the ADSL has an ATM network behind it in order to support high revenue voice services. Cheers, Geoff At 17:38 18/04/01 +0800, shen jing wrote: >> 1. Pure ATM. In this case the switch will operate UNI and NNI interfaces, >> and will run PNNI as its routing protocol (PNNI is both an IGP and EGP). >> UNI and PNNI signalling will happen on VCI 5. > >I don't think this will happen in real world , because MPLS integrate >IP routing and switching mechanism. As it uses ATM switch as transit stage >solution, it has to use SIN style equipments. While, it will go to pure MPLS in >future. If PNNI is used as routing procedure, it should be the situation where >ATM switch path is used as tunnel for MPLS. > > >> >> 2. Pure MPLS. In this mode, there is no ATM signalling, and no PNNI. >> MPLS routing and signalling (OSPF, ISIS, CR-LDP, RSVP-TE, etc.) will pass >> over VCI 32 (note, please check the latest draft for the actual VCI number, >> it's a while since I read this info). >> >> 3. Ships in the Night (SIN). In this case, both ATM and MPLS Control >> Planes operate simultaneously. ATM signalling happens on VCI 5, and MPLS >> signalling on VCI 32. VCs that are set up as a result of signalling are >> "owned" by one or other of these control planes. SIN would allow an >> operator to continue to run high revenue voice services (and maybe existing >> Frame Relay or native ATM services...they make money too) over the ATM >> "character" of the switch. They can then run the loss-making Internet >> services over the MPLS character. >> >> I think there are ideas floating around about a more integrated control >> plane for ATM/MPLS switches based on PNNI, but I don't think these have >> made it to draft as yet. >> >> Cheers, >> Geoff >> >> At 10:02 18/04/01 +0200, MP LS wrote: >> >Hello all, >> > >> >I have some questions becasue something is verry strange to me. >> >I just assumed that ATM-LSRS used an IP routing protocol (IGP) just for >> >finding the topology of the network. >> > >> >But last i read an doccument and there they described that When you change >> >an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. Can >> >anyone make this clear for me?? >> > >> >Thanks a lot. >> > >> >Greetings, >> > >> >Niels Sitters. >> > >> > >> >_________________________________________________________________________ >> >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. >> > >> >------- >> >The MPLS-OPS Mailing List >> >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >> >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >> > >> ================================================================ >> Geoff Bennett Tel: (33) 497 21 43 62 >> Director of Technology, OCTO Fax: (33) 497 21 43 50 >> Marconi >> Gaia - Bat. E email: geoff.bennett@marconi.com >> BP 123 >> 06903 SOPHIA ANTIPOLIS >> FRANCE >> ================================================================ > ================================================================ Geoff Bennett Tel: (33) 497 21 43 62 Director of Technology, OCTO Fax: (33) 497 21 43 50 Marconi Gaia - Bat. E email: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Thu Apr 19 13:07:14 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14515 for ; Thu, 19 Apr 2001 13:07:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllk09622; Thu, 19 Apr 2001 17:04:36 GMT Received: by mail-control.mail.uu.net id QQkllk15782 for mpls-outgoing; Thu, 19 Apr 2001 17:04:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllk15400 for ; Thu, 19 Apr 2001 17:03:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllk18383 for ; Thu, 19 Apr 2001 17:03:32 GMT Received: from WATERTOWN.litchfieldcomm.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.252.190.60]) id QQkllk18897 for ; Thu, 19 Apr 2001 17:03:31 GMT Subject: Static LSPs (Does MPLS Require L3 Routing Table ?) Date: Thu, 19 Apr 2001 13:03:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <0E2DFCE7E586904DA0F583CB5EAD73CC031322@WATERTOWN.litchfieldcomm.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: Does MPLS Require L3 Routing Table ? Thread-Index: AcDI7b0wOfo38E1MS8mACHbHGErAMgAAf9sw From: "Dave Danenberg" To: "Juha Heinanen" Cc: , , , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA14515 Juha, 2 weeks back on another MPLS email thread, folks were discussing how popular statically configured LSPs (MPLS PVCs) might be. This was with respect to detection of data-plane faults if there is no MPLS control-plane. Within the email thread, folks said that although the MPLS equipment will support static LSPs, they were not aware of plans for static LSP deployments. It seems from your response below, you believe MPLS PVCs will be popular because operators will not want customers to apply signaling to their networks. Do I understand you correctly? If so, what mechanisms would you use to detect data-plane faults within networks configured with MPLS PVCs? --Dave -----Original Message----- From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi] Sent: Thursday, April 19, 2001 12:17 PM To: erosen@cisco.com Cc: sgong@gmu.edu; mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? Eric Rosen writes: > An LSR receiving a Label Mapping message from a downstream LSR for a > Prefix or Host Address FEC Element should not use the label for > forwarding unless its routing table contains an entry that exactly > matches the FEC Element. > > So one can't really do things the way you suggest. "should not" is not the same as "must not". i was just trying to point out what CAN be done and not that it would be a good idea to do so. > Given a pre-existing LSP connecting two CEs, it might well make sense to > have a procedure for each to discover who is at the other end. The prior > question here would be whether there is real value in having these > pre-existing LSPs connecting the two CEs. there is a huge installed base of frame relay that is almost 100% based on the pvc paradigm. the fact is that operators don't like the idea of customers signaling dynamically frame relay svcs in their networks and the same will hold for mpls lsps. > I think what people have been objecting to is the suggestion (now apparently > disavowed) that such a procedure somehow eliminates the need to have L3 > routing in the core. That's what made it seems like there must be some > MPOA-like stuff hiding beneath the surface. the soft permanent lsps are setup using l3 routing protocol. there is no mpsl like stuff anywhere. frame pvcs connecting routers have been used years before mpoa appeared. -- juha From owner-mpls@UU.NET Thu Apr 19 13:14:54 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14631 for ; Thu, 19 Apr 2001 13:14:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllk18088; Thu, 19 Apr 2001 17:12:22 GMT Received: by mail-control.mail.uu.net id QQkllk28168 for mpls-outgoing; Thu, 19 Apr 2001 17:11:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkllk28157 for ; Thu, 19 Apr 2001 17:11:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkllk29109 for ; Thu, 19 Apr 2001 17:11:13 GMT From: djiang1@lucent.com Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQkllk16855 for ; Thu, 19 Apr 2001 17:11:13 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3JHBC418264 for ; Thu, 19 Apr 2001 13:11:12 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3JHBCm18246 for ; Thu, 19 Apr 2001 13:11:12 -0400 (EDT) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA14973; Thu, 19 Apr 2001 13:11:10 -0400 (EDT) Subject: Resource reservation during RSVP Path message forwarding? To: mpls@UU.NET Date: Thu, 19 Apr 2001 13:05:35 -0400 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 04/19/2001 13:05:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I have a question regarding when the proper time is to start resource reservation on a transit LSR (not LER). Assume we have R1(LER) --> R2 (LSR) --> R3(LSR) --> R4(LER). R1 gets a signal from, say, user configuration that there is a need to set up a LSP. R1 sends a RSVP Path message to R2. Would you think R2 should try to reserve resource at this time and send another RSVP Path message down to R3, or you think R2 should not reserve any resource until R2 gets a RSVP Resv message from R3? Thanks, Jane D. Jiang From owner-mpls@UU.NET Thu Apr 19 13:48:57 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15188 for ; Thu, 19 Apr 2001 13:48:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklln16562; Thu, 19 Apr 2001 17:45:55 GMT Received: by mail-control.mail.uu.net id QQklln02278 for mpls-outgoing; Thu, 19 Apr 2001 17:45:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklln02111 for ; Thu, 19 Apr 2001 17:45:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllm22970 for ; Thu, 19 Apr 2001 17:44:15 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkllm04522 for ; Thu, 19 Apr 2001 17:44:15 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02053 for ; Thu, 19 Apr 2001 13:44:12 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA01698 for ; Thu, 19 Apr 2001 13:44:16 -0400 (EDT) Message-ID: <3ADF23F8.6055B65B@marconi.com> Date: Thu, 19 Apr 2001 13:44:24 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: <200104191511.QAA03690@salamander.eu.fore.com> <3ADF0A03.8BD22C57@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I agree with your points above. However, I don't think there is > anything stop MPLS implemented with a hard QoS mechanism like ATM > has done. A good LSR with the necessary traffic management > infrastructure (queuing and scheduling) can achieve the same > level, if not better QoS. One clear advantage of ATM is that ATM provides more parameters for tuning QoS than RSVP or CR-LDP do. None of the current MPLS signaling protocols provide a way to specify delay characteristics as part of QoS. ATM's QoS allows signaling of delay and delay variation. RSVP's ADSPEC object allows the collection of delay information, but there is no way to request that the network try to establish an LSP that conforms to particular delay characteristics. Delay information is important for circuit-emulation and for real-time streaming applications (like voice/video). Of course, delay factors are much less of a problem today (with extremely fast backplanes and OC-x interfaces) than they were in the recent past (with slower backplanes and DS-x interfaces), but I don't think we're yet at the point where they can be completely ignored. I think there are still some applications where delay and delay variation are important even on today's hardware. Of course, there's no reason why delay characteristics couldn't be added to either RSVP or CR-LDP in the future. -- David From owner-mpls@UU.NET Thu Apr 19 14:19:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15690 for ; Thu, 19 Apr 2001 14:19:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllp18042; Thu, 19 Apr 2001 18:16:55 GMT Received: by mail-control.mail.uu.net id QQkllp22923 for mpls-outgoing; Thu, 19 Apr 2001 18:15:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkllo22714 for ; Thu, 19 Apr 2001 18:14:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllo14809 for ; Thu, 19 Apr 2001 18:14:21 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkllo24821 for ; Thu, 19 Apr 2001 18:14:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA09361 for mpls@uu.net; Thu, 19 Apr 2001 14:14:20 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllo22367 for ; Thu, 19 Apr 2001 18:13:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllo01339 for ; Thu, 19 Apr 2001 18:13:00 GMT Received: from mail.korea.ac.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: korea.ac.kr [163.152.1.251]) id QQkllo22807 for ; Thu, 19 Apr 2001 18:12:48 GMT Received: from mail-virus (smtp.korea.ac.kr [163.152.1.128]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id DAA90822; Fri, 20 Apr 2001 03:01:57 +0900 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3JIAQM28704; Thu, 19 Apr 2001 14:10:26 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-Id: <3ADF0A03.8BD22C57@alcatel.com> Date: Thu, 19 Apr 2001 11:53:39 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Geoff Bennett CC: "Donkin, Richard" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: <200104191511.QAA03690@salamander.eu.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Mailing-List: archive/latest/1006 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit > But as I understand it, the added value from IP VPNs either comes from > security (whether this is "isolational" in nature like an ATM or Frame > Relay VPN, or "truly secure" as in the case of an ecrypted ATM or IPSec VPN > is up to the user), or from "perceived service enhancement". The latter > could be via a CoS mechanism, which MPLS can potentially offer, or from a > hard QoS mechanism which can only be offered from... > > a: A TDM mechanism (like SONET/SDH, which is expensive). > b: A native ATM service. > c: An over-provisioned stat mux service (eg. IP), which is also expensive > in the long term. Geoff, I agree with your points above. However, I don't think there is anything stop MPLS implemented with a hard QoS mechanism like ATM has done. A good LSR with the necessary traffic management infrastructure (queuing and scheduling) can achieve the same level, if not better QoS. Cheers, Hansen ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Thu Apr 19 14:24:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15759 for ; Thu, 19 Apr 2001 14:24:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllp04876; Thu, 19 Apr 2001 18:21:56 GMT Received: by mail-control.mail.uu.net id QQkllp23684 for mpls-outgoing; Thu, 19 Apr 2001 18:21:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkllp23659 for ; Thu, 19 Apr 2001 18:21:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllp28540 for ; Thu, 19 Apr 2001 18:20:38 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkllp23570 for ; Thu, 19 Apr 2001 18:20:37 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA05749; Thu, 19 Apr 2001 14:20:34 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11343; Thu, 19 Apr 2001 14:20:37 -0400 (EDT) Message-ID: <3ADF2C7E.8AD1050F@marconi.com> Date: Thu, 19 Apr 2001 14:20:46 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: djiang1@lucent.com CC: mpls@UU.NET Subject: Re: Resource reservation during RSVP Path message forwarding? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit djiang1@lucent.com wrote: > > I have a question regarding when the proper time is to start resource > reservation on a transit LSR (not LER). > > Assume we have R1(LER) --> R2 (LSR) --> R3(LSR) --> R4(LER). R1 > gets a signal from, say, user configuration that there is a need to > set up a LSP. R1 sends a RSVP Path message to R2. Would you think > R2 should try to reserve resource at this time and send another RSVP > Path message down to R3, or you think R2 should not reserve any > resource until R2 gets a RSVP Resv message from R3? This is an implementation detail. There are advantages to both ways. REASONS FOR RESERVING RESOURCES DURING PATH PROCESSING 1: There's no need to propagate a Path message all the way to an egress router if you know that you're not going to be able to satisfy the reservation when the Resv returns. Depending on the number of hops to the egress, this might be significant overhead. 2: Actually making reservations on the backplane and involved line-cards may be time-consuming. If the setup can take place in the background, and complete before the Resv arrives, significantly faster LSP setup times may be achieved. REASONS FOR NOT RESERVING RESOURCES UNTIL RESV PROCESSING 1: There will be no data flow along the LSP until the Resv message arrives, but the resources will be reserved. These resources won't be available for other purposes (perhaps other LSPs or non-MPLS circuits.) 2: If a downstream router can't make its reservation, you will have to tear your reservation. During the time between creating and tearing the reservation, the resources were unavailable for other LSPs, and may have caused the other LSP's setup to fail. 3: RSVP doesn't require the resources requested in the Resv message's FLOWSPEC to match the resources specified in the Path message's TSPEC. RSVP will allow any reservation that is less than or equal to the requested reservation. Policy, local configuration, or some kind of application-awareness may allow an egress router to reduce a reservation prior to generating a Resv message. If the Resv QoS doesn't match the Path QoS, then the router will have to reduce its already-reserved reservation when the Resv arrives, or else resources will be wasted. The act of reducing a reservation may be just as time-consuming (perhaps even more so) than simply waiting for the Resv before making any reservations. Which mechanism makes more sense for your code will be a function of your hardware and software architecture. -- David From owner-mpls@UU.NET Thu Apr 19 14:28:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15812 for ; Thu, 19 Apr 2001 14:28:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllp00408; Thu, 19 Apr 2001 18:25:24 GMT Received: by mail-control.mail.uu.net id QQkllp24000 for mpls-outgoing; Thu, 19 Apr 2001 18:24:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllp23928 for ; Thu, 19 Apr 2001 18:24:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkllp24350 for ; Thu, 19 Apr 2001 18:23:33 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQkllp28230 for ; Thu, 19 Apr 2001 18:23:32 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3JINWG03111 for ; Thu, 19 Apr 2001 14:23:32 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3JINVD03105; Thu, 19 Apr 2001 14:23:31 -0400 (EDT) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA26452; Thu, 19 Apr 2001 14:23:30 -0400 (EDT) To: David Charlap Cc: mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Aris Kyriakopoulos" Date: Thu, 19 Apr 2001 14:17:52 -0400 X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 04/19/2001 14:17:56, Serialize complete at 04/19/2001 14:17:56 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi David, No argument about the fact that the ATM QoS model has more features and is more mature than the IP QoS model. However, in order for non-ATM applications (specifically IP) to take advantage of ATM QoS, you need to be able to translate the IP QoS requirements into ATM signalling. As far as I am aware, there is no way you can do this in a dynamically-routed IP network. Sure, you can map static IP routes to ATM (S)PVCs. Even then, what mechanisms are there to distinguish between different IP flows over the same route (e.g. by ToS, TCP/UDP ports)? Because to ATM, all IP packets are created equal, right? To me, this is one of the good reasons to use MPLS: using ATM switching hardware to provide IP QoS. Even though the IP QoS model is not as rich as ATM's, at least ATM LSRs provide some sort of QoS mechanism for IP that CLIP/MPOA simply do not. I agree that RSVP and CR-LDP probably need to provide better delay information than they currently do in order to support delay-sensitive applications. That is the key, though; these metrics need to be added to IP QoS. Or maybe the IP QoS model needs to be extended to have 1-to-1 mapping with ATM QoS. At least on ATM LSRs. Regards, Aris David Charlap Sent by: owner-mpls@UU.NET 04/19/2001 01:44 PM To: mpls@UU.NET cc: Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? > I agree with your points above. However, I don't think there is > anything stop MPLS implemented with a hard QoS mechanism like ATM > has done. A good LSR with the necessary traffic management > infrastructure (queuing and scheduling) can achieve the same > level, if not better QoS. One clear advantage of ATM is that ATM provides more parameters for tuning QoS than RSVP or CR-LDP do. None of the current MPLS signaling protocols provide a way to specify delay characteristics as part of QoS. ATM's QoS allows signaling of delay and delay variation. RSVP's ADSPEC object allows the collection of delay information, but there is no way to request that the network try to establish an LSP that conforms to particular delay characteristics. Delay information is important for circuit-emulation and for real-time streaming applications (like voice/video). Of course, delay factors are much less of a problem today (with extremely fast backplanes and OC-x interfaces) than they were in the recent past (with slower backplanes and DS-x interfaces), but I don't think we're yet at the point where they can be completely ignored. I think there are still some applications where delay and delay variation are important even on today's hardware. Of course, there's no reason why delay characteristics couldn't be added to either RSVP or CR-LDP in the future. -- David From owner-mpls@UU.NET Thu Apr 19 14:38:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16054 for ; Thu, 19 Apr 2001 14:38:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllq20016; Thu, 19 Apr 2001 18:36:15 GMT Received: by mail-control.mail.uu.net id QQkllq25176 for mpls-outgoing; Thu, 19 Apr 2001 18:35:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkllq25164 for ; Thu, 19 Apr 2001 18:35:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkllq01647 for ; Thu, 19 Apr 2001 18:34:36 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkllq07002 for ; Thu, 19 Apr 2001 18:34:35 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 9391294006; Thu, 19 Apr 2001 14:34:35 -0400 (EDT) Message-ID: <3ADF2FBA.FBF5B7B3@sandburst.com> Date: Thu, 19 Apr 2001 14:34:34 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: <200104191511.QAA03690@salamander.eu.fore.com> <3ADF0A03.8BD22C57@alcatel.com> <3ADF23F8.6055B65B@marconi.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David,

    I believe the IP model for control of delay variation
is to control delay.  This approach has its own problems,
but there are complexities associated with having distinct
knobs for delay and delay variation and these complexities
will probably get in the way of building an implementation
that will work this way with IP and still be reasonably
scalable.  Also, there's a well known 'tax' associated with
the approach that ATM uses to control delay variation.  :-)

--
Eric Gray

You wrote:

> I agree with your points above. However, I don't think there is
> anything stop MPLS implemented with a hard QoS mechanism like ATM
> has done. A good LSR with the necessary traffic management
> infrastructure (queuing and scheduling) can achieve the same
> level, if not better QoS.

One clear advantage of ATM is that ATM provides more parameters for
tuning QoS than RSVP or CR-LDP do.

None of the current MPLS signaling protocols provide a way to specify
delay characteristics as part of QoS.  ATM's QoS allows signaling of
delay and delay variation.  RSVP's ADSPEC object allows the collection
of delay information, but there is no way to request that the network
try to establish an LSP that conforms to particular delay
characteristics.

Delay information is important for circuit-emulation and for real-time
streaming applications (like voice/video).

Of course, delay factors are much less of a problem today (with
extremely fast backplanes and OC-x interfaces) than they were in the
recent past (with slower backplanes and DS-x interfaces), but I don't
think we're yet at the point where they can be completely ignored.

I think there are still some applications where delay and delay
variation are important even on today's hardware.

Of course, there's no reason why delay characteristics couldn't be added
to either RSVP or CR-LDP in the future.

-- David

From owner-mpls@UU.NET Thu Apr 19 14:41:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16113 for ; Thu, 19 Apr 2001 14:41:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllq22777; Thu, 19 Apr 2001 18:37:24 GMT Received: by mail-control.mail.uu.net id QQkllq25185 for mpls-outgoing; Thu, 19 Apr 2001 18:35:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkllq25166 for ; Thu, 19 Apr 2001 18:35:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllq01423 for ; Thu, 19 Apr 2001 18:34:30 GMT Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQkllq22547 for ; Thu, 19 Apr 2001 18:34:30 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3JIYNR25557; Thu, 19 Apr 2001 14:34:23 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; THU, 19 Apr 2001 14:30:02 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id <22V70KDW>; Thu, 19 Apr 2001 14:30:01 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E56CB7F0F@newman.tenornet.com> From: "Kavi, Prabhu" To: "'Geoff Bennett'" , "Donkin, Richard" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Thu, 19 Apr 2001 14:29:55 -0400 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 Geoff, Your generalization about "loss making Internet Services" is foolish. Several years ago, somebody forgot to tell UUNET that they were selling loss making Internet services, and they hit break-even during a period of explosive growth (very hard to do). I think it is fair to say they are quite profitable for Worldcom today. I also know for a fact that several other large ISPs are profitable as well, but they are part of larger organizations that do not publicly break out the P+L of each division. No doubt, ISPs could do better by offering a range of services, some of which promise higher service quality. But if a service provider is going to start providing higher revenue services today, why in the world would they want to do it over ATM switches? Prabhu > -----Original Message----- > From: Geoff Bennett [mailto:geoff.bennett@marconi.com] > Sent: Thursday, April 19, 2001 12:20 PM > To: Donkin, Richard; MP LS; mpls-ops@mplsrc.com; mpls@UU.NET > Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? > > > Hi Richard, > Please read my post carefully. Internet services are > generally intended to > mean "best effort". In contrast VPN services are supposed to > carry some > kind of added value. In other words, I fully accept that IP > VPNs should > make more money than a basic Internet service. > > But as I understand it, the added value from IP VPNs either comes from > security (whether this is "isolational" in nature like an ATM or Frame > Relay VPN, or "truly secure" as in the case of an ecrypted > ATM or IPSec VPN > is up to the user), or from "perceived service enhancement". > The latter > could be via a CoS mechanism, which MPLS can potentially > offer, or from a > hard QoS mechanism which can only be offered from... > > a: A TDM mechanism (like SONET/SDH, which is expensive). > b: A native ATM service. > c: An over-provisioned stat mux service (eg. IP), which is > also expensive > in the long term. > > I know that Orchestream's core business is based on the provision of > services over an MPLS core, so this may be akin to asking a > barber if he > thinks I need a haircut, but is there any evidence that IP > VPN services are > "truly profitable" (as opposed to "press release" > profitable)? the problem > is that asking most SPs this question will result in "sorry, > this is very > confidential information" responses. > > I'm not trying to bang a vendor drum here, I'm truly > interested because of > the fact that about a dozen European SPs are technically bankrupt from > being too dependent on IP services ever making money. > > Cheers, > Geoff > > > At 19:38 18/04/01 +0100, Donkin, Richard wrote: > > > > > >> -----Original Message----- > >> From: Geoff Bennett [mailto:geoff.bennett@marconi.com] > >> Sent: 18 April 2001 11:15 > > >> To: MP LS; mpls-ops@mplsrc.com; mpls@uu.net > >> Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? > >> > >> > >> Hi Niels, > >> > >> There may be some confusion arising depending on how you > >> configure the ATM > >> switch. In effect there are three modes of operation for > >> this device... > >> > >> 3. Ships in the Night (SIN). In this case, both ATM and > MPLS Control > >> Planes operate simultaneously. ATM signalling happens on VCI > >> 5, and MPLS > >> signalling on VCI 32. VCs that are set up as a result of > >> signalling are > >> "owned" by one or other of these control planes. SIN > would allow an > >> operator to continue to run high revenue voice services (and > >> maybe existing > >> Frame Relay or native ATM services...they make money too) > >> over the ATM > >> "character" of the switch. They can then run the > loss-making Internet > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> services over the MPLS character. > >^^^^^^^^^^ > > > >Very amusing... I'm sure this was just flame-bait, but first > of all, MPLS > >supports IP services, not just Internet traffic, and you can > of course run > >highly profitable IP VPN services over MPLS. > > > >Ultimately, ATM/FR services (as seen by the customer) may > well be carried > >over an MPLS core, particularly as MPLS becomes one of the > key signalling > >mechanisms for all-optical core networks, but since much of > the traffic > >running over ATM/FR is actually IP, it may be simpler to > deliver IP VPNs > >directly to the customer premises. > > > >> Cheers, > >> Geoff > > > >Richard Donkin > >T: +44 (0)20 7348 1507 > >Orchestream > >Avon House, Kensington Village, Avonmore Road, London W14 8TS > >T: +44 (0)20 7348 1500 F: +44 (0)20 7348 1501 > >www.orchestream.com > > > > > >-- > >This communication contains confidential information > intended solely for > the use of the individual/s and/or entity or entities to whom it was > intended to be addressed. If you are not the intended > recipient, be aware > that any disclosure, copying, distribution, or use of the > contents of this > transmission is prohibited. If you have received this > communication in > error, please contact the sender immediately, delete this > communication > from your system, and do not disclose its contents to any > third party, or > use its contents. Any opinions expressed are solely those of > the author > and do not necessarily represent those of Orchestream Ltd or > its group of > companies unless otherwise specifically stated. > > > >------- > >The MPLS-OPS Mailing List > >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > > ================================================================ > Geoff Bennett > Tel: (33) 497 21 43 62 > Director of Technology, OCTO > Fax: (33) 497 21 43 50 > Marconi > Gaia - Bat. E > email: geoff.bennett@marconi.com > BP 123 > 06903 SOPHIA ANTIPOLIS > FRANCE > ================================================================ > > From owner-mpls@UU.NET Thu Apr 19 14:44:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16178 for ; Thu, 19 Apr 2001 14:44:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllq03000; Thu, 19 Apr 2001 18:42:24 GMT Received: by mail-control.mail.uu.net id QQkllq26211 for mpls-outgoing; Thu, 19 Apr 2001 18:41:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkllq26185 for ; Thu, 19 Apr 2001 18:41:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllq14047 for ; Thu, 19 Apr 2001 18:39:49 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkllq27763 for ; Thu, 19 Apr 2001 18:39:49 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08024; Thu, 19 Apr 2001 14:39:40 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17192; Thu, 19 Apr 2001 14:39:44 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Apr 2001 14:39:41 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55309575@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "Charlap, David" , mpls@UU.NET, "Rosen, Brian" Cc: "'mpls-ops@mplsrc.com'" Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Thu, 19 Apr 2001 14:39:41 -0400 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 David Please look at the Voice over MPLS framework document: http://www.alternic.org/drafts/drafts-k-l/draft-kankkunen-vompls-fw-01.pdf Presently so many VoIP working groups (MMUSIC/SIP/IPTel etc) have there own mechanism for end-to-end delay characteristics but at the applications level. But in the above draft they made some progress to Voice Traffic Engineering using MPLS and Dynamic traffic management. Section 5 is left unanswered about Requirements for MPLS signaling (LDP/CR-LDP and RSVP-TE) Unfortunately I didn't see any progress after in VoMPLS. -Venkata Naidu > > I agree with your points above. However, I don't think there is > > anything stop MPLS implemented with a hard QoS mechanism like ATM > > has done. A good LSR with the necessary traffic management > > infrastructure (queuing and scheduling) can achieve the same > > level, if not better QoS. > > One clear advantage of ATM is that ATM provides more parameters for > tuning QoS than RSVP or CR-LDP do. > > None of the current MPLS signaling protocols provide a way to specify > delay characteristics as part of QoS. ATM's QoS allows signaling of > delay and delay variation. RSVP's ADSPEC object allows the collection > of delay information, but there is no way to request that the network > try to establish an LSP that conforms to particular delay > characteristics. > > Delay information is important for circuit-emulation and for real-time > streaming applications (like voice/video). > > Of course, delay factors are much less of a problem today (with > extremely fast backplanes and OC-x interfaces) than they were in the > recent past (with slower backplanes and DS-x interfaces), but I don't > think we're yet at the point where they can be completely ignored. > > I think there are still some applications where delay and delay > variation are important even on today's hardware. > > Of course, there's no reason why delay characteristics > couldn't be added > to either RSVP or CR-LDP in the future. > > -- David > From owner-mpls@UU.NET Thu Apr 19 14:52:24 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16321 for ; Thu, 19 Apr 2001 14:52:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllr14289; Thu, 19 Apr 2001 18:49:41 GMT Received: by mail-control.mail.uu.net id QQkllr27463 for mpls-outgoing; Thu, 19 Apr 2001 18:49:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkllr27452 for ; Thu, 19 Apr 2001 18:48:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllr04879 for ; Thu, 19 Apr 2001 18:48:45 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkllr12899 for ; Thu, 19 Apr 2001 18:48:44 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 LAA13674; Thu, 19 Apr 2001 11:49:09 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA06410; Thu, 19 Apr 2001 14:48:40 -0400 (EDT) Message-Id: <200104191848.OAA06410@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: "Aris Kyriakopoulos" cc: David Charlap , mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? In-reply-to: Your message of Thu, 19 Apr 2001 14:17:52 -0400. 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, 19 Apr 2001 14:48:40 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk I think this is a good time to repeat a remark that Luca Martini made at the PWOT BoF in Minneapolis: If people wanted the ATM service model, we'd all be run- ning ATM to the desktop now. From owner-mpls@UU.NET Thu Apr 19 14:57:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16410 for ; Thu, 19 Apr 2001 14:57:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklld10656; Thu, 19 Apr 2001 15:19:08 GMT Received: by mail-control.mail.uu.net id QQklld10319 for mpls-outgoing; Thu, 19 Apr 2001 15:18:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklld10314 for ; Thu, 19 Apr 2001 15:18:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklld28420 for ; Thu, 19 Apr 2001 15:18:26 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklld09551 for ; Thu, 19 Apr 2001 15:18:26 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA18816 for mpls@uu.net; Thu, 19 Apr 2001 11:18:25 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkllc09717 for ; Thu, 19 Apr 2001 15:13:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllc29999 for ; Thu, 19 Apr 2001 15:12:29 GMT Received: from salamander.eu.fore.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: salamander.eu.fore.com [193.132.138.12]) id QQkllc27853 for ; Thu, 19 Apr 2001 15:12:27 GMT Received: from gbennett-pc (compuserve-45-92.pit.comms.marconi.com [169.144.45.92]) by salamander.eu.fore.com (8.9.1/8.9.1) with SMTP id QAA03690; Thu, 19 Apr 2001 16:11:31 +0100 (BST) Message-Id: <200104191511.QAA03690@salamander.eu.fore.com> X-Sender: gbennett@salamander.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Apr 2001 17:20:01 +0100 To: "Donkin, Richard" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET From: Geoff Bennett Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Richard, Please read my post carefully. Internet services are generally intended to mean "best effort". In contrast VPN services are supposed to carry some kind of added value. In other words, I fully accept that IP VPNs should make more money than a basic Internet service. But as I understand it, the added value from IP VPNs either comes from security (whether this is "isolational" in nature like an ATM or Frame Relay VPN, or "truly secure" as in the case of an ecrypted ATM or IPSec VPN is up to the user), or from "perceived service enhancement". The latter could be via a CoS mechanism, which MPLS can potentially offer, or from a hard QoS mechanism which can only be offered from... a: A TDM mechanism (like SONET/SDH, which is expensive). b: A native ATM service. c: An over-provisioned stat mux service (eg. IP), which is also expensive in the long term. I know that Orchestream's core business is based on the provision of services over an MPLS core, so this may be akin to asking a barber if he thinks I need a haircut, but is there any evidence that IP VPN services are "truly profitable" (as opposed to "press release" profitable)? the problem is that asking most SPs this question will result in "sorry, this is very confidential information" responses. I'm not trying to bang a vendor drum here, I'm truly interested because of the fact that about a dozen European SPs are technically bankrupt from being too dependent on IP services ever making money. Cheers, Geoff At 19:38 18/04/01 +0100, Donkin, Richard wrote: > > >> -----Original Message----- >> From: Geoff Bennett [mailto:geoff.bennett@marconi.com] >> Sent: 18 April 2001 11:15 >> To: MP LS; mpls-ops@mplsrc.com; mpls@uu.net >> Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? >> >> >> Hi Niels, >> >> There may be some confusion arising depending on how you >> configure the ATM >> switch. In effect there are three modes of operation for >> this device... >> >> 3. Ships in the Night (SIN). In this case, both ATM and MPLS Control >> Planes operate simultaneously. ATM signalling happens on VCI >> 5, and MPLS >> signalling on VCI 32. VCs that are set up as a result of >> signalling are >> "owned" by one or other of these control planes. SIN would allow an >> operator to continue to run high revenue voice services (and >> maybe existing >> Frame Relay or native ATM services...they make money too) >> over the ATM >> "character" of the switch. They can then run the loss-making Internet > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> services over the MPLS character. >^^^^^^^^^^ > >Very amusing... I'm sure this was just flame-bait, but first of all, MPLS >supports IP services, not just Internet traffic, and you can of course run >highly profitable IP VPN services over MPLS. > >Ultimately, ATM/FR services (as seen by the customer) may well be carried >over an MPLS core, particularly as MPLS becomes one of the key signalling >mechanisms for all-optical core networks, but since much of the traffic >running over ATM/FR is actually IP, it may be simpler to deliver IP VPNs >directly to the customer premises. > >> Cheers, >> Geoff > >Richard Donkin >T: +44 (0)20 7348 1507 >Orchestream >Avon House, Kensington Village, Avonmore Road, London W14 8TS >T: +44 (0)20 7348 1500 F: +44 (0)20 7348 1501 >www.orchestream.com > > >-- >This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited. If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents. Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated. > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > ================================================================ Geoff Bennett Tel: (33) 497 21 43 62 Director of Technology, OCTO Fax: (33) 497 21 43 50 Marconi Gaia - Bat. E email: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ From owner-mpls@UU.NET Thu Apr 19 15:22:29 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17046 for ; Thu, 19 Apr 2001 15:22:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllt28300; Thu, 19 Apr 2001 19:19:30 GMT Received: by mail-control.mail.uu.net id QQkllt18903 for mpls-outgoing; Thu, 19 Apr 2001 19:18:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkllt18891 for ; Thu, 19 Apr 2001 19:18:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllt12424 for ; Thu, 19 Apr 2001 19:17:55 GMT Received: from zcars04e.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQkllt14566 for ; Thu, 19 Apr 2001 19:17:55 GMT Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com; Thu, 19 Apr 2001 15:17:34 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JC4S61A6; Thu, 19 Apr 2001 15:17:30 -0400 Received: from gautam.corpeast.baynetworks.com (dhcp225-106.engeast.baynetworks.com [192.32.225.106]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GPSTF85G; Thu, 19 Apr 2001 15:17:33 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Gautam Khera" To: djiang1 , mpls Subject: RE: Resource reservation during RSVP Path message forwarding? Date: Thu, 19 Apr 2001 15:16:16 -0400 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jane, The PATH message should be forwarded all the way to R4(assuming that is the destination) by the intermediate routers(R2 & R3). A Path State Block will be created on the intermediate routers, but, resources need not be reserved at this point. The actual reservation is done when R4 sends a RESV message back to R1 which passes thru the same route. -gautam. > Hi all, > > I have a question regarding when the proper time is to start resource > reservation on a transit LSR (not LER). > > Assume we have R1(LER) --> R2 (LSR) --> R3(LSR) --> R4(LER). R1 gets a > signal from, say, user configuration that there is a need to set up a LSP. > R1 sends a RSVP Path message to R2. Would you think R2 should try to > reserve resource at this time and send another RSVP Path message down to > R3, or you think R2 should not reserve any resource until R2 gets a RSVP > Resv message from R3? > > Thanks, > Jane D. Jiang > From owner-mpls@UU.NET Thu Apr 19 15:52:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17589 for ; Thu, 19 Apr 2001 15:52:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllv07210; Thu, 19 Apr 2001 19:50:06 GMT Received: by mail-control.mail.uu.net id QQkllv22129 for mpls-outgoing; Thu, 19 Apr 2001 19:49:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkllv22112 for ; Thu, 19 Apr 2001 19:49:10 GMT Received: from sysenglt126 by imr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: ippool146-202.corp.us.uu.net [153.39.146.202]) id QQkllv02580; Thu, 19 Apr 2001 19:47:52 GMT Message-Id: <3.0.32.20010419155230.00a48860@neserve0.corp.us.uu.net> X-Sender: abirjand@neserve0.corp.us.uu.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 19 Apr 2001 15:52:30 -0400 To: David Charlap , djiang1@lucent.com From: Amir Birjandi Subject: Re: Resource reservation during RSVP Path message forwarding? Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk >REASONS FOR NOT RESERVING RESOURCES UNTIL RESV PROCESSING > >1: There will be no data flow along the LSP until the Resv message > arrives, but the resources will be reserved. These resources won't > be available for other purposes (perhaps other LSPs or non-MPLS > circuits.) > Can you explain what you mean by non-MPLS circuits? and why do you see a problem? Based on my understanding the reseravation starts at R4. A. From owner-mpls@UU.NET Thu Apr 19 16:25:01 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17991 for ; Thu, 19 Apr 2001 16:25:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllx25244; Thu, 19 Apr 2001 20:22:01 GMT Received: by mail-control.mail.uu.net id QQkllx13206 for mpls-outgoing; Thu, 19 Apr 2001 20:21:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkllx13193 for ; Thu, 19 Apr 2001 20:21:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllx04920 for ; Thu, 19 Apr 2001 20:19:23 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkllx21522 for ; Thu, 19 Apr 2001 20:19:22 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA23038 for mpls@uu.net; Thu, 19 Apr 2001 16:19:22 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllx12994 for ; Thu, 19 Apr 2001 20:18:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkllx17412 for ; Thu, 19 Apr 2001 20:16:08 GMT Received: from netmail2.alcatel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkllx17095 for ; Thu, 19 Apr 2001 20:16:08 GMT Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA14755 for ; Thu, 19 Apr 2001 15:16:07 -0500 (CDT) Received: from usa.alcatel.com ([198.205.41.31]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA6F52 for ; Thu, 19 Apr 2001 16:29:22 -0400 Message-ID: <3ADF47FF.23FEE4C@usa.alcatel.com> Date: Thu, 19 Apr 2001 16:18:07 -0400 From: Yuan Gu Organization: Alcatel USA X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls Subject: LSP ID Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: I have some questions about LSP ID of rsvp-tunnel comparing the one defined in cr-ldp: In draft-ietf-mpls-cr-ldp-05.txt section 4.5 LSP ID TLV: "LSPID is a unique identifier of a CR-LSP within an MPLS network. The LSPID is composed of the ingress LSR Router ID (or any of its own Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR." It's very clear. I have no doubt. But In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt section: 4.6.2.1: "LSP ID A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself." My question are: Is this LSP ID Locally unique? What's mean of "it can be changed to allow a sender to share resources with itself"? In RSVP-LSP-tunnel, how can we unique identify a LSP within an MPLS network? Is it enough to use "LSP ID + sender node address" to identify it? Is there any specification about it? Best Regards! Yuan From owner-mpls@UU.NET Thu Apr 19 16:25:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18002 for ; Thu, 19 Apr 2001 16:25:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklll00746; Thu, 19 Apr 2001 17:25:26 GMT Received: by mail-control.mail.uu.net id QQklll00008 for mpls-outgoing; Thu, 19 Apr 2001 17:24:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklll29986 for ; Thu, 19 Apr 2001 17:24:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklll11968 for ; Thu, 19 Apr 2001 17:22:11 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQklll14334 for ; Thu, 19 Apr 2001 17:22:11 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 KAA07429 for ; Thu, 19 Apr 2001 10:22:14 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA06125 for mpls@uu.net; Thu, 19 Apr 2001 13:22:09 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklll29455 for ; Thu, 19 Apr 2001 17:18:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklll21638 for ; Thu, 19 Apr 2001 17:17:50 GMT Received: from mail2.orchestream.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [195.153.64.126]) id QQklll08372 for ; Thu, 19 Apr 2001 17:17:49 GMT Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 19 Apr 2001 18:18:58 +0100 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id NAA12504; Thu, 19 Apr 2001 13:18:14 +0100 Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Apr 2001 18:14:15 +0100 Message-ID: From: "Donkin, Richard" To: "'Geoff Bennett'" , "Donkin, Richard" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Thu, 19 Apr 2001 18:14:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > From: Geoff Bennett [mailto:geoff.bennett@marconi.com] ... > ... In other words, I fully accept that IP VPNs should > make more money than a basic Internet service. Good to hear :) > But as I understand it, the added value from IP VPNs either comes from > security (whether this is "isolational" in nature like an ATM or Frame > Relay VPN, or "truly secure" as in the case of an ecrypted ATM or IPSec VPN > is up to the user), or from "perceived service enhancement". Many operators are initially interested in the VPN service, i.e. isolational security - QoS/CoS is seen as a supplement, particularly since it requires CE management, and is therefore harder to scale, and requires customer-specific classification/marking, which means more involvement with customer requirements than a non-CoS VPN service. In other words, something like today's successful Frame Relay services, but with better provisioning scalability for the provider, and the option of adding QoS/CoS services on top. > The latter could be via a CoS mechanism, which MPLS can potentially > offer, or from a hard QoS mechanism which can only be offered from... > > a: A TDM mechanism (like SONET/SDH, which is expensive). > b: A native ATM service. > c: An over-provisioned stat mux service (eg. IP), which is also expensive > in the long term. I'm not clear about the current market for hard-QoS services (partly because of the CoS factors above, plus the extra QoS parameters that must be specified, again with customer input), but MPLS TE + CoS features does enable firmer QoS than currently possible with IP alone. Comparison with ATM QoS is probably a religious issue, and left as an exercise to the reader... > I know that Orchestream's core business is based on the provision of > services over an MPLS core, so this may be akin to asking a > barber if he > thinks I need a haircut, but is there any evidence that IP > VPN services are > "truly profitable" (as opposed to "press release" > profitable)? the problem > is that asking most SPs this question will result in "sorry, > this is very > confidential information" responses. Information on profitability is of course hard to come by, and I am on the technical side not business, but I don't see why MPLS VPNs cannot be more profitable than the equivalent Frame Relay services, given better scalability, simpler provisioning (particularly if non-CoS), etc. In fact, MPLS VPNs can be delivered as FR services, e.g. AT&T's 'IP enabled Frame Relay' which is really an MPLS VPN service internally. Cheers, Richard > > At 19:38 18/04/01 +0100, Donkin, Richard wrote: > > > > > >> -----Original Message----- > >> From: Geoff Bennett [mailto:geoff.bennett@marconi.com] > >> Sent: 18 April 2001 11:15 > > >> To: MP LS; mpls-ops@mplsrc.com; mpls@uu.net > >> Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? > >> > >> > >> Hi Niels, > >> > >> There may be some confusion arising depending on how you > >> configure the ATM > >> switch. In effect there are three modes of operation for > >> this device... > >> > >> 3. Ships in the Night (SIN). In this case, both ATM and > MPLS Control > >> Planes operate simultaneously. ATM signalling happens on VCI > >> 5, and MPLS > >> signalling on VCI 32. VCs that are set up as a result of > >> signalling are > >> "owned" by one or other of these control planes. SIN > would allow an > >> operator to continue to run high revenue voice services (and > >> maybe existing > >> Frame Relay or native ATM services...they make money too) > >> over the ATM > >> "character" of the switch. They can then run the > loss-making Internet > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> services over the MPLS character. > >^^^^^^^^^^ > > > >Very amusing... I'm sure this was just flame-bait, but first > of all, MPLS > >supports IP services, not just Internet traffic, and you can > of course run > >highly profitable IP VPN services over MPLS. > > > >Ultimately, ATM/FR services (as seen by the customer) may > well be carried > >over an MPLS core, particularly as MPLS becomes one of the > key signalling > >mechanisms for all-optical core networks, but since much of > the traffic > >running over ATM/FR is actually IP, it may be simpler to > deliver IP VPNs > >directly to the customer premises. > > > >> Cheers, > >> Geoff > > > >Richard Donkin > >T: +44 (0)20 7348 1507 > >Orchestream > >Avon House, Kensington Village, Avonmore Road, London W14 8TS > >T: +44 (0)20 7348 1500 F: +44 (0)20 7348 1501 > >www.orchestream.com > > > > > >-- > >This communication contains confidential information > intended solely for > the use of the individual/s and/or entity or entities to whom it was > intended to be addressed. If you are not the intended > recipient, be aware > that any disclosure, copying, distribution, or use of the > contents of this > transmission is prohibited. If you have received this > communication in > error, please contact the sender immediately, delete this > communication > from your system, and do not disclose its contents to any > third party, or > use its contents. Any opinions expressed are solely those of > the author > and do not necessarily represent those of Orchestream Ltd or > its group of > companies unless otherwise specifically stated. > > > >------- > >The MPLS-OPS Mailing List > >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > > ================================================================ > Geoff Bennett > Tel: (33) 497 21 43 62 > Director of Technology, OCTO > Fax: (33) 497 21 43 50 > Marconi > Gaia - Bat. E > email: geoff.bennett@marconi.com > BP 123 > 06903 SOPHIA ANTIPOLIS > FRANCE > ================================================================ > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > From owner-mpls@UU.NET Thu Apr 19 16:49:14 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18263 for ; Thu, 19 Apr 2001 16:49:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllz29598; Thu, 19 Apr 2001 20:46:48 GMT Received: by mail-control.mail.uu.net id QQkllz15987 for mpls-outgoing; Thu, 19 Apr 2001 20:46:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllz15953 for ; Thu, 19 Apr 2001 20:46:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllz22398 for ; Thu, 19 Apr 2001 20:45:14 GMT Received: from email.nist.gov by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.nist.gov [129.6.2.7]) id QQkllz21730 for ; Thu, 19 Apr 2001 20:45:04 GMT Received: from antd.nist.gov (octopus.antd.nist.gov [129.6.60.19]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA10057 for ; Thu, 19 Apr 2001 16:45:04 -0400 (EDT) Message-ID: <3ADF789A.9D38C8A4@antd.nist.gov> Date: Thu, 19 Apr 2001 16:45:30 -0700 From: SuKyoung Lee X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Question about MPLS-based wireless network Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello all I would like to know if there is any research about MPLS-based wireless network recently. If you have any information, let me know that. -- SuKyoung Lee High Speed Network Technologies Group Advanced Network Technologies Division National Institute of Standards & Technology Email: sukyoung@antd.nist.gov Phone: 301-975-4780 From owner-mpls@UU.NET Thu Apr 19 17:00:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18391 for ; Thu, 19 Apr 2001 17:00:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkllz15915; Thu, 19 Apr 2001 20:58:18 GMT Received: by mail-control.mail.uu.net id QQkllz17170 for mpls-outgoing; Thu, 19 Apr 2001 20:57:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkllz17165 for ; Thu, 19 Apr 2001 20:57:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllz04432 for ; Thu, 19 Apr 2001 20:57:14 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkllz08488 for ; Thu, 19 Apr 2001 20:57:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA26553 for mpls@uu.net; Thu, 19 Apr 2001 16:57:13 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkllz16738 for ; Thu, 19 Apr 2001 20:52:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkllz05191 for ; Thu, 19 Apr 2001 20:50:40 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkllz29233 for ; Thu, 19 Apr 2001 20:50:40 GMT Received: (qmail 22559 invoked by uid 104); 19 Apr 2001 20:50:39 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.842454 secs); 19/04/2001 13:50:38 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 19 Apr 2001 20:50:38 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f3JKoc229259; Thu, 19 Apr 2001 13:50:38 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id <2NK1GX9H>; Thu, 19 Apr 2001 13:52:03 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BD0@BBY1EXM01> From: Shahram Davari To: "'Yuan Gu'" , mpls Subject: RE: LSP ID Date: Thu, 19 Apr 2001 13:51:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, In RSVP-TE, an LSP could be uniquely identified by the combination of Ingress Router ID, which can be found in Session object (Extended Tunnel ID field), and the LSP ID, which can be found in the Session object (Tunnel ID field). Note: the LSP ID field in the Sender Template object should not be used as this can be changed during the life of the LSP! Yours, -Shahram > -----Original Message----- > From: Yuan Gu [mailto:Yuan.Gu@usa.alcatel.com] > Sent: Thursday, April 19, 2001 4:18 PM > To: mpls > Subject: LSP ID > > > Hello: > > I have some questions about LSP ID of rsvp-tunnel comparing the one > defined in cr-ldp: > > In draft-ietf-mpls-cr-ldp-05.txt section 4.5 LSP ID TLV: > > "LSPID is a unique identifier of a CR-LSP within an MPLS network. > The LSPID is composed of the ingress LSR Router ID (or any of its own > Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR." > > It's very clear. I have no doubt. > > But In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt section: 4.6.2.1: > > "LSP ID > > A 16-bit identifier used in the > SENDER_TEMPLATE and the > > FILTER_SPEC that can be changed to allow a > sender to share > > resources with itself." > > My question are: > Is this LSP ID Locally unique? > What's mean of "it can be changed to allow a sender to share > resources > with itself"? > In RSVP-LSP-tunnel, how can we unique identify a LSP within an MPLS > network? Is it enough to use "LSP ID + sender node address" > to identify > it? Is there any specification about it? > > Best Regards! > Yuan > From owner-mpls@UU.NET Thu Apr 19 17:40:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18862 for ; Thu, 19 Apr 2001 17:40:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklmc08507; Thu, 19 Apr 2001 21:36:30 GMT Received: by mail-control.mail.uu.net id QQklmc08777 for mpls-outgoing; Thu, 19 Apr 2001 21:35:52 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklmc08769 for ; Thu, 19 Apr 2001 21:35:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklmc18047 for ; Thu, 19 Apr 2001 21:35:18 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklmc02542 for ; Thu, 19 Apr 2001 21:35:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA29567 for mpls@uu.net; Thu, 19 Apr 2001 17:35:17 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklmc08647 for ; Thu, 19 Apr 2001 21:34:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklmc13203 for ; Thu, 19 Apr 2001 21:32:52 GMT Received: from netmail2.alcatel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQklmc27995 for ; Thu, 19 Apr 2001 21:32:51 GMT Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA24446 for ; Thu, 19 Apr 2001 16:32:50 -0500 (CDT) Received: from usa.alcatel.com ([198.205.41.31]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA4FB; Thu, 19 Apr 2001 17:46:04 -0400 Message-ID: <3ADF59F8.7BB57C3C@usa.alcatel.com> Date: Thu, 19 Apr 2001 17:34:48 -0400 From: Yuan Gu Organization: Alcatel USA X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: mpls Subject: Re: LSP ID References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BD0@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Shahram: Thanks for your answer. Could you tell me the specification from which your answer is getten? As far as I understanding, you are talking about identification of a TE-tunnel i.s.o a LSP (please ref rsvp-lsp-tunnel-08, section 2.1). Within one TE-tunnel(destination address+tunnel ID), we can setup multipul LSPs. And could you explain in which case the LSP ID will be changed? Best Regards! Yuan Shahram Davari wrote: > Hi, > > In RSVP-TE, an LSP could be uniquely identified by the combination of Ingress Router ID, which can be found in Session object (Extended Tunnel ID field), and the LSP ID, which can be found in the Session object (Tunnel ID field). > > Note: the LSP ID field in the Sender Template object should not be used as this can be changed during the life of the LSP! > > Yours, > -Shahram > > > -----Original Message----- > > From: Yuan Gu [mailto:Yuan.Gu@usa.alcatel.com] > > Sent: Thursday, April 19, 2001 4:18 PM > > To: mpls > > Subject: LSP ID > > > > > > Hello: > > > > I have some questions about LSP ID of rsvp-tunnel comparing the one > > defined in cr-ldp: > > > > In draft-ietf-mpls-cr-ldp-05.txt section 4.5 LSP ID TLV: > > > > "LSPID is a unique identifier of a CR-LSP within an MPLS network. > > The LSPID is composed of the ingress LSR Router ID (or any of its own > > Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR." > > > > It's very clear. I have no doubt. > > > > But In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt section: 4.6.2.1: > > > > "LSP ID > > > > A 16-bit identifier used in the > > SENDER_TEMPLATE and the > > > > FILTER_SPEC that can be changed to allow a > > sender to share > > > > resources with itself." > > > > My question are: > > Is this LSP ID Locally unique? > > What's mean of "it can be changed to allow a sender to share > > resources > > with itself"? > > In RSVP-LSP-tunnel, how can we unique identify a LSP within an MPLS > > network? Is it enough to use "LSP ID + sender node address" > > to identify > > it? Is there any specification about it? > > > > Best Regards! > > Yuan > > From owner-mpls@UU.NET Thu Apr 19 17:59:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18979 for ; Thu, 19 Apr 2001 17:59:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklmd18638; Thu, 19 Apr 2001 21:55:01 GMT Received: by mail-control.mail.uu.net id QQklmd10975 for mpls-outgoing; Thu, 19 Apr 2001 21:54:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklmd10966 for ; Thu, 19 Apr 2001 21:54:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklmd01607 for ; Thu, 19 Apr 2001 21:53:57 GMT Received: from mason2.gmu.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQklmd18084 for ; Thu, 19 Apr 2001 21:53:56 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id RAA20852; Thu, 19 Apr 2001 17:54:02 -0400 (EDT) Date: Thu, 19 Apr 2001 17:54:02 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: SuKyoung Lee cc: mpls@UU.NET Subject: Re: Question about MPLS-based wireless network In-Reply-To: <3ADF789A.9D38C8A4@antd.nist.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi sukyoung, "Label Switched Packet Transfer for Wireless Cellular Networks", authored by Dr. Bijan Jabbari, Rajiv Papneja and Esmael Dinan. It was presented at WCNC 2000. We are currently involved in extending this further. Thanks, -Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** On Thu, 19 Apr 2001, SuKyoung Lee wrote: > Hello all > > I would like to know if there is any research about MPLS-based wireless > network recently. > If you have any information, let me know that. > > -- > SuKyoung Lee > High Speed Network Technologies Group > Advanced Network Technologies Division > National Institute of Standards & Technology > Email: sukyoung@antd.nist.gov > Phone: 301-975-4780 > > > From owner-mpls@UU.NET Thu Apr 19 18:05:18 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19032 for ; Thu, 19 Apr 2001 18:05:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklme14770; Thu, 19 Apr 2001 22:02:44 GMT Received: by mail-control.mail.uu.net id QQklme17681 for mpls-outgoing; Thu, 19 Apr 2001 22:02:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklme16902 for ; Thu, 19 Apr 2001 22:01:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklme28332 for ; Thu, 19 Apr 2001 22:01:34 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklme13187 for ; Thu, 19 Apr 2001 22:01:34 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA01797 for mpls@uu.net; Thu, 19 Apr 2001 18:01:33 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklmd11300 for ; Thu, 19 Apr 2001 21:56:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklmd05985 for ; Thu, 19 Apr 2001 21:56:23 GMT Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQklmd06011 for ; Thu, 19 Apr 2001 21:56:23 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3JLuZb29601; Fri, 20 Apr 2001 00:56:35 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15071.24339.890504.475774@lohi.eng.telia.fi> Date: Fri, 20 Apr 2001 00:56:35 +0300 (EEST) To: erosen@cisco.com Cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <200104191640.MAA05950@erosen-sun.cisco.com> References: <15071.3964.759117.255670@lohi.eng.telia.fi> <200104191640.MAA05950@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: > I didn't mean to suggest that the SVC paradigm is better for CE-CE LSPs than > the PVC paradigm; the question is whether MPLS as a CE-CE link layer is > valuable. Of course, this is really far afield of the topic of this > thread. mpls as ce-ce link has many advantages over frame relay, e.g., exp field for diffserv support and label stacking. if mpsl is used in the middle, it is always a good idea to avoid interworking and run mpls all the way. -- juha From owner-mpls@UU.NET Thu Apr 19 18:55:34 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19377 for ; Thu, 19 Apr 2001 18:55:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkljs08488; Thu, 19 Apr 2001 06:09:54 GMT Received: by mail-control.mail.uu.net id QQkljs15000 for mpls-outgoing; Thu, 19 Apr 2001 06:09:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkljs14986 for ; Thu, 19 Apr 2001 06:09:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkljs15291 for ; Thu, 19 Apr 2001 06:07:11 GMT Received: from wiprom2mx1.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQkljs17272 for ; Thu, 19 Apr 2001 06:07:09 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id LAA19939 for ; Thu, 19 Apr 2001 11:45:18 GMT Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GC0ZXI00.UEJ; Thu, 19 Apr 2001 11:42:54 +0530 Date: Thu, 19 Apr 2001 11:57:06 +0000 (Local time zone must be set--see zic manual page) From: "Nagabhushana Ramaswamy Nadig" X-Sender: bhushanr@boochi.alc.wipinfo.soft.net Reply-To: nagabhushana.ramaswamy@wipro.com To: David Charlap cc: mpls@UU.NET Subject: Re: Questions about merge-capability in LDP In-Reply-To: <3ADDC6BD.4A21D8F8@marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello, I have a few observations from your mail. 1. Particularly the way you have mentioned of raising the internal label requests for the FECs. How far does it make sense to wait for a label request from a peer LSR and take the same as a trigger for learning a new FEC. What I think is, as each of these LSR's would be running a L3 routing protocol the moment I learn a new route at L3 should be the trigger for me to make a new request to the next hop peer (Ideally we will be populating our FTN table in this case and ILM in the former). Depending upon this I would say the sequence of message flow changes in your below discussions. 2. Scenario 5. I really doubt such a configuration will work for you. A non-merge capable LSR cofigured for Unsolicited distribution (there by to also to receive unsolicited messages). In this case if you receive an Unsolicited mapping msg, what will you do with that? To which upstream peer are you going to distribute this? I think because of this only the architecture has wisely avoided the DU mode for non-merge LSRs. regards Bhushana > A rereading of the LDP RFC brings to mind some questions abouthow > different modes of operation (on-demand vs. unsolicited) work in > conjunction with merge-capable and non-merge-capable routers. > > I've run through several scenarios. If any of my assumptions are wrong, > please let me know. I think I've got everything right for the > downstream-on-demand scenarios. I don't know if I've got things right > for the downstream-unsolicited scenarios. > > All of these scenarios involve 5 routers in a straight-line topology. > All routers are IP-lookup and push capable, and are therefore capable of > acting as ingress rotuers. There is a single FEC, for which which R5 is > egres.. > > -=-=-=-=- > > Scenario 1: > > [R1]---{R2]---[R3]---[R4]---[R5] > > All routers are merge-capable. They are configured for downstream-on- > demand label distribution. R1 sends a Label-request to R2, and it > propagates to R5. R5 sends a Label-mapping to R4, and it propagates > back to R1. The resulting LSP looks like this: > > ->-\ ->-\ ->-\ > ---------->------>------>------> > [R1]---{R2]---[R3]---[R4]---[R5] > > R1 pushes the label for incoming packets. R2-R4 configure themselves > both to push the label for unlabeled packets, and to swap the label for > labeled packets. R5 pops the label for labeled packets and simply > forwards unlabeled traffic > > -=-=-=-=- > > Scenario 2: > > [R1]---{R2]---[R3]---[R4]---[R5] > > No routers are merge-capable. Downstream-on-demand distribution. > > R1 sends a Label-request to R2. R2 sends two Label-requests to R3 (one > for labeled traffic and one for unlabeled traffic). R3 sends three > Label-requests to R4 (two for the two possible incoming labels and one > for unlabeled traffic.) R4 sends four Label-requests to R5 (three for > the three possible incoming labels and one for unlabeled traffic.) > > Label-mappings propagate back to satisfy all requests. The resulting > LSPs look like: > > ----------> > -----------------> > ------------------------> > -------------------------------> > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 3: > > [R1]---{R2]---[R3]---[R4]---[R5] > (M) (M) > > R2 and R4 are merge capable. R1, R3 and R5 are not. > Downstream-on-demand distribution. > > R1 sends a Label-request to R2. Since R2 can merge this request with > unlabeled traffic, it only sends one Label-request to R3. R3 can not > merge this request with unlabeled traffic, so it sends two > Label-requests to R4. R4 can merge both of these requests with each > other and with unlabeled traffic, so it sends one Label-Request to R5. > > Label-mappings propagate back to satisfy all requests. The resulting > LSP looks like: > > ->-\ ->--------\ > ---------->------------->------> > ->-/ > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 4: > > [R1]---{R2]---[R3]---[R4]---[R5] > > All routers are merge-capable. They are configured for downstream- > unsolicited label distribution. R5 sends a Label-mapping to R4, and it > propagates to R1. The resulting LSP looks just like it would with > on-demand distribution: > > ->-\ ->-\ ->-\ > ---------->------>------>------> > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 5: > > [R1]---{R2]---[R3]---[R4]---[R5] > > No routers are merge-capable. Downstream-unsolicited label distribution. > > - R5 sends a Label-mapping to R4. > - R4 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R5 in order to get a second. > - R5 sends a second Label-mapping to R5 > - R4 sends a Label-mapping message to R3. > - R3 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R4 in order to get a second. > - R4 sends a Label-request downstream to R5, since it now needs a > third label (in order to satisfy the new request). > - R5 sends a third Label-mapping to R4 > - R4 sends a second Label-mapping to R3 > - R3 sends a Label-mapping to R2 > - R2 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R3 in order to get a second. > - R3 sends a Label-request downstream to R4, since it now needs a > third label (in order to satisfy the new request). > - R4 sends a Label-request downstream to R5, since it now needs a > fourth label (in order to satisfy the new request) > - R5 sends a fourth Label-mapping to R4 > - R4 sends a third Label-mapping to R3 > - R3 sends a second Label-mapping to R2 > - R2 sends a Label-mapping to R1 > > The resulting LSPs look just like they would with on-demand > distribution: > > ----------> > -----------------> > ------------------------> > -------------------------------> > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Scenario 6: > > [R1]---{R2]---[R3]---[R4]---[R5] > (M) (M) > > R2 and R4 are merge capable. R1, R3 and R5 are not. > Downstream-unsolicited. > > - R5 sends a Label-mapping to R4 > - R4 sends a Label-mapping to R3 > - R3 realizes that it needs two labels - one to send upstream and one > to install for unlabeled traffic. It uses one label and sends a > Label-request message to R4 in order to get a second. > - R4, being merge-capable, does not propagate the Label-request, but > sends a Label-mapping to R3 > - R3 sends a Label-mappng to R2 > - R2 sends a Label-mapping to R1 > > The resulting LSp looks just like it does with on-demand distribution. > > ->-\ ->--------\ > ---------->------------->------> > ->-/ > [R1]---{R2]---[R3]---[R4]---[R5] > > -=-=-=-=- > > Does all of this look right? It seems good to me. But I'm not certain > about scenarios 5 and 6. The LDP RFC doesn't explicitly document the > behavior of non-merge-capable routers receiving unsolicited label > mappings. > > Comments? > > -- David > From owner-mpls@UU.NET Thu Apr 19 19:08:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19553 for ; Thu, 19 Apr 2001 19:08:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklmi01571; Thu, 19 Apr 2001 23:05:34 GMT Received: by mail-control.mail.uu.net id QQklmi20817 for mpls-outgoing; Thu, 19 Apr 2001 23:05:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklmi20662 for ; Thu, 19 Apr 2001 23:04:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklmi07246; Thu, 19 Apr 2001 23:04:05 GMT Received: from mason2.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQklmi29476; Thu, 19 Apr 2001 23:04:05 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id TAA22921; Thu, 19 Apr 2001 19:04:10 -0400 (EDT) Date: Thu, 19 Apr 2001 19:04:10 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: Amir Birjandi cc: David Charlap , djiang1@lucent.com, mpls@UU.NET Subject: Re: Resource reservation during RSVP Path message forwarding? In-Reply-To: <3.0.32.20010419155230.00a48860@neserve0.corp.us.uu.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 19 Apr 2001, Amir Birjandi wrote: > > > >REASONS FOR NOT RESERVING RESOURCES UNTIL RESV PROCESSING > > > >1: There will be no data flow along the LSP until the Resv message > > arrives, but the resources will be reserved. These resources won't > > be available for other purposes (perhaps other LSPs or non-MPLS > > circuits.) > > > > Can you explain what you mean by non-MPLS circuits? and why do you see a > problem? > > Based on my understanding the reseravation starts at R4. > > A. > > Hi Amir, The LSPs can be established using the extensions to RSVP without even reserving any resources. Such LSPs can be used to carry the best effort traffic and also can be used for other purposes such as recovery policies. For TE applications path message could be used as a means to verify the resource availability along the path before preempting the lower priority traffic. If the path message is allowed to progress when there are no resources, then it might preempt the lower priority tunnels unnecessarily. Regards, -Rajiv ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** From owner-mpls@UU.NET Thu Apr 19 19:19:16 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19649 for ; Thu, 19 Apr 2001 19:19:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklmj24942; Thu, 19 Apr 2001 23:16:31 GMT Received: by mail-control.mail.uu.net id QQklmi22608 for mpls-outgoing; Thu, 19 Apr 2001 23:14:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklmi22596 for ; Thu, 19 Apr 2001 23:14:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklmi11117 for ; Thu, 19 Apr 2001 23:14:04 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklmi21371 for ; Thu, 19 Apr 2001 23:14:04 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA28897 for ; Thu, 19 Apr 2001 19:14:00 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA10227 for ; Thu, 19 Apr 2001 19:14:05 -0400 (EDT) Message-ID: <3ADF7135.7E1FC41@marconi.com> Date: Thu, 19 Apr 2001 19:13:57 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: <200104191848.OAA06410@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 Rosen wrote: > > I think this is a good time to repeat a remark that Luca Martini > made at the PWOT BoF in Minneapolis: > > If people wanted the ATM service model, we'd all be run- > ning ATM to the desktop now. That's incredibly oversimplified. I'm rather surprised to see you take such a cheap shot in this group. There are a great many reasons why ATM hasn't displaced Ethernet on people's desktops, including the price of switch ports and a routing protocol that would have a hard time scaling to the size of the internet. The fact that most people don't run ATM to their desktop doesn't mean that ATM-style QoS wouldn't be appreciated over non-ATM media. -- David From owner-mpls@UU.NET Thu Apr 19 19:20:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19668 for ; Thu, 19 Apr 2001 19:20:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklmj18396; Thu, 19 Apr 2001 23:18:16 GMT Received: by mail-control.mail.uu.net id QQklmi22666 for mpls-outgoing; Thu, 19 Apr 2001 23:14:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklmi22610 for ; Thu, 19 Apr 2001 23:14:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklmi03626 for ; Thu, 19 Apr 2001 23:14:26 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklmi21907 for ; Thu, 19 Apr 2001 23:14:26 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA28919 for ; Thu, 19 Apr 2001 19:14:23 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA10257 for ; Thu, 19 Apr 2001 19:14:27 -0400 (EDT) Message-ID: <3ADF714C.217A6335@marconi.com> Date: Thu, 19 Apr 2001 19:14:20 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Aris Kyriakopoulos wrote: > > No argument about the fact that the ATM QoS model has more features > and is more mature than the IP QoS model. However, in order for > non-ATM applications (specifically IP) to take advantage of ATM QoS, > you need to be able to translate the IP QoS requirements into ATM > signalling. Correction: In order for MPLS applications to take advantage of ATM QoS. There are other ways of running IP over ATM, even though they are not popular as core technologies. > As far as I am aware, there is no way you can do this in a > dynamically-routed IP network. Sure, you can map static IP routes > to ATM (S)PVCs. Even then, what mechanisms are there to distinguish > between different IP flows over the same route (e.g. by ToS, TCP/UDP > ports)? Assigning any QoS other than best-effort to IP traffic requires some degree of policy control. DSCP bits may be used, so can source addresses, physical interface, L4 information, etc. > Because to ATM, all IP packets are created equal, right? Once the packet gets into the ATM VC, there is no IP, just cells. It is the edge router (which puts the IP packets into the VC) which must have the ability to classify the packets and determine what goes where. Which is exactly the same in the MPLS world. Once a packet is in an LSP, it is forwarded according to that LSP's rules. Yes, a certain amount of per-packet QoS is available if E-LSPs are used, but the edge router must still do the bulk of the packet classification - to determine what LSP to put the packet on and to determine what the EXP bits should be set to. > To me, this is one of the good reasons to use MPLS: using ATM > switching hardware to provide IP QoS. Even though the IP QoS model > is not as rich as ATM's, at least ATM LSRs provide some sort of QoS > mechanism for IP that CLIP/MPOA simply do not. The host-side software for CLIP/MPOA (when ATM is run to the desktop) can and does provide the ability to setup application-specific VCs with different levels of QoS. There's no reason why an edge device (serving to gate an IP network into ATM) couldn't do the same thing. As for ATM switching hardware, there's no reason why non-ATM hardware can't do the same thing. ATM hardware has some definite problems when it comes to MPLS - VC (label) merging is difficult, cell tax, no native label-stacking mechanism, etc. > I agree that RSVP and CR-LDP probably need to provide better delay > information than they currently do in order to support delay- > sensitive applications. That is the key, though; these metrics > need to be added to IP QoS. Or maybe the IP QoS model needs to be > extended to have 1-to-1 mapping with ATM QoS. At least on ATM > LSRs. There's no need to use the ATM-style parameters. As a matter of fact, many wouldn't be appropriate without modification anyway, since they are in terms of cells, not bytes or IP packets. The IntServ parameters (used by RSVP) are very good for what they specify. They just don't specify enough. But IntServ is extensible. There's no reason why additional services couldn't be defined that contain delay parameters. -- David From owner-mpls@UU.NET Thu Apr 19 19:23:52 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19692 for ; Thu, 19 Apr 2001 19:23:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklmj22811; Thu, 19 Apr 2001 23:21:22 GMT Received: by mail-control.mail.uu.net id QQklmj23410 for mpls-outgoing; Thu, 19 Apr 2001 23:20:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklmj23405 for ; Thu, 19 Apr 2001 23:20:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklmj15093 for ; Thu, 19 Apr 2001 23:18:36 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklmj28235 for ; Thu, 19 Apr 2001 23:18:36 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA29183 for ; Thu, 19 Apr 2001 19:18:32 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA10818 for ; Thu, 19 Apr 2001 19:18:37 -0400 (EDT) Message-ID: <3ADF7245.F4E50FE1@marconi.com> Date: Thu, 19 Apr 2001 19:18:29 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Resource reservation during RSVP Path message forwarding? References: <3.0.32.20010419155230.00a48860@neserve0.corp.us.uu.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Amir Birjandi wrote: >> >> REASONS FOR NOT RESERVING RESOURCES UNTIL RESV PROCESSING >> >> 1: There will be no data flow along the LSP until the Resv message >> arrives, but the resources will be reserved. These resources >> won't be available for other purposes (perhaps other LSPs or >> non-MPLS circuits.) > > Can you explain what you mean by non-MPLS circuits? and why do you > see a problem? For instance, on an ATM/MPLS switch running a "ships in the night" scenario, resources consumed by an LSP will not be available for an ATM VC and vice versa. > Based on my understanding the reseravation starts at R4. The Resv message originates there. But the other routers can pre-reserve resources in advance, in order to avoid having to do so later. In MPLS, under most circumstances, the amount of resources reserved in the Resv will be the same amount that was requested in the Path message. So resources can theoretically be reserved at Path processing time, even though a label won't be available until after the Resv arrives. -- David From owner-mpls@UU.NET Thu Apr 19 19:40:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19804 for ; Thu, 19 Apr 2001 19:40:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklmk24484; Thu, 19 Apr 2001 23:38:10 GMT Received: by mail-control.mail.uu.net id QQklmk24610 for mpls-outgoing; Thu, 19 Apr 2001 23:37:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklmk24587 for ; Thu, 19 Apr 2001 23:37:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklmk16535 for ; Thu, 19 Apr 2001 23:36:59 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQklmk22477 for ; Thu, 19 Apr 2001 23:36:59 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id AD0D994006; Thu, 19 Apr 2001 19:36:58 -0400 (EDT) Message-ID: <3ADF767B.88B4D120@sandburst.com> Date: Thu, 19 Apr 2001 19:36:27 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: <200104191848.OAA06410@erosen-sun.cisco.com> <3ADF7135.7E1FC41@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, You can't exactly do ATM style QoS over non-ATM media. The thing that allows an ATM switch to contemplate delay variation separately from delay is the fact that ATM switches switch data in fixed size chunks. When the size of data chunks can vary, the only practical way to control delay variation is to try to control delay. Therefore, with IP packets on non-ATM media, you can't even begin support two knobs for delay and delay variation. So why would you undertake to add complexity by trying? -- Eric Gray You wrote: > Eric Rosen wrote: > > > > I think this is a good time to repeat a remark that Luca Martini > > made at the PWOT BoF in Minneapolis: > > > > If people wanted the ATM service model, we'd all be run- > > ning ATM to the desktop now. > > That's incredibly oversimplified. I'm rather surprised to see you take > such a cheap shot in this group. > > There are a great many reasons why ATM hasn't displaced Ethernet on > people's desktops, including the price of switch ports and a routing > protocol that would have a hard time scaling to the size of the > internet. > > The fact that most people don't run ATM to their desktop doesn't mean > that ATM-style QoS wouldn't be appreciated over non-ATM media. > > -- David From owner-mpls@UU.NET Thu Apr 19 19:45:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19861 for ; Thu, 19 Apr 2001 19:45:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklmk21144; Thu, 19 Apr 2001 23:42:37 GMT Received: by mail-control.mail.uu.net id QQklmk24991 for mpls-outgoing; Thu, 19 Apr 2001 23:42:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklmk24974 for ; Thu, 19 Apr 2001 23:41:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklmk05913 for ; Thu, 19 Apr 2001 23:41:45 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklmk28813 for ; Thu, 19 Apr 2001 23:41:44 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA00422 for ; Thu, 19 Apr 2001 19:41:41 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA14308 for ; Thu, 19 Apr 2001 19:41:43 -0400 (EDT) Message-ID: <3ADF77AF.C55FE2B8@marconi.com> Date: Thu, 19 Apr 2001 19:41:36 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls Subject: Re: LSP ID References: <3ADF47FF.23FEE4C@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yuan Gu wrote: > > I have some questions about LSP ID of rsvp-tunnel comparing the one > defined in cr-ldp: > > In draft-ietf-mpls-cr-ldp-05.txt section 4.5 LSP ID TLV: > > "LSPID is a unique identifier of a CR-LSP within an MPLS network. > The LSPID is composed of the ingress LSR Router ID (or any of its own > Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR." > > It's very clear. I have no doubt. > > But In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt section: 4.6.2.1: > > "LSP ID > > A 16-bit identifier used in the SENDER_TEMPLATE and the > FILTER_SPEC that can be changed to allow a sender to share > resources with itself." > > My question are: > Is this LSP ID Locally unique? Yes. It is only meaningful when used in conjunction with the rest of the SENDER_TEMPLATE or FILTER_SPEC object. Since the only other field in the LSP-CType of these objects is the sender IP address, you may safely think of the SENDER_TEMPLATE/FITER_SPEC objects as functionally identical to the CR-LDP LSPDI. > What's mean of "it can be changed to allow a sender to share > resources with itself"? In RSVP, two LSPs that belong to the same tunnel (which is defined by the tunnel-endpoint/tunnel-ID/extended-tunnel-ID triple) will share resources if SE-style reservations are used. A single sender can signal two LSPs in the same session by using identical SESSION objects but different LSPID values in the SENDER_TEMPLATE/FILTER_SPEC objects. If the egress router uses SE style, these two LSPs will share resources wherever possible. > In RSVP-LSP-tunnel, how can we unique identify a LSP within an MPLS > network? Is it enough to use "LSP ID + sender node address" to > identify it? Is there any specification about it? The combination of SESSION object and SENDER_TEMPLATE uniquely identifies a single LSP in Path messages. The combination of SESSION object and FILTER_SPEC uniquely identifies a single LSP in Resv messages. In both cases, this is a 5-tuple consisting of tunnel-endpoint address, tunnel-ID, extended tunnel-ID, sender address, and LSP ID. -- David From owner-mpls@UU.NET Thu Apr 19 19:50:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19925 for ; Thu, 19 Apr 2001 19:50:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklml28067; Thu, 19 Apr 2001 23:47:53 GMT Received: by mail-control.mail.uu.net id QQklml25794 for mpls-outgoing; Thu, 19 Apr 2001 23:47:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklml25783 for ; Thu, 19 Apr 2001 23:47:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklml15534 for ; Thu, 19 Apr 2001 23:46:26 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklml04955 for ; Thu, 19 Apr 2001 23:46:26 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA00560 for ; Thu, 19 Apr 2001 19:46:22 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA14742 for ; Thu, 19 Apr 2001 19:46:26 -0400 (EDT) Message-ID: <3ADF78CB.773499DE@marconi.com> Date: Thu, 19 Apr 2001 19:46:19 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls Subject: Re: LSP ID References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BD0@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > In RSVP-TE, an LSP could be uniquely identified by the combination > of Ingress Router ID, which can be found in Session object (Extended > Tunnel ID field), and the LSP ID, which can be found in the Session > object (Tunnel ID field). Not quite. The LSP ID field is only guaranteed unique within a single session. A single sender may use the same LSP ID for different LSPs in different sessions. If all routers use the sender address as extended tunnel-ID, then you can identify an LSP with the 4-tuple of tunnel-endpoint address, tunnel ID, sender address and LSP ID. But you can't ever be certain of this. It is perfectly legal for routers to use an extended tunnel ID of zero ("don't care") - making it possible to share resources with LSPs that originate from multiple points. Because of this, you really need the full 5-tuple (the above parameters plus extended tunnel ID) in order to uniquely identify an LSP. -- David From owner-mpls@UU.NET Thu Apr 19 19:55:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19975 for ; Thu, 19 Apr 2001 19:55:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklml04960; Thu, 19 Apr 2001 23:53:16 GMT Received: by mail-control.mail.uu.net id QQklml26541 for mpls-outgoing; Thu, 19 Apr 2001 23:52:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklml26526 for ; Thu, 19 Apr 2001 23:52:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklml25509 for ; Thu, 19 Apr 2001 23:52:00 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklml13319 for ; Thu, 19 Apr 2001 23:51:59 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA00787 for ; Thu, 19 Apr 2001 19:51:56 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA15074 for ; Thu, 19 Apr 2001 19:52:00 -0400 (EDT) Message-ID: <3ADF7A18.CE7891BA@marconi.com> Date: Thu, 19 Apr 2001 19:51:52 -0400 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: <200104191848.OAA06410@erosen-sun.cisco.com> <3ADF7135.7E1FC41@marconi.com> <3ADF767B.88B4D120@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > > You can't exactly do ATM style QoS over non-ATM media. > > The thing that allows an ATM switch to contemplate delay > variation separately from delay is the fact that ATM switches > switch data in fixed size chunks. When the size of data chunks > can vary, the only practical way to control delay variation is to > try to control delay. Therefore, with IP packets on non-ATM > media, you can't even begin support two knobs for delay and > delay variation. So why would you undertake to add complexity > by trying? Variable-size frames don't make it impossible. It just means you are forced to work with a coarser granularity (defined by your configured MTU size.) -- david From owner-mpls@UU.NET Thu Apr 19 21:16:47 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20491 for ; Thu, 19 Apr 2001 21:16:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklmq02932; Fri, 20 Apr 2001 01:14:21 GMT Received: by mail-control.mail.uu.net id QQklmq07719 for mpls-outgoing; Fri, 20 Apr 2001 01:13:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklmq07525 for ; Fri, 20 Apr 2001 01:13:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklmq27962 for ; Fri, 20 Apr 2001 01:11:48 GMT Received: from sktelecom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQklmq29628 for ; Fri, 20 Apr 2001 01:11:42 GMT Received: from mrchang (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f3K1Ew308739 for ; Fri, 20 Apr 2001 10:14:59 +0900 (KST) Message-ID: <006901c0c936$89746ee0$77131796@sktelecom.com> From: "Rae M. Chang" To: Subject: LSP setup algorithms Date: Fri, 20 Apr 2001 10:09:22 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01C0C981.F8D5CFE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C0C981.F8D5CFE0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkRvZXMgYW55b25lIGtub3cgdGhlIHJlZmVyZW5jZXMgdG8gZmluZGluZyBMU1Bz IGZvciBhIGdpdmVuIHRyYWZmaWMgZGVtYW5kcw0KYmV0d2VlbiAoaW5ncmVzcywgZWdyZXNzKSBw YWlycywgd2hlcmUgZWFjaCBMU1AgcmVxdWlyZXMgc29tZSB2YWx1ZSBvZiBsaW5rIGJhbmR3aWR0 aD8NCldoZXJlIGRvIGkgaGF2ZSB0byBzdGFydCBmb3IgdGFja2xpbmcgdGhhdCBraW5kIG9mIHBy b2JsZW0/DQoNCi1SYWUNCg0K ------=_NextPart_000_0066_01C0C981.F8D5CFE0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48U1RST05HPkhlbGxvLDwvU1RST05HPjwvRk9OVD48L0RJVj4NCjxESVY+PFNUUk9O Rz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD48L1NUUk9ORz4mbmJzcDs8L0RJ Vj4NCjxESVY+PFNUUk9ORz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkRvZXMmbmJzcDth bnlvbmUga25vdyB0aGUgcmVmZXJlbmNlcyANCnRvIGZpbmRpbmcgTFNQcyBmb3IgYSBnaXZlbiB0 cmFmZmljIGRlbWFuZHM8L0ZPTlQ+PC9TVFJPTkc+PC9ESVY+DQo8RElWPjxTVFJPTkc+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5iZXR3ZWVuIChpbmdyZXNzLCBlZ3Jlc3MpIHBhaXJzLCB3 aGVyZSANCmVhY2ggTFNQIHJlcXVpcmVzIHNvbWUgdmFsdWUgb2YgbGluayBiYW5kd2lkdGg/PC9G T05UPjwvU1RST05HPjwvRElWPg0KPERJVj48U1RST05HPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+V2hlcmUgZG8gaSBoYXZlIHRvIHN0YXJ0Jm5ic3A7Zm9yIA0KdGFja2xpbmcgdGhhdCBr aW5kIG9mIHByb2JsZW0/PC9GT05UPjwvU1RST05HPjwvRElWPg0KPERJVj48U1RST05HPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPjwvU1RST05HPiZuYnNwOzwvRElWPg0KPERJ Vj48U1RST05HPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+LVJhZTwvRk9OVD48L1NUUk9O Rz48L0RJVj4NCjxESVY+PFNUUk9ORz48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9G T05UPjwvU1RST05HPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0066_01C0C981.F8D5CFE0-- From owner-mpls@UU.NET Thu Apr 19 21:56:26 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21811 for ; Thu, 19 Apr 2001 21:56:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklmt08793; Fri, 20 Apr 2001 01:53:02 GMT Received: by mail-control.mail.uu.net id QQklmt11306 for mpls-outgoing; Fri, 20 Apr 2001 01:52:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklmt11298 for ; Fri, 20 Apr 2001 01:52:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklmt06854 for ; Fri, 20 Apr 2001 01:51:37 GMT Received: from sktelecom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQklmt19586 for ; Fri, 20 Apr 2001 01:51:35 GMT Received: from mrchang (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f3K1t3a16979 for ; Fri, 20 Apr 2001 10:55:03 +0900 (KST) Message-ID: <00e501c0c93c$2276b6c0$77131796@sktelecom.com> From: "Rae M. Chang" To: Subject: LSP Setup Algorithms Date: Fri, 20 Apr 2001 10:49:26 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01C0C987.91B80CA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00E2_01C0C987.91B80CA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkRvZXMgYW55b25lIGtub3cgdGhlIHJlZmVyZW5jZXMgdG8gZmluZGluZyBMU1Bz IGZvciBhIGdpdmVuIHRyYWZmaWMgZGVtYW5kcw0KYmV0d2VlbiAoaW5ncmVzcywgZWdyZXNzKSBw YWlycywgd2hlcmUgZWFjaCBMU1AgcmVxdWlyZXMgc29tZSB2YWx1ZSBvZiBsaW5rIGJhbmR3aWR0 aD8NCg0KSSB0aGluayB0aGF0IHRob3NlIHByb2JsZW1zIG1pZ2h0IGJlIGV4YWN0bHkgc2FtZSBh cyB0aGUgdHJhZGl0aW9uYWwgQVRNIFBWQyBzZXR1cC4NCklzIGl0IHRydWU/IFRoZW4sIGFueSBz dGFydGluZyBwb2ludHMgZm9yIHRoYXQga2luZCBvZiBwcm9ibGVtIHdpbGwgYmUgaGVscGZ1bCBm b3IgbXkgcmVzZWFyY2guDQpUaGFua3MgaW4gYWR2YW5jZS4NCg0KLVJhZQ0K ------=_NextPart_000_00E2_01C0C987.91B80CA0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj4N CjxESVY+SGVsbG8sPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5Eb2VzJm5ic3A7YW55 b25lIGtub3cgdGhlIHJlZmVyZW5jZXMgdG8gZmluZGluZyBMU1BzIGZvciBhIGdpdmVuIHRyYWZm aWMgDQpkZW1hbmRzPC9ESVY+DQo8RElWPmJldHdlZW4gKGluZ3Jlc3MsIGVncmVzcykgcGFpcnMs IHdoZXJlIGVhY2ggTFNQIHJlcXVpcmVzIHNvbWUgdmFsdWUgb2YgbGluayANCmJhbmR3aWR0aD88 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgdGhpbmsgdGhhdCB0aG9zZSBwcm9ibGVt cyBtaWdodCBiZSBleGFjdGx5IHNhbWUgYXMgdGhlIHRyYWRpdGlvbmFsIEFUTSANClBWQyBzZXR1 cC48L0RJVj4NCjxESVY+SXMgaXQgdHJ1ZT8gVGhlbiwgYW55IHN0YXJ0aW5nIHBvaW50cyBmb3Ig dGhhdCBraW5kIG9mIHByb2JsZW0gd2lsbCBiZSANCmhlbHBmdWwgZm9yIG15IHJlc2VhcmNoLjwv RElWPg0KPERJVj5UaGFua3MgaW4gYWR2YW5jZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPi1SYWU8L0RJVj48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_00E2_01C0C987.91B80CA0-- From owner-mpls@UU.NET Thu Apr 19 23:59:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23907 for ; Thu, 19 Apr 2001 23:59:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklnb03555; Fri, 20 Apr 2001 03:56:30 GMT Received: by mail-control.mail.uu.net id QQklnb26324 for mpls-outgoing; Fri, 20 Apr 2001 03:55:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklnb26316 for ; Fri, 20 Apr 2001 03:55:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklnb23356 for ; Fri, 20 Apr 2001 03:55:35 GMT From: ytr@123india.com Received: from c001.zsm.cp.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: c001-h003.c001.zsm.cp.net [209.228.56.117]) id QQklnb12791 for ; Fri, 20 Apr 2001 03:55:35 GMT Received: (cpmta 5040 invoked from network); 19 Apr 2001 20:55:34 -0700 Date: 19 Apr 2001 20:55:34 -0700 Message-ID: <20010420035534.5039.cpmta@c001.zsm.cp.net> X-Sent: 20 Apr 2001 03:55:34 GMT Received: from [132.233.247.5] by mail.123india.com with HTTP; 19 Apr 2001 20:55:34 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: Prabhu_B@in.huawei.com Cc: mpls@UU.NET X-Mailer: Web Mail 3.9.1.5 Subject: RE: Regarding Label stack X-Sent-From: ytr@123india.com Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 19 April 2001, Prabhugouda wrote: > > > Dear All, > > > > I have the following questions: > > 1. Does any one supports hierarchy in MPLS, label stacking? pls refer linux implemenation for this. U can get sources at http://sourceforge.net/projects/mpls-linux/ This supports Hierachical forwarding. > > 2. How does the ILM looks in case of label stacking? ILM is supposed to look on ILM table for top label. If operation of the top label is POP, Stack depth is >1 , then ILM look up is required for next label. This is recursive process till the operation of label is not POP or end of stack. Cheers, YTR > > > > Prabhu > > > > ---------------------------------------------------------------- > > Prabhugouda Biradar, > > Huawei Technology India Pvt. Ltd. > > Unit 10/11, Level 2, Innovator Block, > > Whitefield Road, > > Bangalore - 560 066. > > > > Office Tel. +91-80-8410061/753/755/1651. > > Mobile : +91-98440-84691. > > Res. Tel : +91-80-3520909. > > > > > > > > ______________________________________________________ 123India.com - India's Premier Portal Get your Free Email Account at http://www.123india.com From owner-mpls@UU.NET Fri Apr 20 01:15:33 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25348 for ; Fri, 20 Apr 2001 01:15:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklng05881; Fri, 20 Apr 2001 05:12:36 GMT Received: by mail-control.mail.uu.net id QQklng06850 for mpls-outgoing; Fri, 20 Apr 2001 05:12:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklng06839 for ; Fri, 20 Apr 2001 05:11:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklng22767 for ; Fri, 20 Apr 2001 05:11:09 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQklng19302 for ; Fri, 20 Apr 2001 05:11:07 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id KAA04398 for ; Fri, 20 Apr 2001 10:49:08 GMT Received: from soflt.alc.wipinfo.soft.net ([192.168.220.205]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GC2RYK00.PV2; Fri, 20 Apr 2001 10:45:56 +0530 Date: Fri, 20 Apr 2001 10:45:52 +0530 (IST) From: "chetan kumar s" X-Sender: chetansk@soflt.alc.wipinfo.soft.net Reply-To: chetan.kumar@wipro.com To: Bob Thomas cc: mpls@UU.NET Subject: Re: Label Aborting.. In-Reply-To: <200104191318.JAA07239@telescope.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > LAbR.6 handles the following situation: > > > MsgSource ------ LSR ------ R ... > > where: > > - LSR has received a label mapping for FEC from R; > - LSR has not yet sent a label mapping for FEC to MsgSource; Hi, hmm.. makes sense.. Thanks for clarifying.. Chetan S From owner-mpls@UU.NET Fri Apr 20 01:43:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28726 for ; Fri, 20 Apr 2001 01:43:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklku21351; Thu, 19 Apr 2001 13:07:51 GMT Received: by mail-control.mail.uu.net id QQklku21708 for mpls-outgoing; Thu, 19 Apr 2001 13:07:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklku21700 for ; Thu, 19 Apr 2001 13:07:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklku26961 for ; Thu, 19 Apr 2001 13:05:47 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQklku22470 for ; Thu, 19 Apr 2001 13:05:46 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 9FEA49400A; Thu, 19 Apr 2001 09:05:46 -0400 (EDT) Message-ID: <3ADEE2AA.75E26942@sandburst.com> Date: Thu, 19 Apr 2001 09:05:46 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: suchauhan@hss.hns.com Cc: mpls@UU.NET Subject: Re: A question. References: <65256A33.001AA3B7.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sumit, Oh well, I tried to keep this discussion off of the list... :-) Please see comments below. You wrote: > hi eric! > Thanx a lot for the clarification. You made perfect sense here but I still > have a few points that are embedded below as > *****sumit**** > > regards > sumit > > Eric Gray on 04/18/2001 08:13:45 PM > > To: Sumit Chauhan/HSS@HSS > cc: > > Subject: Re: A question. > > Sumit, > > There are plenty of examples of ways in which you can > establish LSPs (and therefore FECs) based on packets > you receive. As you point out, the mechanisms exist to > support creation of an LSP on pretty much any basis you > care to imagine. > > But there are implications of doing what you suggest. > A very similar suggestion was made about a year ago and > it got mostly the silent treatment. Bad history and other > things worked against it then and will undoubtedly work > against it again. > > The fundamtental issue is that - at least for normal IP > packets - you either use topology driven or flow driven > path setup. There is no reason to have both. > > Look at it this way: if you are using topology based > LSP setup and don't have a FEC for a packet, then you > don't have a route for it either. Who are you going to > ask for a label from? Are you going to ask for a label > for a host address or 32 bit address prefix, or are you > going to try to guess what an appropriate prefix length > would be? If you did have a route, then you are waiting > for a label from the next hop (either because you asked > for it already, or because the next hop is supposed to > send one without you asking) or you already know you > are not going to get one - therefore, why would you ask > for one just because you have a packet? What happens > when you get another packet - do you send yet another > request? > ******sumit******** > few points here are > 1. this means that the actual setup of the LSP shall happen once the network(its > routers ) come up and exchange the initial routes (using some IGP) and then > reach their stable state. Till the point they have first echanged the routes and > exchanged lables(set up the LSPs) there can be no MPLS based forwarding > possible. That is perfectly all right. Using the optimal label distribution solution for a given network deployment, and assuming that IP forwarding is possible without labels, MPLS based forwarding lags IP based forwarding by a little bit. This 'little bit' can be as little as zero in the case where labels are distributed (piggyback) with route advertisements. Whatever this little bit is, it is unavoidable - therefore, it is good that it is also acceptable. ;-) > > > 2. From this it seems that "unsolicited downstream" seems to be the most logical > solution as it is simpler for each LSR to generate lables to its > directly-connected routes as I do not see any real value add in a upstream LSR > asking for a label in this scenario. The choice of whether downstream unsolicited (DU) or downstream on demand (DoD) is used is more often a result of the label retention mode that makes sense for the technology that connects a pair of LSRs. What might be argued on the basis of the lag between IP forwarding and MPLS forwarding is whether or not to use ordered or independent control. However, this choice should also depend on the capability of an LSR that will eventually end up being an intermediate LSR, in any given LSP, to forward IP packets to the correct next hop if it: receives labeled packets from an LSR peer to which it has independently distributed labels and has not yet received a corresponding label from the correct next hop. In this case, there is some cost to the system if the LSR distributes labels independently but is required to drop labeled packets until it receives a useful label from the next hop for the LSP. So, the decision as to what control mode an individual LSR will use and whether to use DU or DoD label distribution involves more than the concern over the lag between IP and MPLS forwarding capability. > > > 3. The other point is that it is a pretty simple solution once we are > considering the topology based forwarding but in case we have to do flow based > forwarding and along with that we want to have resource reservation. In that > scenario I always beleived it should be something like "label on demand only and > when needed only" because else we may land up reserving resources we may no use > later. But I am sure I might be missing something here. Please clarify. The currently defined signaling methods for setup of non-best-effort label switched paths have at least three things in common: 1 use of ordered control 2 use of downstream on demand 3 availability of path directing capability I don't necessarily agree that any of these things will always be necessary in setting up LSPs with contractual resource requirements. > > > 4. The other problem that strikes me here is that almost all routers also > maintain "default routes". As you suggested that "whom do we ask for a lable if > we dont have an FEC?" so is there a concept of "default FEC as well". Maybe one > with prefix "0"? I could be wrong, but I do not believe that it is the normal case for routers to have default routes for the context in which they are routers. I think it is common for hosts to have a default route to get them to a router. I believe it is also common for an interior router to have a default route to an exterior gateway router in certain deployments. But I believe that - for example - interior routers having default routes to other interior routers is a good way to turn IP packet forwarding into a form of finger pointing exercise. > > ******************** > Suppose you do know both the next hop and (AIBM) > the correct prefix length (AIBM) and you send a request > for a label. You've simply passed the problem on to the > next hop. > > So, you might ask, what if I have a route entry and I > know the next hop and the right FEC to ask for? Why > can't I wait until I actually have a packet to request a > label? The answer is real simple: there's absolutely > no reason to do so and every reason not to do so. > > The topology based setup defined in MPLS is every > bit as scalable as the routing it is based on - so you > don't gain any advantage from not having to setup an > LSP that you'll never use. Nor is it very likely, in most > real network deployments, that there will be instances > of such LSPs in the first place. > > Delaying LSP setup until a packet is received is one > great way to place a strain on routing implementations > and drop a lot of packets. However many packets may > be dropped (for a particular stream) while I wait for the > topology based setup to complete (for that stream) will > be increased by the amount of time it takes me to get > the first packet for that stream. And topology based > setup can be even faster if using independent control. > With topology based LSP setup, most streams will not > see a single packet drop as a result of not having an LSP > setup already. With flow based LSP setup, at least one > stream for each FEC will see at least one packet drop. > ******sumit***** > Point well taken here. But again I think things should seem diffrently if we > look at an FEC that has not just destiation address and prefix but things for > QoS and CoS incl. resourse reservation. Check out drafts available at: http://www.ietf.org/ids.by.wg/mpls.html > > **************** > -- > Eric > From owner-mpls@UU.NET Fri Apr 20 03:39:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08524 for ; Fri, 20 Apr 2001 03:39:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklnq00246; Fri, 20 Apr 2001 07:36:38 GMT Received: by mail-control.mail.uu.net id QQklnq23548 for mpls-outgoing; Fri, 20 Apr 2001 07:36:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklnq23477 for ; Fri, 20 Apr 2001 07:35:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklnq07582 for ; Fri, 20 Apr 2001 07:35:32 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklnq28659 for ; Fri, 20 Apr 2001 07:35:31 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA00164 for mpls@uu.net; Fri, 20 Apr 2001 03:35:31 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklnq23371 for ; Fri, 20 Apr 2001 07:34:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklnq29266 for ; Fri, 20 Apr 2001 07:32:34 GMT Received: from salamander.eu.fore.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: salamander.eu.fore.com [193.132.138.12]) id QQklnq24976 for ; Fri, 20 Apr 2001 07:32:33 GMT Received: from gbennett-pc (compuserve-45-36.pit.comms.marconi.com [169.144.45.36]) by salamander.eu.fore.com (8.9.1/8.9.1) with SMTP id IAA07500; Fri, 20 Apr 2001 08:31:30 +0100 (BST) Message-Id: <200104200731.IAA07500@salamander.eu.fore.com> X-Sender: gbennett@salamander.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 20 Apr 2001 08:55:54 +0100 To: "Kavi, Prabhu" , "Donkin, Richard" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET From: Geoff Bennett Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? In-Reply-To: <6B190B34070BD411ACA000B0D0214E56CB7F0F@newman.tenornet.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Prabhu, >Your generalization about "loss making Internet Services" is >foolish. Yes, this is a foolishness I share with quite a lot of financial analysts :-) >Several years ago, somebody forgot to tell UUNET that they >were selling loss making Internet services, and they hit >break-even during a period of explosive growth (very hard to >do). I think it is fair to say they are quite profitable >for Worldcom today. UUNET's success has a lot to do with hiring top notch staff, and also having a flexible strategy that takes into account emerging technologies. I'm a great admirer actually because they have been amongst the more aggressive carriers in terms of MPLS piloting. BUT...there is a big difference between wholesale and retail IP sales. I'm talking about IP Services, not raw bandwidth. You need to be aware of the regulatory differences between the US and the rest of the world. While we are all in various stages of deregulation, only in the US did the Telecommunications Act create a legal framework of IXCs, ILECs and CLECs. In contrast in Europe, there are "carriers' carriers", sure, but very often these businesses mix in the notion of retail services, as well as wholesale. In general most people would agree that wholesale bandwidth operation has historically been more profitable than retail. In fact in some cases the wholesale business is profitable enough to offset the losses from retail and allow the company to demonstrate overall profitability. This was helped by generous vendor financing during the "happy time". The problem is that a wholesale market can only maintain price (or profitability) levels while its retail customers are able to stay in business, and that situation is now coming into question. >I also know for a fact that several other large ISPs are >profitable as well, but they are part of larger organizations >that do not publicly break out the P+L of each division. You must have access to information that I don't. Where the P&Ls are combined, isn't this information confidential? One of the sources of debate in this area is that it's so difficult to substatiate these sort of claims, isn't it? >No doubt, ISPs could do better by offering a range of services, >some of which promise higher service quality. But if a service >provider is going to start providing higher revenue services >today, why in the world would they want to do it over ATM >switches? No reason really...except that ATM is the infrastructure that's running today just fine...and supports the services the SPs need in order to be profitable. These days, if your MPLS vendor declines to buy their equipment for you, then ATM is a great alternative as you can demonstrate a real ROI within a sensible timescale. Please forgive me if I appear to be bashing MPLS...I don't intend to. My point is that claims are being made about the technology that are rather exaggerated. This kind of hype ultimately hurts any technology (history teaches us this about FDDI, ISDN, SMDS, ATM, ADSL, etc.). MPLS could be as good as ATM one day. In fact it could be so much better because MPLS is not tied to a single underlying technology. Cheers, Geoff >> -----Original Message----- >> From: Geoff Bennett [mailto:geoff.bennett@marconi.com] >> Sent: Thursday, April 19, 2001 12:20 PM >> To: Donkin, Richard; MP LS; mpls-ops@mplsrc.com; mpls@UU.NET >> Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? >> >> >> Hi Richard, >> Please read my post carefully. Internet services are >> generally intended to >> mean "best effort". In contrast VPN services are supposed to >> carry some >> kind of added value. In other words, I fully accept that IP >> VPNs should >> make more money than a basic Internet service. >> >> But as I understand it, the added value from IP VPNs either comes from >> security (whether this is "isolational" in nature like an ATM or Frame >> Relay VPN, or "truly secure" as in the case of an ecrypted >> ATM or IPSec VPN >> is up to the user), or from "perceived service enhancement". >> The latter >> could be via a CoS mechanism, which MPLS can potentially >> offer, or from a >> hard QoS mechanism which can only be offered from... >> >> a: A TDM mechanism (like SONET/SDH, which is expensive). >> b: A native ATM service. >> c: An over-provisioned stat mux service (eg. IP), which is >> also expensive >> in the long term. >> >> I know that Orchestream's core business is based on the provision of >> services over an MPLS core, so this may be akin to asking a >> barber if he >> thinks I need a haircut, but is there any evidence that IP >> VPN services are >> "truly profitable" (as opposed to "press release" >> profitable)? the problem >> is that asking most SPs this question will result in "sorry, >> this is very >> confidential information" responses. >> >> I'm not trying to bang a vendor drum here, I'm truly >> interested because of >> the fact that about a dozen European SPs are technically bankrupt from >> being too dependent on IP services ever making money. >> >> Cheers, >> Geoff >> >> >> At 19:38 18/04/01 +0100, Donkin, Richard wrote: >> > >> > >> >> -----Original Message----- >> >> From: Geoff Bennett [mailto:geoff.bennett@marconi.com] >> >> Sent: 18 April 2001 11:15 >> >> >> To: MP LS; mpls-ops@mplsrc.com; mpls@uu.net >> >> Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? >> >> >> >> >> >> Hi Niels, >> >> >> >> There may be some confusion arising depending on how you >> >> configure the ATM >> >> switch. In effect there are three modes of operation for >> >> this device... >> >> >> >> 3. Ships in the Night (SIN). In this case, both ATM and >> MPLS Control >> >> Planes operate simultaneously. ATM signalling happens on VCI >> >> 5, and MPLS >> >> signalling on VCI 32. VCs that are set up as a result of >> >> signalling are >> >> "owned" by one or other of these control planes. SIN >> would allow an >> >> operator to continue to run high revenue voice services (and >> >> maybe existing >> >> Frame Relay or native ATM services...they make money too) >> >> over the ATM >> >> "character" of the switch. They can then run the >> loss-making Internet >> > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> services over the MPLS character. >> >^^^^^^^^^^ >> > >> >Very amusing... I'm sure this was just flame-bait, but first >> of all, MPLS >> >supports IP services, not just Internet traffic, and you can >> of course run >> >highly profitable IP VPN services over MPLS. >> > >> >Ultimately, ATM/FR services (as seen by the customer) may >> well be carried >> >over an MPLS core, particularly as MPLS becomes one of the >> key signalling >> >mechanisms for all-optical core networks, but since much of >> the traffic >> >running over ATM/FR is actually IP, it may be simpler to >> deliver IP VPNs >> >directly to the customer premises. >> > >> >> Cheers, >> >> Geoff >> > >> >Richard Donkin >> >T: +44 (0)20 7348 1507 >> >Orchestream >> >Avon House, Kensington Village, Avonmore Road, London W14 8TS >> >T: +44 (0)20 7348 1500 F: +44 (0)20 7348 1501 >> >www.orchestream.com >> > >> > >> >-- >> >This communication contains confidential information >> intended solely for >> the use of the individual/s and/or entity or entities to whom it was >> intended to be addressed. If you are not the intended >> recipient, be aware >> that any disclosure, copying, distribution, or use of the >> contents of this >> transmission is prohibited. If you have received this >> communication in >> error, please contact the sender immediately, delete this >> communication >> from your system, and do not disclose its contents to any >> third party, or >> use its contents. Any opinions expressed are solely those of >> the author >> and do not necessarily represent those of Orchestream Ltd or >> its group of >> companies unless otherwise specifically stated. >> > >> >------- >> >The MPLS-OPS Mailing List >> >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >> >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >> > >> ================================================================ >> Geoff Bennett >> Tel: (33) 497 21 43 62 >> Director of Technology, OCTO >> Fax: (33) 497 21 43 50 >> Marconi >> Gaia - Bat. E >> email: geoff.bennett@marconi.com >> BP 123 >> 06903 SOPHIA ANTIPOLIS >> FRANCE >> ================================================================ >> >> > ================================================================ Geoff Bennett Tel: (33) 497 21 43 62 Director of Technology, OCTO Fax: (33) 497 21 43 50 Marconi Gaia - Bat. E email: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ From owner-mpls@UU.NET Fri Apr 20 03:43:12 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08544 for ; Fri, 20 Apr 2001 03:43:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklnq23176; Fri, 20 Apr 2001 07:40:02 GMT Received: by mail-control.mail.uu.net id QQklnq23725 for mpls-outgoing; Fri, 20 Apr 2001 07:39:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklnq23717 for ; Fri, 20 Apr 2001 07:39:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklnq00214 for ; Fri, 20 Apr 2001 07:39:16 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklnq03903 for ; Fri, 20 Apr 2001 07:39:15 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA00390 for mpls@uu.net; Fri, 20 Apr 2001 03:39:15 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklnq23367 for ; Fri, 20 Apr 2001 07:34:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklnq28856 for ; Fri, 20 Apr 2001 07:32:26 GMT Received: from salamander.eu.fore.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: salamander.eu.fore.com [193.132.138.12]) id QQklnq24779 for ; Fri, 20 Apr 2001 07:32:24 GMT Received: from gbennett-pc (compuserve-45-36.pit.comms.marconi.com [169.144.45.36]) by salamander.eu.fore.com (8.9.1/8.9.1) with SMTP id IAA07504; Fri, 20 Apr 2001 08:31:39 +0100 (BST) Message-Id: <200104200731.IAA07504@salamander.eu.fore.com> X-Sender: gbennett@salamander.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 20 Apr 2001 09:09:57 +0100 To: "Donkin, Richard" , "Donkin, Richard" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET From: Geoff Bennett Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Richard, At 18:14 19/04/01 +0100, Donkin, Richard wrote: >> From: Geoff Bennett [mailto:geoff.bennett@marconi.com] >... >> ... In other words, I fully accept that IP VPNs should >> make more money than a basic Internet service. > >Good to hear :) Even though they make more money than "best effort" IP, it's still not clear that ISPs are actually operating at a profit. I think that Prabhu Kavi's post highlighted the difficulty of getting down to the true state of affairs here. I think I'm right in saying that all independent, pure ISPs (not the ones who are becoming ASPs) operate at a loss. Wholesale business can be profitable if they are well run. Where wholesale and retail are mixed, the accountants can shuffle the numbers from one column to another, but the detailed breakdown in confidential. If anyone wants to confirm this, you can stump up the cash for Infonetics' roll call of European ISPs (http://www.infonetics.com). This lists services provided, and the revenues. It's not comprehensive, there are only 70 companies on the report and there are at least three times that number of SPs in Europe alone. > >> But as I understand it, the added value from IP VPNs either comes from >> security (whether this is "isolational" in nature like an ATM or Frame >> Relay VPN, or "truly secure" as in the case of an ecrypted ATM or IPSec >VPN >> is up to the user), or from "perceived service enhancement". > >Many operators are initially interested in the VPN service, i.e. isolational >security - QoS/CoS is seen as a supplement, particularly since it requires >CE management, and is therefore harder to scale, and requires >customer-specific classification/marking, which means more involvement with >customer requirements than a non-CoS VPN service. In other words, something >like today's successful Frame Relay services, but with better provisioning >scalability for the provider, and the option of adding QoS/CoS services on >top. > >> The latter could be via a CoS mechanism, which MPLS can potentially >> offer, or from a hard QoS mechanism which can only be offered from... >> >> a: A TDM mechanism (like SONET/SDH, which is expensive). >> b: A native ATM service. >> c: An over-provisioned stat mux service (eg. IP), which is also expensive >> in the long term. > >I'm not clear about the current market for hard-QoS services (partly because >of the CoS factors above, plus the extra QoS parameters that must be >specified, again with customer input), but MPLS TE + CoS features does >enable firmer QoS than currently possible with IP alone. Comparison with ATM >QoS is probably a religious issue, and left as an exercise to the reader... > > > I know that Orchestream's core business is based on the provision of >> services over an MPLS core, so this may be akin to asking a >> barber if he >> thinks I need a haircut, but is there any evidence that IP >> VPN services are >> "truly profitable" (as opposed to "press release" >> profitable)? the problem >> is that asking most SPs this question will result in "sorry, >> this is very >> confidential information" responses. > >Information on profitability is of course hard to come by, and I am on the >technical side not business, but I don't see why MPLS VPNs cannot be more >profitable than the equivalent Frame Relay services, given better >scalability, simpler provisioning (particularly if non-CoS), etc. In fact, >MPLS VPNs can be delivered as FR services, e.g. AT&T's 'IP enabled Frame >Relay' which is really an MPLS VPN service internally. I agree. I just haven't seen the figures broken out to prove it yet. The initial implementations of MPLS VPNs seem to be very admin-intensive, while the NMS tools for Frame Relay and ATM VPNs are very well established. Cheers, Geoff > >Cheers, > >Richard > >> >> At 19:38 18/04/01 +0100, Donkin, Richard wrote: >> > >> > >> >> -----Original Message----- >> >> From: Geoff Bennett [mailto:geoff.bennett@marconi.com] >> >> Sent: 18 April 2001 11:15 >> >> >> To: MP LS; mpls-ops@mplsrc.com; mpls@uu.net >> >> Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? >> >> >> >> >> >> Hi Niels, >> >> >> >> There may be some confusion arising depending on how you >> >> configure the ATM >> >> switch. In effect there are three modes of operation for >> >> this device... >> >> >> >> 3. Ships in the Night (SIN). In this case, both ATM and >> MPLS Control >> >> Planes operate simultaneously. ATM signalling happens on VCI >> >> 5, and MPLS >> >> signalling on VCI 32. VCs that are set up as a result of >> >> signalling are >> >> "owned" by one or other of these control planes. SIN >> would allow an >> >> operator to continue to run high revenue voice services (and >> >> maybe existing >> >> Frame Relay or native ATM services...they make money too) >> >> over the ATM >> >> "character" of the switch. They can then run the >> loss-making Internet >> > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> services over the MPLS character. >> >^^^^^^^^^^ >> > >> >Very amusing... I'm sure this was just flame-bait, but first >> of all, MPLS >> >supports IP services, not just Internet traffic, and you can >> of course run >> >highly profitable IP VPN services over MPLS. >> > >> >Ultimately, ATM/FR services (as seen by the customer) may >> well be carried >> >over an MPLS core, particularly as MPLS becomes one of the >> key signalling >> >mechanisms for all-optical core networks, but since much of >> the traffic >> >running over ATM/FR is actually IP, it may be simpler to >> deliver IP VPNs >> >directly to the customer premises. >> > >> >> Cheers, >> >> Geoff >> > >> >Richard Donkin >> >T: +44 (0)20 7348 1507 >> >Orchestream >> >Avon House, Kensington Village, Avonmore Road, London W14 8TS >> >T: +44 (0)20 7348 1500 F: +44 (0)20 7348 1501 >> >www.orchestream.com >> > >> > >> >-- >> >This communication contains confidential information >> intended solely for >> the use of the individual/s and/or entity or entities to whom it was >> intended to be addressed. If you are not the intended >> recipient, be aware >> that any disclosure, copying, distribution, or use of the >> contents of this >> transmission is prohibited. If you have received this >> communication in >> error, please contact the sender immediately, delete this >> communication >> from your system, and do not disclose its contents to any >> third party, or >> use its contents. Any opinions expressed are solely those of >> the author >> and do not necessarily represent those of Orchestream Ltd or >> its group of >> companies unless otherwise specifically stated. >> > >> >------- >> >The MPLS-OPS Mailing List >> >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >> >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >> > >> ================================================================ >> Geoff Bennett >> Tel: (33) 497 21 43 62 >> Director of Technology, OCTO >> Fax: (33) 497 21 43 50 >> Marconi >> Gaia - Bat. E >> email: geoff.bennett@marconi.com >> BP 123 >> 06903 SOPHIA ANTIPOLIS >> FRANCE >> ================================================================ >> >> ------- >> The MPLS-OPS Mailing List >> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >> > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > ================================================================ Geoff Bennett Tel: (33) 497 21 43 62 Director of Technology, OCTO Fax: (33) 497 21 43 50 Marconi Gaia - Bat. E email: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ From owner-mpls@UU.NET Fri Apr 20 03:51:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08601 for ; Fri, 20 Apr 2001 03:51:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklnr27485; Fri, 20 Apr 2001 07:46:49 GMT Received: by mail-control.mail.uu.net id QQklnr24761 for mpls-outgoing; Fri, 20 Apr 2001 07:46:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklnr24708 for ; Fri, 20 Apr 2001 07:45:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklnr24371 for ; Fri, 20 Apr 2001 07:45:09 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklnr11341 for ; Fri, 20 Apr 2001 07:45:09 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA01297 for mpls@uu.net; Fri, 20 Apr 2001 03:45:09 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklnq24317 for ; Fri, 20 Apr 2001 07:44:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklnq16346 for ; Fri, 20 Apr 2001 07:42:14 GMT Received: from salamander.eu.fore.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: salamander.eu.fore.com [193.132.138.12]) id QQklnq07615 for ; Fri, 20 Apr 2001 07:42:09 GMT Received: from gbennett-pc (compuserve-45-36.pit.comms.marconi.com [169.144.45.36]) by salamander.eu.fore.com (8.9.1/8.9.1) with SMTP id IAA07772; Fri, 20 Apr 2001 08:40:44 +0100 (BST) Message-Id: <200104200740.IAA07772@salamander.eu.fore.com> X-Sender: gbennett@salamander.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 20 Apr 2001 09:39:31 +0100 To: "HANSEN CHAN" From: Geoff Bennett Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? Cc: "Donkin, Richard" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <3ADF0A03.8BD22C57@alcatel.com> References: <200104191511.QAA03690@salamander.eu.fore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Hansen, I agree with you in general...MPLS should be able to demonstrate similar capabilities to ATM QoS, but I think most people would agree there's a long way to go yet, especially for the routing protocols. There's also the problem that nobody is yet building LSRs that were designed for the job. They're all adaptations of either a router or an ATM switch design. Hard QoS architectures are hard to build. ATM got it right for the most part, but there would be a strong argument that the way ATM does QoS (on a VC basis) will not scale to networks as big as the Internet. With MPLS we can aggregate things nicely, but in my mind this is not QoS, it's CoS. The tradeoff we seem to be faced with is the "quality" of our QoS architecture vs its scalability. ATM also has the advantage that it's Connection Oriented from end to end. One of the reasons it can deliver such a hard QoS assurance was that the application itself is able to negotiate with the network to ask for the explicit QoS requirements, and to get the network's agreement that these resources were available. To duplicate this with MPLS we'd have to extend RSVP signalling to the host (or maybe to the voice gateway in a VoMPLS installation). I know this has been discussed, but is at a very early stage. Another advantage of ATM in terms of QoS is the fixed cell size. Any fixed-PDU technology will have the edge over a variable PDU technology when it comes to QoS. Before I ignite a cells vs frames debate let me say that I believe the (many) advantages of a variable length PDU infrastructure (especially at very high speeds) outweight the QoS benefits of fixed PDU. In other words, I'll go along with the assumption that if you're transmitting at a high enough speed, the CoS you can squeeze out of a variable PDU network will one day be "good enough" (if you over-provision the network sufficiently). Cheers, Geoff At 11:53 19/04/01 -0400, HANSEN CHAN wrote: >> But as I understand it, the added value from IP VPNs either comes from >> security (whether this is "isolational" in nature like an ATM or Frame >> Relay VPN, or "truly secure" as in the case of an ecrypted ATM or IPSec VPN >> is up to the user), or from "perceived service enhancement". The latter >> could be via a CoS mechanism, which MPLS can potentially offer, or from a >> hard QoS mechanism which can only be offered from... >> >> a: A TDM mechanism (like SONET/SDH, which is expensive). >> b: A native ATM service. >> c: An over-provisioned stat mux service (eg. IP), which is also expensive >> in the long term. > >Geoff, > >I agree with your points above. However, I don't think there is anything stop MPLS implemented with a hard QoS mechanism like ATM >has done. A good LSR with the necessary traffic management infrastructure (queuing and scheduling) can achieve the same level, if >not better QoS. > >Cheers, >Hansen > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > ================================================================ Geoff Bennett Tel: (33) 497 21 43 62 Director of Technology, OCTO Fax: (33) 497 21 43 50 Marconi Gaia - Bat. E email: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ From owner-mpls@UU.NET Fri Apr 20 04:29:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08887 for ; Fri, 20 Apr 2001 04:29:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklnt02240; Fri, 20 Apr 2001 08:26:52 GMT Received: by mail-control.mail.uu.net id QQklnt15553 for mpls-outgoing; Fri, 20 Apr 2001 08:26:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklnt15548 for ; Fri, 20 Apr 2001 08:26:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklnt24033 for ; Fri, 20 Apr 2001 08:25:08 GMT From: utthan.nakarmi@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQklnt28648 for ; Fri, 20 Apr 2001 08:25:08 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Fri, 20 Apr 2001 09:22:43 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <1PP80C1D>; Fri, 20 Apr 2001 09:22:18 +0100 Message-ID: To: mpls@UU.NET Subject: MPLS-multicast Date: Fri, 20 Apr 2001 09:17:17 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Dear all, Would you be able to provide any information on MPLS multicast?Thanks in advance. regards Utthan From owner-mpls@UU.NET Fri Apr 20 05:13:23 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09234 for ; Fri, 20 Apr 2001 05:13:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklnw25930; Fri, 20 Apr 2001 09:10:39 GMT Received: by mail-control.mail.uu.net id QQklnw07938 for mpls-outgoing; Fri, 20 Apr 2001 09:10:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklnw07884 for ; Fri, 20 Apr 2001 09:09:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklnw07215 for ; Fri, 20 Apr 2001 09:08:58 GMT Received: from samar.sasken.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQklnw15202 for ; Fri, 20 Apr 2001 09:08:50 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f3K98hb07043; Fri, 20 Apr 2001 14:38:43 +0530 (IST) Received: from localhost (soumen@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id OAA07048; Fri, 20 Apr 2001 14:37:50 +0530 (IST) Date: Fri, 20 Apr 2001 14:37:50 +0530 (IST) From: Soumen Sarkar X-Sender: To: cc: Subject: Re: MPLS-multicast In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk You possibly should look into PIM work-group activities. -regards, Soumen On Fri, 20 Apr 2001 utthan.nakarmi@bt.com wrote: > Date: Fri, 20 Apr 2001 09:17:17 +0100 > From: utthan.nakarmi@bt.com > To: mpls@UU.NET > Subject: MPLS-multicast > > Dear all, > > Would you be able to provide any information on MPLS multicast?Thanks in > advance. > > regards > Utthan > From owner-mpls@UU.NET Fri Apr 20 05:44:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09531 for ; Fri, 20 Apr 2001 05:44:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklny04976; Fri, 20 Apr 2001 09:42:09 GMT Received: by mail-control.mail.uu.net id QQklny10368 for mpls-outgoing; Fri, 20 Apr 2001 09:41:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklny10360 for ; Fri, 20 Apr 2001 09:41:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklny14475 for ; Fri, 20 Apr 2001 09:40:42 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklny02528 for ; Fri, 20 Apr 2001 09:40:41 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA06593 for mpls@uu.net; Fri, 20 Apr 2001 05:40:41 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklny10054 for ; Fri, 20 Apr 2001 09:36:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklny25572 for ; Fri, 20 Apr 2001 09:33:58 GMT Received: from mail.korea.ac.kr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: korea.ac.kr [163.152.1.251]) id QQklny24261 for ; Fri, 20 Apr 2001 09:33:57 GMT Received: from mail-virus (smtp.korea.ac.kr [163.152.1.128]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id SAA52672; Fri, 20 Apr 2001 18:24:09 +0900 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3K9XMG02291; Fri, 20 Apr 2001 05:33:22 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-Id: <200104200740.IAA07772@salamander.eu.fore.com> X-Sender: gbennett@salamander.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 20 Apr 2001 09:39:31 +0100 To: "HANSEN CHAN" From: Geoff Bennett Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? Cc: "Donkin, Richard" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <3ADF0A03.8BD22C57@alcatel.com> References: <200104191511.QAA03690@salamander.eu.fore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: archive/latest/1018 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk Hi Hansen, I agree with you in general...MPLS should be able to demonstrate similar capabilities to ATM QoS, but I think most people would agree there's a long way to go yet, especially for the routing protocols. There's also the problem that nobody is yet building LSRs that were designed for the job. They're all adaptations of either a router or an ATM switch design. Hard QoS architectures are hard to build. ATM got it right for the most part, but there would be a strong argument that the way ATM does QoS (on a VC basis) will not scale to networks as big as the Internet. With MPLS we can aggregate things nicely, but in my mind this is not QoS, it's CoS. The tradeoff we seem to be faced with is the "quality" of our QoS architecture vs its scalability. ATM also has the advantage that it's Connection Oriented from end to end. One of the reasons it can deliver such a hard QoS assurance was that the application itself is able to negotiate with the network to ask for the explicit QoS requirements, and to get the network's agreement that these resources were available. To duplicate this with MPLS we'd have to extend RSVP signalling to the host (or maybe to the voice gateway in a VoMPLS installation). I know this has been discussed, but is at a very early stage. Another advantage of ATM in terms of QoS is the fixed cell size. Any fixed-PDU technology will have the edge over a variable PDU technology when it comes to QoS. Before I ignite a cells vs frames debate let me say that I believe the (many) advantages of a variable length PDU infrastructure (especially at very high speeds) outweight the QoS benefits of fixed PDU. In other words, I'll go along with the assumption that if you're transmitting at a high enough speed, the CoS you can squeeze out of a variable PDU network will one day be "good enough" (if you over-provision the network sufficiently). Cheers, Geoff At 11:53 19/04/01 -0400, HANSEN CHAN wrote: >> But as I understand it, the added value from IP VPNs either comes from >> security (whether this is "isolational" in nature like an ATM or Frame >> Relay VPN, or "truly secure" as in the case of an ecrypted ATM or IPSec VPN >> is up to the user), or from "perceived service enhancement". The latter >> could be via a CoS mechanism, which MPLS can potentially offer, or from a >> hard QoS mechanism which can only be offered from... >> >> a: A TDM mechanism (like SONET/SDH, which is expensive). >> b: A native ATM service. >> c: An over-provisioned stat mux service (eg. IP), which is also expensive >> in the long term. > >Geoff, > >I agree with your points above. However, I don't think there is anything stop MPLS implemented with a hard QoS mechanism like ATM >has done. A good LSR with the necessary traffic management infrastructure (queuing and scheduling) can achieve the same level, if >not better QoS. > >Cheers, >Hansen > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > ================================================================ Geoff Bennett Tel: (33) 497 21 43 62 Director of Technology, OCTO Fax: (33) 497 21 43 50 Marconi Gaia - Bat. E email: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Fri Apr 20 06:06:59 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09737 for ; Fri, 20 Apr 2001 06:06:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloa00733; Fri, 20 Apr 2001 10:04:13 GMT Received: by mail-control.mail.uu.net id QQkloa24241 for mpls-outgoing; Fri, 20 Apr 2001 10:03:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkloa22738 for ; Fri, 20 Apr 2001 10:03:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkloa21339 for ; Fri, 20 Apr 2001 10:03:04 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkloa29335 for ; Fri, 20 Apr 2001 10:03:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA07846 for mpls@uu.net; Fri, 20 Apr 2001 06:03:04 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkloa21948 for ; Fri, 20 Apr 2001 10:02:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkloa28695 for ; Fri, 20 Apr 2001 10:02:06 GMT Received: from sj-msg-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQkloa28211 for ; Fri, 20 Apr 2001 10:02:05 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id DAA22614; Fri, 20 Apr 2001 03:00:42 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f3KA1xW06730; Fri, 20 Apr 2001 03:01:59 -0700 (PDT) Message-ID: <3AE008B7.5E64D973@cisco.com> Date: Fri, 20 Apr 2001 03:00:23 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Soumen Sarkar CC: utthan.nakarmi@bt.com, mpls@UU.NET Subject: Re: MPLS-multicast References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Or at Dino's draft: http://search.ietf.org/internet-drafts/draft-farinacci-mpls-multicast-03.txt R. > Soumen Sarkar wrote: > > You possibly should look into PIM work-group activities. > -regards, > Soumen > > On Fri, 20 Apr 2001 utthan.nakarmi@bt.com wrote: > > > Date: Fri, 20 Apr 2001 09:17:17 +0100 > > From: utthan.nakarmi@bt.com > > To: mpls@UU.NET > > Subject: MPLS-multicast > > > > Dear all, > > > > Would you be able to provide any information on MPLS multicast?Thanks in > > advance. > > > > regards > > Utthan > > From owner-mpls@UU.NET Fri Apr 20 08:42:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11013 for ; Fri, 20 Apr 2001 08:42:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklok12713; Fri, 20 Apr 2001 12:39:48 GMT Received: by mail-control.mail.uu.net id QQklok17860 for mpls-outgoing; Fri, 20 Apr 2001 12:39:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklok17840 for ; Fri, 20 Apr 2001 12:39:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklok19829 for ; Fri, 20 Apr 2001 12:38:46 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQklok11382 for ; Fri, 20 Apr 2001 12:38:46 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id F16D894009; Fri, 20 Apr 2001 08:38:39 -0400 (EDT) Message-ID: <3AE02DCF.7417B247@sandburst.com> Date: Fri, 20 Apr 2001 08:38:39 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: <200104191848.OAA06410@erosen-sun.cisco.com> <3ADF7135.7E1FC41@marconi.com> <3ADF767B.88B4D120@sandburst.com> <3ADF7A18.CE7891BA@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, I'm sure some smart person or another has written a paper on this, but I don't have the time to do a full-blown literature search right now. While what you are saying is technically true, I believe it has very little applicability in practice. You can see that this works by imagining that an implementation might treat MTU propagation time exactly the same way that ATM treats cell propagation time. But this is very ugly. It is so coarse that many would be hard pressed to consider it a useful guarantee. It also seems to require deliberately inserting latency (N times an MTU propagation time) for all affected traffic (to allow for packet shuffling to accomodate the guarantee). And it would be very difficult to allocate forwarding resources efficiently and still deliver guaranteed delay variation deterministically. Without making any moral judgement about why it is so, many people are more concerned about having a bounded delay than they are about having a bounded delay variation. And with a bounded delay, you get bounded delay variation for free. My opinion: there are two models here and trying to make technologies support both models may not be a good idea. -- Eric Gray You wrote: > Eric Gray wrote: > > > > You can't exactly do ATM style QoS over non-ATM media. > > > > The thing that allows an ATM switch to contemplate delay > > variation separately from delay is the fact that ATM switches > > switch data in fixed size chunks. When the size of data chunks > > can vary, the only practical way to control delay variation is to > > try to control delay. Therefore, with IP packets on non-ATM > > media, you can't even begin support two knobs for delay and > > delay variation. So why would you undertake to add complexity > > by trying? > > Variable-size frames don't make it impossible. It just means you are > forced to work with a coarser granularity (defined by your configured > MTU size.) > > -- david From owner-mpls@UU.NET Fri Apr 20 08:45:15 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11044 for ; Fri, 20 Apr 2001 08:45:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklok25166; Fri, 20 Apr 2001 12:42:38 GMT Received: by mail-control.mail.uu.net id QQklok18251 for mpls-outgoing; Fri, 20 Apr 2001 12:42:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklok18231 for ; Fri, 20 Apr 2001 12:41:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklok29323 for ; Fri, 20 Apr 2001 12:40:52 GMT Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQklok14386 for ; Fri, 20 Apr 2001 12:40:51 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f3KCeCs08028; Fri, 20 Apr 2001 14:40:13 +0200 (MET DST) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A34.0045949A; Fri, 20 Apr 2001 14:40:00 +0200 Message-ID: <3AE02E1F.C9C284F@alcatel.be> Date: Fri, 20 Apr 2001 14:39:59 +0200 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: raszuk@cisco.com CC: Soumen Sarkar , utthan.nakarmi@bt.com, mpls@UU.NET Subject: Re: MPLS-multicast References: <3AE008B7.5E64D973@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Or at: http://search.ietf.org/internet-drafts/draft-ietf-mpls-multicast-05.txt http://search.ietf.org/internet-drafts/draft-ooms-mpls-multicast-te-00.txt dirk Robert Raszuk wrote: > > Or at Dino's draft: > http://search.ietf.org/internet-drafts/draft-farinacci-mpls-multicast-03.txt > > R. > > > Soumen Sarkar wrote: > > > > You possibly should look into PIM work-group activities. > > -regards, > > Soumen > > > > On Fri, 20 Apr 2001 utthan.nakarmi@bt.com wrote: > > > > > Date: Fri, 20 Apr 2001 09:17:17 +0100 > > > From: utthan.nakarmi@bt.com > > > To: mpls@UU.NET > > > Subject: MPLS-multicast > > > > > > Dear all, > > > > > > Would you be able to provide any information on MPLS multicast?Thanks in > > > advance. > > > > > > regards > > > Utthan > > > -- Dirk Ooms mailto:dirk.ooms@alcatel.be tel:+32 3 2404732 Network Strategy Group (NSG) http://aww.alcatel.com/nsg Alcatel http://www.alcatel.com From owner-mpls@UU.NET Fri Apr 20 09:00:19 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11206 for ; Fri, 20 Apr 2001 09:00:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklol03424; Fri, 20 Apr 2001 12:56:21 GMT Received: by mail-control.mail.uu.net id QQklol20003 for mpls-outgoing; Fri, 20 Apr 2001 12:55:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklol19992 for ; Fri, 20 Apr 2001 12:55:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklol12233 for ; Fri, 20 Apr 2001 12:55:29 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQklol03186 for ; Fri, 20 Apr 2001 12:55:28 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3KCtAR03446; Fri, 20 Apr 2001 08:55:11 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; FRI, 20 Apr 2001 08:50:56 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id <22V70MHR>; Fri, 20 Apr 2001 08:50:56 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E56CB7F16@newman.tenornet.com> From: "Kavi, Prabhu" To: "'Geoff Bennett'" , "Kavi, Prabhu" , "Donkin, Richard" , MP LS , mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Fri, 20 Apr 2001 08:50:55 -0400 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 Geoff, All of the components needed to provide QoS with MPLS are available today. That is why I asked why ATM switches were needed. Just to review, here are the major components needed for QoS: 1. Per-class of service bandwidth reservation 2. Line-rate classification & forwarding 3. Policing 4. Non-blocking switch fabric 5. Per-class of service congestion control 6. Queueing discipline that allows both pure priority and WFQ To a large extent, IP routers are close to implementing numbers 2-6. MPLS originally only provided bandwidth reservation on a single class of service. Now it is being extended to multiple classes, solving #1. Today, there are multiple implementations of #1 that are proprietary, but recent Internet Drafts are moving these towards interoperable standards. Now, ISPs an choose how much of this they want. Some want two classes, some want four, and some are happy with best-effort IP services. Almost none of them want the full complexity of ATM QoS (like its per-VC queueing). Prabhu > -----Original Message----- > From: Geoff Bennett [mailto:geoff.bennett@marconi.com] > Sent: Friday, April 20, 2001 3:56 AM > To: Kavi, Prabhu; Donkin, Richard; MP LS; mpls-ops@mplsrc.com; > mpls@UU.NET > Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? > > > Hi Prabhu, > > >Your generalization about "loss making Internet Services" is > >foolish. > > Yes, this is a foolishness I share with quite a lot of > financial analysts :-) > > >Several years ago, somebody forgot to tell UUNET that they > >were selling loss making Internet services, and they hit > >break-even during a period of explosive growth (very hard to > >do). I think it is fair to say they are quite profitable > >for Worldcom today. > > UUNET's success has a lot to do with hiring top notch staff, and also > having a flexible strategy that takes into account emerging > technologies. > I'm a great admirer actually because they have been amongst the more > aggressive carriers in terms of MPLS piloting. > > BUT...there is a big difference between wholesale and retail > IP sales. I'm > talking about IP Services, not raw bandwidth. > > You need to be aware of the regulatory differences between > the US and the > rest of the world. While we are all in various stages of > deregulation, > only in the US did the Telecommunications Act create a legal > framework of > IXCs, ILECs and CLECs. > > In contrast in Europe, there are "carriers' carriers", sure, > but very often > these businesses mix in the notion of retail services, as well as > wholesale. In general most people would agree that wholesale > bandwidth > operation has historically been more profitable than retail. > In fact in > some cases the wholesale business is profitable enough to > offset the losses > from retail and allow the company to demonstrate overall > profitability. > This was helped by generous vendor financing during the > "happy time". The > problem is that a wholesale market can only maintain price (or > profitability) levels while its retail customers are able to stay in > business, and that situation is now coming into question. > > > >I also know for a fact that several other large ISPs are > >profitable as well, but they are part of larger organizations > >that do not publicly break out the P+L of each division. > > You must have access to information that I don't. Where the P&Ls are > combined, isn't this information confidential? One of the sources of > debate in this area is that it's so difficult to substatiate > these sort of > claims, isn't it? > > > > >No doubt, ISPs could do better by offering a range of services, > >some of which promise higher service quality. But if a service > >provider is going to start providing higher revenue services > >today, why in the world would they want to do it over ATM > >switches? > > No reason really...except that ATM is the infrastructure > that's running > today just fine...and supports the services the SPs need in > order to be > profitable. > > These days, if your MPLS vendor declines to buy their > equipment for you, > then ATM is a great alternative as you can demonstrate a real > ROI within a > sensible timescale. > > Please forgive me if I appear to be bashing MPLS...I don't > intend to. My > point is that claims are being made about the technology that > are rather > exaggerated. This kind of hype ultimately hurts any > technology (history > teaches us this about FDDI, ISDN, SMDS, ATM, ADSL, etc.). > > MPLS could be as good as ATM one day. In fact it could be so > much better > because MPLS is not tied to a single underlying technology. > > Cheers, > Geoff > > > > > >> -----Original Message----- > >> From: Geoff Bennett [mailto:geoff.bennett@marconi.com] > >> Sent: Thursday, April 19, 2001 12:20 PM > >> To: Donkin, Richard; MP LS; mpls-ops@mplsrc.com; mpls@UU.NET > >> Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? > >> > >> > >> Hi Richard, > >> Please read my post carefully. Internet services are > >> generally intended to > >> mean "best effort". In contrast VPN services are supposed to > >> carry some > >> kind of added value. In other words, I fully accept that IP > >> VPNs should > >> make more money than a basic Internet service. > >> > >> But as I understand it, the added value from IP VPNs > either comes from > >> security (whether this is "isolational" in nature like an > ATM or Frame > >> Relay VPN, or "truly secure" as in the case of an ecrypted > >> ATM or IPSec VPN > >> is up to the user), or from "perceived service enhancement". > >> The latter > >> could be via a CoS mechanism, which MPLS can potentially > >> offer, or from a > >> hard QoS mechanism which can only be offered from... > >> > >> a: A TDM mechanism (like SONET/SDH, which is expensive). > >> b: A native ATM service. > >> c: An over-provisioned stat mux service (eg. IP), which is > >> also expensive > >> in the long term. > >> > >> I know that Orchestream's core business is based on the > provision of > >> services over an MPLS core, so this may be akin to asking a > >> barber if he > >> thinks I need a haircut, but is there any evidence that IP > >> VPN services are > >> "truly profitable" (as opposed to "press release" > >> profitable)? the problem > >> is that asking most SPs this question will result in "sorry, > >> this is very > >> confidential information" responses. > >> > >> I'm not trying to bang a vendor drum here, I'm truly > >> interested because of > >> the fact that about a dozen European SPs are technically > bankrupt from > >> being too dependent on IP services ever making money. > >> > >> Cheers, > >> Geoff > >> > >> > >> At 19:38 18/04/01 +0100, Donkin, Richard wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: Geoff Bennett [mailto:geoff.bennett@marconi.com] > >> >> Sent: 18 April 2001 11:15 > >> > >> >> To: MP LS; mpls-ops@mplsrc.com; mpls@uu.net > >> >> Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? > >> >> > >> >> > >> >> Hi Niels, > > >> >> > >> >> There may be some confusion arising depending on how you > >> >> configure the ATM > >> >> switch. In effect there are three modes of operation for > >> >> this device... > >> >> > >> >> 3. Ships in the Night (SIN). In this case, both ATM and > >> MPLS Control > >> >> Planes operate simultaneously. ATM signalling happens on VCI > >> >> 5, and MPLS > >> >> signalling on VCI 32. VCs that are set up as a result of > >> >> signalling are > >> >> "owned" by one or other of these control planes. SIN > >> would allow an > >> >> operator to continue to run high revenue voice services (and > >> >> maybe existing > >> >> Frame Relay or native ATM services...they make money too) > >> >> over the ATM > >> >> "character" of the switch. They can then run the > >> loss-making Internet > >> > > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> >> services over the MPLS character. > >> >^^^^^^^^^^ > >> > > >> >Very amusing... I'm sure this was just flame-bait, but first > >> of all, MPLS > >> >supports IP services, not just Internet traffic, and you can > >> of course run > >> >highly profitable IP VPN services over MPLS. > >> > > >> >Ultimately, ATM/FR services (as seen by the customer) may > >> well be carried > >> >over an MPLS core, particularly as MPLS becomes one of the > >> key signalling > >> >mechanisms for all-optical core networks, but since much of > >> the traffic > >> >running over ATM/FR is actually IP, it may be simpler to > >> deliver IP VPNs > >> >directly to the customer premises. > >> > > >> >> Cheers, > >> >> Geoff > >> > > >> >Richard Donkin > >> >T: +44 (0)20 7348 1507 > >> >Orchestream > >> >Avon House, Kensington Village, Avonmore Road, London W14 8TS > >> >T: +44 (0)20 7348 1500 F: +44 (0)20 7348 1501 > >> >www.orchestream.com > >> > > >> > > >> >-- > >> >This communication contains confidential information > >> intended solely for > >> the use of the individual/s and/or entity or entities to > whom it was > >> intended to be addressed. If you are not the intended > >> recipient, be aware > >> that any disclosure, copying, distribution, or use of the > >> contents of this > >> transmission is prohibited. If you have received this > >> communication in > >> error, please contact the sender immediately, delete this > >> communication > >> from your system, and do not disclose its contents to any > >> third party, or > >> use its contents. Any opinions expressed are solely those of > >> the author > >> and do not necessarily represent those of Orchestream Ltd or > >> its group of > >> companies unless otherwise specifically stated. > >> > > >> >------- > >> >The MPLS-OPS Mailing List > >> >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > >> >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > >> > > >> ================================================================ > >> Geoff Bennett > >> Tel: (33) 497 21 43 62 > >> Director of Technology, OCTO > >> Fax: (33) 497 21 43 50 > >> Marconi > >> Gaia - Bat. E > >> email: geoff.bennett@marconi.com > >> BP 123 > >> 06903 SOPHIA ANTIPOLIS > >> FRANCE > >> ================================================================ > >> > > >> > > > ================================================================ > Geoff Bennett > Tel: (33) 497 21 43 62 > Director of Technology, OCTO > Fax: (33) 497 21 43 50 > Marconi > Gaia - Bat. E > email: geoff.bennett@marconi.com > BP 123 > 06903 SOPHIA ANTIPOLIS > FRANCE > ================================================================ > From owner-mpls@UU.NET Fri Apr 20 09:03:54 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11298 for ; Fri, 20 Apr 2001 09:03:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklom20541; Fri, 20 Apr 2001 13:01:32 GMT Received: by mail-control.mail.uu.net id QQklom23042 for mpls-outgoing; Fri, 20 Apr 2001 13:00:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklom22909 for ; Fri, 20 Apr 2001 13:00:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklom16331 for ; Fri, 20 Apr 2001 13:00:46 GMT Received: from dharti.aplion.stpn.soft.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.10.199.46]) id QQklom09884 for ; Fri, 20 Apr 2001 13:00:33 GMT Received: from bhartibatra (sys_test_1 [192.9.202.135]) by dharti.aplion.stpn.soft.net (8.8.7/8.8.4) with SMTP id SAA14523 for ; Fri, 20 Apr 2001 18:16:39 +0530 Message-ID: <041701c0c99a$edf16260$87ca09c0@dharti.aplion.stpn.soft.net> From: "Bharti Batra" To: Subject: CLI for MPLS Date: Fri, 20 Apr 2001 18:37:59 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0414_01C0C9C9.05FAB5E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0414_01C0C9C9.05FAB5E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi ! What is the version of Cisco IOS for MPLS that is closest match to the = configurable parameters defined in IETF's MIBs ? I am looking for CLI = for Static and Signaled LSPs. Any pointers? Regds, Bharti ------=_NextPart_000_0414_01C0C9C9.05FAB5E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi !
 
What is the version of Cisco IOS for MPLS that is closest = match=20 to the configurable parameters defined in IETF's MIBs ? I am looking for = CLI for=20 Static and Signaled LSPs. Any pointers?
 
Regds,
Bharti
 
 
------=_NextPart_000_0414_01C0C9C9.05FAB5E0-- From owner-mpls@UU.NET Fri Apr 20 09:09:30 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11418 for ; Fri, 20 Apr 2001 09:09:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklom11034; Fri, 20 Apr 2001 13:06:19 GMT Received: by mail-control.mail.uu.net id QQklom00169 for mpls-outgoing; Fri, 20 Apr 2001 13:05:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklom00099 for ; Fri, 20 Apr 2001 13:05:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklom24267 for ; Fri, 20 Apr 2001 13:04:12 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklom09445 for ; Fri, 20 Apr 2001 13:04:12 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA18199 for mpls@uu.net; Fri, 20 Apr 2001 09:04:11 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklom26597 for ; Fri, 20 Apr 2001 13:03:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklom19052 for ; Fri, 20 Apr 2001 13:01:57 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklom11763 for ; Fri, 20 Apr 2001 13:01:56 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07833; Fri, 20 Apr 2001 09:01:45 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29329; Fri, 20 Apr 2001 09:01:49 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 09:01:43 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F4A8@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "Naidu, Venkata" , "Charlap, David" , "'mpls@UU.NET '" Cc: "''mpls-ops@mplsrc.com' '" Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Fri, 20 Apr 2001 09:01:42 -0400 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 There is some effort in the MPLS Forum to define VoMPLS for a class of problems that are best described as severe bandwidth restrictions on the MPLS link. It trades off incompatibility with every other VoXXX for link efficiency. That spec is getting close to being finished. End-to-End delay is currently limited by routers - switches don't add significant delay. We can pretty easily build 30 ms end to end systems using ATM switches. Router delays are typically much longer, but then again, some things that are called routers are really switches, and some real routers have so much hardware that they don't add much delay, especially for a media stream (which gets to use cached information effectively). Still in all, if you see traceroute giving you 200 ms RT times, better have long tails on your echo cancel! Putting a bound on delay would be nice, but I don't see routers implementing that any time soon. Brian -----Original Message----- From: Naidu, Venkata To: Charlap, David; mpls@UU.NET; Rosen, Brian Cc: 'mpls-ops@mplsrc.com' Sent: 4/19/01 2:39 PM Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Hi David Please look at the Voice over MPLS framework document: http://www.alternic.org/drafts/drafts-k-l/draft-kankkunen-vompls-fw-01.p df Presently so many VoIP working groups (MMUSIC/SIP/IPTel etc) have there own mechanism for end-to-end delay characteristics but at the applications level. But in the above draft they made some progress to Voice Traffic Engineering using MPLS and Dynamic traffic management. Section 5 is left unanswered about Requirements for MPLS signaling (LDP/CR-LDP and RSVP-TE) Unfortunately I didn't see any progress after in VoMPLS. -Venkata Naidu > > I agree with your points above. However, I don't think there is > > anything stop MPLS implemented with a hard QoS mechanism like ATM > > has done. A good LSR with the necessary traffic management > > infrastructure (queuing and scheduling) can achieve the same > > level, if not better QoS. > > One clear advantage of ATM is that ATM provides more parameters for > tuning QoS than RSVP or CR-LDP do. > > None of the current MPLS signaling protocols provide a way to specify > delay characteristics as part of QoS. ATM's QoS allows signaling of > delay and delay variation. RSVP's ADSPEC object allows the collection > of delay information, but there is no way to request that the network > try to establish an LSP that conforms to particular delay > characteristics. > > Delay information is important for circuit-emulation and for real-time > streaming applications (like voice/video). > > Of course, delay factors are much less of a problem today (with > extremely fast backplanes and OC-x interfaces) than they were in the > recent past (with slower backplanes and DS-x interfaces), but I don't > think we're yet at the point where they can be completely ignored. > > I think there are still some applications where delay and delay > variation are important even on today's hardware. > > Of course, there's no reason why delay characteristics > couldn't be added > to either RSVP or CR-LDP in the future. > > -- David > From owner-mpls@UU.NET Fri Apr 20 09:10:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11448 for ; Fri, 20 Apr 2001 09:10:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklom29762; Fri, 20 Apr 2001 13:07:49 GMT Received: by mail-control.mail.uu.net id QQklom01119 for mpls-outgoing; Fri, 20 Apr 2001 13:07:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklom01053 for ; Fri, 20 Apr 2001 13:06:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklom13999 for ; Fri, 20 Apr 2001 13:05:35 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQklom16864 for ; Fri, 20 Apr 2001 13:05:35 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3KD5WR05057; Fri, 20 Apr 2001 09:05:32 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; FRI, 20 Apr 2001 09:01:19 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id <22V70MJM>; Fri, 20 Apr 2001 09:01:18 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E56CB7F17@newman.tenornet.com> From: "Kavi, Prabhu" To: "'Eric Gray'" , David Charlap Cc: mpls@UU.NET Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Fri, 20 Apr 2001 09:01:18 -0400 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 Eric, I interpreted David's statements to mean that you can get completely bounded delay with variable size packets. David, correct me if I am wrong. For example, a commonly used MTU of 1500 bytes requires only 5 microseconds of transmission time on an OC-48. Therefore it is possible to create a queueing mechanism where a high priority packet is at most 5 microseconds away from the start of transmission. Queuing points in the rest of the system (if any) can be handled in a similar fashion. Implementations of these systems might not be as far away as you think. Prabhu > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: Friday, April 20, 2001 8:39 AM > To: David Charlap > Cc: mpls@UU.NET > Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? > > > David, > > I'm sure some smart person or another has written a paper > on this, but I don't have the time to do a full-blown literature > search right now. While what you are saying is technically > true, I believe it has very little applicability in practice. > You can see that this works by imagining that an implementation > might treat MTU propagation time exactly the same way that ATM > treats cell propagation time. > > But this is very ugly. It is so coarse that many would be > hard pressed to consider it a useful guarantee. It also seems > to require deliberately inserting latency (N times an MTU > propagation time) for all affected traffic (to allow for packet > shuffling to accomodate the guarantee). And it would be > very difficult to allocate forwarding resources efficiently and > still deliver guaranteed delay variation deterministically. > > Without making any moral judgement about why it is so, > many people are more concerned about having a bounded > delay than they are about having a bounded delay variation. > And with a bounded delay, you get bounded delay variation > for free. > > My opinion: there are two models here and trying to make > technologies support both models may not be a good idea. > > -- > Eric Gray > > You wrote: > > > Eric Gray wrote: > > > > > > You can't exactly do ATM style QoS over non-ATM media. > > > > > > The thing that allows an ATM switch to contemplate delay > > > variation separately from delay is the fact that ATM switches > > > switch data in fixed size chunks. When the size of data chunks > > > can vary, the only practical way to control delay variation is to > > > try to control delay. Therefore, with IP packets on non-ATM > > > media, you can't even begin support two knobs for delay and > > > delay variation. So why would you undertake to add complexity > > > by trying? > > > > Variable-size frames don't make it impossible. It just > means you are > > forced to work with a coarser granularity (defined by your > configured > > MTU size.) > > > > -- david > > From owner-mpls@UU.NET Fri Apr 20 09:27:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11737 for ; Fri, 20 Apr 2001 09:27:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklon11993; Fri, 20 Apr 2001 13:24:37 GMT Received: by mail-control.mail.uu.net id QQklon11244 for mpls-outgoing; Fri, 20 Apr 2001 13:24:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklon11235 for ; Fri, 20 Apr 2001 13:23:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklon06819 for ; Fri, 20 Apr 2001 13:23:12 GMT Received: from dharti.aplion.stpn.soft.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.10.199.46]) id QQklon20754 for ; Fri, 20 Apr 2001 13:23:07 GMT Received: from bhartibatra (sys_test_1 [192.9.202.135]) by dharti.aplion.stpn.soft.net (8.8.7/8.8.4) with SMTP id SAA15667 for ; Fri, 20 Apr 2001 18:39:14 +0530 Message-ID: <044801c0c99e$154f7b00$87ca09c0@dharti.aplion.stpn.soft.net> From: "Bharti Batra" To: Subject: Pls Ignore - CLI for MPLS mail Date: Fri, 20 Apr 2001 19:00:36 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0445_01C0C9CC.2EC46C70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0445_01C0C9CC.2EC46C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0445_01C0C9CC.2EC46C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0445_01C0C9CC.2EC46C70-- From owner-mpls@UU.NET Fri Apr 20 09:35:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11814 for ; Fri, 20 Apr 2001 09:35:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloo22988; Fri, 20 Apr 2001 13:32:32 GMT Received: by mail-control.mail.uu.net id QQkloo12134 for mpls-outgoing; Fri, 20 Apr 2001 13:31:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkloo12095 for ; Fri, 20 Apr 2001 13:30:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkloo29319 for ; Fri, 20 Apr 2001 13:30:36 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkloo20085 for ; Fri, 20 Apr 2001 13:30:36 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11079 for ; Fri, 20 Apr 2001 09:30:33 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07695 for ; Fri, 20 Apr 2001 09:30:37 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 09:30:35 -0400 Message-ID: <73573B0D37AFD311A3A800204840ED03227284@dal-server-01.pit.comms.marconi.com> From: "Dekany, Steven" To: mpls@UU.NET Subject: LSP Failure Notification Date: Fri, 20 Apr 2001 09:30:34 -0400 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 Greetings; I am looking for help, with the following: Assume I have an MPLS Service Provider network, running RSVP-TE as a signaling protocol. Customer sites are connected to my network via various IP only links - no MPLS. Upon a LSP link failure in my core - assume that I have exhausted all back-up, re-route etc., options and my LSP tunnel is still down - what happens to my incoming IP traffic at the ingress LER? Is there an ICMP message generated back to IP Source with "Destination Unreachable? , or an SNMP Trap, or both? Or something else? (Or is this a dumb question, because I have not read the relevant draft...) Any help or pointers would be greatly appreciated. Thanks in advance, Steven From owner-mpls@UU.NET Fri Apr 20 09:35:40 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11825 for ; Fri, 20 Apr 2001 09:35:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloo21199; Fri, 20 Apr 2001 13:31:26 GMT Received: by mail-control.mail.uu.net id QQkloo12103 for mpls-outgoing; Fri, 20 Apr 2001 13:30:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkloo12094 for ; Fri, 20 Apr 2001 13:30:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklon27039 for ; Fri, 20 Apr 2001 13:29:53 GMT Received: from prue.eim.surrey.ac.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQklon19113 for ; Fri, 20 Apr 2001 13:29:53 GMT Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14qayk-0005gB-00; Fri, 20 Apr 2001 14:29:42 +0100 Date: Fri, 20 Apr 2001 14:29:42 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Eric Gray cc: David Charlap , mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? In-Reply-To: <3ADF767B.88B4D120@sandburst.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *14qayk-0005gB-00*L2C0cUE59C6* Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 19 Apr 2001, Eric Gray wrote: > You can't exactly do ATM style QoS over non-ATM media. > > The thing that allows an ATM switch to contemplate delay > variation separately from delay is the fact that ATM switches > switch data in fixed size chunks. How does this help variable-sized AAL encapsulations? L. I've always wondered. PGP From owner-mpls@UU.NET Fri Apr 20 09:51:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11928 for ; Fri, 20 Apr 2001 09:51:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklop25153; Fri, 20 Apr 2001 13:48:34 GMT Received: by mail-control.mail.uu.net id QQklop14270 for mpls-outgoing; Fri, 20 Apr 2001 13:47:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklop14253 for ; Fri, 20 Apr 2001 13:47:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklop19349 for ; Fri, 20 Apr 2001 13:46:58 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQklop22838 for ; Fri, 20 Apr 2001 13:46:57 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 GAA29801 for ; Fri, 20 Apr 2001 06:47:00 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA07063 for mpls@uu.net; Fri, 20 Apr 2001 09:46:55 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkloa29447 for ; Fri, 20 Apr 2001 10:05:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkloa25226 for ; Fri, 20 Apr 2001 10:04:58 GMT Received: from mail2.orchestream.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [195.153.64.126]) id QQkloa18144 for ; Fri, 20 Apr 2001 10:04:57 GMT Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 20 Apr 2001 11:06:06 +0100 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id GAA21141; Fri, 20 Apr 2001 06:05:20 +0100 Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Apr 2001 11:01:23 +0100 Message-ID: From: "Donkin, Richard" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Fri, 20 Apr 2001 11:01:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Geoff Bennett [mailto:geoff.bennett@marconi.com] > Sent: 20 April 2001 09:40 > To: HANSEN CHAN > Cc: Donkin, Richard; MP LS; mpls-ops@mplsrc.com; mpls@UU.NET > Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? > > > Hard QoS architectures are hard to build. ATM got it right for the most > part, but there would be a strong argument that the way ATM does QoS (on a > VC basis) will not scale to networks as big as the Internet. With MPLS we > can aggregate things nicely, but in my mind this is not QoS, it's CoS. The > tradeoff we seem to be faced with is the "quality" of our QoS architecture > vs its scalability. This is quite true - I have yet to see anyone doing hard QoS in a highly scalable way. Back in the mid-Nineties, there was much talk of public ATM networks providing SVCs to customers, but this did not materialise, and the same has happened with RSVP in the IP world. > ATM also has the advantage that it's Connection Oriented from end to end. > One of the reasons it can deliver such a hard QoS assurance was that the > application itself is able to negotiate with the network to ask for the > explicit QoS requirements, and to get the network's agreement that these > resources were available. To duplicate this with MPLS we'd have to extend > RSVP signalling to the host (or maybe to the voice gateway in a VoMPLS > installation). I know this has been discussed, but is at a very early stage. The real advantage here is application signalling of QoS, connection orientation is just the simplest way to implement this - if such signalling can interface with a connectionless core (see the RSVP to DiffServ mapping work in the IETF), you can get the best of both worlds. Of course, building such a network is still a research topic, involving bandwidth brokers that make admission control decisions for the DiffServ core. The RSVP community is also working on scalability improvements (in router state and signalling overhead), which may help in this area through aggregation. There are very few applications that can generate ATM or RSVP signalling - Microsoft provides a GQoS API in Windows 2000 that addresses this, but it's not clear how many applications use this (and many of them will just signal the application + user identity, allowing a policy server to assign a DiffServ marking rather than a hard QoS). Until we have smarter middleware, or network gateways that generate such signalling, this chicken and egg problem (no apps, so no hard QoS networks, so no apps) will probably continue. > Another advantage of ATM in terms of QoS is the fixed cell size. Any > fixed-PDU technology will have the edge over a variable PDU technology when > it comes to QoS. Before I ignite a cells vs frames debate let me say that > I believe the (many) advantages of a variable length PDU infrastructure > (especially at very high speeds) outweight the QoS benefits of fixed PDU. > In other words, I'll go along with the assumption that if you're > transmitting at a high enough speed, the CoS you can squeeze out of a > variable PDU network will one day be "good enough" (if you over-provision > the network sufficiently). I don't think you need to overprovision the core network if you are using variable size PDUs - as long as you fragment large packets/frames at the link layer on lower speed links, the higher speed links will take care of themselves (assuming a reasonable upper bound on PDU size). This is now somewhat off the topic of MPLS, but in theory you could have a mapping from flow-based RSVP into RSVP-TE so I guess there is some relevance to MPLS in the longer term if this can be worked out. In practice, most people seem to be building CoS networks with MPLS, and would be more interested in mapping per-flow RSVP onto DiffServ and MPLS CoS, mediated by a bandwidth broker for the MPLS/DiffServ domain. Richard -- This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited. If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents. Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated. From owner-mpls@UU.NET Fri Apr 20 10:02:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12014 for ; Fri, 20 Apr 2001 10:02:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklop18903; Fri, 20 Apr 2001 13:59:04 GMT Received: by mail-control.mail.uu.net id QQklop15632 for mpls-outgoing; Fri, 20 Apr 2001 13:58:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklop15624 for ; Fri, 20 Apr 2001 13:58:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklop24913 for ; Fri, 20 Apr 2001 13:58:25 GMT Received: from osf1.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQklop26850 for ; Fri, 20 Apr 2001 13:58:25 GMT Received: from localhost (hsong@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA25062; Fri, 20 Apr 2001 09:58:05 -0400 (EDT) Date: Fri, 20 Apr 2001 09:58:05 -0400 (EDT) From: Haoxin Song To: "Dekany, Steven" cc: mpls@UU.NET Subject: Re: LSP Failure Notification In-Reply-To: <73573B0D37AFD311A3A800204840ED03227284@dal-server-01.pit.comms.marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Assume you have L3 routing table, wouldn't the pure ip routing be used for the incoming IP traffic in case of LSP Failure? Haoxin On Fri, 20 Apr 2001, Dekany, Steven wrote: > Greetings; > > I am looking for help, with the following: > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > signaling protocol. Customer sites are connected to my network via various > IP only links - no MPLS. Upon a LSP link failure in my core - assume that > I have exhausted all back-up, re-route etc., options and my LSP tunnel is > still down - what happens to my incoming IP traffic at the ingress LER? Is > there an ICMP message generated back to IP Source with "Destination > Unreachable? , or an SNMP Trap, or both? Or something else? > > (Or is this a dumb question, because I have not read the relevant draft...) > > Any help or pointers would be greatly appreciated. > > Thanks in advance, > > > Steven > From owner-mpls@UU.NET Fri Apr 20 10:03:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12025 for ; Fri, 20 Apr 2001 10:03:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloq12240; Fri, 20 Apr 2001 14:00:31 GMT Received: by mail-control.mail.uu.net id QQklop15724 for mpls-outgoing; Fri, 20 Apr 2001 13:59:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklop15687 for ; Fri, 20 Apr 2001 13:59:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklop27723 for ; Fri, 20 Apr 2001 13:59:20 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQklop10462 for ; Fri, 20 Apr 2001 13:59:18 GMT Received: from goneto.net (unknown [195.167.134.116]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 222FF15F7E5; Fri, 20 Apr 2001 14:59:13 +0100 (BST) Message-ID: <3AE04D87.7EFADABC@goneto.net> Date: Fri, 20 Apr 2001 15:53:59 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Dekany, Steven" Cc: mpls@UU.NET Subject: Re: LSP Failure Notification References: <73573B0D37AFD311A3A800204840ED03227284@dal-server-01.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Dekany, Steven" wrote: > > Greetings; > > I am looking for help, with the following: > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > signaling protocol. Customer sites are connected to my network via various > IP only links - no MPLS. Upon a LSP link failure in my core - assume that > I have exhausted all back-up, re-route etc., options and my LSP tunnel is > still down - what happens to my incoming IP traffic at the ingress LER? Is > there an ICMP message generated back to IP Source with "Destination > Unreachable? , or an SNMP Trap, or both? Or something else? It depends... What happens when a customer packet arrives at your ingress LER (under normal circumstances) is the following: 1. The destination IP address is looked up in the forwarding table. 2. An address is returned from the lookup (this will be the BGP next-hop associated with the prefix which matched the destination IP address.) 3. This address is looked up in the forwarding table (so this is a recursive lookup.) 4. An RSVP-TE signalled LSP will be found which matches this address. 5. The packet is labelled and then forwarded via the LSP. In the case you have outlined steps 1 to 3 will proceed as before. However step 4 will return an IP next hop on a connected interface, rather than returning an LSP. There should always be an IP route matching the BGP next-hop (unless the lack of this route is the reason why RSVP-TE is failing, but then you probably wouldn't have a working iBGP session - but I digress!) So the packet will be forwarded using normal IP forwarding. If the core of your network is also running full BGP routes this will work fine (and in fact the traffic may be switched into an LSP by a subsequent router.) However if the core is not running BGP (as I would expect to be the case with ATM LSRs) then the packet will be discarded at the next hop. But of course the next hop won't know how to route an ICMP packet back to the source (since the address of the source is also in BGP) so I'd expect this ICMP to be discarded at source. This is probably why running LDP is generally seen as a precursor to removing BGP from the core of the network? Someone (or many someones) will no doubt correct me if I'm wrong. HTH, Giles > (Or is this a dumb question, because I have not read the relevant draft...) > > Any help or pointers would be greatly appreciated. > > Thanks in advance, > > Steven -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Fri Apr 20 10:05:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12067 for ; Fri, 20 Apr 2001 10:05:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloq01983; Fri, 20 Apr 2001 14:02:13 GMT Received: by mail-control.mail.uu.net id QQkloq20153 for mpls-outgoing; Fri, 20 Apr 2001 14:01:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkloq18086 for ; Fri, 20 Apr 2001 14:00:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkloq00707 for ; Fri, 20 Apr 2001 14:00:15 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host200.pluris.com [208.227.9.200]) id QQkloq29257 for ; Fri, 20 Apr 2001 14:00:14 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id HAA10833; Fri, 20 Apr 2001 07:00:14 -0700 (PDT) Received: from localhost (akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id HAA12652; Fri, 20 Apr 2001 07:00:13 -0700 (PDT) X-Authentication-Warning: volsung.pluris.com: akyol owned process doing -bs Date: Fri, 20 Apr 2001 07:00:13 -0700 (PDT) From: Bora Akyol To: "Dekany, Steven" cc: mpls@UU.NET Subject: Re: LSP Failure Notification In-Reply-To: <73573B0D37AFD311A3A800204840ED03227284@dal-server-01.pit.comms.marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk The tunnels are established using IGP reachability information. When the tunnel goes away, IGP route will become the next best route and traffic will be traveling via IP. This may take a while, but until the head end realizes that the tunnel is down, there really is not much you can do. The packets will fall on the ground. I believe G-MPLS defines a failure notification mechanism. Bora On Fri, 20 Apr 2001, Dekany, Steven wrote: > Greetings; > > I am looking for help, with the following: > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > signaling protocol. Customer sites are connected to my network via various > IP only links - no MPLS. Upon a LSP link failure in my core - assume that > I have exhausted all back-up, re-route etc., options and my LSP tunnel is > still down - what happens to my incoming IP traffic at the ingress LER? Is > there an ICMP message generated back to IP Source with "Destination > Unreachable? , or an SNMP Trap, or both? Or something else? > > (Or is this a dumb question, because I have not read the relevant draft...) > > Any help or pointers would be greatly appreciated. > > Thanks in advance, > > > Steven > From owner-mpls@UU.NET Fri Apr 20 10:13:43 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12188 for ; Fri, 20 Apr 2001 10:13:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloq13233; Fri, 20 Apr 2001 14:10:23 GMT Received: by mail-control.mail.uu.net id QQkloq27305 for mpls-outgoing; Fri, 20 Apr 2001 14:09:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkloq27231 for ; Fri, 20 Apr 2001 14:09:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkloq28811 for ; Fri, 20 Apr 2001 14:09:19 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkloq11746 for ; Fri, 20 Apr 2001 14:09:19 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 HAA01341; Fri, 20 Apr 2001 07:09:43 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA07160; Fri, 20 Apr 2001 10:09:15 -0400 (EDT) Message-Id: <200104201409.KAA07160@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Juha Heinanen cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-reply-to: Your message of Fri, 20 Apr 2001 00:56:35 +0300. <15071.24339.890504.475774@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: Fri, 20 Apr 2001 10:09:15 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Juha> mpls as ce-ce link has many advantages over frame relay, e.g., exp field Juha> for diffserv support I think the IP header already contains a field which the user can set to signal diffserv support to the service provider. Or are you saying that it is important to be able to signal diffserv on a per-packet basis for non-IP packets? Juha> and label stacking. This suggests that the backbone should run MPLS, rather than Frame Relay, and I'd certainly agree with that, but I don't see why this is an issue vis. a vis. CE-CE LSPs. Of course, if two CEs want to send each other MPLS packets, they can send them over any data link whatsoever. Juha> if mpls is used in the middle, it is always a good idea to avoid Juha> interworking and run mpls all the way. I don't see why this is the case. From owner-mpls@UU.NET Fri Apr 20 10:34:56 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12581 for ; Fri, 20 Apr 2001 10:34:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklos25463; Fri, 20 Apr 2001 14:31:58 GMT Received: by mail-control.mail.uu.net id QQklos08350 for mpls-outgoing; Fri, 20 Apr 2001 14:30:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklor08296 for ; Fri, 20 Apr 2001 14:29:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklor25475 for ; Fri, 20 Apr 2001 14:28:07 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklor09736 for ; Fri, 20 Apr 2001 14:28:07 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17362; Fri, 20 Apr 2001 10:28:04 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25909; Fri, 20 Apr 2001 10:28:09 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 10:28:06 -0400 Message-ID: <73573B0D37AFD311A3A800204840ED03227287@dal-server-01.pit.comms.marconi.com> From: "Dekany, Steven" To: Bora Akyol , "Dekany, Steven" Cc: mpls@UU.NET Subject: RE: LSP Failure Notification Date: Fri, 20 Apr 2001 10:28:04 -0400 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 Thank you Bora; and thank you Haoxin and Giles. Yes, best effort is kind of the expected "default" behavior. I just wonder that when we say that the IGP route will become the "next best route" what happens to my SLA with the customer - assuming that there is one in place? I guess the underlying assumption is that I use MPLS in the core because I want to give something better than best effort service to my customer. Now that my LSP is broken and that I cannot setup another one - at least for while, in theory - if I use best effort only, I have basically violated my service level agreement with my customer. Should I not notify him somehow? Or this REALLY VERY IMPLEMENTATION SPECIFIC - read, either private information, or policy dependent? Another theoretical question - how significant is usually the time delay between IGP's convergence and by the time RSVP-TE has found a new LSP? If that is a relatively short time, I may not care, but if it takes a few tens of seconds or minutes, and I have a relatively high speed link to the LER, it may flood my network with unwanted IP traffic real badly too, causing another cascading TE problem for me potentially in the core. Along the same line, if I have certain traffic parameter requirements for my LSP - as required by my SLA - it is entirely possible that RSVP-TE may not find a suitable LSP and comes back with PathErr. Do I still fall back to forward best effort? I wonder if there is any practical experience with this question, or IP best effort is the generally implemented default. Thank you again to all again, who kindly responded, Best Regards, Steven -----Original Message----- From: Bora Akyol [mailto:akyol@pluris.com] Sent: Friday, April 20, 2001 9:00 AM To: Dekany, Steven Cc: mpls@UU.NET Subject: Re: LSP Failure Notification The tunnels are established using IGP reachability information. When the tunnel goes away, IGP route will become the next best route and traffic will be traveling via IP. This may take a while, but until the head end realizes that the tunnel is down, there really is not much you can do. The packets will fall on the ground. I believe G-MPLS defines a failure notification mechanism. Bora On Fri, 20 Apr 2001, Dekany, Steven wrote: > Greetings; > > I am looking for help, with the following: > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > signaling protocol. Customer sites are connected to my network via various > IP only links - no MPLS. Upon a LSP link failure in my core - assume that > I have exhausted all back-up, re-route etc., options and my LSP tunnel is > still down - what happens to my incoming IP traffic at the ingress LER? Is > there an ICMP message generated back to IP Source with "Destination > Unreachable? , or an SNMP Trap, or both? Or something else? > > (Or is this a dumb question, because I have not read the relevant draft...) > > Any help or pointers would be greatly appreciated. > > Thanks in advance, > > > Steven > From owner-mpls@UU.NET Fri Apr 20 10:57:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12857 for ; Fri, 20 Apr 2001 10:57:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklot16724; Fri, 20 Apr 2001 14:57:41 GMT Received: by mail-control.mail.uu.net id QQklot11451 for mpls-outgoing; Fri, 20 Apr 2001 14:57:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklot11401 for ; Fri, 20 Apr 2001 14:56:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklot00248 for ; Fri, 20 Apr 2001 14:56:46 GMT Received: from alemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQklot00429 for ; Fri, 20 Apr 2001 14:56:45 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3KEuj126053 for ; Fri, 20 Apr 2001 10:56:45 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f3KEuim26041; Fri, 20 Apr 2001 10:56:44 -0400 (EDT) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA11376; Fri, 20 Apr 2001 10:56:44 -0400 Message-ID: <3AE04EEA.CF71F41F@hotair.hobl.lucent.com> Date: Fri, 20 Apr 2001 10:59:54 -0400 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dekany, Steven" CC: Bora Akyol , mpls@UU.NET Subject: Re: LSP Failure Notification References: <73573B0D37AFD311A3A800204840ED03227287@dal-server-01.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Steven, Have you considered phyiscally-disjoint pair of LSP's in the solution, with one LSP as a backup so that if the primary path fails the affected traffic can flow on the backup? Ramesh "Dekany, Steven" wrote: > > Thank you Bora; > > and thank you Haoxin and Giles. > > Yes, best effort is kind of the expected "default" behavior. I just wonder > that when we say that the IGP route will become the "next best route" what > happens to my SLA with the customer - assuming that there is one in place? I > guess the underlying assumption is that I use MPLS in the core because I > want to give something better than best effort service to my customer. Now > that my LSP is broken and that I cannot setup another one - at least for > while, in theory - if I use best effort only, I have basically violated my > service level agreement with my customer. Should I not notify him somehow? > Or this REALLY VERY IMPLEMENTATION SPECIFIC - read, either private > information, or policy dependent? > > Another theoretical question - how significant is usually the time delay > between IGP's convergence and by the time RSVP-TE has found a new LSP? If > that is a relatively short time, I may not care, but if it takes a few tens > of seconds or minutes, and I have a relatively high speed link to the LER, > it may flood my network with unwanted IP traffic real badly too, causing > another cascading TE problem for me potentially in the core. > > Along the same line, if I have certain traffic parameter requirements for my > LSP - as required by my SLA - it is entirely possible that RSVP-TE may not > find a suitable LSP and comes back with PathErr. Do I still fall back to > forward best effort? > > I wonder if there is any practical experience with this question, or IP best > effort is the generally implemented default. > > Thank you again to all again, who kindly responded, > > Best Regards, > > Steven > > > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Friday, April 20, 2001 9:00 AM > To: Dekany, Steven > Cc: mpls@UU.NET > Subject: Re: LSP Failure Notification > > The tunnels are established using IGP reachability information. When the > tunnel goes away, IGP route will become the next best route and traffic > will be traveling via IP. > > This may take a while, but until the head end realizes that the tunnel is > down, there really is not much you can do. The packets will fall on the > ground. > > I believe G-MPLS defines a failure notification mechanism. > > Bora > > On Fri, 20 Apr 2001, Dekany, Steven wrote: > > > Greetings; > > > > I am looking for help, with the following: > > > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > > signaling protocol. Customer sites are connected to my network via various > > IP only links - no MPLS. Upon a LSP link failure in my core - assume > that > > I have exhausted all back-up, re-route etc., options and my LSP tunnel is > > still down - what happens to my incoming IP traffic at the ingress LER? Is > > there an ICMP message generated back to IP Source with "Destination > > Unreachable? , or an SNMP Trap, or both? Or something else? > > > > (Or is this a dumb question, because I have not read the relevant > draft...) > > > > Any help or pointers would be greatly appreciated. > > > > Thanks in advance, > > > > > > Steven > > From owner-mpls@UU.NET Fri Apr 20 11:07:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12944 for ; Fri, 20 Apr 2001 11:07:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklou18186; Fri, 20 Apr 2001 15:07:05 GMT Received: by mail-control.mail.uu.net id QQklou22260 for mpls-outgoing; Fri, 20 Apr 2001 15:06:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklou19247 for ; Fri, 20 Apr 2001 15:04:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklou16337 for ; Fri, 20 Apr 2001 15:03:19 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklou14391 for ; Fri, 20 Apr 2001 15:03:18 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20596; Fri, 20 Apr 2001 11:03:15 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05898; Fri, 20 Apr 2001 11:03:18 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 11:03:15 -0400 Message-ID: <73573B0D37AFD311A3A800204840ED0322728C@dal-server-01.pit.comms.marconi.com> From: "Dekany, Steven" To: Ramesh Bhandari , "Dekany, Steven" Cc: Bora Akyol , mpls@UU.NET Subject: RE: LSP Failure Notification Date: Fri, 20 Apr 2001 11:03:14 -0400 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 Ramesh, Yes, I have. The assumption that I made in my first email is, that I have exhausted all back-up and LSP re-route options, at least temporarily. At the moment there is no LSP available. What do SP's most often do in this case with the incoming IP traffic? Signal back to source with Dest Unreachable? Silently drop until a new LSP finally comes up? Light a red lamp in the NOC signaling a NW outage or link failure? Best Regards, Steven -----Original Message----- From: Ramesh Bhandari [mailto:bhandari1@lucent.com] Sent: Friday, April 20, 2001 10:00 AM To: Dekany, Steven Cc: Bora Akyol; mpls@UU.NET Subject: Re: LSP Failure Notification Steven, Have you considered phyiscally-disjoint pair of LSP's in the solution, with one LSP as a backup so that if the primary path fails the affected traffic can flow on the backup? Ramesh "Dekany, Steven" wrote: > > Thank you Bora; > > and thank you Haoxin and Giles. > > Yes, best effort is kind of the expected "default" behavior. I just wonder > that when we say that the IGP route will become the "next best route" what > happens to my SLA with the customer - assuming that there is one in place? I > guess the underlying assumption is that I use MPLS in the core because I > want to give something better than best effort service to my customer. Now > that my LSP is broken and that I cannot setup another one - at least for > while, in theory - if I use best effort only, I have basically violated my > service level agreement with my customer. Should I not notify him somehow? > Or this REALLY VERY IMPLEMENTATION SPECIFIC - read, either private > information, or policy dependent? > > Another theoretical question - how significant is usually the time delay > between IGP's convergence and by the time RSVP-TE has found a new LSP? If > that is a relatively short time, I may not care, but if it takes a few tens > of seconds or minutes, and I have a relatively high speed link to the LER, > it may flood my network with unwanted IP traffic real badly too, causing > another cascading TE problem for me potentially in the core. > > Along the same line, if I have certain traffic parameter requirements for my > LSP - as required by my SLA - it is entirely possible that RSVP-TE may not > find a suitable LSP and comes back with PathErr. Do I still fall back to > forward best effort? > > I wonder if there is any practical experience with this question, or IP best > effort is the generally implemented default. > > Thank you again to all again, who kindly responded, > > Best Regards, > > Steven > > > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Friday, April 20, 2001 9:00 AM > To: Dekany, Steven > Cc: mpls@UU.NET > Subject: Re: LSP Failure Notification > > The tunnels are established using IGP reachability information. When the > tunnel goes away, IGP route will become the next best route and traffic > will be traveling via IP. > > This may take a while, but until the head end realizes that the tunnel is > down, there really is not much you can do. The packets will fall on the > ground. > > I believe G-MPLS defines a failure notification mechanism. > > Bora > > On Fri, 20 Apr 2001, Dekany, Steven wrote: > > > Greetings; > > > > I am looking for help, with the following: > > > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > > signaling protocol. Customer sites are connected to my network via various > > IP only links - no MPLS. Upon a LSP link failure in my core - assume > that > > I have exhausted all back-up, re-route etc., options and my LSP tunnel is > > still down - what happens to my incoming IP traffic at the ingress LER? Is > > there an ICMP message generated back to IP Source with "Destination > > Unreachable? , or an SNMP Trap, or both? Or something else? > > > > (Or is this a dumb question, because I have not read the relevant > draft...) > > > > Any help or pointers would be greatly appreciated. > > > > Thanks in advance, > > > > > > Steven > > From owner-mpls@UU.NET Fri Apr 20 11:13:26 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13009 for ; Fri, 20 Apr 2001 11:13:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklou07001; Fri, 20 Apr 2001 15:13:24 GMT Received: by mail-control.mail.uu.net id QQklou00148 for mpls-outgoing; Fri, 20 Apr 2001 15:12:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklou00114 for ; Fri, 20 Apr 2001 15:12:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklou09929 for ; Fri, 20 Apr 2001 15:11:20 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklou21802 for ; Fri, 20 Apr 2001 15:11:20 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21338; Fri, 20 Apr 2001 11:11:17 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08002; Fri, 20 Apr 2001 11:11:20 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 11:11:17 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55309576@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Kavi, Prabhu'" , "'Eric Gray'" , "Charlap, David" Cc: mpls@UU.NET Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Fri, 20 Apr 2001 11:11:15 -0400 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 Eric > > > > many people are more concerned about having a bounded > > delay than they are about having a bounded delay variation. > > And with a bounded delay, you get bounded delay variation > > for free. I am not quite convinced by this! I looked at many pointers, esp, IETF IPPM working group. Why is delay variation is not as important as delay in delay sensitive applications? And more over, how can we get a bounded delay variation with a bounded delay? By looking at the: section 3.2 of http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-07.txt and http://carmen.cselt.it/papers/iss2000-ipdv/paper/ipdv.html Still so much research in going on in IP to make IPDV work Please let me know how did you came to the above conclusion -Venkata Naidu -- http://www.geocities.com/kvsnaidu From owner-mpls@UU.NET Fri Apr 20 11:37:23 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13296 for ; Fri, 20 Apr 2001 11:37:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklow06490; Fri, 20 Apr 2001 15:37:22 GMT Received: by mail-control.mail.uu.net id QQklow03711 for mpls-outgoing; Fri, 20 Apr 2001 15:36:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklow03690 for ; Fri, 20 Apr 2001 15:36:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklow02862 for ; Fri, 20 Apr 2001 15:36:00 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklow11928 for ; Fri, 20 Apr 2001 15:36:00 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23635; Fri, 20 Apr 2001 11:35:57 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14127; Fri, 20 Apr 2001 11:36:00 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 11:35:56 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55309577@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Kavi, Prabhu'" , "'Eric Gray'" , "Charlap, David" Cc: mpls@UU.NET Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Fri, 20 Apr 2001 11:35:48 -0400 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 > Eric, > > I interpreted David's statements to mean that you can get > completely bounded delay with variable size packets. David, > correct me if I am wrong. ATM established that cells, which are a set of frames that are all the same size, are preferred because they help to eliminate unacceptable "delay variability". In reality, the fact that ATM cells are short is more important than the fact that they're all the same size. The key factor in controlling delay is to control how long each cell - or frame - occupies the transmission facilities. The time that the cell or frame occupies the line - which we'll call "packet time" - is directly related to the "packet length" and inversely related to the transmission speed. In fairness, we should mention that the maximum packet size is at least as important as the fixed size for controlling delay. That is, a frame-based network with a small maximum packet size can offer the same packet times as a cell-based network with equal maximum packet size. Thanks & Regards Venkata Naidu > For example, a commonly used MTU of 1500 bytes requires only > 5 microseconds of transmission time on an OC-48. Therefore > it is possible to create a queueing mechanism where a high > priority packet is at most 5 microseconds away from the > start of transmission. Queuing points in the rest of the > system (if any) can be handled in a similar fashion. > > Implementations of these systems might not be as far away > as you think. > > Prabhu > > > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@sandburst.com] > > Sent: Friday, April 20, 2001 8:39 AM > > To: David Charlap > > Cc: mpls@UU.NET > > Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? > > > > > > David, > > > > I'm sure some smart person or another has written a paper > > on this, but I don't have the time to do a full-blown literature > > search right now. While what you are saying is technically > > true, I believe it has very little applicability in practice. > > You can see that this works by imagining that an implementation > > might treat MTU propagation time exactly the same way that ATM > > treats cell propagation time. > > > > But this is very ugly. It is so coarse that many would be > > hard pressed to consider it a useful guarantee. It also seems > > to require deliberately inserting latency (N times an MTU > > propagation time) for all affected traffic (to allow for packet > > shuffling to accomodate the guarantee). And it would be > > very difficult to allocate forwarding resources efficiently and > > still deliver guaranteed delay variation deterministically. > > > > Without making any moral judgement about why it is so, > > many people are more concerned about having a bounded > > delay than they are about having a bounded delay variation. > > And with a bounded delay, you get bounded delay variation > > for free. > > > > My opinion: there are two models here and trying to make > > technologies support both models may not be a good idea. > > > > -- > > Eric Gray > > > > You wrote: > > > > > Eric Gray wrote: > > > > > > > > You can't exactly do ATM style QoS over non-ATM media. > > > > > > > > The thing that allows an ATM switch to contemplate delay > > > > variation separately from delay is the fact that ATM switches > > > > switch data in fixed size chunks. When the size of data chunks > > > > can vary, the only practical way to control delay > variation is to > > > > try to control delay. Therefore, with IP packets on non-ATM > > > > media, you can't even begin support two knobs for delay and > > > > delay variation. So why would you undertake to add complexity > > > > by trying? > > > > > > Variable-size frames don't make it impossible. It just > > means you are > > > forced to work with a coarser granularity (defined by your > > configured > > > MTU size.) > > > > > > -- david From owner-mpls@UU.NET Fri Apr 20 11:55:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13523 for ; Fri, 20 Apr 2001 11:55:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklox06775; Fri, 20 Apr 2001 15:55:00 GMT Received: by mail-control.mail.uu.net id QQklox05732 for mpls-outgoing; Fri, 20 Apr 2001 15:54:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklox05712 for ; Fri, 20 Apr 2001 15:54:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklox13999 for ; Fri, 20 Apr 2001 15:53:34 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f77.law10.hotmail.com [64.4.15.77]) id QQklox13602 for ; Fri, 20 Apr 2001 15:53:33 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Apr 2001 08:53:33 -0700 Received: from 216.191.40.82 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 20 Apr 2001 15:53:33 GMT X-Originating-IP: [216.191.40.82] From: "Quan Sun" To: mpls@UU.NET Subject: Question about Label allocation in RSVP-TE Date: Fri, 20 Apr 2001 11:53:33 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Apr 2001 15:53:33.0342 (UTC) FILETIME=[0D73ABE0:01C0C9B2] Sender: owner-mpls@UU.NET Precedence: bulk A dumb question, but still a bit confusing for me when reading the RSVP TE draft: when you receive a Path message, (a) you immediately allocate a label for the upstream link and save it for later use (this label will be later put to the RESV message coming from the downstream node), or (b)the label is only allocated after a RESV message has come. If you read RSVP draft Section 4.1.1 (Handling Label Objects in Resv Messages), you understand the above (b) is the case. When you read Section 4.2.4 (Handling of LABEL_REQUEST), you have a feel that the label is attempted to be allocated when you receive the Path message (The draft says: "A node that recognizes a LABEL_REQUEST object, but that is unable to support it (possibly because of a failure to allocate labels) SHOULD send a PathErr...). At least, I know of a MPLS vendor who uses the above case (a). Or, this is an implementation specific issue? Quan that later this label will be put to the LABEL object in the RESV message, for puting to the RESV message Consider the following simple topology: --- LER1 --- LSR --- LER2 --- (1) LER1 first sends a Path message to LSR _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Fri Apr 20 12:02:47 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13704 for ; Fri, 20 Apr 2001 12:02:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloy04944; Fri, 20 Apr 2001 16:02:39 GMT Received: by mail-control.mail.uu.net id QQkloy10980 for mpls-outgoing; Fri, 20 Apr 2001 16:02:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkloy10516 for ; Fri, 20 Apr 2001 16:01:46 GMT Received: from sysenglt126 by imr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: ippool146-202.corp.us.uu.net [153.39.146.202]) id QQkloy12121; Fri, 20 Apr 2001 16:01:36 GMT Message-Id: <3.0.32.20010420120616.00a431d0@neserve0.corp.us.uu.net> X-Sender: abirjand@neserve0.corp.us.uu.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Apr 2001 12:06:16 -0400 To: giles@goneto.net, "Dekany, Steven" From: Amir Birjandi Subject: Re: LSP Failure Notification Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk >3. This address is looked up in the forwarding table (so this is a >recursive lookup.) >4. An RSVP-TE signalled LSP will be found which matches this address. What If you inject LSPs into your IGP. Would the steps be still as you described? Going back to Steve's Q, as mentioned: IP forwarding in his situation. A. From owner-mpls@UU.NET Fri Apr 20 12:08:07 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13820 for ; Fri, 20 Apr 2001 12:08:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloy24251; Fri, 20 Apr 2001 16:07:46 GMT Received: by mail-control.mail.uu.net id QQkloy19327 for mpls-outgoing; Fri, 20 Apr 2001 16:07:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkloy19066 for ; Fri, 20 Apr 2001 16:07:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkloy29702; Fri, 20 Apr 2001 16:06:44 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkloy22687; Fri, 20 Apr 2001 16:06:43 GMT Received: from goneto.net (unknown [195.167.134.116]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id DAC8715F7E6; Fri, 20 Apr 2001 17:06:37 +0100 (BST) Message-ID: <3AE06B64.4355B243@goneto.net> Date: Fri, 20 Apr 2001 18:01:24 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Amir Birjandi Cc: "Dekany, Steven" , mpls@UU.NET Subject: Re: LSP Failure Notification References: <3.0.32.20010420120616.00a431d0@neserve0.corp.us.uu.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Amir Birjandi wrote: > > >3. This address is looked up in the forwarding table (so this is a > >recursive lookup.) > >4. An RSVP-TE signalled LSP will be found which matches this address. > > What If you inject LSPs into your IGP. Would the steps be still as you > described? I would guess it'd be pretty much the same - except that the second lookup would return what appeared to be a direct link to the BGP next-hop, rather than an LSP? In any case this link would probably have a lower metric than going hop by hop so it would be preferred to the hop by hop path... > Going back to Steve's Q, as mentioned: IP forwarding in his situation. Yes. Which may be a problem if you have an ATM LSR (like Marconi's?) Either it won't have the full BGP routes, or if it does it may well end up doing IP forwarding in software? Giles -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Fri Apr 20 12:09:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13843 for ; Fri, 20 Apr 2001 12:09:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloy27236; Fri, 20 Apr 2001 16:09:37 GMT Received: by mail-control.mail.uu.net id QQkloy23934 for mpls-outgoing; Fri, 20 Apr 2001 16:09:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkloy23062 for ; Fri, 20 Apr 2001 16:08:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkloy27158 for ; Fri, 20 Apr 2001 16:08:03 GMT Received: from mason2.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQkloy10982 for ; Fri, 20 Apr 2001 16:08:02 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id MAA19284; Fri, 20 Apr 2001 12:08:07 -0400 (EDT) Date: Fri, 20 Apr 2001 12:08:07 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: Bora Akyol cc: "Dekany, Steven" , mpls@UU.NET Subject: Re: LSP Failure Notification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Bora, See the inlines:) On Fri, 20 Apr 2001, Bora Akyol wrote: > The tunnels are established using IGP reachability information. When the > tunnel goes away, IGP route will become the next best route and traffic > will be traveling via IP. > > This may take a while, but until the head end realizes that the tunnel is > down, there really is not much you can do. The packets will fall on the > ground. I think, probably using local repair can reduce the loss of packets. -Rajiv > > I believe G-MPLS defines a failure notification mechanism. > > Bora > > > On Fri, 20 Apr 2001, Dekany, Steven wrote: > > > Greetings; > > > > I am looking for help, with the following: > > > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > > signaling protocol. Customer sites are connected to my network via various > > IP only links - no MPLS. Upon a LSP link failure in my core - assume that > > I have exhausted all back-up, re-route etc., options and my LSP tunnel is > > still down - what happens to my incoming IP traffic at the ingress LER? Is > > there an ICMP message generated back to IP Source with "Destination > > Unreachable? , or an SNMP Trap, or both? Or something else? > > > > (Or is this a dumb question, because I have not read the relevant draft...) > > > > Any help or pointers would be greatly appreciated. > > > > Thanks in advance, > > > > > > Steven > > > > ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4703 email: rpapneja@osf1.gmu.edu ******************************** From owner-mpls@UU.NET Fri Apr 20 12:22:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14034 for ; Fri, 20 Apr 2001 12:22:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloz26104; Fri, 20 Apr 2001 16:22:00 GMT Received: by mail-control.mail.uu.net id QQkloz26851 for mpls-outgoing; Fri, 20 Apr 2001 16:21:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkloz26837 for ; Fri, 20 Apr 2001 16:21:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkloz11224 for ; Fri, 20 Apr 2001 16:20:24 GMT Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQkloz20493 for ; Fri, 20 Apr 2001 16:20:24 GMT Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3KGKNn11840 for ; Fri, 20 Apr 2001 12:20:23 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f3KGKN711826; Fri, 20 Apr 2001 12:20:23 -0400 (EDT) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA17919; Fri, 20 Apr 2001 12:20:22 -0400 Message-ID: <3AE06284.9831EA9E@hotair.hobl.lucent.com> Date: Fri, 20 Apr 2001 12:23:32 -0400 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dekany, Steven" CC: Ramesh Bhandari , Bora Akyol , mpls@UU.NET Subject: Re: LSP Failure Notification References: <73573B0D37AFD311A3A800204840ED0322728C@dal-server-01.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Steve, Normally, if the customers's traffic is so critical, then one would (to meet the SLA) assign a separate (or at least shared) backup path for this particluar LSP. If the network is properly designed and used, the situation where no backup LSP is available, when the primary LSP fails, should not arise. In the event a new service request comes in and a backup cannot be found (and reserved) due to bandwidth exhaustion or for whatever reason, then the request (with protection LSP) should be denied. If the customer agrees to an unprotected LSP servce, then depending upon the SLA, "best effort" service in the event of a node/link failure could be provided. If the unprotected LSP service cannot be provided also, then the request for this service is also denied, and depending upon the SLA only "best effort" service may be provided. Ramesh "Dekany, Steven" wrote: > > Hi Ramesh, > > Yes, I have. The assumption that I made in my first email is, that I have > exhausted all back-up and LSP re-route options, at least temporarily. At the > moment there is no LSP available. What do SP's most often do in this case > with the incoming IP traffic? Signal back to source with Dest Unreachable? > Silently drop until a new LSP finally comes up? Light a red lamp in the NOC > signaling a NW outage or link failure? > > Best Regards, > > Steven > > -----Original Message----- > From: Ramesh Bhandari [mailto:bhandari1@lucent.com] > Sent: Friday, April 20, 2001 10:00 AM > To: Dekany, Steven > Cc: Bora Akyol; mpls@UU.NET > Subject: Re: LSP Failure Notification > > Steven, > > Have you considered phyiscally-disjoint pair of LSP's in the solution, > with one LSP as a backup so that if the primary path fails the affected > traffic can flow on the backup? > > Ramesh > > "Dekany, Steven" wrote: > > > > Thank you Bora; > > > > and thank you Haoxin and Giles. > > > > Yes, best effort is kind of the expected "default" behavior. I just wonder > > that when we say that the IGP route will become the "next best route" what > > happens to my SLA with the customer - assuming that there is one in place? > I > > guess the underlying assumption is that I use MPLS in the core because I > > want to give something better than best effort service to my customer. Now > > that my LSP is broken and that I cannot setup another one - at least for > > while, in theory - if I use best effort only, I have basically violated my > > service level agreement with my customer. Should I not notify him somehow? > > Or this REALLY VERY IMPLEMENTATION SPECIFIC - read, either private > > information, or policy dependent? > > > > Another theoretical question - how significant is usually the time delay > > between IGP's convergence and by the time RSVP-TE has found a new LSP? If > > that is a relatively short time, I may not care, but if it takes a few > tens > > of seconds or minutes, and I have a relatively high speed link to the LER, > > it may flood my network with unwanted IP traffic real badly too, causing > > another cascading TE problem for me potentially in the core. > > > > Along the same line, if I have certain traffic parameter requirements for > my > > LSP - as required by my SLA - it is entirely possible that RSVP-TE may not > > find a suitable LSP and comes back with PathErr. Do I still fall back to > > forward best effort? > > > > I wonder if there is any practical experience with this question, or IP > best > > effort is the generally implemented default. > > > > Thank you again to all again, who kindly responded, > > > > Best Regards, > > > > Steven > > > > > > -----Original Message----- > > From: Bora Akyol [mailto:akyol@pluris.com] > > Sent: Friday, April 20, 2001 9:00 AM > > To: Dekany, Steven > > Cc: mpls@UU.NET > > Subject: Re: LSP Failure Notification > > > > The tunnels are established using IGP reachability information. When the > > tunnel goes away, IGP route will become the next best route and traffic > > will be traveling via IP. > > > > This may take a while, but until the head end realizes that the tunnel is > > down, there really is not much you can do. The packets will fall on the > > ground. > > > > I believe G-MPLS defines a failure notification mechanism. > > > > Bora > > > > On Fri, 20 Apr 2001, Dekany, Steven wrote: > > > > > Greetings; > > > > > > I am looking for help, with the following: > > > > > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > > > signaling protocol. Customer sites are connected to my network via > various > > > IP only links - no MPLS. Upon a LSP link failure in my core - assume > > that > > > I have exhausted all back-up, re-route etc., options and my LSP tunnel > is > > > still down - what happens to my incoming IP traffic at the ingress LER? > Is > > > there an ICMP message generated back to IP Source with "Destination > > > Unreachable? , or an SNMP Trap, or both? Or something else? > > > > > > (Or is this a dumb question, because I have not read the relevant > > draft...) > > > > > > Any help or pointers would be greatly appreciated. > > > > > > Thanks in advance, > > > > > > > > > Steven > > > From owner-mpls@UU.NET Fri Apr 20 13:03:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14559 for ; Fri, 20 Apr 2001 13:03:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpc07755; Fri, 20 Apr 2001 17:03:17 GMT Received: by mail-control.mail.uu.net id QQklpc07659 for mpls-outgoing; Fri, 20 Apr 2001 17:02:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklpc06974 for ; Fri, 20 Apr 2001 17:02:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklpc10583 for ; Fri, 20 Apr 2001 17:00:45 GMT Received: from rly-ip02.mx.aol.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip02.mx.aol.com [152.163.225.160]) id QQklpc16063 for ; Fri, 20 Apr 2001 17:00:44 GMT Received: from tot-wj.proxy.aol.com (tot-wj.proxy.aol.com [205.188.198.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id NAA08902 for ; Fri, 20 Apr 2001 13:00:37 -0400 (EDT) Received: from SANJOSE1.ece.ucdavis.edu (AC8036FD.ipt.aol.com [172.128.54.253]) by tot-wj.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f3KH0aB28467 for ; Fri, 20 Apr 2001 13:00:36 -0400 (EDT) Message-Id: <5.0.2.1.0.20010420095346.00aebc70@ash.ece.ucdavis.edu> X-Sender: wswen@ash.ece.ucdavis.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 20 Apr 2001 09:58:46 -0700 To: mpls@UU.NET From: wushao wen Subject: Constraint-based Shortest path algorithm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Apparently-From: Wswen99@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Hello, In the traffic engineering, we need to calculate the constraint-based shortest path for a FEC. Is there any mature and efficient algorithm to do the calculation? Let's said that we have two parameter for each link (cost, and delay), how can we calculate the shortest path under end-to-end delay constraint (As I know, this is NP hard problem, right)? If anybody have implemented some algorithms on this, please let me know. Thanks! Wushao From owner-mpls@UU.NET Fri Apr 20 13:15:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14761 for ; Fri, 20 Apr 2001 13:15:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpd17806; Fri, 20 Apr 2001 17:15:06 GMT Received: by mail-control.mail.uu.net id QQklpc20367 for mpls-outgoing; Fri, 20 Apr 2001 17:14:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklpc20341 for ; Fri, 20 Apr 2001 17:14:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklpc18357 for ; Fri, 20 Apr 2001 17:13:06 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklpc12908 for ; Fri, 20 Apr 2001 17:13:06 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03455 for ; Fri, 20 Apr 2001 13:13:03 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10367 for ; Fri, 20 Apr 2001 13:13:06 -0400 (EDT) Message-ID: <3AE06E1B.EEB1946A@marconi.com> Date: Fri, 20 Apr 2001 13:12:59 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? References: <6B190B34070BD411ACA000B0D0214E56CB7F17@newman.tenornet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Kavi, Prabhu" wrote: > > I interpreted David's statements to mean that you can get > completely bounded delay with variable size packets. David, > correct me if I am wrong. Actually, Eric guessed right. Bounded delay with variable-size frames is certainly doable. The upper bound will be the worst-case delay for all packets sizes. I would instinctively guess that this would be the delay incurred by MTU-size packets, but this may not be true for all hardware. Controlling delay variability with variable-size frames is more difficult. As Eric described, you may have to deliberately hold a frame in one LSP and let one from another LSP get ahead in order to keep the delay as constant as possible. I think that per-LSP queueing (similar to ATM's per-VC queueing) can accomplish most of this goal. I do not expect this kind of hardware to be available until switching hardware designed explicitly for MPLS is developed and built. My point is simply that the signaling protocols should allow for these kinds of parameters now (perhaps as optional TLVs) so that they don't have to be extended when that kind of hardware comes into existance. -- David From owner-mpls@UU.NET Fri Apr 20 13:33:58 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15112 for ; Fri, 20 Apr 2001 13:33:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpe19591; Fri, 20 Apr 2001 17:33:51 GMT Received: by mail-control.mail.uu.net id QQklpe22720 for mpls-outgoing; Fri, 20 Apr 2001 17:33:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklpe22710 for ; Fri, 20 Apr 2001 17:33:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklpe11406 for ; Fri, 20 Apr 2001 17:30:55 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklpe15947 for ; Fri, 20 Apr 2001 17:30:54 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05244 for ; Fri, 20 Apr 2001 13:30:51 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15771 for ; Fri, 20 Apr 2001 13:30:56 -0400 (EDT) Message-ID: <3AE07249.7453D52E@marconi.com> Date: Fri, 20 Apr 2001 13:30:49 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls Subject: Re: LSP ID References: <3ADF47FF.23FEE4C@usa.alcatel.com> <3ADF77AF.C55FE2B8@marconi.com> <3AE05FCD.70748832@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yuan Gu wrote: > > CR-LDP LSPID is Locally unique to that LSR(please see the definition > above). > That means LSPID in RSVP-TE is unique within same node i.s.o same > session. No. In RSVP, the same LSPID can be used by multiple LSPs, as long as those LSPs are all in different sessions. I do not know if CR-LDP's LSPID must be unique for the entire LSR or if they are only unique on a per-FEC basis. -- David From owner-mpls@UU.NET Fri Apr 20 13:45:23 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15285 for ; Fri, 20 Apr 2001 13:45:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpf09889; Fri, 20 Apr 2001 17:45:21 GMT Received: by mail-control.mail.uu.net id QQklpe24189 for mpls-outgoing; Fri, 20 Apr 2001 17:44:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklpe24075 for ; Fri, 20 Apr 2001 17:44:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklpe11462 for ; Fri, 20 Apr 2001 17:44:10 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklpe09312 for ; Fri, 20 Apr 2001 17:44:10 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06350 for ; Fri, 20 Apr 2001 13:44:06 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19190 for ; Fri, 20 Apr 2001 13:44:11 -0400 (EDT) Message-ID: <3AE07564.80F6136@marconi.com> Date: Fri, 20 Apr 2001 13:44:04 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Question about Label allocation in RSVP-TE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Quan Sun wrote: > > A dumb question, but still a bit confusing for me when reading the > RSVP TE draft: when you receive a Path message, (a) you immediately > allocate a label for the upstream link and save it for later use > (this label will be later put to the RESV message coming from the > downstream node), or (b)the label is only allocated after a RESV > message has come. It doesn't matter. You can't send the label to the upstream peer until after the Resv arrives. What you do inside your box is not something that RFCs should be dictating. As with pre-reserving resources, there are advantages to both techniques. If you reserve the label during Path processing.... 1: You won't have to take the time to reserve it when the Resv arrives. Depending on your architecture, this might improve LSP setup times. 2: After successfully reserving the label, you won't have to worry about some other LSP taking the last one before your Resv arrives. 3: You will have to deal with the possibility of not having any labels available during Path processing. Do you send back an error? Or do you wait for the Resv and then try again? (in case another LSP was torn during that time.) 4: If you successfully allocate the label, and then the Path is torn before the Resv arrives, the allocation was wasteful. The label was never needed, because no data arrived. In a heavily-loaded situation, this may have prevented another LSP from coming up. > If you read RSVP draft Section 4.1.1 (Handling Label Objects in Resv > Messages), you understand the above (b) is the case. When you read > Section 4.2.4 (Handling of LABEL_REQUEST), you have a feel that the > label is attempted to be allocated when you receive the Path message > (The draft says: "A node that recognizes a LABEL_REQUEST object, but > that is unable to support it (possibly because of a failure to > allocate labels) SHOULD send a PathErr...). At least, I know of a > MPLS vendor who uses the above case (a). > > Or, this is an implementation specific issue? Implementation-specific would be my opinion. IMO, any behavior which is invisible outside the box (such as described above) should not be dictated by standards bodies. -- David From owner-mpls@UU.NET Fri Apr 20 13:52:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15408 for ; Fri, 20 Apr 2001 13:52:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpf24109; Fri, 20 Apr 2001 17:52:20 GMT Received: by mail-control.mail.uu.net id QQklpf25189 for mpls-outgoing; Fri, 20 Apr 2001 17:51:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklpf25168 for ; Fri, 20 Apr 2001 17:51:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklpf06086 for ; Fri, 20 Apr 2001 17:51:02 GMT Received: from fastdarth.exchange_domain by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gateway.frontierast.com [207.136.162.226] (may be forged)) id QQklpf21268 for ; Fri, 20 Apr 2001 17:51:01 GMT Received: by fastdarth.linkusa.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 12:50:43 -0500 Message-ID: <7E14AE1326DAD4118ED600A0C9E5CF6714B9AB@fastdarth.linkusa.com> From: Kevin Santamaria To: "'mpls@UU.net'" Subject: VoMPLS Date: Fri, 20 Apr 2001 12:50:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9C2.6B50983A" Sender: owner-mpls@UU.NET Precedence: bulk ------_=_NextPart_001_01C0C9C2.6B50983A Content-Type: text/plain; charset="iso-8859-1" I apologize if this has been asked and answered before, but can someone point me to any further work being done on VoMPLS after Thanks very much Kevin email: kevin_santamaria@globalcrossing.com 319-298-1493 <<...>> ------_=_NextPart_001_01C0C9C2.6B50983A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VoMPLS

      I = apologize if this has been asked and answered before, but can someone = point me to any further work being done on VoMPLS after = <draft-kankkunen-vompls-fw-01.txt>

      Thanks = very much

      Kevin

      email:  kevin_santamaria@globalcrossing.com
      319-298-1493
      = <<...>>

------_=_NextPart_001_01C0C9C2.6B50983A-- From owner-mpls@UU.NET Fri Apr 20 14:00:23 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15480 for ; Fri, 20 Apr 2001 14:00:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpg09556; Fri, 20 Apr 2001 18:00:20 GMT Received: by mail-control.mail.uu.net id QQklpf26218 for mpls-outgoing; Fri, 20 Apr 2001 17:59:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklpf26179 for ; Fri, 20 Apr 2001 17:59:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklpf01656 for ; Fri, 20 Apr 2001 17:59:11 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklpf01313 for ; Fri, 20 Apr 2001 17:59:10 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07650; Fri, 20 Apr 2001 13:59:07 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22710; Fri, 20 Apr 2001 13:59:11 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 13:59:09 -0400 Message-ID: <73573B0D37AFD311A3A800204840ED03227294@dal-server-01.pit.comms.marconi.com> From: "Dekany, Steven" To: Kevin Santamaria , "'mpls@UU.net'" Subject: RE: VoMPLS Date: Fri, 20 Apr 2001 13:59:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9C3.96BFECE0" 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_01C0C9C3.96BFECE0 Content-Type: text/plain; charset="iso-8859-1" Kevin, There is a lot of work done recently by the MPLS Forum. You might be interested to check it out. Best Regards, Steven -----Original Message----- From: Kevin Santamaria [mailto:kevin_santamaria@globalcrossing.com] Sent: Friday, April 20, 2001 12:51 PM To: 'mpls@UU.net' Subject: VoMPLS I apologize if this has been asked and answered before, but can someone point me to any further work being done on VoMPLS after Thanks very much Kevin email: kevin_santamaria@globalcrossing.com 319-298-1493 <<...>> ------_=_NextPart_001_01C0C9C3.96BFECE0 Content-Type: text/html; charset="iso-8859-1" VoMPLS
Kevin,
 
There is a lot of  work done recently by the MPLS Forum. You might be interested to check it out.
 
Best Regards,
 
Steven
-----Original Message-----
From: Kevin Santamaria [mailto:kevin_santamaria@globalcrossing.com]
Sent: Friday, April 20, 2001 12:51 PM
To: 'mpls@UU.net'
Subject: VoMPLS

      I apologize if this has been asked and answered before, but can someone point me to any further work being done on VoMPLS after <draft-kankkunen-vompls-fw-01.txt>

      Thanks very much

      Kevin

      email:  kevin_santamaria@globalcrossing.com
      319-298-1493
      <<...>>

------_=_NextPart_001_01C0C9C3.96BFECE0-- From owner-mpls@UU.NET Fri Apr 20 14:06:04 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15577 for ; Fri, 20 Apr 2001 14:06:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpg09749; Fri, 20 Apr 2001 18:05:58 GMT Received: by mail-control.mail.uu.net id QQklpg06366 for mpls-outgoing; Fri, 20 Apr 2001 18:05:26 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklpg05945 for ; Fri, 20 Apr 2001 18:05:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklpg09253 for ; Fri, 20 Apr 2001 18:05:06 GMT Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQklpg14268 for ; Fri, 20 Apr 2001 18:05:06 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3KI52R09787; Fri, 20 Apr 2001 14:05:02 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; FRI, 20 Apr 2001 14:00:45 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id <22V70N6R>; Fri, 20 Apr 2001 14:00:45 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E56CB7F1C@newman.tenornet.com> From: "Kavi, Prabhu" To: "'Kevin Santamaria'" , "'mpls@uu.net'" Subject: Re: VoMPLS Date: Fri, 20 Apr 2001 14:00:44 -0400 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 Kevin, Most of the active work on Voice over MPLS is being performed in the MPLS Forum. Since Voice over MPLS is not yet an Implementation Agreement that has been released, the current documents are only available to members of the MPLS Forum. Prabhu ---------------------------------------------------------------------- Prabhu Kavi Phone: 1-978-264-4900 x125 Director, Adv. Prod. Planning Fax: 1-978-264-0671 Tenor Networks Email: prabhu_kavi@tenornetworks.com 100 Nagog Park WWW: www.tenornetworks.com Acton, MA 01720 From owner-mpls@UU.NET Fri Apr 20 14:06:15 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15592 for ; Fri, 20 Apr 2001 14:06:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloc14728; Fri, 20 Apr 2001 10:37:18 GMT Received: by mail-control.mail.uu.net id QQkloc02624 for mpls-outgoing; Fri, 20 Apr 2001 10:36:47 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkloc02616 for ; Fri, 20 Apr 2001 10:36:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkloc21074 for ; Fri, 20 Apr 2001 10:34:08 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQkloc04715 for ; Fri, 20 Apr 2001 10:34:07 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Fri, 20 Apr 2001 11:21:03 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Fri, 20 Apr 2001 11:21:38 +0100 Message-ID: To: geoff.bennett@marconi.com, hansen.chan@alcatel.com Cc: rdonkin@orchestream.com, stagempls@hotmail.com, mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI?? Date: Fri, 20 Apr 2001 11:21:30 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Geoff....there is another important QoS-related difference between ATM and MPLS/IP which I have tried to explain on the list before.....but let me give it another shot since I think this may still be not understood looking at some of recent mails: 1 In a cnls fabric failures get mutated into QoS hits. That is, post the IGP re-convergence, there is no reduction in traffic demand, just a reduction in resource available. With 1 class (ie BE) there is uniform reduction in QoS to everyone, with multiple classes (ie DS) there is some skewing of the resource reduction across the classes. The tolerance of an application to accept resource reduction is application-specific....so what would be unacceptable to say some interactive services (eg voice) would be OK to some less-interactive service (eg Email). Contrast this now with an CO fabric. Here failures just take-out the traffic served by the affected trails. Traffic on unaffected trails sees no QoS hit. So this leads to the 1st observation wrt QoS in comparing a cnls and CO fabric, ie in a cnls fabric failures get mutated into QoS hits but this is not true in CO fabrics. 2 There is no relationship between the up-state QoS forwarding treatment of a given application and its survivability requirements. For example, whether voice is mission-critical or not it has to go EF class to meet delay/jitter-transfer requirements. However, within a VPN (or between different VPNs) who is to say which voice is/is-not mission critical? The sales team may have mission-critical voice but the engineering team may not.....however, things might be reversed for their data applications (which would use some AF class say). So this leads to the 2nd observation wrt QoS in *either* cnls or CO fabrics, ie the up-state QoS forwarding treatment of an application tells you nothing about its survivability requirements. 3 This now leads to the 3rd observation on QoS and availability, ie QoS and availability metrics/objectives need to be set independently, but QoS is only applicable when the trail considered is in the available state.....and from this and the 1st observation we note that this independence is strictly only possible in CO fabrics. 4 As pointed out by a couple of people in recent mails, VPN customers consider security/traffic-isolation requirements (ie trad L2 VPN look-alike) before they consider QoS requirements. Further, the survivability of VPN_A must not be a factor of the traffic/behaviour of any other VPNs. So when we couple this with the previous observations this leads to the almost inescapable requirement to have hard effective BW partitioning between VPNs. And it is this reason why one sees, and will continue to see, ATM in most operators access networks (since here one cannot appeal to 'over-engineering', as may be possible in the core). It was the above perspective (ie a need to be able to offer/measure availability on LSPs) that motivated our recent work on MPLS OAM which some of you will have read I guess. And until we get MPLS to offer the same (or ideally better) QoS/availability attributes, then ATM (or possibly FR and TDM fabrics) will continue to be required for those VPNs (and access networks) that require more robust availability/QoS objectives. regards, neil > -----Original Message----- > From: Geoff Bennett [mailto:geoff.bennett@marconi.com] > Sent: 20 April 2001 09:40 > To: HANSEN CHAN > Cc: Donkin, Richard; MP LS; mpls-ops@mplsrc.com; mpls@UU.NET > Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? > > > Hi Hansen, > I agree with you in general...MPLS should be able to > demonstrate similar > capabilities to ATM QoS, but I think most people would agree > there's a long > way to go yet, especially for the routing protocols. There's also the > problem that nobody is yet building LSRs that were designed > for the job. > They're all adaptations of either a router or an ATM switch design. > > Hard QoS architectures are hard to build. ATM got it right > for the most > part, but there would be a strong argument that the way ATM > does QoS (on a > VC basis) will not scale to networks as big as the Internet. > With MPLS we > can aggregate things nicely, but in my mind this is not QoS, > it's CoS. The > tradeoff we seem to be faced with is the "quality" of our QoS > architecture > vs its scalability. > > ATM also has the advantage that it's Connection Oriented from > end to end. > One of the reasons it can deliver such a hard QoS assurance > was that the > application itself is able to negotiate with the network to > ask for the > explicit QoS requirements, and to get the network's agreement > that these > resources were available. To duplicate this with MPLS we'd > have to extend > RSVP signalling to the host (or maybe to the voice gateway in a VoMPLS > installation). I know this has been discussed, but is at a > very early stage. > > Another advantage of ATM in terms of QoS is the fixed cell size. Any > fixed-PDU technology will have the edge over a variable PDU > technology when > it comes to QoS. Before I ignite a cells vs frames debate > let me say that > I believe the (many) advantages of a variable length PDU > infrastructure > (especially at very high speeds) outweight the QoS benefits > of fixed PDU. > In other words, I'll go along with the assumption that if you're > transmitting at a high enough speed, the CoS you can squeeze out of a > variable PDU network will one day be "good enough" (if you > over-provision > the network sufficiently). > > Cheers, > Geoff > > > > At 11:53 19/04/01 -0400, HANSEN CHAN wrote: > >> But as I understand it, the added value from IP VPNs > either comes from > >> security (whether this is "isolational" in nature like an > ATM or Frame > >> Relay VPN, or "truly secure" as in the case of an ecrypted > ATM or IPSec VPN > >> is up to the user), or from "perceived service > enhancement". The latter > >> could be via a CoS mechanism, which MPLS can potentially > offer, or from a > >> hard QoS mechanism which can only be offered from... > >> > >> a: A TDM mechanism (like SONET/SDH, which is expensive). > >> b: A native ATM service. > >> c: An over-provisioned stat mux service (eg. IP), which is > also expensive > >> in the long term. > > > >Geoff, > > > >I agree with your points above. However, I don't think there > is anything > stop MPLS implemented with a hard QoS mechanism like ATM > >has done. A good LSR with the necessary traffic management > infrastructure > (queuing and scheduling) can achieve the same level, if > >not better QoS. > > > >Cheers, > >Hansen > > > >------- > >The MPLS-OPS Mailing List > >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > > ================================================================ > Geoff Bennett > Tel: (33) 497 21 43 62 > Director of Technology, OCTO > Fax: (33) 497 21 43 50 > Marconi > Gaia - Bat. E > email: geoff.bennett@marconi.com > BP 123 > 06903 SOPHIA ANTIPOLIS > FRANCE > ================================================================ > From owner-mpls@UU.NET Fri Apr 20 14:15:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15714 for ; Fri, 20 Apr 2001 14:15:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklph29077; Fri, 20 Apr 2001 18:15:20 GMT Received: by mail-control.mail.uu.net id QQklpg15273 for mpls-outgoing; Fri, 20 Apr 2001 18:14:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklpg15249 for ; Fri, 20 Apr 2001 18:14:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklpg06109 for ; Fri, 20 Apr 2001 18:13:45 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQklpg26909 for ; Fri, 20 Apr 2001 18:13:45 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f3KIBo514025 for ; Fri, 20 Apr 2001 11:11:50 -0700 (PDT) Reply-To: From: "Anil Gunturu" To: Subject: Two signalling protocols (LDP & RSVP) Date: Fri, 20 Apr 2001 11:12:21 -0700 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.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Is it possible to run both LDP and RSVP on the same interface? If it is possible can they be using the same label space? -Anil From owner-mpls@UU.NET Fri Apr 20 14:16:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15750 for ; Fri, 20 Apr 2001 14:16:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklph01590; Fri, 20 Apr 2001 18:16:49 GMT Received: by mail-control.mail.uu.net id QQklpg15295 for mpls-outgoing; Fri, 20 Apr 2001 18:14:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklpg15243 for ; Fri, 20 Apr 2001 18:14:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklpg13539 for ; Fri, 20 Apr 2001 18:13:47 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f256.law10.hotmail.com [64.4.14.131]) id QQklpg18451 for ; Fri, 20 Apr 2001 18:13:47 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Apr 2001 11:13:46 -0700 Received: from 216.191.40.82 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 20 Apr 2001 18:13:45 GMT X-Originating-IP: [216.191.40.82] From: "Quan Sun" To: mpls@UU.NET Subject: PathErr processing in GMPS RSVP-TE Date: Fri, 20 Apr 2001 14:13:45 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Apr 2001 18:13:46.0755 (UTC) FILETIME=[A43C9D30:01C0C9C5] Sender: owner-mpls@UU.NET Precedence: bulk RSVP [RFC 2205] specifies the intermediate node may inspect the PathErr message, but should not take any action upon it. GMPS RSVP-TE extends the related functionality by introducing a Path_State_removed flag. A question is: Does GMPS RSVP-TE introduce any more functionalities involving the PathErr message processing besides the above mentioned? If you read the "Contention Resolution" section of the "GMPS Signaling Function Description" draft, you'll find that 'To resolve contention, the node with the higher node ID will win the contention and it MUST issue a PathErr message. Upon receipt of such error, the node SHOULD try to allocate a different Upstream label. If no other resources are available, the node must proceed with standard error processing...' Which means that the node must take further actions upon receiving the PathErr message. For the above situation, does it mean that after you succesfully allocate another Upstream label, the PathErr message should not be passed to the original source node? At least, the current GMPS RSVP-TE should make further clarifications about this situation. Quan _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Fri Apr 20 15:06:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16491 for ; Fri, 20 Apr 2001 15:06:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpk23432; Fri, 20 Apr 2001 19:06:46 GMT Received: by mail-control.mail.uu.net id QQklpk04142 for mpls-outgoing; Fri, 20 Apr 2001 19:06:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklpk03625 for ; Fri, 20 Apr 2001 19:05:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklpk00115 for ; Fri, 20 Apr 2001 19:05:45 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f81.law10.hotmail.com [64.4.15.81]) id QQklpk20454 for ; Fri, 20 Apr 2001 19:05:45 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Apr 2001 12:05:44 -0700 Received: from 216.191.40.82 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 20 Apr 2001 19:05:44 GMT X-Originating-IP: [216.191.40.82] From: "Quan Sun" To: mpls@UU.NET Subject: Re: Question about Label allocation in RSVP-TE Date: Fri, 20 Apr 2001 15:05:44 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Apr 2001 19:05:44.0660 (UTC) FILETIME=[E6A72940:01C0C9CC] Sender: owner-mpls@UU.NET Precedence: bulk Thank you, David. What you said makes sense. Could you (or someone else) make some more points (advantages/disadvantages) about similar situation involving bi-directional path setup in GMPLS using RSVP-TE? In that case, when a Resv message comes (e.g. to an intermediate node), if no resource is avaliable at that node, it would be frustrating (and costly if the entire path must be torn down) because the reverse path is already established and may be carrying data (see Section 3.1 of Bidirectionnal LSPs of the GMPLS RSVP-TE draft). Quan >From: David Charlap >To: mpls@UU.NET >Subject: Re: Question about Label allocation in RSVP-TE >Date: Fri, 20 Apr 2001 13:44:04 -0400 > >Quan Sun wrote: > > > > A dumb question, but still a bit confusing for me when reading the > > RSVP TE draft: when you receive a Path message, (a) you immediately > > allocate a label for the upstream link and save it for later use > > (this label will be later put to the RESV message coming from the > > downstream node), or (b)the label is only allocated after a RESV > > message has come. > >It doesn't matter. You can't send the label to the upstream peer until >after the Resv arrives. What you do inside your box is not something >that RFCs should be dictating. > >As with pre-reserving resources, there are advantages to both >techniques. > >If you reserve the label during Path processing.... > >1: You won't have to take the time to reserve it when the Resv > arrives. Depending on your architecture, this might improve LSP > setup times. > >2: After successfully reserving the label, you won't have to worry > about some other LSP taking the last one before your Resv arrives. > >3: You will have to deal with the possibility of not having any labels > available during Path processing. Do you send back an error? Or > do you wait for the Resv and then try again? (in case another LSP > was torn during that time.) > >4: If you successfully allocate the label, and then the Path is torn > before the Resv arrives, the allocation was wasteful. The label > was never needed, because no data arrived. In a heavily-loaded > situation, this may have prevented another LSP from coming up. > > > If you read RSVP draft Section 4.1.1 (Handling Label Objects in Resv > > Messages), you understand the above (b) is the case. When you read > > Section 4.2.4 (Handling of LABEL_REQUEST), you have a feel that the > > label is attempted to be allocated when you receive the Path message > > (The draft says: "A node that recognizes a LABEL_REQUEST object, but > > that is unable to support it (possibly because of a failure to > > allocate labels) SHOULD send a PathErr...). At least, I know of a > > MPLS vendor who uses the above case (a). > > > > Or, this is an implementation specific issue? > >Implementation-specific would be my opinion. > >IMO, any behavior which is invisible outside the box (such as described >above) should not be dictated by standards bodies. > >-- David _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Fri Apr 20 15:57:33 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17206 for ; Fri, 20 Apr 2001 15:57:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpn19138; Fri, 20 Apr 2001 19:57:26 GMT Received: by mail-control.mail.uu.net id QQklpn14241 for mpls-outgoing; Fri, 20 Apr 2001 19:56:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklpn14196 for ; Fri, 20 Apr 2001 19:56:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklpn28577 for ; Fri, 20 Apr 2001 19:54:52 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQklpn16372 for ; Fri, 20 Apr 2001 19:54:52 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3KJspY24695 for ; Fri, 20 Apr 2001 15:54:51 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f3KJspl24685; Fri, 20 Apr 2001 15:54:51 -0400 (EDT) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA06606; Fri, 20 Apr 2001 15:54:50 -0400 Message-ID: <3AE094C8.53766720@hotair.hobl.lucent.com> Date: Fri, 20 Apr 2001 15:58:00 -0400 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ramesh Bhandari CC: "Dekany, Steven" , Bora Akyol , mpls@UU.NET Subject: Re: LSP Failure Notification References: <73573B0D37AFD311A3A800204840ED03227290@dal-server-01.pit.comms.marconi.com> <3AE08FE4.2B7316DB@hotair.hobl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit For completeness, I might add that for calculation of physically-disjoint paths incorporating SRLG's, I have a book: "Survivable Networks: Algorithms for Diverse Routing", Kluwer Academic Publishers (1999). Ramesh Bhandari wrote: > > Steven, > > I might not still be answering your questions, but following are my > comments: > > While leasing dark fiber, two cases arise: > > 1) The lessor guarantees diversely routed fibers (no sheath > commonality)for different pairs of nodes in the network, in which case > no problem should arise, assuming the lessor indeed honestly upholds the > diversity part of the agreement. > > 2) The lessor provides information on the fiber routes leased, and one > then determines the SRLG's and computes the physically-diverse routes > for the given pairs of nodes. If the lessor does not provide this > information because of the proprietary nature, then of course, one > option is to not to lease dark fiber for diversity purposes, and the > other is to simply run the risk of losing both the paths when a sheath > is cut, which is what I believe you are concerned with. In this latter > event, you ares stuck as you have described. > > Ramesh > > > > "Dekany, Steven" wrote: > > > > Ramesh, > > > > See comments inline, > > > > Thanks again, > > > > Steven > > > > -----Original Message----- > > From: Ramesh Bhandari [mailto:bhandari1@lucent.com] > > Sent: Friday, April 20, 2001 11:24 AM > > To: Dekany, Steven > > Cc: Ramesh Bhandari; Bora Akyol; mpls@UU.NET > > Subject: Re: LSP Failure Notification > > > > Steve, > > > > Normally, if the customers's traffic is so critical, then one would (to > > meet the SLA) assign a separate (or at least shared) backup path for > > this particluar LSP. If the network is properly designed and used, the > > situation where no backup LSP is available, when the primary LSP fails, > > should not arise. > > > > * The question is, what do I do if it still does? Example: My backup > > LSP is running over a diverse fiber route but without me knowing about it, > > the two fibers may still share the same sheath. Construction, backhoe error > > etc., I am leasing dark fiber. So now I am stuck. There may still be an IP > > hop by hp route available via Timbuktu though... > > > > * I guess I am interested to find out if there is any "standard" > > error signaling used somehow back to the source, either recommended by any > > of the standards or implemented as a matter of practice by a SP, in case my > > LSP tunnel is hopelessly lost and I still have IP traffic coming in to my > > ingress LER. > > > > * I am not sure if Giles' comment applies to ATM LSR's only. What does > > BGP have to do with the original question? Are you suggesting to use BGP in > > case of LSP failures? I know, that may be a backup safety net for some SP's > > running VPN's, but I am not running VPN's in this particular situation, this > > is only a "straight" or - crooked - LSP. BTW, for the record, Marconi does > > have BGP ... > > > > In the event a new service request comes in and a > > backup cannot be found (and reserved) due to bandwidth exhaustion or > > for whatever reason, then the request (with protection LSP) should be > > denied. If the customer agrees to an unprotected LSP servce, then > > depending upon the SLA, "best effort" service in the event of a > > node/link failure could be provided. If the unprotected LSP service > > cannot be provided also, then the request for this service is also > > denied, and depending upon the SLA only "best effort" service may be > > provided. > > > > Ramesh > > > > "Dekany, Steven" wrote: > > > > > > Hi Ramesh, > > > > > > Yes, I have. The assumption that I made in my first email is, that I have > > > exhausted all back-up and LSP re-route options, at least temporarily. At > > the > > > moment there is no LSP available. What do SP's most often do in this case > > > with the incoming IP traffic? Signal back to source with Dest Unreachable? > > > Silently drop until a new LSP finally comes up? Light a red lamp in the > > NOC > > > signaling a NW outage or link failure? > > > > > > Best Regards, > > > > > > Steven > > > > > > -----Original Message----- > > > From: Ramesh Bhandari [mailto:bhandari1@lucent.com] > > > Sent: Friday, April 20, 2001 10:00 AM > > > To: Dekany, Steven > > > Cc: Bora Akyol; mpls@UU.NET > > > Subject: Re: LSP Failure Notification > > > > > > Steven, > > > > > > Have you considered phyiscally-disjoint pair of LSP's in the solution, > > > with one LSP as a backup so that if the primary path fails the affected > > > traffic can flow on the backup? > > > > > > Ramesh > > > > > > "Dekany, Steven" wrote: > > > > > > > > Thank you Bora; > > > > > > > > and thank you Haoxin and Giles. > > > > > > > > Yes, best effort is kind of the expected "default" behavior. I just > > wonder > > > > that when we say that the IGP route will become the "next best route" > > what > > > > happens to my SLA with the customer - assuming that there is one in > > place? > > > I > > > > guess the underlying assumption is that I use MPLS in the core because I > > > > want to give something better than best effort service to my customer. > > Now > > > > that my LSP is broken and that I cannot setup another one - at least for > > > > while, in theory - if I use best effort only, I have basically violated > > my > > > > service level agreement with my customer. Should I not notify him > > somehow? > > > > Or this REALLY VERY IMPLEMENTATION SPECIFIC - read, either private > > > > information, or policy dependent? > > > > > > > > Another theoretical question - how significant is usually the time delay > > > > between IGP's convergence and by the time RSVP-TE has found a new LSP? > > If > > > > that is a relatively short time, I may not care, but if it takes a few > > > tens > > > > of seconds or minutes, and I have a relatively high speed link to the > > LER, > > > > it may flood my network with unwanted IP traffic real badly too, causing > > > > another cascading TE problem for me potentially in the core. > > > > > > > > Along the same line, if I have certain traffic parameter requirements > > for > > > my > > > > LSP - as required by my SLA - it is entirely possible that RSVP-TE may > > not > > > > find a suitable LSP and comes back with PathErr. Do I still fall back to > > > > forward best effort? > > > > > > > > I wonder if there is any practical experience with this question, or IP > > > best > > > > effort is the generally implemented default. > > > > > > > > Thank you again to all again, who kindly responded, > > > > > > > > Best Regards, > > > > > > > > Steven > > > > > > > > > > > > -----Original Message----- > > > > From: Bora Akyol [mailto:akyol@pluris.com] > > > > Sent: Friday, April 20, 2001 9:00 AM > > > > To: Dekany, Steven > > > > Cc: mpls@UU.NET > > > > Subject: Re: LSP Failure Notification > > > > > > > > The tunnels are established using IGP reachability information. When the > > > > tunnel goes away, IGP route will become the next best route and traffic > > > > will be traveling via IP. > > > > > > > > This may take a while, but until the head end realizes that the tunnel > > is > > > > down, there really is not much you can do. The packets will fall on the > > > > ground. > > > > > > > > I believe G-MPLS defines a failure notification mechanism. > > > > > > > > Bora > > > > > > > > On Fri, 20 Apr 2001, Dekany, Steven wrote: > > > > > > > > > Greetings; > > > > > > > > > > I am looking for help, with the following: > > > > > > > > > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > > > > > signaling protocol. Customer sites are connected to my network via > > > various > > > > > IP only links - no MPLS. Upon a LSP link failure in my core - assume > > > > that > > > > > I have exhausted all back-up, re-route etc., options and my LSP tunnel > > > is > > > > > still down - what happens to my incoming IP traffic at the ingress > > LER? > > > Is > > > > > there an ICMP message generated back to IP Source with "Destination > > > > > Unreachable? , or an SNMP Trap, or both? Or something else? > > > > > > > > > > (Or is this a dumb question, because I have not read the relevant > > > > draft...) > > > > > > > > > > Any help or pointers would be greatly appreciated. > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > > > > Steven > > > > > From owner-mpls@UU.NET Fri Apr 20 16:04:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17338 for ; Fri, 20 Apr 2001 16:04:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpo09969; Fri, 20 Apr 2001 20:04:36 GMT Received: by mail-control.mail.uu.net id QQklpo23875 for mpls-outgoing; Fri, 20 Apr 2001 20:03:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklpo22860 for ; Fri, 20 Apr 2001 20:03:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklpo06747 for ; Fri, 20 Apr 2001 20:02:13 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklpo25087 for ; Fri, 20 Apr 2001 20:02:12 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA04752 for mpls@uu.net; Fri, 20 Apr 2001 16:02:12 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklpo18673 for ; Fri, 20 Apr 2001 20:01:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklpo16079 for ; Fri, 20 Apr 2001 20:01:19 GMT Received: from che-cse-115.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.140.33]) id QQklpo24588 for ; Fri, 20 Apr 2001 20:01:19 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id QAA19270; Fri, 20 Apr 2001 16:01:16 -0400 (EDT) Date: Fri, 20 Apr 2001 16:01:16 -0400 From: Eric Osborne To: anilg@acc.am.ericsson.se Cc: mpls@UU.NET Subject: Re: Two signalling protocols (LDP & RSVP) Message-ID: <20010420160116.D19223@che-cse-115.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from anilg@acc.com on Fri, Apr 20, 2001 at 11:12:21AM -0700 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Fri, Apr 20, 2001 at 11:12:21AM -0700, Anil Gunturu wrote: > Hi, > Is it possible to run both LDP and RSVP on the same interface? If it is > possible can they be using the same label space? > -Anil Yes, and yes. eric From owner-mpls@UU.NET Fri Apr 20 16:19:03 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17499 for ; Fri, 20 Apr 2001 16:19:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpm27845; Fri, 20 Apr 2001 19:35:47 GMT Received: by mail-control.mail.uu.net id QQklpm11771 for mpls-outgoing; Fri, 20 Apr 2001 19:35:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklpm11748 for ; Fri, 20 Apr 2001 19:34:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklpm17412 for ; Fri, 20 Apr 2001 19:34:00 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQklpm23341 for ; Fri, 20 Apr 2001 19:34:00 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3KJXxY11810 for ; Fri, 20 Apr 2001 15:33:59 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f3KJXxl11799; Fri, 20 Apr 2001 15:33:59 -0400 (EDT) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA05407; Fri, 20 Apr 2001 15:33:58 -0400 Message-ID: <3AE08FE4.2B7316DB@hotair.hobl.lucent.com> Date: Fri, 20 Apr 2001 15:37:08 -0400 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dekany, Steven" CC: Ramesh Bhandari , Bora Akyol , mpls@UU.NET Subject: Re: LSP Failure Notification References: <73573B0D37AFD311A3A800204840ED03227290@dal-server-01.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Steven, I might not still be answering your questions, but following are my comments: While leasing dark fiber, two cases arise: 1) The lessor guarantees diversely routed fibers (no sheath commonality)for different pairs of nodes in the network, in which case no problem should arise, assuming the lessor indeed honestly upholds the diversity part of the agreement. 2) The lessor provides information on the fiber routes leased, and one then determines the SRLG's and computes the physically-diverse routes for the given pairs of nodes. If the lessor does not provide this information because of the proprietary nature, then of course, one option is to not to lease dark fiber for diversity purposes, and the other is to simply run the risk of losing both the paths when a sheath is cut, which is what I believe you are concerned with. In this latter event, you ares stuck as you have described. Ramesh "Dekany, Steven" wrote: > > Ramesh, > > See comments inline, > > Thanks again, > > Steven > > -----Original Message----- > From: Ramesh Bhandari [mailto:bhandari1@lucent.com] > Sent: Friday, April 20, 2001 11:24 AM > To: Dekany, Steven > Cc: Ramesh Bhandari; Bora Akyol; mpls@UU.NET > Subject: Re: LSP Failure Notification > > Steve, > > Normally, if the customers's traffic is so critical, then one would (to > meet the SLA) assign a separate (or at least shared) backup path for > this particluar LSP. If the network is properly designed and used, the > situation where no backup LSP is available, when the primary LSP fails, > should not arise. > > * The question is, what do I do if it still does? Example: My backup > LSP is running over a diverse fiber route but without me knowing about it, > the two fibers may still share the same sheath. Construction, backhoe error > etc., I am leasing dark fiber. So now I am stuck. There may still be an IP > hop by hp route available via Timbuktu though... > > * I guess I am interested to find out if there is any "standard" > error signaling used somehow back to the source, either recommended by any > of the standards or implemented as a matter of practice by a SP, in case my > LSP tunnel is hopelessly lost and I still have IP traffic coming in to my > ingress LER. > > * I am not sure if Giles' comment applies to ATM LSR's only. What does > BGP have to do with the original question? Are you suggesting to use BGP in > case of LSP failures? I know, that may be a backup safety net for some SP's > running VPN's, but I am not running VPN's in this particular situation, this > is only a "straight" or - crooked - LSP. BTW, for the record, Marconi does > have BGP ... > > In the event a new service request comes in and a > backup cannot be found (and reserved) due to bandwidth exhaustion or > for whatever reason, then the request (with protection LSP) should be > denied. If the customer agrees to an unprotected LSP servce, then > depending upon the SLA, "best effort" service in the event of a > node/link failure could be provided. If the unprotected LSP service > cannot be provided also, then the request for this service is also > denied, and depending upon the SLA only "best effort" service may be > provided. > > Ramesh > > "Dekany, Steven" wrote: > > > > Hi Ramesh, > > > > Yes, I have. The assumption that I made in my first email is, that I have > > exhausted all back-up and LSP re-route options, at least temporarily. At > the > > moment there is no LSP available. What do SP's most often do in this case > > with the incoming IP traffic? Signal back to source with Dest Unreachable? > > Silently drop until a new LSP finally comes up? Light a red lamp in the > NOC > > signaling a NW outage or link failure? > > > > Best Regards, > > > > Steven > > > > -----Original Message----- > > From: Ramesh Bhandari [mailto:bhandari1@lucent.com] > > Sent: Friday, April 20, 2001 10:00 AM > > To: Dekany, Steven > > Cc: Bora Akyol; mpls@UU.NET > > Subject: Re: LSP Failure Notification > > > > Steven, > > > > Have you considered phyiscally-disjoint pair of LSP's in the solution, > > with one LSP as a backup so that if the primary path fails the affected > > traffic can flow on the backup? > > > > Ramesh > > > > "Dekany, Steven" wrote: > > > > > > Thank you Bora; > > > > > > and thank you Haoxin and Giles. > > > > > > Yes, best effort is kind of the expected "default" behavior. I just > wonder > > > that when we say that the IGP route will become the "next best route" > what > > > happens to my SLA with the customer - assuming that there is one in > place? > > I > > > guess the underlying assumption is that I use MPLS in the core because I > > > want to give something better than best effort service to my customer. > Now > > > that my LSP is broken and that I cannot setup another one - at least for > > > while, in theory - if I use best effort only, I have basically violated > my > > > service level agreement with my customer. Should I not notify him > somehow? > > > Or this REALLY VERY IMPLEMENTATION SPECIFIC - read, either private > > > information, or policy dependent? > > > > > > Another theoretical question - how significant is usually the time delay > > > between IGP's convergence and by the time RSVP-TE has found a new LSP? > If > > > that is a relatively short time, I may not care, but if it takes a few > > tens > > > of seconds or minutes, and I have a relatively high speed link to the > LER, > > > it may flood my network with unwanted IP traffic real badly too, causing > > > another cascading TE problem for me potentially in the core. > > > > > > Along the same line, if I have certain traffic parameter requirements > for > > my > > > LSP - as required by my SLA - it is entirely possible that RSVP-TE may > not > > > find a suitable LSP and comes back with PathErr. Do I still fall back to > > > forward best effort? > > > > > > I wonder if there is any practical experience with this question, or IP > > best > > > effort is the generally implemented default. > > > > > > Thank you again to all again, who kindly responded, > > > > > > Best Regards, > > > > > > Steven > > > > > > > > > -----Original Message----- > > > From: Bora Akyol [mailto:akyol@pluris.com] > > > Sent: Friday, April 20, 2001 9:00 AM > > > To: Dekany, Steven > > > Cc: mpls@UU.NET > > > Subject: Re: LSP Failure Notification > > > > > > The tunnels are established using IGP reachability information. When the > > > tunnel goes away, IGP route will become the next best route and traffic > > > will be traveling via IP. > > > > > > This may take a while, but until the head end realizes that the tunnel > is > > > down, there really is not much you can do. The packets will fall on the > > > ground. > > > > > > I believe G-MPLS defines a failure notification mechanism. > > > > > > Bora > > > > > > On Fri, 20 Apr 2001, Dekany, Steven wrote: > > > > > > > Greetings; > > > > > > > > I am looking for help, with the following: > > > > > > > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > > > > signaling protocol. Customer sites are connected to my network via > > various > > > > IP only links - no MPLS. Upon a LSP link failure in my core - assume > > > that > > > > I have exhausted all back-up, re-route etc., options and my LSP tunnel > > is > > > > still down - what happens to my incoming IP traffic at the ingress > LER? > > Is > > > > there an ICMP message generated back to IP Source with "Destination > > > > Unreachable? , or an SNMP Trap, or both? Or something else? > > > > > > > > (Or is this a dumb question, because I have not read the relevant > > > draft...) > > > > > > > > Any help or pointers would be greatly appreciated. > > > > > > > > Thanks in advance, > > > > > > > > > > > > Steven > > > > From owner-mpls@UU.NET Sat Apr 21 04:23:52 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08728 for ; Sat, 21 Apr 2001 04:23:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklrl19574; Sat, 21 Apr 2001 08:23:53 GMT Received: by mail-control.mail.uu.net id QQklrl01726 for mpls-outgoing; Sat, 21 Apr 2001 08:23:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklrl01715 for ; Sat, 21 Apr 2001 08:23:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklrl23889 for ; Sat, 21 Apr 2001 08:22:04 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklrl12562 for ; Sat, 21 Apr 2001 08:22:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA02506 for mpls@uu.net; Sat, 21 Apr 2001 04:22:04 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklrl01663 for ; Sat, 21 Apr 2001 08:21:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklrl29745 for ; Sat, 21 Apr 2001 08:20:51 GMT Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQklrl29784 for ; Sat, 21 Apr 2001 08:20:51 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3L8KxG31170; Sat, 21 Apr 2001 11:20:59 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15073.17131.642478.638474@lohi.eng.telia.fi> Date: Sat, 21 Apr 2001 11:20:59 +0300 (EEST) To: erosen@cisco.com Cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <200104201409.KAA07160@erosen-sun.cisco.com> References: <15071.24339.890504.475774@lohi.eng.telia.fi> <200104201409.KAA07160@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: > I think the IP header already contains a field which the user can set to > signal diffserv support to the service provider. Or are you saying that it > is important to be able to signal diffserv on a per-packet basis for non-IP > packets? i as a service provider don't have any idea what packets my customer is carrying over the l2 circuits between their sites. it is beneficial for the customer if it can tell in the exp field how it wants the packets to be treated when they cross my network. > This suggests that the backbone should run MPLS, rather than Frame Relay, > and I'd certainly agree with that, but I don't see why this is an issue > vis. a vis. CE-CE LSPs. Of course, if two CEs want to send each other MPLS > packets, they can send them over any data link whatsoever. if the customer uses mpls for its internal stuff and has an lsr ce device, it would be very stupid if i as the provided would need to ask the customer to encapsulate their mpls packets into frame relay packets when they are send to other sites. -- juha From owner-mpls@UU.NET Sat Apr 21 06:17:08 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09065 for ; Sat, 21 Apr 2001 06:17:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklpb16747; Fri, 20 Apr 2001 16:47:28 GMT Received: by mail-control.mail.uu.net id QQklpb29917 for mpls-outgoing; Fri, 20 Apr 2001 16:46:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklpb29903 for ; Fri, 20 Apr 2001 16:46:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklpb27014 for ; Fri, 20 Apr 2001 16:45:45 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklpb21284 for ; Fri, 20 Apr 2001 16:45:44 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00385; Fri, 20 Apr 2001 12:45:39 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04413; Fri, 20 Apr 2001 12:45:42 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 12:45:40 -0400 Message-ID: <73573B0D37AFD311A3A800204840ED03227290@dal-server-01.pit.comms.marconi.com> From: "Dekany, Steven" To: Ramesh Bhandari , "Dekany, Steven" Cc: Bora Akyol , mpls@UU.NET Subject: RE: LSP Failure Notification Date: Fri, 20 Apr 2001 12:45:39 -0400 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 Ramesh, See comments inline, Thanks again, Steven -----Original Message----- From: Ramesh Bhandari [mailto:bhandari1@lucent.com] Sent: Friday, April 20, 2001 11:24 AM To: Dekany, Steven Cc: Ramesh Bhandari; Bora Akyol; mpls@UU.NET Subject: Re: LSP Failure Notification Steve, Normally, if the customers's traffic is so critical, then one would (to meet the SLA) assign a separate (or at least shared) backup path for this particluar LSP. If the network is properly designed and used, the situation where no backup LSP is available, when the primary LSP fails, should not arise. * The question is, what do I do if it still does? Example: My backup LSP is running over a diverse fiber route but without me knowing about it, the two fibers may still share the same sheath. Construction, backhoe error etc., I am leasing dark fiber. So now I am stuck. There may still be an IP hop by hp route available via Timbuktu though... * I guess I am interested to find out if there is any "standard" error signaling used somehow back to the source, either recommended by any of the standards or implemented as a matter of practice by a SP, in case my LSP tunnel is hopelessly lost and I still have IP traffic coming in to my ingress LER. * I am not sure if Giles' comment applies to ATM LSR's only. What does BGP have to do with the original question? Are you suggesting to use BGP in case of LSP failures? I know, that may be a backup safety net for some SP's running VPN's, but I am not running VPN's in this particular situation, this is only a "straight" or - crooked - LSP. BTW, for the record, Marconi does have BGP ... In the event a new service request comes in and a backup cannot be found (and reserved) due to bandwidth exhaustion or for whatever reason, then the request (with protection LSP) should be denied. If the customer agrees to an unprotected LSP servce, then depending upon the SLA, "best effort" service in the event of a node/link failure could be provided. If the unprotected LSP service cannot be provided also, then the request for this service is also denied, and depending upon the SLA only "best effort" service may be provided. Ramesh "Dekany, Steven" wrote: > > Hi Ramesh, > > Yes, I have. The assumption that I made in my first email is, that I have > exhausted all back-up and LSP re-route options, at least temporarily. At the > moment there is no LSP available. What do SP's most often do in this case > with the incoming IP traffic? Signal back to source with Dest Unreachable? > Silently drop until a new LSP finally comes up? Light a red lamp in the NOC > signaling a NW outage or link failure? > > Best Regards, > > Steven > > -----Original Message----- > From: Ramesh Bhandari [mailto:bhandari1@lucent.com] > Sent: Friday, April 20, 2001 10:00 AM > To: Dekany, Steven > Cc: Bora Akyol; mpls@UU.NET > Subject: Re: LSP Failure Notification > > Steven, > > Have you considered phyiscally-disjoint pair of LSP's in the solution, > with one LSP as a backup so that if the primary path fails the affected > traffic can flow on the backup? > > Ramesh > > "Dekany, Steven" wrote: > > > > Thank you Bora; > > > > and thank you Haoxin and Giles. > > > > Yes, best effort is kind of the expected "default" behavior. I just wonder > > that when we say that the IGP route will become the "next best route" what > > happens to my SLA with the customer - assuming that there is one in place? > I > > guess the underlying assumption is that I use MPLS in the core because I > > want to give something better than best effort service to my customer. Now > > that my LSP is broken and that I cannot setup another one - at least for > > while, in theory - if I use best effort only, I have basically violated my > > service level agreement with my customer. Should I not notify him somehow? > > Or this REALLY VERY IMPLEMENTATION SPECIFIC - read, either private > > information, or policy dependent? > > > > Another theoretical question - how significant is usually the time delay > > between IGP's convergence and by the time RSVP-TE has found a new LSP? If > > that is a relatively short time, I may not care, but if it takes a few > tens > > of seconds or minutes, and I have a relatively high speed link to the LER, > > it may flood my network with unwanted IP traffic real badly too, causing > > another cascading TE problem for me potentially in the core. > > > > Along the same line, if I have certain traffic parameter requirements for > my > > LSP - as required by my SLA - it is entirely possible that RSVP-TE may not > > find a suitable LSP and comes back with PathErr. Do I still fall back to > > forward best effort? > > > > I wonder if there is any practical experience with this question, or IP > best > > effort is the generally implemented default. > > > > Thank you again to all again, who kindly responded, > > > > Best Regards, > > > > Steven > > > > > > -----Original Message----- > > From: Bora Akyol [mailto:akyol@pluris.com] > > Sent: Friday, April 20, 2001 9:00 AM > > To: Dekany, Steven > > Cc: mpls@UU.NET > > Subject: Re: LSP Failure Notification > > > > The tunnels are established using IGP reachability information. When the > > tunnel goes away, IGP route will become the next best route and traffic > > will be traveling via IP. > > > > This may take a while, but until the head end realizes that the tunnel is > > down, there really is not much you can do. The packets will fall on the > > ground. > > > > I believe G-MPLS defines a failure notification mechanism. > > > > Bora > > > > On Fri, 20 Apr 2001, Dekany, Steven wrote: > > > > > Greetings; > > > > > > I am looking for help, with the following: > > > > > > Assume I have an MPLS Service Provider network, running RSVP-TE as a > > > signaling protocol. Customer sites are connected to my network via > various > > > IP only links - no MPLS. Upon a LSP link failure in my core - assume > > that > > > I have exhausted all back-up, re-route etc., options and my LSP tunnel > is > > > still down - what happens to my incoming IP traffic at the ingress LER? > Is > > > there an ICMP message generated back to IP Source with "Destination > > > Unreachable? , or an SNMP Trap, or both? Or something else? > > > > > > (Or is this a dumb question, because I have not read the relevant > > draft...) > > > > > > Any help or pointers would be greatly appreciated. > > > > > > Thanks in advance, > > > > > > > > > Steven > > > From owner-mpls@UU.NET Sat Apr 21 09:10:09 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10030 for ; Sat, 21 Apr 2001 09:10:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklse25820; Sat, 21 Apr 2001 13:10:07 GMT Received: by mail-control.mail.uu.net id QQklse20660 for mpls-outgoing; Sat, 21 Apr 2001 13:09:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklse20652 for ; Sat, 21 Apr 2001 13:09:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklse02549 for ; Sat, 21 Apr 2001 13:08:13 GMT Received: from cad.zju.edu.cn by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [210.32.131.2]) id QQklse25229 for ; Sat, 21 Apr 2001 13:08:08 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 412; Sat, 21 Apr 2001 17:02:37 +0800 Message-ID: <3AE14C64.93B7A4C9@cad.zju.edu.cn> Date: Sat, 21 Apr 2001 17:01:24 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jorge ochoa CC: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: ABOUT PNNI AND RSVP OR CR REDISTRIBUTION. References: <3AD8E00A.5CF37A3F@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I think this is not the subject for now, because , as those has been stated before in this list, RSVP-TE / CR-LDP has not get the exact same ability as PNNI. I means there is not a exact QoS mechanism defined in RSVP-TE or CR-LDP. We can not guarantee the conversion between two signalling procedure can keep to each other sematically. regards Jing Shen > Is there any plan to acomplish the redistribution between PNNI and > mpls RSVP and/ or CR in the interoperability between SVC and/or SPVC and > dinamic LDP. > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Sat Apr 21 21:39:25 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14084 for ; Sat, 21 Apr 2001 21:39:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkluc14845; Sun, 22 Apr 2001 01:39:25 GMT Received: by mail-control.mail.uu.net id QQkluc18764 for mpls-outgoing; Sun, 22 Apr 2001 01:38:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkluc18743 for ; Sun, 22 Apr 2001 01:38:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkluc01999 for ; Sun, 22 Apr 2001 01:38:12 GMT Received: from web13101.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13101.mail.yahoo.com [216.136.174.146]) id QQkluc20330 for ; Sun, 22 Apr 2001 01:38:11 GMT Message-ID: <20010422013811.56501.qmail@web13101.mail.yahoo.com> Received: from [38.186.47.9] by web13101.mail.yahoo.com; Sat, 21 Apr 2001 18:38:11 PDT Date: Sat, 21 Apr 2001 18:38:11 -0700 (PDT) From: Elwin Eliazer Subject: VRF and overlapping addresses ... To: mpls@UU.NET, ppvpn@zephion.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, The 2547bis states that, when a site is in multiple VPNs, the VRF associated with that site contains routes from the full set of VPNs of which the site is a member. Thus a VRF has an associated group of VPNs. Though the VRF holds VPN-IPv4 addresses, the data-path address-match can only be done with plain-IPv4 address, and hence these VPNs in the VPN group, have to be in the same IP address space (or should not have overlapping IP subnet/addresses). However, section 1.4 in 2547bis-02 confuses me. It states that, so long as the overlapping part of the address space does not belong to any of the sites which the two VPNs have in common, it should not be ambiguous. Take for example: VPN-1 = site1, site2, site3 VPN-2 = site1, site4 Let's assume site2 and site4 have overlapping addresses. When a packet destined for a host in site4 originates from site1, is looked up in PE, how is the VRF able to choose between site2 and site4? Am i missing something here? Thanks, Elwin. ===== ------- Elwin Stelzer Eliazer Corona Networks San Jose, CA 408-519-3832 ------- __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mpls@UU.NET Sat Apr 21 22:04:27 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14151 for ; Sat, 21 Apr 2001 22:04:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklue15376; Sun, 22 Apr 2001 02:04:22 GMT Received: by mail-control.mail.uu.net id QQklue00516 for mpls-outgoing; Sun, 22 Apr 2001 02:03:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklue00008 for ; Sun, 22 Apr 2001 02:03:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklue15602 for ; Sun, 22 Apr 2001 02:03:29 GMT Received: from zcars0m9. by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQklue25997 for ; Sun, 22 Apr 2001 02:03:29 GMT Received: from zcars04e.nortelnetworks.com by zcars0m9. (SMI-8.6/SMI-SVR4) id WAA11652; Sat, 21 Apr 2001 22:03:27 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Sat, 21 Apr 2001 22:03:27 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 21 Apr 2001 22:03:29 -0400 Message-ID: <03E3E0690542D211A1490000F80836F4051EBDA1@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'anilg'" , mpls Subject: RE: Two signalling protocols (LDP & RSVP) Date: Sat, 21 Apr 2001 22:03:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CAD0.6B76CCD0" 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_01C0CAD0.6B76CCD0 Content-Type: text/plain Yes & Yes. Peter Ashwood-Smith -----Original Message----- From: Anil Gunturu [SMTP:anilg@acc.com] Sent: Friday, April 20, 2001 2:12 PM To: mpls Subject: Two signalling protocols (LDP & RSVP) Hi, Is it possible to run both LDP and RSVP on the same interface? If it is possible can they be using the same label space? -Anil ------_=_NextPart_001_01C0CAD0.6B76CCD0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Two signalling protocols (LDP & RSVP)

Yes & Yes.

Peter Ashwood-Smith

    -----Original = Message-----
    From:   Anil Gunturu = [SMTP:anilg@acc.com]
    Sent:   Friday, April 20, 2001 2:12 PM
    To:     mpls
    Subject:       = Two signalling protocols (LDP & = RSVP)

    Hi,
    Is it possible to run both LDP and = RSVP on the same interface? If it is
    possible can they be using the same = label space?
    -Anil

------_=_NextPart_001_01C0CAD0.6B76CCD0-- From owner-mpls@UU.NET Sun Apr 22 02:55:38 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29870 for ; Sun, 22 Apr 2001 02:55:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklux05503; Sun, 22 Apr 2001 06:55:31 GMT Received: by mail-control.mail.uu.net id QQklux11115 for mpls-outgoing; Sun, 22 Apr 2001 06:55:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklux11020 for ; Sun, 22 Apr 2001 06:54:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklux17696 for ; Sun, 22 Apr 2001 06:54:13 GMT Received: from mail.marhold.at by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.marhold.at [194.152.126.85]) id QQklux03741 for ; Sun, 22 Apr 2001 06:54:11 GMT Received: from AMARHOLD ([192.168.1.34]) by mail.marhold.at (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id at; Sun, 22 Apr 2001 09:04:11 +0200 From: "Alexander Marhold" To: "Elwin Eliazer" , , Cc: Subject: RE: VRF and overlapping addresses ... Date: Sun, 22 Apr 2001 08:54:30 +0200 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010422013811.56501.qmail@web13101.mail.yahoo.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Elwin wrote: >However, section 1.4 in 2547bis-02 confuses me. It >states that, so long as the overlapping part of the >address space does not belong to any of the sites >which the two VPNs have in common, it should not be >ambiguous. > >Take for example: > >VPN-1 = site1, site2, site3 >VPN-2 = site1, site4 > >Let's assume site2 and site4 have overlapping >addresses. When a packet destined for a host in site4 >originates from site1, is looked up in PE, how is the >VRF able to choose between site2 and site4? > >Am i missing something here? YES and NO, but it is not easy to detect the simple answer is, that you must decide which addresses you will allow to enter site1 vrf, so for the overlapping addresses you should decide to either not import them on site1 at all, or only from site2 and NOT from site 4 or vice versa. Excerpt from DRAFT: If two VPNs have no sites in common, then they may have overlapping address spaces. That is, a given address might be used in VPN V1 as the address of system S1, but in VPN V2 as the address of a completely different system S2. This is a common situation when the VPNs each use an RFC1918 private address space. (In fact, two VPNs which do have sites in common may have overlapping address spaces, as long as the overlapping part of the address space does not belong to any of the sites which the two VPNs have in common.) Seeing your point I would suggest to rephrase it that way: In fact, two VPNs which do have sites in common may have overlapping address spaces, as long as the overlapping part of the address space does not belong to any of the sites which the two VPNs have in common ... ...and those overlapping addresses are not forwarded to shared sites from more than one VPN.) From owner-mpls@UU.NET Sun Apr 22 11:51:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10902 for ; Sun, 22 Apr 2001 11:51:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkloy09737; Fri, 20 Apr 2001 16:12:12 GMT Received: by mail-control.mail.uu.net id QQkloy25325 for mpls-outgoing; Fri, 20 Apr 2001 16:11:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkloy25301 for ; Fri, 20 Apr 2001 16:11:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkloy26007 for ; Fri, 20 Apr 2001 16:11:23 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkloy29976 for ; Fri, 20 Apr 2001 16:11:22 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA10669 for mpls@uu.net; Fri, 20 Apr 2001 12:11:22 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkloy25172 for ; Fri, 20 Apr 2001 16:10:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkloy09496 for ; Fri, 20 Apr 2001 16:10:06 GMT Received: from netmail2.alcatel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkloy27987 for ; Fri, 20 Apr 2001 16:10:05 GMT Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA08688 for ; Fri, 20 Apr 2001 11:10:05 -0500 (CDT) Received: from usa.alcatel.com ([198.205.41.31]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA2642 for ; Fri, 20 Apr 2001 12:23:21 -0400 Message-ID: <3AE05FCD.70748832@usa.alcatel.com> Date: Fri, 20 Apr 2001 12:11:58 -0400 From: Yuan Gu Organization: Alcatel USA X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls Subject: Re: LSP ID References: <3ADF47FF.23FEE4C@usa.alcatel.com> <3ADF77AF.C55FE2B8@marconi.com> Content-Type: multipart/alternative; boundary="------------0FD32A3C086ADCE510B5D01B" Sender: owner-mpls@UU.NET Precedence: bulk --------------0FD32A3C086ADCE510B5D01B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, David: Thanks for your answer. Please see my reply in line: David Charlap wrote: > Yuan Gu wrote: > > > > I have some questions about LSP ID of rsvp-tunnel comparing the one > > defined in cr-ldp: > > > > In draft-ietf-mpls-cr-ldp-05.txt section 4.5 LSP ID TLV: > > > > "LSPID is a unique identifier of a CR-LSP within an MPLS network. > > The LSPID is composed of the ingress LSR Router ID (or any of its own > > Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR." > > > > It's very clear. I have no doubt. > > > > But In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt section: 4.6.2.1: > > > > "LSP ID > > > > A 16-bit identifier used in the SENDER_TEMPLATE and the > > FILTER_SPEC that can be changed to allow a sender to share > > resources with itself." > > > > My question are: > > Is this LSP ID Locally unique? > > Yes. It is only meaningful when used in conjunction with the rest of > the SENDER_TEMPLATE or FILTER_SPEC object. Since the only other field > in the LSP-CType of these objects is the sender IP address, you may > safely think of the SENDER_TEMPLATE/FITER_SPEC objects as functionally > identical to the CR-LDP LSPDI. CR-LDP LSPID is Locally unique to that LSR(please see the definition above). That means LSPID in RSVP-TE is unique within same node i.s.o same session. Do you agree? > > > > What's mean of "it can be changed to allow a sender to share > > resources with itself"? > > In RSVP, two LSPs that belong to the same tunnel (which is defined by > the tunnel-endpoint/tunnel-ID/extended-tunnel-ID triple) will share > resources if SE-style reservations are used. > > A single sender can signal two LSPs in the same session by using > identical SESSION objects but different LSPID values in the > SENDER_TEMPLATE/FILTER_SPEC objects. If the egress router uses SE > style, these two LSPs will share resources wherever possible. > > > In RSVP-LSP-tunnel, how can we unique identify a LSP within an MPLS > > network? Is it enough to use "LSP ID + sender node address" to > > identify it? Is there any specification about it? > > The combination of SESSION object and SENDER_TEMPLATE uniquely > identifies a single LSP in Path messages. The combination of SESSION > object and FILTER_SPEC uniquely identifies a single LSP in Resv > messages. > > In both cases, this is a 5-tuple consisting of tunnel-endpoint address, > tunnel-ID, extended tunnel-ID, sender address, and LSP ID. > > -- David --------------0FD32A3C086ADCE510B5D01B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, David:

Thanks for your answer.

Please see my reply in line:

David Charlap wrote:

Yuan Gu wrote:
>
> I have some questions about LSP ID of  rsvp-tunnel comparing the one
> defined in cr-ldp:
>
> In draft-ietf-mpls-cr-ldp-05.txt  section 4.5 LSP ID TLV:
>
> "LSPID is a unique identifier of a CR-LSP within an MPLS network.
> The LSPID is composed of the ingress LSR Router ID (or any of its own
> Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR."
>
> It's very clear. I have no doubt.
>
> But In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt section: 4.6.2.1:
>
> "LSP ID
>
>          A 16-bit identifier used in the SENDER_TEMPLATE and the
>          FILTER_SPEC that can be changed to allow a sender to share
>          resources with itself."
>
> My question are:
> Is this LSP ID Locally unique?

Yes.  It is only meaningful when used in conjunction with the rest of
the SENDER_TEMPLATE or FILTER_SPEC object.  Since the only other field
in the LSP-CType of these objects is the sender IP address, you may
safely think of the SENDER_TEMPLATE/FITER_SPEC objects as functionally
identical to the CR-LDP LSPDI.

CR-LDP LSPID is Locally unique to that LSR(please see the definition above).
That means LSPID in RSVP-TE is unique within same node i.s.o same session.
Do you agree?
 

> What's mean of "it can be changed to allow a sender to share
> resources with itself"?

In RSVP, two LSPs that belong to the same tunnel (which is defined by
the tunnel-endpoint/tunnel-ID/extended-tunnel-ID triple) will share
resources if SE-style reservations are used.

A single sender can signal two LSPs in the same session by using
identical SESSION objects but different LSPID values in the
SENDER_TEMPLATE/FILTER_SPEC objects.  If the egress router uses SE
style, these two LSPs will share resources wherever possible.

> In RSVP-LSP-tunnel, how can we unique identify a LSP within an MPLS
> network? Is it enough to use "LSP ID + sender node address" to
> identify it? Is there any specification about it?

The combination of SESSION object and SENDER_TEMPLATE uniquely
identifies a single LSP in Path messages.  The combination of SESSION
object and FILTER_SPEC uniquely identifies a single LSP in Resv
messages.

In both cases, this is a 5-tuple consisting of tunnel-endpoint address,
tunnel-ID, extended tunnel-ID, sender address, and LSP ID.

-- David

--------------0FD32A3C086ADCE510B5D01B-- From owner-mpls@UU.NET Sun Apr 22 21:02:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14493 for ; Sun, 22 Apr 2001 21:02:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklxs07627; Mon, 23 Apr 2001 01:02:27 GMT Received: by mail-control.mail.uu.net id QQklxs26410 for mpls-outgoing; Mon, 23 Apr 2001 01:01:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklxs26328 for ; Mon, 23 Apr 2001 01:01:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklxs27511 for ; Mon, 23 Apr 2001 01:00:42 GMT Received: from baynet.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20]) id QQklxs05129 for ; Mon, 23 Apr 2001 01:00:41 GMT Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id RAA17876 for ; Sun, 22 Apr 2001 17:58:49 -0700 (PDT) Received: from shasta-exch.shastanets.com (mailserver.shastanets.com [47.82.16.150]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id RAA20978 for ; Sun, 22 Apr 2001 17:58:44 -0700 (PDT) Received: by mailserver.shastanets.com with Internet Mail Service (5.5.2650.21) id ; Sun, 22 Apr 2001 18:00:00 -0700 Message-ID: <940E42DB5D7FD4119C420004ACE6E0A09D7AF1@mailserver.shastanets.com> From: Suresh Boddapati To: "'mpls@uu.net'" Subject: Implicit NULL label/Penultimate hop popping and LDP Date: Sun, 22 Apr 2001 17:59:58 -0700 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, Section 4.1.5 of "MPLS Architecture" states "However, if the penultimate LSR is an ATM switch, it may not have the capability to pop the label stack. Hence a binding of Implicit NULL may be distributed only to LSRs which can support that function". Elsewhere in section 3.16 it states, "Initial label distribution protocol negotiations MUST allow each LSR to determine whether its neighboring LSRs are capable of popping the label stack. A LSR MUST NOT request a label distribution peer to pop the label stack unless it is capable of doing so". But the LDP specification does not have anything in the initialization procedures in order to determine if a neighboring LSR supports penultimate hop popping or not. Am I missing something? Thanks in advance. Regards, Suresh From owner-mpls@UU.NET Sun Apr 22 22:48:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16778 for ; Sun, 22 Apr 2001 22:48:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklxz12956; Mon, 23 Apr 2001 02:48:10 GMT Received: by mail-control.mail.uu.net id QQklxz03615 for mpls-outgoing; Mon, 23 Apr 2001 02:47:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklxz03606 for ; Mon, 23 Apr 2001 02:47:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklxz02436 for ; Mon, 23 Apr 2001 02:47:07 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklxz00488 for ; Mon, 23 Apr 2001 02:47:07 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA18873 for mpls@uu.net; Sun, 22 Apr 2001 22:47:06 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklxy03068 for ; Mon, 23 Apr 2001 02:42:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklxy20679 for ; Mon, 23 Apr 2001 02:42:01 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQklxy25880 for ; Mon, 23 Apr 2001 02:42:01 GMT Received: from ASIMHA-LAPTOP (rtp-vpn-175.cisco.com [10.82.192.175]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA20007; Sun, 22 Apr 2001 22:37:58 -0400 (EDT) Date: Sun, 22 Apr 2001 22:41:41 -0400 (Eastern Daylight Time) From: Ajay Simha To: Suresh Boddapati cc: "'mpls@uu.net'" Subject: Re: Implicit NULL label/Penultimate hop popping and LDP In-Reply-To: <940E42DB5D7FD4119C420004ACE6E0A09D7AF1@mailserver.shastanets.com> Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Sun, 22 Apr 2001, Suresh Boddapati wrote: > Hi, > Section 4.1.5 of "MPLS Architecture" states > "However, if the penultimate LSR is an ATM switch, it may not have > the capability to pop the label stack. Hence a binding of Implicit NULL may > be distributed only to LSRs which can support that function". > > Elsewhere in section 3.16 it states, > "Initial label distribution protocol negotiations MUST allow each > LSR to determine whether its neighboring LSRs are capable of popping the > label stack. A LSR MUST NOT request a label distribution peer to pop the > label stack unless it is capable of doing so". > > But the LDP specification does not have anything in the > initialization procedures in order to determine if a neighboring LSR > supports penultimate hop popping or not. Am I missing something? Thanks in > advance. From RFC 3036: 6. Areas for Future Study The following topics not addressed in this version of LDP are possible areas for future study: - Section 2.16 of the MPLS architecture [RFC3031] requires that the initial label distribution protocol negotiation between peer LSRs enable each LSR to determine whether its peer is capable of popping the label stack. This version of LDP assumes that LSRs support label popping for all link types except ATM and Frame Relay. A future version may specify means to make this determination part of the session initiation negotiation. -ajay > > Regards, > > Suresh > -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Mon Apr 23 00:32:24 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18026 for ; Mon, 23 Apr 2001 00:32:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklyg07205; Mon, 23 Apr 2001 04:32:18 GMT Received: by mail-control.mail.uu.net id QQklyg16956 for mpls-outgoing; Mon, 23 Apr 2001 04:31:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklyg16939 for ; Mon, 23 Apr 2001 04:31:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklyg16853 for ; Mon, 23 Apr 2001 04:31:39 GMT Received: from samar.sasken.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQklyg27970 for ; Mon, 23 Apr 2001 04:31:35 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f3N4VMb19165 for ; Mon, 23 Apr 2001 10:01:23 +0530 (IST) Received: from localhost (soumen@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id KAA07925 for ; Mon, 23 Apr 2001 10:01:17 +0530 (IST) Date: Mon, 23 Apr 2001 10:01:17 +0530 (IST) From: Soumen Sarkar X-Sender: cc: Subject: Re: Two signalling protocols (LDP & RSVP) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 20 Apr 2001, Anil Gunturu wrote: > > Hi, > Is it possible to run both LDP and RSVP on the same interface? If it is > possible can they be using the same label space? > -Anil > I didn't understand this. I thought standard LDP does not use LSP. Where is label space coming into picture for LDP to use ? From owner-mpls@UU.NET Mon Apr 23 01:17:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19395 for ; Mon, 23 Apr 2001 01:17:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklyj29431; Mon, 23 Apr 2001 05:17:43 GMT Received: by mail-control.mail.uu.net id QQklyj08081 for mpls-outgoing; Mon, 23 Apr 2001 05:17:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklyj08073 for ; Mon, 23 Apr 2001 05:16:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklyj16435 for ; Mon, 23 Apr 2001 05:16:15 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklyj15843 for ; Mon, 23 Apr 2001 05:16:15 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id BAA25543 for mpls@uu.net; Mon, 23 Apr 2001 01:16:14 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklyj08004 for ; Mon, 23 Apr 2001 05:15:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklyi25750 for ; Mon, 23 Apr 2001 05:14:52 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQklyi25615 for ; Mon, 23 Apr 2001 05:14:52 GMT Received: from ASIMHA-LAPTOP (rtp-vpn-175.cisco.com [10.82.192.175]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id BAA23448; Mon, 23 Apr 2001 01:11:07 -0400 (EDT) Date: Mon, 23 Apr 2001 01:14:50 -0400 (Eastern Daylight Time) From: Ajay Simha To: Soumen Sarkar cc: Subject: Re: Two signalling protocols (LDP & RSVP) In-Reply-To: Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 23 Apr 2001, Soumen Sarkar wrote: > On Fri, 20 Apr 2001, Anil Gunturu wrote: > > > > > > Hi, > > Is it possible to run both LDP and RSVP on the same interface? If it is > > possible can they be using the same label space? > > -Anil > > > > I didn't understand this. I thought standard LDP does not use LSP. Where is > label space coming into picture for LDP to use ? Both LDP and RSVP *are* Label Distribution Protocols. They both would be responsible for assigning a label to a FEC and distributing it to their neighbors. If they are both running on the same LSR. They could be coming from either the same Label Space OR different Label Spaces. The answer to this like someone pointed out is "yes" and "yes". -ajay -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Mon Apr 23 03:02:53 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02235 for ; Mon, 23 Apr 2001 03:02:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklyq27495; Mon, 23 Apr 2001 07:02:49 GMT Received: by mail-control.mail.uu.net id QQklyq12934 for mpls-outgoing; Mon, 23 Apr 2001 07:02:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklyq12527 for ; Mon, 23 Apr 2001 07:02:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklyq12481 for ; Mon, 23 Apr 2001 07:01:59 GMT Received: from galileo5.galileo.co.il by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pop3.galileo.co.il [199.203.130.130]) id QQklyq26388 for ; Mon, 23 Apr 2001 07:01:58 GMT Received: from galileo.co.il ([10.2.20.187]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id KAA05216 for ; Mon, 23 Apr 2001 10:02:00 +0200 (GMT-2) Message-ID: <3AE3E29B.5EECEF36@galileo.co.il> Date: Mon, 23 Apr 2001 10:06:51 +0200 From: Lior Keren X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: NHLFE structure Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, draft-ietf-mpls-lsr-mib-07 describes NHLFE as three separated entries: MplsInSegmentEntry, MplsOutSegmentEntry and MplsXCEntry. Both MplsInSegmentEntry and MplsOutSegmentEntry are pointing to MplsXCEntry. I assume this structure is needed in order to support point-to-point, point-to-multipoint and multipoint-to-point connections at an LSR. Does supporting point-to-multipoint mean MPLS-multicasting ? Is this structure of NHLFE needed to support mpls-multicasting (as describes in draft-ietf-mpls-multicast-05) ? What about LSR's that have no support for mpls-multicasting, handling such a structure for NHLFE might be useless and inefficient ? Regards, Lior. From owner-mpls@UU.NET Mon Apr 23 03:37:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02397 for ; Mon, 23 Apr 2001 03:37:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklys08653; Mon, 23 Apr 2001 07:37:33 GMT Received: by mail-control.mail.uu.net id QQklys23667 for mpls-outgoing; Mon, 23 Apr 2001 07:37:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklys23656 for ; Mon, 23 Apr 2001 07:36:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklys19278 for ; Mon, 23 Apr 2001 07:34:38 GMT Received: from penguin-ext.wise.edt.ericsson.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: penguin-ext.wise.edt.ericsson.se [194.237.142.110]) id QQklys01155 for ; Mon, 23 Apr 2001 07:34:37 GMT Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3N7YaO13735 for ; Mon, 23 Apr 2001 09:34:36 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Apr 23 09:34:36 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Apr 2001 09:34:35 +0200 Message-ID: From: "Gabor Korossy (ETH)" To: "'Soumen Sarkar'" Cc: "'mpls@UU.NET'" Subject: RE: Two signalling protocols (LDP & RSVP) Date: Mon, 23 Apr 2001 09:34:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, in Tag Switching, there is no concept of LSP. You were probably mixing standard LDP with proprietory TDP (Tag Distribution Protocol). Check out the "LDP Specification": ..."The Label Distribution Protocol (LDP) defined in this document is a new protocol defined for distributing labels. It is the set of procedures and messages by which Label Switched Routers (LSRs) establish Label Switched Paths (LSPs) through a network by mapping network-layer routing information directly to data-link layer switched paths..." /Gabor -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Soumen Sarkar Sent: Monday, April 23, 2001 6:31 AM Cc: mpls@UU.NET Subject: Re: Two signalling protocols (LDP & RSVP) On Fri, 20 Apr 2001, Anil Gunturu wrote: > > Hi, > Is it possible to run both LDP and RSVP on the same interface? If it is > possible can they be using the same label space? > -Anil > I didn't understand this. I thought standard LDP does not use LSP. Where is label space coming into picture for LDP to use ? From owner-mpls@UU.NET Mon Apr 23 04:21:07 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02594 for ; Mon, 23 Apr 2001 04:21:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklyv16043; Mon, 23 Apr 2001 08:20:59 GMT Received: by mail-control.mail.uu.net id QQklyv15008 for mpls-outgoing; Mon, 23 Apr 2001 08:20:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklyv15003 for ; Mon, 23 Apr 2001 08:20:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklyv00504 for ; Mon, 23 Apr 2001 08:19:10 GMT Received: from sktelecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQklyv09932 for ; Mon, 23 Apr 2001 08:19:09 GMT Received: from mrchang (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f3N8MnM10647 for ; Mon, 23 Apr 2001 17:22:50 +0900 (KST) Message-ID: <001b01c0cbcd$cbfa8120$77131796@sktelecom.com> From: "Rae M. Chang" To: Subject: Routing with Preemption Date: Mon, 23 Apr 2001 17:17:10 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C0CC19.3B21E660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C0CC19.3B21E660 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkhhdmUgeW91IGtub3duIHRvIGFueSBwYXBlcnMgb3IgcG9pbnRlcnMgdG8gdGhl IHJvdXRpbmcgYWxnb3JpdGhtcyANCndpdGggInJvdXRlLXByZWVtcHRpb24iIGFsbG93ZWQ/IFRo ZSBuZXR3b3JrIGRvbWFpbiBtaWdodCBiZSBlaXRoZXIgTVBMUyBvciBBVE0uIA0KVGhhbmtzLg0K DQpSYWUNCg== ------=_NextPart_000_0018_01C0CC19.3B21E660 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPkhhdmUgeW91IGtub3duIHRvIGFueSBwYXBlcnMgb3IgcG9pbnRlcnMgdG8g dGhlIHJvdXRpbmcgDQphbGdvcml0aG1zIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PndpdGggInJvdXRlLXByZWVtcHRpb24iIGFsbG93ZWQ/IDwvRk9OVD48Rk9OVCBzaXplPTI+VGhl IA0KbmV0d29yayBkb21haW4mbmJzcDttaWdodCBiZSBlaXRoZXIgTVBMUyZuYnNwO29yIEFUTS4g PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlJh ZTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0018_01C0CC19.3B21E660-- From owner-mpls@UU.NET Mon Apr 23 07:06:36 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03363 for ; Mon, 23 Apr 2001 07:06:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzg27864; Mon, 23 Apr 2001 11:06:33 GMT Received: by mail-control.mail.uu.net id QQklzg20142 for mpls-outgoing; Mon, 23 Apr 2001 11:06:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklzg20112 for ; Mon, 23 Apr 2001 11:05:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklzg16990 for ; Mon, 23 Apr 2001 11:05:36 GMT Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQklzg26846 for ; Mon, 23 Apr 2001 11:05:35 GMT Received: from utfors.se ([10.58.0.153]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GC8S8Z00.KTM; Mon, 23 Apr 2001 13:07:47 +0200 Message-ID: <3AE40C7C.C51FEB1A@utfors.se> Date: Mon, 23 Apr 2001 13:05:32 +0200 From: "Loa Andersson" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Sharma Prem" CC: "'Don Fedyk'" , manoj juneja , mpls@UU.NET Subject: Re: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQklzg27864 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA03363 All, some comments to this discussion. I agree with Perm, if the draft is only applicable to LSPs where every node is explicitly routed, that needs to be explicitly state early in the draft. Also know from some offsets communication that "the explicit routed only" approach is under some debate. Given that we can have LSPs where other constraints are important, I would be interested in combining dynamic routed CR-LSPs (routed on other constraints than explicit nodes), with one explicitly routed node, e.g. for performance measurements. I would also be interested to be able to make those measurements at different places, a reason for changing (modifying) the LSP, drop one explicitly routed node and replace with another. I'm not concerned over have the loosely routed part of an LSP staying alive of the strictly routed part goes away :-), but given that I can retry if the a node in the loosely routed part of the LSP NAK a request, but not if an explicitly routed node does it. Need to distinguish between cases. Of course this is not a problem if explicit routed only. It is not only CR-LDP that sets up CR-LSPs, it is much more common to do so by RSVP-TE, hence my reflection on the need to something for RSVP-TE. /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Mon Apr 23 07:22:43 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03442 for ; Mon, 23 Apr 2001 07:22:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzh14102; Mon, 23 Apr 2001 11:22:42 GMT Received: by mail-control.mail.uu.net id QQklzh21817 for mpls-outgoing; Mon, 23 Apr 2001 11:22:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklzh21801 for ; Mon, 23 Apr 2001 11:21:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklzh08477 for ; Mon, 23 Apr 2001 11:21:44 GMT Received: from ntexgswp02.DMZ by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.kpnqwest.com [193.242.92.8]) id QQklzh20148 for ; Mon, 23 Apr 2001 11:21:43 GMT Received: from ntexghub01.kpnqwest.com (unverified) by ntexgswp02.DMZ (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 23 Apr 2001 13:25:35 +0200 Received: by ntexghub01 with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Apr 2001 13:17:36 +0200 Message-ID: <3F3B952383E8D311A9FC0008C7E61402027A0605@ntexgdhg02> From: "Metz, Eduard" To: dhg@juniper.net, pingpan@juniper.net, arthi@juniper.net, kireeti@juniper.net Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: draft-gan-fast-reroute-00.txt Date: Mon, 23 Apr 2001 13:20:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi all, some questions on draft-gan-fast-reroute: The FAST-REROUTE object includes several parameters for the detour LSP, such as bandwidth, and include/exclude colors. Are these completely independent of those for the primary LSP? Or are these supposed to have a relation? The DETOUR object includes Downstream Node ID, identifying the neighboring node to route around. This seems to work for all hops, except the penultimate. Here the detour only can protect the link, also shown in the picture in section 2. Should there be an exception for this case, or does the penultimate hop apply different logic when setting up the detour? cheers, Eduard From owner-mpls@UU.NET Mon Apr 23 07:27:13 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03456 for ; Mon, 23 Apr 2001 07:27:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzh18228; Mon, 23 Apr 2001 11:27:11 GMT Received: by mail-control.mail.uu.net id QQklzh22164 for mpls-outgoing; Mon, 23 Apr 2001 11:26:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklzh22157 for ; Mon, 23 Apr 2001 11:26:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklzh17627 for ; Mon, 23 Apr 2001 11:26:17 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklzh17637 for ; Mon, 23 Apr 2001 11:26:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA09113 for mpls@uu.net; Mon, 23 Apr 2001 07:26:17 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklzh21802 for ; Mon, 23 Apr 2001 11:21:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklzh08741 for ; Mon, 23 Apr 2001 11:21:49 GMT Received: from che-cse-115.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.140.33]) id QQklzh20260 for ; Mon, 23 Apr 2001 11:21:48 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id HAA23750; Mon, 23 Apr 2001 07:20:48 -0400 (EDT) Date: Mon, 23 Apr 2001 07:20:47 -0400 From: Eric Osborne To: "Gabor Korossy (ETH)" Cc: "'Soumen Sarkar'" , "'mpls@UU.NET'" Subject: Re: Two signalling protocols (LDP & RSVP) Message-ID: <20010423072047.A23742@che-cse-115.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Gabor.Korossy@eth.ericsson.se on Mon, Apr 23, 2001 at 09:34:30AM +0200 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Apr 23, 2001 at 09:34:30AM +0200, Gabor Korossy (ETH) wrote: > Hi, > in Tag Switching, there is no concept of LSP. > You were probably mixing standard LDP with proprietory TDP (Tag Distribution Protocol). > Yes, but in TDP there's a virtually identical thing called a TSP. As it turns out, TDP and LSP are very similar, thought not identical. In general, most of the major things that apply to LDP (like per-interface vs. per-platform label space, advertisement and retention modes, etc) also apply to TDP. eric > Check out the "LDP Specification": > ..."The Label Distribution Protocol (LDP) defined in this document is a > new protocol defined for distributing labels. It is the set of > procedures and messages by which Label Switched Routers (LSRs) > establish Label Switched Paths (LSPs) through a network by mapping > network-layer routing information directly to data-link layer > switched paths..." > > /Gabor > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Soumen > Sarkar > Sent: Monday, April 23, 2001 6:31 AM > Cc: mpls@UU.NET > Subject: Re: Two signalling protocols (LDP & RSVP) > > > On Fri, 20 Apr 2001, Anil Gunturu wrote: > > > > > > Hi, > > Is it possible to run both LDP and RSVP on the same interface? If it is > > possible can they be using the same label space? > > -Anil > > > > I didn't understand this. I thought standard LDP does not use LSP. Where is > label space coming into picture for LDP to use ? From owner-mpls@UU.NET Mon Apr 23 07:28:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03472 for ; Mon, 23 Apr 2001 07:28:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzh27751; Mon, 23 Apr 2001 11:28:43 GMT Received: by mail-control.mail.uu.net id QQklzh22243 for mpls-outgoing; Mon, 23 Apr 2001 11:28:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklzh22207 for ; Mon, 23 Apr 2001 11:27:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklzh03053 for ; Mon, 23 Apr 2001 11:27:26 GMT Received: from spomail01.br.attla.corp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.netstream.com.br [200.192.1.34]) id QQklzh26115 for ; Mon, 23 Apr 2001 11:27:25 GMT Received: from nsrjo4.attla.corp ([10.21.10.6]) by spomail01.br.attla.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10) id JLVK220X; Mon, 23 Apr 2001 08:29:10 -0300 Received: by nsrjo4 with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Apr 2001 08:26:44 -0300 Message-ID: From: "Loureiro, Rodrigo" To: "'Bharti Batra'" Cc: mpls@UU.NET Subject: RES: CLI for MPLS Date: Mon, 23 Apr 2001 08:26:35 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CBE8.4166EF10" 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_01C0CBE8.4166EF10 Content-Type: text/plain; charset="iso-8859-1" Hi Bharti, We are running 12.1(5)T6. Regards, -- Rodrigo Loureiro Systems Engineer - AT&T LA Tel: 55-11-3365-1670/9655-9676 ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- -------------------------------------The Art of Strategy: "Those who are victorious plan effectively and change decisively. They are like a great river that maintains its course but adjusts its flow... They have form but are formless. They are skilled in both planning and adapting and need not fear the result of a thousand battles; for they win in advance, defeating those that have already lost." - Sun Tzu, Chinese Warrior and Philosopher, 100 B.C. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ------------------------------------- -----Mensagem original----- De: Bharti Batra [mailto:bbatra@aplion.stpn.soft.net] Enviada em: sexta-feira, 20 de abril de 2001 10:08 Para: mpls@UU.NET Assunto: CLI for MPLS Hi ! What is the version of Cisco IOS for MPLS that is closest match to the configurable parameters defined in IETF's MIBs ? I am looking for CLI for Static and Signaled LSPs. Any pointers? Regds, Bharti ------_=_NextPart_001_01C0CBE8.4166EF10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Bharti,
 
We are=20 running 12.1(5)T6.
 
 
 
Regards,
--
 

Rodrigo Loureiro
Systems Engineer - AT&T LA
Tel:=20 55-11-3365-1670/9655-9676
---------------------------------------------------------------= ------------------------------------------------------------------------= ------------------------------------------------------The Art of Strategy: "Those who are victorious = plan=20 effectively and change decisively. They are like a great river that = maintains=20 its course but adjusts its flow... They have form but are formless. = They are=20 skilled in both planning and adapting and need not fear the result of a = thousand=20 battles; for they win in advance, defeating those that have already = lost." - Sun=20 Tzu, Chinese Warrior and Philosopher, 100 B.C.

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

 

 -----Mensagem=20 original-----
De: Bharti Batra=20 [mailto:bbatra@aplion.stpn.soft.net]
Enviada em: sexta-feira, = 20 de=20 abril de 2001 10:08
Para: mpls@UU.NET
Assunto: CLI = for=20 MPLS

Hi !
 
What is the version of Cisco IOS for MPLS that is = closest match=20 to the configurable parameters defined in IETF's MIBs ? I am looking = for CLI=20 for Static and Signaled LSPs. Any pointers?
 
Regds,
Bharti
 
 
------_=_NextPart_001_01C0CBE8.4166EF10-- From owner-mpls@UU.NET Mon Apr 23 08:06:55 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03758 for ; Mon, 23 Apr 2001 08:06:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzk08320; Mon, 23 Apr 2001 12:06:50 GMT Received: by mail-control.mail.uu.net id QQklzk10655 for mpls-outgoing; Mon, 23 Apr 2001 12:06:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklzk10598 for ; Mon, 23 Apr 2001 12:06:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklzk01848 for ; Mon, 23 Apr 2001 12:06:13 GMT Received: from malmo.trab.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQklzk27171 for ; Mon, 23 Apr 2001 12:06:12 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f3NC5uu10426; Mon, 23 Apr 2001 14:05:57 +0200 (MEST) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Mon, 23 Apr 2001 14:05:55 +0200 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D02254416@trab-hermes.haninge.trab.se> From: Nhat Thanh Hoang To: "'Metz, Eduard'" , dhg@juniper.net, pingpan@juniper.net, arthi@juniper.net, kireeti@juniper.net Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: draft-gan-fast-reroute-00.txt Date: Mon, 23 Apr 2001 14:05:54 +0200 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 See the comments in line Hi all, some questions on draft-gan-fast-reroute: The FAST-REROUTE object includes several parameters for the detour LSP, such as bandwidth, and include/exclude colors. Are these completely independent of those for the primary LSP? Or are these supposed to have a relation? - In the defaut mode, the detour LSPs inherit the constraints from the primary LSPs, but the network administrator can change the relation. If I'm not wrong. Cheers, Nhat Thanh Telia Research AB From owner-mpls@UU.NET Mon Apr 23 10:09:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04607 for ; Mon, 23 Apr 2001 10:09:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzs22851; Mon, 23 Apr 2001 14:09:38 GMT Received: by mail-control.mail.uu.net id QQklzs25213 for mpls-outgoing; Mon, 23 Apr 2001 14:09:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklzs25167 for ; Mon, 23 Apr 2001 14:08:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklzs14501 for ; Mon, 23 Apr 2001 14:06:16 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQklzs19762 for ; Mon, 23 Apr 2001 14:06:16 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15667 for ; Mon, 23 Apr 2001 10:06:13 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00171 for ; Mon, 23 Apr 2001 10:06:13 -0400 (EDT) Message-ID: <3AE436DB.91F9C595@marconi.com> Date: Mon, 23 Apr 2001 10:06:19 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Two signalling protocols (LDP & RSVP) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Soumen Sarkar wrote: > On Fri, 20 Apr 2001, Anil Gunturu wrote: >> >> Is it possible to run both LDP and RSVP on the same interface? If >> it is possible can they be using the same label space? > > I didn't understand this. I thought standard LDP does not use LSP. > Where is label space coming into picture for LDP to use ? LDP, RSVP-TE and CR-LDP all distribute labels. As such, if multiple protocols are enabled on a single interface, they must share label spaces - the data plane doesn't know which signaling protocol was used to create the LSPs for each packet, so they must remain synchronized. While LDP doesn't explicitly request the setup of LSPs, LSPs are established as a natural consequence of distributing labels from one side of the MPLS cloud to the other. -- David From owner-mpls@UU.NET Mon Apr 23 11:07:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05314 for ; Mon, 23 Apr 2001 11:07:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzw02064; Mon, 23 Apr 2001 15:06:58 GMT Received: by mail-control.mail.uu.net id QQklzw20050 for mpls-outgoing; Mon, 23 Apr 2001 15:06:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklzw19816 for ; Mon, 23 Apr 2001 15:06:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklzw11608 for ; Mon, 23 Apr 2001 15:05:32 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQklzw17312 for ; Mon, 23 Apr 2001 15:05:31 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3NF5Yu14712 for ; Mon, 23 Apr 2001 08:05:34 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA17682 for mpls@uu.net; Mon, 23 Apr 2001 11:05:29 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQklqj26428 for ; Sat, 21 Apr 2001 01:22:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklqj20488 for ; Sat, 21 Apr 2001 01:21:32 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f47.law8.hotmail.com [216.33.241.47]) id QQklqj13655 for ; Sat, 21 Apr 2001 01:21:32 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Apr 2001 18:21:32 -0700 Received: from 134.134.248.26 by lw8fd.law8.hotmail.msn.com with HTTP; Sat, 21 Apr 2001 01:21:31 GMT X-Originating-IP: [134.134.248.26] From: "Denon8000 !!!" To: mpls@UU.NET Subject: End of LSP Date: Sat, 21 Apr 2001 01:21:31 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Apr 2001 01:21:32.0062 (UTC) FILETIME=[65F3ABE0:01C0CA01] Sender: owner-mpls@UU.NET Precedence: bulk Hi, When a LSP is being setup by LDP, how does LDP running on the egress LSR determine that it is the egress for the LSP being setup so that it can send label binding back. Is there some configuration parameter which tell the LDP that it is running on the edge of the MPLS network. regards, Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Apr 23 11:20:33 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05452 for ; Mon, 23 Apr 2001 11:20:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzx19035; Mon, 23 Apr 2001 15:20:23 GMT Received: by mail-control.mail.uu.net id QQklzx00876 for mpls-outgoing; Mon, 23 Apr 2001 15:19:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklzx00858 for ; Mon, 23 Apr 2001 15:19:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklzx09742 for ; Mon, 23 Apr 2001 15:19:13 GMT From: Satish_Amara@3com.com Received: from topaz.3com.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: topaz.3com.com [192.156.136.158]) id QQklzx08139 for ; Mon, 23 Apr 2001 15:19:12 GMT Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3NFHXf11174; Mon, 23 Apr 2001 08:17:33 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f3NFJB725739; Mon, 23 Apr 2001 08:19:11 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A37.005425F6 ; Mon, 23 Apr 2001 08:19:07 -0700 X-Lotus-FromDomain: 3COM To: "Denon8000 !!!" cc: mpls@UU.NET Message-ID: <88256A37.00541CFB.00@hqoutbound.ops.3com.com> Date: Mon, 23 Apr 2001 10:17:18 -0500 Subject: Re: End of LSP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk An LSR may act as an egress LSR, with respect to a particular FEC, under any of the following conditions: 1. The FEC refers to the LSR itself (including one of its directly attached interfaces). 2. The next hop router for the FEC is outside of the Label Switching Network. 3. FEC elements are reachable by crossing a routing domain boundary, such as another area for OSPF summary networks, or another autonomous system for OSPF AS externals and BGP routes [RFC2328] [RFC1771]. Satish Amara "Denon8000 !!!" on 04/20/2001 08:21:31 PM Sent by: "Denon8000 !!!" To: mpls@UU.NET cc: (Satish Amara/MW/US/3Com) Subject: End of LSP Hi, When a LSP is being setup by LDP, how does LDP running on the egress LSR determine that it is the egress for the LSP being setup so that it can send label binding back. Is there some configuration parameter which tell the LDP that it is running on the edge of the MPLS network. regards, Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Apr 23 11:24:21 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05475 for ; Mon, 23 Apr 2001 11:24:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzx03797; Mon, 23 Apr 2001 15:24:17 GMT Received: by mail-control.mail.uu.net id QQklzx01716 for mpls-outgoing; Mon, 23 Apr 2001 15:23:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQklzx01661 for ; Mon, 23 Apr 2001 15:23:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklzx24222 for ; Mon, 23 Apr 2001 15:22:06 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQklzx01256 for ; Mon, 23 Apr 2001 15:22:06 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3NFM4u26390; Mon, 23 Apr 2001 08:22:04 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA17885; Mon, 23 Apr 2001 11:22:03 -0400 (EDT) Message-Id: <200104231522.LAA17885@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Juha Heinanen cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-reply-to: Your message of Sat, 21 Apr 2001 11:20:59 +0300. <15073.17131.642478.638474@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: Mon, 23 Apr 2001 11:22:03 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Eric> I think the IP header already contains a field which the user can set Eric> to signal diffserv support to the service provider. Or are you saying Eric> that it is important to be able to signal diffserv on a per-packet Eric> basis for non-IP packets? Juha> i as a service provider don't have any idea what packets my customer is Juha> carrying over the l2 circuits between their sites. it is beneficial for Juha> the customer if it can tell in the exp field how it wants the packets to Juha> be treated when they cross my network. What is the customer application for which the customer is likely to have a CE device that will mark individual non-IP packets with diffserv information? Eric> This suggests that the backbone should run MPLS, rather than Frame Eric> Relay, and I'd certainly agree with that, but I don't see why this is Eric> an issue vis. a vis. CE-CE LSPs. Of course, if two CEs want to send Eric> each other MPLS packets, they can send them over any data link Eric> whatsoever. Juha> if the customer uses mpls for its internal stuff and has an lsr ce Juha> device, it would be very stupid if i as the provided would need to ask Juha> the customer to encapsulate their mpls packets into frame relay Juha> packets when they are send to other sites. Not many customers use MPLS for their internal stuff. Do you foresee a significant migration of MPLS into the enterprise? Or are you thinking of other service providers as the customers. In any event, if two routers are connected by a serial link, MPLS packets between the routers get encapsulated into (most likely ) PPP packets. If two routers are connected by an ethernet link, MPLS packets between the routes get encapsulated into ethernet frames. If two routers are connected by a frame relay link, MPLS packets between the routers get encapsulated into frame relay frames. If two routers are connected by an ATM link, MPLS packets between the routers get encapsulated in AAL5 frames. In fact, it looks like in all the common cases, MPLS packets get encapsulated in a data link frame when being sent from one system to another. Are all these cases "very stupid"? If not, how do they differ from the case you are considering? From owner-mpls@UU.NET Mon Apr 23 11:48:57 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05937 for ; Mon, 23 Apr 2001 11:48:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzz01432; Mon, 23 Apr 2001 15:48:54 GMT Received: by mail-control.mail.uu.net id QQklzz05664 for mpls-outgoing; Mon, 23 Apr 2001 15:48:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklzz05655 for ; Mon, 23 Apr 2001 15:48:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQklzz16954 for ; Mon, 23 Apr 2001 15:47:57 GMT Received: from ext1.ics.forth.gr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.ics.forth.gr [139.91.1.2]) id QQklzz20100 for ; Mon, 23 Apr 2001 15:47:57 GMT Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51]) by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id SAA02718; Mon, 23 Apr 2001 18:47:56 +0300 (EET DST) Received: from sappho.ics.forth.gr (sappho-lane.ics.forth.gr [139.91.157.50]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id SAA14734; Mon, 23 Apr 2001 18:44:06 +0300 (EET DST) Posted-Date: Mon, 23 Apr 2001 18:44:06 +0300 (EET DST) Organization: Received: from localhost (tziou@localhost) by sappho.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.2C-INTNULL) with ESMTP id SAA04231; Mon, 23 Apr 2001 18:43:16 +0300 (EEST) X-Authentication-Warning: sappho.ics.forth.gr: tziou owned process doing -bs Date: Mon, 23 Apr 2001 18:43:15 +0300 (EEST) From: Chrysostomos Tziouvaras To: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Does ayone have the LEDA book? In-Reply-To: <00bb01c0bce2$2d543ce0$92feffcb@etri.re.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am looking for chapter 7(Graph Algorithms) of the LEDA book. If you have it in electronic form please send it to me with an email. Thanks Tziouvaras Chrysostomos ICS-FORTH Researcher From owner-mpls@UU.NET Mon Apr 23 11:59:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06118 for ; Mon, 23 Apr 2001 11:59:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQklzz13151; Mon, 23 Apr 2001 15:58:56 GMT Received: by mail-control.mail.uu.net id QQklzz07001 for mpls-outgoing; Mon, 23 Apr 2001 15:57:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQklzz06943 for ; Mon, 23 Apr 2001 15:57:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQklzz08847 for ; Mon, 23 Apr 2001 15:56:29 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQklzz12403 for ; Mon, 23 Apr 2001 15:56:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA01082 for mpls@uu.net; Mon, 23 Apr 2001 11:56:28 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQklzz06206 for ; Mon, 23 Apr 2001 15:52:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQklzz15721 for ; Mon, 23 Apr 2001 15:50:45 GMT Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQklzz04304 for ; Mon, 23 Apr 2001 15:50:44 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f3NFp0302236; Mon, 23 Apr 2001 18:51:00 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15076.20324.204064.658438@lohi.eng.telia.fi> Date: Mon, 23 Apr 2001 18:51:00 +0300 (EEST) To: erosen@cisco.com Cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-Reply-To: <200104231522.LAA17885@erosen-sun.cisco.com> References: <15073.17131.642478.638474@lohi.eng.telia.fi> <200104231522.LAA17885@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: > What is the customer application for which the customer is likely to > have a CE device that will mark individual non-IP packets with > diffserv information? for example, bridging ethernet over mpls. > Not many customers use MPLS for their internal stuff. Do you > foresee a significant migration of MPLS into the enterprise? Or are > you thinking of other service providers as the customers. mpls may not be used that much inside the enterprise (apart from the ces), but we have all kinds of other customers that do plan to use mpls, such as other isps and mobile network operators. > Are all these cases "very stupid"? If not, how do they differ from > the case you are considering? no, i was refering as "stupid" a case there the customer wants to send mpls packets over my mpls backbone and must encapsulate them into frame relay over local loop. eric, i haven't understod what you are driving at. are you suggesting that it doesn't make sense to replace frame relay with mlps as a logical link service even when the backbone is mpls and the ces are mpls capable? -- juha From owner-mpls@UU.NET Mon Apr 23 12:08:48 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06308 for ; Mon, 23 Apr 2001 12:08:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmaa02347; Mon, 23 Apr 2001 16:07:45 GMT Received: by mail-control.mail.uu.net id QQkmaa12694 for mpls-outgoing; Mon, 23 Apr 2001 16:06:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmaa12661 for ; Mon, 23 Apr 2001 16:06:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmaa02271 for ; Mon, 23 Apr 2001 16:05:54 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmaa29305 for ; Mon, 23 Apr 2001 16:05:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA02309 for mpls@uu.net; Mon, 23 Apr 2001 12:05:52 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmaa09052 for ; Mon, 23 Apr 2001 16:03:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmaa22441 for ; Mon, 23 Apr 2001 16:02:06 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkmaa23160 for ; Mon, 23 Apr 2001 16:02:06 GMT Received: from juniper.net ([172.16.167.234]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA27305; Mon, 23 Apr 2001 09:01:58 -0700 (PDT) Message-ID: <3AE452B7.59D85B4C@juniper.net> Date: Mon, 23 Apr 2001 09:05:11 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nhat Thanh Hoang CC: "'Metz, Eduard'" , dhg@juniper.net, arthi@juniper.net, kireeti@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: draft-gan-fast-reroute-00.txt References: <778DFE9B4E3BD111A74E08002BA3DC0D02254416@trab-hermes.haninge.trab.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nhat Thanh Hoang wrote: > > See the comments in line > Hi all, > > some questions on draft-gan-fast-reroute: > > The FAST-REROUTE object includes several parameters for the detour LSP, such > as bandwidth, and include/exclude colors. Are these completely independent > of those for the primary LSP? Or are these supposed to have a relation? > > - In the defaut mode, the detour LSPs inherit the constraints from the > primary LSPs, but the network administrator can change the relation. If I'm > not wrong. > Exactly. Better than what I said. ;-) Thanks! - Ping > Cheers, > > Nhat Thanh > > Telia Research AB From owner-mpls@UU.NET Mon Apr 23 12:09:07 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06339 for ; Mon, 23 Apr 2001 12:09:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmaa07727; Mon, 23 Apr 2001 16:09:04 GMT Received: by mail-control.mail.uu.net id QQkmaa12924 for mpls-outgoing; Mon, 23 Apr 2001 16:07:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmaa12707 for ; Mon, 23 Apr 2001 16:06:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmaa02273 for ; Mon, 23 Apr 2001 16:05:54 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmaa02097 for ; Mon, 23 Apr 2001 16:05:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA02301 for mpls@uu.net; Mon, 23 Apr 2001 12:05:52 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmaa09059 for ; Mon, 23 Apr 2001 16:03:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmaa21402 for ; Mon, 23 Apr 2001 16:01:15 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkmaa21837 for ; Mon, 23 Apr 2001 16:01:14 GMT Received: from juniper.net ([172.16.167.234]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA27264; Mon, 23 Apr 2001 09:01:11 -0700 (PDT) Message-ID: <3AE45275.F5523D41@juniper.net> Date: Mon, 23 Apr 2001 09:04:05 -0700 From: Ping Pan Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Metz, Eduard" CC: dhg@juniper.net, arthi@juniper.net, kireeti@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: draft-gan-fast-reroute-00.txt References: <3F3B952383E8D311A9FC0008C7E61402027A0605@ntexgdhg02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Metz, Eduard" wrote: > > The FAST-REROUTE object includes several parameters for the detour LSP, such > as bandwidth, and include/exclude colors. Are these completely independent > of those for the primary LSP? Or are these supposed to have a relation? > They could be independent. For example, the operators may decide to allocate less bandwidth to the backup LSP's. On the other hand, the FAST-REROUTE parameters could be the same the one used in the primary LSP's. We want to provide alternative options here. > The DETOUR object includes Downstream Node ID, identifying the neighboring > node to route around. This seems to work for all hops, except the > penultimate. Here the detour only can protect the link, also shown in the > picture in section 2. Should there be an exception for this case, or does > the penultimate hop apply different logic when setting up the detour? > The downstream ID is one of the nodes at downstream from the router, which could be multiple hops and links away. Of course you can also use it to protect one link. The logic used at a penultimate hop is the same as all others. Thanks! - Ping > cheers, > Eduard From owner-mpls@UU.NET Mon Apr 23 13:07:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07054 for ; Mon, 23 Apr 2001 13:07:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmae04591; Mon, 23 Apr 2001 17:07:47 GMT Received: by mail-control.mail.uu.net id QQkmae14292 for mpls-outgoing; Mon, 23 Apr 2001 17:07:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmae14034 for ; Mon, 23 Apr 2001 17:06:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmae08571 for ; Mon, 23 Apr 2001 17:06:42 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmae02849 for ; Mon, 23 Apr 2001 17:06:41 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3NH6eu15561; Mon, 23 Apr 2001 10:06:40 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA18232; Mon, 23 Apr 2001 13:06:39 -0400 (EDT) Message-Id: <200104231706.NAA18232@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Juha Heinanen cc: sgong@gmu.edu, mpls@UU.NET Subject: Re: Does MPLS Require L3 Routing Table ? In-reply-to: Your message of Mon, 23 Apr 2001 18:51:00 +0300. <15076.20324.204064.658438@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: Mon, 23 Apr 2001 13:06:39 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Juha> are you suggesting that it doesn't make sense to replace frame relay Juha> with mpls as a logical link service even when the backbone is mpls and Juha> the ces are mpls capable? I've just been asking for an explanation of the advantages of doing this. You've suggested two advantages: 1. The CE can set the EXP bits, allowing it to signal per-packet diffserv handling for non-IP packets. This might be an advantage, if there are situations in which it is important for the CE to signal per-packet diffserv handling for packets, without the PE having to know anything at all about the encapsulated packets. On the other hand, any other encapsulation which has three available bits would do as well. This might be worth more discussion. 2. If one CE is sending MPLS packets to a second CE, over a service provider's MPLS backbone, then this eliminates the need to encapsulate the MPLS packets in a data link layer. This one I don't see at all. Since in every existing application, MPLS packets are encapsulated in a data link layer, avoiding the need to encapsulate them in a data link layer in one particular scenario doesn't seem that important. And why would the CE care anyway whether it wraps the MPLS packet in a frame relay header with a DLCI field, or whether it pushes a new (statically configured, I guess, since you dislike SVCs) MPLS label on the packet? If the purpose of using MPLS on the access link is just to have the top label identify a particular virtual circuit, I don't really see that there is a significant advantage over any other data link layer multiplexing technique. From owner-mpls@UU.NET Mon Apr 23 13:57:38 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08268 for ; Mon, 23 Apr 2001 13:57:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmah02900; Mon, 23 Apr 2001 17:57:28 GMT Received: by mail-control.mail.uu.net id QQkmah27368 for mpls-outgoing; Mon, 23 Apr 2001 17:56:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmah27350 for ; Mon, 23 Apr 2001 17:56:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmah13856 for ; Mon, 23 Apr 2001 17:55:37 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkmah00886 for ; Mon, 23 Apr 2001 17:55:37 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id DD87C94009; Mon, 23 Apr 2001 13:55:31 -0400 (EDT) Message-ID: <3AE46C93.E6551DBC@sandburst.com> Date: Mon, 23 Apr 2001 13:55:31 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 Cc: mpls@UU.NET Subject: Re: End of LSP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit 'Mike', There are several ways that an LSR might know that it is the egress for an LSP, including configuration. Simplest is if the LSR looks at the next hop for a specific FEC, and the interface associated with this next hop is not MPLS capable, MPLS is not enabled or the next hop itself is not a peer LSR (as determined, for example, by having a peer session [LDP]), then the local LSR must be the egress for LSPs associated with this FEC. -- Eric Gray Somebody wrote: > Hi, > When a LSP is being setup by LDP, how does LDP running on the egress LSR > determine that it is the egress for the LSP being setup so that it > can send label binding back. Is there some configuration parameter which > tell the LDP that it is running on the edge of the MPLS network. > regards, Mike From owner-mpls@UU.NET Mon Apr 23 14:54:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10318 for ; Mon, 23 Apr 2001 14:54:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmal02600; Mon, 23 Apr 2001 18:54:12 GMT Received: by mail-control.mail.uu.net id QQkmal21614 for mpls-outgoing; Mon, 23 Apr 2001 18:53:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmal21580 for ; Mon, 23 Apr 2001 18:53:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmal18559 for ; Mon, 23 Apr 2001 18:52:45 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkmal00392 for ; Mon, 23 Apr 2001 18:52:43 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f3NIoj521167 for ; Mon, 23 Apr 2001 11:50:45 -0700 (PDT) Reply-To: From: "Anil Gunturu" To: Subject: FTN table Date: Mon, 23 Apr 2001 11:51:14 -0700 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.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Is it possible to specify the FTN table with the lsr mib? http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt It seems to specify only the ILM table. Thanks, -Anil From owner-mpls@UU.NET Mon Apr 23 15:14:59 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10801 for ; Mon, 23 Apr 2001 15:14:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmam18501; Mon, 23 Apr 2001 19:14:55 GMT Received: by mail-control.mail.uu.net id QQkmam11186 for mpls-outgoing; Mon, 23 Apr 2001 19:14:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmam11178 for ; Mon, 23 Apr 2001 19:14:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmam07052 for ; Mon, 23 Apr 2001 19:13:45 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmam00674 for ; Mon, 23 Apr 2001 19:13:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA19544 for mpls@uu.net; Mon, 23 Apr 2001 15:13:44 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmam10560 for ; Mon, 23 Apr 2001 19:09:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmam20697 for ; Mon, 23 Apr 2001 19:09:12 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkmam12417 for ; Mon, 23 Apr 2001 19:09:12 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA01921; Mon, 23 Apr 2001 15:08:10 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.84.75.67]) by bucket.cisco.com (Mirapoint) with ESMTP id AAY01147; Mon, 23 Apr 2001 15:09:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20010423150954.01a11650@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Apr 2001 15:10:43 -0400 To: , From: "Thomas D. Nadeau" Subject: Re: FTN table In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk No, this is what the FTN MIB is for. :P See: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-01.txt --Tom >Is it possible to specify the FTN table with the lsr mib? >http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt >It seems to specify only the ILM table. >Thanks, >-Anil From owner-mpls@UU.NET Mon Apr 23 16:13:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11961 for ; Mon, 23 Apr 2001 16:13:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmaq02563; Mon, 23 Apr 2001 20:13:03 GMT Received: by mail-control.mail.uu.net id QQkmaq05800 for mpls-outgoing; Mon, 23 Apr 2001 20:12:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmaq05784 for ; Mon, 23 Apr 2001 20:12:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmaq23522 for ; Mon, 23 Apr 2001 20:10:39 GMT Received: from acc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkmaq25414 for ; Mon, 23 Apr 2001 20:10:38 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f3NK8e528299; Mon, 23 Apr 2001 13:08:40 -0700 (PDT) Reply-To: From: "Anil Gunturu" To: , Subject: RE: FTN table Date: Mon, 23 Apr 2001 13:09:07 -0700 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.2919.6600 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Also, is possible to distinguish ATM labels from Generic labels using the draft-ietf-mpls-lsr-mib-07.txt mib. The textual convention for mplsLabel encodes generic, ATM and FR labels in a nice fashion, but given a label it is not possible to identify if it represents Genreic/ATM/FR. This could be useful if one wants to display just the ATM bindings from the mplsXCTable. Thanks, -Anil Is it possible to specify the FTN table with the lsr mib? http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt It seems to specify only the ILM table. Thanks, -Anil From owner-mpls@UU.NET Mon Apr 23 16:59:44 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12783 for ; Mon, 23 Apr 2001 16:59:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmat19823; Mon, 23 Apr 2001 20:59:32 GMT Received: by mail-control.mail.uu.net id QQkmat10499 for mpls-outgoing; Mon, 23 Apr 2001 20:58:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmat10490 for ; Mon, 23 Apr 2001 20:58:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmat07129 for ; Mon, 23 Apr 2001 20:58:10 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmat18242 for ; Mon, 23 Apr 2001 20:58:10 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA28396 for mpls@uu.net; Mon, 23 Apr 2001 16:58:10 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmat10202 for ; Mon, 23 Apr 2001 20:53:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmat27792 for ; Mon, 23 Apr 2001 20:53:23 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkmat05624 for ; Mon, 23 Apr 2001 20:53:23 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA11005; Mon, 23 Apr 2001 16:52:20 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.84.75.67]) by bucket.cisco.com (Mirapoint) with ESMTP id AAY02958; Mon, 23 Apr 2001 16:53:20 -0400 (EDT) Message-Id: <4.3.2.7.2.20010423165149.0189af60@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Apr 2001 16:55:03 -0400 To: , , From: "Thomas D. Nadeau" Subject: RE: FTN table In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Also, is possible to distinguish ATM labels from Generic labels using the >draft-ietf-mpls-lsr-mib-07.txt mib. The textual convention for mplsLabel >encodes generic, ATM and FR labels in a nice fashion, but given a label it >is not possible to identify if it represents Genreic/ATM/FR. This could be >useful if one wants to display just the ATM bindings from the mplsXCTable. Hi, Not that I know of. The implementations I know of use an interface-specific label space for each ATM/FR interface, so it is not too difficult to find which labels have been assigned to these special interfaces. --Tom >Thanks, >-Anil > >Is it possible to specify the FTN table with the lsr mib? >http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt >It seems to specify only the ILM table. > >Thanks, >-Anil From owner-mpls@UU.NET Mon Apr 23 18:12:21 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13818 for ; Mon, 23 Apr 2001 18:12:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmay10570; Mon, 23 Apr 2001 22:12:06 GMT Received: by mail-control.mail.uu.net id QQkmay22454 for mpls-outgoing; Mon, 23 Apr 2001 22:11:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmay22449 for ; Mon, 23 Apr 2001 22:11:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmay06957 for ; Mon, 23 Apr 2001 22:11:19 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmay09690 for ; Mon, 23 Apr 2001 22:11:19 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA03479 for mpls@uu.net; Mon, 23 Apr 2001 18:11:19 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmay21888 for ; Mon, 23 Apr 2001 22:06:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmay27133 for ; Mon, 23 Apr 2001 22:06:44 GMT Received: from netmail2.alcatel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkmay25809 for ; Mon, 23 Apr 2001 22:06:44 GMT Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA23820 for ; Mon, 23 Apr 2001 17:06:43 -0500 (CDT) Received: from usa.alcatel.com ([198.205.41.158]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA442F; Mon, 23 Apr 2001 18:20:01 -0400 Message-ID: <3AE4ADDC.5BE944E9@usa.alcatel.com> Date: Mon, 23 Apr 2001 18:34:04 -0400 From: Senthil Venkatachalam Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: mpls Subject: Re: LSP ID References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BD0@BBY1EXM01> <3ADF78CB.773499DE@marconi.com> Content-Type: multipart/alternative; boundary="------------41E418255BBD8093B074C997" Sender: owner-mpls@UU.NET Precedence: bulk --------------41E418255BBD8093B074C997 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi David, Please see my comments at the end. David Charlap wrote: > Shahram Davari wrote: > > > > In RSVP-TE, an LSP could be uniquely identified by the combination > > of Ingress Router ID, which can be found in Session object (Extended > > Tunnel ID field), and the LSP ID, which can be found in the Session > > object (Tunnel ID field). > > Not quite. > > The LSP ID field is only guaranteed unique within a single session. > > A single sender may use the same LSP ID for different LSPs in different > sessions. > > If all routers use the sender address as extended tunnel-ID, then you > can identify an LSP with the 4-tuple of tunnel-endpoint address, tunnel > ID, sender address and LSP ID. > > But you can't ever be certain of this. It is perfectly legal for > routers to use an extended tunnel ID of zero ("don't care") - making it > possible to share resources with LSPs that originate from multiple > points. Because of this, you really need the full 5-tuple (the above > parameters plus extended tunnel ID) in order to uniquely identify an > LSP. > > -- David The MPLS TE MIB describes the Tunnel Ingress LSR ID as follows: mplsTunnelIngressLSRId OBJECT-TYPE SYNTAX MplsLsrId MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The purpose of this object is to uniquely identity a tunnel within a network. When the MPLS signalling protoocol is rsvp(2) this value should mimic the Extended Tunnel Id field in the Session object. When the MPLS signalling protoocol is crldp(3) this value should mimic the Ingress LSR Router ID field in the LSPID TLV object." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, Internet Draft , August 2000., 2. Constraint-Based LSP Setup using LDP, Jamoussi, Internet Draft , July 2000." ::= { mplsTunnelEntry 3 } The MIB clearly indicates that the extended Tunnel ID should be the same as the mplsTunnelIngressLSRId. Is it still necessary for the Extended Tunnel ID to be a key? If this were another key, then shouldn't the mplsTunnelTable have the Extended Tunnel ID as another index? (As it stands, mplsTunnelTable is indexed by: mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId) Regards, Senthil. -- Senthil K. Venkatachalam senthil.venkatachalam@adn.alcatel.com Off#:, MBox: (703) 679-6435 [Off] Alcatel USA (703) 679-6450 [Fax] __________________________________________________________________ --------------41E418255BBD8093B074C997 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi David,

Please see my comments at the end.

David Charlap wrote:

Shahram Davari wrote:
>
> In RSVP-TE, an LSP could be uniquely identified by the combination
> of Ingress Router ID, which can be found in Session object (Extended
> Tunnel ID field), and the LSP ID, which can be found in the Session
> object (Tunnel ID field).

Not quite.

The LSP ID field is only guaranteed unique within a single session.

A single sender may use the same LSP ID for different LSPs in different
sessions.

If all routers use the sender address as extended tunnel-ID, then you
can identify an LSP with the 4-tuple of tunnel-endpoint address, tunnel
ID, sender address and LSP ID.

But you can't ever be certain of this.  It is perfectly legal for
routers to use an extended tunnel ID of zero ("don't care") - making it
possible to share resources with LSPs that originate from multiple
points.  Because of this, you really need the full 5-tuple (the above
parameters plus extended tunnel ID) in order to uniquely identify an
LSP.

-- David

The MPLS TE MIB describes the Tunnel Ingress LSR ID as follows:

mplsTunnelIngressLSRId OBJECT-TYPE
   SYNTAX        MplsLsrId
   MAX-ACCESS    accessible-for-notify
   STATUS        current
   DESCRIPTION
        "The purpose of this object is to uniquely identity a
          tunnel within a network. When the MPLS signalling
          protoocol is rsvp(2) this value should mimic the
          Extended Tunnel Id field in the Session object.
          When the MPLS signalling protoocol is crldp(3) this
          value should mimic the Ingress LSR Router ID field
          in the LSPID TLV object."
   REFERENCE
        "1. RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Awduche et al, Internet Draft <draft-ietf-mpls-rsvp-
          lsp-tunnel-07.txt>, August 2000.,
         2. Constraint-Based LSP Setup using LDP, Jamoussi,
          Internet Draft <draft-ietf-mpls-cr-ldp-04.txt>,
          July 2000."
   ::= { mplsTunnelEntry 3 }

The MIB clearly indicates that the extended Tunnel ID should be
the same as the mplsTunnelIngressLSRId. Is it still necessary for
the Extended Tunnel ID to be a key?

If this were another key, then shouldn't the mplsTunnelTable have
the Extended Tunnel ID as another index?
(As it stands, mplsTunnelTable is indexed by:
mplsTunnelIndex, mplsTunnelInstance,
mplsTunnelIngressLSRId, mplsTunnelEgressLSRId)

Regards,
Senthil.
  

-- 
Senthil K. Venkatachalam     senthil.venkatachalam@adn.alcatel.com
Off#:, MBox:                 (703) 679-6435 [Off]
Alcatel USA                  (703) 679-6450 [Fax]
__________________________________________________________________
  --------------41E418255BBD8093B074C997-- From owner-mpls@UU.NET Mon Apr 23 18:40:28 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14212 for ; Mon, 23 Apr 2001 18:40:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmba11238; Mon, 23 Apr 2001 22:40:20 GMT Received: by mail-control.mail.uu.net id QQkmba24910 for mpls-outgoing; Mon, 23 Apr 2001 22:39:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmba24883 for ; Mon, 23 Apr 2001 22:39:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmba25968 for ; Mon, 23 Apr 2001 22:38:31 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkmba17613 for ; Mon, 23 Apr 2001 22:38:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA06895 for ; Mon, 23 Apr 2001 18:38:29 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA12424 for ; Mon, 23 Apr 2001 18:38:31 -0400 (EDT) Message-ID: <3AE4AEEE.37DD0012@marconi.com> Date: Mon, 23 Apr 2001 18:38:38 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls Subject: Re: LSP ID References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BD0@BBY1EXM01> <3ADF78CB.773499DE@marconi.com> <3AE4ADDC.5BE944E9@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Senthil Venkatachalam wrote: > > The MPLS TE MIB describes the Tunnel Ingress LSR ID as follows: > > mplsTunnelIngressLSRId OBJECT-TYPE > SYNTAX MplsLsrId > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The purpose of this object is to uniquely identity a > tunnel within a network. When the MPLS signalling > protoocol is rsvp(2) this value should mimic the > Extended Tunnel Id field in the Session object. > When the MPLS signalling protoocol is crldp(3) this > value should mimic the Ingress LSR Router ID field > in the LSPID TLV object." > REFERENCE > "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, > Awduche et al, Internet Draft lsp-tunnel-07.txt>, August 2000., > 2. Constraint-Based LSP Setup using LDP, Jamoussi, > Internet Draft , > July 2000." > ::= { mplsTunnelEntry 3 } > > The MIB clearly indicates that the extended Tunnel ID should be > the same as the mplsTunnelIngressLSRId. Is it still necessary for > the Extended Tunnel ID to be a key? Then there is potential for conflict between the TE MIB and RSVP-TE itself. If the extended tunnel ID and sender address do not match, then there is no way to properly represent the LSP in the MIB table. RSVP-TE (including the latest drafts) says (section 4.6.1.1): Extended Tunnel ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv4 address here as a globally unique identifier. It is clear that the use of an all-zeros extended tunnel ID is valid. It is even documented as the default case. The fact that the all-zeros value is not commonly used does not change the fact that it is a legal value. An RSVP-TE-specific MIB table (which has not been specified, apparently) must take this into consideration. > If this were another key, then shouldn't the mplsTunnelTable have > the Extended Tunnel ID as another index? > (As it stands, mplsTunnelTable is indexed by: > mplsTunnelIndex, mplsTunnelInstance, > mplsTunnelIngressLSRId, mplsTunnelEgressLSRId) I can only assume that the TE MIB was based upon the features of RSVP-TE that are commonly in use, and can not fully accomodate all of its features. If someone build a router that supports multipoint-to-point LSPs using RSVP-TE, the TE MIB will have to be updated, or that implementation will be unable to properly represent these kinds of LSPs using it. -- David From owner-mpls@UU.NET Mon Apr 23 20:41:14 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15415 for ; Mon, 23 Apr 2001 20:41:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmbi17985; Tue, 24 Apr 2001 00:41:07 GMT Received: by mail-control.mail.uu.net id QQkmbi09414 for mpls-outgoing; Tue, 24 Apr 2001 00:40:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmbi09403 for ; Tue, 24 Apr 2001 00:40:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmbi00690 for ; Tue, 24 Apr 2001 00:38:44 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmbi08601 for ; Tue, 24 Apr 2001 00:38:43 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA11046 for mpls@uu.net; Mon, 23 Apr 2001 20:38:42 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmbi09198 for ; Tue, 24 Apr 2001 00:37:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmbi08472 for ; Tue, 24 Apr 2001 00:36:51 GMT Received: from sj-msg-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQkmbi27655 for ; Tue, 24 Apr 2001 00:36:51 GMT Received: from mira-sjc5-8.cisco.com (mira-sjc5-8.cisco.com [171.71.163.31]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id RAA11216 for ; Mon, 23 Apr 2001 17:34:56 -0700 (PDT) Received: from DCHINNAI-W2K.cisco.com (dhcp-171-71-27-208.cisco.com [171.71.27.208]) by mira-sjc5-8.cisco.com (Mirapoint) with ESMTP id AAO11172 (AUTH dchinnai); Mon, 23 Apr 2001 17:35:04 -0700 (PDT) Message-Id: <4.3.2.7.2.20010423173320.00afa6d0@mira-sjc5-8.cisco.com> X-Sender: dchinnai@mira-sjc5-8.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Apr 2001 17:33:55 -0700 To: mpls@UU.NET From: Durai Chinnaiah Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk unsubscribe From owner-mpls@UU.NET Tue Apr 24 02:31:17 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04162 for ; Tue, 24 Apr 2001 02:31:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmcg27900; Tue, 24 Apr 2001 06:31:00 GMT Received: by mail-control.mail.uu.net id QQkmcg22117 for mpls-outgoing; Tue, 24 Apr 2001 06:30:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmcg22109 for ; Tue, 24 Apr 2001 06:30:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmcg16139 for ; Tue, 24 Apr 2001 06:30:13 GMT Received: from web13104.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13104.mail.yahoo.com [216.136.174.149]) id QQkmcg26993 for ; Tue, 24 Apr 2001 06:30:12 GMT Message-ID: <20010424063012.6931.qmail@web13104.mail.yahoo.com> Received: from [38.186.47.9] by web13104.mail.yahoo.com; Mon, 23 Apr 2001 23:30:12 PDT Date: Mon, 23 Apr 2001 23:30:12 -0700 (PDT) From: Elwin Eliazer Subject: RE: VRF and overlapping addresses ... To: Alexander Marhold , mpls@UU.NET, ppvpn@zephion.net Cc: erosen@cisco.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Alex, Hope the corrections you have mentioned are the intentions of the authors, and the draft gets updated accordingly. Thanks, Elwin. --- Alexander Marhold wrote: > Elwin wrote: > >However, section 1.4 in 2547bis-02 confuses me. It > >states that, so long as the overlapping part of the > >address space does not belong to any of the sites > >which the two VPNs have in common, it should not be > >ambiguous. > > > >Take for example: > > > >VPN-1 = site1, site2, site3 > >VPN-2 = site1, site4 > > > >Let's assume site2 and site4 have overlapping > >addresses. When a packet destined for a host in > site4 > >originates from site1, is looked up in PE, how is > the > >VRF able to choose between site2 and site4? > > > >Am i missing something here? > > YES and NO, but it is not easy to detect > the simple answer is, that you must decide which > addresses you will allow > to enter site1 vrf, so for the overlapping addresses > you should decide to > either not import them on site1 at all, or only from > site2 and NOT from > site 4 or vice versa. > > Excerpt from DRAFT: > If two VPNs have no sites in common, then they > may have overlapping > address spaces. That is, a given address might > be used in VPN V1 as > the address of system S1, but in VPN V2 as the > address of a > completely different system S2. This is a common > situation when the > VPNs each use an RFC1918 private address space. > (In fact, two VPNs > which do have sites in common may have > overlapping address spaces, as > long as the overlapping part of the address space > does not belong to > any of the sites which the two VPNs have in > common.) > > Seeing your point I would suggest to rephrase it > that way: > In fact, two VPNs > which do have sites in common may have > overlapping address spaces, as > long as the overlapping part of the address space > does not belong to > any of the sites which the two VPNs have in > common ... > ...and those overlapping addresses are not > forwarded to shared sites > from more than one VPN.) > ===== ------- Elwin Stelzer Eliazer Corona Networks San Jose, CA 408-519-3832 ------- __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mpls@UU.NET Tue Apr 24 05:12:17 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05187 for ; Tue, 24 Apr 2001 05:12:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmcq00531; Tue, 24 Apr 2001 09:12:13 GMT Received: by mail-control.mail.uu.net id QQkmcq27144 for mpls-outgoing; Tue, 24 Apr 2001 09:11:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmcq26965 for ; Tue, 24 Apr 2001 09:11:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmcq08202 for ; Tue, 24 Apr 2001 09:11:16 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQkmcq00189 for ; Tue, 24 Apr 2001 09:11:15 GMT Received: from gayatri.hclt.com (GAYATRI [192.168.232.199]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JLKTZB4P; Tue, 24 Apr 2001 14:52:31 +0530 Received: from MALLIKPC ([192.168.232.110]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 24KQ0X3M; Tue, 24 Apr 2001 14:45:29 +0530 From: "gopinathg" To: Subject: test mail Date: Tue, 24 Apr 2001 14:47:32 +0530 Message-ID: <008801c0cc9f$64f79f30$6ee8a8c0@hclt.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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From owner-mpls@UU.NET Tue Apr 24 10:28:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08433 for ; Tue, 24 Apr 2001 10:28:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmdl24111; Tue, 24 Apr 2001 14:28:48 GMT Received: by mail-control.mail.uu.net id QQkmdl23728 for mpls-outgoing; Tue, 24 Apr 2001 14:28:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmdl23701 for ; Tue, 24 Apr 2001 14:28:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmdl04422 for ; Tue, 24 Apr 2001 14:27:15 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQkmdl22211 for ; Tue, 24 Apr 2001 14:27:14 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id XAA25550; Tue, 24 Apr 2001 23:24:39 +0900 (KST) X-OpenMail-Hops: 2 Date: Tue, 24 Apr 2001 23:23:58 +0900 Message-Id: In-Reply-To: <00bb01c0ccb7$72960650$761813ac@blapc0023> Subject: (Reply) QoS in MPLS MIME-Version: 1.0 TO: mpls@UU.NET, shailendra_suman@bla.satyam.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Tue, 24 Apr 2001 23:23:01 +0900" ;Modification-Date="Tue, 24 Apr 2001 23:23:52 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi Suman, Please find the required info at www.mplsrc.com Regards, Seenu From owner-mpls@UU.NET Tue Apr 24 11:02:09 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08879 for ; Tue, 24 Apr 2001 11:02:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmdo00936; Tue, 24 Apr 2001 15:02:02 GMT Received: by mail-control.mail.uu.net id QQkmdo02195 for mpls-outgoing; Tue, 24 Apr 2001 15:01:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmdo01717 for ; Tue, 24 Apr 2001 15:01:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmdn09372 for ; Tue, 24 Apr 2001 14:59:56 GMT Received: from galileo5.galileo.co.il by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pop3.galileo.co.il [199.203.130.130]) id QQkmdn17907 for ; Tue, 24 Apr 2001 14:59:55 GMT Received: from galileo.co.il ([10.2.20.187]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id SAA08062 for ; Tue, 24 Apr 2001 18:00:00 +0200 (GMT-2) Message-ID: <3AE5A421.F4092EB7@galileo.co.il> Date: Tue, 24 Apr 2001 18:04:49 +0200 From: Lior Keren X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: IP min-max in FTN entry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, draft-ietf-mpls-ftn-mib-01.txt defines MplsFTNEntry as follows: MplsFTNEntry ::= SEQUENCE { mplsFTNIndex MplsFTNIndex, mplsFTNRowStatus RowStatus, mplsFTNDescr DisplayString, mplsFTNApplied TruthValue, mplsFTNMask BITS, mplsFTNAddrType InetAddressType, mplsFTNSourceIpv4AddrMin InetAddressIPv4, mplsFTNSourceIpv6AddrMin InetAddressIPv6, mplsFTNSourceIpv4AddrMax InetAddressIPv4, mplsFTNSourceIpv6AddrMax InetAddressIPv6, mplsFTNDestIpv4AddrMin InetAddressIPv4, mplsFTNDestIpv6AddrMin InetAddressIPv6, mplsFTNDestIpv4AddrMax InetAddressIPv4, mplsFTNDestIpv6AddrMax InetAddressIPv6, mplsFTNSourcePortMin MplsPortAddr, mplsFTNSourcePortMax MplsPortAddr, mplsFTNDestPortMin MplsPortAddr, mplsFTNDestPortMax MplsPortAddr, mplsFTNProtocol INTEGER, mplsFTNActionType INTEGER, mplsFTNActionPointer RowPointer, mplsFTNStorageType StorageType } Do you know why ranging IP-addr is done using min-max and not with IP-perfix as usually done for IP ? Thanks, Lior. From owner-mpls@UU.NET Tue Apr 24 11:30:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09280 for ; Tue, 24 Apr 2001 11:30:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmdq00749; Tue, 24 Apr 2001 15:30:00 GMT Received: by mail-control.mail.uu.net id QQkmdp20241 for mpls-outgoing; Tue, 24 Apr 2001 15:29:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmdp20223 for ; Tue, 24 Apr 2001 15:29:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmdp03330 for ; Tue, 24 Apr 2001 15:28:22 GMT Received: from mail2.packetengines.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail2.packetengines.com [208.227.187.173]) id QQkmdp25691 for ; Tue, 24 Apr 2001 15:28:21 GMT Received: from hostr607.alcatel.com by mail2.packetengines.com via smtpd (for cmr2.ash.ops.us.uu.net [198.5.241.40]) with SMTP; 24 Apr 2001 15:28:21 UT Received: by steam.corp.packetengines.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Apr 2001 08:25:22 -0700 Message-ID: From: Marc Lewis To: mpls@UU.NET Subject: RE: LSP ID Date: Tue, 24 Apr 2001 08:25:19 -0700 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 Charlap wrote: > [...] It is perfectly legal for > routers to use an extended tunnel ID of zero ("don't care") - making it > possible to share resources with LSPs that originate from multiple > points. Because of this, you really need the full 5-tuple (the above > parameters plus extended tunnel ID) in order to uniquely identify an LSP. This relates to a question I have about the SENDER_TEMPLATE object (specifically, the LSP_TUNNEL variety). The draft says the IP address is for "a" sender node. Does this mean "the" sender node? i.e. the ingress of the tunnel? I assumed it did, and that due to the point you make above, that the SENDER_TEMPLATE was therefore the proper place from which to derive the ingress IP address. But I'm sure I've seen traces of RSVP-TE traffic where transit LSRs put their own IP addresses in the SENDER_TEMPLATE instead of passing it on unmodified. (those same transit LSRs did, as I recall, put the ingress address in the ExtTunnelID of the SESSION object) From owner-mpls@UU.NET Tue Apr 24 12:14:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10008 for ; Tue, 24 Apr 2001 12:14:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmds21170; Tue, 24 Apr 2001 16:13:58 GMT Received: by mail-control.mail.uu.net id QQkmds13403 for mpls-outgoing; Tue, 24 Apr 2001 16:13:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmds13398 for ; Tue, 24 Apr 2001 16:13:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmds07062 for ; Tue, 24 Apr 2001 16:12:24 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkmds16785 for ; Tue, 24 Apr 2001 16:12:24 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04728 for ; Tue, 24 Apr 2001 12:12:22 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA29887 for ; Tue, 24 Apr 2001 12:12:24 -0400 (EDT) Message-ID: <3AE5A5F1.65BF3B80@marconi.com> Date: Tue, 24 Apr 2001 12:12:33 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: LSP ID References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Marc Lewis wrote: > > This relates to a question I have about the SENDER_TEMPLATE object > (specifically, the LSP_TUNNEL variety). The draft says the IP > address is for "a" sender node. Does this mean "the" sender node? > i.e. the ingress of the tunnel? That would be correct. > I assumed it did, and that due to the point you make above, that the > SENDER_TEMPLATE was therefore the proper place from which to derive > the ingress IP address. Yes. > But I'm sure I've seen traces of RSVP-TE traffic where transit > LSRs put their own IP addresses in the SENDER_TEMPLATE instead of > passing it on unmodified. (those same transit LSRs did, as I > recall, put the ingress address in the ExtTunnelID of the SESSION > object) This would be a broken implementation. Transit LSRs should be putting their own addresses in the HOP objects. SESSION, SENDER_TEMPLATE and FILTER_SPEC (the objects that define endpoints) should propagate unaltered. -- David From owner-mpls@UU.NET Tue Apr 24 12:56:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10498 for ; Tue, 24 Apr 2001 12:56:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmdv16253; Tue, 24 Apr 2001 16:55:48 GMT Received: by mail-control.mail.uu.net id QQkmdv18893 for mpls-outgoing; Tue, 24 Apr 2001 16:55:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmdv18885 for ; Tue, 24 Apr 2001 16:55:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmdv09620 for ; Tue, 24 Apr 2001 16:54:21 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmdv29103 for ; Tue, 24 Apr 2001 16:54:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA05084 for mpls@uu.net; Tue, 24 Apr 2001 12:54:21 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmdv18793 for ; Tue, 24 Apr 2001 16:53:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmdv19493 for ; Tue, 24 Apr 2001 16:53:18 GMT Received: from sj-msg-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10]) id QQkmdv12908 for ; Tue, 24 Apr 2001 16:53:17 GMT Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA02828 for ; Tue, 24 Apr 2001 09:53:22 -0700 (PDT) Received: from sen-nt.cisco.com (dhcp-171-71-223-186.cisco.com [171.71.223.186]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AES08322; Tue, 24 Apr 2001 09:53:16 -0700 (PDT) Message-Id: <5.0.2.1.0.20010424093748.0343a170@mira-sjc5-7.cisco.com> X-Sender: sen@mira-sjc5-7.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 24 Apr 2001 09:55:54 -0700 To: mpls@UU.NET From: Siddhartha Sen Subject: Output features for MPLS2IP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi: Say I have IP output features configured on a port on IP addresses. Now I have a MPLS to IP packet (Removing the label at the penultimate hop pop point). The question is will this packet be tested for output features. One school of thought says that it should not be done as it is strictly an MPLS packet with implicit NULL label. They also go further and say that what if the port is ATM (or explicit null configured) ? In that case, it would be an MPLS packet and no test on IP output features will be done. How can u build a system where the answer depends on the type of the port. An opposing school of thought says that the protocol plane is independent of the forwarding plane. The forwarding plane does not and should not distinguish between IP packets that came in as IP packets and IP packets that was obtained from being penultimate-hop-popped. Who is correct ? Which way should I implement ? Also please give pointers to any relevant RFC so as to defend myself. Thanking you, Siddhartha From owner-mpls@UU.NET Tue Apr 24 13:27:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11074 for ; Tue, 24 Apr 2001 13:27:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmdx18060; Tue, 24 Apr 2001 17:27:46 GMT Received: by mail-control.mail.uu.net id QQkmdx09908 for mpls-outgoing; Tue, 24 Apr 2001 17:27:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmdx09848 for ; Tue, 24 Apr 2001 17:26:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmdx29240 for ; Tue, 24 Apr 2001 17:25:42 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmdx15782 for ; Tue, 24 Apr 2001 17:25:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA08504 for mpls@uu.net; Tue, 24 Apr 2001 13:25:41 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmdx09518 for ; Tue, 24 Apr 2001 17:21:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmdx11899 for ; Tue, 24 Apr 2001 17:20:35 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkmdx02212 for ; Tue, 24 Apr 2001 17:20:30 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA03544; Tue, 24 Apr 2001 13:19:23 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-206.cisco.com [161.44.134.206]) by bucket.cisco.com (Mirapoint) with ESMTP id AAY12176; Tue, 24 Apr 2001 13:20:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20010424132113.018d96a8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Apr 2001 13:22:09 -0400 To: Lior Keren , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: IP min-max in FTN entry In-Reply-To: <3AE5A421.F4092EB7@galileo.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 06:04 PM 4/24/2001 +0200, Lior Keren wrote: >Hi, > >draft-ietf-mpls-ftn-mib-01.txt defines MplsFTNEntry as follows: > >MplsFTNEntry ::= SEQUENCE { > mplsFTNIndex MplsFTNIndex, > mplsFTNRowStatus RowStatus, > mplsFTNDescr DisplayString, > mplsFTNApplied TruthValue, > mplsFTNMask BITS, > mplsFTNAddrType InetAddressType, > mplsFTNSourceIpv4AddrMin InetAddressIPv4, > mplsFTNSourceIpv6AddrMin InetAddressIPv6, > mplsFTNSourceIpv4AddrMax InetAddressIPv4, > mplsFTNSourceIpv6AddrMax InetAddressIPv6, > mplsFTNDestIpv4AddrMin InetAddressIPv4, > mplsFTNDestIpv6AddrMin InetAddressIPv6, > mplsFTNDestIpv4AddrMax InetAddressIPv4, > mplsFTNDestIpv6AddrMax InetAddressIPv6, > mplsFTNSourcePortMin MplsPortAddr, > mplsFTNSourcePortMax MplsPortAddr, > mplsFTNDestPortMin MplsPortAddr, > mplsFTNDestPortMax MplsPortAddr, > mplsFTNProtocol INTEGER, > mplsFTNActionType INTEGER, > mplsFTNActionPointer RowPointer, > mplsFTNStorageType StorageType > } > >Do you know why ranging IP-addr is done using min-max and not with >IP-perfix as usually done for IP ? This is done so that you can specify a range of IP addresses to be affected by a single rule. The IP address may be a prefix too --Tom From owner-mpls@UU.NET Tue Apr 24 21:33:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19543 for ; Tue, 24 Apr 2001 21:33:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmfe16340; Wed, 25 Apr 2001 01:33:10 GMT Received: by mail-control.mail.uu.net id QQkmfe15784 for mpls-outgoing; Wed, 25 Apr 2001 01:32:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmfe15770 for ; Wed, 25 Apr 2001 01:32:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmfe07657 for ; Wed, 25 Apr 2001 01:32:15 GMT Received: from server.nayna.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: server.nayna.com [207.5.81.3]) id QQkmfe15144 for ; Wed, 25 Apr 2001 01:32:14 GMT Received: from nayna.com (sonicwall [207.5.81.2]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA01369 for ; Tue, 24 Apr 2001 18:32:13 -0700 X-Authentication-Warning: server.nayna.com: Host sonicwall [207.5.81.2] claimed to be nayna.com Message-ID: <3AE6291F.983FF64D@nayna.com> Date: Tue, 24 Apr 2001 18:32:15 -0700 From: Steven Cheung Reply-To: Steven Cheung Organization: Nayna Networks (http://www.nayna.com) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en, zh MIME-Version: 1.0 To: mpls@UU.NET Subject: what's the status code values for "Routing Problem/..."? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I have a question on draft-ietf-mpls-generalized-cr-ldp-02.txt, there are many references to NOTIFICATION message "Routing problem/...", may I ask where can I find those status code? Thanks. -Steven From owner-mpls@UU.NET Tue Apr 24 22:07:44 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20799 for ; Tue, 24 Apr 2001 22:07:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmfg06038; Wed, 25 Apr 2001 02:07:39 GMT Received: by mail-control.mail.uu.net id QQkmfg06030 for mpls-outgoing; Wed, 25 Apr 2001 02:07:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmfg06019 for ; Wed, 25 Apr 2001 02:06:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmfg02450 for ; Wed, 25 Apr 2001 02:06:46 GMT Received: from eyou.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.136.62.73]) id QQkmfg00063 for ; Wed, 25 Apr 2001 02:06:43 GMT Received: (qmail 21388 invoked from network); 25 Apr 2001 09:58:26 +0800 Received: from unknown (HELO eyou.com) (172.16.2.1) by 172.16.1.1 with SMTP; 25 Apr 2001 09:58:26 +0800 Received: (qmail 79702 invoked by uid 65534); 25 Apr 2001 09:58:26 +0800 Date: 25 Apr 2001 09:58:26 +0800 Message-ID: <20010425095826.79701.qmail@eyou.com> From: "Gao Deyun" To: mpls@UU.NET Reply-To: "Gao Deyun" Subject: load balancing Sender: owner-mpls@UU.NET Precedence: bulk Dear all, We can do load balancing in MPLS networks, but how to distribute load in several LSP? Who know it, please tell me some papers for reference. Thank you in advance, Deyun Gao --http://www.eyou.com --Îȶ¨¿É¿¿µÄĂâ·Ñµç×ÓĐÅÏä Óï̉ôÓʼ₫ ̉ƶ¯ÊéÇ© ÈƠÀú·₫Îñ ÍøÂç´æ´¢...̉ÚÓÊδ¾¡ From owner-mpls@UU.NET Tue Apr 24 23:30:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22672 for ; Tue, 24 Apr 2001 23:30:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmfm19190; Wed, 25 Apr 2001 03:30:26 GMT Received: by mail-control.mail.uu.net id QQkmfl00439 for mpls-outgoing; Wed, 25 Apr 2001 03:29:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmfl00389 for ; Wed, 25 Apr 2001 03:29:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmfl13866 for ; Wed, 25 Apr 2001 03:28:30 GMT Received: from noya.bupt.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQkmfl16513 for ; Wed, 25 Apr 2001 03:28:27 GMT Received: from mars ([202.112.109.69]) by noya.bupt.edu.cn (8.11.3/8.10.1) with SMTP id f3P3SIR24661 for ; Wed, 25 Apr 2001 11:28:19 +0800 (CST) Message-Id: <200104250328.f3P3SIR24661@noya.bupt.edu.cn> Date: Wed, 25 Apr 2001 11:32:35 +0800 From: =?ISO-8859-1?Q?=CD=F5=E8=A4?= To: "mpls@uu.net" Subject: question about Trigger Control Block? X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, everybody, Here are some questions about MPLS LDP State Machine. Can someone give me explanation? Thanks in advance. 1. Trigger Control Block is discribed unclearly in "LDP State Machine"(draft-ietf-mpls-ldp-state-04.txt). (1)what is it on earth? (2)what is its function? (3)what information does it contain? (4)how does it operation? (5)how does it interwork with LSP control block? 2.Next Hop Control Block is discribed unclearly in "LDP State Machine"(draft-ietf-mpls-ldp-state-04.txt). I have the same questions about Next Hop Control Block as 1. 3.Next Hop Control Block = Next Hop Trigger Control Block ? In draft-ietf-mpls-ldp-state-04.txt, ------------------------------------------- 3.2.1 LSP Control Block For each LSP, an LSP Control Block is defined which may contain the following information: - Upstream Label Request ID (assigned by the upstream LSR), which is the 'Message Id' in the Label Request Message received from the upstream LSR. - Downstream Label Request ID (assigned by this LSR itself), which is 'Message Id' in the Label Request Message sent to the downstream LSR. - Upstream LDP Identifier - Downstream LDP Identifier - State - FEC - Upstream Label (assigned by this LSR) - Downstream Label (assigned by the downstream LSR) - Trigger Control Block Pointer, (Only used at the ingress LSR of a LSP) that points to the control block that triggers setting up this LSP or tearing down this LSP. - Next Hop Control Block Pointer, which points to the control ********************** block which is used for switching over to a better LSP. --------------------------------------------------------------------- Is Next Hop Control Block = Next Hop Trigger Control Block? Yu Wang wangyu7707@263.net From owner-mpls@UU.NET Wed Apr 25 00:09:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23456 for ; Wed, 25 Apr 2001 00:09:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmfo11082; Wed, 25 Apr 2001 04:08:53 GMT Received: by mail-control.mail.uu.net id QQkmfo21009 for mpls-outgoing; Wed, 25 Apr 2001 04:08:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmfo20994 for ; Wed, 25 Apr 2001 04:08:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmfo08718 for ; Wed, 25 Apr 2001 04:08:10 GMT From: mgoel@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkmfo10774 for ; Wed, 25 Apr 2001 04:08:07 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3P48OI09340; Wed, 25 Apr 2001 09:38:24 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A39.00155296 ; Wed, 25 Apr 2001 09:22:53 +0530 X-Lotus-FromDomain: HSS To: "Gao Deyun" cc: mpls@UU.NET Message-ID: <65256A39.00153BF1.00@sandesh.hss.hns.com> Date: Wed, 25 Apr 2001 09:34:19 +0530 Subject: Re: load balancing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi Gao, You may refer the following drafts 1. Policy-Based Load-Balancing in Traffic-Engineered MPLS Networks This draft is available online at http://www.watersprings.org/links/mlr/id/draft-wright-mpls-te-policy-00.txt 2. Traffic Engineering of Load Distribution This draft is available online at http://www.watersprings.org/links/mlr/id/draft-wright-load-distribution-00.txt Regards Mohit Goel "Gao Deyun" on 04/25/2001 07:28:26 AM Please respond to "Gao Deyun" To: mpls@UU.NET cc: (bcc: Mohit Goel/HSS) Subject: load balancing Dear all, We can do load balancing in MPLS networks, but how to distribute load in several LSP? Who know it, please tell me some papers for reference. Thank you in advance, Deyun Gao --http://www.eyou.com --?????????????????????? ???????? ???????? ???????? ????????...???????? From owner-mpls@UU.NET Wed Apr 25 00:18:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23616 for ; Wed, 25 Apr 2001 00:18:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmfp06268; Wed, 25 Apr 2001 04:18:24 GMT Received: by mail-control.mail.uu.net id QQkmfp22274 for mpls-outgoing; Wed, 25 Apr 2001 04:17:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmfp22256 for ; Wed, 25 Apr 2001 04:17:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmfp11561 for ; Wed, 25 Apr 2001 04:17:16 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmfp19396 for ; Wed, 25 Apr 2001 04:17:15 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id AAA21098 for mpls@uu.net; Wed, 25 Apr 2001 00:17:15 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmfo21685 for ; Wed, 25 Apr 2001 04:13:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmfo27502 for ; Wed, 25 Apr 2001 04:12:32 GMT Received: from lobster.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns3.BayNetworks.COM [192.32.253.3]) id QQkmfo21643 for ; Wed, 25 Apr 2001 04:12:32 GMT Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id AAA26235; Wed, 25 Apr 2001 00:10:35 -0400 (EDT) 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 AAA07307; Wed, 25 Apr 2001 00:04:01 -0400 (EDT) Received: from baynetworks.com (abl6t0fm.us.nortel.com [47.16.4.84]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id AAA11930; Wed, 25 Apr 2001 00:04:00 -0400 for Message-ID: <3AE64C55.72A03A4A@baynetworks.com> Date: Wed, 25 Apr 2001 00:02:29 -0400 From: Shobhan Lakkapragada Reply-To: slakkapr@nortelnetworks.com Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Gao Deyun CC: mpls@UU.NET Subject: Re: load balancing References: <20010425095826.79701.qmail@eyou.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkmfp06268 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA23616 Deyun, There can be two scenarios of load balancing in MPLS. (1) load-balance a flow over multiple LSPs and (2) load-balance a single LSP over multiple physical paths. I think your question relates to (1). In this case, you could use any standard load-balancing algorithm (such as source/destination IP address hashing). (2) is a totally different problem and I believe "Optimized Multipath (OMP)" was meant to address this issue. I am not sure what happened to MPLS OMP ? - shobhan Gao Deyun wrote: > Dear all, > > We can do load balancing in MPLS networks, but how to distribute load in > several LSP? Who know it, please tell me some papers for reference. > Thank you in advance, > > Deyun Gao > > --http://www.eyou.com > --Îȶ¨¿É¿¿µÄĂâ·Ñµç×ÓĐÅÏä Óï̉ôÓʼ₫ ̉ƶ¯ÊéÇ© ÈƠÀú·₫Îñ ÍøÂç´æ´¢...̉ÚÓÊδ¾¡ From owner-mpls@UU.NET Wed Apr 25 02:47:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08510 for ; Wed, 25 Apr 2001 02:47:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmfz23076; Wed, 25 Apr 2001 06:47:12 GMT Received: by mail-control.mail.uu.net id QQkmfz08626 for mpls-outgoing; Wed, 25 Apr 2001 06:46:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmfz08621 for ; Wed, 25 Apr 2001 06:46:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmfz18256 for ; Wed, 25 Apr 2001 06:46:35 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkmfz21907 for ; Wed, 25 Apr 2001 06:46:20 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3P6l4u17394; Wed, 25 Apr 2001 12:17:05 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A39.0023D8FD ; Wed, 25 Apr 2001 12:01:33 +0530 X-Lotus-FromDomain: HSS To: Siddhartha Sen cc: mpls@UU.NET Message-ID: <65256A39.0023D7D2.00@sandesh.hss.hns.com> Date: Wed, 25 Apr 2001 12:01:29 +0530 Subject: Re: Output features for MPLS2IP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi Siddhartha! Presuming by "IP output features" you mean things like IP tunneling, GRE etc, the solutio is quite staright forward. If we are doing penultimate hop popping and our network is like r1-------r2----------r3--------r4-------r5 where r4 is the penultimate LSR for the LSP from r1 to r5 then r4 should strip the packet of the Label (pop operation) and forward the packet to r5 and hence this is completely MPLS forwarding stuff. However when we reach the router r5 it should ofcourse do all the L3 stuff needed to forward the packet to its outgoing port. The key thing here is that between the r4 and r5 it is only L2 forawarding (essentially enabled by MPLS) and when we reach the egress router then everything should happen at L3 including evrything that needs to be done before forwarding an IP packet to its outgoing port. hope this helps! ciao sumit Siddhartha Sen on 04/24/2001 10:25:54 PM To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: Output features for MPLS2IP Hi: Say I have IP output features configured on a port on IP addresses. Now I have a MPLS to IP packet (Removing the label at the penultimate hop pop point). The question is will this packet be tested for output features. One school of thought says that it should not be done as it is strictly an MPLS packet with implicit NULL label. They also go further and say that what if the port is ATM (or explicit null configured) ? In that case, it would be an MPLS packet and no test on IP output features will be done. How can u build a system where the answer depends on the type of the port. An opposing school of thought says that the protocol plane is independent of the forwarding plane. The forwarding plane does not and should not distinguish between IP packets that came in as IP packets and IP packets that was obtained from being penultimate-hop-popped. Who is correct ? Which way should I implement ? Also please give pointers to any relevant RFC so as to defend myself. Thanking you, Siddhartha From owner-mpls@UU.NET Wed Apr 25 02:52:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08526 for ; Wed, 25 Apr 2001 02:52:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmfz23355; Wed, 25 Apr 2001 06:52:05 GMT Received: by mail-control.mail.uu.net id QQkmfz09074 for mpls-outgoing; Wed, 25 Apr 2001 06:51:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmfz09055 for ; Wed, 25 Apr 2001 06:51:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmfz28429 for ; Wed, 25 Apr 2001 06:50:29 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkmfz27705 for ; Wed, 25 Apr 2001 06:50:25 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3P6p8m17503; Wed, 25 Apr 2001 12:21:10 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A39.002438E2 ; Wed, 25 Apr 2001 12:05:38 +0530 X-Lotus-FromDomain: HSS To: "Gao Deyun" cc: mpls@UU.NET Message-ID: <65256A39.00243743.00@sandesh.hss.hns.com> Date: Wed, 25 Apr 2001 12:05:33 +0530 Subject: Re: load balancing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi gao! apart from what has been already said the key thing in that shall be teh following 1. most probably you will have to us liberal retension mode to retain alternate LSP paths to different destinations. 2. idealy DU mode should be the least costly in this kind of solution. 3. Algorithms for determining the load sharing would depend on the kind of traffic needs you want to support like whether you want to maximise or optimise output amound LSPs etc. regards sumit "Gao Deyun" on 04/25/2001 07:28:26 AM Please respond to "Gao Deyun" To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: load balancing Dear all, We can do load balancing in MPLS networks, but how to distribute load in several LSP? Who know it, please tell me some papers for reference. Thank you in advance, Deyun Gao --http://www.eyou.com --?????????????????????? ???????? ???????? ???????? ????????...???????? From owner-mpls@UU.NET Wed Apr 25 07:19:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10982 for ; Wed, 25 Apr 2001 07:18:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmgr29912; Wed, 25 Apr 2001 11:18:54 GMT Received: by mail-control.mail.uu.net id QQkmgr28045 for mpls-outgoing; Wed, 25 Apr 2001 11:18:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmgr28028 for ; Wed, 25 Apr 2001 11:18:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmgr00193 for ; Wed, 25 Apr 2001 11:17:44 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmgr05402 for ; Wed, 25 Apr 2001 11:17:44 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA10985 for mpls@uu.net; Wed, 25 Apr 2001 07:17:44 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmgr27992 for ; Wed, 25 Apr 2001 11:17:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmgr27710 for ; Wed, 25 Apr 2001 11:16:46 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkmgr24614 for ; Wed, 25 Apr 2001 11:16:46 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10842; Wed, 25 Apr 2001 07:16:45 -0400 (EDT) Message-Id: <200104251116.HAA10842@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-generalized-rsvp-te-02.txt Date: Wed, 25 Apr 2001 07:16:45 -0400 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 : Generalized MPLS Signaling - RSVP-TE Extensions Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-rsvp-te-02.txt Pages : 23 Date : 24-Apr-01 This document describes extensions to RSVP-TE signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents an RSVP-TE specific description of the extensions. A CR-LDP specific description can be found in [GMPLS-LDP]. A generic functional description is presented in [GMPLS-SIG]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-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-generalized-rsvp-te-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-generalized-rsvp-te-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: <20010424133612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-rsvp-te-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010424133612.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Apr 25 07:23:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11049 for ; Wed, 25 Apr 2001 07:23:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmgr12288; Wed, 25 Apr 2001 11:23:48 GMT Received: by mail-control.mail.uu.net id QQkmgr28438 for mpls-outgoing; Wed, 25 Apr 2001 11:23:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmgr28417 for ; Wed, 25 Apr 2001 11:22:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmgr14468 for ; Wed, 25 Apr 2001 11:22:30 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmgr09153 for ; Wed, 25 Apr 2001 11:22:30 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA11496 for mpls@uu.net; Wed, 25 Apr 2001 07:22:30 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmgr28037 for ; Wed, 25 Apr 2001 11:18:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmgr03044 for ; Wed, 25 Apr 2001 11:16:26 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkmgr23697 for ; Wed, 25 Apr 2001 11:16: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 HAA10810; Wed, 25 Apr 2001 07:16:23 -0400 (EDT) Message-Id: <200104251116.HAA10810@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-generalized-cr-ldp-02.txt Date: Wed, 25 Apr 2001 07:16:23 -0400 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 : Generalized MPLS Signaling - CR-LDP Extensions Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-cr-ldp-02.txt Pages : 15 Date : 24-Apr-01 This document describes extensions to CR-LDP signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. An RSVP-TE specific description can be found in [GMPLS- RSVP]. A generic functional description is presented in [GMPLS-SIG]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-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-generalized-cr-ldp-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-generalized-cr-ldp-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: <20010424133603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-cr-ldp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010424133603.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Apr 25 07:25:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11062 for ; Wed, 25 Apr 2001 07:25:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmgr15698; Wed, 25 Apr 2001 11:25:06 GMT Received: by mail-control.mail.uu.net id QQkmgr28441 for mpls-outgoing; Wed, 25 Apr 2001 11:23:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmgr28418 for ; Wed, 25 Apr 2001 11:22:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmgr11381 for ; Wed, 25 Apr 2001 11:21:29 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmgr09187 for ; Wed, 25 Apr 2001 11:21:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA11326 for mpls@uu.net; Wed, 25 Apr 2001 07:21:29 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmgr27990 for ; Wed, 25 Apr 2001 11:17:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmgr26612 for ; Wed, 25 Apr 2001 11:16:21 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkmgr23521 for ; Wed, 25 Apr 2001 11:16:20 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10794; Wed, 25 Apr 2001 07:16:18 -0400 (EDT) Message-Id: <200104251116.HAA10794@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-generalized-signaling-03.txt Date: Wed, 25 Apr 2001 07:16:17 -0400 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 : Generalized MPLS - Signaling Functional Description Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-signaling-03.txt Pages : 26 Date : 24-Apr-01 This document describes extensions to MPLS signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms are specified in [GMPLS-RSVP] and [GMPLS-LDP]. Technology specific details are expected to be specified in independent technology specific documents, e.g., [GMPLS-SONET]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-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-generalized-signaling-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-generalized-signaling-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: <20010424133552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-signaling-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010424133552.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Apr 25 08:31:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12742 for ; Wed, 25 Apr 2001 08:31:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmgw13385; Wed, 25 Apr 2001 12:30:56 GMT Received: by mail-control.mail.uu.net id QQkmgw22962 for mpls-outgoing; Wed, 25 Apr 2001 12:30:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmgw22947 for ; Wed, 25 Apr 2001 12:30:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmgv21428 for ; Wed, 25 Apr 2001 12:29:27 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f141.law14.hotmail.com [64.4.21.141]) id QQkmgv09760 for ; Wed, 25 Apr 2001 12:29:27 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Apr 2001 05:29:26 -0700 Received: from 212.153.183.58 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 25 Apr 2001 12:29:26 GMT X-Originating-IP: [212.153.183.58] From: "MP LS" To: MPLS@UU.NET, mpls-ops@mplsrc.com Subject: MPLS Trafficdriven Date: Wed, 25 Apr 2001 14:29:26 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Apr 2001 12:29:26.0612 (UTC) FILETIME=[5DE5B940:01C0CD83] Sender: owner-mpls@UU.NET Precedence: bulk Hello all, I have a question. Is there any possibile way to create a fully dynamical Traffic driven MPLS network. So that when any packet arives at an LSR it will analyse the IP pakket ads a label in front of it with it combines to a FEC and then just sent it to the Destination LSR? Just till now i only found that you have to ask for an LSP manualy and then the data can be transported over it. I hope someone can make this clear for me. Kind regards, Niels Sitters _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Wed Apr 25 08:36:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12907 for ; Wed, 25 Apr 2001 08:36:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmgw25309; Wed, 25 Apr 2001 12:36:34 GMT Received: by mail-control.mail.uu.net id QQkmgw23546 for mpls-outgoing; Wed, 25 Apr 2001 12:35:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmgw23519 for ; Wed, 25 Apr 2001 12:35:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmgw22065 for ; Wed, 25 Apr 2001 12:35:12 GMT Received: from beamer.mchh.siemens.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQkmgw23004 for ; Wed, 25 Apr 2001 12:35:12 GMT Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA29187; Wed, 25 Apr 2001 14:35:04 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA09063; Wed, 25 Apr 2001 14:35:00 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id <2ZTCTLZF>; Wed, 25 Apr 2001 14:34:58 +0200 Message-ID: From: Hummel Heinrich To: "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com Subject: AW: MPLS Trafficdriven Date: Wed, 25 Apr 2001 14:34:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 IAA12907 What you are looking for is a MPLS UNI, where a user may request the establishment of an LSP all by signalling. Some work is going on in the MPLS Forum to specify such capability. Regards, Heinrich Hummel Siemens AG > -----Urspr> üngliche Nachricht----- > Von: MP LS [SMTP:stagempls@hotmail.com] > Gesendet am: Mittwoch, 25. April 2001 14:29 > An: MPLS@UU.NET; mpls-ops@mplsrc.com > Betreff: MPLS Trafficdriven > > Hello all, > > I have a question. Is there any possibile way to create a fully dynamical > Traffic driven MPLS network. So that when any packet arives at an LSR it > will analyse the IP pakket ads a label in front of it with it combines to a > FEC and then just sent it to the Destination LSR? Just till now i only > found that you have to ask for an LSP manualy and then the data can be > transported over it. > > I hope someone can make this clear for me. > > Kind regards, > > Niels Sitters > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Wed Apr 25 08:49:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13330 for ; Wed, 25 Apr 2001 08:49:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmgx10215; Wed, 25 Apr 2001 12:49:45 GMT Received: by mail-control.mail.uu.net id QQkmgx25168 for mpls-outgoing; Wed, 25 Apr 2001 12:49:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmgx25159 for ; Wed, 25 Apr 2001 12:49:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmgx06250 for ; Wed, 25 Apr 2001 12:48:59 GMT Received: from ntexgswp02.DMZ by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.kpnqwest.com [193.242.92.8]) id QQkmgx24210 for ; Wed, 25 Apr 2001 12:48:45 GMT Received: from ntexghub01.kpnqwest.com (unverified) by ntexgswp02.DMZ (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 25 Apr 2001 14:52:39 +0200 Received: by ntexghub01 with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 14:44:35 +0200 Message-ID: <3F3B952383E8D311A9FC0008C7E61402027A0622@ntexgdhg02> From: "Metz, Eduard" To: "'MP LS'" Cc: "'Hummel Heinrich'" , MPLS@UU.NET, mpls-ops@mplsrc.com Subject: RE: MPLS Trafficdriven Date: Wed, 25 Apr 2001 14:47:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 IAA13330 Most current MPLS implement either: - topology driven LSP setup, based on the IP routing table; - request driven LSP setup, typically this is used for TE purposes. As far as I know traffic driven has been used only in e.g. Ipsilon's IP switching which can be seen as a pre-decessor of what currently is known as MPLS. By the way: traffic-driven would mean, the LSP is setup based on the arrival of traffic. This is slightly different from what you described below. An edge LSR will always inspect the IP header and then place the packet in the appropriate LSP (independent of the LSP is setup). cheers, Eduard > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: 25 April 2001 14:35 > To: 'MP LS'; MPLS@UU.NET; mpls-ops@mplsrc.com > Subject: AW: MPLS Trafficdriven > > > What you are looking for is a MPLS UNI, where a user may > request the establishment of an LSP all by signalling. > Some work is going on in the MPLS Forum to specify such capability. > > Regards, > Heinrich Hummel > Siemens AG > > > -----Urspr> üngliche Nachricht----- > > Von: MP LS [SMTP:stagempls@hotmail.com] > > Gesendet am: Mittwoch, 25. April 2001 14:29 > > An: MPLS@UU.NET; mpls-ops@mplsrc.com > > Betreff: MPLS Trafficdriven > > > > Hello all, > > > > I have a question. Is there any possibile way to create a > fully dynamical > > Traffic driven MPLS network. So that when any packet arives > at an LSR it > > will analyse the IP pakket ads a label in front of it with > it combines to a > > FEC and then just sent it to the Destination LSR? Just > till now i only > > found that you have to ask for an LSP manualy and then the > data can be > > transported over it. > > > > I hope someone can make this clear for me. > > > > Kind regards, > > > > Niels Sitters > > > ______________________________________________________________ > ___________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Wed Apr 25 09:08:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14060 for ; Wed, 25 Apr 2001 09:08:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmgy02199; Wed, 25 Apr 2001 13:08:38 GMT Received: by mail-control.mail.uu.net id QQkmgy11227 for mpls-outgoing; Wed, 25 Apr 2001 13:08:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmgy10655 for ; Wed, 25 Apr 2001 13:07:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmgy19610 for ; Wed, 25 Apr 2001 13:07:45 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkmgy13104 for ; Wed, 25 Apr 2001 13:07:45 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id E208B94006; Wed, 25 Apr 2001 09:07:44 -0400 (EDT) Message-ID: <3AE6CC20.D5E9E141@sandburst.com> Date: Wed, 25 Apr 2001 09:07:44 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: slakkapr@nortelnetworks.com Cc: Gao Deyun , mpls@UU.NET Subject: Re: load balancing References: <20010425095826.79701.qmail@eyou.com> <3AE64C55.72A03A4A@baynetworks.com> 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 JAA14060 Shobhan, You might say that 'sanity' happened to MPLS-OMP. :-) The distinction between your #1 and #2 below is that one assumes that 'splitting' a load occurs at the ingress to a set of MPLS LSPs and the other assumes that 'splitting' can be done anywhere along an LSP. There were two assumptions that needed to be true for this latter approach to work: 1) you need to be able to plow through to the bottom of the MPLS stack (without losing context for all labels - meaning you pretty much had to keep all existing labels (at least after the first one) and insert (or swap) a new label from a set of OMP labels; 2) you need to be certain of the format for the header that follows the last label (i.e. - is it IPv4, IPv6 or something else?). The first of these is non-trivial at any really interesting wire rate, but not impossible. The second would only work if the last label was an explicit NULL for either IPv4 or IPv6. The second assumption must be true because MPLS-OMP - like other multipathing load- sharing/balancing approaches - relies on use of some algorithm (i.e. - a hashing approach you mention) to ensure that individual streams follow the same path (avoiding certain problems with packet re-ordering). If the MPLS payload is opaque, a hashing algorithm would essentially act to scatter packets from streams of data across multiple paths. -- Eric Gray You wrote: > Deyun, > > There can be two scenarios of load balancing in MPLS. > (1) load-balance a flow over multiple LSPs and > (2) load-balance a single LSP over multiple physical paths. > > I think your question relates to (1). In this case, you could use > any standard load-balancing algorithm (such as source/destination > IP address hashing). > > (2) is a totally different problem and I believe "Optimized > Multipath (OMP)" was meant to address this issue. I am not > sure what happened to MPLS OMP ? > > - shobhan > > Gao Deyun wrote: > > > Dear all, > > > > We can do load balancing in MPLS networks, but how to distribute load in > > several LSP? Who know it, please tell me some papers for reference. > > Thank you in advance, > > > > Deyun Gao > > > > --http://www.eyou.com > > --Îȶ¨¿É¿¿µÄĂâ·Ñµç×ÓĐÅÏä Óï̉ôÓʼ₫ ̉ƶ¯ÊéÇ© ÈƠÀú·₫Îñ ÍøÂç´æ´¢...̉ÚÓÊδ¾¡ From owner-mpls@UU.NET Wed Apr 25 09:41:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15168 for ; Wed, 25 Apr 2001 09:41:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmha09069; Wed, 25 Apr 2001 13:41:45 GMT Received: by mail-control.mail.uu.net id QQkmha19075 for mpls-outgoing; Wed, 25 Apr 2001 13:41:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmha19040 for ; Wed, 25 Apr 2001 13:40:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmha22529 for ; Wed, 25 Apr 2001 13:40:50 GMT Received: from noya.bupt.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQkmha12471 for ; Wed, 25 Apr 2001 13:40:47 GMT Received: from mars ([202.112.109.69]) by noya.bupt.edu.cn (8.11.3/8.10.1) with SMTP id f3PDedR08499 for ; Wed, 25 Apr 2001 21:40:39 +0800 (CST) Message-Id: <200104251340.f3PDedR08499@noya.bupt.edu.cn> Date: Wed, 25 Apr 2001 21:44:59 +0800 From: Wang Yu To: "mpls@uu.net" Subject: questions about MPLS LDP State Machine. X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, everybody, Here are some questions about MPLS LDP State Machine. Can someone give me explanation? Thanks in advance. 1. Trigger Control Block is discribed unclearly in "LDP State Machine"(draft-ietf-mpls-ldp-state-04.txt). (1)what is it on earth? (2)what is its function? (3)what information does it contain? (4)how does it operation? (5)how does it interwork with LSP control block? 2.Next Hop Control Block is discribed unclearly in "LDP State Machine"(draft-ietf-mpls-ldp-state-04.txt). I have the same questions about Next Hop Control Block as 1. 3.Next Hop Control Block = Next Hop Trigger Control Block ? In draft-ietf-mpls-ldp-state-04.txt, ------------------------------------------- 3.2.1 LSP Control Block For each LSP, an LSP Control Block is defined which may contain the following information: - Upstream Label Request ID (assigned by the upstream LSR), which is the 'Message Id' in the Label Request Message received from the upstream LSR. - Downstream Label Request ID (assigned by this LSR itself), which is 'Message Id' in the Label Request Message sent to the downstream LSR. - Upstream LDP Identifier - Downstream LDP Identifier - State - FEC - Upstream Label (assigned by this LSR) - Downstream Label (assigned by the downstream LSR) - Trigger Control Block Pointer, (Only used at the ingress LSR of a LSP) that points to the control block that triggers setting up this LSP or tearing down this LSP. - Next Hop Control Block Pointer, which points to the control ********************** block which is used for switching over to a better LSP. --------------------------------------------------------------------- Is Next Hop Control Block = Next Hop Trigger Control Block? Yu Wang wangyu7707@263.net From owner-mpls@UU.NET Wed Apr 25 10:01:12 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16163 for ; Wed, 25 Apr 2001 10:01:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhc14679; Wed, 25 Apr 2001 14:00:51 GMT Received: by mail-control.mail.uu.net id QQkmhc22534 for mpls-outgoing; Wed, 25 Apr 2001 14:00:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmhc22380 for ; Wed, 25 Apr 2001 14:00:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhb18991 for ; Wed, 25 Apr 2001 13:59:18 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmhb12823 for ; Wed, 25 Apr 2001 13:59:17 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3PDxJL18960 for ; Wed, 25 Apr 2001 06:59:19 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA23056 for mpls@uu.net; Wed, 25 Apr 2001 09:59:12 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmek20134 for ; Tue, 24 Apr 2001 20:30:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmej28875 for ; Tue, 24 Apr 2001 20:26:05 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f224.law15.hotmail.com [64.4.23.224]) id QQkmej24946 for ; Tue, 24 Apr 2001 20:26:04 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 24 Apr 2001 13:26:04 -0700 Received: from 65.112.106.16 by lw15fd.law15.hotmail.msn.com with HTTP; Tue, 24 Apr 2001 20:26:04 GMT X-Originating-IP: [65.112.106.16] From: "John Wysocki" To: mpls-ops@mplsrc.com, mpls@UU.NET Date: Tue, 24 Apr 2001 20:26:04 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Apr 2001 20:26:04.0252 (UTC) FILETIME=[C90189C0:01C0CCFC] Sender: owner-mpls@UU.NET Precedence: bulk I have very high level generic MPLS TE questions to ask. If you could help me on it, I'll appreciate very much. 1) It's my understanding LSPs are usually within an AS and not inter-AS. Is this correct? 2) BGP-TE is really not well defined yet, right? 3) Is multicast well defined in MPLS? 4) Only GMPLS defineds bi-directional LSPs, but ISIS usu takes links as bi-directional but MPLS tunnel is not. Does anyone know how to handle this situation? Thanks. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Apr 25 10:03:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16288 for ; Wed, 25 Apr 2001 10:03:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhc01346; Wed, 25 Apr 2001 14:03:11 GMT Received: by mail-control.mail.uu.net id QQkmhc24836 for mpls-outgoing; Wed, 25 Apr 2001 14:02:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmhc24703 for ; Wed, 25 Apr 2001 14:02:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhc16105 for ; Wed, 25 Apr 2001 14:00:36 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmhc14328 for ; Wed, 25 Apr 2001 14:00:35 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3PE0bL19825 for ; Wed, 25 Apr 2001 07:00:37 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA23094 for mpls@uu.net; Wed, 25 Apr 2001 10:00:32 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmha18319 for ; Wed, 25 Apr 2001 13:34:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmha15223 for ; Wed, 25 Apr 2001 13:33:43 GMT Received: from caesar.appiancom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.appiancom.com [146.115.35.70]) id QQkmha15237 for ; Wed, 25 Apr 2001 13:33:43 GMT Received: by CAESAR with Internet Mail Service (5.5.2448.0) id <2THCAXC4>; Wed, 25 Apr 2001 09:33:42 -0400 Message-ID: From: Ashwin Moranganti To: "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com Subject: RE: MPLS Trafficdriven Date: Wed, 25 Apr 2001 09:33:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CD8C.582F2D7A" 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_01C0CD8C.582F2D7A Content-Type: text/plain; charset="windows-1252" I have seen this as one of the feature in Lucent's IP Navigator MPLS product. The ports are configurable for this feature, and when a certain traffic flow is detected LSPs are signalled for and the data is transmitted and then LSPs are destroyed. Though this is not useful for all applications. The key here is the signalling rate. If the rate is satisfactory, it is useful for some applications thankyou Ashwin -----Original Message----- From: MP LS [mailto:stagempls@hotmail.com] Sent: Wednesday, April 25, 2001 8:29 AM To: MPLS@uu.net; mpls-ops@mplsrc.com Subject: MPLS Trafficdriven Hello all, I have a question. Is there any possibile way to create a fully dynamical Traffic driven MPLS network. So that when any packet arives at an LSR it will analyse the IP pakket ads a label in front of it with it combines to a FEC and then just sent it to the Destination LSR? Just till now i only found that you have to ask for an LSP manualy and then the data can be transported over it. I hope someone can make this clear for me. Kind regards, Niels Sitters _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------_=_NextPart_001_01C0CD8C.582F2D7A Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable RE: MPLS Trafficdriven

I have seen this as one of the feature in Lucent's IP = Navigator MPLS product.
The ports are configurable for this feature, and = when a certain traffic flow is detected LSPs are signalled for and the = data is transmitted and then LSPs are destroyed. Though this is not = useful for all applications. The key here is the signalling rate. If = the rate is satisfactory, it is useful for some applications

thankyou
Ashwin

-----Original Message-----
From: MP LS [mailto:stagempls@hotmail.com]<= /FONT>
Sent: Wednesday, April 25, 2001 8:29 AM
To: MPLS@uu.net; mpls-ops@mplsrc.com
Subject: MPLS Trafficdriven


Hello all,

I have a question. Is there any possibile way to = create a fully dynamical
Traffic driven MPLS network. So that when any packet = arives at an LSR it
will analyse the IP pakket ads a label in front of = it with it combines to a
FEC and then just sent it to the Destination = LSR?  Just till now i only
found that you have to ask for an LSP manualy and = then the data can be
transported over it.

I hope someone can make this clear for me.

Kind regards,

Niels Sitters
_______________________________________________________________= __________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

------_=_NextPart_001_01C0CD8C.582F2D7A-- From owner-mpls@UU.NET Wed Apr 25 10:16:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16820 for ; Wed, 25 Apr 2001 10:16:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhd22407; Wed, 25 Apr 2001 14:16:00 GMT Received: by mail-control.mail.uu.net id QQkmhd03126 for mpls-outgoing; Wed, 25 Apr 2001 14:15:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmhd02974 for ; Wed, 25 Apr 2001 14:15:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhc18204 for ; Wed, 25 Apr 2001 14:14:57 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkmhc01311 for ; Wed, 25 Apr 2001 14:14:57 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id AE8889400A; Wed, 25 Apr 2001 10:14:56 -0400 (EDT) Message-ID: <3AE6DBDF.8AF81B93@sandburst.com> Date: Wed, 25 Apr 2001 10:14:56 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?=CD=F5=E8=A4?= Cc: "mpls@uu.net" Subject: Re: question about Trigger Control Block? References: <200104250328.f3P3SIR24661@noya.bupt.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yu, Hello. Please see my earlier answer on this subject at: http://cell.onecall.net/mhonarc/mpls/2001-Mar/msg00009.html If this does not clear up your questions below, let me know. Thanks! -- Eric Gray You wrote: > Hi, everybody, > > Here are some questions about MPLS LDP State Machine. > Can someone give me explanation? > Thanks in advance. > > 1. Trigger Control Block is discribed unclearly in "LDP State Machine"(draft-ietf-mpls-ldp-state-04.txt). > (1)what is it on earth? > (2)what is its function? > (3)what information does it contain? > (4)how does it operation? > (5)how does it interwork with LSP control block? > > 2.Next Hop Control Block is discribed unclearly in "LDP State Machine"(draft-ietf-mpls-ldp-state-04.txt). > I have the same questions about Next Hop Control Block as 1. > > 3.Next Hop Control Block = Next Hop Trigger Control Block ? > > In draft-ietf-mpls-ldp-state-04.txt, > ------------------------------------------- > 3.2.1 LSP Control Block > > For each LSP, an LSP Control Block is defined which may contain the > following information: > - Upstream Label Request ID (assigned by the upstream LSR), > which is the 'Message Id' in the Label Request Message > received from the upstream LSR. > - Downstream Label Request ID (assigned by this LSR itself), > which is 'Message Id' in the Label Request Message sent to > the downstream LSR. > - Upstream LDP Identifier > - Downstream LDP Identifier > - State > - FEC > - Upstream Label (assigned by this LSR) > - Downstream Label (assigned by the downstream LSR) > - Trigger Control Block Pointer, (Only used at the ingress LSR > of a LSP) that points to the control block that triggers > setting up this LSP or tearing down this LSP. > - Next Hop Control Block Pointer, which points to the control > ********************** > block which is used for switching over to a better LSP. > --------------------------------------------------------------------- > Is Next Hop Control Block = Next Hop Trigger Control Block? > > Yu Wang > wangyu7707@263.net From owner-mpls@UU.NET Wed Apr 25 10:51:02 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18372 for ; Wed, 25 Apr 2001 10:51:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhf04616; Wed, 25 Apr 2001 14:50:59 GMT Received: by mail-control.mail.uu.net id QQkmhf15833 for mpls-outgoing; Wed, 25 Apr 2001 14:50:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmhf15805 for ; Wed, 25 Apr 2001 14:50:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmhf14066 for ; Wed, 25 Apr 2001 14:49:37 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmhf27555 for ; Wed, 25 Apr 2001 14:49:36 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA29180 for mpls@uu.net; Wed, 25 Apr 2001 10:49:36 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmhf15112 for ; Wed, 25 Apr 2001 14:45:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhe21316 for ; Wed, 25 Apr 2001 14:41:25 GMT Received: from sj-msg-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10]) id QQkmhe29447 for ; Wed, 25 Apr 2001 14:41:24 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA22373; Wed, 25 Apr 2001 07:41:20 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f3PEfDI04591; Wed, 25 Apr 2001 07:41:13 -0700 (PDT) Message-ID: <3AE6E1AA.F551582B@cisco.com> Date: Wed, 25 Apr 2001 07:39:38 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: MP LS CC: MPLS@UU.NET, mpls-ops@mplsrc.com Subject: Re: MPLS Trafficdriven References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit For me what you are asking for is just plane prefix-LSPs supported for long time by means of TDP (Cisco) or LDP by a lot of vendors. It WILL NOT be traffic driven, but control driven - and that is huge advantage of mpls. For some people MPLS only means TE-LSPs, but this is just one big misunderstanding. > found that you have to ask for an LSP manualy and then the data can be That is for TE-LSPs only. Prefix-based LSPs are build based on the IGP routing table. R. > MP LS wrote: > > Hello all, > > I have a question. Is there any possibile way to create a fully dynamical > Traffic driven MPLS network. So that when any packet arives at an LSR it > will analyse the IP pakket ads a label in front of it with it combines to a > FEC and then just sent it to the Destination LSR? Just till now i only > found that you have to ask for an LSP manualy and then the data can be > transported over it. > > I hope someone can make this clear for me. > > Kind regards, > > Niels Sitters > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Wed Apr 25 11:36:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20082 for ; Wed, 25 Apr 2001 11:36:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhi17528; Wed, 25 Apr 2001 15:36:04 GMT Received: by mail-control.mail.uu.net id QQkmhi08657 for mpls-outgoing; Wed, 25 Apr 2001 15:35:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmhi08642 for ; Wed, 25 Apr 2001 15:35:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmhi09385 for ; Wed, 25 Apr 2001 15:34:36 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmhi15931 for ; Wed, 25 Apr 2001 15:34:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA03861 for mpls@uu.net; Wed, 25 Apr 2001 11:34:35 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmhi08307 for ; Wed, 25 Apr 2001 15:34:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhi13508 for ; Wed, 25 Apr 2001 15:33:16 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkmhi29042 for ; Wed, 25 Apr 2001 15:33:15 GMT Received: (qmail 20550 invoked by uid 104); 25 Apr 2001 15:33:15 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 5.791572 secs); 25/04/2001 08:33:09 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 25 Apr 2001 15:33:05 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f3PFX4201912 for ; Wed, 25 Apr 2001 08:33:04 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id <2NK1JKYT>; Wed, 25 Apr 2001 08:34:51 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BEE@BBY1EXM01> From: Shahram Davari To: "'mpls@uu.net'" Subject: Fragmentation in RFC-3032 Date: Wed, 25 Apr 2001 08:34:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0CD9D.4427C330" 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_01C0CD9D.4427C330 Content-Type: text/plain; charset="iso-8859-1" Hi all, There seems to be an error in RFC-3032: "3.4. Processing Labeled IPv4 Datagrams which are Too Big If a labeled IPv4 datagram is "too big", and the DF bit is not set in its IP header, then the LSR MAY silently discard the datagram. ... If the LSR chooses not to discard a labeled IPv4 datagram which is too big, or if the DF bit is set in that datagram, then it MUST execute the following algorithm:" It seems that the first sentence should read " and if DF bit is set", and the second sentence should read " if DF bit is not set". right? I also have a question regarding MPLS packet that are not transporting IP packets. Is any fragmentation done or the packet is silently discarded? Yours, Shahram Davari Systems Engineer Internet Routing Division PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 <> ------_=_NextPart_000_01C0CD9D.4427C330 Content-Type: application/octet-stream; name="Shahram Davari.vcf" Content-Disposition: attachment; filename="Shahram Davari.vcf" BEGIN:VCARD VERSION:2.1 N:Davari;Shahram FN:Shahram Davari ORG:PMC-Sierra, Inc.;R&D Research Ottawa-109203 TITLE:Product Research Engineer TEL;WORK;VOICE:+1 613 271 4018 ADR;WORK:;Ottawa;Kanata Research Park, Suite 834, Office Tower B, 555 Legget Drive;Kanata;Ontario;K2K 2X3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ottawa=0D=0AKanata Research Park, Suite 834, Office Tower B, 555 Legget Driv= e=0D=0AKanata, Ontario K2K 2X3=0D=0ACanada EMAIL;PREF;INTERNET:Shahram_Davari@pmc-sierra.com REV:20010112T213717Z END:VCARD ------_=_NextPart_000_01C0CD9D.4427C330-- From owner-mpls@UU.NET Wed Apr 25 12:13:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21368 for ; Wed, 25 Apr 2001 12:13:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhk00821; Wed, 25 Apr 2001 16:13:16 GMT Received: by mail-control.mail.uu.net id QQkmhk00557 for mpls-outgoing; Wed, 25 Apr 2001 16:12:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmhk00504 for ; Wed, 25 Apr 2001 16:12:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmhk24361 for ; Wed, 25 Apr 2001 16:12:17 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkmhk10443 for ; Wed, 25 Apr 2001 16:12:17 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA03883 for ; Wed, 25 Apr 2001 12:12:14 -0400 (EDT) Received: from marconi.com (lego-king.dc.fore.com [169.144.136.180]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04354 for ; Wed, 25 Apr 2001 12:12:17 -0400 (EDT) Message-ID: <3AE6F782.2E3E7926@marconi.com> Date: Wed, 25 Apr 2001 12:12:50 -0400 From: Jack Brennen X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: Fragmentation in RFC-3032 References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BEE@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > Hi all, > > There seems to be an error in RFC-3032: > > "3.4. Processing Labeled IPv4 Datagrams which are Too Big > If a labeled IPv4 datagram is "too big", and the DF bit is not set in its IP header, then the LSR MAY silently discard the datagram. ... > If the LSR chooses not to discard a labeled IPv4 datagram which is too big, or if the DF bit is set in that datagram, then it MUST execute the following algorithm:" > It seems that the first sentence should read " and if DF bit is set", and the second sentence should read " if DF bit is not set". > right? No, the RFC is correct. Specifically, the behavior that is mandated by the RFC is to generate an ICMP message if an IPv4 packet is too large and the DF bit is set. Silently discarding an IPv4 packet which has the DF bit set is not an allowable action. From owner-mpls@UU.NET Wed Apr 25 12:25:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21727 for ; Wed, 25 Apr 2001 12:25:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhl17684; Wed, 25 Apr 2001 16:25:48 GMT Received: by mail-control.mail.uu.net id QQkmhl02188 for mpls-outgoing; Wed, 25 Apr 2001 16:25:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmhl02158 for ; Wed, 25 Apr 2001 16:24:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmhl28363 for ; Wed, 25 Apr 2001 16:21:34 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkmhl09671 for ; Wed, 25 Apr 2001 16:21:34 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id C4A8E94006; Wed, 25 Apr 2001 12:21:33 -0400 (EDT) Message-ID: <3AE6F98D.67E4B0C3@sandburst.com> Date: Wed, 25 Apr 2001 12:21:33 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Jack Brennen Cc: "'mpls@uu.net'" Subject: Re: Fragmentation in RFC-3032 References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BEE@BBY1EXM01> <3AE6F782.2E3E7926@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, In addition to what Jack says below, the intent is to specifically allow implementations to silently discard packets it might otherwise be expected to fragment. Jack Brennen wrote: > Shahram Davari wrote: > > > > Hi all, > > > > There seems to be an error in RFC-3032: > > > > "3.4. Processing Labeled IPv4 Datagrams which are Too Big > > If a labeled IPv4 datagram is "too big", and the DF bit is not set in its IP header, then the LSR MAY silently discard the datagram. ... > > If the LSR chooses not to discard a labeled IPv4 datagram which is too big, or if the DF bit is set in that datagram, then it MUST execute the following algorithm:" > > It seems that the first sentence should read " and if DF bit is set", and the second sentence should read " if DF bit is not set". > > right? > > No, the RFC is correct. Specifically, the behavior that is mandated > by the RFC is to generate an ICMP message if an IPv4 packet is too > large and the DF bit is set. Silently discarding an IPv4 packet which > has the DF bit set is not an allowable action. From owner-mpls@UU.NET Wed Apr 25 12:53:52 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22355 for ; Wed, 25 Apr 2001 12:53:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhn15577; Wed, 25 Apr 2001 16:53:40 GMT Received: by mail-control.mail.uu.net id QQkmhn04176 for mpls-outgoing; Wed, 25 Apr 2001 16:53:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmhn04171 for ; Wed, 25 Apr 2001 16:53:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmhn07833 for ; Wed, 25 Apr 2001 16:51:50 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmhn15030 for ; Wed, 25 Apr 2001 16:51:50 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA12767 for mpls@uu.net; Wed, 25 Apr 2001 12:51:50 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmhn04033 for ; Wed, 25 Apr 2001 16:51:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmhn08665 for ; Wed, 25 Apr 2001 16:49:25 GMT Received: from mail.korea.ac.kr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: korea.ac.kr [163.152.1.251]) id QQkmhn08286 for ; Wed, 25 Apr 2001 16:49:24 GMT Received: from mail-virus (smtp.korea.ac.kr [163.152.1.128]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id BAA124378; Thu, 26 Apr 2001 01:39:41 +0900 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3PGmv116038; Wed, 25 Apr 2001 12:48:57 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-ID: <3AE6E1AA.F551582B@cisco.com> Date: Wed, 25 Apr 2001 07:39:38 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: MP LS CC: MPLS@UU.NET, mpls-ops@mplsrc.com Subject: Re: MPLS Trafficdriven References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Mailing-List: archive/latest/1048 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit For me what you are asking for is just plane prefix-LSPs supported for long time by means of TDP (Cisco) or LDP by a lot of vendors. It WILL NOT be traffic driven, but control driven - and that is huge advantage of mpls. For some people MPLS only means TE-LSPs, but this is just one big misunderstanding. > found that you have to ask for an LSP manualy and then the data can be That is for TE-LSPs only. Prefix-based LSPs are build based on the IGP routing table. R. > MP LS wrote: > > Hello all, > > I have a question. Is there any possibile way to create a fully dynamical > Traffic driven MPLS network. So that when any packet arives at an LSR it > will analyse the IP pakket ads a label in front of it with it combines to a > FEC and then just sent it to the Destination LSR? Just till now i only > found that you have to ask for an LSP manualy and then the data can be > transported over it. > > I hope someone can make this clear for me. > > Kind regards, > > Niels Sitters > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Wed Apr 25 13:54:43 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24379 for ; Wed, 25 Apr 2001 13:54:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhr13298; Wed, 25 Apr 2001 17:54:13 GMT Received: by mail-control.mail.uu.net id QQkmhr27781 for mpls-outgoing; Wed, 25 Apr 2001 17:53:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmhr27776 for ; Wed, 25 Apr 2001 17:53:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmhr07645 for ; Wed, 25 Apr 2001 17:53:32 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkmhr18090 for ; Wed, 25 Apr 2001 17:53:32 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12266 for ; Wed, 25 Apr 2001 13:53:29 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26009 for ; Wed, 25 Apr 2001 13:53:32 -0400 (EDT) Message-ID: <3AE70F27.E3625700@marconi.com> Date: Wed, 25 Apr 2001 13:53:43 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: MPLS@UU.NET Subject: Re: MPLS Trafficdriven References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MP LS wrote: > > I have a question. Is there any possibile way to create a fully > dynamical Traffic driven MPLS network. So that when any packet > arives at an LSR it will analyse the IP pakket ads a label in front > of it with it combines to a FEC and then just sent it to the > Destination LSR? Just till now i only found that you have to ask > for an LSP manualy and then the data can be transported over it. What you describe is certainly possible, and may even be used by some vendors' products. In addition to manually configured LSPs, routers may auto-generate LSPs based on the routing table. (This is one of the primary ways that LDP operates.) There's no reason why a router, upon receiving an unlabeled packet that doesn't classify into any LSP, couldn't signal an LSP for that packet's destination, in order to more rapidly forward subsequent packets. IMO, this would be far more useful in an enterprise network than a core network, but it's still a reasonable way of operating. This technique is similar to the way LANE operates on ATM networks - arriving traffic causes a VC for the traffic to be set up. The VC is torn down if too much time elapses without any traffic. Running MPLS directly to the desktop, where an application (or an IP stack) explictly requests LSPs for traffic is also a possibility, although I am unfamiliar with any work that may be going on in this area. IMO, this would be most useful in an all-MPLS enterprise network, where you could actually have a single LSP going all the way from host application to host application. -- David From owner-mpls@UU.NET Wed Apr 25 14:01:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24609 for ; Wed, 25 Apr 2001 14:01:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhs03080; Wed, 25 Apr 2001 18:01:03 GMT Received: by mail-control.mail.uu.net id QQkmhs00634 for mpls-outgoing; Wed, 25 Apr 2001 18:00:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmhs29148 for ; Wed, 25 Apr 2001 18:00:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmhr23244 for ; Wed, 25 Apr 2001 17:59:55 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkmhr27996 for ; Wed, 25 Apr 2001 17:59:55 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12906 for ; Wed, 25 Apr 2001 13:59:51 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27615 for ; Wed, 25 Apr 2001 13:59:53 -0400 (EDT) Message-ID: <3AE710A7.41DC84F9@marconi.com> Date: Wed, 25 Apr 2001 14:00:07 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit John Wysocki wrote: > > I have very high level generic MPLS TE questions to ask. If you > could help me on it, I'll appreciate very much. > > 1) It's my understanding LSPs are usually within an AS and not > inter-AS. Is this correct? This is how they will typically be used. There are explicit-route subobjects in RSVP-TE and CR-LDP for specifying AS numbers as hops along an LSP. It is theoretically possible for a single LSP to cross AS boundaries. But in actual practice, you will probably not see much of this. Mostly for political, security and business reasons. > 2) BGP-TE is really not well defined yet, right? There are drafts in progress for this. > 3) Is multicast well defined in MPLS? There are drafts in progress for this. > 4) Only GMPLS defineds bi-directional LSPs, but ISIS usu takes > links as bi-directional but MPLS tunnel is not. Does anyone > know how to handle this situation? I don't see what the problem is. Knowing that a link is bidirectional doesn't force you to signal bidirectional LSPs on it. No more than it would (somehow) force the existance of bidirectional traffic over a link in a non-MPLS network. -- David From owner-mpls@UU.NET Wed Apr 25 14:07:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24854 for ; Wed, 25 Apr 2001 14:07:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhs08206; Wed, 25 Apr 2001 18:07:13 GMT Received: by mail-control.mail.uu.net id QQkmhs15662 for mpls-outgoing; Wed, 25 Apr 2001 18:06:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmhs15171 for ; Wed, 25 Apr 2001 18:06:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmhs06286 for ; Wed, 25 Apr 2001 18:05:37 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkmhs07530 for ; Wed, 25 Apr 2001 18:05:37 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13397 for ; Wed, 25 Apr 2001 14:05:34 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28638 for ; Wed, 25 Apr 2001 14:05:37 -0400 (EDT) Message-ID: <3AE711FF.1A51F0B5@marconi.com> Date: Wed, 25 Apr 2001 14:05:51 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 CC: "'mpls@uu.net'" Subject: Re: Fragmentation in RFC-3032 References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BEE@BBY1EXM01> <3AE6F782.2E3E7926@marconi.com> <3AE6F98D.67E4B0C3@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > > In addition to what Jack says below, the intent is to specifically > allow implementations to silently discard packets it might otherwise > be expected to fragment. More specifically, some hardware (especially legacy ATM hardware) may be incapable of performing IP fragmentation. These same boxes may also be incapable of generating ICMP messages. If a too-large packet arrives at such a box, it has no choice but to drop it. Ideally, the LER that admits the packet into the LSP should check the size and fragment (or generate ICMP if DF is set) to the LSP's MTU size (that is, the mimimum MTU of all the routers along the LSP). But this may not always be possible - not all signaling protocols report the LSP's MTU to the ingress router. Hence the RFC, which allows LSRs to either fragment or discard too-large packets that don't have DF set. -- David From owner-mpls@UU.NET Wed Apr 25 14:20:17 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25357 for ; Wed, 25 Apr 2001 14:20:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmht06455; Wed, 25 Apr 2001 18:20:08 GMT Received: by mail-control.mail.uu.net id QQkmht17876 for mpls-outgoing; Wed, 25 Apr 2001 18:19:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmht17865 for ; Wed, 25 Apr 2001 18:19:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmht18490 for ; Wed, 25 Apr 2001 18:18:51 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkmht23142 for ; Wed, 25 Apr 2001 18:18:48 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 LAA03061 for ; Wed, 25 Apr 2001 11:19:14 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA23879 for mpls@uu.net; Wed, 25 Apr 2001 14:18:46 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmhs28613 for ; Wed, 25 Apr 2001 18:00:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhr14137 for ; Wed, 25 Apr 2001 17:59:29 GMT Received: from apolo2.comsat.com.ar by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [200.3.119.235]) id QQkmhr01082 for ; Wed, 25 Apr 2001 17:59:28 GMT Received: FROM halcon.comsat.com.ar BY apolo2.comsat.com.ar ; Wed Apr 25 14:56:38 2001 -0300 Received: by HALCON with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 14:58:27 -0300 Message-ID: <89158E87E11BD511AFB6001083FD99AF4DDC@HALCON> From: "Marinzulich, Matias" To: "'Ashwin Moranganti'" , "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com Subject: RE: MPLS Trafficdriven Date: Wed, 25 Apr 2001 14:58:26 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 OAA25357 Hello all, as far I can see, all cell-mode MPLS implementations (that is, MPLS network constructed with ATM switches) use 'on demand' label allocation. Since you have a very small place for save the label, the allocation and distribution must be highly conservative. For stay this minimal, all LSP are created 'on demand' in this kind of networks. In the other hand, MPLS networks based in routers can use 'on demand' or unsolicited label distribution. Matias.- > -----Mensaje original----- > De: Ashwin Moranganti [SMTP:amoranganti@appiancom.com] > Enviado el: Miércoles, 25 de Abril de 2001 10:34 a.m. > Para: 'MP LS'; MPLS@uu.net; mpls-ops@mplsrc.com > Asunto: RE: MPLS Trafficdriven > > I have seen this as one of the feature in Lucent's IP Navigator MPLS > product. > The ports are configurable for this feature, and when a certain traffic > flow is detected LSPs are signalled for and the data is transmitted and > then LSPs are destroyed. Though this is not useful for all applications. > The key here is the signalling rate. If the rate is satisfactory, it is > useful for some applications > > thankyou > Ashwin > > -----Original Message----- > From: MP LS [ ] > Sent: Wednesday, April 25, 2001 8:29 AM > To: MPLS@uu.net; mpls-ops@mplsrc.com > Subject: MPLS Trafficdriven > > > Hello all, > > I have a question. Is there any possibile way to create a fully dynamical > Traffic driven MPLS network. So that when any packet arives at an LSR it > will analyse the IP pakket ads a label in front of it with it combines to > a > FEC and then just sent it to the Destination LSR? Just till now i only > found that you have to ask for an LSP manualy and then the data can be > transported over it. > > I hope someone can make this clear for me. > > Kind regards, > > Niels Sitters > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at > . > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: > Archive: > From owner-mpls@UU.NET Wed Apr 25 14:22:45 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25438 for ; Wed, 25 Apr 2001 14:22:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmht11944; Wed, 25 Apr 2001 18:22:39 GMT Received: by mail-control.mail.uu.net id QQkmht18129 for mpls-outgoing; Wed, 25 Apr 2001 18:22:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmht18082 for ; Wed, 25 Apr 2001 18:21:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmht22690 for ; Wed, 25 Apr 2001 18:20:17 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmht24962 for ; Wed, 25 Apr 2001 18:20:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA21210 for mpls@uu.net; Wed, 25 Apr 2001 14:20:16 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmht17762 for ; Wed, 25 Apr 2001 18:17:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmht22029 for ; Wed, 25 Apr 2001 18:15:38 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f179.law10.hotmail.com [64.4.15.179]) id QQkmht19219 for ; Wed, 25 Apr 2001 18:15:38 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Apr 2001 11:15:37 -0700 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 25 Apr 2001 18:15:37 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: mpls@UU.NET Cc: ccamp@ops.ietf.org Subject: Route Pinning Doubt Date: Wed, 25 Apr 2001 11:15:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Apr 2001 18:15:37.0421 (UTC) FILETIME=[BA43A7D0:01C0CDB3] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, Is anybody using Route Pinning in the MPLS network ? If yes, what are the benefits of using route pinning ? Is route pinning applicable once the CR-LSP gets established ? Following is my understanding regarding Route pinning : Please correct me if I am wrong. Once the LSP gets established and then afterwards if better nexthop becomes available and route pinning is requested along the path, u don't change the CR-LSP path (only the loosely routed portion of LSP). Is the nexthop change procedure same for both LSP and CR-LSP ? Is there any option in LDP that once a LSP gets established and subsequent better next-hop changes should be rejected (like route pinning in LDP inaddition to CR-LDP)? Thanks, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Apr 25 14:24:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25501 for ; Wed, 25 Apr 2001 14:24:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmht29475; Wed, 25 Apr 2001 18:24:08 GMT Received: by mail-control.mail.uu.net id QQkmht18251 for mpls-outgoing; Wed, 25 Apr 2001 18:23:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmht18179 for ; Wed, 25 Apr 2001 18:22:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmht29558 for ; Wed, 25 Apr 2001 18:22:42 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmht27625 for ; Wed, 25 Apr 2001 18:22:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA21449 for mpls@uu.net; Wed, 25 Apr 2001 14:22:38 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmht18084 for ; Wed, 25 Apr 2001 18:21:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmht11463 for ; Wed, 25 Apr 2001 18:21:24 GMT Received: from shell-beach.layer8.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQkmht09291 for ; Wed, 25 Apr 2001 18:21:24 GMT Received: (qmail 17677 invoked by uid 1000); 25 Apr 2001 18:21:00 -0000 Date: Wed, 25 Apr 2001 11:21:00 -0700 From: Ben Black To: David Charlap Cc: "'mpls@uu.net'" Subject: Re: Fragmentation in RFC-3032 Message-ID: <20010425112059.B17543@layer8.net> References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BEE@BBY1EXM01> <3AE6F782.2E3E7926@marconi.com> <3AE6F98D.67E4B0C3@sandburst.com> <3AE711FF.1A51F0B5@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AE711FF.1A51F0B5@marconi.com>; from david.charlap@marconi.com on Wed, Apr 25, 2001 at 02:05:51PM -0400 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, Apr 25, 2001 at 02:05:51PM -0400, David Charlap wrote: > > Hence the RFC, which allows LSRs to either fragment or discard too-large > packets that don't have DF set. > And forces LSRs to manipulate the payload of labelled packets. Laughable arguments that MPLS is just an extension of IP aside, there is no excuse for this requirement. This is an edge function and has no business in a label switch. Ben From owner-mpls@UU.NET Wed Apr 25 14:32:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26020 for ; Wed, 25 Apr 2001 14:32:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhu02044; Wed, 25 Apr 2001 18:32:03 GMT Received: by mail-control.mail.uu.net id QQkmhu18780 for mpls-outgoing; Wed, 25 Apr 2001 18:31:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmhu18771 for ; Wed, 25 Apr 2001 18:31:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhu24950 for ; Wed, 25 Apr 2001 18:30:36 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQkmhu07505 for ; Wed, 25 Apr 2001 18:30:34 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id ; Wed, 25 Apr 2001 20:29:34 +0200 Message-ID: From: Javier Antich To: "Marinzulich, Matias" , "'Ashwin Moranganti'" , "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com Subject: RE: MPLS Trafficdriven Date: Wed, 25 Apr 2001 20:29:29 +0200 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 OAA26020 Well, that "on demand" does not mean usually "when traffic arrives", but "when I get an entry in my routing table for that destination". However it could be the first meaning. I am not sure whether traffic driven models would scale in the core of Internet. Javier. ^ ^ ==============ooo====(.)v(.)====ooo===== Javier Antich Romaguera Network Consultant --------------------------------------------------------------------------- TELINDUS Pza. Ciudad de Viena, 6-2º 28040 Madrid --------------------------------------------------------------------------- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 --------------------------------------------------------------------------- For more information about our products and services, please visit our website http://www.telindus.com --------------------------------------------------------------------------- Full connectivity & mobility ==================ooo0===0ooo======== > -----Mensaje original----- > De: Marinzulich, Matias [SMTP:Matias.Marinzulich@comsat.com.ar] > Enviado el: miércoles 25 de abril de 2001 19:58 > Para: 'Ashwin Moranganti'; 'MP LS'; MPLS@UU.NET; mpls-ops@mplsrc.com > Asunto: RE: MPLS Trafficdriven > > Hello all, as far I can see, all cell-mode MPLS implementations (that is, > MPLS network constructed with ATM switches) use 'on demand' label > allocation. Since you have a very small place for save the label, the > allocation and distribution must be highly conservative. For stay this > minimal, all LSP are created 'on demand' in this kind of networks. > In the other hand, MPLS networks based in routers can use 'on demand' or > unsolicited label distribution. > > Matias.- > > > -----Mensaje original----- > > De: Ashwin Moranganti [SMTP:amoranganti@appiancom.com] > > Enviado el: Miércoles, 25 de Abril de 2001 10:34 a.m. > > Para: 'MP LS'; MPLS@uu.net; mpls-ops@mplsrc.com > > Asunto: RE: MPLS Trafficdriven > > > > I have seen this as one of the feature in Lucent's IP Navigator MPLS > > product. > > The ports are configurable for this feature, and when a certain traffic > > flow is detected LSPs are signalled for and the data is transmitted and > > then LSPs are destroyed. Though this is not useful for all applications. > > The key here is the signalling rate. If the rate is satisfactory, it is > > useful for some applications > > > > thankyou > > Ashwin > > > > -----Original Message----- > > From: MP LS [ ] > > Sent: Wednesday, April 25, 2001 8:29 AM > > To: MPLS@uu.net; mpls-ops@mplsrc.com > > Subject: MPLS Trafficdriven > > > > > > Hello all, > > > > I have a question. Is there any possibile way to create a fully > dynamical > > Traffic driven MPLS network. So that when any packet arives at an LSR it > > > will analyse the IP pakket ads a label in front of it with it combines > to > > a > > FEC and then just sent it to the Destination LSR? Just till now i only > > found that you have to ask for an LSP manualy and then the data can be > > transported over it. > > > > I hope someone can make this clear for me. > > > > Kind regards, > > > > Niels Sitters > > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at > > . > > > > ------- > > The MPLS-OPS Mailing List > > Subscribe/Unsubscribe: > > Archive: > > From owner-mpls@UU.NET Wed Apr 25 14:34:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26088 for ; Wed, 25 Apr 2001 14:34:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhu19296; Wed, 25 Apr 2001 18:34:17 GMT Received: by mail-control.mail.uu.net id QQkmhu18933 for mpls-outgoing; Wed, 25 Apr 2001 18:33:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmhu18922 for ; Wed, 25 Apr 2001 18:33:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmhu01817 for ; Wed, 25 Apr 2001 18:33:28 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmhu04930 for ; Wed, 25 Apr 2001 18:33:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA23984 for mpls@uu.net; Wed, 25 Apr 2001 14:33:28 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmhu18802 for ; Wed, 25 Apr 2001 18:31:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmhu27403 for ; Wed, 25 Apr 2001 18:31:38 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmhu01129 for ; Wed, 25 Apr 2001 18:31:37 GMT Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3PIVZL09112; Wed, 25 Apr 2001 11:31:35 -0700 (PDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f3PIVK103393; Wed, 25 Apr 2001 11:31:20 -0700 (PDT) Received: from chsharp-w2k.cisco.com (rtp-vpn-150.cisco.com [10.82.192.150]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA14090; Wed, 25 Apr 2001 11:31:14 -0700 (PDT) Message-Id: <4.3.2.7.2.20010425141302.01e4acd0@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Apr 2001 14:31:04 -0400 To: kevin_santamaria@globalcrossing.com From: Chip Sharp Subject: Re: VoMPLS Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Recently the MPLS Forum have submitted a lot of their VoMPLS work to the upcoming ITU SG13 and SG11 meetings (in May) to be the basis of an ITU recommendation. These documents were submitted to the last T1S1 meeting in the US. I believe a draft can be found here: ftp://ftp.t1.org/T1S1/T1S1.7/2001/1s171190.zip If you want to see all the MPLS-related contributions, go to the following web page and search on "MPLS". http://www.t1.org/filemgr/FileList.taf?Directory=t1s1%5Ct1s1.7%5C2001&ShowTitle=2001%20T1S1.7%20Files These will be discussed at the upcoming SG11 & SG13 meetings. "Kevin Santamaria" wrote in message news:<7E14AE1326DAD4118ED600A0C9E5CF6714B9AB.16026@fastdarth.linkusa.com>... > I apologize if this has been asked and answered before, but >can someone point me to any further work being done on VoMPLS after > > Thanks very much > Kevin > email: kevin_santamaria@globalcrossing.com > 319-298-1493 > <<...>> ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- From owner-mpls@UU.NET Wed Apr 25 14:35:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26164 for ; Wed, 25 Apr 2001 14:35:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhu09674; Wed, 25 Apr 2001 18:35:49 GMT Received: by mail-control.mail.uu.net id QQkmhu19052 for mpls-outgoing; Wed, 25 Apr 2001 18:35:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmhu19006 for ; Wed, 25 Apr 2001 18:34:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmhu03837 for ; Wed, 25 Apr 2001 18:34:11 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkmhu06425 for ; Wed, 25 Apr 2001 18:34:11 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 067F094006; Wed, 25 Apr 2001 14:34:06 -0400 (EDT) Message-ID: <3AE7189E.B1392F30@sandburst.com> Date: Wed, 25 Apr 2001 14:34:06 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: "'mpls@uu.net'" Subject: Re: Fragmentation in RFC-3032 References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6BEE@BBY1EXM01> <3AE6F782.2E3E7926@marconi.com> <3AE6F98D.67E4B0C3@sandburst.com> <3AE711FF.1A51F0B5@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Correct me if I'm wrong (or feel free to correct me if I'm right ... again), but ATM switches switching ATM cells have no way to know if an IP packet that extends over multiple cells is "too long". I believe this determination would be made by that ATM switch saddled with SAR responsibility. If that is the case, why would that ATM switch be intrinsically in- capable of fragmenting IP packets? -- Eric Gray You wrote: > Eric Gray wrote: > > > > In addition to what Jack says below, the intent is to specifically > > allow implementations to silently discard packets it might otherwise > > be expected to fragment. > > More specifically, some hardware (especially legacy ATM hardware) may be > incapable of performing IP fragmentation. These same boxes may also be > incapable of generating ICMP messages. > > If a too-large packet arrives at such a box, it has no choice but to > drop it. > > Ideally, the LER that admits the packet into the LSP should check the > size and fragment (or generate ICMP if DF is set) to the LSP's MTU size > (that is, the mimimum MTU of all the routers along the LSP). But this > may not always be possible - not all signaling protocols report the > LSP's MTU to the ingress router. > > Hence the RFC, which allows LSRs to either fragment or discard too-large > packets that don't have DF set. > > -- David From owner-mpls@UU.NET Wed Apr 25 14:37:02 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26248 for ; Wed, 25 Apr 2001 14:37:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhu12415; Wed, 25 Apr 2001 18:36:58 GMT Received: by mail-control.mail.uu.net id QQkmhu19068 for mpls-outgoing; Wed, 25 Apr 2001 18:35:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmhu19007 for ; Wed, 25 Apr 2001 18:34:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhu04665 for ; Wed, 25 Apr 2001 18:34:27 GMT Received: from dtctxexchims01.ins.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.164.93.95]) id QQkmhu11888 for ; Wed, 25 Apr 2001 18:34:26 GMT Received: from kentyu (aventail.ins.com [208.164.93.91]) by dtctxexchims01.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JLMJMZG1; Wed, 25 Apr 2001 13:34:25 -0500 Message-ID: <009701c0cdb6$4efcb4a0$5b5da4d0@kentyu> Reply-To: "Kent Yu" From: "Kent Yu" To: , , "MP LS" Subject: Fw: MPLS Trafficdriven Date: Wed, 25 Apr 2001 14:34:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Niels, If you are asking traffic driven LSP, there are many docs you could find from the web. Some vendors, as Ashwin mentioned Lucent IP Navigator in his reply, already integrated this feature. It is hard to imagine a instantly traffic-driven network can be useful in the real world, one of the solutions probably is the LSR keeps track the taffic state of the whole network, we give it a configurable time syntax so it will compute and setup LSPs upon each calculation periodically. The network could be unstable and unpredictable, especially when you add the bypass and backup links. Probably we could get a decent optimization on the fly to some extend at some time, but this needs to verified and justified in the real world. As for the MPLS to the desktop, I am not sure it is necessary, IMHO, current IGPs are sufficient for enterprise users. Kent Yu Lucent Technologies Worldwide Services > ----- Original Message ----- > From: "MP LS" > To: ; > Sent: Wednesday, April 25, 2001 8:29 AM > Subject: MPLS Trafficdriven > > > > Hello all, > > > > I have a question. Is there any possibile way to create a fully dynamical > > Traffic driven MPLS network. So that when any packet arives at an LSR it > > will analyse the IP pakket ads a label in front of it with it combines to > a > > FEC and then just sent it to the Destination LSR? Just till now i only > > found that you have to ask for an LSP manualy and then the data can be > > transported over it. > > > > I hope someone can make this clear for me. > > > > Kind regards, > > > > Niels Sitters > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > From owner-mpls@UU.NET Wed Apr 25 14:52:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26767 for ; Wed, 25 Apr 2001 14:52:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhv13543; Wed, 25 Apr 2001 18:52:04 GMT Received: by mail-control.mail.uu.net id QQkmhv20423 for mpls-outgoing; Wed, 25 Apr 2001 18:51:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmhv20416 for ; Wed, 25 Apr 2001 18:51:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmhv20801 for ; Wed, 25 Apr 2001 18:49:39 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmhv12816 for ; Wed, 25 Apr 2001 18:49:38 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3PImNL19300 for ; Wed, 25 Apr 2001 11:48:23 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA24036 for mpls@uu.net; Wed, 25 Apr 2001 14:48:22 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmhv20037 for ; Wed, 25 Apr 2001 18:45:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhv28859 for ; Wed, 25 Apr 2001 18:45:16 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f221.law15.hotmail.com [64.4.23.221]) id QQkmhv24314 for ; Wed, 25 Apr 2001 18:45:16 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Apr 2001 11:45:15 -0700 Received: from 65.112.106.16 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 25 Apr 2001 18:45:15 GMT X-Originating-IP: [65.112.106.16] From: "John Wysocki" To: mpls@UU.NET Subject: draft-katz-yeung-ospf-traffic-04 Date: Wed, 25 Apr 2001 18:45:15 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Apr 2001 18:45:15.0877 (UTC) FILETIME=[DE4E8150:01C0CDB7] Sender: owner-mpls@UU.NET Precedence: bulk In this draft 2.4.2 Link TLV has sub-TLV 8 - Unreserved bandwidth (32 octets). 2.5.8 says Each value will be less than or equal to the maximum reservable bandwidth. It specifies not yet reserved BW at each of the eight priority levels. Does this mean each 4 octets (32/8 = 4) will represent unreserved bandwith for a priority? What does it represent? 2^4 = 16 values, but how do you use it? Does anyone know? Thanks. John _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Apr 25 15:32:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28208 for ; Wed, 25 Apr 2001 15:32:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhy25487; Wed, 25 Apr 2001 19:31:53 GMT Received: by mail-control.mail.uu.net id QQkmhy13594 for mpls-outgoing; Wed, 25 Apr 2001 19:31:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmhy13574 for ; Wed, 25 Apr 2001 19:31:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmhy11927 for ; Wed, 25 Apr 2001 19:31:00 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmhy18043 for ; Wed, 25 Apr 2001 19:30:59 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3PJV1L21103 for ; Wed, 25 Apr 2001 12:31:01 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA24255 for mpls@uu.net; Wed, 25 Apr 2001 15:30:55 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmhv20037 for ; Wed, 25 Apr 2001 18:45:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhv28859 for ; Wed, 25 Apr 2001 18:45:16 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f221.law15.hotmail.com [64.4.23.221]) id QQkmhv24314 for ; Wed, 25 Apr 2001 18:45:16 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Apr 2001 11:45:15 -0700 Received: from 65.112.106.16 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 25 Apr 2001 18:45:15 GMT X-Originating-IP: [65.112.106.16] From: "John Wysocki" To: mpls@UU.NET Subject: draft-katz-yeung-ospf-traffic-04 Date: Wed, 25 Apr 2001 18:45:15 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Apr 2001 18:45:15.0877 (UTC) FILETIME=[DE4E8150:01C0CDB7] Sender: owner-mpls@UU.NET Precedence: bulk In this draft 2.4.2 Link TLV has sub-TLV 8 - Unreserved bandwidth (32 octets). 2.5.8 says Each value will be less than or equal to the maximum reservable bandwidth. It specifies not yet reserved BW at each of the eight priority levels. Does this mean each 4 octets (32/8 = 4) will represent unreserved bandwith for a priority? What does it represent? 2^4 = 16 values, but how do you use it? Does anyone know? Thanks. John _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Apr 25 15:34:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28284 for ; Wed, 25 Apr 2001 15:33:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmhy22172; Wed, 25 Apr 2001 19:33:54 GMT Received: by mail-control.mail.uu.net id QQkmhy13750 for mpls-outgoing; Wed, 25 Apr 2001 19:32:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmhy13714 for ; Wed, 25 Apr 2001 19:32:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhy27842 for ; Wed, 25 Apr 2001 19:31:23 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmhy16902 for ; Wed, 25 Apr 2001 19:31:21 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3PJVML21413 for ; Wed, 25 Apr 2001 12:31:23 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA24260 for mpls@uu.net; Wed, 25 Apr 2001 15:31:17 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmhx11271 for ; Wed, 25 Apr 2001 19:19:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmhx25637 for ; Wed, 25 Apr 2001 19:19:09 GMT Received: from caesar.appiancom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.appiancom.com [146.115.35.70]) id QQkmhx02830 for ; Wed, 25 Apr 2001 19:19:09 GMT Received: by CAESAR with Internet Mail Service (5.5.2448.0) id <2THCAX8Q>; Wed, 25 Apr 2001 15:19:09 -0400 Message-ID: From: Ashwin Moranganti To: "'Javier Antich'" , "Marinzulich, Matias" , "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com Subject: RE: MPLS Trafficdriven Date: Wed, 25 Apr 2001 15:19:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDBC.99B0D002" 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_01C0CDBC.99B0D002 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "traffic driven" models are not for the core internet. But there are some applications in the VOIP networks which can use this feature. Ashwin -----Original Message----- From: Javier Antich [mailto:javier.antich@telindus.es] Sent: Wednesday, April 25, 2001 2:29 PM To: Marinzulich, Matias; 'Ashwin Moranganti'; 'MP LS'; MPLS@UU.NET; mpls-ops@mplsrc.com Subject: RE: MPLS Trafficdriven Well, that "on demand" does not mean usually "when traffic arrives", = but "when I get an entry in my routing table for that destination". However = it could be the first meaning. I am not sure whether traffic driven models would scale in the core of Internet.=20 Javier. ^ ^ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dooo=3D=3D=3D=3D(.)v(.)=3D=3D=3D= =3Dooo=3D=3D=3D=3D=3D Javier Antich Romaguera Network Consultant ------------------------------------------------------------------------= --- TELINDUS=20 Pza. Ciudad de Viena, 6-2=BA 28040 Madrid=20 ------------------------------------------------------------------------= --- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 ------------------------------------------------------------------------= --- For more information about our products and services, please visit our website http://www.telindus.com ------------------------------------------------------------------------= --- Full connectivity & mobility =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dooo0=3D=3D=3D0ooo=3D= =3D=3D=3D=3D=3D=3D=3D > -----Mensaje original----- > De: Marinzulich, Matias [SMTP:Matias.Marinzulich@comsat.com.ar] > Enviado el: mi=E9rcoles 25 de abril de 2001 19:58 > Para: 'Ashwin Moranganti'; 'MP LS'; MPLS@UU.NET; mpls-ops@mplsrc.com > Asunto: RE: MPLS Trafficdriven >=20 > Hello all, as far I can see, all cell-mode MPLS implementations (that = is, > MPLS network constructed with ATM switches) use 'on demand' label > allocation. Since you have a very small place for save the label, the > allocation and distribution must be highly conservative. For stay = this > minimal, all LSP are created 'on demand' in this kind of networks. > In the other hand, MPLS networks based in routers can use 'on demand' = or > unsolicited label distribution. >=20 > Matias.- >=20 > > -----Mensaje original----- > > De: Ashwin Moranganti [SMTP:amoranganti@appiancom.com] > > Enviado el: Mi=E9rcoles, 25 de Abril de 2001 10:34 a.m. > > Para: 'MP LS'; MPLS@uu.net; mpls-ops@mplsrc.com > > Asunto: RE: MPLS Trafficdriven > >=20 > > I have seen this as one of the feature in Lucent's IP Navigator = MPLS > > product.=20 > > The ports are configurable for this feature, and when a certain = traffic > > flow is detected LSPs are signalled for and the data is transmitted = and > > then LSPs are destroyed. Though this is not useful for all = applications. > > The key here is the signalling rate. If the rate is satisfactory, = it is > > useful for some applications > >=20 > > thankyou=20 > > Ashwin=20 > >=20 > > -----Original Message-----=20 > > From: MP LS [ ]=20 > > Sent: Wednesday, April 25, 2001 8:29 AM=20 > > To: MPLS@uu.net; mpls-ops@mplsrc.com=20 > > Subject: MPLS Trafficdriven=20 > >=20 > >=20 > > Hello all,=20 > >=20 > > I have a question. Is there any possibile way to create a fully > dynamical=20 > > Traffic driven MPLS network. So that when any packet arives at an = LSR it >=20 > > will analyse the IP pakket ads a label in front of it with it = combines > to > > a=20 > > FEC and then just sent it to the Destination LSR? Just till now i = only=20 > > found that you have to ask for an LSP manualy and then the data can = be=20 > > transported over it.=20 > >=20 > > I hope someone can make this clear for me.=20 > >=20 > > Kind regards,=20 > >=20 > > Niels Sitters=20 > > > = ________________________________________________________________________= _=20 > > Get Your Private, Free E-mail from MSN Hotmail at > > .=20 > >=20 > > -------=20 > > The MPLS-OPS Mailing List=20 > > Subscribe/Unsubscribe: =20 > > Archive: =20 > >=20 ------_=_NextPart_001_01C0CDBC.99B0D002 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS Trafficdriven

"traffic driven" models are not for the = core internet.
But there are some applications in the VOIP networks = which can use this feature.

Ashwin

-----Original Message-----
From: Javier Antich [mailto:javier.antich@telindus.= es]
Sent: Wednesday, April 25, 2001 2:29 PM
To: Marinzulich, Matias; 'Ashwin Moranganti'; 'MP = LS'; MPLS@UU.NET;
mpls-ops@mplsrc.com
Subject: RE: MPLS Trafficdriven


Well, that "on demand" does not mean = usually "when traffic arrives", but
"when I get an entry in my routing table for = that destination". However it
could be the first meaning. I am not sure whether = traffic driven models
would scale in the core of Internet.

Javier.
          &nb= sp;           &nb= sp;           &nb= sp;       ^   ^
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dooo=3D=3D=3D=3D(.)v(.= )=3D=3D=3D=3Dooo=3D=3D=3D=3D=3D
Javier Antich Romaguera
Network Consultant
---------------------------------------------------------------= ------------
TELINDUS
Pza. Ciudad de Viena, 6-2=BA
28040 Madrid
---------------------------------------------------------------= ------------
javier.antich@telindus.es
tel: +34 91 456 00 08
fax: +34 91 536 10 74
---------------------------------------------------------------= ------------
For more information about our products and = services,
please visit our website http://www.telindus.com
---------------------------------------------------------------= ------------
Full connectivity & mobility
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dooo0=3D=3D= =3D0ooo=3D=3D=3D=3D=3D=3D=3D=3D



> -----Mensaje original-----
> De:   Marinzulich, Matias = [SMTP:Matias.Marinzulich@comsat.com.ar]
> Enviado el:   mi=E9rcoles 25 de abril = de 2001 19:58
> Para: 'Ashwin Moranganti'; 'MP LS'; = MPLS@UU.NET; mpls-ops@mplsrc.com
> Asunto:       RE: = MPLS Trafficdriven
>
> Hello all, as far I can see, all cell-mode MPLS = implementations (that is,
> MPLS network constructed with ATM switches) use = 'on demand' label
> allocation. Since you have a very small place = for save the label, the
> allocation and distribution must be highly = conservative. For stay this
> minimal, all LSP are created 'on demand' in = this kind of networks.
> In the other hand, MPLS networks based in = routers can use 'on demand' or
> unsolicited label distribution.
>
> Matias.-
>
> > -----Mensaje original-----
> > De: Ashwin Moranganti = [SMTP:amoranganti@appiancom.com]
> > Enviado el: Mi=E9rcoles, 25 de Abril de = 2001 10:34 a.m.
> > Para:       = 'MP LS'; MPLS@uu.net; mpls-ops@mplsrc.com
> > Asunto:     RE: MPLS = Trafficdriven
> >
> > I have seen this as one of the feature in = Lucent's IP Navigator MPLS
> > product.
> > The ports are configurable for this = feature, and when a certain traffic
> > flow is detected LSPs are signalled for = and the data is transmitted and
> > then LSPs are destroyed. Though this is = not useful for all applications.
> > The key here is the signalling rate. If = the rate is satisfactory, it is
> > useful for some applications
> >
> > thankyou
> > Ashwin
> >
> > -----Original Message-----
> > From: MP LS [ <mailto:stagempls@hotmail.com&g= t;]
> > Sent: Wednesday, April 25, 2001 8:29 AM =
> > To: MPLS@uu.net; mpls-ops@mplsrc.com =
> > Subject: MPLS Trafficdriven
> >
> >
> > Hello all,
> >
> > I have a question. Is there any possibile = way to create a fully
> dynamical
> > Traffic driven MPLS network. So that when = any packet arives at an LSR it
>
> > will analyse the IP pakket ads a label in = front of it with it combines
> to
> > a
> > FEC and then just sent it to the = Destination LSR?  Just till now i only
> > found that you have to ask for an LSP = manualy and then the data can be
> > transported over it.
> >
> > I hope someone can make this clear for me. =
> >
> > Kind regards,
> >
> > Niels Sitters
> >
> = ________________________________________________________________________= _
> > Get Your Private, Free E-mail from MSN = Hotmail at
> > <http://www.hotmail.com>.
> >
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:  <http://www.mplsrc.com/mplsops.shtml>
> > Archive: <http://www.mplsrc.com/mpls-ops_archive.shtml> =
> >

------_=_NextPart_001_01C0CDBC.99B0D002-- From owner-mpls@UU.NET Wed Apr 25 16:03:59 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29419 for ; Wed, 25 Apr 2001 16:03:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmia29874; Wed, 25 Apr 2001 20:03:56 GMT Received: by mail-control.mail.uu.net id QQkmia23366 for mpls-outgoing; Wed, 25 Apr 2001 20:03:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmia22840 for ; Wed, 25 Apr 2001 20:03:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmia02359 for ; Wed, 25 Apr 2001 20:02:32 GMT Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQkmia23605 for ; Wed, 25 Apr 2001 20:02:31 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21) id <2X8CPFV2>; Wed, 25 Apr 2001 15:57:11 -0400 Message-ID: <87009604743AD411B1F600508BA0F95971BAA6@XOVER.dedham.mindspeed.com> From: "Saha, Sayandeb" To: mpls@UU.NET Subject: CR_LDP Label Set question. Date: Wed, 25 Apr 2001 15:57:00 -0400 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 Label set TLV in draft-ietf-mpls-generalized-cr-ldp-02.txt is described as follows. The format of a Label_Set is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| type=0x0905 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Label Type | Action | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel 1 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel N | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label Type: 8 bits Indicates the type and format of the labels carried in the TLV. Values match the TLV type of the appropriate Label TLV. How can a size of 8 bits for Label Type field suffice when clearly the tlv types are much bigger in size like 0x0905 which require 12 bits. Does this suggest the use of only the last octet of tlv_type in the Label Type field?? -sayan From owner-mpls@UU.NET Wed Apr 25 16:17:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29869 for ; Wed, 25 Apr 2001 16:17:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmib10890; Wed, 25 Apr 2001 20:17:46 GMT Received: by mail-control.mail.uu.net id QQkmib06542 for mpls-outgoing; Wed, 25 Apr 2001 20:17:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmib06523 for ; Wed, 25 Apr 2001 20:16:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmib04728 for ; Wed, 25 Apr 2001 20:15:59 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmib18479 for ; Wed, 25 Apr 2001 20:15:58 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA07896 for mpls@uu.net; Wed, 25 Apr 2001 16:15:57 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmib06347 for ; Wed, 25 Apr 2001 20:15:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmia00049 for ; Wed, 25 Apr 2001 20:14:28 GMT Received: from salamander.eu.fore.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: salamander.eu.fore.com [193.132.138.12]) id QQkmia28553 for ; Wed, 25 Apr 2001 20:14:26 GMT Received: from gbennett-pc (compuserve-45-93.pit.comms.marconi.com [169.144.45.93]) by salamander.eu.fore.com (8.9.1/8.9.1) with SMTP id VAA08752; Wed, 25 Apr 2001 21:13:43 +0100 (BST) Message-Id: <200104252013.VAA08752@salamander.eu.fore.com> X-Sender: gbennett@salamander.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 25 Apr 2001 22:15:45 +0100 To: "Marinzulich, Matias" , "'Ashwin Moranganti'" , "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com From: Geoff Bennett Subject: RE: MPLS Trafficdriven In-Reply-To: <89158E87E11BD511AFB6001083FD99AF4DDC@HALCON> 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 QAA29869 Hi Matias, I have to disagree with your conclusion here. There's no specific relationship between ATM/MPLS implementations and a requirement to operate with data-driven LSPs. You may be confusing this with MPOA, which was always data-driven, but in general was restricted to use in Enterprise networks due the the scalability issues that these microflow setups created. As you point out, the label size in the ATM encapsulation is smaller than the shim header (16 bits vs 20 bits), but since labels only have local scope (in this case the scope is the ends of the inter-LSR cable), then there is no real issue about "label exhaustion". Current MPLS implemetations can be: a: Control Driven (ie. LSPs are established by routing protocol information, and as a result cannot offer Traffic Engineering, but may be able to support "assisted VPN" capability). b: Manually established (this is the case for all current TE implementations) c: (At some undetermined point in the future) may be automatically established via policies and information generated by extended (constraint-based) routing protocols (eg. ISIS-TE or OSPF-TE). As far as I'm aware there are no data-driven implementations today for the simple reason that they don't scale beyond "Enterprise" networks, and because MPLS is actually intended to be a core SP technology. It makes sense to pursue the idea of data driven LSP setup, but it's essential to combine this approach with a flow aggregation mechanism if we expect to deploy such a technology in "large networks" (eg. a Service Provider). In theory the Ingress LSR could be given the capability to aggregate flows of information into a single LSP, but the details of how this could be done are generally clouded in marketing smoke and mirrors today. The issue is that IPv4 lacks either a flow label (which IPv6 has), or a session identifier (that ISO TP4 has) to provide an easy classification mechanism. The current "edge LSR" implementations are handicapped by these limitations. So how can they assign or aggregate traffic? They are normally limited to assignment on the basis of destination IP address (essentially useless in most cases), or by the use of the Port ID, or by some combination of these two. In other words, whatever criteria you can use to build a filter or ACL, you can use to assign individual packets to an existing LSP (or as a trigger mechanism to create a new LSP). Based on this "filter rule" limitation, the only application I can think of that has both a well-known Port ID, and that I'd like to classify at the Ingress LSR is Telnet (Port 23). Obviously I'd like to give Telnet priority as it's the major tool for network management, and these are the packets I want to keep getting through in times of network congestion. All the applications that really need to be classified (like VoIP with H.323 for instance) use dynamic port numbers. In fact there's nothing in an individual H.323 packet that would allow you to build such a filter rule. The edge LER actually has to have quite a bit of protocol in it to pick up packets like H.245, SIP, MGCP or whatever "flavour" of VoIP you're using. Cheers, Geoff At 14:58 25/04/01 -0300, Marinzulich, Matias wrote: >Hello all, as far I can see, all cell-mode MPLS implementations (that is, >MPLS network constructed with ATM switches) use 'on demand' label >allocation. Since you have a very small place for save the label, the >allocation and distribution must be highly conservative. For stay this >minimal, all LSP are created 'on demand' in this kind of networks. >In the other hand, MPLS networks based in routers can use 'on demand' or >unsolicited label distribution. > >Matias.- > >> -----Mensaje original----- >> De: Ashwin Moranganti [SMTP:amoranganti@appiancom.com] >> Enviado el: Miércoles, 25 de Abril de 2001 10:34 a.m. >> Para: 'MP LS'; MPLS@uu.net; mpls-ops@mplsrc.com >> Asunto: RE: MPLS Trafficdrive >> >> I have seen this as one of the feature in Lucent's IP Navigator MPLS >> product. >> The ports are configurable for this feature, and when a certain traffic >> flow is detected LSPs are signalled for and the data is transmitted and >> then LSPs are destroyed. Though this is not useful for all applications. >> The key here is the signalling rate. If the rate is satisfactory, it is >> useful for some applications >> >> thankyou >> Ashwin >> >> -----Original Message----- >> From: MP LS [ ] >> Sent: Wednesday, April 25, 2001 8:29 AM >> To: MPLS@uu.net; mpls-ops@mplsrc.com >> Subject: MPLS Trafficdriven >> >> >> Hello all, >> >> I have a question. Is there any possibile way to create a fully dynamical >> Traffic driven MPLS network. So that when any packet arives at an LSR it >> will analyse the IP pakket ads a label in front of it with it combines to >> a >> FEC and then just sent it to the Destination LSR? Just till now i only >> found that you have to ask for an LSP manualy and then the data can be >> transported over it. >> >> I hope someone can make this clear for me. >> >> Kind regards, >> >> Niels Sitters >> _________________________________________________________________________ >> Get Your Private, Free E-mail from MSN Hotmail at >> . >> >> ------- >> The MPLS-OPS Mailing List >> Subscribe/Unsubscribe: >> Archive: >> > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > ================================================================ Geoff Bennett Tel: (33) 497 21 43 62 Director of Technology, OCTO Fax: (33) 497 21 43 50 Marconi Gaia - Bat. E email: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ From owner-mpls@UU.NET Wed Apr 25 17:17:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01486 for ; Wed, 25 Apr 2001 17:17:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmif19973; Wed, 25 Apr 2001 21:17:06 GMT Received: by mail-control.mail.uu.net id QQkmif00719 for mpls-outgoing; Wed, 25 Apr 2001 21:16:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmif00701 for ; Wed, 25 Apr 2001 21:16:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmif14717 for ; Wed, 25 Apr 2001 21:16:11 GMT Received: from c2.ciena.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQkmif02088 for ; Wed, 25 Apr 2001 21:16:09 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id RAA15263; Wed, 25 Apr 2001 17:15:58 -0400 (EDT) Received: from wntasdexg01.asd.ciena.com(10.25.2.11) by c2.ciena.com via smap (V2.0) id xma015252; Wed, 25 Apr 01 17:15:46 -0400 Received: by wntasdexg01.asd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 17:14:58 -0400 Message-ID: <4D29EF232640D311A78C0008C75D8B9201181097@wntasdexg01.asd.ciena.com> From: "Hass, Barry" To: "'Geoff Bennett'" , "Marinzulich, Matias" , "'Ashwin Moranganti'" , "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com Subject: RE: MPLS Trafficdriven Date: Wed, 25 Apr 2001 17:14:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Geoff, Would it make sense to use the DSCP field for flow aggregation, perhaps in combination with the IP destination address? Barry > It makes sense to pursue the idea of data driven LSP setup, but it's > essential to combine this approach with a flow aggregation mechanism if we > expect to deploy such a technology in "large networks" (eg. a Service > Provider). In theory the Ingress LSR could be given the capability to > aggregate flows of information into a single LSP, but the details of how > this could be done are generally clouded in marketing smoke and mirrors > today. The issue is that IPv4 lacks either a flow label (which IPv6 has), > or a session identifier (that ISO TP4 has) to provide an easy > classification mechanism. The current "edge LSR" implementations are > handicapped by these limitations. So how can they assign or aggregate > traffic? They are normally limited to assignment on the basis of > destination IP address (essentially useless in most cases), or by the use > of the Port ID, or by some combination of these two. In other words, > whatever criteria you can use to build a filter or ACL, you can use to > assign individual packets to an existing LSP (or as a trigger mechanism to > create a new LSP). > From owner-mpls@UU.NET Wed Apr 25 17:43:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02096 for ; Wed, 25 Apr 2001 17:43:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmig26277; Wed, 25 Apr 2001 21:43:00 GMT Received: by mail-control.mail.uu.net id QQkmig03215 for mpls-outgoing; Wed, 25 Apr 2001 21:42:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmig03196 for ; Wed, 25 Apr 2001 21:42:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmig01546 for ; Wed, 25 Apr 2001 21:42:04 GMT Received: from longwood.cs.ucf.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1]) id QQkmig24336 for ; Wed, 25 Apr 2001 21:42:03 GMT Received: from iris.cs.ucf.edu (iris [132.170.108.55]) by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f3PLg9k23130 for ; Wed, 25 Apr 2001 17:42:09 -0400 (EDT) From: Arturo Nunez Received: (from artnpp@localhost) by iris.cs.ucf.edu (8.9.3/8.9.0) id RAA06751 for mpls@uu.net; Wed, 25 Apr 2001 17:40:33 -0400 (EDT) Message-Id: <200104252140.RAA06751@iris.cs.ucf.edu> Subject: MPLS SWITCH OVER LINUX ?? To: mpls@UU.NET Date: Wed, 25 Apr 2001 17:40:32 -0400 (EDT) X-Mailer: ELM [version 2.5 PL3] 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: Does anybody know about any free implemmentation of MPLS over Linux ?? As a matter of fact there is one for ATM. Any comments I will be glad to receive. Best Regards Arturo Nunez From owner-mpls@UU.NET Wed Apr 25 17:49:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02250 for ; Wed, 25 Apr 2001 17:49:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmih06024; Wed, 25 Apr 2001 21:49:51 GMT Received: by mail-control.mail.uu.net id QQkmih04283 for mpls-outgoing; Wed, 25 Apr 2001 21:48:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmih04258 for ; Wed, 25 Apr 2001 21:48:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmih02920 for ; Wed, 25 Apr 2001 21:47:01 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmih22868 for ; Wed, 25 Apr 2001 21:47:01 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA15423 for mpls@uu.net; Wed, 25 Apr 2001 17:47:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmih03949 for ; Wed, 25 Apr 2001 21:46:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmih14597 for ; Wed, 25 Apr 2001 21:46:07 GMT Received: from nero.doit.wisc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQkmih21860 for ; Wed, 25 Apr 2001 21:46:06 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id QAA32669; Wed, 25 Apr 2001 16:45:59 -0500 Date: Wed, 25 Apr 2001 16:45:58 -0500 From: "James R. Leu" To: Arturo Nunez Cc: mpls@UU.NET Subject: Re: MPLS SWITCH OVER LINUX ?? Message-ID: <20010425164558.B32614@doit.wisc.edu> Reply-To: jleu@mindspring.com References: <200104252140.RAA06751@iris.cs.ucf.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200104252140.RAA06751@iris.cs.ucf.edu>; from artnpp@cs.ucf.edu on Wed, Apr 25, 2001 at 05:40:32PM -0400 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk On Wed, Apr 25, 2001 at 05:40:32PM -0400, Arturo Nunez wrote: > Hello: > Does anybody know about any free implemmentation of MPLS over Linux ?? > As a matter of fact there is one for ATM. Check out http://mpls-linux.sourceforge.net/ > > Any comments I will be glad to receive. > > Best Regards > > Arturo Nunez -- James R. Leu From owner-mpls@UU.NET Wed Apr 25 18:18:18 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02766 for ; Wed, 25 Apr 2001 18:18:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmij16531; Wed, 25 Apr 2001 22:18:17 GMT Received: by mail-control.mail.uu.net id QQkmij24851 for mpls-outgoing; Wed, 25 Apr 2001 22:17:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmij24824 for ; Wed, 25 Apr 2001 22:17:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmij02877 for ; Wed, 25 Apr 2001 22:16:34 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmij13055 for ; Wed, 25 Apr 2001 22:16:33 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA18153 for mpls@uu.net; Wed, 25 Apr 2001 18:16:33 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmih05309 for ; Wed, 25 Apr 2001 21:57:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmih05651 for ; Wed, 25 Apr 2001 21:57:49 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkmih02428 for ; Wed, 25 Apr 2001 21:57:49 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02439; Wed, 25 Apr 2001 17:57:43 -0400 (EDT) Message-Id: <200104252157.RAA02439@ietf.org> To: IETF-Announce:; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: mpls@UU.NET From: The IESG Subject: Protocol Action: Constraint-Based LSP Setup using LDP to Proposed Standard Date: Wed, 25 Apr 2001 17:57:43 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the publication of the following Internet-Drafts: o Constraint-Based LSP Setup using LDP as a Proposed Standard. o Applicability Statement for CR-LDP as an Informational RFC o LSP Modification Using CR-LDP as a Proposed Standard. o LDP State Machine as an Informational RFC. These documents are the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are David Oran and Rob Coltun. Technical Summary Constraint-based routing (CR) is a mechanism used to meet Traffic Engineering requirements. These requirements may be met by extending LDP for support of constraint-based routed label switched paths (CR-LSPs). These specifications propose an end-to-end setup mechanism of a constraint-based routed LSP (CR-LSP) initiated by the ingress LSR. They define extensions to LDP and specifies mechanisms to provide means for reservation of resources for new CR-LSPs, modification of the resources for existing CR-LSPs (including re-routing) and the MIB for LDP. Working Group Summary The working group supported this document and no issues were raised during IETF Last-Call. Protocol Quality Rob Coltun has reviewed the spec for the IESG. There are currently multiple implementations of these specifications. From owner-mpls@UU.NET Wed Apr 25 18:33:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03026 for ; Wed, 25 Apr 2001 18:33:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmik14211; Wed, 25 Apr 2001 22:33:47 GMT Received: by mail-control.mail.uu.net id QQkmik26724 for mpls-outgoing; Wed, 25 Apr 2001 22:33:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmik26709 for ; Wed, 25 Apr 2001 22:33:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmik03015 for ; Wed, 25 Apr 2001 22:32:27 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmik12698 for ; Wed, 25 Apr 2001 22:32:27 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA19552 for mpls@uu.net; Wed, 25 Apr 2001 18:32:27 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmij26266 for ; Wed, 25 Apr 2001 22:28:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmij21910 for ; Wed, 25 Apr 2001 22:27:59 GMT Received: from sj-msg-core-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQkmij29822 for ; Wed, 25 Apr 2001 22:27:59 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id OAA27827; Wed, 25 Apr 2001 14:59:36 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f3PM0d016883; Wed, 25 Apr 2001 15:00:40 -0700 (PDT) Message-ID: <3AE748A7.8905C073@cisco.com> Date: Wed, 25 Apr 2001 14:59:03 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: manoj juneja CC: mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Route Pinning Doubt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Manoj, One application of route pinning I know of being used is following: * Establishment of TE-LSPs with dynamic path options (ERO calculated on the headends with cspf) * Recording the routes from RROs (route pinning) * Setting explicit TE-LSPs with the recorded EROs. I don't know of any use of signalled "route pinning" as you are describing below. R. > manoj juneja wrote: > > Hi All, > Is anybody using Route Pinning in the MPLS network ? If yes, what > are the benefits of using route pinning ? > Is route pinning applicable once the CR-LSP gets established ? > > Following is my understanding regarding Route pinning : > > Please correct me if I am wrong. > > Once the LSP gets established and then afterwards if better nexthop > becomes available and route pinning is requested along the path, u don't > change the CR-LSP path (only the loosely routed portion of LSP). > > Is the nexthop change procedure same for both LSP and CR-LSP ? > > Is there any option in LDP that once a LSP gets established and subsequent > better next-hop changes should be rejected (like route pinning in LDP > inaddition to CR-LDP)? > > Thanks, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Apr 25 18:37:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03085 for ; Wed, 25 Apr 2001 18:37:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmik18270; Wed, 25 Apr 2001 22:37:15 GMT Received: by mail-control.mail.uu.net id QQkmik27043 for mpls-outgoing; Wed, 25 Apr 2001 22:36:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmik27023 for ; Wed, 25 Apr 2001 22:36:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmik16323 for ; Wed, 25 Apr 2001 22:35:54 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmik21456 for ; Wed, 25 Apr 2001 22:35:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA19829 for mpls@uu.net; Wed, 25 Apr 2001 18:35:53 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmik26909 for ; Wed, 25 Apr 2001 22:35:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmik04604 for ; Wed, 25 Apr 2001 22:33:08 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f219.law10.hotmail.com [64.4.15.219]) id QQkmik13456 for ; Wed, 25 Apr 2001 22:33:08 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Apr 2001 15:33:07 -0700 Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 25 Apr 2001 22:33:07 GMT X-Originating-IP: [38.204.3.195] From: "manoj juneja" To: loa.andersson@utfors.se, p_sharma@trillium.com Cc: dwfedyk@nortelnetworks.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" Date: Wed, 25 Apr 2001 15:33:07 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Apr 2001 22:33:07.0512 (UTC) FILETIME=[B33C7380:01C0CDD7] Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQkmik18270 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA03085 Hi Don/Loa/Prem, Today we got the mail of making the draft "draft-ietf-mpls-crlsp -modify-03.txt" as a proposed standard. Should not you people feel that the restriction that modification of CR-LSP is only applicable to strictly routed hops should be addressed in the draft prior to making it as a RFC. I think this is a major restriction and should be addressed in the scope of the document. Regards, manoj. >From: "Loa Andersson" >To: "Sharma Prem" >CC: 'Don Fedyk' , manoj juneja >, mpls@UU.NET >Subject: Re: Valid Race Condition related to draft "draft-ietf-mpls-crlsp >-modify-03.txt" >Date: Mon, 23 Apr 2001 13:05:32 +0200 > >All, > >some comments to this discussion. > >I agree with Perm, if the draft is only applicable to LSPs where every >node is explicitly routed, that needs to be explicitly state early in >the draft. Also know from some offsets communication that "the >explicit routed only" approach is under some debate. > >Given that we can have LSPs where other constraints are important, I >would >be interested in combining dynamic routed CR-LSPs (routed on other >constraints than explicit nodes), with one explicitly routed node, >e.g. for performance measurements. I would also be interested to be >able to make those measurements at different places, a reason for >changing (modifying) the LSP, drop one explicitly routed node and >replace with another. > >I'm not concerned over have the loosely routed part of an LSP staying >alive of the strictly routed part goes away :-), but given that I can >retry if the a node in the loosely routed part of the LSP NAK a >request, >but not if an explicitly routed node does it. Need to distinguish >between >cases. Of course this is not a problem if explicit routed only. > >It is not only CR-LDP that sets up CR-LSPs, it is much more common to >do so by RSVP-TE, hence my reflection on the need to something for >RSVP-TE. > >/Loa > > > >-- >Loa Andersson >Chief Architect, >Utfors Research, Architecture and Future Lab (URAX) >Utfors AB >Råsundavägen 12 >Box 525, 169 29 Solna >Office +46 8 5270 2000 >Office direct +46 8 5270 5038 >Mobile +46 70 848 5038 >Email loa.andersson@utfors.se >WWW www.utfors.se _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Apr 25 19:35:10 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03927 for ; Wed, 25 Apr 2001 19:35:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmio01346; Wed, 25 Apr 2001 23:35:04 GMT Received: by mail-control.mail.uu.net id QQkmio19432 for mpls-outgoing; Wed, 25 Apr 2001 23:34:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmio19420 for ; Wed, 25 Apr 2001 23:34:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmio23039 for ; Wed, 25 Apr 2001 23:34:16 GMT Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQkmio00225 for ; Wed, 25 Apr 2001 23:34:16 GMT Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id TAA18365; Wed, 25 Apr 2001 19:34:13 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Wed, 25 Apr 2001 19:34:14 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 19:34:16 -0400 Message-ID: From: "Don Fedyk" To: manoj juneja , loa.andersson@utfors.se, p_sharma@trillium.com Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt" Date: Wed, 25 Apr 2001 19:34:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDE0.3ACBFF70" 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_01C0CDE0.3ACBFF70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Manoj This thread has gone full circle. Just because the draft is=20 most useful for CR strictly routed LSPs does not mean it is=20 harmful to loose LSPs.=20 If it were up to me I would put a question any wide spread use of loose LSPs. These LSPs are operational headaches. The more=20 you add the more provisioning you have to change should=20 your network change. One of the benefits of the modify draft=20 was to make CR strictly routed LSPs less of a an operational=20 headache and an even better option than loose LSPs. But the question is the draft only applicable to Strict LSPs? My answer is no in fact if you wanted to modify the explicit=20 part of a strictly LSP this feature would work and must work without any race conditions (which was the original objection).=20 Any implementation of the modify will have a knob to turn on=20 or off the modify so if you don't want the feature don't use it. Don > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Wednesday, April 25, 2001 6:33 PM > To: loa.andersson@utfors.se; p_sharma@trillium.com > Cc: Fedyk, Don [BL60:2868:EXCH]; mpls@UU.NET; ccamp@ops.ietf.org > Subject: Re: Valid Race Condition related to draft > "draft-ietf-mpls-crlsp -modify-03.txt" >=20 >=20 > Hi Don/Loa/Prem, >=20 > Today we got the mail of making the draft=20 > "draft-ietf-mpls-crlsp=20 > -modify-03.txt" as a proposed standard. Should not you people=20 > feel that the=20 > restriction that modification of CR-LSP is only applicable to=20 > strictly=20 > routed hops should be addressed in the draft prior to making=20 > it as a RFC. I=20 > think this is a major restriction and should be addressed in=20 > the scope of=20 > the document. >=20 > Regards, > manoj. >=20 >=20 >=20 >=20 > >From: "Loa Andersson" > >To: "Sharma Prem" > >CC: 'Don Fedyk' , manoj juneja=20 > >, mpls@UU.NET > >Subject: Re: Valid Race Condition related to draft=20 > "draft-ietf-mpls-crlsp=20 > >-modify-03.txt" > >Date: Mon, 23 Apr 2001 13:05:32 +0200 > > > >All, > > > >some comments to this discussion. > > > >I agree with Perm, if the draft is only applicable to LSPs=20 > where every > >node is explicitly routed, that needs to be explicitly state early = in > >the draft. Also know from some offsets communication that "the > >explicit routed only" approach is under some debate. > > > >Given that we can have LSPs where other constraints are important, I > >would > >be interested in combining dynamic routed CR-LSPs (routed on other > >constraints than explicit nodes), with one explicitly routed node, > >e.g. for performance measurements. I would also be interested to be > >able to make those measurements at different places, a reason for > >changing (modifying) the LSP, drop one explicitly routed node and > >replace with another. > > > >I'm not concerned over have the loosely routed part of an LSP = staying > >alive of the strictly routed part goes away :-), but given that I = can > >retry if the a node in the loosely routed part of the LSP NAK a > >request, > >but not if an explicitly routed node does it. Need to distinguish > >between > >cases. Of course this is not a problem if explicit routed only. > > > >It is not only CR-LDP that sets up CR-LSPs, it is much more common = to > >do so by RSVP-TE, hence my reflection on the need to something for > >RSVP-TE. > > > >/Loa > > > > > > > >-- > >Loa Andersson > >Chief Architect, > >Utfors Research, Architecture and Future Lab (URAX) > >Utfors AB > >R=E5sundav=E4gen 12 > >Box 525, 169 29 Solna > >Office +46 8 5270 2000 > >Office direct +46 8 5270 5038 > >Mobile +46 70 848 5038 > >Email loa.andersson@utfors.se > >WWW www.utfors.se >=20 > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com >=20 >=20 >=20 ------_=_NextPart_001_01C0CDE0.3ACBFF70 Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkmio01346 Content-Transfer-Encoding: quoted-printable RE: Valid Race Condition related to draft "draft-ietf-mpls-cr= lsp -modify-03.txt"

Manoj

This thread has gone full circle. Just because the draf= t is
most useful for CR strictly routed LSPs does not mean = it is
harmful to loose LSPs.
If it were up to me I would put a question any wide sp= read use of
loose LSPs. These LSPs are operational headaches. The = more
you add the more provisioning you have to change shoul= d
your network change. One of the benefits of the modify= draft
was to make CR strictly routed LSPs less of a an opera= tional
headache and an even better option than loose LSPs.
But the question is the draft only applicable to Stric= t LSPs?
My answer is no in fact if you wanted to modify the ex= plicit
part of a strictly LSP this feature would work and mus= t work without
any race conditions (which was the original objection)= .

Any implementation of the modify will have a knob to tu= rn on
or off the modify so if you don't want the feature don= 't use it.

Don




> -----Original Message-----
> From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
> Sent: Wednesday, April 25, 2001 6:33 PM
> To: loa.andersson@utfors.se; p_sharma@trillium.co= m
> Cc: Fedyk, Don [BL60:2868:EXCH]; mpls@UU.NET; cca= mp@ops.ietf.org
> Subject: Re: Valid Race Condition related to draf= t
> "draft-ietf-mpls-crlsp -modify-03.txt"<= /FONT>
>
>
> Hi Don/Loa/Prem,
>
>        Today w= e got the mail of making the draft
> "draft-ietf-mpls-crlsp
> -modify-03.txt" as a proposed standard. Shou= ld not you people
> feel that the
> restriction that modification of CR-LSP is only a= pplicable to
> strictly
> routed hops should be addressed in the draft prio= r to making
> it as a RFC. I
> think this is a major restriction and should be a= ddressed in
> the scope of
> the document.
>
> Regards,
> manoj.
>
>
>
>
> >From: "Loa Andersson" <loa.ander= sson@utfors.se>
> >To: "Sharma Prem" <p_sharma@tril= lium.com>
> >CC: 'Don Fedyk' <dwfedyk@nortelnetworks.co= m>,  manoj juneja
> ><manojkumarjuneja@hotmail.com>, mpls@UU= .NET
> >Subject: Re: Valid Race Condition related to = draft
> "draft-ietf-mpls-crlsp
> >-modify-03.txt"
> >Date: Mon, 23 Apr 2001 13:05:32 +0200
> >
> >All,
> >
> >some comments to this discussion.
> >
> >I agree with Perm, if the draft is only appli= cable to LSPs
> where every
> >node is explicitly routed, that needs to be e= xplicitly state early in
> >the draft. Also know from some offsets commun= ication that "the
> >explicit routed only" approach  is = under some debate.
> >
> >Given that we can have LSPs where other const= raints are important, I
> >would
> >be interested in combining dynamic routed CR-= LSPs (routed on other
> >constraints than explicit nodes), with one ex= plicitly routed node,
> >e.g. for performance measurements. I would al= so be interested to be
> >able to make those  measurements at diff= erent places, a reason for
> >changing (modifying) the LSP, drop one explic= itly routed node and
> >replace with another.
> >
> >I'm not concerned over have the loosely route= d part of an LSP staying
> >alive of the strictly routed part goes away := -), but given that I can
> >retry if the a node in the loosely routed par= t of the LSP NAK a
> >request,
> >but not if an explicitly routed node does it.= Need to distinguish
> >between
> >cases. Of course this is not a problem if exp= licit routed only.
> >
> >It is not only CR-LDP that sets up CR-LSPs, i= t is much more common to
> >do so by RSVP-TE, hence my reflection on the = need to something for
> >RSVP-TE.
> >
> >/Loa
> >
> >
> >
> >--
> >Loa Andersson
> >Chief Architect,
> >Utfors Research, Architecture and Future Lab = (URAX)
> >Utfors AB
> >R=E5sundav=E4gen 12
> >Box 525, 169 29 Solna
> >Office      &nb= sp;   +46 8 5270 2000
> >Office direct   +46 8 5270 5038
> >Mobile      &nb= sp;   +46 70 848 5038
> >Email      &nbs= p;    loa.andersson@utfors.se
> >WWW       =       www.utfors.se
>
> _________________________________________________= ________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
>

------_=_NextPart_001_01C0CDE0.3ACBFF70-- From owner-mpls@UU.NET Wed Apr 25 20:03:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04372 for ; Wed, 25 Apr 2001 20:03:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmiq08400; Thu, 26 Apr 2001 00:02:45 GMT Received: by mail-control.mail.uu.net id QQkmiq01164 for mpls-outgoing; Thu, 26 Apr 2001 00:02:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmiq00770 for ; Thu, 26 Apr 2001 00:02:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmiq04619 for ; Thu, 26 Apr 2001 00:02:04 GMT Received: from web11402.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11402.mail.yahoo.com [216.136.131.232]) id QQkmiq08257 for ; Thu, 26 Apr 2001 00:02:03 GMT Message-ID: <20010426000203.94524.qmail@web11402.mail.yahoo.com> Received: from [65.194.140.2] by web11402.mail.yahoo.com; Wed, 25 Apr 2001 17:02:03 PDT Date: Wed, 25 Apr 2001 17:02:03 -0700 (PDT) From: Sanjay Wadhwa To: dhg@juniper.net, pingpan@juniper.net, arthi@juniper.net, kireeti@juniper.net Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi The re-route technique mentioned in this draft talks about using the same sender_template for each detour LSP and the primary LSP. It is also restricted to use FF style. How would overlapping detours be handled here ? R1 ---- R2 ---- R3 ------ R4 ----- R5 ----- R6 | o | o | o | o +------ R7 -o-o-o R8 oooooooo Lets say R2 and R3 are local repairers. R2-R7-R8-R4 (dashed path) provides detour for node R3. R3-R7-R8-R5 (bubbled path) provides a detour for R4. Both detours have R7-R8 as a common link. In this case you would want R8 to send different labels corresponding to the two detours to R7, since R8 needs to switch packets coming on the two detours out different interfaces (R8-R4 and R8-R5). If the sender_template is identical for the two detours how would R8 send two different labels to R7 (labels go with the filter-spec in RESVs. And I don't see the detour object being passed back in the RESV to possibly identify the detour) ? -Sanjay __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mpls@UU.NET Wed Apr 25 22:02:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06787 for ; Wed, 25 Apr 2001 22:02:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmiy23547; Thu, 26 Apr 2001 02:01:57 GMT Received: by mail-control.mail.uu.net id QQkmiy10933 for mpls-outgoing; Thu, 26 Apr 2001 02:01:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmiy10700 for ; Thu, 26 Apr 2001 02:01:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmiy08460 for ; Thu, 26 Apr 2001 02:00:40 GMT Received: from noya.bupt.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQkmiy26509 for ; Thu, 26 Apr 2001 02:00:39 GMT Received: from mars ([202.112.109.69]) by noya.bupt.edu.cn (8.11.3/8.10.1) with SMTP id f3Q20HR18032; Thu, 26 Apr 2001 10:00:18 +0800 (CST) Message-Id: <200104260200.f3Q20HR18032@noya.bupt.edu.cn> Date: Thu, 26 Apr 2001 10:4:40 +0800 From: Wang Yu To: Eric Gray , "mpls@UU.NET" Subject: Re: Re: question about Trigger Control Block? X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray, Hello, thank you very much! But the third question is still not clear. Next Hop Control Block = Next Hop Trigger Control Block ? Could you explain it? Thank you again. Wang Yu wangyu7707@263.net ----------------- 01-4-25 10:14:00 You wrote: >Yu, > > Hello. Please see my earlier answer on this subject at: > > http://cell.onecall.net/mhonarc/mpls/2001-Mar/msg00009.html > > If this does not clear up your questions below, let me know. > >Thanks! >-- >Eric Gray > >You wrote: > >> Hi, everybody, >> >> Here are some questions about MPLS LDP State Machine. >> Can someone give me explanation? >> Thanks in advance. >> >> 1. Trigger Control Block is discribed unclearly in "LDP State Machine"(draft-ietf-mpls-ldp-state-04.txt). >> (1)what is it on earth? >> (2)what is its function? >> (3)what information does it contain? >> (4)how does it operation? >> (5)how does it interwork with LSP control block? >> >> 2.Next Hop Control Block is discribed unclearly in "LDP State Machine"(draft-ietf-mpls-ldp-state-04.txt). >> I have the same questions about Next Hop Control Block as 1. >> >> 3.Next Hop Control Block = Next Hop Trigger Control Block ? >> >> In draft-ietf-mpls-ldp-state-04.txt, >> ------------------------------------------- >> 3.2.1 LSP Control Block >> >> For each LSP, an LSP Control Block is defined which may contain the >> following information: >> - Upstream Label Request ID (assigned by the upstream LSR), >> which is the 'Message Id' in the Label Request Message >> received from the upstream LSR. >> - Downstream Label Request ID (assigned by this LSR itself), >> which is 'Message Id' in the Label Request Message sent to >> the downstream LSR. >> - Upstream LDP Identifier >> - Downstream LDP Identifier >> - State >> - FEC >> - Upstream Label (assigned by this LSR) >> - Downstream Label (assigned by the downstream LSR) >> - Trigger Control Block Pointer, (Only used at the ingress LSR >> of a LSP) that points to the control block that triggers >> setting up this LSP or tearing down this LSP. >> - Next Hop Control Block Pointer, which points to the control >> ********************** >> block which is used for switching over to a better LSP. >> --------------------------------------------------------------------- >> Is Next Hop Control Block = Next Hop Trigger Control Block? >> >> Yu Wang >> wangyu7707@263.net From owner-mpls@UU.NET Wed Apr 25 22:10:57 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06908 for ; Wed, 25 Apr 2001 22:10:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmiy09972; Thu, 26 Apr 2001 02:10:54 GMT Received: by mail-control.mail.uu.net id QQkmiy24629 for mpls-outgoing; Thu, 26 Apr 2001 02:10:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmiy24624 for ; Thu, 26 Apr 2001 02:10:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmiy06922 for ; Thu, 26 Apr 2001 02:10:01 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmiy04920 for ; Thu, 26 Apr 2001 02:10:01 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA02006 for mpls@uu.net; Wed, 25 Apr 2001 22:10:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmiy24440 for ; Thu, 26 Apr 2001 02:09:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmiy24963 for ; Thu, 26 Apr 2001 02:08:58 GMT Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQkmiy07854 for ; Thu, 26 Apr 2001 02:08:57 GMT Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id WAA21926; Wed, 25 Apr 2001 22:08:54 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Wed, 25 Apr 2001 22:08:41 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 22:08:43 -0400 Message-ID: <03E3E0690542D211A1490000F80836F404B7469E@zcard00f.ca.nortel.com> From: "Gang Luo" To: "'mpls@UU.NET'" , "'wswen@ash.ece.ucdavis.edu'" Subject: RE: Constraint-based Shortest path algorithm Date: Wed, 25 Apr 2001 22:08:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDF5.D04B95F0" 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_01C0CDF5.D04B95F0 Content-Type: text/plain Hi Wushao, You may find our paper that proposed such an algorithm that does not try to find the path with minimum cost , but nearly minimun path (to avoid solving the NP-hard problem). http://members.home.net/gluo1/qospathcomp.pdf Therefore, the complexity of our algorihtm is n square, at the cost of missing the minimum cost path. For practical use, it looks ok to miss the minimum path if the nearly minimum path can be found. Best regards. Gang Luo. ====================================================== From: wushao wen Date: Fri, 20 Apr 2001 09:58:46 -0700 X-Apparently-From: Wswen99@aol.com X-Sender: wswen@ash.ece.ucdavis.edu Hello, In the traffic engineering, we need to calculate the constraint-based shortest path for a FEC. Is there any mature and efficient algorithm to do the calculation? Let's said that we have two parameter for each link (cost, and delay), how can we calculate the shortest path under end-to-end delay constraint (As I know, this is NP hard problem, right)? If anybody have implemented some algorithms on this, please let me know. Thanks! Wushao Prev by Date: LSP Failure Notification Next by Date: ATM-LSR do they use OSPF/IS-IS or PNNI?? Prev by thread: VoMPLS Next by thread: Question about Label allocation in RSVP-TE Index(es): Date Thread ------_=_NextPart_001_01C0CDF5.D04B95F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Constraint-based Shortest path algorithm

Hi Wushao,

You may find our paper that proposed = such an algorithm that does not try to
find the path with minimum cost , but = nearly minimun path (to avoid solving the NP-hard problem).

http://members.home.net/gluo1/qospathcomp.pdf

Therefore, the complexity of our = algorihtm is n square, at the cost of
missing the minimum cost path. For = practical use, it looks ok to miss the minimum path
if the nearly minimum path can be = found.
Best regards.
Gang Luo.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
     From: wushao = wen <wswen@ece.ucdavis.edu>
     Date: Fri, = 20 Apr 2001 09:58:46 -0700
     = X-Apparently-From: Wswen99@aol.com
     X-Sender: = wswen@ash.ece.ucdavis.edu


Hello,
        In the = traffic engineering, we need to calculate the
constraint-based shortest path for a = FEC. Is there any mature and efficient
algorithm to do the calculation? = Let's said that we have two parameter for
each link (cost, and delay), how can = we calculate the shortest path under
end-to-end delay constraint (As I = know, this is NP hard problem, right)?
       = If anybody have implemented some  algorithms on this, please let = me
know.
       = Thanks!


Wushao



     Prev by Date: = LSP Failure Notification
     Next by = Date: ATM-LSR do they use OSPF/IS-IS or PNNI??
     Prev by = thread: VoMPLS
     Next by = thread: Question about Label allocation in RSVP-TE
     Index(es): =
          = Date
          = Thread

------_=_NextPart_001_01C0CDF5.D04B95F0-- From owner-mpls@UU.NET Wed Apr 25 22:12:33 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06980 for ; Wed, 25 Apr 2001 22:12:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmiy08465; Thu, 26 Apr 2001 02:12:31 GMT Received: by mail-control.mail.uu.net id QQkmiy24818 for mpls-outgoing; Thu, 26 Apr 2001 02:11:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmiy24790 for ; Thu, 26 Apr 2001 02:11:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmiy00739 for ; Thu, 26 Apr 2001 02:11:27 GMT Received: from web11407.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11407.mail.yahoo.com [216.136.131.237]) id QQkmiy11163 for ; Thu, 26 Apr 2001 02:11:26 GMT Message-ID: <20010426021126.20775.qmail@web11407.mail.yahoo.com> Received: from [152.148.173.55] by web11407.mail.yahoo.com; Wed, 25 Apr 2001 19:11:26 PDT Date: Wed, 25 Apr 2001 19:11:26 -0700 (PDT) From: Sanjay Wadhwa Subject: fast re-route To: dhg@juniper.net, pingpan@juniper.net, arthi@juniper.net, kireeti@juniper.net Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Following question (from my previous posting) is regarding draft-gan-fast-reroute-00.txt. > > The re-route technique mentioned in this draft talks about using the > same sender_template for each detour LSP and the primary LSP. It is > also restricted to use FF style. How would overlapping detours be > handled here ? > > > R1 ---- R2 ---- R3 ------ R4 ----- R5 ----- R6 > | o | o > | o | o > +------ R7 -o-o-o R8 oooooooo > > Lets say R2 and R3 are local repairers. > R2-R7-R8-R4 (dashed path) provides detour for node R3. > R3-R7-R8-R5 (bubbled path) provides a detour for R4. > Both detours have R7-R8 as a common link. In this case you would want > R8 to send different labels corresponding to the two detours to R7, > since R8 needs to switch packets coming on the two detours out > different interfaces (R8-R4 and R8-R5). If the sender_template is > identical for the two detours how would R8 send two different labels > to R7 (labels go with the filter-spec in RESVs. And I don't see the > detour object being passed back in the RESV to possibly identify the > detour)? > > -Sanjay > > > __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mpls@UU.NET Wed Apr 25 22:30:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07352 for ; Wed, 25 Apr 2001 22:30:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmja03741; Thu, 26 Apr 2001 02:30:25 GMT Received: by mail-control.mail.uu.net id QQkmiz26518 for mpls-outgoing; Thu, 26 Apr 2001 02:29:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmiz26434 for ; Thu, 26 Apr 2001 02:29:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmiz00377 for ; Thu, 26 Apr 2001 02:27:39 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkmiz03400 for ; Thu, 26 Apr 2001 02:27:38 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA00438; Wed, 25 Apr 2001 19:27:38 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id TAA23583; Wed, 25 Apr 2001 19:27:38 -0700 (PDT) Date: Wed, 25 Apr 2001 19:27:38 -0700 (PDT) From: Kireeti Kompella Message-Id: <200104260227.TAA23583@kummer.juniper.net> To: jwysocki83@hotmail.com, mpls@UU.NET Subject: Re: draft-katz-yeung-ospf-traffic-04 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk > In this draft 2.4.2 Link TLV has sub-TLV 8 - Unreserved bandwidth (32 > octets). > > 2.5.8 says Each value will be less than or equal to the maximum reservable > bandwidth. It specifies not yet reserved BW at each of the eight priority > levels. > > Does this mean each 4 octets (32/8 = 4) will represent unreserved bandwith > for a priority? > What does it represent? 2^4 = 16 values, but how do you use it? The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels, in IEEE floating point format. Each value will be less than or equal to the maximum reservable bandwidth. The units are bytes per second. An octet is *8* bits. 4 octets is 32 bits. > Does anyone know? Excellent question. Kireeti. From owner-mpls@UU.NET Wed Apr 25 22:56:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08558 for ; Wed, 25 Apr 2001 22:56:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmjb13148; Thu, 26 Apr 2001 02:56:33 GMT Received: by mail-control.mail.uu.net id QQkmjb28908 for mpls-outgoing; Thu, 26 Apr 2001 02:55:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmjb28900 for ; Thu, 26 Apr 2001 02:55:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmjb07968 for ; Thu, 26 Apr 2001 02:55:45 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmjb07729 for ; Thu, 26 Apr 2001 02:55:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA05403 for mpls@uu.net; Wed, 25 Apr 2001 22:55:29 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmjb28851 for ; Thu, 26 Apr 2001 02:54:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmjb05517 for ; Thu, 26 Apr 2001 02:54:40 GMT Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQkmjb10683 for ; Thu, 26 Apr 2001 02:54:40 GMT Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id WAA22940; Wed, 25 Apr 2001 22:54:37 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Wed, 25 Apr 2001 22:54:39 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 22:54:41 -0400 Message-ID: <03E3E0690542D211A1490000F80836F404B746A1@zcard00f.ca.nortel.com> From: "Gang Luo" To: "'mpls@UU.NET'" Subject: Two signalling protocols (LDP & RSVP) Date: Wed, 25 Apr 2001 22:54:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDFC.3C761C40" 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_01C0CDFC.3C761C40 Content-Type: text/plain Hi, Is there any practical reason that the signalling protocols (LDP & RSVP) is supported on the same interface? Best regards. Gang Luo. =================================== Two signalling protocols (LDP & RSVP) From: "Peter Ashwood-Smith" Date: Sat, 21 Apr 2001 22:03:27 -0400 X-Orig: Title: RE: Two signalling protocols (LDP & RSVP) Yes & Yes. Peter Ashwood-Smith -----Original Message----- From: Anil Gunturu [SMTP:anilg@acc.com] Sent: Friday, April 20, 2001 2:12 PM To: mpls Subject: Two signalling protocols (LDP & RSVP) Hi, Is it possible to run both LDP and RSVP on the same interface? If it is possible can they be using the same label space? -Anil Prev by Date: VRF and overlapping addresses ... Next by Date: VRF and overlapping addresses ... Prev by thread: Two signalling protocols (LDP & RSVP) Next by thread: Two signalling protocols (LDP & RSVP) Index(es): Date Thread ------_=_NextPart_001_01C0CDFC.3C761C40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Two signalling protocols (LDP & RSVP)

Hi,

Is there any practical reason that the = signalling protocols (LDP & RSVP) is
supported on the same = interface?

Best regards.
Gang Luo.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Two signalling protocols (LDP & = RSVP)

     From: = "Peter Ashwood-Smith" <petera@nortelnetworks.com> =
     Date: Sat, = 21 Apr 2001 22:03:27 -0400
     X-Orig: = <petera@americasm01.nt.com>


Title: RE: Two signalling protocols = (LDP & RSVP)

Yes & Yes.

Peter Ashwood-Smith

     -----Original = Message-----
     = From:   Anil Gunturu [SMTP:anilg@acc.com]
     = Sent:   Friday, April 20, 2001 2:12 PM
     = To:     mpls
     = Subject:        Two signalling = protocols (LDP & RSVP)

     Hi,
     Is it = possible to run both LDP and RSVP on the same interface? If it is =
     possible can = they be using the same label space?
     -Anil =


     Prev by Date: = VRF and overlapping addresses ...
     Next by = Date: VRF and overlapping addresses ...
     Prev by = thread: Two signalling protocols (LDP & RSVP)
     Next by = thread: Two signalling protocols (LDP & RSVP)
     Index(es): =
          = Date
          = Thread


------_=_NextPart_001_01C0CDFC.3C761C40-- From owner-mpls@UU.NET Wed Apr 25 23:18:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08758 for ; Wed, 25 Apr 2001 23:18:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmjd21721; Thu, 26 Apr 2001 03:18:02 GMT Received: by mail-control.mail.uu.net id QQkmjd18405 for mpls-outgoing; Thu, 26 Apr 2001 03:17:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmjd18388 for ; Thu, 26 Apr 2001 03:17:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmjd03193 for ; Thu, 26 Apr 2001 03:17:04 GMT Received: from mail.krioukov.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cj114416-a.reston1.va.home.com [24.15.191.36]) id QQkmjd11821 for ; Thu, 26 Apr 2001 03:17:03 GMT Received: from DIMA1 (dhcp-host-017.cj114416-a.reston1.va.home.com [192.168.1.17]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id XAA27484; Wed, 25 Apr 2001 23:17:01 -0400 From: "Dmitri Krioukov" To: "wushao wen" Cc: Subject: RE: Constraint-based Shortest path algorithm Date: Wed, 25 Apr 2001 23:17:02 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <5.0.2.1.0.20010420095346.00aebc70@ash.ece.ucdavis.edu> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit My understanding is that the TE path computation draft is now expired, but the old version is still available from http://www.watersprings.org/links/mlr/id/draft-kompella-te-pathcomp-00.txt, for example. -- dima. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of wushao > wen > Sent: Friday, April 20, 2001 12:59 PM > To: mpls@UU.NET > Subject: Constraint-based Shortest path algorithm > > > Hello, > In the traffic engineering, we need to calculate the > constraint-based shortest path for a FEC. Is there any mature and > efficient > algorithm to do the calculation? Let's said that we have two > parameter for > each link (cost, and delay), how can we calculate the shortest path under > end-to-end delay constraint (As I know, this is NP hard problem, right)? > If anybody have implemented some algorithms on this, > please let me > know. > Thanks! > > > Wushao From owner-mpls@UU.NET Thu Apr 26 00:38:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09999 for ; Thu, 26 Apr 2001 00:38:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmji04579; Thu, 26 Apr 2001 04:38:12 GMT Received: by mail-control.mail.uu.net id QQkmji12412 for mpls-outgoing; Thu, 26 Apr 2001 04:37:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmji12401 for ; Thu, 26 Apr 2001 04:37:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmji28567 for ; Thu, 26 Apr 2001 04:36:30 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkmji02047 for ; Thu, 26 Apr 2001 04:36:27 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3Q4aBn11440; Thu, 26 Apr 2001 10:06:11 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A3A.0017DCBB ; Thu, 26 Apr 2001 09:50:38 +0530 X-Lotus-FromDomain: HSS To: Eric Gray cc: David Charlap , "'mpls@uu.net'" Message-ID: <65256A3A.0017DB4F.00@sandesh.hss.hns.com> Date: Thu, 26 Apr 2001 09:50:33 +0530 Subject: Re: Fragmentation in RFC-3032 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi! A few other points to ponder here;- 1. As David said that the switch may be incapable of detemination of IP characteristics. This leads us implicitly to the discussion held earlier that can there be MPLS nodes that are L3 unaware. My understanding is if we try and have a scenario where the MPLS nodes (LSRs) are L3 unaware we are doing away a lot of advantages MPLS gives us and not gaining much. To me a LSR unaware of L3 is basically a ATM switch which is un-neccesarily also running LDP. Correct me if I am wrong but this will only be benificial if we consider static LSP setup done manually which would be sacrificing a lot and gaining nothing, as that you can almost do with just a pure ATM setup. 2. The other thing as Eric pointed out here about ATM SAR cpability in my opinion SAR and IP Fragmentation are seperate functions and can and should not be clubbed as one. the reason is that for doing IP Fragmentation there are a whole lot of other things that need to be done (like IP header replication) rather than just chopping a packet into smaller ones. I think what Eric is proposing is very novel that we try and do some sort of Fragmentaions at L2 instead of L3 to deal with teh small MTU on the outgoing link. This will need a whole lot of thinking before we want to commit on this. 3. As has been said here earlier it should be a requirement put on the LERs to run Path MTU discovery in order to provide that this sort of case does not arise. What the RFC says is probably the "worst case action" than the "best possible one" ;o) regards sumit Eric Gray on 04/26/2001 12:04:06 AM To: David Charlap cc: "'mpls@uu.net'" (bcc: Sumit Chauhan/HSS) Subject: Re: Fragmentation in RFC-3032 David, Correct me if I'm wrong (or feel free to correct me if I'm right ... again), but ATM switches switching ATM cells have no way to know if an IP packet that extends over multiple cells is "too long". I believe this determination would be made by that ATM switch saddled with SAR responsibility. If that is the case, why would that ATM switch be intrinsically in- capable of fragmenting IP packets? -- Eric Gray You wrote: > Eric Gray wrote: > > > > In addition to what Jack says below, the intent is to specifically > > allow implementations to silently discard packets it might otherwise > > be expected to fragment. > > More specifically, some hardware (especially legacy ATM hardware) may be > incapable of performing IP fragmentation. These same boxes may also be > incapable of generating ICMP messages. > > If a too-large packet arrives at such a box, it has no choice but to > drop it. > > Ideally, the LER that admits the packet into the LSP should check the > size and fragment (or generate ICMP if DF is set) to the LSP's MTU size > (that is, the mimimum MTU of all the routers along the LSP). But this > may not always be possible - not all signaling protocols report the > LSP's MTU to the ingress router. > > Hence the RFC, which allows LSRs to either fragment or discard too-large > packets that don't have DF set. > > -- David From owner-mpls@UU.NET Thu Apr 26 01:33:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13551 for ; Thu, 26 Apr 2001 01:33:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmjm14207; Thu, 26 Apr 2001 05:33:25 GMT Received: by mail-control.mail.uu.net id QQkmjm04255 for mpls-outgoing; Thu, 26 Apr 2001 05:32:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmjm04242 for ; Thu, 26 Apr 2001 05:32:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmjm11748 for ; Thu, 26 Apr 2001 05:31:36 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmjm20516 for ; Thu, 26 Apr 2001 05:31:34 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id BAA13449 for mpls@uu.net; Thu, 26 Apr 2001 01:31:34 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmjm04172 for ; Thu, 26 Apr 2001 05:31:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmjm02693 for ; Thu, 26 Apr 2001 05:30:04 GMT Received: from salamander.eu.fore.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: salamander.eu.fore.com [193.132.138.12]) id QQkmjm18298 for ; Thu, 26 Apr 2001 05:30:03 GMT Received: from gbennett-pc (compuserve-45-111.pit.comms.marconi.com [169.144.45.111]) by salamander.eu.fore.com (8.9.1/8.9.1) with SMTP id GAA10398; Thu, 26 Apr 2001 06:29:11 +0100 (BST) Message-Id: <200104260529.GAA10398@salamander.eu.fore.com> X-Sender: gbennett@salamander.eu.fore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 26 Apr 2001 07:31:39 +0100 To: "Hass, Barry" , "Marinzulich, Matias" , "'Ashwin Moranganti'" , "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com From: Geoff Bennett Subject: RE: MPLS Trafficdriven In-Reply-To: <4D29EF232640D311A78C0008C75D8B9201181097@wntasdexg01.asd.c iena.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Barry, Yes it would make sense. But who sets the DSCP field? The "end user" can't be allowed to do this because DSCP is used to prioritise traffic, and everyone would set their traffic to high priority. The ideal thing would be to build proxy devices to insert the appropriate value according to a policy. IMHO the obvious location for such a proxy is the Ingress LSR. But the problem is how do you recognise the appropriate traffic types. Cheers, Geoff At 17:14 25/04/01 -0400, Hass, Barry wrote: >Hi Geoff, > >Would it make sense to use the DSCP field for flow aggregation, perhaps >in combination with the IP destination address? > >Barry > >> It makes sense to pursue the idea of data driven LSP setup, but it's >> essential to combine this approach with a flow aggregation mechanism if we >> expect to deploy such a technology in "large networks" (eg. a Service >> Provider). In theory the Ingress LSR could be given the capability to >> aggregate flows of information into a single LSP, but the details of how >> this could be done are generally clouded in marketing smoke and mirrors >> today. The issue is that IPv4 lacks either a flow label (which IPv6 has), >> or a session identifier (that ISO TP4 has) to provide an easy >> classification mechanism. The current "edge LSR" implementations are >> handicapped by these limitations. So how can they assign or aggregate >> traffic? They are normally limited to assignment on the basis of >> destination IP address (essentially useless in most cases), or by the use >> of the Port ID, or by some combination of these two. In other words, >> whatever criteria you can use to build a filter or ACL, you can use to >> assign individual packets to an existing LSP (or as a trigger mechanism to >> create a new LSP). >> > ================================================================ Geoff Bennett Tel: (33) 497 21 43 62 Director of Technology, OCTO Fax: (33) 497 21 43 50 Marconi Gaia - Bat. E email: geoff.bennett@marconi.com BP 123 06903 SOPHIA ANTIPOLIS FRANCE ================================================================ From owner-mpls@UU.NET Thu Apr 26 03:07:48 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25043 for ; Thu, 26 Apr 2001 03:07:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmjs21366; Thu, 26 Apr 2001 07:07:39 GMT Received: by mail-control.mail.uu.net id QQkmjs15747 for mpls-outgoing; Thu, 26 Apr 2001 07:07:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmjs15065 for ; Thu, 26 Apr 2001 07:06:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmjs19652 for ; Thu, 26 Apr 2001 07:06:44 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQkmjs19512 for ; Thu, 26 Apr 2001 07:06:42 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id MAA13919 for ; Thu, 26 Apr 2001 12:44:53 GMT Received: from Sonal.alc.wipinfo.soft.net ([192.168.220.119]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GCE1CT00.LX2 for ; Thu, 26 Apr 2001 12:42:29 +0530 Message-ID: <04eb01c0ce21$25651cc0$77dca8c0@Sonal.alc.wipinfo.soft.net> Reply-To: "venkat" From: "Venkat Dabbara" To: Subject: Merge capability in MPLS. Date: Thu, 26 Apr 2001 12:48:52 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hai , Is mergecapability defined in CRLDP ?? If yes , when does the scenario arise to do so ?? thanks and regards venkat From owner-mpls@UU.NET Thu Apr 26 03:49:01 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25738 for ; Thu, 26 Apr 2001 03:49:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmjv22421; Thu, 26 Apr 2001 07:48:59 GMT Received: by mail-control.mail.uu.net id QQkmjv20249 for mpls-outgoing; Thu, 26 Apr 2001 07:48:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmjv20226 for ; Thu, 26 Apr 2001 07:48:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmjv20456 for ; Thu, 26 Apr 2001 07:47:59 GMT Received: from noya.bupt.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQkmjv10308 for ; Thu, 26 Apr 2001 07:47:44 GMT Received: from vinus ([202.112.109.71]) by noya.bupt.edu.cn (8.11.3/8.10.1) with SMTP id f3Q7lZR27556 for ; Thu, 26 Apr 2001 15:47:36 +0800 (CST) Message-Id: <200104260747.f3Q7lZR27556@noya.bupt.edu.cn> Date: Fri, 27 Apr 2001 15:46:59 +0800 From: Felix Chang To: "mpls@UU.NET" Subject: What is the "LDP entity table" used for? X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi, In "draft-ietf-mpls-ldp-mib-07.txt", LDP entity is defined as "A table is used to configure potential LDP Sessions, where each row in the table initiates an LDP Session." When do we use the information in the LDP Entity Table? As I understand, each LDP_ID identifies a LDP Entity. Does that means we have to creat a LDP entity for each label space? Because the last bits in LDP_ID identify label space. If the LSR has two mpls-interfaces. One is ATM-based and the other is fr-based. They certainly use different label spaces. If LSR creat two LDP Entities for them respectly, can these two interface interwork? In the LDP Entity Table, some entries specify label distribution mode, such as mplsLdpEntityLabelDistributionMethod and mplsLdpEntityLabelRetentionMode. Are they different in different LDP Entity(i.e. different row in LDP Entity Table). Best regards! Felix Chang mplszhz@263.net From owner-mpls@UU.NET Thu Apr 26 05:27:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26759 for ; Thu, 26 Apr 2001 05:27:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmkb08990; Thu, 26 Apr 2001 09:27:01 GMT Received: by mail-control.mail.uu.net id QQkmkb03120 for mpls-outgoing; Thu, 26 Apr 2001 09:26:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmkb03112 for ; Thu, 26 Apr 2001 09:26:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmkb06186 for ; Thu, 26 Apr 2001 09:25:55 GMT Received: from mel.alcatel.fr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mel.alcatel.fr [212.208.74.132]) id QQkmkb27638 for ; Thu, 26 Apr 2001 09:25:50 GMT Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id KAA11470 for ; Thu, 26 Apr 2001 10:10:57 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id LAA01019 for ; Thu, 26 Apr 2001 11:19:28 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id LAA13339 for ; Thu, 26 Apr 2001 11:25:29 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.248.220]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id LAA06649 for ; Thu, 26 Apr 2001 11:25:35 +0200 (MET DST) Message-ID: <3AE7E9D0.1CBD2413@ms.alcatel.fr> Date: Thu, 26 Apr 2001 11:26:41 +0200 From: Victorianus Kapuangan X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: mpls@UU.NET Subject: TE using MPLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I am just new to this mailing list and also to the MPLS so sorry if someone has already posted the same questions. I have some questions concerning traffic engineering over MPLS (hope you won't be bored :-) ) 1) In case that we use the secondary LSP to back up the primary one, is there any mechanism to tell the ingress LSR for not using the secondary LSP while the primary one is still available ? In case that there is an outage and we are perforced to use the secondary LSP (using the fast reroute mechanism, for example) to forward the traffic, is there any mechanism to tell the ingress router to restart using the primary LSP when it becomes available ? 2)When we introduce the notion of LSP preemption to MPLS, what will happen to the traffic over the LSP being preempted ? Correct me if I'm wrong, can we consider that the LSP fails and then we apply fast reroute mechanism to start using the secondary LSP for that LSP ? 3)Is it possible to use both load balancing strategy and fast reroute mechanism as the complementary strategy for traffic engineering over MPLS since we will probably deal with a number of LSPs for the same FEC ? Thanks in advance and any response will be greatly appreciated. Best regards, ~victor From owner-mpls@UU.NET Thu Apr 26 06:56:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27497 for ; Thu, 26 Apr 2001 06:56:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmkh20478; Thu, 26 Apr 2001 10:56:32 GMT Received: by mail-control.mail.uu.net id QQkmkh27783 for mpls-outgoing; Thu, 26 Apr 2001 10:56:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmkh27758 for ; Thu, 26 Apr 2001 10:55:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmkh16809 for ; Thu, 26 Apr 2001 10:53:24 GMT From: mgoel@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkmkh02039 for ; Thu, 26 Apr 2001 10:53:18 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3QAsYk25091 for ; Thu, 26 Apr 2001 16:24:35 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A3A.003A815A ; Thu, 26 Apr 2001 16:09:02 +0530 X-Lotus-FromDomain: HSS To: mpls@UU.NET Message-ID: <65256A3A.003A7B5B.00@sandesh.hss.hns.com> Date: Thu, 26 Apr 2001 16:20:06 +0530 Subject: IP Source Route Option Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I have a small doubt. Let an unlabelled IP packet with IP source route option enabled comes in MPLS domain. Let the packet is assigned to a LSP (say numbered 1). While traversing the MPLS domain, packet will not go to the Network layer, thus the LSR in between the ingress LSR and egress LSR cannot insert their IP addresses in the datagram. So does MPLS supports IP source route option or it does not support it? Thanks Mohit Goel From owner-mpls@UU.NET Thu Apr 26 07:08:54 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27592 for ; Thu, 26 Apr 2001 07:08:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmki09585; Thu, 26 Apr 2001 11:08:51 GMT Received: by mail-control.mail.uu.net id QQkmki16092 for mpls-outgoing; Thu, 26 Apr 2001 11:08:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmki16076 for ; Thu, 26 Apr 2001 11:08:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmki29767 for ; Thu, 26 Apr 2001 11:07:50 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkmki21951 for ; Thu, 26 Apr 2001 11:07:46 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3QB93125722 for ; Thu, 26 Apr 2001 16:39:03 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A3A.003BD33E ; Thu, 26 Apr 2001 16:23:27 +0530 X-Lotus-FromDomain: HSS To: mgoel@hss.hns.com cc: mpls@UU.NET Message-ID: <65256A3A.003BD26D.00@sandesh.hss.hns.com> Date: Thu, 26 Apr 2001 16:23:23 +0530 Subject: Re: IP Source Route Option Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi mohit! Ideally this thing should be handled at the Ingress LER and he should translate the IP Source Route to MPLS sourse Route by defining a complete path for the packet (means asking the downstream routers for this). The question still hold weight as to what should be done if such a path does not exist at the time of the packet coming in or the path cannot be setup even when requested. My guess is that its best in both cases to discard the packet and send a normal ICMP packet back to source as is normally done. Going a bit deeper we generally use IP Source Routing for testing purposes and not as a means of data path reservation. Hence it might make sense to try and set up the LSP requested starting at the Ingress LER to the Egress LER if possible while holding on to the packet. This does complicate things but I guess if we have to do source routing we have to do this. ;o( regards sumit mgoel@hss.hns.com on 04/26/2001 04:20:06 PM To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: IP Source Route Option Hi All, I have a small doubt. Let an unlabelled IP packet with IP source route option enabled comes in MPLS domain. Let the packet is assigned to a LSP (say numbered 1). While traversing the MPLS domain, packet will not go to the Network layer, thus the LSR in between the ingress LSR and egress LSR cannot insert their IP addresses in the datagram. So does MPLS supports IP source route option or it does not support it? Thanks Mohit Goel From owner-mpls@UU.NET Thu Apr 26 07:26:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28417 for ; Thu, 26 Apr 2001 07:26:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmkj27566; Thu, 26 Apr 2001 11:25:59 GMT Received: by mail-control.mail.uu.net id QQkmkj17830 for mpls-outgoing; Thu, 26 Apr 2001 11:25:26 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmkj17817 for ; Thu, 26 Apr 2001 11:25:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmkj10602 for ; Thu, 26 Apr 2001 11:25:01 GMT From: mgoel@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkmkj15876 for ; Thu, 26 Apr 2001 11:24:58 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3QBQFv26313 for ; Thu, 26 Apr 2001 16:56:15 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A3A.003D6787 ; Thu, 26 Apr 2001 16:40:41 +0530 X-Lotus-FromDomain: HSS To: suchauhan@hss.hns.com cc: mpls@UU.NET Message-ID: <65256A3A.003D655E.00@sandesh.hss.hns.com> Date: Thu, 26 Apr 2001 16:54:42 +0530 Subject: Re: IP Source Route Option Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi Sumit ! But how mpls will handle the IP's Record route option which requires that each intermediate router should insert its IP address in the datagram. MPLS cannot drop that packet simply because record route option is enabled in it. Moreover if explicit routing is there then ingress router can insert the complete IP addresses of the intermediate LSRs in the datagram, but what will happen in the case of hop by hop LSP. Thanks Mohit Goel suchauhan@hss.hns.com on 04/26/2001 04:23:23 PM To: Mohit Goel/HSS@HSS cc: mpls@UU.NET Subject: Re: IP Source Route Option hi mohit! Ideally this thing should be handled at the Ingress LER and he should translate the IP Source Route to MPLS sourse Route by defining a complete path for the packet (means asking the downstream routers for this). The question still hold weight as to what should be done if such a path does not exist at the time of the packet coming in or the path cannot be setup even when requested. My guess is that its best in both cases to discard the packet and send a normal ICMP packet back to source as is normally done. Going a bit deeper we generally use IP Source Routing for testing purposes and not as a means of data path reservation. Hence it might make sense to try and set up the LSP requested starting at the Ingress LER to the Egress LER if possible while holding on to the packet. This does complicate things but I guess if we have to do source routing we have to do this. ;o( regards sumit mgoel@hss.hns.com on 04/26/2001 04:20:06 PM To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: IP Source Route Option Hi All, I have a small doubt. Let an unlabelled IP packet with IP source route option enabled comes in MPLS domain. Let the packet is assigned to a LSP (say numbered 1). While traversing the MPLS domain, packet will not go to the Network layer, thus the LSR in between the ingress LSR and egress LSR cannot insert their IP addresses in the datagram. So does MPLS supports IP source route option or it does not support it? Thanks Mohit Goel From owner-mpls@UU.NET Thu Apr 26 07:36:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28756 for ; Thu, 26 Apr 2001 07:36:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmkk02846; Thu, 26 Apr 2001 11:36:48 GMT Received: by mail-control.mail.uu.net id QQkmkk18649 for mpls-outgoing; Thu, 26 Apr 2001 11:36:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmkk18586 for ; Thu, 26 Apr 2001 11:35:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmkk20289 for ; Thu, 26 Apr 2001 11:35:50 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkmkk01248 for ; Thu, 26 Apr 2001 11:35:47 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3QBb4i26714 for ; Thu, 26 Apr 2001 17:07:04 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A3A.003E622F ; Thu, 26 Apr 2001 16:51:23 +0530 X-Lotus-FromDomain: HSS To: mgoel@hss.hns.com cc: mpls@UU.NET Message-ID: <65256A3A.003E6029.00@sandesh.hss.hns.com> Date: Thu, 26 Apr 2001 16:51:16 +0530 Subject: Re: IP Source Route Option Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi mohit! yes that is a definite problem and our point regarding the record route being filled in my the ingress is also not done bacause ingress can not know the IP address of all intermediate LSR's IP addresses. So even that cannot be done. Sorry I dont have the answer to this. My best guess is that these troublesome options cannot be supported for MPLS. Easy after all , eh?! ;o))) ciao sumit mgoel@hss.hns.com on 04/26/2001 04:54:42 PM To: Sumit Chauhan/HSS@HSS cc: mpls@UU.NET Subject: Re: IP Source Route Option Hi Sumit ! But how mpls will handle the IP's Record route option which requires that each intermediate router should insert its IP address in the datagram. MPLS cannot drop that packet simply because record route option is enabled in it. Moreover if explicit routing is there then ingress router can insert the complete IP addresses of the intermediate LSRs in the datagram, but what will happen in the case of hop by hop LSP. Thanks Mohit Goel suchauhan@hss.hns.com on 04/26/2001 04:23:23 PM To: Mohit Goel/HSS@HSS cc: mpls@UU.NET Subject: Re: IP Source Route Option hi mohit! Ideally this thing should be handled at the Ingress LER and he should translate the IP Source Route to MPLS sourse Route by defining a complete path for the packet (means asking the downstream routers for this). The question still hold weight as to what should be done if such a path does not exist at the time of the packet coming in or the path cannot be setup even when requested. My guess is that its best in both cases to discard the packet and send a normal ICMP packet back to source as is normally done. Going a bit deeper we generally use IP Source Routing for testing purposes and not as a means of data path reservation. Hence it might make sense to try and set up the LSP requested starting at the Ingress LER to the Egress LER if possible while holding on to the packet. This does complicate things but I guess if we have to do source routing we have to do this. ;o( regards sumit mgoel@hss.hns.com on 04/26/2001 04:20:06 PM To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: IP Source Route Option Hi All, I have a small doubt. Let an unlabelled IP packet with IP source route option enabled comes in MPLS domain. Let the packet is assigned to a LSP (say numbered 1). While traversing the MPLS domain, packet will not go to the Network layer, thus the LSR in between the ingress LSR and egress LSR cannot insert their IP addresses in the datagram. So does MPLS supports IP source route option or it does not support it? Thanks Mohit Goel From owner-mpls@UU.NET Thu Apr 26 09:22:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02786 for ; Thu, 26 Apr 2001 09:22:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmkr10710; Thu, 26 Apr 2001 13:21:57 GMT Received: by mail-control.mail.uu.net id QQkmkr02752 for mpls-outgoing; Thu, 26 Apr 2001 13:21:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmkr02741 for ; Thu, 26 Apr 2001 13:21:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmkr28346 for ; Thu, 26 Apr 2001 13:17:53 GMT Received: from c2.ciena.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQkmkr04326 for ; Thu, 26 Apr 2001 13:17:52 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id JAA14487; Thu, 26 Apr 2001 09:17:38 -0400 (EDT) Received: from wntasdexg01.asd.ciena.com(10.25.2.11) by c2.ciena.com via smap (V2.0) id xma014432; Thu, 26 Apr 01 09:17:23 -0400 Received: by wntasdexg01.asd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 09:16:48 -0400 Message-ID: <4D29EF232640D311A78C0008C75D8B920118109A@wntasdexg01.asd.ciena.com> From: "Hass, Barry" To: "'Geoff Bennett'" , "Marinzulich, Matias" , "'Ashwin Moranganti'" , "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com Subject: RE: MPLS Trafficdriven Date: Thu, 26 Apr 2001 09:16:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Geoff, I agree completely with everything you say here. I think that a policy server (perhaps located in the LSR, perhaps in a separate box) has to do the classification. And I imagine that classification policies would be based on fields in the L3 and higher layer headers. Barry > -----Original Message----- > From: Geoff Bennett [SMTP:geoff.bennett@marconi.com] > Sent: Thursday, April 26, 2001 2:32 AM > To: Hass, Barry; Marinzulich, Matias; 'Ashwin Moranganti'; 'MP LS'; > MPLS@UU.NET; mpls-ops@mplsrc.com > Subject: RE: MPLS Trafficdriven > > Hi Barry, > Yes it would make sense. But who sets the DSCP field? > > The "end user" can't be allowed to do this because DSCP is used to > prioritise traffic, and everyone would set their traffic to high priority. > > The ideal thing would be to build proxy devices to insert the appropriate > value according to a policy. IMHO the obvious location for such a proxy > is > the Ingress LSR. But the problem is how do you recognise the appropriate > traffic types. > > Cheers, > Geoff > > > > > At 17:14 25/04/01 -0400, Hass, Barry wrote: > >Hi Geoff, > > > >Would it make sense to use the DSCP field for flow aggregation, perhaps > >in combination with the IP destination address? > > > >Barry > > > >> It makes sense to pursue the idea of data driven LSP setup, but it's > >> essential to combine this approach with a flow aggregation mechanism if > we > >> expect to deploy such a technology in "large networks" (eg. a Service > >> Provider). In theory the Ingress LSR could be given the capability to > >> aggregate flows of information into a single LSP, but the details of > how > >> this could be done are generally clouded in marketing smoke and mirrors > >> today. The issue is that IPv4 lacks either a flow label (which IPv6 > has), > >> or a session identifier (that ISO TP4 has) to provide an easy > >> classification mechanism. The current "edge LSR" implementations are > >> handicapped by these limitations. So how can they assign or aggregate > >> traffic? They are normally limited to assignment on the basis of > >> destination IP address (essentially useless in most cases), or by the > use > >> of the Port ID, or by some combination of these two. In other words, > >> whatever criteria you can use to build a filter or ACL, you can use to > >> assign individual packets to an existing LSP (or as a trigger mechanism > to > >> create a new LSP). > >> > > > ================================================================ > Geoff Bennett > Tel: (33) 497 21 43 62 > Director of Technology, OCTO > Fax: (33) 497 21 43 50 > Marconi > Gaia - Bat. E > email: geoff.bennett@marconi.com > BP 123 > 06903 SOPHIA ANTIPOLIS > FRANCE > ================================================================ From owner-mpls@UU.NET Thu Apr 26 09:36:05 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03235 for ; Thu, 26 Apr 2001 09:36:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmks19687; Thu, 26 Apr 2001 13:35:49 GMT Received: by mail-control.mail.uu.net id QQkmks03855 for mpls-outgoing; Thu, 26 Apr 2001 13:35:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmks03850 for ; Thu, 26 Apr 2001 13:35:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmks05682 for ; Thu, 26 Apr 2001 13:33:02 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkmks27705 for ; Thu, 26 Apr 2001 13:33:02 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 GAA22477 for ; Thu, 26 Apr 2001 06:33:27 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA27228 for mpls@uu.net; Thu, 26 Apr 2001 09:33:00 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmjt18000 for ; Thu, 26 Apr 2001 07:18:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmjt11514 for ; Thu, 26 Apr 2001 07:18:26 GMT Received: from web11702.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11702.mail.yahoo.com [216.136.172.68]) id QQkmjt12903 for ; Thu, 26 Apr 2001 07:18:26 GMT Message-ID: <20010426071826.9227.qmail@web11702.mail.yahoo.com> Received: from [24.12.61.77] by web11702.mail.yahoo.com; Thu, 26 Apr 2001 00:18:26 PDT Date: Thu, 26 Apr 2001 00:18:26 -0700 (PDT) From: vola ray Subject: RE: MPLS Trafficdriven To: Geoff Bennett , "Hass, Barry" , "Marinzulich, Matias" , "'Ashwin Moranganti'" , "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com In-Reply-To: <200104260529.GAA10398@salamander.eu.fore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk geoff, As U mentioned..... "But the problem is how do you recognise the appropriate traffic types." Well we can solve this Problem: In the Ingress Router the ASIC device is already Configured to handle respective Packet types based on Profiles/Policies. End user can set the DSCP field in the transmitted IP packet to the Ingress Router. Now after receiving the IP Packet, Router checks the IP address and the DSCP field then validates via looking into the Port number and other stuff. By the way ASIC must be configured with such stuff to process such Traffic. Hence if somebody is sending email but prtending this is a VoIP packet it can be easily detected and either packet can be dropped or DSCP field changed accordingly. This is completely a configuration issue as to how to set up the ASIC for what type of traffic. SNMP or CLI can be used to configure such things. Hope, this helps........ vola --- Geoff Bennett wrote: > Hi Barry, > Yes it would make sense. But who sets the DSCP field? > > The "end user" can't be allowed to do this because DSCP is used to > prioritise traffic, and everyone would set their traffic to high priority. > > The ideal thing would be to build proxy devices to insert the appropriate > value according to a policy. IMHO the obvious location for such a proxy is > the Ingress LSR. But the problem is how do you recognise the appropriate > traffic types. > > Cheers, > Geoff __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mpls@UU.NET Thu Apr 26 10:39:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05798 for ; Thu, 26 Apr 2001 10:39:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmkw07876; Thu, 26 Apr 2001 14:39:29 GMT Received: by mail-control.mail.uu.net id QQkmkw27496 for mpls-outgoing; Thu, 26 Apr 2001 14:38:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmkw27479 for ; Thu, 26 Apr 2001 14:38:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmkw19964 for ; Thu, 26 Apr 2001 14:37:14 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkmkw03101 for ; Thu, 26 Apr 2001 14:37:14 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 81CDF94006; Thu, 26 Apr 2001 10:37:10 -0400 (EDT) Message-ID: <3AE83296.9FA3C835@sandburst.com> Date: Thu, 26 Apr 2001 10:37:10 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Wang Yu Cc: "mpls@UU.NET" Subject: Re: question about Trigger Control Block? References: <200104260200.f3Q20HR18032@noya.bupt.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yu, In this answer, I will use the following shorthand: NHCB = Next Hop Control Block NHCBP = Next Hop Control Block Pointer NHTCB = Next Hop Trigger Control Block NHTCBP = Next Hop Trigger Control Block Pointer JPLIG = Just Plain Lazy I Guess On page 6, you should see a statement that the NHCBP "points to the control block which is used for switching over to a better LSP." In section 3.2.6.1 Next Hop Trigger Control Block, on page 24, you should find that the NHTCB contains two pointers - one to the original downstream LSP control block and one to a new Next Hop LSP Control Block. I confess that - in at least this case - I'm guilty of not quite catching every inconsistency in the terminology used. In this definition, NHCB also equals Next Hop LSP Control Block, and NHCBP also equals Next Hop LSP Control Block Pointer I believe this is vestigial since LSP is redundant and should have been removed. Does this help? -- Eric Gray You wrote: > Eric Gray, > Hello, thank you very much! > But the third question is still not clear. > > Next Hop Control Block = Next Hop Trigger Control Block ? > > Could you explain it? > Thank you again. > > Wang Yu > wangyu7707@263.net > > ----------------- > 01-4-25 10:14:00 You wrote: > >Yu, > > > > Hello. Please see my earlier answer on this subject at: > > > > http://cell.onecall.net/mhonarc/mpls/2001-Mar/msg00009.html > > > > If this does not clear up your questions below, let me know. > > > >Thanks! > >-- > >Eric Gray > > > >You wrote: > > > >> Hi, everybody, > >> > >> Here are some questions about MPLS LDP State Machine. > >> Can someone give me explanation? > >> Thanks in advance. > >> > >> 1. Trigger Control Block is discribed unclearly in "LDP State Machine"(draft-ietf-mpls-ldp-state-04.txt). > >> (1)what is it on earth? > >> (2)what is its function? > >> (3)what information does it contain? > >> (4)how does it operation? > >> (5)how does it interwork with LSP control block? > >> > >> 2.Next Hop Control Block is discribed unclearly in "LDP State Machine"(draft-ietf-mpls-ldp-state-04.txt). > >> I have the same questions about Next Hop Control Block as 1. > >> > >> 3.Next Hop Control Block = Next Hop Trigger Control Block ? > >> > >> In draft-ietf-mpls-ldp-state-04.txt, > >> ------------------------------------------- > >> 3.2.1 LSP Control Block > >> > >> For each LSP, an LSP Control Block is defined which may contain the > >> following information: > >> - Upstream Label Request ID (assigned by the upstream LSR), > >> which is the 'Message Id' in the Label Request Message > >> received from the upstream LSR. > >> - Downstream Label Request ID (assigned by this LSR itself), > >> which is 'Message Id' in the Label Request Message sent to > >> the downstream LSR. > >> - Upstream LDP Identifier > >> - Downstream LDP Identifier > >> - State > >> - FEC > >> - Upstream Label (assigned by this LSR) > >> - Downstream Label (assigned by the downstream LSR) > >> - Trigger Control Block Pointer, (Only used at the ingress LSR > >> of a LSP) that points to the control block that triggers > >> setting up this LSP or tearing down this LSP. > >> - Next Hop Control Block Pointer, which points to the control > >> ********************** > >> block which is used for switching over to a better LSP. > >> --------------------------------------------------------------------- > >> Is Next Hop Control Block = Next Hop Trigger Control Block? > >> > >> Yu Wang > >> wangyu7707@263.net From owner-mpls@UU.NET Thu Apr 26 10:54:23 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06549 for ; Thu, 26 Apr 2001 10:54:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmkx02743; Thu, 26 Apr 2001 14:54:21 GMT Received: by mail-control.mail.uu.net id QQkmkx29027 for mpls-outgoing; Thu, 26 Apr 2001 14:53:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmkx29012 for ; Thu, 26 Apr 2001 14:53:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmkx01203 for ; Thu, 26 Apr 2001 14:52:12 GMT Received: from ersfirep1 by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.jasper.com [64.19.21.34] (may be forged)) id QQkmkx29566 for ; Thu, 26 Apr 2001 14:52:11 GMT Received: by ersfirep1; id JAA07041; Thu, 26 Apr 2001 09:53:24 -0500 (CDT) Received: from unknown(10.0.0.65) by ersfirep1.erlangtech.com via smap (V5.5) id xma007026; Thu, 26 Apr 01 09:52:47 -0500 Message-ID: <009401c0ce60$45014fb0$4100000a@internal.erlangtech.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: , "Eric Gray" Cc: "David Charlap" , "'mpls@uu.net'" References: <65256A3A.0017DB4F.00@sandesh.hss.hns.com> Subject: Re: Fragmentation in RFC-3032 Date: Thu, 26 Apr 2001 09:50:43 -0500 Organization: Erlang Technology, Inc. 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, please find the inline comment below. Take care, Thanks. ----- Original Message ----- From: To: "Eric Gray" Cc: "David Charlap" ; "'mpls@uu.net'" Sent: Wednesday, April 25, 2001 11:20 PM Subject: Re: Fragmentation in RFC-3032 hi! A few other points to ponder here;- 1. As David said that the switch may be incapable of detemination of IP characteristics. This leads us implicitly to the discussion held earlier that can there be MPLS nodes that are L3 unaware. My understanding is if we try and have a scenario where the MPLS nodes (LSRs) are L3 unaware we are doing away a lot of advantages MPLS gives us and not gaining much. To me a LSR unaware of L3 is basically a ATM switch which is un-neccesarily also running LDP. Correct me if I am wrong but this will only be benificial if we consider static LSP setup done manually which would be sacrificing a lot and gaining nothing, as that you can almost do with just a pure ATM setup. >>In my opinion, an ATM swith without an MPLS signaling capability is just >>"Native ATM Switch", not LSR. Basically when we call an ATM switch as an LSR, >>it means that the ATM switch has a capability of MPLS signaling like LDP. >>If the LSR has an MPLS signaling capability, the LSR also has an IP forwarding capability >>because the LDP runs over TCP(UDP)/IP protocols. That is to say, any real LSR supports >>an IP forwarding in control path, even though the MPLS data path is a cell-based forwarding. >>Can we think that an LDP could be working without co-operating with L3 routing protocol? >>I don't think so. Thanks, Yongjun. 2. The other thing as Eric pointed out here about ATM SAR cpability in my opinion SAR and IP Fragmentation are seperate functions and can and should not be clubbed as one. the reason is that for doing IP Fragmentation there are a whole lot of other things that need to be done (like IP header replication) rather than just chopping a packet into smaller ones. I think what Eric is proposing is very novel that we try and do some sort of Fragmentaions at L2 instead of L3 to deal with teh small MTU on the outgoing link. This will need a whole lot of thinking before we want to commit on this. 3. As has been said here earlier it should be a requirement put on the LERs to run Path MTU discovery in order to provide that this sort of case does not arise. What the RFC says is probably the "worst case action" than the "best possible one" ;o) regards sumit Eric Gray on 04/26/2001 12:04:06 AM To: David Charlap cc: "'mpls@uu.net'" (bcc: Sumit Chauhan/HSS) Subject: Re: Fragmentation in RFC-3032 David, Correct me if I'm wrong (or feel free to correct me if I'm right ... again), but ATM switches switching ATM cells have no way to know if an IP packet that extends over multiple cells is "too long". I believe this determination would be made by that ATM switch saddled with SAR responsibility. If that is the case, why would that ATM switch be intrinsically in- capable of fragmenting IP packets? -- Eric Gray You wrote: > Eric Gray wrote: > > > > In addition to what Jack says below, the intent is to specifically > > allow implementations to silently discard packets it might otherwise > > be expected to fragment. > > More specifically, some hardware (especially legacy ATM hardware) may be > incapable of performing IP fragmentation. These same boxes may also be > incapable of generating ICMP messages. > > If a too-large packet arrives at such a box, it has no choice but to > drop it. > > Ideally, the LER that admits the packet into the LSP should check the > size and fragment (or generate ICMP if DF is set) to the LSP's MTU size > (that is, the mimimum MTU of all the routers along the LSP). But this > may not always be possible - not all signaling protocols report the > LSP's MTU to the ingress router. > > Hence the RFC, which allows LSRs to either fragment or discard too-large > packets that don't have DF set. > > -- David From owner-mpls@UU.NET Thu Apr 26 11:47:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09063 for ; Thu, 26 Apr 2001 11:47:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmlb25479; Thu, 26 Apr 2001 15:47:24 GMT Received: by mail-control.mail.uu.net id QQkmlb20817 for mpls-outgoing; Thu, 26 Apr 2001 15:46:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmlb20806 for ; Thu, 26 Apr 2001 15:46:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmlb25289 for ; Thu, 26 Apr 2001 15:46:23 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkmlb18630 for ; Thu, 26 Apr 2001 15:46:19 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 IAA16555 for ; Thu, 26 Apr 2001 08:46:44 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA27979 for mpls@uu.net; Thu, 26 Apr 2001 11:46:17 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmla19938 for ; Thu, 26 Apr 2001 15:36:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmla00300 for ; Thu, 26 Apr 2001 15:34:11 GMT Received: from smtprelay.ua.pt by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprelay.ua.pt [193.136.80.103]) id QQkmla04002 for ; Thu, 26 Apr 2001 15:34:05 GMT Received: from trantor.it.pt (trantor.it.pt [193.136.92.65]) by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id F03D097E6B for ; Thu, 26 Apr 2001 16:34:02 +0100 (WEST) Received: from gumdrop (gumdrop.av.it.pt [193.136.92.176]) by trantor.it.pt (sendmail) with ESMTP id B22092C63 for ; Thu, 26 Apr 2001 16:30:34 +0100 (PST) Date: Thu, 26 Apr 2001 16:35:05 +0100 From: =?ISO-8859-1?B?Sm9yZ2UgUGF0cuNv?= X-Mailer: The Bat! (v1.46d) Personal Reply-To: =?ISO-8859-1?B?Sm9yZ2UgUGF0cuNv?= Organization: IT X-Priority: 3 (Normal) Message-ID: <18926308089.20010426163505@av.it.pt> To: mpls@UU.NET Subject: MPLS Network Planning Tools Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkmlb25479 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA09063 Hi! I need to make a survey on network planning tools. Besides WANDL's NPAT, does anyone know other tools? Thanks in advance, Jorge Patrăo From owner-mpls@UU.NET Thu Apr 26 11:53:13 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09303 for ; Thu, 26 Apr 2001 11:53:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmlb26830; Thu, 26 Apr 2001 15:52:57 GMT Received: by mail-control.mail.uu.net id QQkmlb21478 for mpls-outgoing; Thu, 26 Apr 2001 15:52:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmlb21448 for ; Thu, 26 Apr 2001 15:52:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmlb13631 for ; Thu, 26 Apr 2001 15:51:53 GMT Received: from asc_exch.asc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: outlook.asc.com [63.82.128.45]) id QQkmlb27146 for ; Thu, 26 Apr 2001 15:51:53 GMT Received: by ASC_EXCH with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 11:27:35 -0400 Message-ID: <4AA0C69EF2C3D411B94600B0D04931BD14B826@ASC_EXCH> From: Jim Loehndorf To: "'mpls@uu.net'" Subject: Uce of control word Date: Thu, 26 Apr 2001 11:27:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE65.6B2B6A40" 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_01C0CE65.6B2B6A40 Content-Type: text/plain; charset="iso-8859-1" I have a few questions that I would like some help with. The "draft-martini-l2circuit-encap-mpls-01.txt" specifies that ... "if the packet's length is less than 256 bytes, the length field MUST be set to the packet's length. Why? Is the minimum MPLS packet length fixed at 256 bytes? If not, why would I ever use padding and the length field? Jim Loehndorf ASC ------_=_NextPart_001_01C0CE65.6B2B6A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Uce of control word

I have = a few questions that I would like some help with.  The = "draft-martini-l2circuit-encap-mpls-01.txt" specifies that ... "if the = packet's length is less than 256 bytes, the length field MUST be set to = the packet's length.  Why?  Is the minimum MPLS packet length = fixed at 256 bytes?  If not, why would I ever use padding and the = length field? 

Jim = Loehndorf

ASC

------_=_NextPart_001_01C0CE65.6B2B6A40-- From owner-mpls@UU.NET Thu Apr 26 12:23:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10725 for ; Thu, 26 Apr 2001 12:23:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmld00398; Thu, 26 Apr 2001 16:23:26 GMT Received: by mail-control.mail.uu.net id QQkmld12818 for mpls-outgoing; Thu, 26 Apr 2001 16:22:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmld12804 for ; Thu, 26 Apr 2001 16:22:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmld14971 for ; Thu, 26 Apr 2001 16:22:02 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmld15723 for ; Thu, 26 Apr 2001 16:22:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA20222 for mpls@uu.net; Thu, 26 Apr 2001 12:22:01 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmld12320 for ; Thu, 26 Apr 2001 16:17:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmld05464 for ; Thu, 26 Apr 2001 16:16:33 GMT Received: from che-cse-115.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.140.33]) id QQkmld23135 for ; Thu, 26 Apr 2001 16:16:32 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id MAA01556; Thu, 26 Apr 2001 12:11:20 -0400 (EDT) Date: Thu, 26 Apr 2001 12:11:20 -0400 From: Eric Osborne To: Gang Luo Cc: "'mpls@UU.NET'" Subject: Re: Two signalling protocols (LDP & RSVP) Message-ID: <20010426121120.D1517@che-cse-115.cisco.com> References: <03E3E0690542D211A1490000F80836F404B746A1@zcard00f.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <03E3E0690542D211A1490000F80836F404B746A1@zcard00f.ca.nortel.com>; from gluo@nortelnetworks.com on Wed, Apr 25, 2001 at 10:54:39PM -0400 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, Apr 25, 2001 at 10:54:39PM -0400, Gang Luo wrote: > Hi, > > Is there any practical reason that the signalling protocols (LDP & RSVP) is > supported on the same interface? > Because they do two different things, and you may want to do both of those things on the same interface.... eric From owner-mpls@UU.NET Thu Apr 26 12:27:58 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10992 for ; Thu, 26 Apr 2001 12:27:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmld16525; Thu, 26 Apr 2001 16:27:57 GMT Received: by mail-control.mail.uu.net id QQkmld13195 for mpls-outgoing; Thu, 26 Apr 2001 16:27:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmld13174 for ; Thu, 26 Apr 2001 16:27:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmld23902 for ; Thu, 26 Apr 2001 16:25:56 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmld03397 for ; Thu, 26 Apr 2001 16:25:55 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3QGPrL22133 for ; Thu, 26 Apr 2001 09:25:53 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA28215 for mpls@uu.net; Thu, 26 Apr 2001 12:25:33 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmld12798 for ; Thu, 26 Apr 2001 16:22:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmld11647 for ; Thu, 26 Apr 2001 16:20:36 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkmld02170 for ; Thu, 26 Apr 2001 16:20:35 GMT Received: from kishan (devdhcp6211.dev.acc.am.ericsson.se [129.192.62.11]) by acc.com (8.11.1/8.11.1) with SMTP id f3QGIa513535 for ; Thu, 26 Apr 2001 09:18:36 -0700 (PDT) Reply-To: From: "Hari Kishan" To: Subject: Address message ? Date: Thu, 26 Apr 2001 09:16:57 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, What exactly are the addresses a LDP peer advertises in it's Address message before sending label advertisements? Is it a list of addresses configured on a particular interface or can it be any arbitrary list of addresses the peer is configured to advertise. thanks, Kishan --------------------------------- Hari Kishan Desineni, Ericsson Inc, Data Backbone & Optical Division, Santabarbara, California - 93117 Office:(805) 562 6419 Home:(805) 968 1894 From owner-mpls@UU.NET Thu Apr 26 13:02:56 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12535 for ; Thu, 26 Apr 2001 13:02:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmlg01676; Thu, 26 Apr 2001 17:02:45 GMT Received: by mail-control.mail.uu.net id QQkmlg22260 for mpls-outgoing; Thu, 26 Apr 2001 17:02:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmlg21217 for ; Thu, 26 Apr 2001 17:01:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmlf05367 for ; Thu, 26 Apr 2001 16:59:28 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkmlf09456 for ; Thu, 26 Apr 2001 16:59:28 GMT Received: from goneto.net (unknown [195.167.134.116]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id EB74215F817; Thu, 26 Apr 2001 17:59:21 +0100 (BST) Message-ID: <3AE860C5.FAA62229@goneto.net> Date: Thu, 26 Apr 2001 18:54:13 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jim Loehndorf Cc: "'mpls@uu.net'" Subject: Re: Uce of control word References: <4AA0C69EF2C3D411B94600B0D04931BD14B826@ASC_EXCH> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jim, the reason there is a length field in the control word is to handle the case there one or more of the physical media in the path may have a minimum frame size. For example Ethernet has a 64 octet minimum frame size (14 bytes of MAC header, 46 of data and 4 of FCS.) If there is less than 46 octets of data it must be padded to 46 octets. If, for example, a very small PPP or FR frame is carried using draft-martini then there will be less than 46 octets of data (even including the MPLS labels and the control word.) Since neither MPLS nor Ethernet has a length field the padding will then be carried on subsequent links in the path (for example if the next hop is Packet over SONET.) When the packet arrives at the egress draft-martini edge device it will need to strip off the padding. The only way to do this is using the length field in the control word. Of course all this isn't a problem with IP over MPLS because IP has a length field. Giles > Jim Loehndorf wrote: > > I have a few questions that I would like some help with. The > "draft-martini-l2circuit-encap-mpls-01.txt" specifies that ... "if the > packet's length is less than 256 bytes, the length field MUST be set > to the packet's length. Why? Is the minimum MPLS packet length fixed > at 256 bytes? If not, why would I ever use padding and the length > field? > > Jim Loehndorf > > ASC -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Thu Apr 26 14:30:18 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15426 for ; Thu, 26 Apr 2001 14:30:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmlm12771; Thu, 26 Apr 2001 18:30:06 GMT Received: by mail-control.mail.uu.net id QQkmll00062 for mpls-outgoing; Thu, 26 Apr 2001 18:29:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmll00057 for ; Thu, 26 Apr 2001 18:29:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmll02682 for ; Thu, 26 Apr 2001 18:29:00 GMT Received: from asc_exch.asc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: outlook.asc.com [63.82.128.45]) id QQkmll11118 for ; Thu, 26 Apr 2001 18:29:00 GMT Received: by ASC_EXCH with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 14:21:22 -0400 Message-ID: <4AA0C69EF2C3D411B94600B0D04931BD14B828@ASC_EXCH> From: Jim Loehndorf To: "'mpls@uu.net'" Subject: Use of Control Word Date: Thu, 26 Apr 2001 14:21:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE7D.B271A500" 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_01C0CE7D.B271A500 Content-Type: text/plain; charset="iso-8859-1" Does that mean that any MPLS frame under 256 bytes MUST include the control word? As an example, the transparent cell relay encapsulation techniques indicate that the control word is optional. If the number of cells packed into a MPLS frame results in a frame less than 256 bytes, must the control word then be included and the frame padded out? How does an edge LSR dynamically determine the control word is included? Or is this by a priori agreement? How does an edge LSR determine the minimum MTU size for an LSP? I have seen Max MTU negotiations in the LDP and RSVP extensions, but I have not seen any drafts pertaining to minimum MTU negotiations. Thank you for the help! Jim Loehndorf ASC -----Original Message----- From: Giles Heron [mailto:giles@goneto.net] Sent: Thursday, April 26, 2001 1:54 PM To: Jim Loehndorf Cc: 'mpls@uu.net' Subject: Re: Uce of control word Hi Jim, the reason there is a length field in the control word is to handle the case there one or more of the physical media in the path may have a minimum frame size. For example Ethernet has a 64 octet minimum frame size (14 bytes of MAC header, 46 of data and 4 of FCS.) If there is less than 46 octets of data it must be padded to 46 octets. If, for example, a very small PPP or FR frame is carried using draft-martini then there will be less than 46 octets of data (even including the MPLS labels and the control word.) Since neither MPLS nor Ethernet has a length field the padding will then be carried on subsequent links in the path (for example if the next hop is Packet over SONET.) When the packet arrives at the egress draft-martini edge device it will need to strip off the padding. The only way to do this is using the length field in the control word. Of course all this isn't a problem with IP over MPLS because IP has a length field. Giles > Jim Loehndorf wrote: > > I have a few questions that I would like some help with. The > "draft-martini-l2circuit-encap-mpls-01.txt" specifies that ... "if the > packet's length is less than 256 bytes, the length field MUST be set > to the packet's length. Why? Is the minimum MPLS packet length fixed > at 256 bytes? If not, why would I ever use padding and the length > field? > > Jim Loehndorf > > ASC -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ ------_=_NextPart_001_01C0CE7D.B271A500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Use of Control Word

Does = that mean that any MPLS frame under 256 bytes MUST include the control = word?  As an example, the transparent cell relay encapsulation = techniques indicate that the control word is optional.  If the = number of cells packed into a MPLS frame results in a frame less than = 256 bytes, must the control word then be included and the frame padded = out?  How does an edge LSR dynamically determine the control word = is included?  Or is this by a priori agreement?  How does an = edge LSR determine the minimum MTU size for an LSP? I have seen Max MTU = negotiations in the LDP and RSVP extensions, but I have not seen any = drafts pertaining to minimum MTU negotiations.  Thank you for the = help!

Jim = Loehndorf

ASC

-----Original Message-----

From:   Giles Heron [mailto:giles@goneto.net]

Sent:   Thursday, April 26, 2001 1:54 = PM

To:     Jim Loehndorf

Cc:     'mpls@uu.net'

Subject:        Re: = Uce of control word

Hi = Jim,

the = reason there is a length field in the control word is to handle = the

case = there one or more of the physical media in the path may have = a

minimum = frame size.

For = example Ethernet has a 64 octet minimum frame size (14 bytes of = MAC

header, = 46 of data and 4 of FCS.)  If there is less than 46 octets = of

data it = must be padded to 46 octets.  If, for example, a very small = PPP

or FR = frame is carried using draft-martini then there will be less = than

46 = octets of data (even including the MPLS labels and the = control

word.)  Since neither MPLS nor Ethernet has a = length field the padding

will = then be carried on subsequent links in the path (for example if = the

next = hop is Packet over SONET.)  When the packet arrives at the egress

draft-martini edge device it will need to strip off the = padding.  The

only = way to do this is using the length field in the control = word.

Of = course all this isn't a problem with IP over MPLS because IP has = a

length = field.

Giles

    > Jim Loehndorf wrote:

    >

    > I have a few questions that I would like some help = with.  The

    > "draft-martini-l2circuit-encap-mpls-01.txt" specifies that ... = "if the

    > packet's length is less than 256 bytes, the length field MUST = be set

    > to the packet's length.  Why?  Is the minimum MPLS packet = length fixed

    > at 256 bytes?  If not, why would I ever use padding = and the length

    > field?

    >

    > Jim Loehndorf

    >

    > ASC

-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Giles = Heron      Principal Network = Architect      Gone2 Inc.

ph: +44 = 7880 506185         = "if you build it they will = yawn"

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C0CE7D.B271A500-- From owner-mpls@UU.NET Thu Apr 26 15:20:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16759 for ; Thu, 26 Apr 2001 15:20:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmlp22952; Thu, 26 Apr 2001 19:20:01 GMT Received: by mail-control.mail.uu.net id QQkmlp23418 for mpls-outgoing; Thu, 26 Apr 2001 19:19:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmlp23406 for ; Thu, 26 Apr 2001 19:19:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmlp01983 for ; Thu, 26 Apr 2001 19:18:53 GMT Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQkmlp21338 for ; Thu, 26 Apr 2001 19:18:53 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id PAA12364 for ; Thu, 26 Apr 2001 15:15:40 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256A3A.0069CBE6 ; Thu, 26 Apr 2001 15:15:34 -0400 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <85256A3A.0069CB13.00@notes949.cc.telcordia.com> Date: Thu, 26 Apr 2001 15:15:05 -0400 Subject: path message Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, If Ingress router is connected directly to the Egress router, the path message will not be sent out from the Ingress router? Thanks, Julia From owner-mpls@UU.NET Thu Apr 26 15:51:33 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17513 for ; Thu, 26 Apr 2001 15:51:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmlr27632; Thu, 26 Apr 2001 19:51:20 GMT Received: by mail-control.mail.uu.net id QQkmlr26245 for mpls-outgoing; Thu, 26 Apr 2001 19:49:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmlr26181 for ; Thu, 26 Apr 2001 19:49:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmlr03293 for ; Thu, 26 Apr 2001 19:49:26 GMT From: djiang1@lucent.com Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQkmlr25531 for ; Thu, 26 Apr 2001 19:49:26 GMT Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3QJnPZ22746 for ; Thu, 26 Apr 2001 15:49:25 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3QJnPQ22735 for ; Thu, 26 Apr 2001 15:49:25 -0400 (EDT) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA07096; Thu, 26 Apr 2001 15:49:21 -0400 (EDT) Subject: question on encapsulation of IP/MPLS/Ethernet To: mpls@UU.NET Date: Thu, 26 Apr 2001 15:43:25 -0400 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 04/26/2001 15:43:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I know the RFCs clearly defined for IP/MPLS/ATM that only VC mux is allowed to encapsulate an MPLS labeled IP packet into ATM cells. However, I have not seen any document specifying what encapsulation needs to be used for IP/MPLS/Ethernet frame goes over an ATM backbone. LLC-SNAP encapsulation or VC mux? Thanks a lot. Jane D. Jiang From owner-mpls@UU.NET Thu Apr 26 16:46:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20693 for ; Thu, 26 Apr 2001 16:46:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmlv29582; Thu, 26 Apr 2001 20:46:38 GMT Received: by mail-control.mail.uu.net id QQkmlv19747 for mpls-outgoing; Thu, 26 Apr 2001 20:46:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmlv19742 for ; Thu, 26 Apr 2001 20:45:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmlv18524 for ; Thu, 26 Apr 2001 20:45:32 GMT Received: from ganymede.or.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns01.or.intel.com [134.134.248.3]) id QQkmlv27404 for ; Thu, 26 Apr 2001 20:45:31 GMT Received: from SMTP (orsmsx226.jf.intel.com [192.168.65.226]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id UAA00871; Thu, 26 Apr 2001 20:45:26 GMT Received: from orsmsx228.JF.INTEL.COM ([192.168.70.228]) by 192.168.70.226 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 26 Apr 2001 20:45:24 0000 (GMT) Received: by ORSMSX228 with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 13:45:23 -0700 Message-ID: From: "Bakshi, Sanjay" To: "'Eric Gray'" Cc: mpls@UU.NET Subject: RE: A question. Date: Wed, 18 Apr 2001 13:33:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, Thanks for the clarification. So, this implies that LSP setup (via LDP etc) is triggered either by routing changes or by management e.g. in case of ERLSP and packets for which 'FEC entry' is missing in FTN are handled as you suggested. Is that fair to say? thanks --sanjay -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] Sent: Monday, April 16, 2001 5:12 AM To: Bakshi, Sanjay Cc: mpls@UU.NET Subject: Re: A question. Sanjay, Your assumption is slightly faulty. :-) The term LER (label edge router) is somewhat misleading, because it seems to define a box (router) as opposed to a function (label edge routing) which a box may or may not support. People tend to think of an LER as a box that supports the edge routing functions of MPLS ingress and egress. That does not mean that it absolutely must find an LSP for every packet it receives - or that it absolutely must pop the last label off of every packet that it sends. It's behavior WRT any packet it receives or sends depends largely on the capabilities of the interfaces on which it was received or will be sent and the apriori existence of an FTN (or ILM) entry. There is no 'data-driven label binding operation' as you imply in your question. If an LER does not have a 'FEC entry' in its FTN (FEC to NHLFE) table, it either forwards the packet using IP routing (if it is able to do so) or it drops the packet (possibly returning a 'destination unreachable' error to the sender - again if it is able to do so). -- Eric Gray You wrote: > Hello, > I have a simple question for which I think I know the answer but cannot find > the reference in the RFCs to de certain. What happens when a unlabeled > packet is received by a LER and there is no FEC entry corresponding to the > packet? > I know this falls under the data-driven label binding operation, in which > LDP is trigerred by the arriving packet. But I have not found a reference to > it in any RFC to back my assumption up. > Any pointers? > thanks > sanjay From owner-mpls@UU.NET Thu Apr 26 17:32:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23060 for ; Thu, 26 Apr 2001 17:32:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmly12182; Thu, 26 Apr 2001 21:32:13 GMT Received: by mail-control.mail.uu.net id QQkmly13697 for mpls-outgoing; Thu, 26 Apr 2001 21:31:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmly13626 for ; Thu, 26 Apr 2001 21:31:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmly28471 for ; Thu, 26 Apr 2001 21:31:05 GMT Received: from ersfirep1 by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.jasper.com [64.19.21.34] (may be forged)) id QQkmly09879 for ; Thu, 26 Apr 2001 21:31:04 GMT Received: by ersfirep1; id QAA12393; Thu, 26 Apr 2001 16:31:58 -0500 (CDT) Received: from unknown(10.0.0.65) by ersfirep1.erlangtech.com via smap (V5.5) id xma012387; Thu, 26 Apr 01 16:31:22 -0500 Message-ID: <01cd01c0ce97$f40ead40$4100000a@internal.erlangtech.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: , References: Subject: Re: question on encapsulation of IP/MPLS/Ethernet Date: Thu, 26 Apr 2001 16:29:19 -0500 Organization: Erlang Technology, Inc. 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I am not sure that what you mean by "IP/MPLS/Ethernet goes over an ATM Backbone". If it means that an Ethernet Frame with an MPLS packet is transmitted over an ATM virtual connection, I think that it's not a senario regarding an MPLS network configuration. It's just about how to encapsulate an Ethernet Frame over an ATM virtual connection, which could use LLC-SNAP encapsulation or null encapsulation (VC-mux) (RFC 1483). If I'm wrong, I would apologize for that and please let me know. Take care, Yongjun ----- Original Message ----- From: To: Sent: Thursday, April 26, 2001 2:43 PM Subject: question on encapsulation of IP/MPLS/Ethernet Hi All, I know the RFCs clearly defined for IP/MPLS/ATM that only VC mux is allowed to encapsulate an MPLS labeled IP packet into ATM cells. However, I have not seen any document specifying what encapsulation needs to be used for IP/MPLS/Ethernet frame goes over an ATM backbone. LLC-SNAP encapsulation or VC mux? Thanks a lot. Jane D. Jiang From owner-mpls@UU.NET Thu Apr 26 20:26:46 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25348 for ; Thu, 26 Apr 2001 20:26:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmmj11932; Fri, 27 Apr 2001 00:26:34 GMT Received: by mail-control.mail.uu.net id QQkmmj25825 for mpls-outgoing; Fri, 27 Apr 2001 00:26:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmmj25806 for ; Fri, 27 Apr 2001 00:25:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmmj10019 for ; Fri, 27 Apr 2001 00:25:10 GMT Received: from sutton.acbm.qc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.96.170.5]) id QQkmmj03615 for ; Fri, 27 Apr 2001 00:25:09 GMT Received: from hermes.hyperchip.com ([216.249.11.203]) by sutton.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-69929U800L2S100V35) with ESMTP id ca; Thu, 26 Apr 2001 20:27:00 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Apr 2001 20:25:04 -0400 Message-ID: From: Martin-Guy Richard To: "'mpls@UU.NET'" , "'jwysocki83@hotmail.com'" Subject: RE: draft-katz-yeung-ospf-traffic-04 Date: Thu, 26 Apr 2001 20:25:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CEB0.808045F0" 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_01C0CEB0.808045F0 Content-Type: text/plain; charset="iso-8859-1" John, The best way to see it is to use an example: Those are the sub-TLVs for the Link TLV. 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Resource class/color (4 octets) Let say on a certain interface on a certain router we have for the Max Rsv BW and Unreserved bandwidth sub-TLVs the following values: Maximum reservable bandwidth : 1250000 Priority 0 : 1250000 Priority 1 : 1225000 Priority 2 : 1225000 Priority 3 : 1225000 Priority 4 : 1225000 Priority 5 : 1209750 Priority 6 : 1209750 Priority 7 : 1209750 You can see that I've set the Max Resv BW to 10Mbps (10Mbps/8bytes=1250000 bytes per second) One thing you have to know before I continue: On that particular interface on that same router, I have two tunnel having two different hold priority Tunnel 1 has a hold priority of 5, with Resv BW of 122 kbps Tunnel 2 has a hold priority of 1, with Resv BW of 200 kbps. Let's continue. To find the Unreserved Bandwidth at each priority we need to apply the following formula: (Unreserved BW for current hold priority)=(Unreserved BW from previous hold priority) - (Resv BW for current hold priority) At priority 0, I still have the maximum reservable bandwidth. It is equal to Max Resv BW. At priority 1, I have a different number. When we apply the formula, we get 1225000 bytes per second left for next priority. At priority 2, nothing reserved, so by applying the formula, we still have 1225000 bytes per second left for next priority. At priority 3, same thing. At priority 4, same thing. At priority 5, we get 1209750 bytes per second since I reserved 122 kbps for that hold priority. At priority 6, nothing reserved, so by applying the formula, we still have 1209750 bytes per second left for next priority. At priority 7, same thing. I hope that my example is "draft compliant"! -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of John Wysocki Sent: April 25, 2001 2:45 PM To: mpls@UU.NET Subject: draft-katz-yeung-ospf-traffic-04 In this draft 2.4.2 Link TLV has sub-TLV 8 - Unreserved bandwidth (32 octets). 2.5.8 says Each value will be less than or equal to the maximum reservable bandwidth. It specifies not yet reserved BW at each of the eight priority levels. Does this mean each 4 octets (32/8 = 4) will represent unreserved bandwith for a priority? What does it represent? 2^4 = 16 values, but how do you use it? Does anyone know? Thanks. John _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com ------_=_NextPart_001_01C0CEB0.808045F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-katz-yeung-ospf-traffic-04

John,

The best way to see it is to use an example:

Those are the sub-TLVs for the Link TLV.

1 - Link type (1 octet)
2 - Link ID (4 octets)
3 - Local interface IP address (4 octets)
4 - Remote interface IP address (4 octets)
5 - Traffic engineering metric (4 octets)
6 - Maximum bandwidth (4 octets)
7 - Maximum reservable bandwidth (4 octets)
8 - Unreserved bandwidth (32 octets)
9 - Resource class/color (4 octets)

Let say on a certain interface on a certain router we = have for the Max Rsv BW and Unreserved bandwidth sub-TLVs the following = values:

Maximum reservable bandwidth : 1250000
Priority 0 : 1250000     = Priority 1 : 1225000  
Priority 2 : 1225000     = Priority 3 : 1225000  
Priority 4 : 1225000     = Priority 5 : 1209750  
Priority 6 : 1209750     = Priority 7 : 1209750  

You can see that I've set the Max Resv BW to 10Mbps = (10Mbps/8bytes=3D1250000 bytes per second)

One thing you have to know before I continue:

On  that particular interface on that same = router, I have two tunnel having two different hold priority

    Tunnel 1 has a hold priority of 5, = with Resv BW of 122 kbps
    Tunnel 2 has a hold priority of = 1, with Resv BW of 200 kbps.

Let's continue.

To find the Unreserved Bandwidth at each priority we = need to apply the following formula:

 (Unreserved BW for current hold = priority)=3D(Unreserved BW from previous hold priority) - (Resv BW for = current hold priority)

At priority 0, I still have the maximum reservable = bandwidth. It is equal to Max Resv BW.
At priority 1, I have a different number. When we = apply the formula, we get 1225000 bytes per second left for next = priority.

At priority 2, nothing reserved, so by applying the = formula, we still have 1225000 bytes per second left for next = priority.

At priority 3, same thing.
At priority 4, same thing.
At priority 5, we get 1209750 bytes per second since = I reserved 122 kbps for that hold priority.
At priority 6, nothing reserved, so by applying the = formula, we still have 1209750 bytes per second left for next = priority.

At priority 7, same thing.

I hope that my example is "draft = compliant"!

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of John
Wysocki
Sent: April 25, 2001 2:45 PM
To: mpls@UU.NET
Subject: draft-katz-yeung-ospf-traffic-04


In this draft 2.4.2 Link TLV has sub-TLV 8 - = Unreserved bandwidth (32
octets).

2.5.8 says Each value will be less than or equal to = the maximum reservable
bandwidth.  It specifies not yet reserved BW at = each of the eight priority
levels.

Does this mean each 4 octets (32/8 =3D 4) will = represent unreserved bandwith
for a priority?
What does it represent?  2^4 =3D 16 values, but = how do you use it?

Does anyone know?

Thanks.

John
_______________________________________________________________= __
Get your FREE download of MSN Explorer at http://explorer.msn.com

------_=_NextPart_001_01C0CEB0.808045F0-- From owner-mpls@UU.NET Thu Apr 26 20:53:17 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25771 for ; Thu, 26 Apr 2001 20:53:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmml04092; Fri, 27 Apr 2001 00:53:12 GMT Received: by mail-control.mail.uu.net id QQkmml28028 for mpls-outgoing; Fri, 27 Apr 2001 00:52:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmml28012 for ; Fri, 27 Apr 2001 00:52:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmml14431 for ; Fri, 27 Apr 2001 00:50:42 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmml18759 for ; Fri, 27 Apr 2001 00:50:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA17428 for mpls@uu.net; Thu, 26 Apr 2001 20:50:42 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmll29791 for ; Thu, 26 Apr 2001 18:25:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmll23302 for ; Thu, 26 Apr 2001 18:24:58 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQkmll00419 for ; Thu, 26 Apr 2001 18:24:57 GMT Received: from ASIMHA-LAPTOP (dhcp-64-102-48-168.cisco.com [64.102.48.168]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA03748; Thu, 26 Apr 2001 14:21:25 -0400 (EDT) Date: Thu, 26 Apr 2001 14:25:13 -0400 (Eastern Daylight Time) From: Ajay Simha To: Hari Kishan cc: Subject: Re: Address message ? In-Reply-To: Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 26 Apr 2001, Hari Kishan wrote: > Hi, > > What exactly are the addresses a LDP peer > advertises in it's Address message before > sending label advertisements? > > Is it a list of addresses configured on a > particular interface or can it be any arbitrary > list of addresses the peer is configured to > advertise. I would think it should be the addresses that are configured on interfaces not arbitrary list of addresses. Because these addresses could be used later to dip into the LIB if for example one of the links to that neighbor goes away and we continue to have a session. We still want to use the label bindings this neighbor sent us earlier. -ajay > > thanks, > Kishan > > --------------------------------- > Hari Kishan Desineni, > Ericsson Inc, > Data Backbone & Optical Division, > Santabarbara, > California - 93117 > Office:(805) 562 6419 > Home:(805) 968 1894 > -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Thu Apr 26 22:59:47 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29841 for ; Thu, 26 Apr 2001 22:59:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmmt24998; Fri, 27 Apr 2001 02:59:26 GMT Received: by mail-control.mail.uu.net id QQkmmt15870 for mpls-outgoing; Fri, 27 Apr 2001 02:58:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmmt15854 for ; Fri, 27 Apr 2001 02:58:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmmt27995 for ; Fri, 27 Apr 2001 02:57:14 GMT Received: from noya.bupt.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQkmmt21481 for ; Fri, 27 Apr 2001 02:56:55 GMT Received: from mars ([202.112.109.69]) by noya.bupt.edu.cn (8.11.3/8.10.1) with SMTP id f3R2ufR16670; Fri, 27 Apr 2001 10:56:45 +0800 (CST) Message-Id: <200104270256.f3R2ufR16670@noya.bupt.edu.cn> Date: Fri, 27 Apr 2001 11:1:10 +0800 From: Wang Yu To: Eric Gray , "mpls@UU.NET" Subject: Re: Re: question about Trigger Control Block? X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray, thanks a lot! ----------------- 01-4-26 10:37:00 You wrote: >Yu, > > In this answer, I will use the following shorthand: > > NHCB = Next Hop Control Block > NHCBP = Next Hop Control Block Pointer > NHTCB = Next Hop Trigger Control Block > NHTCBP = Next Hop Trigger Control Block Pointer > JPLIG = Just Plain Lazy I Guess > > On page 6, you should see a statement that the NHCBP >"points to the control block which is used for switching over >to a better LSP." > > In section 3.2.6.1 Next Hop Trigger Control Block, on page >24, you should find that the NHTCB contains two pointers - >one to the original downstream LSP control block and one to a >new Next Hop LSP Control Block. I confess that - in at least >this case - I'm guilty of not quite catching every inconsistency >in the terminology used. In this definition, > > NHCB also equals Next Hop LSP Control Block, and > NHCBP also equals Next Hop LSP Control Block Pointer > >I believe this is vestigial since LSP is redundant and should ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >have been removed. ~~~~~~~~~~~~~~~~~~~ Do you mean Next Hop LSP Control Block and Next Hop LSP Control Block is useless and should have been removed? If the answer is no, what is the function of Next Hop LSP Control Block Pointer in LSP Control Block? > > Does this help? > >-- >Eric Gray > In 3.2.1, LSP Control Block contains NHCBP (Next Hop LSP Control Block Pointer). But it seems that NHCBP is not useless. It is NHTCBP that is used for switching over to a better LSP. Certainly, NHCBP is useful in Next Hop Trigger Control Block. +-----------------------+ | LSP Control Block | | (original LSP) | +-----------------------+ (LSP ^ | Control | | (Next Hop Trigger Control Block Pointer) Block | | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Pointer) | v +--------------------------------+ | Next Hop Trigger Control Block | +--------------------------------+ ^ | (Trigger | | (New Next Hop LSP Control Block Pointer) Control | | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Block | | Pointer)| | | v +------------------------+ | LSP Control Block | | (for LSP: LSR-B, LSR-E,| | LSR-D) | +------------------------+ Wang Yu From owner-mpls@UU.NET Fri Apr 27 01:38:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06192 for ; Fri, 27 Apr 2001 01:38:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmne27916; Fri, 27 Apr 2001 05:37:56 GMT Received: by mail-control.mail.uu.net id QQkmne24782 for mpls-outgoing; Fri, 27 Apr 2001 05:37:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmne24774 for ; Fri, 27 Apr 2001 05:37:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmne18668 for ; Fri, 27 Apr 2001 05:36:05 GMT Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQkmne09759 for ; Fri, 27 Apr 2001 05:36:03 GMT Received: from utfors.se ([10.58.0.153]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GCFRNU00.GEC; Fri, 27 Apr 2001 07:38:18 +0200 Message-ID: <3AE90542.901DA8CD@utfors.se> Date: Fri, 27 Apr 2001 07:36:02 +0200 From: "Loa Andersson" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: suchauhan@hss.hns.com CC: mgoel@hss.hns.com, mpls@UU.NET Subject: Re: IP Source Route Option References: <65256A3A.003E6029.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkmne27916 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA06192 All, why not forward on L3? /Loa suchauhan@hss.hns.com wrote: > > hi mohit! > yes that is a definite problem and our point regarding the record route > being filled in my the ingress is also not done bacause ingress can not know the > IP address of all intermediate LSR's IP addresses. So even that cannot be done. > Sorry I dont have the answer to this. My best guess is that these troublesome > options cannot be supported for MPLS. Easy after all , eh?! ;o))) > > ciao > sumit > > mgoel@hss.hns.com on 04/26/2001 04:54:42 PM > > To: Sumit Chauhan/HSS@HSS > cc: mpls@UU.NET > > Subject: Re: IP Source Route Option > > Hi Sumit ! > > But how mpls will handle the IP's Record route option which requires that each > intermediate router should insert its IP address in the datagram. MPLS cannot > drop that packet simply because record route option is enabled in it. Moreover > if explicit routing is there then ingress router can insert the complete IP > addresses of the intermediate LSRs in the datagram, but what will happen in the > case of hop by hop LSP. > > Thanks > Mohit Goel > > suchauhan@hss.hns.com on 04/26/2001 04:23:23 PM > > To: Mohit Goel/HSS@HSS > cc: mpls@UU.NET > > Subject: Re: IP Source Route Option > > hi mohit! > Ideally this thing should be handled at the Ingress LER and he should > translate the IP Source Route to MPLS sourse Route by defining a complete path > for the packet (means asking the downstream routers for this). The question > still hold weight as to what should be done if such a path does not exist at the > time of the packet coming in or the path cannot be setup even when requested. My > guess is that its best in both cases to discard the packet and send a normal > ICMP packet back to source as is normally done. Going a bit deeper we generally > use IP Source Routing for testing purposes and not as a means of data path > reservation. Hence it might make sense to try and set up the LSP requested > starting at the Ingress LER to the Egress LER if possible while holding on to > the packet. This does complicate things but I guess if we have to do source > routing we have to do this. ;o( > regards > sumit > > mgoel@hss.hns.com on 04/26/2001 04:20:06 PM > > To: mpls@UU.NET > cc: (bcc: Sumit Chauhan/HSS) > > Subject: IP Source Route Option > > Hi All, > > I have a small doubt. Let an unlabelled IP packet with IP source route option > enabled comes in MPLS domain. Let the packet is assigned to a LSP (say numbered > 1). While traversing the MPLS domain, packet will not go to the Network layer, > thus the LSR in between the ingress LSR and egress LSR cannot insert their IP > addresses in the datagram. So does MPLS supports IP source route option or it > does not support it? > > Thanks > Mohit Goel -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Fri Apr 27 05:47:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20137 for ; Fri, 27 Apr 2001 05:47:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmnv12738; Fri, 27 Apr 2001 09:47:14 GMT Received: by mail-control.mail.uu.net id QQkmnv00026 for mpls-outgoing; Fri, 27 Apr 2001 09:46:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmnv00016 for ; Fri, 27 Apr 2001 09:46:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmnv05409 for ; Fri, 27 Apr 2001 09:45:50 GMT From: mgoel@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkmnv16264 for ; Fri, 27 Apr 2001 09:45:46 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3R9cwJ22435; Fri, 27 Apr 2001 15:08:58 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A3B.00339583 ; Fri, 27 Apr 2001 14:53:26 +0530 X-Lotus-FromDomain: HSS To: Eric Osborne cc: Gang Luo , "'mpls@UU.NET'" Message-ID: <65256A3B.003390E8.00@sandesh.hss.hns.com> Date: Fri, 27 Apr 2001 15:07:20 +0530 Subject: Re: Two signalling protocols (LDP & RSVP) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk > Hi, > > Is there any practical reason that the signalling protocols (LDP & RSVP) is > supported on the same interface? > Although both CR-LDP and RSVP-TE provides similar functionalities, but one significant reason why we would like to run both the protocols on the same interface can be that TE-RSVP supports IP record route option using its record route objects.But CR-LDP doesn't support IP record route option. Regards Mohit Goel From owner-mpls@UU.NET Fri Apr 27 05:50:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20174 for ; Fri, 27 Apr 2001 05:50:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmnv20937; Fri, 27 Apr 2001 09:50:11 GMT Received: by mail-control.mail.uu.net id QQkmnv00290 for mpls-outgoing; Fri, 27 Apr 2001 09:49:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmnv00259 for ; Fri, 27 Apr 2001 09:49:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmnv10266 for ; Fri, 27 Apr 2001 09:48:44 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkmnv04549 for ; Fri, 27 Apr 2001 09:48:44 GMT Received: from goneto.net (stockley11-dhcp72.cisco.com [144.254.99.81]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 67AE215F817; Fri, 27 Apr 2001 10:48:38 +0100 (BST) Message-ID: <3AE94D52.3373F33B@goneto.net> Date: Fri, 27 Apr 2001 11:43:30 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jim Loehndorf Cc: mpls@UU.NET Subject: Re: Uce of control word References: <4AA0C69EF2C3D411B94600B0D04931BD14B827@ASC_EXCH> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit No, this means that you need to have the control word if traffic may be sent over a path including any segments with a minimum frame size lower than the minimum draft-martini packet size (including MPLS labels.) So for ATM cells over MPLS over Ethernet you should be OK (as 52 bytes + MPLS labels > 46 bytes.) To answer some of your other questions: 1. The control word is negotiated in advance on a per LSP basis (using the procedures in draft-martini-l2circuit-trans-mpls-05.txt.) 2. There is no way to determine the min MTU size for an LSP. I guess it would be a reasonably easy extension to add, but I'm not sure how much value there is in this - given that it isn't an issue for IP over MPLS? HTH Giles > Jim Loehndorf wrote: > > Does that mean that any MPLS frame under 256 bytes MUST include the > control word? As an example, the transparent cell relay encapsulation > techniques indicate that the control word is optional. If the number > of cells packed into a MPLS frame results in a frame less than 256 > bytes, must the control word then be included and the frame padded > out? How does an edge LSR dynamically determine the control word is > included? Or is this by a priori agreement? How does an edge LSR > determine the minimum MTU size for an LSP? I have seen Max MTU > negotiations in the LDP and RSVP extensions, but I have not seen any > drafts pertaining to minimum MTU negotiations. Thank you for the > help! > > Jim Loehndorf > ASC > > -----Original Message----- > From: Giles Heron [mailto:giles@goneto.net] > Sent: Thursday, April 26, 2001 1:54 PM > To: Jim Loehndorf > Cc: 'mpls@uu.net' > Subject: Re: Uce of control word > > Hi Jim, > > the reason there is a length field in the control word is to handle > the > case there one or more of the physical media in the path may have a > minimum frame size. > > For example Ethernet has a 64 octet minimum frame size (14 bytes of > MAC > header, 46 of data and 4 of FCS.) If there is less than 46 octets of > data it must be padded to 46 octets. If, for example, a very small > PPP > or FR frame is carried using draft-martini then there will be less > than > 46 octets of data (even including the MPLS labels and the control > word.) Since neither MPLS nor Ethernet has a length field the padding > > will then be carried on subsequent links in the path (for example if > the > next hop is Packet over SONET.) When the packet arrives at the egress > > draft-martini edge device it will need to strip off the padding. The > only way to do this is using the length field in the control word. > > Of course all this isn't a problem with IP over MPLS because IP has a > length field. > > Giles > > > Jim Loehndorf wrote: > > > > I have a few questions that I would like some help with. The > > "draft-martini-l2circuit-encap-mpls-01.txt" specifies that ... "if > the > > packet's length is less than 256 bytes, the length field MUST be set > > > to the packet's length. Why? Is the minimum MPLS packet length > fixed > > at 256 bytes? If not, why would I ever use padding and the length > > field? > > > > Jim Loehndorf > > > > ASC > > -- > ============================================================ > Giles Heron Principal Network Architect Gone2 Inc. > ph: +44 7880 506185 "if you build it they will yawn" > ============================================================ -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Fri Apr 27 05:57:57 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20332 for ; Fri, 27 Apr 2001 05:57:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmnv23835; Fri, 27 Apr 2001 09:57:57 GMT Received: by mail-control.mail.uu.net id QQkmnv01048 for mpls-outgoing; Fri, 27 Apr 2001 09:57:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmnv01039 for ; Fri, 27 Apr 2001 09:57:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmnv05427 for ; Fri, 27 Apr 2001 09:56:37 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkmnv27763 for ; Fri, 27 Apr 2001 09:56:36 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id CAA01113; Fri, 27 Apr 2001 02:56:36 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id CAA02089; Fri, 27 Apr 2001 02:56:36 -0700 (PDT) Date: Fri, 27 Apr 2001 02:56:36 -0700 (PDT) From: Kireeti Kompella Message-Id: <200104270956.CAA02089@kummer.juniper.net> To: eosborne@cisco.com, mgoel@hss.hns.com Subject: Re: Two signalling protocols (LDP & RSVP) Cc: gluo@nortelnetworks.com, mpls@UU.NET In-Reply-To: <65256A3B.003390E8.00@sandesh.hss.hns.com> Sender: owner-mpls@UU.NET Precedence: bulk > Although both CR-LDP and RSVP-TE provides similar functionalities, but one > significant reason why we would like to run both the protocols on the same > interface can be that TE-RSVP supports IP record route option using its record > route objects.But CR-LDP doesn't support IP record route option. The above seems to be an excellent argument for running RSVP-TE. It is not (as it stands) a justification for running *both* RSVP and CR-LDP. Kireeti. From owner-mpls@UU.NET Fri Apr 27 06:49:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21534 for ; Fri, 27 Apr 2001 06:49:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmnz19804; Fri, 27 Apr 2001 10:49:21 GMT Received: by mail-control.mail.uu.net id QQkmnz24077 for mpls-outgoing; Fri, 27 Apr 2001 10:48:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmnz24069 for ; Fri, 27 Apr 2001 10:48:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmnz09368 for ; Fri, 27 Apr 2001 10:47:59 GMT From: mgoel@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkmnz18224 for ; Fri, 27 Apr 2001 10:47:55 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3RAmum25141; Fri, 27 Apr 2001 16:18:57 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A3B.0039FCBD ; Fri, 27 Apr 2001 16:03:22 +0530 X-Lotus-FromDomain: HSS To: Kireeti Kompella cc: mpls@UU.NET Message-ID: <65256A3B.0039FBD5.00@sandesh.hss.hns.com> Date: Fri, 27 Apr 2001 16:17:25 +0530 Subject: Re: Two signalling protocols (LDP & RSVP) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk > > Although both CR-LDP and RSVP-TE provides similar functionalities, but one >> significant reason why we would like to run both the protocols on the same >> interface can be that TE-RSVP supports IP record route option using its record >> route objects.But CR-LDP doesn't support IP record route option. >>Mohit >The above seems to be an excellent argument for running RSVP-TE. >It is not (as it stands) a justification for running *both* RSVP >and CR-LDP. >Kireeti. CR-LDP supports path reoptimization which means that it has the capability to repath loosely routed LSPs based on traffic pattern changes. But RSVP-TE does not support the feature of path reoptimization. Mohit From owner-mpls@UU.NET Fri Apr 27 09:02:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27269 for ; Fri, 27 Apr 2001 09:02:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoi08661; Fri, 27 Apr 2001 13:02:26 GMT Received: by mail-control.mail.uu.net id QQkmoi17071 for mpls-outgoing; Fri, 27 Apr 2001 13:01:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmoi16849 for ; Fri, 27 Apr 2001 13:01:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmoi26789 for ; Fri, 27 Apr 2001 13:01:03 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmoi19272 for ; Fri, 27 Apr 2001 13:01:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA16809 for mpls@uu.net; Fri, 27 Apr 2001 09:01:03 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmoh12012 for ; Fri, 27 Apr 2001 12:56:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmoh08526 for ; Fri, 27 Apr 2001 12:56:37 GMT Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQkmoh01897 for ; Fri, 27 Apr 2001 12:56:37 GMT Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id IAA03389; Fri, 27 Apr 2001 08:56:34 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Fri, 27 Apr 2001 08:56:26 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Apr 2001 08:56:29 -0400 Message-ID: <03E3E0690542D211A1490000F80836F404B746AE@zcard00f.ca.nortel.com> From: "Gang Luo" To: "'Kireeti Kompella'" , eosborne@cisco.com, mgoel@hss.hns.com Cc: mpls@UU.NET Subject: RE: Two signalling protocols (LDP & RSVP) Date: Fri, 27 Apr 2001 08:56:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CF19.780DB470" 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_01C0CF19.780DB470 Content-Type: text/plain; charset="iso-8859-1" Hi Kireeti, I agree with you. If some feature is required, but missing, it looks that we just build the feature as an option into the existing protocol. That will be less implementation overhead than supporting two protocols. Best regards. Gang. -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, April 27, 2001 5:57 AM To: eosborne@cisco.com; mgoel@hss.hns.com Cc: Luo, Gang [SKY:1H91:EXCH]; mpls@UU.NET Subject: Re: Two signalling protocols (LDP & RSVP) > Although both CR-LDP and RSVP-TE provides similar functionalities, but one > significant reason why we would like to run both the protocols on the same > interface can be that TE-RSVP supports IP record route option using its record > route objects.But CR-LDP doesn't support IP record route option. The above seems to be an excellent argument for running RSVP-TE. It is not (as it stands) a justification for running *both* RSVP and CR-LDP. Kireeti. ------_=_NextPart_001_01C0CF19.780DB470 Content-Type: text/html; charset="iso-8859-1" RE: Two signalling protocols (LDP & RSVP)

Hi Kireeti,

I agree with you. If some feature is required, but missing,
it looks that we just build the feature as an option into the existing protocol.

That will be less implementation overhead than supporting two protocols.

Best regards.
Gang.



-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Friday, April 27, 2001 5:57 AM
To: eosborne@cisco.com; mgoel@hss.hns.com
Cc: Luo, Gang [SKY:1H91:EXCH]; mpls@UU.NET
Subject: Re: Two signalling protocols (LDP & RSVP)


> Although both CR-LDP and RSVP-TE provides similar functionalities, but one
> significant reason why we would like to run both the protocols on the same
> interface can be that TE-RSVP supports IP record route option using its record
> route objects.But CR-LDP doesn't support IP record route option.

The above seems to be an excellent argument for running RSVP-TE.
It is not (as it stands) a justification for running *both* RSVP
and CR-LDP.

Kireeti.

------_=_NextPart_001_01C0CF19.780DB470-- From owner-mpls@UU.NET Fri Apr 27 09:12:38 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27603 for ; Fri, 27 Apr 2001 09:12:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoi02171; Fri, 27 Apr 2001 13:12:31 GMT Received: by mail-control.mail.uu.net id QQkmoi01928 for mpls-outgoing; Fri, 27 Apr 2001 13:11:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmoi01882 for ; Fri, 27 Apr 2001 13:11:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmoi25702 for ; Fri, 27 Apr 2001 13:10:25 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmoi17701 for ; Fri, 27 Apr 2001 13:10:24 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA17811 for mpls@uu.net; Fri, 27 Apr 2001 09:10:24 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmoi01114 for ; Fri, 27 Apr 2001 13:09:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmoi18877 for ; Fri, 27 Apr 2001 13:07:19 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQkmoi04956 for ; Fri, 27 Apr 2001 13:07:19 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA22756 for ; Fri, 27 Apr 2001 09:06:11 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (rtp-dial-2-171.cisco.com [10.83.96.171]) by bucket.cisco.com (Mirapoint) with ESMTP id ABA03656; Fri, 27 Apr 2001 09:07:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20010427090746.01956b48@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Apr 2001 09:08:43 -0400 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: missing drafts/RFCs from MPLS web site Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Has anyone else noticed the absence of all of the MPLS-related drafts from the MPLS IETF web site? http://www.ietf.org/html.charters/mpls-charter.html It appears that this is the case with CCAMP and other WGs too. --Tom From owner-mpls@UU.NET Fri Apr 27 09:27:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28340 for ; Fri, 27 Apr 2001 09:27:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoj26626; Fri, 27 Apr 2001 13:27:43 GMT Received: by mail-control.mail.uu.net id QQkmoj03696 for mpls-outgoing; Fri, 27 Apr 2001 13:27:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmoj03684 for ; Fri, 27 Apr 2001 13:27:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmoj25174 for ; Fri, 27 Apr 2001 13:25:59 GMT Received: from malmo.trab.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQkmoj17000 for ; Fri, 27 Apr 2001 13:25:58 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f3RDPsu01014; Fri, 27 Apr 2001 15:25:54 +0200 (MEST) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Fri, 27 Apr 2001 15:25:53 +0200 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D02254421@trab-hermes.haninge.trab.se> From: Nhat Thanh Hoang To: "'Thomas D. Nadeau'" , mpls@UU.NET Subject: RE: missing drafts/RFCs from MPLS web site Date: Fri, 27 Apr 2001 15:25:52 +0200 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 Hi, Me too. I have noticed that every RFC and I-D are missing under the whole the Sub-IP area. /Nhat Thanh -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: den 27 april 2001 15:09 To: mpls@UU.NET Subject: missing drafts/RFCs from MPLS web site Has anyone else noticed the absence of all of the MPLS-related drafts from the MPLS IETF web site? http://www.ietf.org/html.charters/mpls-charter.html It appears that this is the case with CCAMP and other WGs too. --Tom From owner-mpls@UU.NET Fri Apr 27 09:28:50 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28426 for ; Fri, 27 Apr 2001 09:28:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoj28260; Fri, 27 Apr 2001 13:28:49 GMT Received: by mail-control.mail.uu.net id QQkmoj03703 for mpls-outgoing; Fri, 27 Apr 2001 13:27:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmoj03689 for ; Fri, 27 Apr 2001 13:27:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmoj24631 for ; Fri, 27 Apr 2001 13:25:47 GMT Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQkmoj03386 for ; Fri, 27 Apr 2001 13:25:47 GMT Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id JAA07275; Fri, 27 Apr 2001 09:25:43 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Fri, 27 Apr 2001 09:25:44 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Apr 2001 09:25:46 -0400 Message-ID: <03E3E0690542D211A1490000F80836F4051EBDE2@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'mpls@UU.NET'" Subject: RE: Two signalling protocols (LDP & RSVP) Date: Fri, 27 Apr 2001 09:25:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CF1D.8FDD9A80" 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_01C0CF1D.8FDD9A80 Content-Type: text/plain http://search.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-01.txt Allows you to query the route with CR-LDP. It also allows you to query the exact labels used at every hop and in the case of a SONET/SDH trail will give you down to the timeslot level. You can also query available bandwidth on the traversed interfaces. Cheers, Peter Ashwood-Smith > Hi, > > Is there any practical reason that the signalling protocols (LDP & RSVP) is > supported on the same interface? > Although both CR-LDP and RSVP-TE provides similar functionalities, but one significant reason why we would like to run both the protocols on the same interface can be that TE-RSVP supports IP record route option using its record route objects.But CR-LDP doesn't support IP record route option. Regards Mohit Goel ------_=_NextPart_001_01C0CF1D.8FDD9A80 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Two signalling protocols (LDP & RSVP)

http://search.ietf.org/internet-drafts/draft-ietf-mpls-ls= p-query-01.txt

Allows you to query the route with = CR-LDP. It also allows you to query the exact labels used at every hop = and in the case of a = SONET/SDH trail will give you down to the timeslot = level. You can also query = available bandwidth on the traversed interfaces.

Cheers,

Peter Ashwood-Smith

    > Hi,
    >
    > Is there any practical reason = that the signalling protocols (LDP & RSVP) is
    > supported on the same = interface?
    >


    Although both CR-LDP and RSVP-TE = provides similar functionalities, but one
    significant reason why we would like = to run both the protocols on the same
    interface can be that TE-RSVP = supports IP record route option using its record
    route objects.But CR-LDP doesn't = support IP record route option.

    Regards
    Mohit Goel

------_=_NextPart_001_01C0CF1D.8FDD9A80-- From owner-mpls@UU.NET Fri Apr 27 09:41:46 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29043 for ; Fri, 27 Apr 2001 09:41:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmok12288; Fri, 27 Apr 2001 13:41:29 GMT Received: by mail-control.mail.uu.net id QQkmok05087 for mpls-outgoing; Fri, 27 Apr 2001 13:40:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmok05064 for ; Fri, 27 Apr 2001 13:40:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmok12333 for ; Fri, 27 Apr 2001 13:37:39 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmok08071 for ; Fri, 27 Apr 2001 13:37:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA20839 for mpls@uu.net; Fri, 27 Apr 2001 09:37:38 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmok04701 for ; Fri, 27 Apr 2001 13:37:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmok22072 for ; Fri, 27 Apr 2001 13:34:53 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQkmok27320 for ; Fri, 27 Apr 2001 13:34:53 GMT Received: from ASIMHA-LAPTOP (dhcp-64-102-48-168.cisco.com [64.102.48.168]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA10304; Fri, 27 Apr 2001 09:31:16 -0400 (EDT) Date: Fri, 27 Apr 2001 09:35:06 -0400 (Eastern Daylight Time) From: Ajay Simha To: Hari Kishan cc: Subject: RE: Address message ? In-Reply-To: Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 26 Apr 2001, Hari Kishan wrote: > > To be more specific, > can it be only the list of all MPLS enabled/capable interface > addresses on that LSR? or can it have something more ? I think it should be the list of all MPLS enabled/capable interfaces and nothing more. These interfaces as I mentioned in my last email get used when the route to a prefix changes. Look at example: 10.0.1 +-------+ A B +-------+ 10.0.2 A=.1 B=.2 RIB On A: Dest prefix: 200.1.1.1 Next hop : 10.0.1.2 LIB on A: Remote lbl : 25, LSR-ID=B Addresses bound to B: 10.0.1.2, 10.0.2.2 LFIB on A: Dest prefix :200.1.1.1 Out label :25 Out Intf :Pos 2/1 Then 10.0.1 link goes down and the routing entry now looks like: Dest prefix: 200.1.1.1 Next hop : 10.0.2.2 Now since the session is up (due to 10.0.2 link), A tries to use same label binding it received from B. Since it is going to send a labeled packet, 10.0.2.2 interface on B better be MPLS enabled. Assumption here is that B is doing per-platform label space. -ajay > > --kishan > > -----Original Message----- > From: Ajay Simha [mailto:asimha@cisco.com] > Sent: Thursday, April 26, 2001 11:25 AM > To: Hari Kishan > Cc: mpls@UU.NET > Subject: Re: Address message ? > > > On Thu, 26 Apr 2001, Hari Kishan wrote: > > > Hi, > > > > What exactly are the addresses a LDP peer > > advertises in it's Address message before > > sending label advertisements? > > > > Is it a list of addresses configured on a > > particular interface or can it be any arbitrary > > list of addresses the peer is configured to > > advertise. > > I would think it should be the addresses that are configured on > interfaces > not arbitrary list of addresses. Because these addresses could be > used > later to dip into the LIB if for example one of the links to that > neighbor > goes away and we continue to have a session. We still want to use the > label bindings this neighbor sent us earlier. > > -ajay > > > > > thanks, > > Kishan > > > > --------------------------------- > > Hari Kishan Desineni, > > Ericsson Inc, > > Data Backbone & Optical Division, > > Santabarbara, > > California - 93117 > > Office:(805) 562 6419 > > Home:(805) 968 1894 > > > > -- > Ajay Simha > MPLS Deployment Engineer > IOS Technology Division > (919) 392-3141 > > "Study as if you were to live forever > Live as if you were to die tomorrow" > > - Mahatma Gandhi > > -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Fri Apr 27 10:20:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00904 for ; Fri, 27 Apr 2001 10:20:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmon24433; Fri, 27 Apr 2001 14:20:40 GMT Received: by mail-control.mail.uu.net id QQkmon28110 for mpls-outgoing; Fri, 27 Apr 2001 14:20:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmon28099 for ; Fri, 27 Apr 2001 14:19:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmon15767 for ; Fri, 27 Apr 2001 14:19:14 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmon22798 for ; Fri, 27 Apr 2001 14:19:14 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA23682 for mpls@uu.net; Fri, 27 Apr 2001 10:19:13 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmon27929 for ; Fri, 27 Apr 2001 14:18:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmon07828 for ; Fri, 27 Apr 2001 14:16:15 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQkmon12170 for ; Fri, 27 Apr 2001 14:16:15 GMT Received: from ASIMHA-LAPTOP (dhcp-64-102-48-168.cisco.com [64.102.48.168]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA13412; Fri, 27 Apr 2001 10:06:08 -0400 (EDT) Date: Fri, 27 Apr 2001 10:09:59 -0400 (Eastern Daylight Time) From: Ajay Simha To: Kireeti Kompella cc: , , , Subject: Re: Two signalling protocols (LDP & RSVP) In-Reply-To: <200104270956.CAA02089@kummer.juniper.net> Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 27 Apr 2001, Kireeti Kompella wrote: > > Although both CR-LDP and RSVP-TE provides similar functionalities, but one > > significant reason why we would like to run both the protocols on the same > > interface can be that TE-RSVP supports IP record route option using its record > > route objects.But CR-LDP doesn't support IP record route option. > > The above seems to be an excellent argument for running RSVP-TE. > It is not (as it stands) a justification for running *both* RSVP > and CR-LDP. Kireeti, Do you think the original question used "LDP" to mean "CR-LDP"? I just assumed they were talking about RFC3036. It would make more sense for folks to have LDP and RSVP on the same interface but may not make much sense to have CR-LDP and RSVP on the same interface. -ajay > > Kireeti. > -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Fri Apr 27 10:31:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01690 for ; Fri, 27 Apr 2001 10:31:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoo05830; Fri, 27 Apr 2001 14:31:09 GMT Received: by mail-control.mail.uu.net id QQkmoo28979 for mpls-outgoing; Fri, 27 Apr 2001 14:30:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmoo28963 for ; Fri, 27 Apr 2001 14:30:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmoo06427 for ; Fri, 27 Apr 2001 14:30:08 GMT Received: from mail-blue.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQkmoo28061 for ; Fri, 27 Apr 2001 14:30:07 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 222104DB79; Fri, 27 Apr 2001 10:30:03 -0400 (EDT) Received: from research.att.com (dhcp145.research.att.com [135.207.28.145]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id KAA15498; Fri, 27 Apr 2001 10:30:02 -0400 (EDT) Message-ID: <3AE98315.98C3E6C9@research.att.com> Date: Fri, 27 Apr 2001 10:32:53 -0400 From: Guangzhi Li X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Internet-Drafts@ietf.org Cc: mpls@UU.NET Subject: Re: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-02.txt References: <200104251116.HAA10842@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Authors: How do you distinguish and in a PATH message for GMPLS (RSVP-TE) ? Do I miss something ? Thanks, -- Guangzhi Internet-Drafts@ietf.org wrote: > 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 : Generalized MPLS Signaling - RSVP-TE Extensions > Author(s) : P. Ashwood-Smith et al. > Filename : draft-ietf-mpls-generalized-rsvp-te-02.txt > Pages : 23 > Date : 24-Apr-01 > > This document describes extensions to RSVP-TE signaling required to > support Generalized MPLS. Generalized MPLS extends MPLS to encompass > time-division (e.g. SONET ADMs), wavelength (optical lambdas) and > spatial switching (e.g. incoming port or fiber to outgoing port or > fiber). This document presents an RSVP-TE specific description of > the extensions. A CR-LDP specific description can be found in > [GMPLS-LDP]. A generic functional description is presented in > [GMPLS-SIG]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-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-generalized-rsvp-te-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-generalized-rsvp-te-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. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20010424133612.I-D@ietf.org> From owner-mpls@UU.NET Fri Apr 27 10:41:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02386 for ; Fri, 27 Apr 2001 10:41:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoo11124; Fri, 27 Apr 2001 14:41:20 GMT Received: by mail-control.mail.uu.net id QQkmoo29710 for mpls-outgoing; Fri, 27 Apr 2001 14:40:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmoo29702 for ; Fri, 27 Apr 2001 14:40:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmoo04368 for ; Fri, 27 Apr 2001 14:40:17 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmoo22080 for ; Fri, 27 Apr 2001 14:40:16 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA25876 for mpls@uu.net; Fri, 27 Apr 2001 10:40:16 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmoo29309 for ; Fri, 27 Apr 2001 14:35:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmoo06411 for ; Fri, 27 Apr 2001 14:35:32 GMT Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQkmoo04277 for ; Fri, 27 Apr 2001 14:35:32 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21) id <2X8CPJC4>; Fri, 27 Apr 2001 10:30:10 -0400 Message-ID: <87009604743AD411B1F600508BA0F9595ECD42@XOVER.dedham.mindspeed.com> From: "Sanford, Bill" To: "'mgoel@hss.hns.com'" Cc: mpls@UU.NET Subject: RE: Two signalling protocols (LDP & RSVP) Date: Fri, 27 Apr 2001 10:30:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Mohit, What document has path "reoptimization" in it? How are you defining it? In 4.7.2. Format with resource affinities (draft-ietf-mpls-rsvp-lsp-tunnel-08.txt), doesn't it state that "A transit router can reroute traffic for fast service restoration"? Bill > > > Although both CR-LDP and RSVP-TE provides similar > functionalities, but one > >> significant reason why we would like to run both the > protocols on the same > >> interface can be that TE-RSVP supports IP record route > option using its > record > >> route objects.But CR-LDP doesn't support IP record route option. > >>Mohit > > >The above seems to be an excellent argument for running RSVP-TE. > >It is not (as it stands) a justification for running *both* RSVP > >and CR-LDP. > > >Kireeti. > > CR-LDP supports path reoptimization which means that it has > the capability to > repath loosely routed LSPs based on traffic pattern changes. > But RSVP-TE does > not support the feature of path reoptimization. > > Mohit > > > > From owner-mpls@UU.NET Fri Apr 27 10:54:55 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03143 for ; Fri, 27 Apr 2001 10:54:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmop00880; Fri, 27 Apr 2001 14:54:48 GMT Received: by mail-control.mail.uu.net id QQkmop01548 for mpls-outgoing; Fri, 27 Apr 2001 14:54:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmop01506 for ; Fri, 27 Apr 2001 14:54:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmop13534 for ; Fri, 27 Apr 2001 14:53:50 GMT Received: from bgslc02.TBG.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQkmop06621 for ; Fri, 27 Apr 2001 14:53:50 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Apr 2001 08:40:08 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE70146DA98@BGSLC02> From: Irwin Lazar To: "'Arturo Nunez'" Cc: "'mpls@uu.net'" Subject: RE: MPLS SWITCH OVER LINUX ?? Date: Fri, 27 Apr 2001 08:40:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0CF27.F482283E" 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_01C0CF27.F482283E Content-Type: text/plain; charset="iso-8859-1" See: http://www.mplsrc.com/vendor.shtml in the "shareware" section -----Original Message----- From: Arturo Nunez [mailto:artnpp@cs.ucf.edu] Sent: Wednesday, April 25, 2001 5:41 PM To: mpls@UU.NET Subject: MPLS SWITCH OVER LINUX ?? Hello: Does anybody know about any free implemmentation of MPLS over Linux ?? As a matter of fact there is one for ATM. Any comments I will be glad to receive. Best Regards Arturo Nunez ------_=_NextPart_000_01C0CF27.F482283E Content-Type: application/octet-stream; name="Irwin Lazar.vcf" Content-Disposition: attachment; filename="Irwin Lazar.vcf" BEGIN:VCARD VERSION:2.1 N:Lazar;Irwin FN:Irwin Lazar ORG:The Burton Group;Consulting TITLE:Consultant NOTE:Burton Group Staff TEL;WORK;VOICE:(703) 742-9659 TEL;CELL;VOICE:703-402-4119 ADR;WORK:;Sterling;45615 Willow Pond Plaza;Sterling;VA;20164;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Sterling=0D=0A45615 Willow Pond Plaza=0D=0ASterling, VA 20164=0D=0AUSA EMAIL;PREF;INTERNET:ILazar@tbg.com REV:20010108T223605Z END:VCARD ------_=_NextPart_000_01C0CF27.F482283E-- From owner-mpls@UU.NET Fri Apr 27 11:09:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03940 for ; Fri, 27 Apr 2001 11:09:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoq16686; Fri, 27 Apr 2001 15:09:16 GMT Received: by mail-control.mail.uu.net id QQkmoq22400 for mpls-outgoing; Fri, 27 Apr 2001 15:08:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmoq22380 for ; Fri, 27 Apr 2001 15:08:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmoq20584 for ; Fri, 27 Apr 2001 15:06:39 GMT Received: from china.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: TCE-E-7-182-12.bta.net.cn [202.106.182.12]) id QQkmoq20530 for ; Fri, 27 Apr 2001 15:06:38 GMT Received: from china.com([10.1.7.101]) by china.com(AIMC 2.9.5.1) with SMTP id jm93ae9f8a6; Fri, 27 Apr 2001 22:58:26 +0800 Received: from host.secure4-hosting.net([209.239.41.31]) by china.com(AIMC 2.9.5.1) with SMTP id jmb3ae78f61; Thr, 26 Apr 2001 05:57:07 +0800 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3PIrjL16733 for sehcheok@china.com; Wed, 25 Apr 2001 14:53:45 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-ID: <009701c0cdb6$4efcb4a0$5b5da4d0@kentyu> Reply-To: "Kent Yu" From: "Kent Yu" To: , , "MP LS" Subject: Fw: MPLS Trafficdriven Date: Wed, 25 Apr 2001 14:34:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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.50.4133.2400 X-Mailing-List: archive/latest/1056 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Niels, If you are asking traffic driven LSP, there are many docs you could find from the web. Some vendors, as Ashwin mentioned Lucent IP Navigator in his reply, already integrated this feature. It is hard to imagine a instantly traffic-driven network can be useful in the real world, one of the solutions probably is the LSR keeps track the taffic state of the whole network, we give it a configurable time syntax so it will compute and setup LSPs upon each calculation periodically. The network could be unstable and unpredictable, especially when you add the bypass and backup links. Probably we could get a decent optimization on the fly to some extend at some time, but this needs to verified and justified in the real world. As for the MPLS to the desktop, I am not sure it is necessary, IMHO, current IGPs are sufficient for enterprise users. Kent Yu Lucent Technologies Worldwide Services > ----- Original Message ----- > From: "MP LS" > To: ; > Sent: Wednesday, April 25, 2001 8:29 AM > Subject: MPLS Trafficdriven > > > > Hello all, > > > > I have a question. Is there any possibile way to create a fully dynamical > > Traffic driven MPLS network. So that when any packet arives at an LSR it > > will analyse the IP pakket ads a label in front of it with it combines to > a > > FEC and then just sent it to the Destination LSR? Just till now i only > > found that you have to ask for an LSP manualy and then the data can be > > transported over it. > > > > I hope someone can make this clear for me. > > > > Kind regards, > > > > Niels Sitters > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Fri Apr 27 11:23:13 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04577 for ; Fri, 27 Apr 2001 11:23:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmor14493; Fri, 27 Apr 2001 15:23:12 GMT Received: by mail-control.mail.uu.net id QQkmor24174 for mpls-outgoing; Fri, 27 Apr 2001 15:22:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmor24154 for ; Fri, 27 Apr 2001 15:22:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmor06850 for ; Fri, 27 Apr 2001 15:21:54 GMT Received: from mail2.packetengines.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail2.packetengines.com [208.227.187.173]) id QQkmor12607 for ; Fri, 27 Apr 2001 15:21:54 GMT Received: from hostr607.alcatel.com by mail2.packetengines.com via smtpd (for cmr2.ash.ops.us.uu.net [198.5.241.40]) with SMTP; 27 Apr 2001 15:21:54 UT Received: by steam.corp.packetengines.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Apr 2001 08:18:43 -0700 Message-ID: From: Marc Lewis To: mpls@UU.NET Subject: Determining the Ingress IP address in an RSVP session Date: Fri, 27 Apr 2001 08:18:42 -0700 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 Several recent messages have concerned the issue of how to discern the Ingress LSR's IP address. Though it is true that some routers seem to put it in the Extended Tunnel ID field of the SESSION object, draft-ietf-mpls-rsvp-lsp-tunnel-08 does not require it. Furthermore, RFC2205 is not terribly clear about what the phrase "a sender" means, which is used repeatedly in describing the workings of RSVP message objects. Assuming it means the Ingress LSR (the original sender) leads to one interpretation, and assuming it means the LSR that sent the message being examined (simply an RSVP peer, not necessarily the Ingress LSR) leads to another interpretation. I suspect, but am not certain, the latter assumption is the correct one. It does seem reasonably unambiguous, however, that the Ingress and Egress IP addresses are reliably to be found as the source and destination addresses, respectively, of the IP header of PATH messages. Quoting from 3.1.3 in RFC2205: "Each message contains a sender descriptor defining one sender, and carries the original sender's IP address as its IP source address". From owner-mpls@UU.NET Fri Apr 27 11:25:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04840 for ; Fri, 27 Apr 2001 11:25:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmor18309; Fri, 27 Apr 2001 15:25:21 GMT Received: by mail-control.mail.uu.net id QQkmor24270 for mpls-outgoing; Fri, 27 Apr 2001 15:24:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmor24265 for ; Fri, 27 Apr 2001 15:24:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmor21734 for ; Fri, 27 Apr 2001 15:17:30 GMT Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQkmor27447 for ; Fri, 27 Apr 2001 15:17:28 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21) id <2X8CPJFH>; Fri, 27 Apr 2001 11:12:07 -0400 Message-ID: <87009604743AD411B1F600508BA0F95971BAAC@XOVER.dedham.mindspeed.com> From: "Saha, Sayandeb" To: "'Guangzhi Li'" Cc: mpls@UU.NET Subject: RE: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-02.txt Date: Fri, 27 Apr 2001 11:12:07 -0400 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 Guangzhi, and have different class numbers. They are two separate objects, though their format is identical to a generalized label -Sayan -----Original Message----- From: Guangzhi Li [mailto:gli@research.att.com] Sent: Friday, April 27, 2001 10:33 AM To: Internet-Drafts@ietf.org Cc: mpls@UU.NET Subject: Re: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-02.txt Authors: How do you distinguish and in a PATH message for GMPLS (RSVP-TE) ? Do I miss something ? Thanks, -- Guangzhi Internet-Drafts@ietf.org wrote: > 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 : Generalized MPLS Signaling - RSVP-TE Extensions > Author(s) : P. Ashwood-Smith et al. > Filename : draft-ietf-mpls-generalized-rsvp-te-02.txt > Pages : 23 > Date : 24-Apr-01 > > This document describes extensions to RSVP-TE signaling required to > support Generalized MPLS. Generalized MPLS extends MPLS to encompass > time-division (e.g. SONET ADMs), wavelength (optical lambdas) and > spatial switching (e.g. incoming port or fiber to outgoing port or > fiber). This document presents an RSVP-TE specific description of > the extensions. A CR-LDP specific description can be found in > [GMPLS-LDP]. A generic functional description is presented in > [GMPLS-SIG]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-02.t xt > > 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-generalized-rsvp-te-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-generalized-rsvp-te-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. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20010424133612.I-D@ietf.org> From owner-mpls@UU.NET Fri Apr 27 12:14:11 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07323 for ; Fri, 27 Apr 2001 12:14:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmou11308; Fri, 27 Apr 2001 16:14:04 GMT Received: by mail-control.mail.uu.net id QQkmou18027 for mpls-outgoing; Fri, 27 Apr 2001 16:13:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmou17878 for ; Fri, 27 Apr 2001 16:13:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmou09124 for ; Fri, 27 Apr 2001 16:13:07 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkmou02947 for ; Fri, 27 Apr 2001 16:13:07 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA13718; Fri, 27 Apr 2001 09:13:06 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id JAA03452; Fri, 27 Apr 2001 09:13:06 -0700 (PDT) Date: Fri, 27 Apr 2001 09:13:06 -0700 (PDT) From: Kireeti Kompella Message-Id: <200104271613.JAA03452@kummer.juniper.net> To: asimha@cisco.com, kireeti@juniper.net Subject: Re: Two signalling protocols (LDP & RSVP) Cc: eosborne@cisco.com, gluo@nortelnetworks.com, mgoel@hss.hns.com, mpls@UU.NET In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk > Do you think the original question used "LDP" to mean "CR-LDP"? I don't think so, but the previous poster switched subjects. I agree completely, it makes perfect sense to run LDP and RSVP-TE on the same interfaces (depending on your applications), whereas running RSVP-TE and CR-LDP in the same network, let alone on the same interfaces, seems to be inviting gratuitous complexity. Kireeti. From owner-mpls@UU.NET Fri Apr 27 12:20:57 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07495 for ; Fri, 27 Apr 2001 12:20:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmov18960; Fri, 27 Apr 2001 16:20:52 GMT Received: by mail-control.mail.uu.net id QQkmov18823 for mpls-outgoing; Fri, 27 Apr 2001 16:20:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmov18813 for ; Fri, 27 Apr 2001 16:20:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmov04835 for ; Fri, 27 Apr 2001 16:17:09 GMT Received: from caip.rutgers.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: caip.rutgers.edu [128.6.236.10]) id QQkmov14809 for ; Fri, 27 Apr 2001 16:17:09 GMT Received: (from senthil@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id MAA00526; Fri, 27 Apr 2001 12:17:01 -0400 (EDT) Date: Fri, 27 Apr 2001 12:17:01 -0400 (EDT) From: Senthilkumar Rajasekharan To: mgoel@hss.hns.com cc: Kireeti Kompella , mpls@UU.NET Subject: Re: Two signalling protocols (LDP & RSVP) In-Reply-To: <65256A3B.0039FBD5.00@sandesh.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, > > >The above seems to be an excellent argument for running RSVP-TE. > >It is not (as it stands) a justification for running *both* RSVP > >and CR-LDP. > > >Kireeti. > > CR-LDP supports path reoptimization which means that it has the capability to > repath loosely routed LSPs based on traffic pattern changes. But RSVP-TE does > not support the feature of path reoptimization. Is this your own interpretation or is there a spec which explains on how this can be done ?? Further I thought both CR-LDP and RSVP-TE supported strict/loose explicit routes. Please clarify. -Senthil > > Mohit > > > > > From owner-mpls@UU.NET Fri Apr 27 13:02:18 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08582 for ; Fri, 27 Apr 2001 13:02:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoy27315; Fri, 27 Apr 2001 17:01:43 GMT Received: by mail-control.mail.uu.net id QQkmoy26343 for mpls-outgoing; Fri, 27 Apr 2001 17:01:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmoy26033 for ; Fri, 27 Apr 2001 17:00:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmoy08793 for ; Fri, 27 Apr 2001 17:00:04 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmoy20959 for ; Fri, 27 Apr 2001 17:00:03 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3RH02Z06255 for ; Fri, 27 Apr 2001 10:00:02 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA01830 for mpls@uu.net; Fri, 27 Apr 2001 13:00:00 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmlv20857 for ; Thu, 26 Apr 2001 20:58:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmlv06540 for ; Thu, 26 Apr 2001 20:57:25 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkmlv15399 for ; Thu, 26 Apr 2001 20:57:24 GMT Received: from kishan (devdhcp6211.dev.acc.am.ericsson.se [129.192.62.11]) by acc.com (8.11.1/8.11.1) with SMTP id f3QKt1509681; Thu, 26 Apr 2001 13:55:01 -0700 (PDT) Reply-To: From: "Hari Kishan" To: "Ajay Simha" Cc: Subject: RE: Address message ? Date: Thu, 26 Apr 2001 13:53:22 -0700 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.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit To be more specific, can it be only the list of all MPLS enabled/capable interface addresses on that LSR? or can it have something more ? --kishan -----Original Message----- From: Ajay Simha [mailto:asimha@cisco.com] Sent: Thursday, April 26, 2001 11:25 AM To: Hari Kishan Cc: mpls@UU.NET Subject: Re: Address message ? On Thu, 26 Apr 2001, Hari Kishan wrote: > Hi, > > What exactly are the addresses a LDP peer > advertises in it's Address message before > sending label advertisements? > > Is it a list of addresses configured on a > particular interface or can it be any arbitrary > list of addresses the peer is configured to > advertise. I would think it should be the addresses that are configured on interfaces not arbitrary list of addresses. Because these addresses could be used later to dip into the LIB if for example one of the links to that neighbor goes away and we continue to have a session. We still want to use the label bindings this neighbor sent us earlier. -ajay > > thanks, > Kishan > > --------------------------------- > Hari Kishan Desineni, > Ericsson Inc, > Data Backbone & Optical Division, > Santabarbara, > California - 93117 > Office:(805) 562 6419 > Home:(805) 968 1894 > -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Fri Apr 27 13:03:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08604 for ; Fri, 27 Apr 2001 13:03:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoy25860; Fri, 27 Apr 2001 17:03:16 GMT Received: by mail-control.mail.uu.net id QQkmoy02250 for mpls-outgoing; Fri, 27 Apr 2001 17:02:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmoy29238 for ; Fri, 27 Apr 2001 17:01:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmoy01122 for ; Fri, 27 Apr 2001 17:01:07 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmoy22083 for ; Fri, 27 Apr 2001 17:01:07 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3RH1AZ07431 for ; Fri, 27 Apr 2001 10:01:10 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA01840 for mpls@uu.net; Fri, 27 Apr 2001 13:01:05 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmnp04460 for ; Fri, 27 Apr 2001 08:17:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmnp13769 for ; Fri, 27 Apr 2001 08:16:49 GMT Received: from noya.bupt.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQkmnp16495 for ; Fri, 27 Apr 2001 08:16:48 GMT Received: from pluto ([202.112.109.93]) by noya.bupt.edu.cn (8.11.3/8.10.1) with SMTP id f3R8GlR25798 for ; Fri, 27 Apr 2001 16:16:47 +0800 (CST) Message-Id: <200104270816.f3R8GlR25798@noya.bupt.edu.cn> Date: Fri, 27 Apr 2001 16:17:51 +0800 From: Xu Peng To: "mpls@UU.NET" Subject: What are in LIB? X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi,everybody I'am wandering what should be contained in the LIB, and how to represent NHLFE. Anybody can explain it to me? Thanks! Best regards! xupengpeng@263.net From owner-mpls@UU.NET Fri Apr 27 13:04:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08630 for ; Fri, 27 Apr 2001 13:04:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoy27957; Fri, 27 Apr 2001 17:04:21 GMT Received: by mail-control.mail.uu.net id QQkmoy02266 for mpls-outgoing; Fri, 27 Apr 2001 17:02:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmoy29220 for ; Fri, 27 Apr 2001 17:01:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmoy12255 for ; Fri, 27 Apr 2001 17:01:38 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmoy01629 for ; Fri, 27 Apr 2001 17:01:37 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3RH1eZ08139 for ; Fri, 27 Apr 2001 10:01:40 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA01844 for mpls@uu.net; Fri, 27 Apr 2001 13:01:35 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmns15088 for ; Fri, 27 Apr 2001 09:01:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmns18391 for ; Fri, 27 Apr 2001 09:01:43 GMT Received: from carrier1.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: carrier1.net [212.4.193.68]) id QQkmns29762 for ; Fri, 27 Apr 2001 09:01:42 GMT Received: from gblon1s07.carrier1.com ([10.1.9.21]) by carrier1.net (8.9.3/8.9.3) with ESMTP id KAA49844; Fri, 27 Apr 2001 10:01:58 +0100 (BST) Received: by GBLON1S07 with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Apr 2001 10:01:12 +0100 Message-ID: <83189BAB0F57D411A1C400508B6AADBD034086A2@GBLON1S07> From: Ruyter Hill To: "'mpls-ops@mplsrc.com'" , Geoff Bennett , "Hass, Barry" , "Marinzulich, Matias" , "'Ashwin Moranganti'" , "'MP LS'" , MPLS@UU.NET Subject: RE: MPLS Trafficdriven Date: Fri, 27 Apr 2001 10:01:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Geoff It may be worth mentioning here that in MPLS we have the option to completely ignore the TOS bits in the IP packet and write our own COS into the EXP field of the MPLS shim header this can be done either by trusting the settings from the customer or by filtering on TCP/UDP port number to define the traffic type before assigning a class and writing the EXP MPLS traffic is prioritised through the network by the EXP field so if you neglect to configure a copy into or fresh write of the exp field I am not sure what the default behaviour is Can any one answer that question for me Hill -----Original Message----- From: mpls-ops-request@mplsrc.com [mailto:mpls-ops-request@mplsrc.com]On Behalf Of mpls-ops@mplsrc.com Sent: 26 April 2001 08:18 To: Geoff Bennett; Hass, Barry; Marinzulich, Matias; 'Ashwin Moranganti'; 'MP LS'; MPLS@UU.NET; mpls-ops@mplsrc.com Subject: RE: MPLS Trafficdriven geoff, As U mentioned..... "But the problem is how do you recognise the appropriate traffic types." Well we can solve this Problem: In the Ingress Router the ASIC device is already Configured to handle respective Packet types based on Profiles/Policies. End user can set the DSCP field in the transmitted IP packet to the Ingress Router. Now after receiving the IP Packet, Router checks the IP address and the DSCP field then validates via looking into the Port number and other stuff. By the way ASIC must be configured with such stuff to process such Traffic. Hence if somebody is sending email but prtending this is a VoIP packet it can be easily detected and either packet can be dropped or DSCP field changed accordingly. This is completely a configuration issue as to how to set up the ASIC for what type of traffic. SNMP or CLI can be used to configure such things. Hope, this helps........ vola --- Geoff Bennett wrote: > Hi Barry, > Yes it would make sense. But who sets the DSCP field? > > The "end user" can't be allowed to do this because DSCP is used to > prioritise traffic, and everyone would set their traffic to high priority. > > The ideal thing would be to build proxy devices to insert the appropriate > value according to a policy. IMHO the obvious location for such a proxy is > the Ingress LSR. But the problem is how do you recognise the appropriate > traffic types. > > Cheers, > Geoff __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Fri Apr 27 13:05:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08647 for ; Fri, 27 Apr 2001 13:05:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoy29880; Fri, 27 Apr 2001 17:05:19 GMT Received: by mail-control.mail.uu.net id QQkmoy02312 for mpls-outgoing; Fri, 27 Apr 2001 17:02:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmoy00072 for ; Fri, 27 Apr 2001 17:02:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmoy03418 for ; Fri, 27 Apr 2001 17:01:52 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmoy01905 for ; Fri, 27 Apr 2001 17:01:51 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3RH1sZ08361 for ; Fri, 27 Apr 2001 10:01:54 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA01850 for mpls@uu.net; Fri, 27 Apr 2001 13:01:49 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmol07284 for ; Fri, 27 Apr 2001 13:59:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmol16134 for ; Fri, 27 Apr 2001 13:59:34 GMT Received: from mailsrv.coronanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.186.47.7]) id QQkmol23986 for ; Fri, 27 Apr 2001 13:59:33 GMT Received: from hamrick (63.137.88.2 [63.137.88.2]) by mailsrv.coronanetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JRD359LX; Fri, 27 Apr 2001 06:59:57 -0700 From: "Vincent Hamrick" To: Subject: RE: IP Source Route Option Date: Fri, 27 Apr 2001 09:58:04 -0400 Message-ID: <006001c0cf22$15c14800$0808650a@nc.coronanetworks.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) In-Reply-To: <65256A3A.003E6029.00@sandesh.hss.hns.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Could this be a use for the Router Alert label? -V -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of suchauhan@hss.hns.com Sent: Thursday, April 26, 2001 7:21 AM To: mgoel@hss.hns.com Cc: mpls@UU.NET Subject: Re: IP Source Route Option hi mohit! yes that is a definite problem and our point regarding the record route being filled in my the ingress is also not done bacause ingress can not know the IP address of all intermediate LSR's IP addresses. So even that cannot be done. Sorry I dont have the answer to this. My best guess is that these troublesome options cannot be supported for MPLS. Easy after all , eh?! ;o))) ciao sumit mgoel@hss.hns.com on 04/26/2001 04:54:42 PM To: Sumit Chauhan/HSS@HSS cc: mpls@UU.NET Subject: Re: IP Source Route Option Hi Sumit ! But how mpls will handle the IP's Record route option which requires that each intermediate router should insert its IP address in the datagram. MPLS cannot drop that packet simply because record route option is enabled in it. Moreover if explicit routing is there then ingress router can insert the complete IP addresses of the intermediate LSRs in the datagram, but what will happen in the case of hop by hop LSP. Thanks Mohit Goel suchauhan@hss.hns.com on 04/26/2001 04:23:23 PM To: Mohit Goel/HSS@HSS cc: mpls@UU.NET Subject: Re: IP Source Route Option hi mohit! Ideally this thing should be handled at the Ingress LER and he should translate the IP Source Route to MPLS sourse Route by defining a complete path for the packet (means asking the downstream routers for this). The question still hold weight as to what should be done if such a path does not exist at the time of the packet coming in or the path cannot be setup even when requested. My guess is that its best in both cases to discard the packet and send a normal ICMP packet back to source as is normally done. Going a bit deeper we generally use IP Source Routing for testing purposes and not as a means of data path reservation. Hence it might make sense to try and set up the LSP requested starting at the Ingress LER to the Egress LER if possible while holding on to the packet. This does complicate things but I guess if we have to do source routing we have to do this. ;o( regards sumit mgoel@hss.hns.com on 04/26/2001 04:20:06 PM To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: IP Source Route Option Hi All, I have a small doubt. Let an unlabelled IP packet with IP source route option enabled comes in MPLS domain. Let the packet is assigned to a LSP (say numbered 1). While traversing the MPLS domain, packet will not go to the Network layer, thus the LSR in between the ingress LSR and egress LSR cannot insert their IP addresses in the datagram. So does MPLS supports IP source route option or it does not support it? Thanks Mohit Goel From owner-mpls@UU.NET Fri Apr 27 13:07:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08727 for ; Fri, 27 Apr 2001 13:06:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoy07111; Fri, 27 Apr 2001 17:06:53 GMT Received: by mail-control.mail.uu.net id QQkmoy10642 for mpls-outgoing; Fri, 27 Apr 2001 17:06:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmoy02390 for ; Fri, 27 Apr 2001 17:03:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmoy06307 for ; Fri, 27 Apr 2001 17:02:16 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkmoy24015 for ; Fri, 27 Apr 2001 17:02:15 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 KAA13319 for ; Fri, 27 Apr 2001 10:02:40 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA01854 for mpls@uu.net; Fri, 27 Apr 2001 13:02:13 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmoo29079 for ; Fri, 27 Apr 2001 14:32:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmoo24390 for ; Fri, 27 Apr 2001 14:31:48 GMT Received: from mailsrv.coronanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.186.47.7]) id QQkmoo29917 for ; Fri, 27 Apr 2001 14:31:46 GMT Received: from hamrick (63.137.88.2 [63.137.88.2]) by mailsrv.coronanetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JRD359NG; Fri, 27 Apr 2001 07:32:10 -0700 From: "Vincent Hamrick" To: "_MplsWorkgroup \(E-mail\)" Subject: Router Alert label Date: Fri, 27 Apr 2001 10:30:18 -0400 Message-ID: <007101c0cf26$95e084c0$0808650a@nc.coronanetworks.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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit How exactly will the Router Alert label be used? RFC 3032 states that it should be handled like the IP Router Alert Option. Does this mean that this label should just be passed to the IP options code to be processed like the Router Alert Option? Thanks in advance, -V From owner-mpls@UU.NET Fri Apr 27 13:19:58 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09072 for ; Fri, 27 Apr 2001 13:19:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmoz21267; Fri, 27 Apr 2001 17:19:42 GMT Received: by mail-control.mail.uu.net id QQkmoz12976 for mpls-outgoing; Fri, 27 Apr 2001 17:19:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmoz12965 for ; Fri, 27 Apr 2001 17:19:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmoz12194 for ; Fri, 27 Apr 2001 17:17:57 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmoz19266 for ; Fri, 27 Apr 2001 17:17:57 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA11332 for mpls@uu.net; Fri, 27 Apr 2001 13:17:56 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmoy12295 for ; Fri, 27 Apr 2001 17:13:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmoy04752 for ; Fri, 27 Apr 2001 17:12:28 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkmoy11989 for ; Fri, 27 Apr 2001 17:12:28 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA19965; Fri, 27 Apr 2001 10:12:53 -0700 (PDT) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA08252; Fri, 27 Apr 2001 13:12:26 -0400 (EDT) Message-Id: <200104271712.NAA08252@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: harikishan.desineni@ericsson.com cc: "Ajay Simha" , mpls@UU.NET Subject: Re: Address message ? In-reply-to: Your message of "Thu, 26 Apr 2001 13:53:22 PDT." Date: Fri, 27 Apr 2001 13:12:25 -0400 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk > To be more specific, > can it be only the list of all MPLS enabled/capable interface > addresses on that LSR? or can it have something more ? The addresses advertised should be any which can appear as a next hop address in the neighbor's routing table. Bob From owner-mpls@UU.NET Fri Apr 27 16:30:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15165 for ; Fri, 27 Apr 2001 16:30:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmpm21143; Fri, 27 Apr 2001 20:30:24 GMT Received: by mail-control.mail.uu.net id QQkmpl26857 for mpls-outgoing; Fri, 27 Apr 2001 20:29:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmpl26852 for ; Fri, 27 Apr 2001 20:29:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmpl17476 for ; Fri, 27 Apr 2001 20:29:28 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmpl19971 for ; Fri, 27 Apr 2001 20:29:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA21297 for mpls@uu.net; Fri, 27 Apr 2001 16:29:27 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmpl26807 for ; Fri, 27 Apr 2001 20:29:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmpl12488 for ; Fri, 27 Apr 2001 20:27:41 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmpl09157 for ; Fri, 27 Apr 2001 20:27:40 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3RKRdZ27637; Fri, 27 Apr 2001 13:27:39 -0700 (PDT) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA09155; Fri, 27 Apr 2001 16:27:38 -0400 (EDT) Message-Id: <200104272027.QAA09155@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: harikishan.desineni@ericsson.com, "Ajay Simha" , mpls@UU.NET Subject: Re: Address message ? In-reply-to: Your message of "Fri, 27 Apr 2001 13:12:25 EDT." Date: Fri, 27 Apr 2001 16:27:38 -0400 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk > > To be more specific, > > can it be only the list of all MPLS enabled/capable interface > > addresses on that LSR? or can it have something more ? > > The addresses advertised should be any which can appear as a > next hop address in the neighbor's routing table. Correction: The addresses advertised by router A to router B should be any which can appear in router B's routing table as a next hop address for router A. The issue here is that if router A is an RFC 2547 MPLS VPN PE, it should not be advertise addresses for interfaces which are links to CE routers. (Thanks to Eric Rosen for reminding me of this.) From owner-mpls@UU.NET Fri Apr 27 17:06:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16098 for ; Fri, 27 Apr 2001 17:06:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmpo05324; Fri, 27 Apr 2001 21:06:50 GMT Received: by mail-control.mail.uu.net id QQkmpo08629 for mpls-outgoing; Fri, 27 Apr 2001 21:06:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmpo08374 for ; Fri, 27 Apr 2001 21:06:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmpo11672 for ; Fri, 27 Apr 2001 21:04:38 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmpo01403 for ; Fri, 27 Apr 2001 21:04:37 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA23326 for mpls@uu.net; Fri, 27 Apr 2001 17:04:37 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmpo05119 for ; Fri, 27 Apr 2001 21:04:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmpo17616 for ; Fri, 27 Apr 2001 21:03:52 GMT Received: from che-cse-115.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.140.33]) id QQkmpo17951 for ; Fri, 27 Apr 2001 21:03:52 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id QAA03268; Fri, 27 Apr 2001 16:47:56 -0400 (EDT) Date: Fri, 27 Apr 2001 16:47:56 -0400 From: Eric Osborne To: Kireeti Kompella Cc: asimha@cisco.com, eosborne@cisco.com, gluo@nortelnetworks.com, mgoel@hss.hns.com, mpls@UU.NET Subject: Re: Two signalling protocols (LDP & RSVP) Message-ID: <20010427164755.A3246@che-cse-115.cisco.com> References: <200104271613.JAA03452@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104271613.JAA03452@kummer.juniper.net>; from kireeti@juniper.net on Fri, Apr 27, 2001 at 09:13:06AM -0700 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Fri, Apr 27, 2001 at 09:13:06AM -0700, Kireeti Kompella wrote: > > Do you think the original question used "LDP" to mean "CR-LDP"? > > I don't think so, but the previous poster switched subjects. I > agree completely, it makes perfect sense to run LDP and RSVP-TE > on the same interfaces (depending on your applications), whereas > running RSVP-TE and CR-LDP in the same network, let alone on the > same interfaces, seems to be inviting gratuitous complexity. Except in multi-vendor networks, where one vendor does RSVP and the other does CR-LDP: C / A---B \ D If C does only CR-LDP and D does only RSVP, then A may need to do both RSVP and CR-LDP on the A<->B link. This would not be the case if B instead did some sort of RSVP<->CR-LDP translation, however. eric From owner-mpls@UU.NET Fri Apr 27 22:31:40 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23829 for ; Fri, 27 Apr 2001 22:31:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmqk24752; Sat, 28 Apr 2001 02:31:10 GMT Received: by mail-control.mail.uu.net id QQkmqk03798 for mpls-outgoing; Sat, 28 Apr 2001 02:30:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmqk03709 for ; Sat, 28 Apr 2001 02:30:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmqj11176 for ; Sat, 28 Apr 2001 02:29:10 GMT Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQkmqj17428 for ; Sat, 28 Apr 2001 02:29:10 GMT Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id WAA01280; Fri, 27 Apr 2001 22:29:07 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 27 Apr 2001 22:29:08 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Apr 2001 22:29:09 -0400 Message-ID: <03E3E0690542D211A1490000F80836F4051EBDEA@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'mgoel@hss.hns.com'" , mpls@UU.NET Subject: RE: IP Source Route Option Date: Fri, 27 Apr 2001 22:29:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CF8B.003EBFD0" 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_01C0CF8B.003EBFD0 Content-Type: text/plain; charset="iso-8859-1" I assume it would be placed on the appropriate LSP as normal. Then, when it popped off the LSP it would route again, as usual. So, if the source route were not carefully structured to take the LSP into account it could take you all the way back to say the second router along the LSP, which would then put you on possibly the same LSP. You would then pop off the end of the LSP and be returned by normal routing to possibly the third router along the LSP ... kind of neat but undesirable behaviour. Anyway, source routing and MPLS LSP's are somewhat orthogonal but source routing would I presume work if you did not specify any of the routers along which the LSP already flowed in the source route, otherwise it would loop around a bit before getting to its destination. Cheers, Peter Ashwood-Smith -----Original Message----- From: mgoel@hss.hns.com [SMTP:mgoel@hss.hns.com] Sent: Thursday, April 26, 2001 6:50 AM To: mpls@UU.NET Subject: IP Source Route Option Hi All, I have a small doubt. Let an unlabelled IP packet with IP source route option enabled comes in MPLS domain. Let the packet is assigned to a LSP (say numbered 1). While traversing the MPLS domain, packet will not go to the Network layer, thus the LSR in between the ingress LSR and egress LSR cannot insert their IP addresses in the datagram. So does MPLS supports IP source route option or it does not support it? Thanks Mohit Goel ------_=_NextPart_001_01C0CF8B.003EBFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IP Source Route Option

I assume it would be placed on the = appropriate LSP as normal. Then, when it popped off the LSP it would = route again, as usual. So, if the source route were not carefully = structured to take the LSP into account it could take you all the way = back to say the second router along the LSP, which would then put you = on possibly the same LSP. You would then pop off the end of the LSP and = be returned by normal routing to possibly the third router along the = LSP ... kind of neat but undesirable behaviour.

Anyway, source routing and MPLS LSP's = are somewhat orthogonal but source routing would I presume work if you = did not specify any of the routers along which the LSP already flowed = in the source route, otherwise it would loop around a bit before = getting to its destination.

Cheers,

Peter Ashwood-Smith

    -----Original = Message-----
    From:   = mgoel@hss.hns.com [SMTP:mgoel@hss.hns.com]
    Sent:   Thursday, April 26, 2001 6:50 AM
    To:     mpls@UU.NET
    Subject:       = IP Source Route Option



    Hi All,

    I have a small doubt. Let an = unlabelled IP packet with IP source route option
    enabled comes in MPLS domain. Let the = packet is assigned to a LSP (say numbered
    1). While traversing the MPLS domain, = packet will not go to the Network layer,
    thus the LSR in between the ingress = LSR and egress LSR cannot insert their IP
    addresses in the datagram. So does = MPLS supports IP source route option or it
    does not support it?

    Thanks
    Mohit Goel

------_=_NextPart_001_01C0CF8B.003EBFD0-- From owner-mpls@UU.NET Sat Apr 28 06:32:10 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12416 for ; Sat, 28 Apr 2001 06:32:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmrq27980; Sat, 28 Apr 2001 10:32:04 GMT Received: by mail-control.mail.uu.net id QQkmrq24574 for mpls-outgoing; Sat, 28 Apr 2001 10:31:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmrq24555 for ; Sat, 28 Apr 2001 10:31:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmrp19352 for ; Sat, 28 Apr 2001 10:29:25 GMT Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQkmrp12041 for ; Sat, 28 Apr 2001 10:29:24 GMT Received: from tomp.smb.utfors.se ([127.0.0.1]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GCHZWR00.QO5; Sat, 28 Apr 2001 12:31:39 +0200 From: "Loa Andersson" To: Eric Osborne Cc: Kireeti Kompella , asimha@cisco.com, eosborne@cisco.com, gluo@nortelnetworks.com, mgoel@hss.hns.com, mpls@UU.NET, loa.andersson@utfors.se Message-ID: <5a02a57851.578515a02a@tomp.smb.utfors.se> Date: Sat, 28 Apr 2001 12:31:39 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: Two signalling protocols (LDP & RSVP) X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, I pointed this out in a "off the list" mail to Gang Luo, you could even have C and D over the same interface on shared media. It is technical possible. This said an operator that has e.g. RSVP-TE and LDP in the network would hardly introduce equipment that requires introducing another signalling protcol and won't give you any major advantages. In the case below, running A,B and D on RSVP-TE, C would have to stay out of my network. Permanetly. I think Kireetis point is valid. Off load complexity when possible. /Loa ----- Original Message ----- From: Eric Osborne Date: Friday, April 27, 2001 10:47 pm Subject: Re: Two signalling protocols (LDP & RSVP) > On Fri, Apr 27, 2001 at 09:13:06AM -0700, Kireeti Kompella wrote: > > > Do you think the original question used "LDP" to mean "CR-LDP"? > > > > I don't think so, but the previous poster switched subjects. I > > agree completely, it makes perfect sense to run LDP and RSVP-TE > > on the same interfaces (depending on your applications), whereas > > running RSVP-TE and CR-LDP in the same network, let alone on the > > same interfaces, seems to be inviting gratuitous complexity. > > > Except in multi-vendor networks, where one vendor does RSVP and the > other does CR-LDP: > > > C > / > A---B > \ > D > > If C does only CR-LDP and D does only RSVP, then A may need to do > both > RSVP and CR-LDP on the A<->B link. This would not be the case if B > instead did some sort of RSVP<->CR-LDP translation, however. > > > > eric > > From owner-mpls@UU.NET Sat Apr 28 10:23:40 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14085 for ; Sat, 28 Apr 2001 10:23:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmsf16111; Sat, 28 Apr 2001 14:23:34 GMT Received: by mail-control.mail.uu.net id QQkmsf04345 for mpls-outgoing; Sat, 28 Apr 2001 14:23:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmsf04333 for ; Sat, 28 Apr 2001 14:22:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmsf12101 for ; Sat, 28 Apr 2001 14:21:45 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmsf24376 for ; Sat, 28 Apr 2001 14:21:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA24967 for mpls@uu.net; Sat, 28 Apr 2001 10:21:44 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmsf04218 for ; Sat, 28 Apr 2001 14:21:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmsf11991 for ; Sat, 28 Apr 2001 14:20:17 GMT Received: from che-cse-115.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.140.33]) id QQkmsf29678 for ; Sat, 28 Apr 2001 14:20:16 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id KAA04088; Sat, 28 Apr 2001 10:18:43 -0400 (EDT) Date: Sat, 28 Apr 2001 10:18:43 -0400 From: Eric Osborne To: Loa Andersson Cc: Eric Osborne , Kireeti Kompella , asimha@cisco.com, gluo@nortelnetworks.com, mgoel@hss.hns.com, mpls@UU.NET Subject: Re: Two signalling protocols (LDP & RSVP) Message-ID: <20010428101843.A4072@che-cse-115.cisco.com> References: <5a02a57851.578515a02a@tomp.smb.utfors.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5a02a57851.578515a02a@tomp.smb.utfors.se>; from loa.andersson@utfors.se on Sat, Apr 28, 2001 at 12:31:39PM +0200 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Sat, Apr 28, 2001 at 12:31:39PM +0200, Loa Andersson wrote: > > Eric, > > I pointed this out in a "off the list" mail to Gang Luo, you > could even have C and D over the same interface on shared > media. It is technical possible. > > This said an operator that has e.g. RSVP-TE and LDP in the > network would hardly introduce equipment that requires introducing > another signalling protcol and won't give you any major > advantages. > In the case below, running A,B and D on RSVP-TE, C would have > to stay out of my network. Permanetly. > I think Kireetis point is valid. Off load complexity when possible. Sure. I agree completely. I think we're still not sure whether the original question about using RSVP and LDP at the same time, or RSVP and CR-LDP. The former makes more sense as a requirement; the latter, although maybe not the least complex way to do things, is certainly possible. eric > > /Loa > ----- Original Message ----- > From: Eric Osborne > Date: Friday, April 27, 2001 10:47 pm > Subject: Re: Two signalling protocols (LDP & RSVP) > > > On Fri, Apr 27, 2001 at 09:13:06AM -0700, Kireeti Kompella wrote: > > > > Do you think the original question used "LDP" to mean "CR-LDP"? > > > > > > I don't think so, but the previous poster switched subjects. I > > > agree completely, it makes perfect sense to run LDP and RSVP-TE > > > on the same interfaces (depending on your applications), whereas > > > running RSVP-TE and CR-LDP in the same network, let alone on the > > > same interfaces, seems to be inviting gratuitous complexity. > > > > > > Except in multi-vendor networks, where one vendor does RSVP and the > > other does CR-LDP: > > > > > > C > > / > > A---B > > \ > > D > > > > If C does only CR-LDP and D does only RSVP, then A may need to do > > both > > RSVP and CR-LDP on the A<->B link. This would not be the case if B > > instead did some sort of RSVP<->CR-LDP translation, however. > > > > > > > > eric > > > > From owner-mpls@UU.NET Sun Apr 29 16:28:01 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11490 for ; Sun, 29 Apr 2001 16:28:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmwv23379; Sun, 29 Apr 2001 20:27:55 GMT Received: by mail-control.mail.uu.net id QQkmwv12725 for mpls-outgoing; Sun, 29 Apr 2001 20:27:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmwv12714 for ; Sun, 29 Apr 2001 20:27:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmwv18270 for ; Sun, 29 Apr 2001 20:27:05 GMT Received: from sol.extremenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sol.extremenetworks.com [216.52.8.2]) id QQkmwv21790 for ; Sun, 29 Apr 2001 20:27:05 GMT Received: by SOL with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Apr 2001 13:21:02 -0700 Message-ID: <2F5F27915881D411B43F00508BD8935F9D068F@sc-sol-04.extremenetworks.com> From: Paul Billinghurst To: "'mpls@UU.NET'" Subject: Use of NSSAs & Stub areas with downstream unsolicited LDP Date: Sun, 29 Apr 2001 13:23:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Can anyone verify or correct my understanding of the following scenario. The MPLS domain is LDP, configured as downstream unsolicited. When I use the term ABR - I am referring to the ABR of the stub or NSSA area unless I state differently. A router internal to a stub or NSSA potentially will only have an advertisement from ABRs for the default route. If routers internal to the stub area wish to reach destinations for which they do not have a FEC entry then they will have to send the data unlabelled to the ABR. Is that correct ? Is there any mechanism short of static routes which would allow the stub area router(s) to use an LSP to the default route which I assume would be pretty dangerous to use because if there is a default route across the OSPF domain and that LSP is used, then all data from stubs or NSSA would use that LSP whereas the ABRs could make far more intelligent routing decisions if they were not simply swapping labels for the default route. If use of a default route LSP is possible, is there a mechanism which would allow an ABR, to pop the label instead of swapping and making that "intelligent decision" if indeed it does have default route LSP which extends beyond itself into the domain, but it would be better served sending the data on an LSP for which it has a more direct FEC entry. Thanks Paul From owner-mpls@UU.NET Sun Apr 29 16:51:54 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11602 for ; Sun, 29 Apr 2001 16:51:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmwx28504; Sun, 29 Apr 2001 20:51:48 GMT Received: by mail-control.mail.uu.net id QQkmwx14533 for mpls-outgoing; Sun, 29 Apr 2001 20:51:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmwx14528 for ; Sun, 29 Apr 2001 20:51:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmwx12435 for ; Sun, 29 Apr 2001 20:50:55 GMT Received: from penguin-ext.wise.edt.ericsson.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: penguin-ext.wise.edt.ericsson.se [194.237.142.110]) id QQkmwx27424 for ; Sun, 29 Apr 2001 20:50:54 GMT Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f3TKorO13141 for ; Sun, 29 Apr 2001 22:50:53 +0200 (MEST) Received: from ericsson.com (tsgw1c022.exu.ericsson.se [138.85.130.22]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id WAA06237 for ; Sun, 29 Apr 2001 22:50:59 +0200 (MET DST) Message-ID: <3AEC628C.CB3B2AF3@ericsson.com> Date: Sun, 29 Apr 2001 13:50:52 -0500 From: Jean-Luc SCHERER X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Question on "draft-chadha-policy-mpls-te-01.txt" 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 regarding "draft-chadha-policy-mpls-te-01.txt". From what I read in previous messages it seems that the intent of the draft is to provide an information model for network management and TE. This model does not seem to cover static LSPs. For these type of LSPs you need to model In/Out segments and cross-connections as described in draft-ietf-mpls-lsr-07.txt. Is this right or am I missing something? /Jean-Luc From owner-mpls@UU.NET Mon Apr 30 05:23:27 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03306 for ; Mon, 30 Apr 2001 05:23:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmyv14305; Mon, 30 Apr 2001 09:22:55 GMT Received: by mail-control.mail.uu.net id QQkmyv18090 for mpls-outgoing; Mon, 30 Apr 2001 09:22:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmyv18074 for ; Mon, 30 Apr 2001 09:22:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmyv03843 for ; Mon, 30 Apr 2001 09:20:05 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmyv11495 for ; Mon, 30 Apr 2001 09:20:05 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA12331 for mpls@uu.net; Mon, 30 Apr 2001 05:20:04 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmyv17852 for ; Mon, 30 Apr 2001 09:19:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmyv04297 for ; Mon, 30 Apr 2001 09:19:19 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: megha.cisco.com [192.122.173.140]) id QQkmyv09994 for ; Mon, 30 Apr 2001 09:19:17 GMT Received: from jkannan-pc ([192.122.174.196]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id OAA28065 for ; Mon, 30 Apr 2001 14:48:34 +0530 (IST) Message-Id: <200104300918.OAA28065@cisco.com> X-Sender: jkannan@megha.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 30 Apr 2001 14:57:57 +0530 To: mpls@UU.NET From: "J.Kannan" Subject: Question regarding RFC 3031 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi In Section 3.12 ( FEC-To-NHLFE Map (FTN) ) of RFC 3031 , paragraph 2 begins with the following statement : "If the FTN maps a particular label to a set of NHLFEs ..." Shouldn't it be "If the FTN maps a particular FEC to a set of NHLFEs..." since by definition the FTN maps each FEC to a set of NHLFEs. Or is there some other interpretation to this statement ? Thanks Kannan From owner-mpls@UU.NET Mon Apr 30 05:28:23 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03366 for ; Mon, 30 Apr 2001 05:28:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmyv17560; Mon, 30 Apr 2001 09:28:21 GMT Received: by mail-control.mail.uu.net id QQkmyv18552 for mpls-outgoing; Mon, 30 Apr 2001 09:27:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmyv18533 for ; Mon, 30 Apr 2001 09:27:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmyv28043 for ; Mon, 30 Apr 2001 09:27:12 GMT Received: from mail.marhold.at by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.marhold.at [194.152.126.85]) id QQkmyv23229 for ; Mon, 30 Apr 2001 09:27:11 GMT Received: from AMARHOLD ([192.168.1.33]) by mail.marhold.at (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id at; Mon, 30 Apr 2001 11:36:34 +0200 From: "Alexander Marhold" To: , "Paul Billinghurst" Subject: RE: Use of NSSAs & Stub areas with downstream unsolicited LDP Date: Mon, 30 Apr 2001 11:27:40 +0200 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: <2F5F27915881D411B43F00508BD8935F9D068F@sc-sol-04.extremenetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit see inline comments -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Paul Billinghurst >Sent: Sunday, April 29, 2001 10:23 PM >To: 'mpls@UU.NET' >Subject: Use of NSSAs & Stub areas with downstream unsolicited LDP > >Can anyone verify or correct my understanding of the following scenario. The >MPLS domain is LDP, configured as downstream unsolicited. When I use the >term ABR - I am referring to the ABR of the stub or NSSA area unless I state >differently. > >A router internal to a stub or NSSA potentially will only have an >advertisement from ABRs for the default route. If routers internal to the >stub area wish to reach destinations for which they do not have a FEC entry >then they will have to send the data unlabelled to the ABR. Is that correct >? -------------> no a default route is also a FEC, so it sends the labelled packet to the ABR. But this LSP ends at the ABR, which did the summarization. But the ABR has to do a L3 lookup, so he needs a full routing table also for routes external to the cloud. So if the ABR runs the full BGP routing table this works for MPLS ( not for VPN) However this does not work for MPLS/VPN as the packet itself with only SA and DA is not unique and the according destination and the correct VPN cannot be determined ----------------> But you can cheat the system and make it run, I just tested the thing today with Cisco IOS 12.1.5T and it worked perfectly: ----------------> If you make the ABR also a RR for vpnv4 (MP-BGP) and you specify NEXT_HOP_SELF then this node will swap the vpn label , leaving the vpnspecific information okay and the packet can be correctly sent to the destination. For your OSPF multiarea topology you only need to additonally define 2 loopback interfaces ( one in each area ) on the ABR and use the correct ones for the MP-iBGP connections, so that the MP-BGP connection is always within an area. The mechanisms used are the same needed for MPLS/VPN in confederations or for interprovider VPNs. This works exactly like MPLS/VPN in a confederation environment with various IGP domains. I tested this and these are the positive results: the only difference is that I did not have 2 IGPs running ( so no ABR) but when specifying things as explained above it should also work: CE1------PE3-----GSR1-----GSR2----PE2----CE6 cust label label label cust RR = domainedge CE1: Tracing the route to 194.10.10.54 (=CE6) PE3 1 195.10.10.85 [AS 100] 16 msec 16 msec 16 msec GSR1 2 193.10.10.77 [MPLS: Label 25 Exp 0] 200 msec 196 msec 196 msec GSR2 3 193.10.10.66 [MPLS: Labels 17/27 Exp 0] 184 msec 184 msec 184 msec PE2 4 195.10.10.73 [AS 100] [MPLS: Label 27 Exp 0] 164 msec 344 msec 160 msec CE6 5 195.10.10.74 [AS 100] 72 msec * 76 msec (note the penultimate hop-popping) --- this is the VPN-label table on the domain-edge GSR1 WG1-GSR1#sho ip bgp vpnv4 all tag Network Next Hop In tag/Out tag Route Distinguisher: 100:1 11.0.0.0/24 194.10.10.45 23/26 12.0.0.0/24 194.10.10.44 22/16 194.10.10.48/32 194.10.10.45 27/27 194.10.10.54/32 194.10.10.44 25/27 <--- this is the swap of vpn-label 195.10.10.72/30 194.10.10.44 24/26 195.10.10.84/30 194.10.10.45 26/16 WG1-GSR1#show tag for Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 194.10.10.45/32 0 Se1/0 point2point 17 Pop tag 194.10.10.42/32 0 Se1/3 point2point 18 17 194.10.10.44/32 0 Se1/3 point2point 19 Pop tag 193.10.10.68/30 0 Se1/3 point2point 20 Pop tag 193.10.10.72/30 0 Se1/3 point2point 21 Pop tag 193.10.10.96/30 0 Se1/3 point2point 22 17 100:1:12.0.0.0/24 \ 1228 Se1/3 point2point 23 26 100:1:11.0.0.0/24 \ 744 Se1/0 point2point 24 17 100:1:195.10.10.72/30 \ 0 Se1/3 point2point 25 17 100:1:194.10.10.54/32 \ 456 Se1/3 point2point 26 16 100:1:195.10.10.84/30 \ 0 Se1/0 point2point 27 27 100:1:194.10.10.48/32 \ 1724 Se1/0 point2point this is the MP-BGP table on PE3 (notice the next-hop of 194.10.10.41 which is the GSR) WG1-PE3#sho ip bgp vpnv4 all tag Network Next Hop In tag/Out tag Route Distinguisher: 100:1 (vpn) 11.0.0.0/24 0.0.0.0 26/aggregate(vpn) 12.0.0.0/24 194.10.10.41 notag/22 194.10.10.48/32 195.10.10.86 27/notag 194.10.10.54/32 194.10.10.41 notag/25 195.10.10.72/30 194.10.10.41 notag/24 195.10.10.84/30 0.0.0.0 16/aggregate(vpn) >Is there any mechanism short of static routes which would allow the stub >area router(s) to use an LSP to the default route which >I assume would be pretty dangerous to use because if there is a default >route across the OSPF domain and that LSP is used, then all data from stubs >or NSSA would use that LSP whereas the ABRs could make far more intelligent >routing decisions if they were not simply swapping labels for the default >route. I think the above example solves such a problem, for BGP and MPLS/VPN but generally a stub area is a stubarea and has no optimal interarea routing !!! >If use of a default route LSP is possible, is there a mechanism which would >allow an ABR, to pop the label instead of swapping and making that >"intelligent decision" if indeed it does have default route LSP which >extends beyond itself into the domain, but it would be better served sending >the data on an LSP for which it has a more direct FEC entry. the only important thing is that for external routes in MPLS/VPN you are not allowed to summarize the NEXT-HOP address, so using the above stated trick you stay on next-hop addresses whithin each area and have no problem about summarization of this address. By the way this also proofs that the statement in Pepelnjaks and Guichards book "MPLS and VPN architectures" page 280 is not true (anymore): they stated in the book that the next-hop cannot be changed on a route-reflector and they say that you would need confederations where the confed boundary matches the OSPF area boundaries, which would be another more complicated way of solving the problem as for OSPF the boundary is withina node and for BGP it is between nodes (like in ISIS). with best regards Alexander __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ __/ __/ Dipl.Ing. Alexander Marhold MBA __/ CCIE #3324, CCNP, CCNA, CCDP, CCDA, CCSI #20642 __/ PRO IN __/ Mobile: ++43-(0)664-16 28 234 __/ From owner-mpls@UU.NET Mon Apr 30 06:22:30 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03851 for ; Mon, 30 Apr 2001 06:22:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmyz14632; Mon, 30 Apr 2001 10:22:26 GMT Received: by mail-control.mail.uu.net id QQkmyz12067 for mpls-outgoing; Mon, 30 Apr 2001 10:21:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmyz12062 for ; Mon, 30 Apr 2001 10:21:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmyz13174 for ; Mon, 30 Apr 2001 10:20:27 GMT Received: from localhost.localdomain by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.199.93.15]) id QQkmyz12572 for ; Mon, 30 Apr 2001 10:20:26 GMT Received: from 192.168.57.15 (a1 [192.168.57.21]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id PAA01527; Mon, 30 Apr 2001 15:35:37 +0530 From: "Bhupesh Bajaj" Message-Id: <200104301005.PAA01527@localhost.localdomain> To: , , CC: Reply-To: "Bhupesh Bajaj" Subject: doubt in RFC 3031 Date: Mon, 30 Apr 2001 15:42:10 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk hi all. while going thru RFC 3031 , in Page 18 , second paragraph says... " This technique allows the egress to do a single lookup, and also requires only a single lookup by the penultimate node " isnt the penultimate node going to do a single lookup anyway...? or i have got it all wrong..? according to what i perceived...the penultimate node is going to look into the label which it received and then sends the packet to the next hop according to the information in the label it received with packet...which means ...single lookup.... when would it do a second lookup..? is it referring to the second lookup that the penultimate node will have to do when it wouldnt find the label in the stack which it is expecting ...and it will go for network layer information...? kindly let me know. thanks and regards, bhupesh. Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com From owner-mpls@UU.NET Mon Apr 30 06:49:37 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04153 for ; Mon, 30 Apr 2001 06:49:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzb17606; Mon, 30 Apr 2001 10:49:32 GMT Received: by mail-control.mail.uu.net id QQkmzb14225 for mpls-outgoing; Mon, 30 Apr 2001 10:49:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmzb14217 for ; Mon, 30 Apr 2001 10:48:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzb02994 for ; Mon, 30 Apr 2001 10:47:52 GMT Received: from localhost.localdomain by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.199.93.15]) id QQkmzb10360 for ; Mon, 30 Apr 2001 10:47:51 GMT Received: from 192.168.57.15 (a1 [192.168.57.21]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id QAA02352; Mon, 30 Apr 2001 16:05:04 +0530 From: "Bhupesh Bajaj" Message-Id: <200104301035.QAA02352@localhost.localdomain> To: , CC: , Reply-To: "Bhupesh Bajaj" Subject: RE: doubt in RFC 3031 Date: Mon, 30 Apr 2001 16:11:37 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk thanks asheesh and sumit , but my douubt was that in RFC they have mentioned that... ".. This technique allows the egress to do a single lookup, and also requires only a single lookup by the penultimate node.." to be noticed.." and also requires only a single lookup by penultimate..." which anyways is the case... so as far as penultimate hop is concerned ..it in both cases will be operating in same way i.e looking for the labbel and if not found looking for network information and sending the packet ... so as far as this technique is concerned the benifit one gets is from egress side and penultimate hop will still be having to do the same number of lookups in both cases with / without this technique.. thats all the confusion was , as in the RFC they have mentioned in a way that one gets benifit on penultimate hop lookups also.. anyways..thanks for prompt reply regards bhupesh Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com From owner-mpls@UU.NET Mon Apr 30 06:59:50 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04236 for ; Mon, 30 Apr 2001 06:59:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzb23865; Mon, 30 Apr 2001 10:59:47 GMT Received: by mail-control.mail.uu.net id QQkmzb14900 for mpls-outgoing; Mon, 30 Apr 2001 10:59:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmzb14892 for ; Mon, 30 Apr 2001 10:59:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmzb06368 for ; Mon, 30 Apr 2001 10:58:47 GMT Received: from localhost.localdomain by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.199.93.15]) id QQkmzb21981 for ; Mon, 30 Apr 2001 10:58:46 GMT Received: from 192.168.57.15 (a1 [192.168.57.21]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id QAA02582; Mon, 30 Apr 2001 16:16:24 +0530 From: "Bhupesh Bajaj" Message-Id: <200104301046.QAA02582@localhost.localdomain> To: CC: , Reply-To: "Bhupesh Bajaj" Subject: Re: RE: doubt in RFC 3031 Date: Mon, 30 Apr 2001 16:22:57 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk hello, as far as i believe the penultimate hop is going to behave in same way ( as far as number of lookups is concerned )in both cases with / without using this technique.."penultimate hop popping".. so i believe it needn't be mentioned in RFC that with PNP one gets the benifit of just one lookup from penultimate hop side also as they have mentioned in RFC waiting for comments, thanks and regards, bhupesh Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com From owner-mpls@UU.NET Mon Apr 30 07:04:41 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04282 for ; Mon, 30 Apr 2001 07:04:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzc27238; Mon, 30 Apr 2001 11:04:37 GMT Received: by mail-control.mail.uu.net id QQkmzc28328 for mpls-outgoing; Mon, 30 Apr 2001 11:04:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmzc26538 for ; Mon, 30 Apr 2001 11:03:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmzc05192 for ; Mon, 30 Apr 2001 11:03:50 GMT Received: from localhost.localdomain by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.199.93.15]) id QQkmzc04053 for ; Mon, 30 Apr 2001 11:03:49 GMT Received: from 192.168.57.15 (a1 [192.168.57.21]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id QAA02728; Mon, 30 Apr 2001 16:21:27 +0530 From: "Bhupesh Bajaj" Message-Id: <200104301051.QAA02728@localhost.localdomain> To: CC: , Reply-To: "Bhupesh Bajaj" Subject: Re: Re: megaco/H.248 Date: Mon, 30 Apr 2001 16:28:00 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk hi.. Megaco is a Voip protocol which operates between Gateway and Call Agents( Gateway Controllers) just like MGCP , and H.248 is similar recommendation by ITU. but it isnt competing with SIP or H.323 as its areas of operation is totally different. Megaco Operates betweek Gateways and "Gateway Controllers" while H.323 and Sip Operate between different Gateway Controllers / Call Agents itself . thanks and regards bhupesh. ilazar@earthlink.net wrote: Hi, Megaco is a new VoIP signalling protocol that competes with SIP and H.323. You can find additional information at http://www.itprc.com/voice.htm Irwin At 01:14 PM 4/30/2001 +0530, S.K.Suman wrote: >Hi Everybody, > >I am going through the documents on QoS in MPLS..I came across the term >megaco/H.248 >Can anbody pls explain me,What exactly is megaco/H.248..and How it is >related to MPLS-QoS.. > >Thanks in Advance.. > >Regards >Suman > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com From owner-mpls@UU.NET Mon Apr 30 07:13:12 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05038 for ; Mon, 30 Apr 2001 07:13:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzc13878; Mon, 30 Apr 2001 11:13:07 GMT Received: by mail-control.mail.uu.net id QQkmzc05005 for mpls-outgoing; Mon, 30 Apr 2001 11:12:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmzc04989 for ; Mon, 30 Apr 2001 11:12:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzc23097 for ; Mon, 30 Apr 2001 11:11:42 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmzc04921 for ; Mon, 30 Apr 2001 11:11:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA18735 for mpls@uu.net; Mon, 30 Apr 2001 07:11:42 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmzc04297 for ; Mon, 30 Apr 2001 11:07:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzc00489 for ; Mon, 30 Apr 2001 11:07:02 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQkmzc29925 for ; Mon, 30 Apr 2001 11:07:02 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04732; Mon, 30 Apr 2001 07:07:01 -0400 (EDT) Message-Id: <200104301107.HAA04732@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-09.txt Date: Mon, 30 Apr 2001 07:07:01 -0400 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-09.txt Pages : 53 Date : 27-Apr-01 This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. This solution allows the MPLS network administrator to select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic Engineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-09.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-09.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-09.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: <20010427152759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-diff-ext-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-diff-ext-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010427152759.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Apr 30 08:53:16 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07964 for ; Mon, 30 Apr 2001 08:53:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzj27774; Mon, 30 Apr 2001 12:52:52 GMT Received: by mail-control.mail.uu.net id QQkmzj02506 for mpls-outgoing; Mon, 30 Apr 2001 12:52:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmzj02495 for ; Mon, 30 Apr 2001 12:52:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzj11753 for ; Mon, 30 Apr 2001 12:50:47 GMT Received: from bemigl02.swift.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.swift.com [195.99.94.1]) id QQkmzj08081 for ; Mon, 30 Apr 2001 12:50:47 GMT Date: Mon, 30 Apr 2001 14:52:45 +0200 From: Dirk Maeckelberghe Subject: MPLS TE question To: mpls@UU.NET Message-id: <3AED601D.710F0481@swift.com> Organization: S.W.I.F.T. sc MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en]C-CCK-MCD SWIFT-W60 (WinNT; I) Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6C7359DA439516D3AFC1AD65" X-Accept-Language: en Sender: owner-mpls@UU.NET Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms6C7359DA439516D3AFC1AD65 Content-Type: multipart/mixed; boundary="------------B6F194048246E3D7923ECF64" This is a multi-part message in MIME format. --------------B6F194048246E3D7923ECF64 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Can you point me to the right references or help answer underneath questions. I need to know if I can use the TE extensions to setup an LSP using RSVP-TE ( cross area ) in case my IGP is hierarchical IS-IS ( L1 and L2 ). Can I assume that summarization happens at area boundaries and that the detailed TE info does not get propagated inside the area ? This is case A to B where A,B LER and L2A and L2B LSR A - area 1 - L2A ---- L2X --- L2B - area 2 - B If now I am only extending my MPLS cloud to the L2 routers ( L2A - L2B are now LER ), A and B are NON-MPLS routers, can I then use the TE extensions of IS-IS to do TE between the L2A and L2B. I understand that the L2 routers only form L2 adjacencies, are the TE extensions communicated between them ? A - area 1 - L2A ---- L2X --- L2B - area 2 - B Thanks, Dirk --------------B6F194048246E3D7923ECF64 Content-Type: text/x-vcard; charset=us-ascii; name="Dirk.Maeckelberghe.vcf" Content-Description: Card for Dirk Maeckelberghe Content-Disposition: attachment; filename="Dirk.Maeckelberghe.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Maeckelberghe;Dirk tel;cell:+32 476207502 tel;fax:+32 2 6554339 tel;work:S.W.I.F.T. s.c. x-mozilla-html:FALSE org:Phone: +32 2 6553414;Mobile: +32 476207502 version:2.1 email;internet:Dirk.Maeckelberghe@swift.com title:S.W.I.F.T. Strategy & Architecture dept. - Network Architect adr;quoted-printable:;;Avenue Adele 1=0D=0A;La Hulpe;;B-1310;Belgium fn:Dirk Maeckelberghe end:vcard --------------B6F194048246E3D7923ECF64-- --------------ms6C7359DA439516D3AFC1AD65 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIFGAYJKoZIhvcNAQcCoIIFCTCCBQUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC A7YwggOyMIIDG6ADAgECAgQ3y/YqMA0GCSqGSIb3DQEBBAUAMDQxCzAJBgNVBAYTAkJFMQ4w DAYDVQQKEwVTV0lGVDEVMBMGA1UECxMMSW50cmFuZXQgUEtJMB4XDTAwMDIwNDEzNDgzM1oX DTAyMDIwNDE0MTgzM1owSzELMAkGA1UEBhMCQkUxDjAMBgNVBAoTBXN3aWZ0MQ8wDQYDVQQL EwZQZW9wbGUxGzAZBgNVBAMTEkRpcmsgTWFlY2tlbGJlcmdoZTBcMA0GCSqGSIb3DQEBAQUA A0sAMEgCQQCpHlo3qA+kH98Qjownj4R/9xtKBFP91oN2yHSNdp+CW++NrsoGI3Zi/P2KhF2G IbmuFPFEC5d372qRk0mWciHpAgMBAAGjggH8MIIB+DALBgNVHQ8EBAMCBaAwKwYDVR0QBCQw IoAPMjAwMDAyMDQxNDE4MzNagQ8yMDAxMDYzMDA2MTgzM1owEQYJYIZIAYb4QgEBBAQDAgWg MIGmBglghkgBhvhCAQ0EgZgWgZVUaGUgQ2VydGlmaWNhdGUgUG9saWN5IChDUCkgYW5kIENl cnRpZmljYXRpb24gUHJhY3RpY2UgU3RhdGVtZW50IChDUFMpIHJlbGF0ZWQgdG8gdGhlIHVz YWdlIG9mIHRoaXMgY2VydGlmaWNhdGUgY2FuIGJlIGZvdW5kIGF0IGh0dHA6Ly93d3cuc3dp ZnQuY29tLjAZBgNVHSAEEjAQMAYGBCsVBgYwBgYEKxUGBzAnBgNVHREEIDAegRxkaXJrLm1h ZWNrZWxiZXJnaGVAc3dpZnQuY29tMFYGA1UdHwRPME0wS6BJoEekRTBDMQswCQYDVQQGEwJC RTEOMAwGA1UEChMFU1dJRlQxFTATBgNVBAsTDEludHJhbmV0IFBLSTENMAsGA1UEAxMEQ1JM MjAfBgNVHSMEGDAWgBRSyQxitIPAdsIITu8S9KeLLiUkaDAdBgNVHQ4EFgQUs8VQFKyIKmwW ItXGTSvHuoq66uQwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAKGwRWNC4wAwIDqDANBgkq hkiG9w0BAQQFAAOBgQAq/xv23TwUBOWYwPcXfv+ACSosslsOmPIyecSwDSAD+sP+jZ58Xo+T 6wnVshfcf5c2cI22/fTHheVgE2aUmAUp3+vntK2FPHuaH2xEUNN2kqIaTeDZea0g1YqxmAR4 roN4BO7/PYfsHiLGXB2VIMuNEE0CeHz44GvlDQJJw/ANaTGCASowggEmAgEBMDwwNDELMAkG A1UEBhMCQkUxDjAMBgNVBAoTBVNXSUZUMRUwEwYDVQQLEwxJbnRyYW5ldCBQS0kCBDfL9iow CQYFKw4DAhoFAKCBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wMTA0MzAxMjUyNDVaMCMGCSqGSIb3DQEJBDEWBBRoiDgLdanU/6Iy03jU0wMX0Prw8jAn BgkqhkiG9w0BCQ8xGjAYMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BEAQIgDTnVKg0nz75gBqhAn56pOeSTw0JSF3kXDpAi+yKTM8lrflBLcHKKTIRXaSwRQ84Vco 1EUW0rDoiowmCGiJ --------------ms6C7359DA439516D3AFC1AD65-- From owner-mpls@UU.NET Mon Apr 30 09:44:49 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09931 for ; Mon, 30 Apr 2001 09:44:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzm09744; Mon, 30 Apr 2001 13:44:46 GMT Received: by mail-control.mail.uu.net id QQkmzm26117 for mpls-outgoing; Mon, 30 Apr 2001 13:44:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmzm26082 for ; Mon, 30 Apr 2001 13:43:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzm08253 for ; Mon, 30 Apr 2001 13:42:12 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkmzm14018 for ; Mon, 30 Apr 2001 13:42:11 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 90E5094009; Mon, 30 Apr 2001 09:42:11 -0400 (EDT) Message-ID: <3AED6BB3.98B46B03@sandburst.com> Date: Mon, 30 Apr 2001 09:42:11 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Wang Yu Cc: "mpls@UU.NET" Subject: Re: question about Trigger Control Block? References: <200104270256.f3R2ufR16670@noya.bupt.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yu, Lately, I've apparently been having a lot of trouble with imprecision. The term "LSP" is redundant and should be removed. In any case, there should be a consistent usage. I get a chance to fix minor editing issues like this before the draft actually gets published as an RFC (which should happen really soon). The concept of NHCB (or NHCBP) is not vestigial and will not be removed. The reason for the keeping this data was already spelled out in the reference to page 6 below. -- Eric Gray You wrote: > Eric Gray, > > thanks a lot! > ----------------- > 01-4-26 10:37:00 You wrote: > >Yu, > > > > In this answer, I will use the following shorthand: > > > > NHCB = Next Hop Control Block > > NHCBP = Next Hop Control Block Pointer > > NHTCB = Next Hop Trigger Control Block > > NHTCBP = Next Hop Trigger Control Block Pointer > > JPLIG = Just Plain Lazy I Guess > > > > On page 6, you should see a statement that the NHCBP > >"points to the control block which is used for switching over > >to a better LSP." > > > > In section 3.2.6.1 Next Hop Trigger Control Block, on page > >24, you should find that the NHTCB contains two pointers - > >one to the original downstream LSP control block and one to a > >new Next Hop LSP Control Block. I confess that - in at least > >this case - I'm guilty of not quite catching every inconsistency > >in the terminology used. In this definition, > > > > NHCB also equals Next Hop LSP Control Block, and > > NHCBP also equals Next Hop LSP Control Block Pointer > > > > >I believe this is vestigial since LSP is redundant and should > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >have been removed. > ~~~~~~~~~~~~~~~~~~~ > Do you mean Next Hop LSP Control Block and Next Hop LSP Control Block is useless and should have been removed? > If the answer is no, what is the function of Next Hop LSP Control Block Pointer in LSP Control Block? > > > > Does this help? > > > >-- > >Eric Gray > > > > In 3.2.1, LSP Control Block contains NHCBP (Next Hop LSP Control Block Pointer). > But it seems that NHCBP is not useless. > It is NHTCBP that is used for switching over to a better LSP. > Certainly, NHCBP is useful in Next Hop Trigger Control Block. > > > +-----------------------+ > | LSP Control Block | > | (original LSP) | > +-----------------------+ > (LSP ^ | > Control | | (Next Hop Trigger Control Block Pointer) > Block | | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Pointer) | v > +--------------------------------+ > | Next Hop Trigger Control Block | > +--------------------------------+ > ^ | > (Trigger | | (New Next Hop LSP Control Block Pointer) > Control | | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Block | | > Pointer)| | > | v > +------------------------+ > | LSP Control Block | > | (for LSP: LSR-B, LSR-E,| > | LSR-D) | > +------------------------+ > > Wang Yu From owner-mpls@UU.NET Mon Apr 30 09:55:36 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10671 for ; Mon, 30 Apr 2001 09:55:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzn13998; Mon, 30 Apr 2001 13:55:18 GMT Received: by mail-control.mail.uu.net id QQkmzn27352 for mpls-outgoing; Mon, 30 Apr 2001 13:54:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmzn27342 for ; Mon, 30 Apr 2001 13:54:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmzn13251 for ; Mon, 30 Apr 2001 13:54:14 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkmzn25080 for ; Mon, 30 Apr 2001 13:54:14 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id D1A8894009; Mon, 30 Apr 2001 09:54:08 -0400 (EDT) Message-ID: <3AED6E80.D9B83D71@sandburst.com> Date: Mon, 30 Apr 2001 09:54:08 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Xu Peng Cc: "mpls@UU.NET" Subject: Re: What are in LIB? References: <200104270816.f3R8GlR25798@noya.bupt.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Xu Peng, See section 3.10 - "The Next Hop Label Forwarding Entry (NHLFE)" - of RFC 3031 ("Multiprotocol Label Switching Architecture") for a list of the contents of the NHLFE. Note that this is an architectural document and - even if it were a protocol specification - it lists the information needed in order for an implementation to behave predictably with respect to MPLS protocols. In other words, your implementation may store more than this in an NHLFE equivalent 'record' or it may store this information in some other way - as long as your implementation ultimately behaves as if it has this information in this form. You can find more discussion of this in various literature on MPLS. -- Eric Gray You wrote: > hi,everybody > > I'am wandering what should be contained in the LIB, and how to represent NHLFE. > Anybody can explain it to me? > Thanks! > > Best regards! > > xupengpeng@263.net From owner-mpls@UU.NET Mon Apr 30 10:02:40 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10973 for ; Mon, 30 Apr 2001 10:02:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzo07587; Mon, 30 Apr 2001 14:02:32 GMT Received: by mail-control.mail.uu.net id QQkmzo02223 for mpls-outgoing; Mon, 30 Apr 2001 14:01:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmzo01689 for ; Mon, 30 Apr 2001 14:01:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmzn03441 for ; Mon, 30 Apr 2001 13:58:11 GMT Received: from malmo.trab.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQkmzn01251 for ; Mon, 30 Apr 2001 13:58:11 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f3UDw8u12185; Mon, 30 Apr 2001 15:58:08 +0200 (MEST) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Mon, 30 Apr 2001 15:58:08 +0200 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D02254426@trab-hermes.haninge.trab.se> From: Nhat Thanh Hoang To: "'Dirk Maeckelberghe'" , mpls@UU.NET Subject: RE: MPLS TE question Date: Mon, 30 Apr 2001 15:58:01 +0200 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 Hi, I Think you can find the answer at the following drafts: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-02.txt As I know contraint-based (the constraints such as bandwidth, link colors) signaled LSPs can only be established within one IS-IS area, because the traffic-engineering database is only propagating within an area. But, I think there are RSVP-TE implementations (are vendor dependent)that support inter-area LSPs by explicitly and strictly point out hop-by-hop along the LSP you want to establsih and without the constraints: bandwidth and linkcoloring. See also the comment line below: -----Original Message----- From: Dirk Maeckelberghe [mailto:Dirk.Maeckelberghe@swift.com] Sent: den 30 april 2001 14:53 To: mpls@UU.NET Subject: MPLS TE question Hello, Can you point me to the right references or help answer underneath questions. I need to know if I can use the TE extensions to setup an LSP using RSVP-TE ( cross area ) in case my IGP is hierarchical IS-IS ( L1 and L2 ). Can I assume that summarization happens at area boundaries and that the detailed TE info does not get propagated inside the area ? - Yes, You are right about that. This is case A to B where A,B LER and L2A and L2B LSR A - area 1 - L2A ---- L2X --- L2B - area 2 - B If now I am only extending my MPLS cloud to the L2 routers ( L2A - L2B are now LER ), A and B are NON-MPLS routers, can I then use the TE extensions of IS-IS to do TE between the L2A and L2B. I understand that the L2 routers only form L2 adjacencies, are the TE extensions communicated between them ? - I'm not sure if I understand you correctly, and I suppose that now you mean the changed scenario is L2A, L2X and L2B are Level 2 MPLS-capable routers, then the answer to your question is YES. - If I'm wrong please correct me. - I hope it would help something Cheers, /Nhat Thanh Telia Research AB A - area 1 - L2A ---- L2X --- L2B - area 2 - B Thanks, Dirk From owner-mpls@UU.NET Mon Apr 30 10:08:19 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11224 for ; Mon, 30 Apr 2001 10:08:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzo28656; Mon, 30 Apr 2001 14:08:01 GMT Received: by mail-control.mail.uu.net id QQkmzo16731 for mpls-outgoing; Mon, 30 Apr 2001 14:07:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmzo16673 for ; Mon, 30 Apr 2001 14:07:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzo29803 for ; Mon, 30 Apr 2001 14:01:29 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQkmzo06346 for ; Mon, 30 Apr 2001 14:01:28 GMT Received: from goneto.net (unknown [195.167.134.116]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id A7C3215F80E; Mon, 30 Apr 2001 15:01:27 +0100 (BST) Message-ID: <3AED7D18.DA6C2B55@goneto.net> Date: Mon, 30 Apr 2001 15:56:24 +0100 From: Giles Heron Reply-To: giles@goneto.net Organization: Gone2 Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dirk Maeckelberghe Cc: mpls@UU.NET Subject: Re: MPLS TE question References: <3AED601D.710F0481@swift.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dirk Maeckelberghe wrote: > > Hello, > > Can you point me to the right references or help answer underneath questions. > > I need to know if I can use the TE extensions to setup an LSP using RSVP-TE ( cross area ) in case my IGP is hierarchical IS-IS ( > L1 and L2 ). > Can I assume that summarization happens at area boundaries and that the detailed TE info does not get propagated inside the area ? TE information doesn't cross area boundaries. You can't use CSPF to set up RSVP-TE LSPs across area boundaries (or at least not yet - there is work in progress on multi-area TE.) However you can set up RSVP-TE LSPs across areas by specifying an explicit path. > This is case A to B where A,B LER and L2A and L2B LSR > > A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > If now I am only extending my MPLS cloud to the L2 routers ( L2A - L2B are now LER ), A and B are NON-MPLS routers, > can I then use the TE extensions of IS-IS to do TE between the L2A and L2B. Yes. > I understand that the L2 routers only form L2 adjacencies, are the TE extensions communicated between them ? The L2 routers will communicate TE information to each other. Each will set up a Traffic Engineering Database containing this information (which can then be used for CSPF.) Just out of interest - are you sure you need to build a hierarchical IS-IS network? AFAIK most large ISPs run IS-IS using level 2 only? Giles > A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > Thanks, > > Dirk -- ============================================================ Giles Heron Principal Network Architect Gone2 Inc. ph: +44 7880 506185 "if you build it they will yawn" ============================================================ From owner-mpls@UU.NET Mon Apr 30 10:30:56 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12367 for ; Mon, 30 Apr 2001 10:30:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzq11074; Mon, 30 Apr 2001 14:30:50 GMT Received: by mail-control.mail.uu.net id QQkmzq19812 for mpls-outgoing; Mon, 30 Apr 2001 14:30:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmzq19792 for ; Mon, 30 Apr 2001 14:30:01 GMT Received: from sysenglt126 by imr3.ash.ops.us.uu.net with SMTP (peer crosschecked as: ippool146-202.corp.us.uu.net [153.39.146.202]) id QQkmzp29257; Mon, 30 Apr 2001 14:29:28 GMT Message-Id: <3.0.32.20010430102837.00a51c90@neserve0.corp.us.uu.net> X-Sender: abirjand@neserve0.corp.us.uu.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 30 Apr 2001 10:28:38 -0400 To: Dirk Maeckelberghe , mpls@UU.NET From: Amir Birjandi Subject: Re: MPLS TE question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk There are implementations that you can setup static LSPs. Amir At 02:52 PM 4/30/01 +0200, Dirk Maeckelberghe wrote: >Hello, > >Can you point me to the right references or help answer underneath questions. > >I need to know if I can use the TE extensions to setup an LSP using RSVP-TE ( cross area ) in case my IGP is hierarchical IS-IS ( >L1 and L2 ). >Can I assume that summarization happens at area boundaries and that the detailed TE info does not get propagated inside the area ? > >This is case A to B where A,B LER and L2A and L2B LSR > >A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > >If now I am only extending my MPLS cloud to the L2 routers ( L2A - L2B are now LER ), A and B are NON-MPLS routers, >can I then use the TE extensions of IS-IS to do TE between the L2A and L2B. >I understand that the L2 routers only form L2 adjacencies, are the TE extensions communicated between them ? > >A - area 1 - L2A ---- L2X --- L2B - area 2 - B > >Thanks, > >Dirk > >Attachment Converted: "C:\Eudora\Attach\Dirk.Maeckelberghe.vcf" > >Attachment Converted: "C:\Eudora\Attach\smime1.p7s" > From owner-mpls@UU.NET Mon Apr 30 11:03:26 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14150 for ; Mon, 30 Apr 2001 11:03:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzs17980; Mon, 30 Apr 2001 15:03:16 GMT Received: by mail-control.mail.uu.net id QQkmzs28399 for mpls-outgoing; Mon, 30 Apr 2001 15:02:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmzs27975 for ; Mon, 30 Apr 2001 15:02:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmzs27579 for ; Mon, 30 Apr 2001 15:02:03 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkmzs14170 for ; Mon, 30 Apr 2001 15:02:02 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26173 for ; Mon, 30 Apr 2001 11:02:00 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15272 for ; Mon, 30 Apr 2001 11:02:01 -0400 (EDT) Message-ID: <3AED7E8B.F15DC4AC@marconi.com> Date: Mon, 30 Apr 2001 11:02:35 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@UU.NET'" Subject: Re: Two signalling protocols (LDP & RSVP) References: <65256A3B.003390E8.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit mgoel@hss.hns.com wrote: > > Although both CR-LDP and RSVP-TE provides similar functionalities, > but one significant reason why we would like to run both the > protocols on the same interface can be that TE-RSVP supports IP > record route option using its record route objects.But CR-LDP > doesn't support IP record route option. CR-LDP has the Path-Vector TLV, which works almost identically to the RSVP RECORD_ROUTE object. -- David From owner-mpls@UU.NET Mon Apr 30 11:04:47 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14233 for ; Mon, 30 Apr 2001 11:04:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzs16951; Mon, 30 Apr 2001 15:04:44 GMT Received: by mail-control.mail.uu.net id QQkmzs03864 for mpls-outgoing; Mon, 30 Apr 2001 15:04:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmzs00018 for ; Mon, 30 Apr 2001 15:03:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzs04208 for ; Mon, 30 Apr 2001 15:02:52 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmzs17485 for ; Mon, 30 Apr 2001 15:02:52 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA05537 for mpls@uu.net; Mon, 30 Apr 2001 11:02:52 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmzr22750 for ; Mon, 30 Apr 2001 14:58:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmzr15975 for ; Mon, 30 Apr 2001 14:58:16 GMT Received: from che-cse-115.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.140.33]) id QQkmzr16878 for ; Mon, 30 Apr 2001 14:58:15 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id KAA05269; Mon, 30 Apr 2001 10:57:43 -0400 (EDT) Date: Mon, 30 Apr 2001 10:57:43 -0400 From: Eric Osborne To: Bhupesh Bajaj Cc: alexander@marhold.at, mpls@UU.NET, mpls-ops@mplsrc.com Subject: Re: RE: doubt in RFC 3031 Message-ID: <20010430105743.A5258@che-cse-115.cisco.com> References: <200104301046.QAA02582@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104301046.QAA02582@localhost.localdomain>; from mpls@indiatimes.com on Mon, Apr 30, 2001 at 04:22:57PM +0530 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Apr 30, 2001 at 04:22:57PM +0530, Bhupesh Bajaj wrote: > hello, > > as far as i believe the penultimate hop is going to behave in same way ( as far as number of lookups is concerned )in both cases with / without using this technique.."penultimate hop popping".. > > so i believe it needn't be mentioned in RFC that with PNP one gets the benifit of just one lookup from penultimate hop side also as they have mentioned in RFC > > waiting for comments, > The statement may be extraneous, but it's certainly true. THe idea was (I think) to point out that implicit-null causes no extra work on the penultimate router. Is there major objection to pointing this out? eric > > thanks and regards, > bhupesh > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com From owner-mpls@UU.NET Mon Apr 30 11:22:57 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14945 for ; Mon, 30 Apr 2001 11:22:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzt15841; Mon, 30 Apr 2001 15:22:45 GMT Received: by mail-control.mail.uu.net id QQkmzt15084 for mpls-outgoing; Mon, 30 Apr 2001 15:22:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmzt14806 for ; Mon, 30 Apr 2001 15:21:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmzt22037 for ; Mon, 30 Apr 2001 15:19:13 GMT Received: from mailer.syr.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailer.syr.edu [128.230.18.29]) id QQkmzt11852 for ; Mon, 30 Apr 2001 15:19:13 GMT Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.000F435B@mailer.syr.edu>; Mon, 30 Apr 2001 11:19:04 -0400 Received: from localhost (iokumus@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id LAA06166; Mon, 30 Apr 2001 11:19:03 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: iokumus owned process doing -bs Date: Mon, 30 Apr 2001 11:19:03 -0400 (EDT) From: Ibrahim Okumus X-Sender: iokumus@rodan.syr.edu To: Nhat Thanh Hoang cc: mpls@UU.NET Subject: RE: MPLS TE question In-Reply-To: <778DFE9B4E3BD111A74E08002BA3DC0D02254426@trab-hermes.haninge.trab.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Nhat, Do you have pointers to the inter-area LSP setup? Thanks, _________________________ Ibrahim Taner OKUMUS On Mon, 30 Apr 2001, Nhat Thanh Hoang wrote: > Hi, > > I Think you can find the answer at the following drafts: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt > http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-02.txt > > As I know contraint-based (the constraints such as bandwidth, link colors) > signaled LSPs can only be established within one IS-IS area, because the > traffic-engineering database is only propagating within an area. But, I > think there are RSVP-TE implementations (are vendor dependent)that support > inter-area LSPs by explicitly and strictly point out hop-by-hop along the > LSP you want to establsih and without the constraints: bandwidth and > linkcoloring. > See also the comment line below: > > -----Original Message----- > From: Dirk Maeckelberghe [mailto:Dirk.Maeckelberghe@swift.com] > Sent: den 30 april 2001 14:53 > To: mpls@UU.NET > Subject: MPLS TE question > > > Hello, > > Can you point me to the right references or help answer underneath > questions. > > I need to know if I can use the TE extensions to setup an LSP using RSVP-TE > ( cross area ) in case my IGP is hierarchical IS-IS ( > L1 and L2 ). > Can I assume that summarization happens at area boundaries and that the > detailed TE info does not get propagated inside the area ? > > - Yes, You are right about that. > > This is case A to B where A,B LER and L2A and L2B LSR > > A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > > If now I am only extending my MPLS cloud to the L2 routers ( L2A - L2B are > now LER ), A and B are NON-MPLS routers, > can I then use the TE extensions of IS-IS to do TE between the L2A and L2B. > I understand that the L2 routers only form L2 adjacencies, are the TE > extensions communicated between them ? > > - I'm not sure if I understand you correctly, and I suppose that now you > mean the changed scenario is L2A, L2X and L2B are Level 2 MPLS-capable > routers, then the answer to your question is YES. > > - If I'm wrong please correct me. > > - I hope it would help something > > Cheers, > /Nhat Thanh > > Telia Research AB > > A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > Thanks, > > Dirk > From owner-mpls@UU.NET Mon Apr 30 11:24:41 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15040 for ; Mon, 30 Apr 2001 11:24:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzt08473; Mon, 30 Apr 2001 15:24:40 GMT Received: by mail-control.mail.uu.net id QQkmzt15246 for mpls-outgoing; Mon, 30 Apr 2001 15:24:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmzt15199 for ; Mon, 30 Apr 2001 15:23:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmzt13514 for ; Mon, 30 Apr 2001 15:23:36 GMT Received: from mailer.syr.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailer.syr.edu [128.230.18.29]) id QQkmzt16793 for ; Mon, 30 Apr 2001 15:23:36 GMT Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.000F443C@mailer.syr.edu>; Mon, 30 Apr 2001 11:23:37 -0400 Received: from localhost (iokumus@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id LAA07213; Mon, 30 Apr 2001 11:23:35 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: iokumus owned process doing -bs Date: Mon, 30 Apr 2001 11:23:35 -0400 (EDT) From: Ibrahim Okumus X-Sender: iokumus@rodan.syr.edu To: Nhat Thanh Hoang cc: "'Dirk Maeckelberghe'" , mpls@UU.NET Subject: RE: MPLS TE question In-Reply-To: <778DFE9B4E3BD111A74E08002BA3DC0D02254426@trab-hermes.haninge.trab.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Dirk, following might be a related pointer for your question. A Framework for the LSP Setup Across IGP Areas for MPLS Traffic Engineering draft-venkatachalam-interarea-mpls-te-01.txt _______________________________ Ibrahim Taner OKUMUS On Mon, 30 Apr 2001, Nhat Thanh Hoang wrote: > Hi, > > I Think you can find the answer at the following drafts: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt > http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-02.txt > > As I know contraint-based (the constraints such as bandwidth, link colors) > signaled LSPs can only be established within one IS-IS area, because the > traffic-engineering database is only propagating within an area. But, I > think there are RSVP-TE implementations (are vendor dependent)that support > inter-area LSPs by explicitly and strictly point out hop-by-hop along the > LSP you want to establsih and without the constraints: bandwidth and > linkcoloring. > See also the comment line below: > > -----Original Message----- > From: Dirk Maeckelberghe [mailto:Dirk.Maeckelberghe@swift.com] > Sent: den 30 april 2001 14:53 > To: mpls@UU.NET > Subject: MPLS TE question > > > Hello, > > Can you point me to the right references or help answer underneath > questions. > > I need to know if I can use the TE extensions to setup an LSP using RSVP-TE > ( cross area ) in case my IGP is hierarchical IS-IS ( > L1 and L2 ). > Can I assume that summarization happens at area boundaries and that the > detailed TE info does not get propagated inside the area ? > > - Yes, You are right about that. > > This is case A to B where A,B LER and L2A and L2B LSR > > A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > > If now I am only extending my MPLS cloud to the L2 routers ( L2A - L2B are > now LER ), A and B are NON-MPLS routers, > can I then use the TE extensions of IS-IS to do TE between the L2A and L2B. > I understand that the L2 routers only form L2 adjacencies, are the TE > extensions communicated between them ? > > - I'm not sure if I understand you correctly, and I suppose that now you > mean the changed scenario is L2A, L2X and L2B are Level 2 MPLS-capable > routers, then the answer to your question is YES. > > - If I'm wrong please correct me. > > - I hope it would help something > > Cheers, > /Nhat Thanh > > Telia Research AB > > A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > Thanks, > > Dirk > From owner-mpls@UU.NET Mon Apr 30 11:25:51 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15120 for ; Mon, 30 Apr 2001 11:25:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzt10053; Mon, 30 Apr 2001 15:25:47 GMT Received: by mail-control.mail.uu.net id QQkmzt15263 for mpls-outgoing; Mon, 30 Apr 2001 15:24:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmzt15129 for ; Mon, 30 Apr 2001 15:22:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmzt25153 for ; Mon, 30 Apr 2001 15:20:24 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkmzt13172 for ; Mon, 30 Apr 2001 15:20:23 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f3UFKnE12647 for ; Mon, 30 Apr 2001 08:20:49 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA11592 for mpls@uu.net; Mon, 30 Apr 2001 11:20:21 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmxv06031 for ; Mon, 30 Apr 2001 02:51:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmxv23093 for ; Mon, 30 Apr 2001 02:50:43 GMT Received: from email.com.cn by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.106.186.237]) id QQkmxv20788 for ; Mon, 30 Apr 2001 02:50:37 GMT Received: from email.com.cn([127.0.0.1]) by email.com.cn(JetMail 2.5.3.0) with SMTP id jm203aed0db5; Mon, 30 Apr 2001 02:50:59 -0000 Received: from host.secure4-hosting.net([209.239.41.31]) by email.com.cn(JetMail 2.5.3.0) with SMTP id jmba3ae7f2d7; Thu, 26 Apr 2001 08:50:16 -0000 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3Q8YvP23164; Thu, 26 Apr 2001 04:34:57 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-ID: <20010426071826.9227.qmail@web11702.mail.yahoo.com> Date: Thu, 26 Apr 2001 00:18:26 -0700 (PDT) From: vola ray Subject: RE: MPLS Trafficdriven To: Geoff Bennett , "Hass, Barry" , "Marinzulich, Matias" , "'Ashwin Moranganti'" , "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com In-Reply-To: <200104260529.GAA10398@salamander.eu.fore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: archive/latest/1066 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk geoff, As U mentioned..... "But the problem is how do you recognise the appropriate traffic types." Well we can solve this Problem: In the Ingress Router the ASIC device is already Configured to handle respective Packet types based on Profiles/Policies. End user can set the DSCP field in the transmitted IP packet to the Ingress Router. Now after receiving the IP Packet, Router checks the IP address and the DSCP field then validates via looking into the Port number and other stuff. By the way ASIC must be configured with such stuff to process such Traffic. Hence if somebody is sending email but prtending this is a VoIP packet it can be easily detected and either packet can be dropped or DSCP field changed accordingly. This is completely a configuration issue as to how to set up the ASIC for what type of traffic. SNMP or CLI can be used to configure such things. Hope, this helps........ vola --- Geoff Bennett wrote: > Hi Barry, > Yes it would make sense. But who sets the DSCP field? > > The "end user" can't be allowed to do this because DSCP is used to > prioritise traffic, and everyone would set their traffic to high priority. > > The ideal thing would be to build proxy devices to insert the appropriate > value according to a policy. IMHO the obvious location for such a proxy is > the Ingress LSR. But the problem is how do you recognise the appropriate > traffic types. > > Cheers, > Geoff __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Mon Apr 30 11:27:15 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15218 for ; Mon, 30 Apr 2001 11:27:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzt15025; Mon, 30 Apr 2001 15:27:12 GMT Received: by mail-control.mail.uu.net id QQkmzt15542 for mpls-outgoing; Mon, 30 Apr 2001 15:26:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmzt15303 for ; Mon, 30 Apr 2001 15:24:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmzt24822 for ; Mon, 30 Apr 2001 15:22:05 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkmzt05924 for ; Mon, 30 Apr 2001 15:22:05 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA08539 for mpls@uu.net; Mon, 30 Apr 2001 11:22:05 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmzt14531 for ; Mon, 30 Apr 2001 15:17:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzt01729 for ; Mon, 30 Apr 2001 15:17:01 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQkmzt03863 for ; Mon, 30 Apr 2001 15:17:01 GMT Received: from ASIMHA-LAPTOP (dhcp-64-102-48-168.cisco.com [64.102.48.168]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06295; Mon, 30 Apr 2001 11:13:20 -0400 (EDT) Date: Mon, 30 Apr 2001 11:17:14 -0400 (Eastern Daylight Time) From: Ajay Simha To: David Charlap cc: "'mpls@UU.NET'" Subject: Re: Two signalling protocols (LDP & RSVP) In-Reply-To: <3AED7E8B.F15DC4AC@marconi.com> Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 30 Apr 2001, David Charlap wrote: > mgoel@hss.hns.com wrote: > > > > Although both CR-LDP and RSVP-TE provides similar functionalities, > > but one significant reason why we would like to run both the > > protocols on the same interface can be that TE-RSVP supports IP > > record route option using its record route objects.But CR-LDP > > doesn't support IP record route option. > > CR-LDP has the Path-Vector TLV, which works almost identically to the > RSVP RECORD_ROUTE object. Good point. But is it of consequence when one is not using Ordered/DoD? -ajay > > -- David > -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Mon Apr 30 11:28:37 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15274 for ; Mon, 30 Apr 2001 11:28:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzt13516; Mon, 30 Apr 2001 15:28:30 GMT Received: by mail-control.mail.uu.net id QQkmzt15601 for mpls-outgoing; Mon, 30 Apr 2001 15:26:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmzt15555 for ; Mon, 30 Apr 2001 15:26:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzt10557 for ; Mon, 30 Apr 2001 15:26:23 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkmzt14053 for ; Mon, 30 Apr 2001 15:26:23 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29458 for ; Mon, 30 Apr 2001 11:26:21 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22312 for ; Mon, 30 Apr 2001 11:26:22 -0400 (EDT) Message-ID: <3AED8440.43C2365@marconi.com> Date: Mon, 30 Apr 2001 11:26:56 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@UU.NET'" Subject: Re: Two signalling protocols (LDP & RSVP) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ajay Simha wrote: >> >> CR-LDP has the Path-Vector TLV, which works almost identically to >> the RSVP RECORD_ROUTE object. > > Good point. But is it of consequence when one is not using > Ordered/DoD? Other modes are only for LDP, not CR-LDP. But, since you ask, they are also useful in LDP in those modes, but Path-Vector must now be used in conjunction with hop-count. Hop-count will only be non-zero for messages that come from, or are propagated from, the egress node. So... If an ingress node receives a Label Mapping where the hop-count is zero (unknown), then it the Path-Vector is not a complete path to the egress. It represents a partial path through the MPLS cloud, and may change as the LSP setup is completed. If it receives a Label Mapping where the hop-count is non-zero, then it knows that there is a path all the way to the egress, and the Path-Vector should be an accurate trace of what that path is. -- David From owner-mpls@UU.NET Mon Apr 30 11:48:44 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16287 for ; Mon, 30 Apr 2001 11:48:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzv05921; Mon, 30 Apr 2001 15:48:34 GMT Received: by mail-control.mail.uu.net id QQkmzv18266 for mpls-outgoing; Mon, 30 Apr 2001 15:47:47 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmzv18256 for ; Mon, 30 Apr 2001 15:47:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzv07302 for ; Mon, 30 Apr 2001 15:46:40 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkmzv07012 for ; Mon, 30 Apr 2001 15:46:39 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 84DD194009; Mon, 30 Apr 2001 11:46:39 -0400 (EDT) Message-ID: <3AED88DF.8AE3EA17@sandburst.com> Date: Mon, 30 Apr 2001 11:46:39 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Marc Lewis Cc: mpls@UU.NET Subject: Re: Determining the Ingress IP address in an RSVP session References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Marc, In at least one case, the IPv4 address is required in the extended tunnel ID. That case is described in section 4.6.4 as shown below: ========================================================================= 4.6.4. Reroute and Bandwidth Increase Procedure This section describes how to setup a tunnel that is capable of maintaining resource reservations (without double counting) while it is being rerouted or while it is attempting to increase its bandwidth. In the initial Path message, the ingress node forms a SESSION object, assigns a Tunnel_ID, and places its IPv4 address in the Extended_Tunnel_ID It also forms a SENDER_TEMPLATE and assigns a LSP_ID. Tunnel setup then proceeds according to the normal procedure. ========================================================================= In addition, though I cannot find where it is explicitly stated right at the moment, I believe the IPv4 (or IPv6) address in the SENDER_TEMPLATE object is supposed to be for the ingress LSR on the LSP. This is implied by the statement (on page 9, last paragraph in section 2.1): "The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel". This statement would not be true if two separate ingress LSRs could each choose to use the same 'sender' when creating the SENDER_TEMPLATE object. -- Eric Gray You wrote: > Several recent messages have concerned the issue of how to discern the > Ingress LSR's IP address. Though it is true that some routers seem to put > it in the Extended Tunnel ID field of the SESSION object, > draft-ietf-mpls-rsvp-lsp-tunnel-08 does not require it. > > Furthermore, RFC2205 is not terribly clear about what the phrase "a sender" > means, which is used repeatedly in describing the workings of RSVP message > objects. Assuming it means the Ingress LSR (the original sender) leads to > one interpretation, and assuming it means the LSR that sent the message > being examined (simply an RSVP peer, not necessarily the Ingress LSR) leads > to another interpretation. I suspect, but am not certain, the latter > assumption is the correct one. > > It does seem reasonably unambiguous, however, that the Ingress and Egress IP > addresses are reliably to be found as the source and destination addresses, > respectively, of the IP header of PATH messages. Quoting from 3.1.3 in > RFC2205: "Each message contains a sender descriptor defining one sender, and > carries the original sender's IP address as its IP source address". > > From owner-mpls@UU.NET Mon Apr 30 11:54:32 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16444 for ; Mon, 30 Apr 2001 11:54:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzt04134; Mon, 30 Apr 2001 15:20:37 GMT Received: by mail-control.mail.uu.net id QQkmzt14740 for mpls-outgoing; Mon, 30 Apr 2001 15:20:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmzt14720 for ; Mon, 30 Apr 2001 15:19:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmzt20359 for ; Mon, 30 Apr 2001 15:18:50 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkmzt11431 for ; Mon, 30 Apr 2001 15:18:50 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28549 for ; Mon, 30 Apr 2001 11:18:48 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19948 for ; Mon, 30 Apr 2001 11:18:50 -0400 (EDT) Message-ID: <3AED827B.D85A77D@marconi.com> Date: Mon, 30 Apr 2001 11:19:23 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Determining the Ingress IP address in an RSVP session References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Marc Lewis wrote: > > Several recent messages have concerned the issue of how to discern > the Ingress LSR's IP address. Though it is true that some routers > seem to put it in the Extended Tunnel ID field of the SESSION > object, draft-ietf-mpls-rsvp-lsp-tunnel-08 does not require it. If extended tunnel ID is non-zero, then it must be a value that can unambiguously identify the sender (LSP ingress). The only standard mechanism for generating these values is to use one of the sender's IP addresses. > Furthermore, RFC2205 is not terribly clear about what the phrase "a > sender" means, which is used repeatedly in describing the workings > of RSVP message objects. Assuming it means the Ingress LSR (the > original sender) leads to one interpretation, and assuming it means > the LSR that sent the message being examined (simply an RSVP peer, > not necessarily the Ingress LSR) leads to another interpretation. > I suspect, but am not certain, the latter assumption is the correct > one. This is really a question for the RSVP working group, not the MPLS group. "Sender", unless explicitly stated otherwise, always refers to the sender on the data plane - meaning the ingress node when used in the context of MPLS. Any other definition makes the multicast features of RSVP impossible to implement. (Never forget that RFC-2205 is not an MPLS document. RSVP was designed to signal QoS over a multicast IP network, not over a unicast MPLS network.) If two hosts are sending data to a single destination, and their routes converge at some point, the egress router must be able to keep the two separate if FF or SE style reservations are to be used. Remember that there is no extended tunnel ID in RFC-2205. If sender is defined as previous-hop, then the recipient of the Path message will not know that there are two senders. Both will end up being replaced with a single PHOP address. Those who interpret "sender" as previous/next hop have a broken implementation. > It does seem reasonably unambiguous, however, that the Ingress and > Egress IP addresses are reliably to be found as the source and > destination addresses, respectively, of the IP header of PATH > messages. Quoting from 3.1.3 in RFC2205: "Each message contains a > sender descriptor defining one sender, and carries the original > sender's IP address as its IP source address". This is true. RFC-2205 was designed to work in a network where not everybody supports RSVP. (Unlike all MPLS applications of RSVP). In order to make this work, packets are addresses to the ultimate recipient of the data, and not the next-hop router. This way, the packets won't be dropped by a non-RSVP router that happens to be in the middle of the path. -- David From owner-mpls@UU.NET Mon Apr 30 12:06:31 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16934 for ; Mon, 30 Apr 2001 12:06:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzw04667; Mon, 30 Apr 2001 16:06:25 GMT Received: by mail-control.mail.uu.net id QQkmzw00797 for mpls-outgoing; Mon, 30 Apr 2001 16:05:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkmzw00738 for ; Mon, 30 Apr 2001 16:05:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzw22396 for ; Mon, 30 Apr 2001 16:03:08 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkmzw25603 for ; Mon, 30 Apr 2001 16:03:07 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3UG37Z12838 for ; Mon, 30 Apr 2001 09:03:07 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA00552 for mpls@uu.net; Mon, 30 Apr 2001 12:03:06 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmzw21972 for ; Mon, 30 Apr 2001 16:00:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzv23670 for ; Mon, 30 Apr 2001 15:59:11 GMT Received: from email.com.cn by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.106.186.237]) id QQkmzv21144 for ; Mon, 30 Apr 2001 15:59:09 GMT Received: from email.com.cn([127.0.0.1]) by email.com.cn(JetMail 2.5.3.0) with SMTP id jm43aedc684; Mon, 30 Apr 2001 15:59:29 -0000 Received: from host.secure4-hosting.net([209.239.41.31]) by email.com.cn(JetMail 2.5.3.0) with SMTP id jmba3ae7f2d7; Thu, 26 Apr 2001 08:50:16 -0000 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3Q8YvP23164; Thu, 26 Apr 2001 04:34:57 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-ID: <20010426071826.9227.qmail@web11702.mail.yahoo.com> Date: Thu, 26 Apr 2001 00:18:26 -0700 (PDT) From: vola ray Subject: RE: MPLS Trafficdriven To: Geoff Bennett , "Hass, Barry" , "Marinzulich, Matias" , "'Ashwin Moranganti'" , "'MP LS'" , MPLS@UU.NET, mpls-ops@mplsrc.com In-Reply-To: <200104260529.GAA10398@salamander.eu.fore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: archive/latest/1066 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk geoff, As U mentioned..... "But the problem is how do you recognise the appropriate traffic types." Well we can solve this Problem: In the Ingress Router the ASIC device is already Configured to handle respective Packet types based on Profiles/Policies. End user can set the DSCP field in the transmitted IP packet to the Ingress Router. Now after receiving the IP Packet, Router checks the IP address and the DSCP field then validates via looking into the Port number and other stuff. By the way ASIC must be configured with such stuff to process such Traffic. Hence if somebody is sending email but prtending this is a VoIP packet it can be easily detected and either packet can be dropped or DSCP field changed accordingly. This is completely a configuration issue as to how to set up the ASIC for what type of traffic. SNMP or CLI can be used to configure such things. Hope, this helps........ vola --- Geoff Bennett wrote: > Hi Barry, > Yes it would make sense. But who sets the DSCP field? > > The "end user" can't be allowed to do this because DSCP is used to > prioritise traffic, and everyone would set their traffic to high priority. > > The ideal thing would be to build proxy devices to insert the appropriate > value according to a policy. IMHO the obvious location for such a proxy is > the Ingress LSR. But the problem is how do you recognise the appropriate > traffic types. > > Cheers, > Geoff __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Mon Apr 30 12:26:07 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17755 for ; Mon, 30 Apr 2001 12:26:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzx26103; Mon, 30 Apr 2001 16:26:01 GMT Received: by mail-control.mail.uu.net id QQkmzx11530 for mpls-outgoing; Mon, 30 Apr 2001 16:24:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkmzx11515 for ; Mon, 30 Apr 2001 16:24:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkmzx26181 for ; Mon, 30 Apr 2001 16:23:43 GMT Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQkmzx13432 for ; Mon, 30 Apr 2001 16:23:40 GMT Received: from tomp.smb.utfors.se ([127.0.0.1]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GCM5N400.95S; Mon, 30 Apr 2001 18:25:52 +0200 From: "Loa Andersson" To: David Charlap Cc: "'mpls@UU.NET'" Message-ID: <5d3475da81.5da815d347@tomp.smb.utfors.se> Date: Mon, 30 Apr 2001 18:25:52 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: Two signalling protocols (LDP & RSVP) X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA17755 ----- Original Message ----- From: David Charlap Date: Monday, April 30, 2001 5:02 pm Subject: Re: Two signalling protocols (LDP & RSVP) > mgoel@hss.hns.com wrote: > > > > Although both CR-LDP and RSVP-TE provides similar functionalities, > > but one significant reason why we would like to run both the > > protocols on the same interface can be that TE-RSVP supports IP > > record route option using its record route objects.But CR-LDP > > doesn't support IP record route option. > > CR-LDP has the Path-Vector TLV, which works almost identically to the > RSVP RECORD_ROUTE object. The path vector comes from LDP , it is intended to be use to detect loops. proper working of the path vector requires that all the nodes are configured for loop detection. Yes, the path vector and RSVP RECORD_ROUTE works "almost" the same, but not quite enough the same, not to require changes in the current specs. Admittedly these changes are small and easy to make, but how many small changes ióf this nature do we need before it really becomes a pain? /Loa > > -- David > From owner-mpls@UU.NET Mon Apr 30 12:41:16 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18339 for ; Mon, 30 Apr 2001 12:41:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkmzy09481; Mon, 30 Apr 2001 16:41:11 GMT Received: by mail-control.mail.uu.net id QQkmzy12738 for mpls-outgoing; Mon, 30 Apr 2001 16:40:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkmzy12723 for ; Mon, 30 Apr 2001 16:40:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkmzy01776 for ; Mon, 30 Apr 2001 16:39:59 GMT Received: from gw.tropicnetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: gw.tropicnetworks.com [209.87.233.9]) id QQkmzy11736 for ; Mon, 30 Apr 2001 16:39:58 GMT Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for cmr0.ash.ops.us.uu.net [198.5.241.38]) with SMTP; 30 Apr 2001 16:39:58 UT Received: from cr437225a ([10.1.2.190]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with SMTP id AAA4E4F; Mon, 30 Apr 2001 12:39:57 -0400 From: "Sudhakar Ganti" To: Cc: "Nabil Seddigh" , "Biswajit Nandy" Subject: MPLS Support of E-LSPs Date: Mon, 30 Apr 2001 12:38:49 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, The following draft is available in the IETF draft repository that extends E-LSP signaling: Title: MPLS Support of Differentiated Services using E-LSP Authors: S.Ganti, N.Seddigh, B.Nandy URL: http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-elsp-00.txt The current E-LSP approach allows multiple Ordered Aggregates (OAs) to be carried by a single LSP. The existing E-LSP specification only supports collective bandwidth signalling for all the OAs in an E-LSP. However, there exist uses of the E-LSP approach where it is desirable to support bandwidth signalling on a per-OA or per-PSC basis. This draft extends the original E-LSP approach by defining extensions to support per-OA signalling. The extensions are proposed for both RSVP and CR-LDP. Please comment on the same. Thanks -Sudhakar ------------ Dr. Sudhakar Ganti Technical Specialist Tropic Networks Inc, Kanata, Ontario, Canada From owner-mpls@UU.NET Mon Apr 30 13:01:10 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18961 for ; Mon, 30 Apr 2001 13:01:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknaa02044; Mon, 30 Apr 2001 17:01:00 GMT Received: by mail-control.mail.uu.net id QQknaa16938 for mpls-outgoing; Mon, 30 Apr 2001 17:00:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknaa16372 for ; Mon, 30 Apr 2001 17:00:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzz21956 for ; Mon, 30 Apr 2001 16:57:49 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkmzz28131 for ; Mon, 30 Apr 2001 16:57:48 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 7FE4494006; Mon, 30 Apr 2001 12:57:48 -0400 (EDT) Message-ID: <3AED998C.B76F9D54@sandburst.com> Date: Mon, 30 Apr 2001 12:57:48 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "J.Kannan" Cc: mpls@UU.NET Subject: Re: Question regarding RFC 3031 References: <200104300918.OAA28065@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kannan, You got it right. Two sentences before the one you point out, it makes the same assertion that you state as 'definition' of FTN. This is almost certainly a typo. -- Eric Gray You wrote: > Hi > > In Section 3.12 ( FEC-To-NHLFE Map (FTN) ) of RFC 3031 , > paragraph 2 begins with the following statement : > > "If the FTN maps a particular label to a set of NHLFEs ..." > > Shouldn't it be "If the FTN maps a particular FEC to a set > of NHLFEs..." since by definition the FTN maps each > FEC to a set of NHLFEs. > > Or is there some other interpretation to this statement ? > > Thanks > Kannan From owner-mpls@UU.NET Mon Apr 30 13:09:40 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19234 for ; Mon, 30 Apr 2001 13:09:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknaa11724; Mon, 30 Apr 2001 17:09:27 GMT Received: by mail-control.mail.uu.net id QQknaa29139 for mpls-outgoing; Mon, 30 Apr 2001 17:08:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknaa28454 for ; Mon, 30 Apr 2001 17:08:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknaa09444 for ; Mon, 30 Apr 2001 17:06:43 GMT Received: from mail-blue.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQknaa27834 for ; Mon, 30 Apr 2001 17:06:43 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id C3F014CE09; Mon, 30 Apr 2001 13:06:42 -0400 (EDT) Received: from research.att.com (dhcp145.research.att.com [135.207.28.145]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id NAA29171; Mon, 30 Apr 2001 13:06:42 -0400 (EDT) Message-ID: <3AED9C4F.4065388A@research.att.com> Date: Mon, 30 Apr 2001 13:09:35 -0400 From: Guangzhi Li X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Gray Cc: Marc Lewis , mpls@UU.NET Subject: Re: Determining the Ingress IP address in an RSVP session References: <3AED88DF.8AE3EA17@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In RSVP-TE, section 2.5, it says" The LSP_TUNNEL_SESSION object is used to narrow the scope of the RSVP session to the particular TE tunnel in question. To uniquely identify a TE tunnel, we use the combination of the destination IP address (an address of the node which is the egres of the tunnel), a Tunnel ID, and the tunnel ingress node's IP address, which is placed in the Extended Tunnel ID field." To apply RSVP-TE to MPLS, destination is the egress node IP address, source is the ingress node IP address, both are placed in LSP_TUNNEL_SESSION object. Without Extended Tunnel ID, you can not uniquely identify a TE tunnel. It seems that both source and sender are ingress node when RSVP-TE talks about the LSPs. RSVP was originally designed for multicast applications, where sender and receiver are clear. In MPLS, LSPs are not exactly applications anymore, I think. -- Guangzhi Eric Gray wrote: > Marc, > > In at least one case, the IPv4 address is required in the > extended tunnel ID. That case is described in section 4.6.4 > as shown below: > > ========================================================================= > 4.6.4. Reroute and Bandwidth Increase Procedure > > This section describes how to setup a tunnel that is capable of > maintaining resource reservations (without double counting) while > it is being rerouted or while it is attempting to increase its > bandwidth. In the initial Path message, the ingress node forms a > SESSION object, assigns a Tunnel_ID, and places its IPv4 address in > the Extended_Tunnel_ID It also forms a SENDER_TEMPLATE and assigns a > LSP_ID. Tunnel setup then proceeds according to the normal procedure. > ========================================================================= > > In addition, though I cannot find where it is explicitly stated right at > the moment, I believe the IPv4 (or IPv6) address in the SENDER_TEMPLATE > object is supposed to be for the ingress LSR on the LSP. This is implied > by the statement (on page 9, last paragraph in section 2.1): > > "The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION > object uniquely identifies an LSP tunnel". > > This statement would not be true if two separate ingress LSRs could > each choose to use the same 'sender' when creating the SENDER_TEMPLATE > object. > > -- > Eric Gray > > You wrote: > > > Several recent messages have concerned the issue of how to discern the > > Ingress LSR's IP address. Though it is true that some routers seem to put > > it in the Extended Tunnel ID field of the SESSION object, > > draft-ietf-mpls-rsvp-lsp-tunnel-08 does not require it. > > > > Furthermore, RFC2205 is not terribly clear about what the phrase "a sender" > > means, which is used repeatedly in describing the workings of RSVP message > > objects. Assuming it means the Ingress LSR (the original sender) leads to > > one interpretation, and assuming it means the LSR that sent the message > > being examined (simply an RSVP peer, not necessarily the Ingress LSR) leads > > to another interpretation. I suspect, but am not certain, the latter > > assumption is the correct one. > > > > It does seem reasonably unambiguous, however, that the Ingress and Egress IP > > addresses are reliably to be found as the source and destination addresses, > > respectively, of the IP header of PATH messages. Quoting from 3.1.3 in > > RFC2205: "Each message contains a sender descriptor defining one sender, and > > carries the original sender's IP address as its IP source address". > > > > From owner-mpls@UU.NET Mon Apr 30 13:11:49 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19301 for ; Mon, 30 Apr 2001 13:11:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknaa03106; Mon, 30 Apr 2001 17:11:38 GMT Received: by mail-control.mail.uu.net id QQknaa04009 for mpls-outgoing; Mon, 30 Apr 2001 17:11:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknaa03560 for ; Mon, 30 Apr 2001 17:10:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknaa28885 for ; Mon, 30 Apr 2001 17:10:06 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQknaa14846 for ; Mon, 30 Apr 2001 17:10:04 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3UHA7Z01512 for ; Mon, 30 Apr 2001 10:10:07 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA00734 for mpls@uu.net; Mon, 30 Apr 2001 13:10:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmzz14690 for ; Mon, 30 Apr 2001 16:59:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzz18581 for ; Mon, 30 Apr 2001 16:56:08 GMT Received: from notes01.peakxv.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.169.12.3]) id QQkmzz26399 for ; Mon, 30 Apr 2001 16:56:08 GMT Received: from c385293a ([10.10.30.46]) by notes01.peakxv.net (Lotus Domino Release 5.0.7) with SMTP id 2001043009560500:27417 ; Mon, 30 Apr 2001 09:56:05 -0700 Message-ID: <04a901c0d196$3c3093d0$e996b018@c385293a> From: "Harish D V" To: "Bhupesh Bajaj" , Cc: , References: <200104301051.QAA02728@localhost.localdomain> Subject: Re: Re: megaco/H.248 Date: Mon, 30 Apr 2001 09:54:34 -0700 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on notes01/peakxv(Release 5.0.7 |March 21, 2001) at 04/30/2001 09:56:05 AM, Serialize by Router on notes01/peakxv(Release 5.0.7 |March 21, 2001) at 04/30/2001 09:56:08 AM, Serialize complete at 04/30/2001 09:56:08 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Also look at http://www.radvision.com/c_v2oip/c_papers.php3 Regards, Harish D V Peak XV Networks San Ramon CA - 94583 925-242-7459 office 925-381-9967 cell www.peakxv.net ----- Original Message ----- From: "Bhupesh Bajaj" To: Cc: ; Sent: Monday, April 30, 2001 3:58 AM Subject: Re: Re: megaco/H.248 > hi.. > Megaco is a Voip protocol which operates between Gateway and Call gents( Gateway Controllers) just like MGCP , and H.248 is similar recommendation by ITU. > but it isnt competing with SIP or H.323 as its areas of operation is totally different. Megaco Operates betweek Gateways and "Gateway Controllers" while H.323 and Sip Operate between different Gateway Controllers / Call Agents itself . > > thanks and regards > bhupesh. > > > > > ilazar@earthlink.net wrote: > > Hi, Megaco is a new VoIP signalling protocol that competes with SIP and H.323. You can find additional information at http://www.itprc.com/voice.htm Irwin At 01:14 PM 4/30/2001 +0530, S.K.Suman wrote: >Hi Everybody, > >I am going through the documents on QoS in MPLS..I came across the term >megaco/H.248 >Can anbody pls explain me,What exactly is megaco/H.248..and How it is >related to MPLS-QoS.. > >Thanks in Advance.. > >Regards >Suman > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Mon Apr 30 13:14:37 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19416 for ; Mon, 30 Apr 2001 13:14:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknaa06528; Mon, 30 Apr 2001 17:14:31 GMT Received: by mail-control.mail.uu.net id QQknaa04961 for mpls-outgoing; Mon, 30 Apr 2001 17:13:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknaa04921 for ; Mon, 30 Apr 2001 17:13:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknaa23245 for ; Mon, 30 Apr 2001 17:13:25 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQknaa05354 for ; Mon, 30 Apr 2001 17:13:25 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 1BA7594006; Mon, 30 Apr 2001 13:13:25 -0400 (EDT) Message-ID: <3AED9D35.340DA43E@sandburst.com> Date: Mon, 30 Apr 2001 13:13:25 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Osborne Cc: Bhupesh Bajaj , alexander@marhold.at, mpls@UU.NET Subject: Re: doubt in RFC 3031 References: <200104301046.QAA02582@localhost.localdomain> <20010430105743.A5258@che-cse-115.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, If you mean that the use of penultimate hop pop reduces the 'look-up' requirement at the egress without increasing the 'look-up' requirements at the penultimate hop, then you are correct. But it does incur some extra work for the penultimate hop - particularly in the case where the last label (bottom of stack) is being removed. Without penultimate hop pop, the penultimate hop doesn't even have to look to see if the current label is the last one. With PHP it has to do this and use different encap- sulation depending on the result. There is also implicit state requirements associated with accepting the implicit NULL label. This is cheap, but it isn't free. The current wording in the RFC, states that there is no new lookup required at the penultimate hop and - as you point out below - it is correct. It is not extraneous because the statement is needed in order to demonstrate that the desirability of the PHP optimization is justified. -- Eric Gray You wrote: > On Mon, Apr 30, 2001 at 04:22:57PM +0530, Bhupesh Bajaj wrote: > > hello, > > > > as far as i believe the penultimate hop is going to behave in same way ( as far as number of lookups is concerned )in both cases with / without using this technique.."penultimate hop popping".. > > > > so i believe it needn't be mentioned in RFC that with PNP one gets the benifit of just one lookup from penultimate hop side also as they have mentioned in RFC > > > > waiting for comments, > > > > The statement may be extraneous, but it's certainly true. THe idea > was (I think) to point out that implicit-null causes no extra work on > the penultimate router. Is there major objection to pointing this > out? > > eric > > > > > thanks and regards, > > bhupesh > > > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com From owner-mpls@UU.NET Mon Apr 30 15:32:44 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23485 for ; Mon, 30 Apr 2001 15:32:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknak24568; Mon, 30 Apr 2001 19:32:34 GMT Received: by mail-control.mail.uu.net id QQknak27106 for mpls-outgoing; Mon, 30 Apr 2001 19:31:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknak27079 for ; Mon, 30 Apr 2001 19:31:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknak09218 for ; Mon, 30 Apr 2001 19:31:37 GMT Received: from wrnxchg.Whiterocknetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.whiterocknetworks.com [65.192.92.133]) id QQknak20844 for ; Mon, 30 Apr 2001 19:31:36 GMT Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id <25S6SWPZ>; Mon, 30 Apr 2001 14:30:41 -0500 Message-ID: <66E0B27B8A29D511B19600D0B744446527AE25@192-168-1-220.customer.algx.net> From: "Fong, Man Wing" To: mpls@UU.NET, "'Kireeti Kompella'" Cc: ccamp@ops.ietf.org Subject: Question about logical link in Link bundling Date: Mon, 30 Apr 2001 14:30: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 Hi All, From "draft-kompella-mpls-bundle-05.txt", it indicates that multiple links between two LSRs can be bundled as a single link to improve the routing scalability. Apparently, it can be used to bundle multiple links from multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s, etc...) to be a single link. However, can it be used to bundle logical links like T1s in channelized T3, or DS3s, STS-3c in channelized OC-12 interface? Thanks. Regards, Man Wing From owner-mpls@UU.NET Mon Apr 30 15:55:09 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24162 for ; Mon, 30 Apr 2001 15:55:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknal29619; Mon, 30 Apr 2001 19:54:54 GMT Received: by mail-control.mail.uu.net id QQknal29989 for mpls-outgoing; Mon, 30 Apr 2001 19:54:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknal29890 for ; Mon, 30 Apr 2001 19:53:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknal01398 for ; Mon, 30 Apr 2001 19:51:23 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.axiowave.com [209.6.34.2]) id QQknal20438 for ; Mon, 30 Apr 2001 19:51:22 GMT Message-ID: From: Dimitry Haskin To: "'Sudhakar Ganti'" , mpls@UU.NET Cc: Nabil Seddigh , Biswajit Nandy Subject: RE: MPLS Support of E-LSPs Date: Mon, 30 Apr 2001 15:51:06 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D1AE.E4DB8400" 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_01C0D1AE.E4DB8400 Content-Type: text/plain; charset="iso-8859-1" Sudhakar, Thanks for the draft. The proposed extensions will provide a needed signaling support for the Diff-Serv's Uniform Tunneling model described in draft-ietf-mpls-diff-ext-09.txt. To make your proposal consistent with the Class-Type concept of draft-ietf-mpls-diff-te-reqts-00.txt, I would suggest to replace the PSC field of the proposed Traffic Profile with a 4-bit Class-Type (CT) field. In addition if your allow the ELSP Object to carry resource requirements for L-LSP also (you'd need to rename the object) there would be no need for the CLASSTYPE Object defined in draft-ietf-mpls-diff-te-ext-01.txt. Dimitry -----Original Message----- From: Sudhakar Ganti [mailto:sganti@tropicnetworks.com] Sent: Monday, April 30, 2001 12:39 PM To: mpls@UU.NET Cc: Nabil Seddigh; Biswajit Nandy Subject: MPLS Support of E-LSPs Hello, The following draft is available in the IETF draft repository that extends E-LSP signaling: Title: MPLS Support of Differentiated Services using E-LSP Authors: S.Ganti, N.Seddigh, B.Nandy URL: http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-elsp-00.txt The current E-LSP approach allows multiple Ordered Aggregates (OAs) to be carried by a single LSP. The existing E-LSP specification only supports collective bandwidth signalling for all the OAs in an E-LSP. However, there exist uses of the E-LSP approach where it is desirable to support bandwidth signalling on a per-OA or per-PSC basis. This draft extends the original E-LSP approach by defining extensions to support per-OA signalling. The extensions are proposed for both RSVP and CR-LDP. Please comment on the same. Thanks -Sudhakar ------------ Dr. Sudhakar Ganti Technical Specialist Tropic Networks Inc, Kanata, Ontario, Canada ------_=_NextPart_001_01C0D1AE.E4DB8400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS Support of E-LSPs

Sudhakar,

Thanks for the draft. The proposed extensions will = provide a needed signaling support for the Diff-Serv's Uniform = Tunneling model described in = draft-ietf-mpls-diff-ext-09.txt.

To make your proposal consistent with the Class-Type = concept of draft-ietf-mpls-diff-te-reqts-00.txt, I would suggest to = replace the PSC field of the proposed Traffic Profile with a 4-bit = Class-Type (CT) field. In addition if your allow the ELSP Object to = carry resource requirements for L-LSP also (you'd need to rename the = object) there would be no need for the CLASSTYPE Object defined in = draft-ietf-mpls-diff-te-ext-01.txt.

Dimitry

-----Original Message-----
From: Sudhakar Ganti [mailto:sganti@tropicnetworks.c= om]
Sent: Monday, April 30, 2001 12:39 PM
To: mpls@UU.NET
Cc: Nabil Seddigh; Biswajit Nandy
Subject: MPLS Support of E-LSPs


Hello,

The following draft is available in the IETF = draft
repository that extends E-LSP signaling:

Title: MPLS Support of Differentiated Services using = E-LSP
Authors: S.Ganti, N.Seddigh, B.Nandy
URL:
http://www.ietf.org/internet-drafts/draft-ganti-mpls-d= iffserv-elsp-00.txt

The current E-LSP approach allows multiple = Ordered
Aggregates  (OAs)  to  be = carried  by  a  single
LSP. The  existing  E-LSP specification = only supports
collective bandwidth signalling for all the OAs = in
an E-LSP. However, there exist uses of the = E-LSP
approach where it is desirable to support = bandwidth
signalling on a per-OA or per-PSC  = basis.
This draft extends the original E-LSP approach = by
defining extensions to support per-OA = signalling.
The extensions are proposed  for  both = RSVP and CR-LDP.

Please comment on the same. Thanks

-Sudhakar
------------
Dr. Sudhakar Ganti
Technical Specialist
Tropic Networks Inc,
Kanata, Ontario, Canada

------_=_NextPart_001_01C0D1AE.E4DB8400-- From owner-mpls@UU.NET Mon Apr 30 16:26:52 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24982 for ; Mon, 30 Apr 2001 16:26:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknan22694; Mon, 30 Apr 2001 20:26:47 GMT Received: by mail-control.mail.uu.net id QQknan22343 for mpls-outgoing; Mon, 30 Apr 2001 20:25:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknan22313 for ; Mon, 30 Apr 2001 20:25:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknan02788 for ; Mon, 30 Apr 2001 20:25:18 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQknan00099 for ; Mon, 30 Apr 2001 20:25:17 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3UKPGZ25868 for ; Mon, 30 Apr 2001 13:25:16 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA01442 for mpls@uu.net; Mon, 30 Apr 2001 16:25:15 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkmzz14690 for ; Mon, 30 Apr 2001 16:59:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkmzz18581 for ; Mon, 30 Apr 2001 16:56:08 GMT Received: from notes01.peakxv.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.169.12.3]) id QQkmzz26399 for ; Mon, 30 Apr 2001 16:56:08 GMT Received: from c385293a ([10.10.30.46]) by notes01.peakxv.net (Lotus Domino Release 5.0.7) with SMTP id 2001043009560500:27417 ; Mon, 30 Apr 2001 09:56:05 -0700 Message-ID: <04a901c0d196$3c3093d0$e996b018@c385293a> From: "Harish D V" To: "Bhupesh Bajaj" , Cc: , References: <200104301051.QAA02728@localhost.localdomain> Subject: Re: Re: megaco/H.248 Date: Mon, 30 Apr 2001 09:54:34 -0700 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on notes01/peakxv(Release 5.0.7 |March 21, 2001) at 04/30/2001 09:56:05 AM, Serialize by Router on notes01/peakxv(Release 5.0.7 |March 21, 2001) at 04/30/2001 09:56:08 AM, Serialize complete at 04/30/2001 09:56:08 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Also look at http://www.radvision.com/c_v2oip/c_papers.php3 Regards, Harish D V Peak XV Networks San Ramon CA - 94583 925-242-7459 office 925-381-9967 cell www.peakxv.net ----- Original Message ----- From: "Bhupesh Bajaj" To: Cc: ; Sent: Monday, April 30, 2001 3:58 AM Subject: Re: Re: megaco/H.248 > hi.. > Megaco is a Voip protocol which operates between Gateway and Call gents( Gateway Controllers) just like MGCP , and H.248 is similar recommendation by ITU. > but it isnt competing with SIP or H.323 as its areas of operation is totally different. Megaco Operates betweek Gateways and "Gateway Controllers" while H.323 and Sip Operate between different Gateway Controllers / Call Agents itself . > > thanks and regards > bhupesh. > > > > > ilazar@earthlink.net wrote: > > Hi, Megaco is a new VoIP signalling protocol that competes with SIP and H.323. You can find additional information at http://www.itprc.com/voice.htm Irwin At 01:14 PM 4/30/2001 +0530, S.K.Suman wrote: >Hi Everybody, > >I am going through the documents on QoS in MPLS..I came across the term >megaco/H.248 >Can anbody pls explain me,What exactly is megaco/H.248..and How it is >related to MPLS-QoS.. > >Thanks in Advance.. > >Regards >Suman > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Mon Apr 30 17:11:45 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26139 for ; Mon, 30 Apr 2001 17:11:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknaq07256; Mon, 30 Apr 2001 21:11:40 GMT Received: by mail-control.mail.uu.net id QQknaq14530 for mpls-outgoing; Mon, 30 Apr 2001 21:11:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknaq14443 for ; Mon, 30 Apr 2001 21:11:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknaq06962 for ; Mon, 30 Apr 2001 21:09:53 GMT Received: from gw.tropicnetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: gw.tropicnetworks.com [209.87.233.9]) id QQknaq19099 for ; Mon, 30 Apr 2001 21:09:52 GMT Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for cmr0.ash.ops.us.uu.net [198.5.241.38]) with SMTP; 30 Apr 2001 21:09:52 UT Received: from cr437225a ([10.1.2.190]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with SMTP id AAA2FFA for ; Mon, 30 Apr 2001 17:09:51 -0400 From: "Sudhakar Ganti" To: Subject: RE: MPLS TE question Date: Mon, 30 Apr 2001 17:08:42 -0400 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.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Also see the draft "Requirements for Multi-Area TE" http://www.ietf.org/internet-drafts/draft-ash-ccamp-multi-area-te-reqmts-00. txt This draft compares some of the interarea TE methods -Sudhakar -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Ibrahim Okumus Sent: Monday, April 30, 2001 11:24 AM To: Nhat Thanh Hoang Cc: 'Dirk Maeckelberghe'; mpls@UU.NET Subject: RE: MPLS TE question Hi Dirk, following might be a related pointer for your question. A Framework for the LSP Setup Across IGP Areas for MPLS Traffic Engineering draft-venkatachalam-interarea-mpls-te-01.txt _______________________________ Ibrahim Taner OKUMUS On Mon, 30 Apr 2001, Nhat Thanh Hoang wrote: > Hi, > > I Think you can find the answer at the following drafts: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt > http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-02.txt > > As I know contraint-based (the constraints such as bandwidth, link colors) > signaled LSPs can only be established within one IS-IS area, because the > traffic-engineering database is only propagating within an area. But, I > think there are RSVP-TE implementations (are vendor dependent)that support > inter-area LSPs by explicitly and strictly point out hop-by-hop along the > LSP you want to establsih and without the constraints: bandwidth and > linkcoloring. > See also the comment line below: > > -----Original Message----- > From: Dirk Maeckelberghe [mailto:Dirk.Maeckelberghe@swift.com] > Sent: den 30 april 2001 14:53 > To: mpls@UU.NET > Subject: MPLS TE question > > > Hello, > > Can you point me to the right references or help answer underneath > questions. > > I need to know if I can use the TE extensions to setup an LSP using RSVP-TE > ( cross area ) in case my IGP is hierarchical IS-IS ( > L1 and L2 ). > Can I assume that summarization happens at area boundaries and that the > detailed TE info does not get propagated inside the area ? > > - Yes, You are right about that. > > This is case A to B where A,B LER and L2A and L2B LSR > > A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > > If now I am only extending my MPLS cloud to the L2 routers ( L2A - L2B are > now LER ), A and B are NON-MPLS routers, > can I then use the TE extensions of IS-IS to do TE between the L2A and L2B. > I understand that the L2 routers only form L2 adjacencies, are the TE > extensions communicated between them ? > > - I'm not sure if I understand you correctly, and I suppose that now you > mean the changed scenario is L2A, L2X and L2B are Level 2 MPLS-capable > routers, then the answer to your question is YES. > > - If I'm wrong please correct me. > > - I hope it would help something > > Cheers, > /Nhat Thanh > > Telia Research AB > > A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > Thanks, > > Dirk > From owner-mpls@UU.NET Mon Apr 30 17:18:29 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26265 for ; Mon, 30 Apr 2001 17:18:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknar29171; Mon, 30 Apr 2001 21:18:17 GMT Received: by mail-control.mail.uu.net id QQknar16874 for mpls-outgoing; Mon, 30 Apr 2001 21:17:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknar16850 for ; Mon, 30 Apr 2001 21:17:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknar28857 for ; Mon, 30 Apr 2001 21:17:07 GMT Received: from eth.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.eth.net [202.9.145.18]) id QQknar27698 for ; Mon, 30 Apr 2001 21:17:06 GMT Received: from mail pickup service by eth.net with Microsoft SMTPSVC; Tue, 1 May 2001 02:37:06 +0530 Received: from host.secure4-hosting.net ([209.239.41.31]) by eth.net with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 30 Apr 2001 22:24:22 +0530 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3UBmhf23310 for murukku@eth.net; Mon, 30 Apr 2001 07:48:43 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f From: "Bhupesh Bajaj" Message-Id: <200104301035.QAA02352@localhost.localdomain> To: , CC: , Reply-To: "Bhupesh Bajaj" Subject: RE: doubt in RFC 3031 Date: Mon, 30 Apr 2001 16:11:37 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii X-Mailing-List: archive/latest/1087 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk thanks asheesh and sumit , but my douubt was that in RFC they have mentioned that... ".. This technique allows the egress to do a single lookup, and also requires only a single lookup by the penultimate node.." to be noticed.." and also requires only a single lookup by penultimate..." which anyways is the case... so as far as penultimate hop is concerned ..it in both cases will be operating in same way i.e looking for the labbel and if not found looking for network information and sending the packet ... so as far as this technique is concerned the benifit one gets is from egress side and penultimate hop will still be having to do the same number of lookups in both cases with / without this technique.. thats all the confusion was , as in the RFC they have mentioned in a way that one gets benifit on penultimate hop lookups also.. anyways..thanks for prompt reply regards bhupesh Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Mon Apr 30 17:39:02 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26496 for ; Mon, 30 Apr 2001 17:38:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknas09504; Mon, 30 Apr 2001 21:38:39 GMT Received: by mail-control.mail.uu.net id QQknas19716 for mpls-outgoing; Mon, 30 Apr 2001 21:37:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknas19703 for ; Mon, 30 Apr 2001 21:37:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknas01888 for ; Mon, 30 Apr 2001 21:37:29 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknas08093 for ; Mon, 30 Apr 2001 21:37:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA17068 for mpls@uu.net; Mon, 30 Apr 2001 17:37:28 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknas19144 for ; Mon, 30 Apr 2001 21:32:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknar16244 for ; Mon, 30 Apr 2001 21:27:28 GMT Received: from eth.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.eth.net [202.9.145.18]) id QQknar06356 for ; Mon, 30 Apr 2001 21:27:26 GMT Received: from mail pickup service by eth.net with Microsoft SMTPSVC; Tue, 1 May 2001 02:39:45 +0530 Received: from host.secure4-hosting.net ([209.239.41.31]) by eth.net with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 30 Apr 2001 22:33:47 +0530 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3UHCPB17757 for murukku@eth.net; Mon, 30 Apr 2001 13:12:25 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Date: Mon, 30 Apr 2001 10:57:43 -0400 From: Eric Osborne To: Bhupesh Bajaj Cc: alexander@marhold.at, mpls@UU.NET, mpls-ops@mplsrc.com Subject: Re: RE: doubt in RFC 3031 Message-ID: <20010430105743.A5258@che-cse-115.cisco.com> References: <200104301046.QAA02582@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104301046.QAA02582@localhost.localdomain>; from mpls@indiatimes.com on Mon, Apr 30, 2001 at 04:22:57PM +0530 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 X-Mailing-List: archive/latest/1092 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Apr 30, 2001 at 04:22:57PM +0530, Bhupesh Bajaj wrote: > hello, > > as far as i believe the penultimate hop is going to behave in same way ( as far as number of lookups is concerned )in both cases with / without using this technique.."penultimate hop popping".. > > so i believe it needn't be mentioned in RFC that with PNP one gets the benifit of just one lookup from penultimate hop side also as they have mentioned in RFC > > waiting for comments, > The statement may be extraneous, but it's certainly true. THe idea was (I think) to point out that implicit-null causes no extra work on the penultimate router. Is there major objection to pointing this out? eric > > thanks and regards, > bhupesh > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Mon Apr 30 18:22:30 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27305 for ; Mon, 30 Apr 2001 18:22:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknav03264; Mon, 30 Apr 2001 22:22:11 GMT Received: by mail-control.mail.uu.net id QQknav14195 for mpls-outgoing; Mon, 30 Apr 2001 22:21:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknav14174 for ; Mon, 30 Apr 2001 22:21:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknav06392 for ; Mon, 30 Apr 2001 22:20:33 GMT Received: from eth.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.eth.net [202.9.145.18]) id QQknav05810 for ; Mon, 30 Apr 2001 22:20:32 GMT Received: from mail pickup service by eth.net with Microsoft SMTPSVC; Tue, 1 May 2001 03:23:18 +0530 Received: from host.secure4-hosting.net ([209.239.41.31]) by eth.net with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 30 Apr 2001 23:24:49 +0530 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f3UBng323559 for murukku@eth.net; Mon, 30 Apr 2001 07:49:42 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f From: "Bhupesh Bajaj" Message-Id: <200104301051.QAA02728@localhost.localdomain> To: CC: , Reply-To: "Bhupesh Bajaj" Subject: Re: Re: megaco/H.248 Date: Mon, 30 Apr 2001 16:28:00 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii X-Mailing-List: archive/latest/1090 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk hi.. Megaco is a Voip protocol which operates between Gateway and Call Agents( Gateway Controllers) just like MGCP , and H.248 is similar recommendation by ITU. but it isnt competing with SIP or H.323 as its areas of operation is totally different. Megaco Operates betweek Gateways and "Gateway Controllers" while H.323 and Sip Operate between different Gateway Controllers / Call Agents itself . thanks and regards bhupesh. ilazar@earthlink.net wrote: Hi, Megaco is a new VoIP signalling protocol that competes with SIP and H.323. You can find additional information at http://www.itprc.com/voice.htm Irwin At 01:14 PM 4/30/2001 +0530, S.K.Suman wrote: >Hi Everybody, > >I am going through the documents on QoS in MPLS..I came across the term >megaco/H.248 >Can anbody pls explain me,What exactly is megaco/H.248..and How it is >related to MPLS-QoS.. > >Thanks in Advance.. > >Regards >Suman > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Mon Apr 30 18:50:03 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27693 for ; Mon, 30 Apr 2001 18:50:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknax06773; Mon, 30 Apr 2001 22:49:58 GMT Received: by mail-control.mail.uu.net id QQknax17618 for mpls-outgoing; Mon, 30 Apr 2001 22:49:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknax17607 for ; Mon, 30 Apr 2001 22:49:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknax01396 for ; Mon, 30 Apr 2001 22:48:49 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknax05058 for ; Mon, 30 Apr 2001 22:48:49 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA06897; Mon, 30 Apr 2001 18:48:40 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA01717; Mon, 30 Apr 2001 18:48:42 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Apr 2001 18:48:36 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF446C53@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'Dimitry Haskin'" , "'Sudhakar Ganti'" , mpls@UU.NET Cc: Nabil Seddigh , Biswajit Nandy Subject: RE: MPLS Support of E-LSPs Date: Mon, 30 Apr 2001 18:48:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D1C7.B3874E20" 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_01C0D1C7.B3874E20 Content-Type: text/plain; charset="iso-8859-1" Hi! I agree that this draft brings a much needed clarity to the E-LSP support ( specifically from a CAC point of view). However, I differ from your suggestion to replace the PSC field with the Class-Type field. Here are the reasons: 1. Platforms that do not support the class-type extensions proposed in the diff-te-reqts-00.txt draft, can still take advantage of this draft. Platforms that do implement the class-type extensions, can still determine the class-type from the signaled PSC, 2. In my opinion Class-Type concept proposed in the diff-te-reqts-00.txt, is a good optimization of the IGPs, but not very useful for signaled LSPs. Since PSC-->Class-Type information is locally configured anyway, one can easily determine the class-type from the associated PSC. Infact, in my opinion the idea proposed in this draft, is a cleaner approach to signal bandwidth for OAs, than the one specified in the draft-ietf-mpls-diff-te-ext-01.txt. Thanks, sanjay -----Original Message----- From: Dimitry Haskin [mailto:dhaskin@axiowave.com] Sent: Monday, April 30, 2001 3:51 PM To: 'Sudhakar Ganti'; mpls@UU.NET Cc: Nabil Seddigh; Biswajit Nandy Subject: RE: MPLS Support of E-LSPs Sudhakar, Thanks for the draft. The proposed extensions will provide a needed signaling support for the Diff-Serv's Uniform Tunneling model described in draft-ietf-mpls-diff-ext-09.txt. To make your proposal consistent with the Class-Type concept of draft-ietf-mpls-diff-te-reqts-00.txt, I would suggest to replace the PSC field of the proposed Traffic Profile with a 4-bit Class-Type (CT) field. In addition if your allow the ELSP Object to carry resource requirements for L-LSP also (you'd need to rename the object) there would be no need for the CLASSTYPE Object defined in draft-ietf-mpls-diff-te-ext-01.txt. Dimitry -----Original Message----- From: Sudhakar Ganti [ mailto:sganti@tropicnetworks.com ] Sent: Monday, April 30, 2001 12:39 PM To: mpls@UU.NET Cc: Nabil Seddigh; Biswajit Nandy Subject: MPLS Support of E-LSPs Hello, The following draft is available in the IETF draft repository that extends E-LSP signaling: Title: MPLS Support of Differentiated Services using E-LSP Authors: S.Ganti, N.Seddigh, B.Nandy URL: http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-elsp-00.txt The current E-LSP approach allows multiple Ordered Aggregates (OAs) to be carried by a single LSP. The existing E-LSP specification only supports collective bandwidth signalling for all the OAs in an E-LSP. However, there exist uses of the E-LSP approach where it is desirable to support bandwidth signalling on a per-OA or per-PSC basis. This draft extends the original E-LSP approach by defining extensions to support per-OA signalling. The extensions are proposed for both RSVP and CR-LDP. Please comment on the same. Thanks -Sudhakar ------------ Dr. Sudhakar Ganti Technical Specialist Tropic Networks Inc, Kanata, Ontario, Canada ------_=_NextPart_001_01C0D1C7.B3874E20 Content-Type: text/html; charset="iso-8859-1" RE: MPLS Support of E-LSPs
 
         Hi! I agree that this draft brings a much needed clarity to the E-LSP support (
        specifically from a CAC point of view). However, I differ from your suggestion
        to replace the PSC field with the Class-Type field. Here are the reasons:
 
            1. Platforms that do not support the class-type extensions proposed
                in the diff-te-reqts-00.txt draft, can still take advantage of this
                draft.
 
                Platforms that do implement the class-type extensions, can still
                determine the class-type from the signaled PSC,
 
            2. In my opinion Class-Type concept proposed in the diff-te-reqts-00.txt,
                is a good optimization of the IGPs, but not very useful for signaled
                LSPs. Since PSC-->Class-Type information is locally configured anyway,
                one can easily determine the class-type from the associated PSC.
 
                Infact, in my opinion the idea proposed in this draft, is a cleaner
                approach to signal bandwidth for OAs, than the one specified in the
                draft-ietf-mpls-diff-te-ext-01.txt.
 
         Thanks,
         sanjay
-----Original Message-----
From: Dimitry Haskin [mailto:dhaskin@axiowave.com]
Sent: Monday, April 30, 2001 3:51 PM
To: 'Sudhakar Ganti'; mpls@UU.NET
Cc: Nabil Seddigh; Biswajit Nandy
Subject: RE: MPLS Support of E-LSPs

Sudhakar,

Thanks for the draft. The proposed extensions will provide a needed signaling support for the Diff-Serv's Uniform Tunneling model described in draft-ietf-mpls-diff-ext-09.txt.

To make your proposal consistent with the Class-Type concept of draft-ietf-mpls-diff-te-reqts-00.txt, I would suggest to replace the PSC field of the proposed Traffic Profile with a 4-bit Class-Type (CT) field. In addition if your allow the ELSP Object to carry resource requirements for L-LSP also (you'd need to rename the object) there would be no need for the CLASSTYPE Object defined in draft-ietf-mpls-diff-te-ext-01.txt.

Dimitry

-----Original Message-----
From: Sudhakar Ganti [mailto:sganti@tropicnetworks.com]
Sent: Monday, April 30, 2001 12:39 PM
To: mpls@UU.NET
Cc: Nabil Seddigh; Biswajit Nandy
Subject: MPLS Support of E-LSPs


Hello,

The following draft is available in the IETF draft
repository that extends E-LSP signaling:

Title: MPLS Support of Differentiated Services using E-LSP
Authors: S.Ganti, N.Seddigh, B.Nandy
URL:
http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-elsp-00.txt

The current E-LSP approach allows multiple Ordered
Aggregates  (OAs)  to  be carried  by  a  single
LSP. The  existing  E-LSP specification only supports
collective bandwidth signalling for all the OAs in
an E-LSP. However, there exist uses of the E-LSP
approach where it is desirable to support bandwidth
signalling on a per-OA or per-PSC  basis.
This draft extends the original E-LSP approach by
defining extensions to support per-OA signalling.
The extensions are proposed  for  both RSVP and CR-LDP.

Please comment on the same. Thanks

-Sudhakar
------------
Dr. Sudhakar Ganti
Technical Specialist
Tropic Networks Inc,
Kanata, Ontario, Canada

------_=_NextPart_001_01C0D1C7.B3874E20-- From owner-mpls@UU.NET Mon Apr 30 23:08:39 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03826 for ; Mon, 30 Apr 2001 23:08:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknbo11557; Tue, 1 May 2001 03:08:26 GMT Received: by mail-control.mail.uu.net id QQknbo11621 for mpls-outgoing; Tue, 1 May 2001 03:07:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknbo11608 for ; Tue, 1 May 2001 03:07:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknbo03657 for ; Tue, 1 May 2001 03:07:29 GMT Received: from dtctxexchims05.ins.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.164.93.100]) id QQknbo26100 for ; Tue, 1 May 2001 03:07:28 GMT Received: from KENT (aventail.ins.com [208.164.93.91]) by dtctxexchims05.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 210KXXDH; Mon, 30 Apr 2001 22:02:20 -0500 Message-ID: <007b01c0d204$fde2df60$5b5da4d0@KENT> Reply-To: "Kent Yu" From: "Kent Yu" To: "Bhupesh Bajaj" , Cc: , References: <200104301046.QAA02582@localhost.localdomain> Subject: Re: RE: doubt in RFC 3031 Date: Mon, 30 Apr 2001 23:07:20 -0700 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 bhupesh, Seems to me the phrase here emphasizes the PHP does not require either the egress or the penultimate router do more than one lookup. The authors, IMHO, believe it is necessary to clarify the PHP does not transfer the two lookups from the edge to either the penultimate hop or any other LSRs along the LSP. HTH Kent Yu ----- Original Message ----- From: "Bhupesh Bajaj" To: Cc: ; Sent: Monday, April 30, 2001 3:52 AM Subject: Re: RE: doubt in RFC 3031 > hello, > > as far as i believe the penultimate hop is going to behave in same way as far as number of lookups is concerned )in both cases with / without using this technique.."penultimate hop popping".. > > so i believe it needn't be mentioned in RFC that with PNP one gets the benifit of just one lookup from penultimate hop side also as they have mentioned in RFC > > waiting for comments, > > > thanks and regards, > bhupesh > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml