From owner-mpls@UU.NET Mon Jul 1 02:44:02 2002 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 ESMTP id CAA02706 for ; Mon, 1 Jul 2002 02:44:02 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpa05127 for ; Mon, 1 Jul 2002 06:44:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvpa02110; Mon, 1 Jul 2002 06:43:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvpa16803 for mpls-outgoing; Mon, 1 Jul 2002 06:42:47 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvpa16796 for ; Mon, 1 Jul 2002 06:42: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 QQmvpa26565 for ; Mon, 1 Jul 2002 06:42:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpa20687 for ; Mon, 1 Jul 2002 06:42:17 GMT Received: from tama5.ecl.ntt.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQmvpa20667 for ; Mon, 1 Jul 2002 06:42:16 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id PAA14147; Mon, 1 Jul 2002 15:41:42 +0900 (JST) (envelope-from yasukawa.seisho@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g616ffxV026157; Mon, 1 Jul 2002 15:41:41 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g616ffn5007956; Mon, 1 Jul 2002 15:41:41 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id PAA23897; Mon, 1 Jul 2002 15:41:40 +0900 (JST) Received: from [129.60.144.181] by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id PAA19144; Mon, 1 Jul 2002 15:41:32 +0900 (JST) X-Authentication-Warning: imc.m.ecl.ntt.co.jp: [129.60.144.181] didn't use HELO protocol Message-Id: <4.3.2-J.20020701130120.00bc8c58@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Mon, 01 Jul 2002 15:40:14 +0900 To: David Charlap , IETF MPLS List From: Seisho Yasukawa Subject: Re: I-D ACTION:draft-yasukawa-mpls-rsvp-multicast-00.txt In-Reply-To: <3D1B4D0C.7070509@marconi.com> References: <200206271038.GAA08972@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dear David Thank you for your comment. I agree that classical RSVP was designed around multicast and existing RSVP-TE can cope with multicast in essesntial. But I still think existing RSVP-TE is not suitable and some modifications are necessary to support multicast because its lack of TE function. >In my opinion, this draft is not necessary. It is based on the incorrect >assumption that RSVP-TE, as it is currently defined, does not have >supprort for multicast. > >Classical RSVP was designed around multicast, and RSVP-TE introduces >nothing to change this, even though it does not explicitly describe a >multicast implementation. As mentioned above, I agree with your assumption to RSVP-TE basically. But please note that our draft describe some modification and extensions to existing RSVP-TE in order to cope with not only multicast application but also p-to-mp application. >For a multicast LSP, one has only to specify a multicast group address in >the SESSION object (the tunnel endpoint address), and do not include an >EXPLICIT_ROUTE object. Normal Path processing should propagate the Path >message to all next-hops in the multicast group, according to the >multicast table that already exists. We think some modification is necessary to SESSION object definition when considering multicast session. We think it is important to define multicast LSP tunnel independent to its accomodated traffic. In this design, intermediate node along the LSP must not conscious of its accomodated traffic protocol. And we want a p-to-mp LSP to accomodate both multiple IP multicast group traffic and non-IP traffic, such as Ether traffic. Therefore, it is not convenient to specify a multicast group address in the SESSION object. To enable the identification and association of such multicast LSP tunnels, new MULTICAST_LSP_TUNNEL session objects are defined in our proposal. Each session object carries the sender node address of a p-to-mp LSP and its tunnel ID. The sender node address is more preferable than destination (leaf) node addresses to identify a multicast LSP tunnel because frequent topological changes may occur and destination node addresses are not stable in this tunnel. Therefore, the SENDER_TEMPLATE (or FILTER_SPEC) object together with this SESSION object uniquely identify a multicast LSP tunnel. To identify the leaf and topology of this multicast LSP tunnel, TREE_EXPLICIT_ROUTE object and TREE_RECORD_ROUTE object are also defined. >I am aware that RSVP-TE's definition of EXPLICIT_ROUTE and RECORD_ROUTE >does not accommodate multicast. If there is some need to specify an >explicit multicast tree that differs from the multicast routing table, >then this might be required. > >Personally, I think attempting to traffic-engineer a multicast tree >beyond what existing multicast routing protocols already do is pointless. >Any automatic process for generating these trees will duplicate all of the >work that routing protocols already do. Any manual process will be >unmanageable, since receivers may be continuously joining and leaving the >multicast group. We think Traffic Engineering become more important when considering multicast application. A multicast LSP has more complex topology and it affect network switching resource more drastically compared with unicast LSP. And we think it is not enough to combine existing multicast routing protocol and RSVP-TE to enable mulitcast traffic engineering. We think what existing multicast routing protocol do for traffic-engineering is completely weak. For example, PIM-SM that is most widely used multicast protocol, I think, has three phases to establish muticast tree. Phase 1: Encapsulation transmission to Randezvous Point (RP) + RP Multicast Tree distribution Phase 2: Register Stop Process which switch over to (S,G) transmission from RP encapsulation transmission Phase 3: Shortest Path multicast distribution (switch over from RP transmission) This mechanism allows very frequent topological change into tree topology. Therefore we think it is not realistic to make multicast LSP synchronized with L3 multicast routing protocol. We can not control multicast traffic completely in this design. Moreover, path-protection mechanism or rerouting mechanism are not supported in this design. >Given the infeasability of a manually-configured multicast LSP, we're >back to automatic configuration. RSVP, as it currently stands, is >sufficient in this situation. It reads the existing multicast routing >table to determine the next-hops for a multicast group, and monitors the >routing table to add and remove next-hops as needed. Rules for merging >FLOWSPEC objects are already in place. Rules for merging labels are >self-evident. > >While it is true that current RSVP-TE implementations do not have support >for multicast LSPs, there is nothing in RFC 3209 that prohibits the use of >RSVP-TE for multicast situations. Note that the only part of RSVP-TE that >is not multicast-friendly is the EXPLICIT_ROUTE object - ant this object >is optional in Path messages anyway. > >-- David As you mentioned above, it is better to construct multicast LSP automatically. We can use TERO for this purpose. Some multicast tree calculation mechanism that is implemented in Network Mangement Sytem or Sender node calculate TERO that represents suitable multicast tree and invoke this multicast MPLS protocol to setup multicast LSP tunnel. And as mentioned in our draft, our scheme also target to support multicast LSP setup using multicast routing table information. We are sevice provider and strongly need this p-to-mp LSP setup mechanism to enable Contents delivery service and p-to-mp L2/MPLS service. We are willing to modify our proposal to accelerate this discussion. Please join this discussion and give us comments. Seisho From owner-mpls@UU.NET Mon Jul 1 03:21:57 2002 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 ESMTP id DAA03471 for ; Mon, 1 Jul 2002 03:21:57 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpd19859 for ; Mon, 1 Jul 2002 07:22:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvpd18836; Mon, 1 Jul 2002 07:22:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvpd12279 for mpls-outgoing; Mon, 1 Jul 2002 07:21:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvpd12272 for ; Mon, 1 Jul 2002 07:21: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 QQmvpd13499 for ; Mon, 1 Jul 2002 07:20:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpd27332 for ; Mon, 1 Jul 2002 07:20:26 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQmvpd27323 for ; Mon, 1 Jul 2002 07:20:25 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 JAA26858; Mon, 1 Jul 2002 09:19:50 +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 JAA20239; Mon, 1 Jul 2002 09:20:03 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 09:19:30 +0200 Message-ID: From: Hummel Heinrich To: "'ananth.nagarajan@mail.sprint.com'" , ananth@celoxnetworks.com, mpls@UU.NET, Shahram_Davari@pmc-sierra.com Cc: ppvpn@ppvpn.francetelecom.com Subject: AW: Basic LDP Question Date: Mon, 1 Jul 2002 09:19:06 +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 Ananth wrote: MPLS is not like source routing. if you use LDP, it is very much like IP routing. Also, source routing is true only if you use "explicit routing". Ananth Already years ago (in Oslo) I proposed to provide explicit routing for mp2p resp. p2mp LSPs. By inserting "bracket"-TLVs between ER HOP-TLVs you can provide the info for a tree-like source route. This tree-route may take into consideration QoS,policy, etc. You may even build several such LSPs using different Explicit tree route information, as to get them differently routed - e.g. for supporting traffic balancing. Unfortunately, no one cared at that time. Would there be interest now, to provide a, what I called, TREE ROUTE TLV e.g. for establishing mp2p LSPs in support of VPN ? Heinrich Hummel From owner-mpls@UU.NET Mon Jul 1 04:08:59 2002 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 ESMTP id EAA09957 for ; Mon, 1 Jul 2002 04:08:59 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpg24605 for ; Mon, 1 Jul 2002 08:09:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvpg21795; Mon, 1 Jul 2002 08:08:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvpg06633 for mpls-outgoing; Mon, 1 Jul 2002 08:07:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvpg06617 for ; Mon, 1 Jul 2002 08:07: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 QQmvpg27668 for ; Mon, 1 Jul 2002 08:06:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpg20956 for ; Mon, 1 Jul 2002 08:06:29 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 QQmvpg20937 for ; Mon, 1 Jul 2002 08:06:28 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA10667; Mon, 1 Jul 2002 10:06:19 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA23388; Mon, 1 Jul 2002 10:06:19 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 10:05:46 +0200 Message-ID: From: Hummel Heinrich To: "'neil.2.harrison@bt.com'" , asimha@cisco.com Cc: mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: AW: Basic LDP Question Date: Mon, 1 Jul 2002 10:05:40 +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 EAA09957 In response to a previous email on this thread I wrote today what also fits in response to Neil Harrison's email from below: Already years ago (in Oslo) I proposed to provide explicit routing for mp2p resp. p2mp LSPs. By inserting "bracket"-TLVs between ER HOP-TLVs you can provide the info for a tree-like source route. This tree-route may take into consideration QoS,policy, etc. You may even build several such LSPs using different Explicit tree route information, as to get them differently routed - e.g. for supporting traffic balancing. Unfortunately, no one cared at that time. Yes,LDP only yields LSPs, routed like by SPF. In Oslo I showed how to compute (at the ingress) the explicit tree-like source route while considering all kind of QoS&Policy constraints and how to put the results into some TREE ROUTE TLV. I also showed how to process that TLV at each hop so that only the right part of it, which is still needed ahead,is forwarded via the respective child links. In new draft-hummel-mpls-n-square-investigations-00.txt I mention four methods how to provide a full mesh connectivity for layer-3 /layer-2 VPNs. One of the methods use merging normal LSPs, one of the methods use merging hierarchical LSPs. In both cases an Explicit Tree Route TLV could take care of all the QoS/policy/traffic balancing aspects. Question: Is there sufficient interest now to bring those ideas from draft-hummel-mpls-explicit-tree-01.txt, expired in Dec 1999, once more to the coming IETF meetings ? Heinrich Hummel -----Ursprüngliche Nachricht----- Von: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Gesendet: Montag, 3. Juni 2002 12:26 An: asimha@cisco.com Cc: mpls@UU.NET; ppvpn@ppvpn.francetelecom.com Betreff: RE: Basic LDP Question Ajay, Let me take you back to the point of Shahram's orginal question.....which in essence, if I have understood it correctly, was 'what problem/application is LDP solving/addressing that cannot be done either (i) using IP directly or (ii) ER LSPs?'.....and which must also take a wider pro/con analysis of the implications of using LDP-LSPs vs ER-LSPs (or IP directly). Please also see below. Regards, Neil Ajay Simha wrote 01 June 2002 04:15 > The point is MPLS effectively decouples the forwarding > portion from the > routing. NH=> Well I agree, this is vital and it's what is needed. And it's something we in Telco-land have known/used for years, ie decoupling of the traffic carrying data-plane and its control-plane (both its own data-plane, where appropriate, and its routing and signalling protocols). But LDP does nothing more than instantiate labels per hop that are locked to the IGP. That is (i) they take the same SPF routes as the IGP would use for IP fowarding and (ii) the LSPs change as the IGP changes. I would argue this is not a required behaviour for applications where LSPs are long-holding and/or must not be affected by ad hoc routing changes or failures of routing protocols (eg VPNs). Further, because LDP is so tightly coupled to the IGP then one has to introduce 'layer violations' to make it work a bit better, eg Load-balancing using IP-level hashing......its hard to take seriously anyone claiming this is MPLS label forwarding when one has to look at the client/IP level (which it may not always be, ie XoverMPLS) to make switching/forwarding decisions. > This makes MPLS a service enabler. NH=> I don't agree that *LDP* makes MPLS a 'service-enabler'. Considered against a VPN service, the behaviour noted above is not what is needed. Now take the fact that QoS (a pkt forwarding attribute) and survivability (an LSP attribute) need decoupling so that per VPN QoS/availability SLAs can be defined/measured (independent of other VPNs) and look what LDP does to that.....it mangles then both so they can't be decoupled, and now VPN QoS/survivability behaviour is no longer independent on a per VPN basis. Again this is not the required behaviour for VPNs. > For instance I > did not see anyone > mention things like QoS transparency that MPLS can achieve. NH=> How can you claim this in view of the above observations? Further, on what basis are you discussing QoS? That is, unless you can automatically fault-manage MPLS I fail to see how anyone has any basis on which to discuss QoS with any conviction......you have to define availability 1st, since QoS metrics *only* have relevance to the up-state, and availability is dependent of having defects defined. So where are the defects defined and where is availability defined?....once you can point at these then we can meaningfully discuss QoS, but not before. > Sure you can > monkey around with IP to make IP have everything that MPLS > has. NH=> No, you have to monkey around with LDP (eg load-balancing) because it does not provide sufficient decoupling from IP behaviour as I noted above. > May be even a > fixed length tag and call it something else :). > > Why do it when this extension already exists as an IETF based > standards where > folks like us can debate issues and come up with solutions > that are acceptable > to most? NH=> I have no problems with people defining solution's for a restricted perspective of the problem-space if that is all they need/want from MPLS, just so long as they don't try to stop others defining solutions which have a more general application. I have a strong sense that some people want to do this....and therein lies the real problem IMO. > > -ajay > > > >:Robert Raszuk writes: > >: > >: > Currently deployed hardware & software. > >: > >:your current router hardware can't do many other things either, like > >:learning mac addresses. so when you re-spin it, you could > also consider > >:adding real support for ip tunneling for those who don't like the > >:complexity of mpls control plane. > >: > >:-- juha > >: > > -- > From owner-mpls@UU.NET Mon Jul 1 04:19:48 2002 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 ESMTP id EAA10222 for ; Mon, 1 Jul 2002 04:19:48 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvph08214 for ; Mon, 1 Jul 2002 08:20:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvph06121; Mon, 1 Jul 2002 08:19:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvph08621 for mpls-outgoing; Mon, 1 Jul 2002 08:19:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvph08616 for ; Mon, 1 Jul 2002 08:19: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 QQmvph22118 for ; Mon, 1 Jul 2002 08:18:58 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvph05361 for ; Mon, 1 Jul 2002 08:18:57 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f270.law12.hotmail.com [64.4.18.145]) id QQmvph05348 for ; Mon, 1 Jul 2002 08:18:57 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Jul 2002 01:18:56 -0700 Received: from 63.197.79.145 by lw12fd.law12.hotmail.msn.com with HTTP; Mon, 01 Jul 2002 08:18:56 GMT X-Originating-IP: [63.197.79.145] From: "George Sheng" To: asimha@cisco.com, Shahram_Davari@pmc-sierra.com Cc: eosborne@cisco.com, scullptor@yahoo.com, mpls@UU.NET Subject: RE: your mail Date: Mon, 01 Jul 2002 08:18:56 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Jul 2002 08:18:56.0553 (UTC) FILETIME=[F1BCB990:01C220D7] Sender: owner-mpls@UU.NET Precedence: bulk > >SD: Silly or not, I am afraid it is the reality. LDP is inherently unable >to > >SD:do load ballancing, that is why this kludge is there. > >Shahram, > >What are we comparing this against? IP? Please explain how in the IP world >one >achieved IP vs non-IP load balancing and how it is different when you run >LDP? well, for example, take a topology below: R2 / \ R1 R3 -- R5 -- R6 \ / R4 assume the IGP cost is the same for all the links above. In the "native" IP mode, traffic from R6 to R1, they will be(normally) load shared using the links to both R2 and R4, R3 is the router performs this ECMP loadsharing(IP flow based usually). now, if R1 through R6 are running LDP, please tell me how does R3 perform the same flow based ECMP loadsharing(without looking into the IP packets)? -george _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Mon Jul 1 05:23:29 2002 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 ESMTP id FAA14893 for ; Mon, 1 Jul 2002 05:23:29 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpl22856 for ; Mon, 1 Jul 2002 09:24:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvpl19768; Mon, 1 Jul 2002 09:22:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvpl05560 for mpls-outgoing; Mon, 1 Jul 2002 09:22:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvpl05555 for ; Mon, 1 Jul 2002 09:22: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 QQmvpl03750 for ; Mon, 1 Jul 2002 09:22:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpl19179 for ; Mon, 1 Jul 2002 09:22:04 GMT Received: from ziplip.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ziplip.com [128.242.109.119]) id QQmvpl19175 for ; Mon, 1 Jul 2002 09:22:04 GMT Received: from 10.1.0.20 (EHLO 10.1.0.20 10.1.0.20 [10.1.0.20] (may be forged)) by 10.1.0.20 with ESMTP id for ; 01 Jul 2002 02:21:23 -0700 (PDT) Message-ID: Date: Mon, 1 Jul 2002 02:21:23 -0700 (PDT) From: vivek_1975 Reply-To: vivek_1975 To: mpls@UU.NET Subject: LDP Question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ZLExpiry: -1 X-ZLReceiptConfirm: N X-ZLAuthType: WEB-MAIL X-ZLAuthOn: Y X-Mailer: ZipLip Sonoma v3.2 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In RFC3036 section 2.6.2.2 says When operating in Downstream on Demand mode with liberal label retention, an LSR might choose to request label mappings for all known prefixes from all peer LSRs. As per my understanding there won't be any restriction when we learn any routes from IP and we obtain the mappings by sending Label Request for all the learnt FEC's (FEC aggregation/without aggregation) if we find the required session/adjacenecy with the peer. So DoD acts as liberal in nature....... Does this mean any filtering is done for achieving conservative in DoD or am I missing something........ Thanks and Regards Vivek From owner-mpls@UU.NET Mon Jul 1 06:14:13 2002 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 ESMTP id GAA19105 for ; Mon, 1 Jul 2002 06:14:13 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpo00532 for ; Mon, 1 Jul 2002 10:14:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvpo28398; Mon, 1 Jul 2002 10:14:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvpo00955 for mpls-outgoing; Mon, 1 Jul 2002 10:13:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvpo00948 for ; Mon, 1 Jul 2002 10:13: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 QQmvpo17290 for ; Mon, 1 Jul 2002 10:12:13 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpo12571 for ; Mon, 1 Jul 2002 10:12:13 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmvpo12563 for ; Mon, 1 Jul 2002 10:12:13 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17Oy9u-0000zX-00; Mon, 01 Jul 2002 11:11:50 +0100 Subject: RE: your mail From: Giles Heron To: George Sheng Cc: asimha@cisco.com, Shahram_Davari@pmc-sierra.com, eosborne@cisco.com, scullptor@yahoo.com, mpls@UU.NET In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 01 Jul 2002 11:11:51 +0000 Message-Id: <1025521911.1543.23.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-07-01 at 08:18, George Sheng wrote: > > > > > >SD: Silly or not, I am afraid it is the reality. LDP is inherently unable > >to > > >SD:do load ballancing, that is why this kludge is there. > > > >Shahram, > > > >What are we comparing this against? IP? Please explain how in the IP world > >one > >achieved IP vs non-IP load balancing and how it is different when you run > >LDP? > > > well, for example, take a topology below: > > R2 > / \ > R1 R3 -- R5 -- R6 > \ / > R4 > > assume the IGP cost is the same for all the links above. In the > "native" IP mode, traffic from R6 to R1, they will be(normally) > load shared using the links to both R2 and R4, R3 is the router > performs this ECMP loadsharing(IP flow based usually). > > now, if R1 through R6 are running LDP, please tell me how does > R3 perform the same flow based ECMP loadsharing(without looking > into the IP packets)? you can't. however there is, of course, nothing to stop you looking into the IP packets (using the "first nibble hack".) What you *do* get with LDP is the ability to load-balance *without* looking into the IP packets. For example for traffic flowing from R1 to R3, R5, R6 it would be possible to hash this across the links to R2 and R4 just by looking at the LDP-assigned label. In addition if you are doing L2 over MPLS then you can hash different L2 tunnels over the different links by "walking the stack". Similar techniques are possible for RFC2547. With IP you wouldn't have either of these options (both are technically possible but are AFAIK unimplemented today...) Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Jul 1 06:40:12 2002 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 ESMTP id GAA22727 for ; Mon, 1 Jul 2002 06:40:12 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpq25444 for ; Mon, 1 Jul 2002 10:40:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvpq23311; Mon, 1 Jul 2002 10:40:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvpq03085 for mpls-outgoing; Mon, 1 Jul 2002 10:39:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvpq03073 for ; Mon, 1 Jul 2002 10:39: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 QQmvpq22025 for ; Mon, 1 Jul 2002 10:39:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpq22723 for ; Mon, 1 Jul 2002 10:39:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvpq22715 for ; Mon, 1 Jul 2002 10:39:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA28490 for ; Mon, 1 Jul 2002 06:39:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA06624 for mpls@uu.net; Mon, 1 Jul 2002 06:39:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvpq03032 for ; Mon, 1 Jul 2002 10:38: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 QQmvpq16211 for ; Mon, 1 Jul 2002 10:37:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpq29594 for ; Mon, 1 Jul 2002 10:37: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 QQmvpq29588 for ; Mon, 1 Jul 2002 10:37: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 GAA21635; Mon, 1 Jul 2002 06:36:14 -0400 (EDT) Message-Id: <200207011036.GAA21635@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-jensen-mpls-interop-00.txt Date: Mon, 01 Jul 2002 06:36:14 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : General Summary of Interoperability Testing Results and Experiences Author(s) : B. Jensen et al. Filename : draft-jensen-mpls-interop-00.txt Pages : 8 Date : 28-Jun-02 This document describes certain issues observed during a recent large MPLS Interoperability Test Event conducted by the Interoperability Work Group of the MPLS Forum. The aim of this document is to make the vendor and service provider community aware of these issues. Certain recommendations have also been provided in the document in the expectation that a discussion will ensue to get these issues resolved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jensen-mpls-interop-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-jensen-mpls-interop-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-jensen-mpls-interop-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: <20020628142136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jensen-mpls-interop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jensen-mpls-interop-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142136.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jul 1 06:41:45 2002 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 ESMTP id GAA22987 for ; Mon, 1 Jul 2002 06:41:45 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpq06687 for ; Mon, 1 Jul 2002 10:42:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvpq01274; Mon, 1 Jul 2002 10:40:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvpq03090 for mpls-outgoing; Mon, 1 Jul 2002 10:39:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvpq03074 for ; Mon, 1 Jul 2002 10:39: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 QQmvpq22010 for ; Mon, 1 Jul 2002 10:39:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpq22722 for ; Mon, 1 Jul 2002 10:39:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvpq22714 for ; Mon, 1 Jul 2002 10:39:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA28486 for ; Mon, 1 Jul 2002 06:39:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA06620 for mpls@uu.net; Mon, 1 Jul 2002 06:39:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvpq03028 for ; Mon, 1 Jul 2002 10:38: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 QQmvpq12471 for ; Mon, 1 Jul 2002 10:36:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpq29561 for ; Mon, 1 Jul 2002 10:36:58 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 QQmvpq29557 for ; Mon, 1 Jul 2002 10:36:58 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21619; Mon, 1 Jul 2002 06:36:10 -0400 (EDT) Message-Id: <200207011036.GAA21619@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-iwata-mpls-crankback-04.txt Date: Mon, 01 Jul 2002 06:36:10 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Routing Extensions for MPLS Signaling Author(s) : A. Iwata, N. Fujita, G. Ash, A. Farrel, S. Marshall-Unitt Filename : draft-iwata-mpls-crankback-04.txt Pages : 32 Date : 28-Jun-02 This draft proposes crankback routing extensions for CR- LDP signaling and for RSVP-TE signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that LSP setup requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR- LDP and RSVP-TE so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-iwata-mpls-crankback-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-iwata-mpls-crankback-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020628142125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iwata-mpls-crankback-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-iwata-mpls-crankback-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142125.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jul 1 08:20:18 2002 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 ESMTP id IAA00263 for ; Mon, 1 Jul 2002 08:20:18 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpx10418 for ; Mon, 1 Jul 2002 12:21:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvpx08082; Mon, 1 Jul 2002 12:19:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvpx25228 for mpls-outgoing; Mon, 1 Jul 2002 12:19:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvpx25216 for ; Mon, 1 Jul 2002 12:19:22 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 QQmvpx15482 for ; Mon, 1 Jul 2002 12:18:59 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpx07625 for ; Mon, 1 Jul 2002 12:18:59 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQmvpx07617 for ; Mon, 1 Jul 2002 12:18: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 OAA24566; Mon, 1 Jul 2002 14:18:42 +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 OAA06496; Mon, 1 Jul 2002 14:18:55 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 14:18:19 +0200 Message-ID: From: Hummel Heinrich To: "'Ajay Simha'" , Shahram Davari Cc: "'Eric Osborne '" , "'George Sheng '" , "'scullptor@yahoo.com '" , "'mpls@UU.NET '" Subject: AW: your mail Date: Mon, 1 Jul 2002 14:17:52 +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 IAA00263 Hi all, IMHO, neither current LDP nor current IP is capable to do loadbalancing. Therefore, why don't we specify MPLS protocols which can establish QoS/Policy/Bandwidth-sensitive mp2p LSPs and why don't we open a new IP routing WG which enables QoS/Policy/Bandwidth-sensitive IP forwarding ? Heinrich -----Ursprüngliche Nachricht----- Von: Ajay Simha [mailto:asimha@cisco.com] Gesendet: Sonntag, 30. Juni 2002 12:42 An: Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: RE: your mail On Sat, 29 Jun 2002, Shahram Davari wrote: >SD: Silly or not, I am afraid it is the reality. LDP is inherently unable to >SD:do load ballancing, that is why this kludge is there. Shahram, What are we comparing this against? IP? Please explain how in the IP world one achieved IP vs non-IP load balancing and how it is different when you run LDP? -ajay >SD: >SD:-Shahram >SD: >SD:-----Original Message----- >SD:From: Eric Osborne >SD:To: Shahram Davari >SD:Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET >SD:Sent: 6/27/02 7:11 PM >SD:Subject: Re: your mail >SD: >SD:On Thu, Jun 27, 2002 at 01:02:53PM -0700, Shahram Davari wrote: >SD:> > ECMP is inherent in the architecture. >SD:> >SD:> What? ECMP is a kludge to overcome LDP's inability to TE. >SD: >SD:That seems to be an Extremely Silly statement; if you want TE, use >SD:RSVP. RFC3209, in case you've missed it...:) >SD: >SD: >SD: >SD:eric >SD: >SD:> If you think about it doing hashing of multiple labels and perhaps >SD:> IP header in the middle of an LSP actually defeats the purpose of >SD:> MPLS, which was supposed to be have a simple label lookup in the >SD:> core. >SD: >SD:> -Shahram >SD:> >SD: From owner-mpls@UU.NET Mon Jul 1 08:35:02 2002 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 ESMTP id IAA00973 for ; Mon, 1 Jul 2002 08:35:02 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpy03503 for ; Mon, 1 Jul 2002 12:35:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvpy26363; Mon, 1 Jul 2002 12:32:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvpy26339 for mpls-outgoing; Mon, 1 Jul 2002 12:32:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvpy26334 for ; Mon, 1 Jul 2002 12:32: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 QQmvpy12066 for ; Mon, 1 Jul 2002 12:32:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpy25882 for ; Mon, 1 Jul 2002 12:32:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvpy25875 for ; Mon, 1 Jul 2002 12:32:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA02218 for ; Mon, 1 Jul 2002 08:32:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA19482 for mpls@uu.net; Mon, 1 Jul 2002 08:32:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvpq03072 for ; Mon, 1 Jul 2002 10:39:29 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 QQmvpq22167 for ; Mon, 1 Jul 2002 10:39:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpq00615 for ; Mon, 1 Jul 2002 10:39:05 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 QQmvpq00611 for ; Mon, 1 Jul 2002 10:39:05 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22232; Mon, 1 Jul 2002 06:38:17 -0400 (EDT) Message-Id: <200207011038.GAA22232@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-recovery-frmwrk-05.txt Date: Mon, 01 Jul 2002 06:38: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 : Framework for MPLS-based Recovery Author(s) : V. Sharma, F. Hellstrand Filename : draft-ietf-mpls-recovery-frmwrk-05.txt Pages : 31 Date : 28-Jun-02 Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switched routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling, support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-recovery-frmwrk-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020628142705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-recovery-frmwrk-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142705.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jul 1 08:50:41 2002 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 ESMTP id IAA01911 for ; Mon, 1 Jul 2002 08:50:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpz05448 for ; Mon, 1 Jul 2002 12:51:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvpz03395; Mon, 1 Jul 2002 12:50:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvpz28119 for mpls-outgoing; Mon, 1 Jul 2002 12:49:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvpz28113 for ; Mon, 1 Jul 2002 12:49:48 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 QQmvpz13854 for ; Mon, 1 Jul 2002 12:48:23 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvpz26657 for ; Mon, 1 Jul 2002 12:48:22 GMT Received: from gorilla.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQmvpz26644 for ; Mon, 1 Jul 2002 12:48:22 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA08098; Mon, 1 Jul 2002 14:48:20 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA01593; Mon, 1 Jul 2002 14:48:20 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 14:47:49 +0200 Message-ID: From: Hummel Heinrich To: "'Naidu, Venkata'" , "'neil.2.harrison@bt.com'" Cc: mpls@UU.NET Subject: AW: your mail Date: Mon, 1 Jul 2002 14:47:46 +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 1) Venkata wrote to Neil: As I said before, whether to do load balancing or not is _not_ an interoperability issue. It's the best interest of any vendor. No *specification* required - *requirements* may be sufficient. I completely disagree. It takes a lot of common specification to enable load balancing capable IP routing. Honestly, I believe it would take a new working group to do that. 2) Can anybody explain to me why Equal-Cost Multipath and why not simply Multipath ? For traffic balancing you may need alternatively routed pathes (MPLS-pathes, IP-pathes) which arent necessarily of equal cost, right ? Heinrich Hummel Siemens From owner-mpls@UU.NET Mon Jul 1 10:04:01 2002 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 ESMTP id KAA06558 for ; Mon, 1 Jul 2002 10:04:01 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvqe14483 for ; Mon, 1 Jul 2002 14:04:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvqe11450; Mon, 1 Jul 2002 14:02:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvqe06261 for mpls-outgoing; Mon, 1 Jul 2002 14:02:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvqe06155 for ; Mon, 1 Jul 2002 14:02: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 QQmvqe23455 for ; Mon, 1 Jul 2002 14:02:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvqe10946 for ; Mon, 1 Jul 2002 14:02:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvqe10942 for ; Mon, 1 Jul 2002 14:02:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA07011 for ; Mon, 1 Jul 2002 10:02:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA29255 for mpls@uu.net; Mon, 1 Jul 2002 10:02:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvqe29876 for ; Mon, 1 Jul 2002 14:00: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 QQmvqd12085 for ; Mon, 1 Jul 2002 13:57:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvqd08730 for ; Mon, 1 Jul 2002 13:57:10 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvqd08710 for ; Mon, 1 Jul 2002 13:57:10 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA06694; Mon, 1 Jul 2002 09:57:09 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03299; Mon, 1 Jul 2002 09:57:09 -0400 (EDT) Date: Mon, 1 Jul 2002 09:57:09 -0400 From: Eric Osborne To: Hummel Heinrich Cc: "'Naidu, Venkata'" , "'neil.2.harrison@bt.com'" , mpls@UU.NET Subject: Re: your mail Message-ID: <20020701135709.GJ24180@eosborne-u10.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Jul 01, 2002 at 02:47:46PM +0200, Hummel Heinrich wrote: > 1) > Venkata wrote to Neil: > > As I said before, whether to do load balancing or not > is _not_ an interoperability issue. It's the best interest > of any vendor. No *specification* required - *requirements* > may be sufficient. > > I completely disagree. It takes a lot of common specification to > enable load balancing capable IP routing. Honestly, I believe it > would take a new working group to do that. OK, now I'm confused. I suspect that your definition of "load balancing" is different than mine, as I believe that both IP and LDP are capable of load-balancing. Some folks have said that LDP is not capable of such a thing, but this is the first time I've heard anyone say that IP can't do it, either. What exactly does "load balancing" mean to you? > 2) Can anybody explain to me why Equal-Cost Multipath and why not > simply Multipath ? For traffic balancing you may need alternatively > routed pathes (MPLS-pathes, IP-pathes) which arent necessarily of > equal cost, right ? With IP, you can end up with permanent loops if you don't provision equal-cost forwarding properly. That's why IP (and LDP, which I've always viewed as more of an arp-like thing under IP, in this instances) only do equal-cost balancing. TE has the advantage that it can use MPLS to assure a loop-free path from head to tail of a tunnel, so it can do more complex balancing at the headend, i.e. unequal cost placement of traffic into tunnels. At least that's how I look at it. eric > > Heinrich Hummel > > Siemens From owner-mpls@UU.NET Mon Jul 1 14:56:40 2002 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 ESMTP id OAA26027 for ; Mon, 1 Jul 2002 14:56:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvqx10594 for ; Mon, 1 Jul 2002 18:57:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvqx06701; Mon, 1 Jul 2002 18:55:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvqx09833 for mpls-outgoing; Mon, 1 Jul 2002 18:55:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvqx09820 for ; Mon, 1 Jul 2002 18:54: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 QQmvqx08836 for ; Mon, 1 Jul 2002 18:54:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvqx09638 for ; Mon, 1 Jul 2002 18:54:12 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvqx09628 for ; Mon, 1 Jul 2002 18:54:12 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA28563 for ; Mon, 1 Jul 2002 14:54:11 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA29740 for mpls@uu.net; Mon, 1 Jul 2002 14:54:11 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvqs11499 for ; Mon, 1 Jul 2002 17:37:44 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 QQmvqs00633 for ; Mon, 1 Jul 2002 17:37:27 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvqs11533 for ; Mon, 1 Jul 2002 17:37:27 GMT Received: from web21203.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web21203.mail.yahoo.com [216.136.130.22]) id QQmvqs11520 for ; Mon, 1 Jul 2002 17:37:26 GMT Message-ID: <20020701173726.91250.qmail@web21203.mail.yahoo.com> Received: from [216.140.58.174] by web21203.mail.yahoo.com via HTTP; Mon, 01 Jul 2002 10:37:26 PDT Date: Mon, 1 Jul 2002 10:37:26 -0700 (PDT) From: Richard Stephens Subject: RE: your mail To: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk wouldn't it be possible to solve the problem by having the ingress node create multiple explicit path lsp's based on it's igp ecmp information? All that should take is initiative by the vendor. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-mpls@UU.NET Mon Jul 1 15:53:41 2002 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 ESMTP id PAA29539 for ; Mon, 1 Jul 2002 15:53:41 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrb29713 for ; Mon, 1 Jul 2002 19:54:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvrb25249; Mon, 1 Jul 2002 19:52:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvrb06574 for mpls-outgoing; Mon, 1 Jul 2002 19:52:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvrb06540 for ; Mon, 1 Jul 2002 19:52:00 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 QQmvrb15132 for ; Mon, 1 Jul 2002 19:51:46 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrb12900 for ; Mon, 1 Jul 2002 19:51:45 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f78.law15.hotmail.com [64.4.23.78]) id QQmvrb12885 for ; Mon, 1 Jul 2002 19:51:45 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Jul 2002 12:51:44 -0700 Received: from 12.234.67.129 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 01 Jul 2002 19:51:44 GMT X-Originating-IP: [12.234.67.129] From: "Chetan Pinto" To: vivek_1975@ziplip.com, mpls@UU.NET Subject: Re: LDP Question Date: Mon, 01 Jul 2002 12:51:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Jul 2002 19:51:44.0564 (UTC) FILETIME=[BA33D740:01C22138] Sender: owner-mpls@UU.NET Precedence: bulk >Hi, > >In RFC3036 section 2.6.2.2 says > When operating in Downstream on Demand mode with liberal label >retention, >an LSR might choose to request label mappings for all known prefixes from >all peer LSRs. > > As per my understanding there won't be any restriction when we learn any >routes from IP and we obtain the mappings by sending Label Request for all >the learnt FEC's (FEC aggregation/without aggregation) if we find the >required >session/adjacenecy with the peer. So DoD acts as liberal in nature....... Let us try to keep the "advertisement mode" and the "retention method" separate. You can have a combination of DoD or DU with Liberal or Conservative retention. Hence, DoD cannot be liberal by itself. > > Does this mean any filtering is done for achieving conservative in DoD >or >am I missing something........ If u are using DoD on a particular interface: If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs If using Conservative retention, request labels for only those FECs which u deem the LDP peer is the next hop. This is the kind of filtering you would be talking about The filter would in fact be the "match" of "LDP peer" for "FEC next hop" chetan _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-mpls@UU.NET Mon Jul 1 16:44:51 2002 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 ESMTP id QAA02185 for ; Mon, 1 Jul 2002 16:44:51 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrd17877 for ; Mon, 1 Jul 2002 20:20:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvrd12611; Mon, 1 Jul 2002 20:18:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvrd01841 for mpls-outgoing; Mon, 1 Jul 2002 20:18:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvrd01836 for ; Mon, 1 Jul 2002 20:18:04 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 QQmvrd06409 for ; Mon, 1 Jul 2002 20:15:35 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrd10628 for ; Mon, 1 Jul 2002 20:15:34 GMT Received: from xover.netplane.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cnxt10002.conexant.com [198.62.10.2]) id QQmvrd10612 for ; Mon, 1 Jul 2002 20:15:34 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 16:15:32 -0400 Message-ID: <076236BAE727D611943F00508BA0F95906E7B4@XOVER.dedham.mindspeed.com> From: "Kullberg, Alan" To: "MPLS_WG (E-mail)" Subject: comments on draft-yasukawa-mpls-rsvp-multicast-00.txt Date: Mon, 1 Jul 2002 16:15:32 -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 I think that this draft has technical merit in that an IGMP Multicast protocol is not required. Also, protocols other than IP can be supported since there is no dependence on an IP multicast address as the destination. Here are some specific comments on the draft: 1. What is the expected behavior at the branch point when trying to setup more than one LSP (multiple PATH messages are sent). How long should the branch node wait for all of the returning RESVs to be received and what is the recovery mechanism if the node does not receive an RESV for all PATH messages. 2. For each type of the Notify message, when it reaches the sender node, the sender must update the TERO in the outgoing PATH message to reflect the changes in the multicast tree. This must be stated in the draft. 3. See figure 9 on page 27. The PATH message from node B to node E includes the sub-tree from node E downwards. When the PRUNE message arrives at E, E sends a PATH_TEAR downstream and a PRUNE_NOTIFY to the sender node A. If node B sends a PATH refresh message (with the old TERO), then E will setup the sub-tree again. But if the PRUNE_NOTIFY to node A causes A to remove the sub-tree from the TERO and send the modified PATH, and the PATH is received at B before B sends a PATH refresh to E, then no problem occurs. This is a race condition that is very likely to happen. This race condition exists for both the prune and the leave mechanisms. A similar problem could also exist for the JOIN and GRAFT mechanisms, depending upon what a node should do when a PATH with TERO is received that does not specify an already signaled sub-tree below this node. A possible solution to the prune and leave problems is to implement a D (delete) bit in the TERO sub-objects similar to that in draft-cheng-mpls-rsvp-multicast-er-00.txt, except that when the prune or leave is done, the branch point node sends some kind of NOTIFY message to the sender so that the sub-tree may be removed from the TERO. This requires a leaf node to send the LEAVE request all the way to the sender. A possible solution for the join and graft problems is to signal the join or graft by sending a modified TERO from the sender node and then having the branch point send some kind of NOTIFY message to the sender upon successful signaling of the join or graft. This requires a leaf node to send the JOIN request all the way to the sender. 4. In figure 14, at the bottom, why is a PATH message being sent from node A to node B? Is this a typo? 5. Instead of sending an ADD message for MP-to-MP, why not send a PATH message that has the 2 new objects in the ADD message? 6. On page 36, last paragraph, the TERO is included in the PATH_TEAR message, but the contents of the PATH_TEAR message was not shown to contain the TERO. 7. In figure 7, on GRAFT mechanism, does GRAFT mechanism require that node E was already a branch point? I think yes, otherwise data won't be sent from node B to the node E sub-tree until sender node A updates the TERO and B sends a PATH to E and E sends a RESV to B. 8. Can a node be both a leaf and a branch? If yes, how does a node know that it is both? Alan From owner-mpls@UU.NET Mon Jul 1 16:49:23 2002 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 ESMTP id QAA02325 for ; Mon, 1 Jul 2002 16:49:22 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrf14961 for ; Mon, 1 Jul 2002 20:49:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvrf11752; Mon, 1 Jul 2002 20:47:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvrf06191 for mpls-outgoing; Mon, 1 Jul 2002 20:47:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvrf06184 for ; Mon, 1 Jul 2002 20:47:25 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 QQmvrf14448 for ; Mon, 1 Jul 2002 20:47:00 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrf02467 for ; Mon, 1 Jul 2002 20:46:59 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 QQmvrf02463 for ; Mon, 1 Jul 2002 20:46: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 QAA02801 for ; Mon, 1 Jul 2002 16:46:57 -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 QAA19622 for ; Mon, 1 Jul 2002 16:46:58 -0400 (EDT) Message-ID: <3D20BFC7.8000007@marconi.com> Date: Mon, 01 Jul 2002 16:47:03 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: I-D ACTION:draft-yasukawa-mpls-rsvp-multicast-00.txt References: <200206271038.GAA08972@ietf.org> <4.3.2-J.20020701130120.00bc8c58@imc.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Seisho Yasukawa wrote: > > I agree that classical RSVP was designed around multicast and existing RSVP-TE can > cope with multicast in essesntial. But I still think existing RSVP-TE is not suitable and > some modifications are necessary to support multicast because its lack > of TE function. You mean the lack of explicit routes. TE is a very broad and vague term. If you think you need to define a multicast ERO, you can do that without changing the rest of the protocol. > As mentioned above, I agree with your assumption to RSVP-TE basically. > But please note that our draft describe some modification and extensions > to existing RSVP-TE in order to cope with > not only multicast application but also p-to-mp application. point-to-multipoint is simply a subset of IP multicast, where there is only one sender. > We think some modification is necessary to SESSION object definition > when considering multicast session. > > We think it is important to define multicast LSP tunnel independent to its accomodated traffic. > In this design, intermediate node along the LSP must not conscious of its accomodated traffic protocol. > And we want a p-to-mp LSP to accomodate both multiple IP multicast group traffic and non-IP traffic, > such as Ether traffic. Transit nodes never have to know anything about the data-plane payload. In unicast scenarios, there is nothing requiring the traffic to be IP. As a matter of fact, there are two different explicit mechanisms for non-IP traffic. One is to specify the Ethertype for the payload in the LABEL_REQUEST object, and the other is to signal an IP LSP, and use an extra label on the stack to identify the protocol (the Martini draft). Yes, you need to specify an IP address for the tunnel endpoint, but you need to do that for unicast LSPs as well. Note also that you will need _some_ mechanism for defining the endpoints of a multicast LSP. If you don't define an IP multicast group and have your egress routers all join that group, then you'll have to re-invent the wheel by replicating what existing multicast routing protocols already do. Multicast is difficult enough with established protocols (IGMP, DVMRP, PIM-DM and PIM-SM). Inventing yet another routing protocol, and making it part of RSVP (which is already enormously complex) is something I would want to avoid at all costs. > To enable the identification and association of such multicast LSP tunnels, new MULTICAST_LSP_TUNNEL > session objects are defined in our proposal. Each session object carries the sender node address of a p-to-mp LSP > and its tunnel ID. The sender node address is more preferable than destination (leaf) node addresses to identify > a multicast LSP tunnel because frequent topological changes may occur and destination node addresses are not > stable in this tunnel. Tunnel ID is not a globally unique value. And note that you are forcing your multicast to be only p-to-mp. You are not permitting IP multicast (wich is mp-to-mp) to be used. Which means you end up with less funcationality than there was before. As for topology changes, that's why the concept of a multicast group was invented in the first place. It's a way to uniquely identify the entire set of senders, receivers, and links. By eliminating it, you now have to replace it with something else that does the same thing or you make your new protocol needlessly complicated. > Therefore, the SENDER_TEMPLATE (or FILTER_SPEC) object together with > this SESSION object uniquely identify a multicast LSP tunnel. To identify the leaf and topology of this > multicast LSP tunnel, TREE_EXPLICIT_ROUTE object and TREE_RECORD_ROUTE object are also defined. All of the work necessary to define and maintain your topology is already defined for all of the major multicast routing protocols. There is no need to redefine it in yet another protocol. > And we think it is not enough to combine existing multicast routing > protocol and RSVP-TE to enable mulitcast traffic engineering. > We think what existing multicast routing protocol do for > traffic-engineering is completely weak. > > For example, PIM-SM that is most widely used multicast protocol, I > think, has three phases to establish muticast tree. > Phase 1: Encapsulation transmission to Randezvous Point (RP) + RP > Multicast Tree distribution > Phase 2: Register Stop Process which switch over to (S,G) transmission > from RP encapsulation transmission > Phase 3: Shortest Path multicast distribution (switch over from RP > transmission) > This mechanism allows very frequent topological change into tree topology. > > Therefore we think it is not realistic to make multicast LSP > synchronized with L3 multicast routing protocol. > We can not control multicast traffic completely in this design. > Moreover, path-protection mechanism or rerouting mechanism are not > supported in this design. There's no big deal if you want to define your own private multicast groups, for the purpose of establishing TE across your own routing core. Once the multicast LSPs are in place, you can then transit any traffic you want across it. Remember, you're not interested in setting up LSPs that run from a server to all of the millions of hosts receiving from that server. You're interested in setting up LSPs to efficiently transit multicast traffic to the edges of your network. This is especially true if you're talking about non-IP traffic. This is no different from how TE is being used in the unicast case. People are creating LSPs that connect from one edge of their network to the other edge. The addresses used here do not have to be global addresses, since the LSP never leaves the private address space. Similarly, your choice of multicast group addresses don't have to be global addresses, since your group won't ever extend beyond your own network. > As you mentioned above, it is better to construct multicast LSP automatically. > We can use TERO for this purpose. Some multicast tree calculation mechanism that is implemented in Network > Mangement Sytem or Sender node calculate TERO that represents suitable multicast tree and invoke this multicast > MPLS protocol to setup multicast LSP tunnel. > > And as mentioned in our draft, our scheme also target to support > multicast LSP setup using multicast routing table information. > > We are sevice provider and strongly need this p-to-mp LSP setup > mechanism to enable Contents delivery service and p-to-mp L2/MPLS service. I still think you can accomplish all of your goals using an existing multicast routing protocol and an unmodified RSVP-TE protocol. -- David From owner-mpls@UU.NET Mon Jul 1 17:26:50 2002 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 ESMTP id RAA04512 for ; Mon, 1 Jul 2002 17:26:50 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrh19451 for ; Mon, 1 Jul 2002 21:27:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvrh17084; Mon, 1 Jul 2002 21:26:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvrh01194 for mpls-outgoing; Mon, 1 Jul 2002 21:26:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvrh01163 for ; Mon, 1 Jul 2002 21:25:59 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 QQmvrh14454 for ; Mon, 1 Jul 2002 21:25:49 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrh16533 for ; Mon, 1 Jul 2002 21:25:48 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmvrh16529 for ; Mon, 1 Jul 2002 21:25:48 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 17:25:44 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022670F5@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Chetan Pinto'" Cc: vivek_1975@ziplip.com, mpls@UU.NET Subject: RE: LDP Question Date: Mon, 1 Jul 2002 17:25:44 -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 Chetan, You are quite correct in saying that advertisement and retention modes are not strictly tied to each other. However, for reasons relating to the amount of overhead associated with the combination of liberal retention and DoD - or conservative retention and DU advertisement - it may be the case that implementations are optimized for the combination of DU and liberal retention or DoD and conservative retention for practical reasons. Ideally, implementations will share this practical perspective making it unnecessary to have to deal with a peer that negotiates an impractical combination of modes. Eric W. Gray egray@celoxnetworks.com -----Original Message----- From: Chetan Pinto [mailto:chetanpinto@hotmail.com] Sent: Monday, July 01, 2002 3:52 PM To: vivek_1975@ziplip.com; mpls@UU.NET Subject: Re: LDP Question >Hi, > >In RFC3036 section 2.6.2.2 says > When operating in Downstream on Demand mode with liberal label >retention, >an LSR might choose to request label mappings for all known prefixes from >all peer LSRs. > > As per my understanding there won't be any restriction when we learn any >routes from IP and we obtain the mappings by sending Label Request for all >the learnt FEC's (FEC aggregation/without aggregation) if we find the >required >session/adjacenecy with the peer. So DoD acts as liberal in nature....... Let us try to keep the "advertisement mode" and the "retention method" separate. You can have a combination of DoD or DU with Liberal or Conservative retention. Hence, DoD cannot be liberal by itself. > > Does this mean any filtering is done for achieving conservative in DoD >or >am I missing something........ If u are using DoD on a particular interface: If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs If using Conservative retention, request labels for only those FECs which u deem the LDP peer is the next hop. This is the kind of filtering you would be talking about The filter would in fact be the "match" of "LDP peer" for "FEC next hop" chetan _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-mpls@UU.NET Mon Jul 1 17:28:58 2002 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 ESMTP id RAA04697 for ; Mon, 1 Jul 2002 17:28:58 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrh02358 for ; Mon, 1 Jul 2002 21:29:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvrh00118; Mon, 1 Jul 2002 21:28:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvrh01315 for mpls-outgoing; Mon, 1 Jul 2002 21:28:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvrh01297 for ; Mon, 1 Jul 2002 21:27: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 QQmvrh11492 for ; Mon, 1 Jul 2002 21:27:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrh29321 for ; Mon, 1 Jul 2002 21:27:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvrh29317 for ; Mon, 1 Jul 2002 21:27:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA09502 for ; Mon, 1 Jul 2002 17:27:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA16661 for mpls@uu.net; Mon, 1 Jul 2002 17:27:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvrh01199 for ; Mon, 1 Jul 2002 21:26: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 QQmvrh28628 for ; Mon, 1 Jul 2002 21:24:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrh28343 for ; Mon, 1 Jul 2002 21:24:19 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvrh28339 for ; Mon, 1 Jul 2002 21:24:19 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA09311; Mon, 1 Jul 2002 17:24:19 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA04108; Mon, 1 Jul 2002 17:24:19 -0400 (EDT) Date: Mon, 1 Jul 2002 17:24:19 -0400 From: Eric Osborne To: Richard Stephens Cc: mpls@UU.NET Subject: Re: your mail Message-ID: <20020701212418.GA4101@eosborne-u10.cisco.com> References: <20020701173726.91250.qmail@web21203.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020701173726.91250.qmail@web21203.mail.yahoo.com> User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Jul 01, 2002 at 10:37:26AM -0700, Richard Stephens wrote: > wouldn't it be possible to solve the problem by having > the ingress node create multiple explicit path lsp's > based on it's igp ecmp information? All that should > take is initiative by the vendor. What does that buy you that LDP+IGP doesn't? traffic ends up taking the same path, and you have the advantage of p2mp at each hop. eric > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com From owner-mpls@UU.NET Mon Jul 1 18:00:52 2002 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 ESMTP id SAA06304 for ; Mon, 1 Jul 2002 18:00:52 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrk23847 for ; Mon, 1 Jul 2002 22:01:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvrj16388; Mon, 1 Jul 2002 21:58:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvrj03881 for mpls-outgoing; Mon, 1 Jul 2002 21:58:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvrj03855 for ; Mon, 1 Jul 2002 21:57: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 QQmvrj21614 for ; Mon, 1 Jul 2002 21:56:33 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvrj19269 for ; Mon, 1 Jul 2002 21:56:32 GMT Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQmvrj19262 for ; Mon, 1 Jul 2002 21:56:32 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA01441 for ; Mon, 1 Jul 2002 17:54:37 -0400 (EDT) Subject: rsvp bw request To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Mon, 1 Jul 2002 17:54:37 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 07/01/2002 05:54:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I asked the bandwidth request from the Path msg before. Now my question is how to request 100% bw from the configured bw(for ex. 50k) from the path msg(Tspec---TBS, PDR). Thanks Julia From owner-mpls@UU.NET Mon Jul 1 22:17:09 2002 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 ESMTP id WAA13687 for ; Mon, 1 Jul 2002 22:17:09 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsb16091 for ; Tue, 2 Jul 2002 02:17:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvsb13390; Tue, 2 Jul 2002 02:16:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvsb07319 for mpls-outgoing; Tue, 2 Jul 2002 02:15:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvsb07314 for ; Tue, 2 Jul 2002 02:15: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 QQmvsb24256 for ; Tue, 2 Jul 2002 02:15:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsb12933 for ; Tue, 2 Jul 2002 02:15:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvsb12929 for ; Tue, 2 Jul 2002 02:15:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA22377 for ; Mon, 1 Jul 2002 22:15:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA15510 for mpls@uu.net; Mon, 1 Jul 2002 22:15:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvsa06988 for ; Tue, 2 Jul 2002 02:13: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 QQmvsa18845 for ; Tue, 2 Jul 2002 02:13:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsa02376 for ; Tue, 2 Jul 2002 02:13:06 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 QQmvsa02372 for ; Tue, 2 Jul 2002 02:13:05 GMT Received: (qmail 2002 invoked by uid 104); 2 Jul 2002 02:13:05 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4209. . Clean. Processed in 0.44188 secs); 02 Jul 2002 02:13:05 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 2 Jul 2002 02:13:04 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g622D0c03457; Mon, 1 Jul 2002 19:13:00 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 19:13:02 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03725@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" , Eric Osborne Cc: George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: RE: your mail Date: Mon, 1 Jul 2002 19:12:58 -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 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, June 28, 2002 11:10 AM > To: Eric Osborne > Cc: Shahram Davari; George Sheng; scullptor@yahoo.com; mpls@UU.NET > Subject: Re: your mail > > > > Shahram> ECMP is a kludge to overcome LDP's inability to TE. > > EricO> That seems to be an Extremely Silly statement > > Yes, indeed. That's a bit like saying that dynamic routing > is a kludge to > overcome IP's inability to set up end-to-end circuits for > individual flows. I don't think this is a good analogy. > > The ability to do load balancing without creating extra > states is generally > construed as a good thing, Sure, but LDP ECMP requires hashing states to be created in the LSRs. but I guess not by the "CO > networking rules" > crowd. Next we'll be hearing that equal cost load > balancing couldn't > possibly work; violates some ITU architecture, no doubt. ; > > > > From owner-mpls@UU.NET Mon Jul 1 22:37:25 2002 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 ESMTP id WAA14349 for ; Mon, 1 Jul 2002 22:37:24 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsc02887 for ; Tue, 2 Jul 2002 02:38:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvsc29665; Tue, 2 Jul 2002 02:36:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvsc08953 for mpls-outgoing; Tue, 2 Jul 2002 02:35:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvsc08948 for ; Tue, 2 Jul 2002 02:35: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 QQmvsc22092 for ; Tue, 2 Jul 2002 02:34:02 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsc28916 for ; Tue, 2 Jul 2002 02:34:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvsc28912 for ; Tue, 2 Jul 2002 02:34:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA23041 for ; Mon, 1 Jul 2002 22:34:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA18862 for mpls@uu.net; Mon, 1 Jul 2002 22:34:01 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvsc08876 for ; Tue, 2 Jul 2002 02:33: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 QQmvsc17076 for ; Tue, 2 Jul 2002 02:32:18 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsc28371 for ; Tue, 2 Jul 2002 02:32:17 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvsc28365 for ; Tue, 2 Jul 2002 02:32:17 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA22947; Mon, 1 Jul 2002 22:32:13 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA04461; Mon, 1 Jul 2002 22:32:13 -0400 (EDT) Date: Mon, 1 Jul 2002 22:32:13 -0400 From: Eric Osborne To: Shahram Davari Cc: "'erosen@cisco.com'" , Eric Osborne , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: Re: your mail Message-ID: <20020702023212.GD4101@eosborne-u10.cisco.com> References: <4B6D09F3B826D411A67300D0B706EFDEB03725@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03725@nt-exch-yow.pmc-sierra.bc.ca> User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Jul 01, 2002 at 07:12:58PM -0700, Shahram Davari wrote: > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Friday, June 28, 2002 11:10 AM > > To: Eric Osborne > > Cc: Shahram Davari; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > Subject: Re: your mail > > > > > > > > Shahram> ECMP is a kludge to overcome LDP's inability to TE. > > > > EricO> That seems to be an Extremely Silly statement > > > > Yes, indeed. That's a bit like saying that dynamic routing > > is a kludge to > > overcome IP's inability to set up end-to-end circuits for > > individual flows. > > I don't think this is a good analogy. > Why not? Given that LDP (not CR-LDP) simply follows the IGP routing, shouldn't you have said something like "...to overcome {ISIS|OSPF}'s ability to TE..."? At the very least, that's spitting into the wind; what we have with IP now has made a lot of people happy for a very long time. > > > > The ability to do load balancing without creating extra > > states is generally > > construed as a good thing, > > Sure, but LDP ECMP requires hashing states to be created in the LSRs. > Not sure what "hash states" are, but at least in one implementation I'm familiar with, there's no state kept for any sort of load balancing, be it IP ECMP, MPLS ECMP, or MPLS unequal-cost balancing. No per-flow state, no per-packet state, nothing. It's true that the forwarding path involves a hash lookup during forwarding to a load-balanced prefix, but to inherently declare that unacceptable doesn't seem right. And for what it's worth, the same forwarding implementation handles MPLS-TE loadsharing as well, which I think we've agreed so far is pretty useful. Maybe you and I are just on different planes. In simple words, so folks like me who actually deploy the stuff can understand, what is the fundamental problem with LDP's load-sharing that doesn't also exist in IP, and how is this fundamental problem different from whatever it is that MPLS-TE (CR-LDP or RSVP) does? eric > > but I guess not by the "CO > > networking rules" > > crowd. Next we'll be hearing that equal cost load > > balancing couldn't > > possibly work; violates some ITU architecture, no doubt. ; > > > > > > > > > From owner-mpls@UU.NET Mon Jul 1 23:35:31 2002 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 ESMTP id XAA15491 for ; Mon, 1 Jul 2002 23:35:30 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsg08478 for ; Tue, 2 Jul 2002 03:36:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvsg05131; Tue, 2 Jul 2002 03:34:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvsg04594 for mpls-outgoing; Tue, 2 Jul 2002 03:33:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvsg04582 for ; Tue, 2 Jul 2002 03:33: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 QQmvsg25376 for ; Tue, 2 Jul 2002 03:33:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsg15551 for ; Tue, 2 Jul 2002 03:33:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvsg15546 for ; Tue, 2 Jul 2002 03:33:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA24935 for ; Mon, 1 Jul 2002 23:33:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA25717 for mpls@uu.net; Mon, 1 Jul 2002 23:33:03 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvsg04535 for ; Tue, 2 Jul 2002 03:32: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 QQmvsg12275 for ; Tue, 2 Jul 2002 03:31:49 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsg15087 for ; Tue, 2 Jul 2002 03:31:48 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 QQmvsg15083 for ; Tue, 2 Jul 2002 03:31:48 GMT Received: (qmail 11481 invoked by uid 104); 2 Jul 2002 03:31:47 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4209. . Clean. Processed in 0.495058 secs); 02 Jul 2002 03:31:47 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 2 Jul 2002 03:31:46 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g623Vfc18464; Mon, 1 Jul 2002 20:31:41 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 20:31:42 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03726@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Eric Osborne'" Cc: "'erosen@cisco.com'" , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: RE: your mail Date: Mon, 1 Jul 2002 20:31:38 -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 > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Monday, July 01, 2002 10:32 PM > To: Shahram Davari > Cc: 'erosen@cisco.com'; Eric Osborne; George Sheng; > scullptor@yahoo.com; > mpls@UU.NET > Subject: Re: your mail > > > On Mon, Jul 01, 2002 at 07:12:58PM -0700, Shahram Davari wrote: > > > -----Original Message----- > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > Sent: Friday, June 28, 2002 11:10 AM > > > To: Eric Osborne > > > Cc: Shahram Davari; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > > Subject: Re: your mail > > > > > > > > > > > > Shahram> ECMP is a kludge to overcome LDP's inability to TE. > > > > > > EricO> That seems to be an Extremely Silly statement > > > > > > Yes, indeed. That's a bit like saying that dynamic routing > > > is a kludge to > > > overcome IP's inability to set up end-to-end circuits for > > > individual flows. > > > > I don't think this is a good analogy. > > > > Why not? Given that LDP (not CR-LDP) simply follows the IGP routing, > shouldn't you have said something like "...to overcome {ISIS|OSPF}'s > ability to TE..."? At the very least, that's spitting into the wind; > what we have with IP now has made a lot of people happy for a very > long time. I don't believe dynamic routing = TE > > > > > > > The ability to do load balancing without creating extra > > > states is generally > > > construed as a good thing, > > > > Sure, but LDP ECMP requires hashing states to be created in > the LSRs. > > > > Not sure what "hash states" are, but at least in one implementation > I'm familiar with, there's no state kept for any sort of load > balancing, be it IP ECMP, MPLS ECMP, or MPLS unequal-cost balancing. > No per-flow state, no per-packet state, nothing. To do ECMP, you need to assign hashed values to egress ports. This assignment is the hash state that I said you need. > It's true that the > forwarding path involves a hash lookup during forwarding to a > load-balanced prefix, but to inherently declare that unacceptable > doesn't seem right. And for what it's worth, the same forwarding > implementation handles MPLS-TE loadsharing as well, which I think > we've agreed so far is pretty useful. Agree, but only if the top label is used for hashing. > > Maybe you and I are just on different planes. In simple words, so > folks like me who actually deploy the stuff can understand, what is > the fundamental problem with LDP's load-sharing that doesn't also > exist in IP, and how is this fundamental problem different from > whatever it is that MPLS-TE (CR-LDP or RSVP) does? > > > eric > > > > > but I guess not by the "CO > > > networking rules" > > > crowd. Next we'll be hearing that equal cost load > > > balancing couldn't > > > possibly work; violates some ITU architecture, no doubt. ; > > > > > > > > > > > > > > > From owner-mpls@UU.NET Tue Jul 2 03:11:57 2002 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 ESMTP id DAA27245 for ; Tue, 2 Jul 2002 03:11:57 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsu10089 for ; Tue, 2 Jul 2002 07:12:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvsu07985; Tue, 2 Jul 2002 07:11:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvsu19010 for mpls-outgoing; Tue, 2 Jul 2002 07:11:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvsu18946 for ; Tue, 2 Jul 2002 07:11: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 QQmvsu05908 for ; Tue, 2 Jul 2002 07:09:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsu06903 for ; Tue, 2 Jul 2002 07:09:57 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQmvsu06830 for ; Tue, 2 Jul 2002 07:09:54 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 02 Jul 2002 13:01:38 +0530 Received: from maheshks (maheshks.future.futsoft.com [10.20.6.83]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g6279Ub17869 for ; Tue, 2 Jul 2002 12:39:31 +0530 Reply-To: From: "Mahesh kumar S" To: Subject: RE: LDP Question Date: Tue, 2 Jul 2002 12:27:18 +0530 Message-Id: <000501c22195$b5108e40$5306140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <1117F7D44159934FB116E36F4ABF221B022670F5@celox-ma1-ems1.celoxnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, When you are saying that "If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs" In DOD case:- LDP queries the routing table for FECs. The routing table only has the best route. ( There can't be multiple best routes except in the case of equal cost multipath). As a result of this only one request can be sent and hence only one mapping will exist. So how does liberal come into play for DOD. Thanks, Maheshkumar -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Gray, Eric Sent: Tuesday, July 02, 2002 2:56 AM To: 'Chetan Pinto' Cc: vivek_1975@ziplip.com; mpls@uu.net Subject: RE: LDP Question Chetan, You are quite correct in saying that advertisement and retention modes are not strictly tied to each other. However, for reasons relating to the amount of overhead associated with the combination of liberal retention and DoD - or conservative retention and DU advertisement - it may be the case that implementations are optimized for the combination of DU and liberal retention or DoD and conservative retention for practical reasons. Ideally, implementations will share this practical perspective making it unnecessary to have to deal with a peer that negotiates an impractical combination of modes. Eric W. Gray egray@celoxnetworks.com -----Original Message----- From: Chetan Pinto [mailto:chetanpinto@hotmail.com] Sent: Monday, July 01, 2002 3:52 PM To: vivek_1975@ziplip.com; mpls@UU.NET Subject: Re: LDP Question >Hi, > >In RFC3036 section 2.6.2.2 says > When operating in Downstream on Demand mode with liberal label >retention, >an LSR might choose to request label mappings for all known prefixes from >all peer LSRs. > > As per my understanding there won't be any restriction when we learn any >routes from IP and we obtain the mappings by sending Label Request for all >the learnt FEC's (FEC aggregation/without aggregation) if we find the >required >session/adjacenecy with the peer. So DoD acts as liberal in nature....... Let us try to keep the "advertisement mode" and the "retention method" separate. You can have a combination of DoD or DU with Liberal or Conservative retention. Hence, DoD cannot be liberal by itself. > > Does this mean any filtering is done for achieving conservative in DoD >or >am I missing something........ If u are using DoD on a particular interface: If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs If using Conservative retention, request labels for only those FECs which u deem the LDP peer is the next hop. This is the kind of filtering you would be talking about The filter would in fact be the "match" of "LDP peer" for "FEC next hop" chetan _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue Jul 2 03:23:42 2002 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 ESMTP id DAA27400 for ; Tue, 2 Jul 2002 03:23:42 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsv21670 for ; Tue, 2 Jul 2002 07:24:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvsv18891; Tue, 2 Jul 2002 07:23:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvsv20380 for mpls-outgoing; Tue, 2 Jul 2002 07:22:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvsv20375 for ; Tue, 2 Jul 2002 07:22: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 QQmvsv22489 for ; Tue, 2 Jul 2002 07:22:34 GMT From: suchauhan@hss.hns.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsv21748 for ; Tue, 2 Jul 2002 07:22:34 GMT Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQmvsv21722 for ; Tue, 2 Jul 2002 07:22:32 GMT Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g627N7Y08014; Tue, 2 Jul 2002 12:53:07 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id g627NbV29244; Tue, 2 Jul 2002 12:53:37 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256BEA.00282C1A ; Tue, 2 Jul 2002 12:48:47 +0530 X-Lotus-FromDomain: HSS To: maheshks@future.futsoft.com cc: mpls@UU.NET Message-ID: <65256BEA.002829C4.00@sandesh.hss.hns.com> Date: Tue, 2 Jul 2002 12:51:03 +0530 Subject: RE: LDP Question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi Mahesh! You point is valid for conventional IGP protocols like RIP but other one's like OSPF with appropriate extensions for TE can support multiple paths with different cost parameters. The decision for pure IP forwarding in that case is based on suitable values for different QoS attributes maintained as part of these multipaths e.g link bandwidth, utilisation, delay etc. The same mechanism can be used by LDP in case it wants to maintain multiple LSPs to the same destinations. Ofcourse the capability to learn and retain multiple routes has to be with the IGP in use firstly for LDP to be able to use it. regards, sumit "Mahesh kumar S" on 07/02/2002 12:27:18 PM Please respond to maheshks@future.futsoft.com To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: RE: LDP Question Hi, When you are saying that "If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs" In DOD case:- LDP queries the routing table for FECs. The routing table only has the best route. ( There can't be multiple best routes except in the case of equal cost multipath). As a result of this only one request can be sent and hence only one mapping will exist. So how does liberal come into play for DOD. Thanks, Maheshkumar -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Gray, Eric Sent: Tuesday, July 02, 2002 2:56 AM To: 'Chetan Pinto' Cc: vivek_1975@ziplip.com; mpls@uu.net Subject: RE: LDP Question Chetan, You are quite correct in saying that advertisement and retention modes are not strictly tied to each other. However, for reasons relating to the amount of overhead associated with the combination of liberal retention and DoD - or conservative retention and DU advertisement - it may be the case that implementations are optimized for the combination of DU and liberal retention or DoD and conservative retention for practical reasons. Ideally, implementations will share this practical perspective making it unnecessary to have to deal with a peer that negotiates an impractical combination of modes. Eric W. Gray egray@celoxnetworks.com -----Original Message----- From: Chetan Pinto [mailto:chetanpinto@hotmail.com] Sent: Monday, July 01, 2002 3:52 PM To: vivek_1975@ziplip.com; mpls@UU.NET Subject: Re: LDP Question >Hi, > >In RFC3036 section 2.6.2.2 says > When operating in Downstream on Demand mode with liberal label >retention, >an LSR might choose to request label mappings for all known prefixes from >all peer LSRs. > > As per my understanding there won't be any restriction when we learn any >routes from IP and we obtain the mappings by sending Label Request for all >the learnt FEC's (FEC aggregation/without aggregation) if we find the >required >session/adjacenecy with the peer. So DoD acts as liberal in nature....... Let us try to keep the "advertisement mode" and the "retention method" separate. You can have a combination of DoD or DU with Liberal or Conservative retention. Hence, DoD cannot be liberal by itself. > > Does this mean any filtering is done for achieving conservative in DoD >or >am I missing something........ If u are using DoD on a particular interface: If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs If using Conservative retention, request labels for only those FECs which u deem the LDP peer is the next hop. This is the kind of filtering you would be talking about The filter would in fact be the "match" of "LDP peer" for "FEC next hop" chetan _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue Jul 2 04:14:22 2002 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 ESMTP id EAA28284 for ; Tue, 2 Jul 2002 04:14:22 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsz20150 for ; Tue, 2 Jul 2002 08:15:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvsy17651; Tue, 2 Jul 2002 08:14:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvsy15814 for mpls-outgoing; Tue, 2 Jul 2002 08:13:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvsy15809 for ; Tue, 2 Jul 2002 08:13: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 QQmvsy28254 for ; Tue, 2 Jul 2002 08:13:22 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvsy18600 for ; Tue, 2 Jul 2002 08:13:22 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmvsy18588 for ; Tue, 2 Jul 2002 08:13:21 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <3B226P7Q>; Tue, 2 Jul 2002 13:46:01 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA063692B0@HARITHA> From: "Kannan S (Networking) - CTD, Chennai." To: suchauhan@hss.hns.com Cc: mpls@UU.NET Subject: RE: LDP Question Date: Tue, 2 Jul 2002 13:45:23 +0530 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 Sumit, Even if you had different paths one for higher throughput, and another for delay sensitive traffic, how will you use it ? How will you determine the QoS attribute of a incoming packet ? AFAIK, there are two ways to identify 1. The FEC for the inlabel identifies both the destination address prefix & the QoS attribute. 2. Hack - Look at the IP header below the MPLS label header. Option 1. may not be possible with just LDP Option 2. may not be recommended. (well, there is a debate on this in another thread). Also each LSR will have to do this identification inorder to ensure that routing loops are avoided. AFAIK, eventhough the IGP is capable of identifying multiple paths based on QoS attributes , LDP may not be able to use it. ECMP may be possible. Regards, Kans. -----Original Message----- From: suchauhan@hss.hns.com [mailto:suchauhan@hss.hns.com] Sent: Tuesday, July 02, 2002 12:51 PM To: maheshks@future.futsoft.com Cc: mpls@UU.NET Subject: RE: LDP Question hi Mahesh! You point is valid for conventional IGP protocols like RIP but other one's like OSPF with appropriate extensions for TE can support multiple paths with different cost parameters. The decision for pure IP forwarding in that case is based on suitable values for different QoS attributes maintained as part of these multipaths e.g link bandwidth, utilisation, delay etc. The same mechanism can be used by LDP in case it wants to maintain multiple LSPs to the same destinations. Ofcourse the capability to learn and retain multiple routes has to be with the IGP in use firstly for LDP to be able to use it. regards, sumit "Mahesh kumar S" on 07/02/2002 12:27:18 PM Please respond to maheshks@future.futsoft.com To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: RE: LDP Question Hi, When you are saying that "If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs" In DOD case:- LDP queries the routing table for FECs. The routing table only has the best route. ( There can't be multiple best routes except in the case of equal cost multipath). As a result of this only one request can be sent and hence only one mapping will exist. So how does liberal come into play for DOD. Thanks, Maheshkumar -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Gray, Eric Sent: Tuesday, July 02, 2002 2:56 AM To: 'Chetan Pinto' Cc: vivek_1975@ziplip.com; mpls@uu.net Subject: RE: LDP Question Chetan, You are quite correct in saying that advertisement and retention modes are not strictly tied to each other. However, for reasons relating to the amount of overhead associated with the combination of liberal retention and DoD - or conservative retention and DU advertisement - it may be the case that implementations are optimized for the combination of DU and liberal retention or DoD and conservative retention for practical reasons. Ideally, implementations will share this practical perspective making it unnecessary to have to deal with a peer that negotiates an impractical combination of modes. Eric W. Gray egray@celoxnetworks.com -----Original Message----- From: Chetan Pinto [mailto:chetanpinto@hotmail.com] Sent: Monday, July 01, 2002 3:52 PM To: vivek_1975@ziplip.com; mpls@UU.NET Subject: Re: LDP Question >Hi, > >In RFC3036 section 2.6.2.2 says > When operating in Downstream on Demand mode with liberal label >retention, >an LSR might choose to request label mappings for all known prefixes from >all peer LSRs. > > As per my understanding there won't be any restriction when we learn any >routes from IP and we obtain the mappings by sending Label Request for all >the learnt FEC's (FEC aggregation/without aggregation) if we find the >required >session/adjacenecy with the peer. So DoD acts as liberal in nature....... Let us try to keep the "advertisement mode" and the "retention method" separate. You can have a combination of DoD or DU with Liberal or Conservative retention. Hence, DoD cannot be liberal by itself. > > Does this mean any filtering is done for achieving conservative in DoD >or >am I missing something........ If u are using DoD on a particular interface: If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs If using Conservative retention, request labels for only those FECs which u deem the LDP peer is the next hop. This is the kind of filtering you would be talking about The filter would in fact be the "match" of "LDP peer" for "FEC next hop" chetan _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue Jul 2 05:42:10 2002 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 ESMTP id FAA29678 for ; Tue, 2 Jul 2002 05:42:10 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvte00330 for ; Tue, 2 Jul 2002 09:42:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvte27433; Tue, 2 Jul 2002 09:41:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvte14648 for mpls-outgoing; Tue, 2 Jul 2002 09:41:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvte14556 for ; Tue, 2 Jul 2002 09:40:59 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 QQmvte20579 for ; Tue, 2 Jul 2002 09:40:42 GMT From: suchauhan@hss.hns.com Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvte00934 for ; Tue, 2 Jul 2002 09:40:42 GMT Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQmvte00927 for ; Tue, 2 Jul 2002 09:40:40 GMT Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g629fEY17879; Tue, 2 Jul 2002 15:11:14 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id g629fd709451; Tue, 2 Jul 2002 15:11:39 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256BEA.0034CE13 ; Tue, 2 Jul 2002 15:06:46 +0530 X-Lotus-FromDomain: HSS To: "Kannan S (Networking) - CTD, Chennai." cc: mpls@UU.NET Message-ID: <65256BEA.0034CD4C.00@sandesh.hss.hns.com> Date: Tue, 2 Jul 2002 15:09:06 +0530 Subject: RE: LDP Question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi Kannan! You are correct on that and i wanted to suggest the same but i guess i dint say it clear enough. The original question pertained, iI think, to the role of IGP in giving information regarding the multiple paths to teh same destination and hence I answered it assuming LDP to also mean CR-LDP. But ofcourse your points are absolutely valid in case teh question was just pertaining to LDP. cheers sumit "Kannan S (Networking) - CTD, Chennai." on 07/02/2002 01:45:23 PM To: Sumit Chauhan/HSS@HSS cc: mpls@UU.NET Subject: RE: LDP Question Sumit, Even if you had different paths one for higher throughput, and another for delay sensitive traffic, how will you use it ? How will you determine the QoS attribute of a incoming packet ? AFAIK, there are two ways to identify 1. The FEC for the inlabel identifies both the destination address prefix & the QoS attribute. 2. Hack - Look at the IP header below the MPLS label header. Option 1. may not be possible with just LDP Option 2. may not be recommended. (well, there is a debate on this in another thread). Also each LSR will have to do this identification inorder to ensure that routing loops are avoided. AFAIK, eventhough the IGP is capable of identifying multiple paths based on QoS attributes , LDP may not be able to use it. ECMP may be possible. Regards, Kans. -----Original Message----- From: suchauhan@hss.hns.com [mailto:suchauhan@hss.hns.com] Sent: Tuesday, July 02, 2002 12:51 PM To: maheshks@future.futsoft.com Cc: mpls@UU.NET Subject: RE: LDP Question hi Mahesh! You point is valid for conventional IGP protocols like RIP but other one's like OSPF with appropriate extensions for TE can support multiple paths with different cost parameters. The decision for pure IP forwarding in that case is based on suitable values for different QoS attributes maintained as part of these multipaths e.g link bandwidth, utilisation, delay etc. The same mechanism can be used by LDP in case it wants to maintain multiple LSPs to the same destinations. Ofcourse the capability to learn and retain multiple routes has to be with the IGP in use firstly for LDP to be able to use it. regards, sumit "Mahesh kumar S" on 07/02/2002 12:27:18 PM Please respond to maheshks@future.futsoft.com To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: RE: LDP Question Hi, When you are saying that "If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs" In DOD case:- LDP queries the routing table for FECs. The routing table only has the best route. ( There can't be multiple best routes except in the case of equal cost multipath). As a result of this only one request can be sent and hence only one mapping will exist. So how does liberal come into play for DOD. Thanks, Maheshkumar -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Gray, Eric Sent: Tuesday, July 02, 2002 2:56 AM To: 'Chetan Pinto' Cc: vivek_1975@ziplip.com; mpls@uu.net Subject: RE: LDP Question Chetan, You are quite correct in saying that advertisement and retention modes are not strictly tied to each other. However, for reasons relating to the amount of overhead associated with the combination of liberal retention and DoD - or conservative retention and DU advertisement - it may be the case that implementations are optimized for the combination of DU and liberal retention or DoD and conservative retention for practical reasons. Ideally, implementations will share this practical perspective making it unnecessary to have to deal with a peer that negotiates an impractical combination of modes. Eric W. Gray egray@celoxnetworks.com -----Original Message----- From: Chetan Pinto [mailto:chetanpinto@hotmail.com] Sent: Monday, July 01, 2002 3:52 PM To: vivek_1975@ziplip.com; mpls@UU.NET Subject: Re: LDP Question >Hi, > >In RFC3036 section 2.6.2.2 says > When operating in Downstream on Demand mode with liberal label >retention, >an LSR might choose to request label mappings for all known prefixes from >all peer LSRs. > > As per my understanding there won't be any restriction when we learn any >routes from IP and we obtain the mappings by sending Label Request for all >the learnt FEC's (FEC aggregation/without aggregation) if we find the >required >session/adjacenecy with the peer. So DoD acts as liberal in nature....... Let us try to keep the "advertisement mode" and the "retention method" separate. You can have a combination of DoD or DU with Liberal or Conservative retention. Hence, DoD cannot be liberal by itself. > > Does this mean any filtering is done for achieving conservative in DoD >or >am I missing something........ If u are using DoD on a particular interface: If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs If using Conservative retention, request labels for only those FECs which u deem the LDP peer is the next hop. This is the kind of filtering you would be talking about The filter would in fact be the "match" of "LDP peer" for "FEC next hop" chetan _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue Jul 2 05:53:52 2002 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 ESMTP id FAA29851 for ; Tue, 2 Jul 2002 05:53:52 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtf08123 for ; Tue, 2 Jul 2002 09:54:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvtf05575; Tue, 2 Jul 2002 09:53:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvtf15798 for mpls-outgoing; Tue, 2 Jul 2002 09:53:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvtf15793 for ; Tue, 2 Jul 2002 09:53: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 QQmvtf14244 for ; Tue, 2 Jul 2002 09:52:10 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtf20959 for ; Tue, 2 Jul 2002 09:52:10 GMT Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmvtf20950 for ; Tue, 2 Jul 2002 09:52:09 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3DLP03G0>; Tue, 2 Jul 2002 10:52:18 +0100 Message-ID: To: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: your mail Date: Tue, 2 Jul 2002 10:51:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Eric, please see below....I think this is the answer you seek (though I suspect you may not like it). regards, Neil > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: 02 July 2002 03:32 > To: Shahram Davari > Cc: 'erosen@cisco.com'; Eric Osborne; George Sheng; > scullptor@yahoo.com; > mpls@UU.NET > Subject: Re: your mail (snipped> > Maybe you and I are just on different planes. In simple words, so > folks like me who actually deploy the stuff can understand, what is > the fundamental problem with LDP's load-sharing that doesn't also > exist in IP, and how is this fundamental problem different from > whatever it is that MPLS-TE (CR-LDP or RSVP) does? NH=> The key issue at question is this: IP (inc IPinIP) maintains the cnls paradigm for any-any connectivity. This is fine as *each/every* pkt contains absolute addressing information. Let me put this another way....each/every pkt contains a *connectivity verification function*. Here, the fundamental networking concept is a *routing domain*, and the key requirement is to ensure correct connectivity therein (as provided by absolute per pkt addressing). If you want a co paradigm......because you want stronger QoS/survivability assurances (that can be fault managed and measured, and even partitioned on a *per customer* basis when required, eg VPNs)......which uses a relative addressing mode (ie link-connection unique-only addressing like labels (MPLS), VPI/VCI (ATM) or DLCI (FR)) then only p2p trail entities make sense. Here, we need to introduce a signalling or NMS set-up/tear-down capability, and the fundamantal networking concept is the *connection* itself, and the fault/performance management of such is the critical piece. General LDP with mp2p merging network entities is neither one of these models nor the other. It uses the relative addressing transfer mode of the co paradigm with the aim of satisfying the goal of the routing domain cnls paradigm. But now LDP introduces new failure mode weaknesses that were not present in the true IP cnls model due to the relative addressing per link-connection which are not network-wide unique (unlike the case for IP where they are). Further, because of the SPF mode we have to introduce load-balancing.....so we 'break' the simple co label-forwarding idea of MPLS (because of LDP limitations); though this is not the real problem it's merely one symptom.....just like the fact we can't have QoS/survivabily isolation between VPNs with like-DS-class merging across VPNs using LDP....the real problem is what I mentioned previously. So in conclusion, only 2 network models make sense: true cnls for any-any behaviour and true p2p co where harder QoS/survivability behaviour assurances are required (though to be fair, one can still have some reasonable management capabilities with p2mp entities). LDP mp2p however is a hybrid that offers no compelling advantages (over either using IPinIP or p2p LSPs as required) and only creates problems/weaknesses from my analysis of it. I have talked to enough people now to know I/Shahram are far from alone in this view.....however, I do realise not everyone has reached this point of understanding yet. Hope that helps. regards, Neil From owner-mpls@UU.NET Tue Jul 2 06:42:01 2002 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 ESMTP id GAA02306 for ; Tue, 2 Jul 2002 06:42:01 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvti11000 for ; Tue, 2 Jul 2002 10:42:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvti01214; Tue, 2 Jul 2002 10:38:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvti11049 for mpls-outgoing; Tue, 2 Jul 2002 10:37:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvti11037 for ; Tue, 2 Jul 2002 10:37: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 QQmvti27372 for ; Tue, 2 Jul 2002 10:37:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvti20401 for ; Tue, 2 Jul 2002 10:37:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvti20378 for ; Tue, 2 Jul 2002 10:37:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA13560 for ; Tue, 2 Jul 2002 06:37:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA09467 for mpls@uu.net; Tue, 2 Jul 2002 06:37:03 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvti11000 for ; Tue, 2 Jul 2002 10:36:43 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 QQmvti23504 for ; Tue, 2 Jul 2002 10:35:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvti19664 for ; Tue, 2 Jul 2002 10:35:36 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmvti19654 for ; Tue, 2 Jul 2002 10:35:35 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01763; Tue, 2 Jul 2002 06:34:47 -0400 (EDT) Message-Id: <200207021034.GAA01763@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-fastreroute-mib-00.txt Date: Tue, 02 Jul 2002 06:34:47 -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) Traffic Engineering Management Information Base for Fast Reroute Author(s) : R. Cetin et al. Filename : draft-ietf-mpls-fastreroute-mib-00.txt Pages : 32 Date : 01-Jul-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based fast rerouting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-fastreroute-mib-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-ietf-mpls-fastreroute-mib-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: <20020701152720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-fastreroute-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-fastreroute-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701152720.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jul 2 06:43:25 2002 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 ESMTP id GAA02342 for ; Tue, 2 Jul 2002 06:43:25 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvti13962 for ; Tue, 2 Jul 2002 10:44:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvti01593; Tue, 2 Jul 2002 10:38:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvti11052 for mpls-outgoing; Tue, 2 Jul 2002 10:37:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvti11038 for ; Tue, 2 Jul 2002 10:37: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 QQmvti27366 for ; Tue, 2 Jul 2002 10:37:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvti20396 for ; Tue, 2 Jul 2002 10:37:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvti20373 for ; Tue, 2 Jul 2002 10:37:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA13558 for ; Tue, 2 Jul 2002 06:37:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA09457 for mpls@uu.net; Tue, 2 Jul 2002 06:37:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvti10816 for ; Tue, 2 Jul 2002 10:35:53 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 QQmvti16088 for ; Tue, 2 Jul 2002 10:35:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvti19625 for ; Tue, 2 Jul 2002 10:35:30 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmvti19621 for ; Tue, 2 Jul 2002 10:35:30 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01744; Tue, 2 Jul 2002 06:34:42 -0400 (EDT) Message-Id: <200207021034.GAA01744@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-mtu-extensions-00.txt Date: Tue, 02 Jul 2002 06:34:41 -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 : MTU Signalling Extensions for LDP Author(s) : B. Black, K. Kompella Filename : draft-ietf-mpls-ldp-mtu-extensions-00.txt Pages : 12 Date : 01-Jul-02 Proper functioning of RFC 1191 path MTU detection requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, LDP does not have the ability to signal the MTU for an LSP to ingress LSRs. In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent, off-line mechanisms. This document specifies extensions to the LDP label distribution protocol in support of LSP MTU signalling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mtu-extensions-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-mtu-extensions-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-ietf-mpls-ldp-mtu-extensions-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: <20020701152709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-mtu-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-mtu-extensions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701152709.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jul 2 06:43:34 2002 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 ESMTP id GAA02356 for ; Tue, 2 Jul 2002 06:43:34 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvti14378 for ; Tue, 2 Jul 2002 10:44:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvti01579; Tue, 2 Jul 2002 10:38:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvti11057 for mpls-outgoing; Tue, 2 Jul 2002 10:37:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvti11039 for ; Tue, 2 Jul 2002 10:37: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 QQmvti27383 for ; Tue, 2 Jul 2002 10:37:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvti20405 for ; Tue, 2 Jul 2002 10:37:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvti20385 for ; Tue, 2 Jul 2002 10:37:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA13566 for ; Tue, 2 Jul 2002 06:37:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA09476 for mpls@uu.net; Tue, 2 Jul 2002 06:37:03 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvti11001 for ; Tue, 2 Jul 2002 10:36: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 QQmvti23175 for ; Tue, 2 Jul 2002 10:35:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvti19614 for ; Tue, 2 Jul 2002 10:35:29 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmvti19610 for ; Tue, 2 Jul 2002 10:35:29 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01724; Tue, 2 Jul 2002 06:34:37 -0400 (EDT) Message-Id: <200207021034.GAA01724@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-lsp-hierarchy-07.txt Date: Tue, 02 Jul 2002 06:34:36 -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 : LSP Hierarchy with Generalized MPLS TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-lsp-hierarchy-07.txt Pages : 12 Date : 01-Jul-02 To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lsp-hierarchy-07.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-lsp-hierarchy-07.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: <20020701152657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-hierarchy-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701152657.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jul 2 07:50:29 2002 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 ESMTP id HAA04388 for ; Tue, 2 Jul 2002 07:50:29 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtn10712 for ; Tue, 2 Jul 2002 11:51:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvtn07605; Tue, 2 Jul 2002 11:49:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvtn09088 for mpls-outgoing; Tue, 2 Jul 2002 11:49:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvtn09081 for ; Tue, 2 Jul 2002 11:49: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 QQmvtn00180 for ; Tue, 2 Jul 2002 11:47:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtn05628 for ; Tue, 2 Jul 2002 11:47:19 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmvtn05624 for ; Tue, 2 Jul 2002 11:47:19 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 07:47:19 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022670F7@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'suchauhan@hss.hns.com'" , maheshks@future.futsoft.com Cc: mpls@UU.NET Subject: RE: LDP Question Date: Tue, 2 Jul 2002 07:47:13 -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 Sumit/Mahesh, The issue of what labels are asked for, or retained, is orthogonal to routing when liberal retention mode is in use. That's the point of liberal retention - with liberal retention, routing determines the labels that are used - not the labels that are ob(/re)tained. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com -----Original Message----- From: suchauhan@hss.hns.com [mailto:suchauhan@hss.hns.com] Sent: Tuesday, July 02, 2002 3:21 AM To: maheshks@future.futsoft.com Cc: mpls@UU.NET Subject: RE: LDP Question hi Mahesh! You point is valid for conventional IGP protocols like RIP but other one's like OSPF with appropriate extensions for TE can support multiple paths with different cost parameters. The decision for pure IP forwarding in that case is based on suitable values for different QoS attributes maintained as part of these multipaths e.g link bandwidth, utilisation, delay etc. The same mechanism can be used by LDP in case it wants to maintain multiple LSPs to the same destinations. Ofcourse the capability to learn and retain multiple routes has to be with the IGP in use firstly for LDP to be able to use it. regards, sumit "Mahesh kumar S" on 07/02/2002 12:27:18 PM Please respond to maheshks@future.futsoft.com To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: RE: LDP Question Hi, When you are saying that "If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs" In DOD case:- LDP queries the routing table for FECs. The routing table only has the best route. ( There can't be multiple best routes except in the case of equal cost multipath). As a result of this only one request can be sent and hence only one mapping will exist. So how does liberal come into play for DOD. Thanks, Maheshkumar -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Gray, Eric Sent: Tuesday, July 02, 2002 2:56 AM To: 'Chetan Pinto' Cc: vivek_1975@ziplip.com; mpls@uu.net Subject: RE: LDP Question Chetan, You are quite correct in saying that advertisement and retention modes are not strictly tied to each other. However, for reasons relating to the amount of overhead associated with the combination of liberal retention and DoD - or conservative retention and DU advertisement - it may be the case that implementations are optimized for the combination of DU and liberal retention or DoD and conservative retention for practical reasons. Ideally, implementations will share this practical perspective making it unnecessary to have to deal with a peer that negotiates an impractical combination of modes. Eric W. Gray egray@celoxnetworks.com -----Original Message----- From: Chetan Pinto [mailto:chetanpinto@hotmail.com] Sent: Monday, July 01, 2002 3:52 PM To: vivek_1975@ziplip.com; mpls@UU.NET Subject: Re: LDP Question >Hi, > >In RFC3036 section 2.6.2.2 says > When operating in Downstream on Demand mode with liberal label >retention, >an LSR might choose to request label mappings for all known prefixes from >all peer LSRs. > > As per my understanding there won't be any restriction when we learn any >routes from IP and we obtain the mappings by sending Label Request for all >the learnt FEC's (FEC aggregation/without aggregation) if we find the >required >session/adjacenecy with the peer. So DoD acts as liberal in nature....... Let us try to keep the "advertisement mode" and the "retention method" separate. You can have a combination of DoD or DU with Liberal or Conservative retention. Hence, DoD cannot be liberal by itself. > > Does this mean any filtering is done for achieving conservative in DoD >or >am I missing something........ If u are using DoD on a particular interface: If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs If using Conservative retention, request labels for only those FECs which u deem the LDP peer is the next hop. This is the kind of filtering you would be talking about The filter would in fact be the "match" of "LDP peer" for "FEC next hop" chetan _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue Jul 2 08:07:39 2002 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 ESMTP id IAA04883 for ; Tue, 2 Jul 2002 08:07:39 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvto20749 for ; Tue, 2 Jul 2002 12:07:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvto17665; Tue, 2 Jul 2002 12:06:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvto00902 for mpls-outgoing; Tue, 2 Jul 2002 12:06:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvto00742 for ; Tue, 2 Jul 2002 12:05: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 QQmvto07158 for ; Tue, 2 Jul 2002 12:05:17 GMT From: suchauhan@hss.hns.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvto11327 for ; Tue, 2 Jul 2002 12:05:16 GMT Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQmvto11310 for ; Tue, 2 Jul 2002 12:05:15 GMT Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g62C5mY28569; Tue, 2 Jul 2002 17:35:48 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id g62C6H820323; Tue, 2 Jul 2002 17:36:17 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256BEA.00420D5B ; Tue, 2 Jul 2002 17:31:27 +0530 X-Lotus-FromDomain: HSS To: "Gray, Eric" cc: maheshks@future.futsoft.com, mpls@UU.NET Message-ID: <65256BEA.00420C57.00@sandesh.hss.hns.com> Date: Tue, 2 Jul 2002 17:33:47 +0530 Subject: RE: LDP Question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi Eric! I do get your point. Just one more point here is that in such a case Liberal Mode seems to always go hand in hand with DU mode only and not DoD. I do know that this is recommended and logical as well but IMHO your philosophy will not hold if we think of Liberal Mode with DoD. regards, sumit "Gray, Eric" on 07/02/2002 05:17:13 PM To: Sumit Chauhan/HSS@HSS, maheshks@future.futsoft.com cc: mpls@UU.NET Subject: RE: LDP Question Sumit/Mahesh, The issue of what labels are asked for, or retained, is orthogonal to routing when liberal retention mode is in use. That's the point of liberal retention - with liberal retention, routing determines the labels that are used - not the labels that are ob(/re)tained. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com -----Original Message----- From: suchauhan@hss.hns.com [mailto:suchauhan@hss.hns.com] Sent: Tuesday, July 02, 2002 3:21 AM To: maheshks@future.futsoft.com Cc: mpls@UU.NET Subject: RE: LDP Question hi Mahesh! You point is valid for conventional IGP protocols like RIP but other one's like OSPF with appropriate extensions for TE can support multiple paths with different cost parameters. The decision for pure IP forwarding in that case is based on suitable values for different QoS attributes maintained as part of these multipaths e.g link bandwidth, utilisation, delay etc. The same mechanism can be used by LDP in case it wants to maintain multiple LSPs to the same destinations. Ofcourse the capability to learn and retain multiple routes has to be with the IGP in use firstly for LDP to be able to use it. regards, sumit "Mahesh kumar S" on 07/02/2002 12:27:18 PM Please respond to maheshks@future.futsoft.com To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: RE: LDP Question Hi, When you are saying that "If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs" In DOD case:- LDP queries the routing table for FECs. The routing table only has the best route. ( There can't be multiple best routes except in the case of equal cost multipath). As a result of this only one request can be sent and hence only one mapping will exist. So how does liberal come into play for DOD. Thanks, Maheshkumar -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Gray, Eric Sent: Tuesday, July 02, 2002 2:56 AM To: 'Chetan Pinto' Cc: vivek_1975@ziplip.com; mpls@uu.net Subject: RE: LDP Question Chetan, You are quite correct in saying that advertisement and retention modes are not strictly tied to each other. However, for reasons relating to the amount of overhead associated with the combination of liberal retention and DoD - or conservative retention and DU advertisement - it may be the case that implementations are optimized for the combination of DU and liberal retention or DoD and conservative retention for practical reasons. Ideally, implementations will share this practical perspective making it unnecessary to have to deal with a peer that negotiates an impractical combination of modes. Eric W. Gray egray@celoxnetworks.com -----Original Message----- From: Chetan Pinto [mailto:chetanpinto@hotmail.com] Sent: Monday, July 01, 2002 3:52 PM To: vivek_1975@ziplip.com; mpls@UU.NET Subject: Re: LDP Question >Hi, > >In RFC3036 section 2.6.2.2 says > When operating in Downstream on Demand mode with liberal label >retention, >an LSR might choose to request label mappings for all known prefixes from >all peer LSRs. > > As per my understanding there won't be any restriction when we learn any >routes from IP and we obtain the mappings by sending Label Request for all >the learnt FEC's (FEC aggregation/without aggregation) if we find the >required >session/adjacenecy with the peer. So DoD acts as liberal in nature....... Let us try to keep the "advertisement mode" and the "retention method" separate. You can have a combination of DoD or DU with Liberal or Conservative retention. Hence, DoD cannot be liberal by itself. > > Does this mean any filtering is done for achieving conservative in DoD >or >am I missing something........ If u are using DoD on a particular interface: If using liberal retention, request labels for all FECs even if the LDP peer is not a next hop for all FECs If using Conservative retention, request labels for only those FECs which u deem the LDP peer is the next hop. This is the kind of filtering you would be talking about The filter would in fact be the "match" of "LDP peer" for "FEC next hop" chetan _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue Jul 2 09:01:44 2002 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 ESMTP id JAA07197 for ; Tue, 2 Jul 2002 09:01:44 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvts11366 for ; Tue, 2 Jul 2002 13:01:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvtr07766; Tue, 2 Jul 2002 12:59:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvtr06557 for mpls-outgoing; Tue, 2 Jul 2002 12:59:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvtr06552 for ; Tue, 2 Jul 2002 12:59: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 QQmvtr17188 for ; Tue, 2 Jul 2002 12:58:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtr20593 for ; Tue, 2 Jul 2002 12:58:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvtr20585 for ; Tue, 2 Jul 2002 12:58:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA19339 for ; Tue, 2 Jul 2002 08:58:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA25889 for mpls@uu.net; Tue, 2 Jul 2002 08:58:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvtr06392 for ; Tue, 2 Jul 2002 12: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 QQmvtr25686 for ; Tue, 2 Jul 2002 12:56:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtr19992 for ; Tue, 2 Jul 2002 12:56:31 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvtr19983 for ; Tue, 2 Jul 2002 12:56:30 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA19241; Tue, 2 Jul 2002 08:56:30 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA05255; Tue, 2 Jul 2002 08:56:30 -0400 (EDT) Date: Tue, 2 Jul 2002 08:56:30 -0400 From: Eric Osborne To: Shahram Davari Cc: "'Eric Osborne'" , "'erosen@cisco.com'" , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: Re: your mail Message-ID: <20020702125629.GE4101@eosborne-u10.cisco.com> References: <4B6D09F3B826D411A67300D0B706EFDEB03726@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03726@nt-exch-yow.pmc-sierra.bc.ca> User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk > > Why not? Given that LDP (not CR-LDP) simply follows the IGP routing, > > shouldn't you have said something like "...to overcome {ISIS|OSPF}'s > > ability to TE..."? At the very least, that's spitting into the wind; > > what we have with IP now has made a lot of people happy for a very > > long time. > > I don't believe dynamic routing = TE > ok...so not that I agree with you, but if your definition of TE means "non-SPF paths" then things are starting to make sense. Certainly using SPF is pretty coarse, but I've always considered it a form of TE. To me, TE is manipulating your traffic to fit your network topology, and changing IGP metrics to steer traffic around is one way to do that. > > Not sure what "hash states" are, but at least in one implementation > > I'm familiar with, there's no state kept for any sort of load > > balancing, be it IP ECMP, MPLS ECMP, or MPLS unequal-cost balancing. > > No per-flow state, no per-packet state, nothing. > > To do ECMP, you need to assign hashed values to egress ports. This > assignment is the hash state that I said you need. > Then I guess I don't see what's inherently bad about them? So I add a hash lookup - so what? From an IP perspective, as long as I avoid out of order packets, I'm OK, and any reasonable implementation is going to keep the same conversation/flow/whatever following the same path. > > It's true that the > > forwarding path involves a hash lookup during forwarding to a > > load-balanced prefix, but to inherently declare that unacceptable > > doesn't seem right. And for what it's worth, the same forwarding > > implementation handles MPLS-TE loadsharing as well, which I think > > we've agreed so far is pretty useful. > > Agree, but only if the top label is used for hashing. > Why does it matter what value you use for hashing? What's the fundamental objection to using label stack/underlying payload? This is like saying it's OK to use only IP SA/DA for hashing, and not things like L4 ports. From my perspective, as long as a) you keep conversations in order b) you can balance traffic reasonably well then your hash function has done its job. Right? And for that matter, is it OK to use SA/DA on an IP packet for hashing? If so, why can't I use the same information (as found underneath a label stack) in an MPLS packet to do the same thing? It's not like this is *forwarding*, it's just hashing. eric From owner-mpls@UU.NET Tue Jul 2 09:15:58 2002 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 ESMTP id JAA08092 for ; Tue, 2 Jul 2002 09:15:57 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtt00680 for ; Tue, 2 Jul 2002 13:16:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvts27138; Tue, 2 Jul 2002 13:14:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvts29751 for mpls-outgoing; Tue, 2 Jul 2002 13:14:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvts29746 for ; Tue, 2 Jul 2002 13:14: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 QQmvts28666 for ; Tue, 2 Jul 2002 13:13:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvts29173 for ; Tue, 2 Jul 2002 13:13:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvts29168 for ; Tue, 2 Jul 2002 13:13:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA20167 for ; Tue, 2 Jul 2002 09:13:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA28381 for mpls@uu.net; Tue, 2 Jul 2002 09:13:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvts29495 for ; Tue, 2 Jul 2002 13:11: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 QQmvts28756 for ; Tue, 2 Jul 2002 13:11:44 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvts28672 for ; Tue, 2 Jul 2002 13:11:44 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvts28664 for ; Tue, 2 Jul 2002 13:11:43 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA20112; Tue, 2 Jul 2002 09:11:43 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05271; Tue, 2 Jul 2002 09:11:43 -0400 (EDT) Date: Tue, 2 Jul 2002 09:11:43 -0400 From: Eric Osborne To: neil.2.harrison@bt.com Cc: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: Re: your mail Message-ID: <20020702131143.GF4101@eosborne-u10.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Tue, Jul 02, 2002 at 10:51:52AM +0100, neil.2.harrison@bt.com wrote: > Eric, please see below....I think this is the answer you seek (though I > suspect you may not like it). > yeah, probably...:) see inline > regards, Neil > > > -----Original Message----- > > From: Eric Osborne [mailto:eosborne@cisco.com] > > Sent: 02 July 2002 03:32 > > To: Shahram Davari > > Cc: 'erosen@cisco.com'; Eric Osborne; George Sheng; > > scullptor@yahoo.com; > > mpls@UU.NET > > Subject: Re: your mail > (snipped> > > Maybe you and I are just on different planes. In simple words, so > > folks like me who actually deploy the stuff can understand, what is > > the fundamental problem with LDP's load-sharing that doesn't also > > exist in IP, and how is this fundamental problem different from > > whatever it is that MPLS-TE (CR-LDP or RSVP) does? > > NH=> The key issue at question is this: > > IP (inc IPinIP) maintains the cnls paradigm for any-any connectivity. This > is fine as *each/every* pkt contains absolute addressing information. Let > me put this another way....each/every pkt contains a *connectivity > verification function*. Here, the fundamental networking concept is a > *routing domain*, and the key requirement is to ensure correct connectivity > therein (as provided by absolute per pkt addressing). This is where I start to turn my head sideways as I look at my screen. I hope maybe it's just a terminology thing, so let me parse out your sentence and we'll see where I've gone wrong. "absolute addressing information", to me, sounds like "enough addressing information to get the packet to its final destination, i.e. an end station". Right? If so, wouldn't that be true for cases like IPinIP when the IP core doesn't know about addresses at the IP edge (a la gre tunnels)? Or do you mean something else? I also don't see how this turns into a "connectivity verification function". What about an IP packet (or IPinIP) inherently has more verification than IPinMPLS? And isn't this turning into an OAM discussion again, rather than talking about loadsharing? > > If you want a co paradigm......because you want stronger QoS/survivability > assurances (that can be fault managed and measured, and even partitioned on > a *per customer* basis when required, eg VPNs)......which uses a relative > addressing mode (ie link-connection unique-only addressing like labels > (MPLS), VPI/VCI (ATM) or DLCI (FR)) then only p2p trail entities > make sense. I'm not sure I buy into the argument that the co paradigm is the only way to do stuff like qos/survivability/etc. Granted, you are far more a co-paradigm guy than I am, so you know this area better, but I suspect that means you're walking around with a co-paradigm-shaped hammer, looking for a nail. Of course, the same thing could be said about my connectionless bias, so really there's no easy way out, here. I'm also not sure what you mean by "link-connection unique-only". You mean a switching identifier on a packet that's relevant to a particular link? Not true for packet-mode MPLS, as a global label space has its advantages, but I don't see how that has any bearing on traffic management. But whatever the argument, isn't the same is true for IPinIP where the outer IP address is your PE (or whatever your term is) and the inner IP is relevant to your customer, right? > Here, we need to introduce a signalling or NMS set-up/tear-down capability, > and the fundamantal networking concept is the *connection* itself, and the > fault/performance management of such is the critical piece. ah....OAM again...me and my ten-foot pole are going somewhere else now... > > General LDP with mp2p merging network entities is neither one of these > models nor the other. It uses the relative addressing transfer mode of the > co paradigm with the aim of satisfying the goal of the routing domain cnls > paradigm. But now LDP introduces new failure mode weaknesses that were not > present in the true IP cnls model due to the relative addressing per > link-connection which are not network-wide unique (unlike the case for IP > where they are). But not necessarily for IPinIP. > Further, because of the SPF mode we have to introduce > load-balancing.....so we 'break' the simple co label-forwarding idea of MPLS > (because of LDP limitations); though this is not the real problem it's > merely one symptom.....just like the fact we can't have QoS/survivabily > isolation between VPNs with like-DS-class merging across VPNs using > LDP....the real problem is what I mentioned previously. I guess I don't see how load-balancing breaks any sort of CO model, other than the fact that the CO protocols don't have loadsharing. So I see how it's different, I don't see how that makes it broken. > > So in conclusion, only 2 network models make sense: true cnls for any-any > behaviour and true p2p co where harder QoS/survivability behaviour > assurances are required (though to be fair, one can still have some > reasonable management capabilities with p2mp entities). LDP mp2p however is > a hybrid that offers no compelling advantages (over either using IPinIP or > p2p LSPs as required) and only creates problems/weaknesses from my analysis > of it. I have talked to enough people now to know I/Shahram are far from > alone in this view.....however, I do realise not everyone has reached this > point of understanding yet. I guess the fundamental piece I'm still missing is that I don't see how LDP is any different from IP at the forwarding level. At least in one implementation, given the same topology and the same set of data, the traffic pattern across the network will look the same whether the traffic the network carries is IP or IPinLDP. Given that the traffic pattern is the same whether or not LDP is used, how does that make LDP *bad*? I will agree that LDP hasn't made anything _better_ in this picture, but we already had the "why use LDP at all" discussion a few weeks ago. I'm just trying to understand the basic objection to LDP, when the forwarding looks the same as IP. And I don't mean the OAM side, but the loadsharing side; loadsharing is how we started this topic (I think), so I'd like to keep it there. thanks... eric > > Hope that helps. > > regards, Neil From owner-mpls@UU.NET Tue Jul 2 10:08:30 2002 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 ESMTP id KAA10542 for ; Tue, 2 Jul 2002 10:08:30 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtw14402 for ; Tue, 2 Jul 2002 14:08:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvtw10807; Tue, 2 Jul 2002 14:07:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvtw28156 for mpls-outgoing; Tue, 2 Jul 2002 14:06:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvtw27075 for ; Tue, 2 Jul 2002 14:06: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 QQmvtw04675 for ; Tue, 2 Jul 2002 14:06:29 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtw25557 for ; Tue, 2 Jul 2002 14:06:28 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvtw25550 for ; Tue, 2 Jul 2002 14:06:28 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA23630; Tue, 2 Jul 2002 10:06:27 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA05961; Tue, 2 Jul 2002 10:06:27 -0400 (EDT) Message-Id: <200207021406.KAA05961@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: "'Eric Osborne'" , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: Re: your mail In-reply-to: Your message of Mon, 01 Jul 2002 20:31:38 -0700. <4B6D09F3B826D411A67300D0B706EFDEB03726@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Jul 2002 10:06:27 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Shahram> To do ECMP, you need to assign hashed values to egress ports. This Shahram> assignment is the hash state that I said you need. A hash is a function that maps some sequence of octets into a sequence of integers. If you want to split traffic over six paths, while ensuring that all packets with the same bottom label travel the same path, you need a function that maps a 20 bit quantity into a number from 1-6. There is no need to maintain state of any kind. From owner-mpls@UU.NET Tue Jul 2 10:15:42 2002 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 ESMTP id KAA11036 for ; Tue, 2 Jul 2002 10:15:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtx26254 for ; Tue, 2 Jul 2002 14:16:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvtx23830; Tue, 2 Jul 2002 14:15:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvtx04401 for mpls-outgoing; Tue, 2 Jul 2002 14:15:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvtw04208 for ; Tue, 2 Jul 2002 14:14: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 QQmvtw25587 for ; Tue, 2 Jul 2002 14:14:39 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtw23349 for ; Tue, 2 Jul 2002 14:14:38 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQmvtw23344 for ; Tue, 2 Jul 2002 14:14:38 GMT Message-ID: From: Jeff Parker To: "'erosen@cisco.com'" , Shahram Davari Cc: "'Eric Osborne'" , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: RE: your mail Date: Tue, 2 Jul 2002 10:14:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > A hash is a function that maps some sequence of octets into > a sequence of integers. If you want to split traffic over > six paths, while ensuring that all packets with the same > bottom label travel the same path, you need a > function that maps a 20 bit quantity into a number from > 1-6. There is no need to maintain state of any kind. Eric - There are many functions that map your octets onto the range from 1 to 6. Based on the distribution of your octets (i.e. the flows you expect to see) you might have different functions if you tried to spread the load evenly. Wouldn't you need some state to remember which function you picked? - jeff parker - axiowave networks From owner-mpls@UU.NET Tue Jul 2 10:27:48 2002 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 ESMTP id KAA12066 for ; Tue, 2 Jul 2002 10:27:48 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtx06015 for ; Tue, 2 Jul 2002 14:28:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvtx03691; Tue, 2 Jul 2002 14:27:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvtx05657 for mpls-outgoing; Tue, 2 Jul 2002 14:27:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvtx05650 for ; Tue, 2 Jul 2002 14:26: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 QQmvtx09215 for ; Tue, 2 Jul 2002 14:26:00 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtx08937 for ; Tue, 2 Jul 2002 14:25:59 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 QQmvtx08928 for ; Tue, 2 Jul 2002 14:25:59 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA03093; Tue, 2 Jul 2002 16:25:26 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA29442; Tue, 2 Jul 2002 16:25:41 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 16:25:40 +0200 Message-ID: From: Hummel Heinrich To: "'erosen@cisco.com'" , Shahram Davari Cc: "'Eric Osborne'" , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: AW: your mail Date: Tue, 2 Jul 2002 16:25:37 +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 KAA12066 It gets weirder and weirder: The MPLS WG invents a label stack, but does not care at all that any of the deeper nested labels may ever be signalled/carried by means of a Label-TLV/object (no public comments to my Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). However it is ok, to "steal" the deepest nested label and call it "VC-label" for indexing some VRF at some remote PE. Furthermore it is ok, to "steal" the very same label for hashing. Independent from what is clean and what is quick&dirty, I cannot detect any sense in giving a hash-meaning to the bottom label at all. Heinrich Hummel Siemens -----Ursprüngliche Nachricht----- Von: Eric Rosen [mailto:erosen@cisco.com] Gesendet: Dienstag, 2. Juli 2002 16:06 An: Shahram Davari Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET Betreff: Re: your mail Shahram> To do ECMP, you need to assign hashed values to egress ports. This Shahram> assignment is the hash state that I said you need. A hash is a function that maps some sequence of octets into a sequence of integers. If you want to split traffic over six paths, while ensuring that all packets with the same bottom label travel the same path, you need a function that maps a 20 bit quantity into a number from 1-6. There is no need to maintain state of any kind. From owner-mpls@UU.NET Tue Jul 2 10:30:50 2002 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 ESMTP id KAA12248 for ; Tue, 2 Jul 2002 10:30:50 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvty15339 for ; Tue, 2 Jul 2002 14:31:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvtx11398; Tue, 2 Jul 2002 14:29:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvtx05717 for mpls-outgoing; Tue, 2 Jul 2002 14:28:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvtx05709 for ; Tue, 2 Jul 2002 14:28: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 QQmvtx20938 for ; Tue, 2 Jul 2002 14:27:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtx05660 for ; Tue, 2 Jul 2002 14:27:36 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvtx05652 for ; Tue, 2 Jul 2002 14:27:36 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA25373 for ; Tue, 2 Jul 2002 10:27:36 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA10337 for mpls@uu.net; Tue, 2 Jul 2002 10:27:36 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvtx05226 for ; Tue, 2 Jul 2002 14:22: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 QQmvtx28753 for ; Tue, 2 Jul 2002 14:20:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtx02682 for ; Tue, 2 Jul 2002 14:20:47 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmvtx02676 for ; Tue, 2 Jul 2002 14:20:46 GMT Received: (qmail 21236 invoked by uid 104); 2 Jul 2002 14:20:46 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4209. . Clean. Processed in 0.523916 secs); 02 Jul 2002 14:20:46 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 2 Jul 2002 14:20:45 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g62EKic16201; Tue, 2 Jul 2002 07:20:44 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 07:20:45 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03728@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Eric Osborne '" Cc: "''erosen@cisco.com' '" , "'George Sheng '" , "'scullptor@yahoo.com '" , "'mpls@UU.NET '" Subject: RE: your mail Date: Tue, 2 Jul 2002 07:20:42 -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 -----Original Message----- From: Eric Osborne To: Shahram Davari Cc: 'Eric Osborne'; 'erosen@cisco.com'; George Sheng; scullptor@yahoo.com; mpls@UU.NET Sent: 7/2/02 5:56 AM Subject: Re: your mail > > Why not? Given that LDP (not CR-LDP) simply follows the IGP routing, > > shouldn't you have said something like "...to overcome {ISIS|OSPF}'s > > ability to TE..."? At the very least, that's spitting into the wind; > > what we have with IP now has made a lot of people happy for a very > > long time. > > I don't believe dynamic routing = TE > ok...so not that I agree with you, but if your definition of TE means "non-SPF paths" then things are starting to make sense. Yes. Certainly using SPF is pretty coarse, but I've always considered it a form of TE. SD=> Interesting !!!! SPF ~= TE. I let others judge. To me, TE is manipulating your traffic to fit your network topology, and changing IGP metrics to steer traffic around is one way to do that. > > Not sure what "hash states" are, but at least in one implementation > > I'm familiar with, there's no state kept for any sort of load > > balancing, be it IP ECMP, MPLS ECMP, or MPLS unequal-cost balancing. > > No per-flow state, no per-packet state, nothing. > > To do ECMP, you need to assign hashed values to egress ports. This > assignment is the hash state that I said you need. > Then I guess I don't see what's inherently bad about them? SD=>This was in response to your comment that said no state is required. So I add a hash lookup - so what? SD=> So you do more than one lookup- so what? so you need to parse the whole packet in the core-so what? so you need to keep state in the core, so what? so you have no longer a simple label swap- so what? so you may hash an encripted packet-so what?..... From an IP perspective, as long as I avoid out of order packets, I'm OK, and any reasonable implementation is going to keep the same conversation/flow/whatever following the same path. > > It's true that the > > forwarding path involves a hash lookup during forwarding to a > > load-balanced prefix, but to inherently declare that unacceptable > > doesn't seem right. And for what it's worth, the same forwarding > > implementation handles MPLS-TE loadsharing as well, which I think > > we've agreed so far is pretty useful. > > Agree, but only if the top label is used for hashing. > Why does it matter what value you use for hashing? SD=> I was responding to your comment that the same technique handles MPLS-TE. What's the fundamental objection to using label stack/underlying payload? SD=> MPLS was designed to have simple forwarding. Hashing takes it to new levels of simplification never seen before. -Shahram This is like saying it's OK to use only IP SA/DA for hashing, and not things like L4 ports. From my perspective, as long as a) you keep conversations in order b) you can balance traffic reasonably well then your hash function has done its job. Right? And for that matter, is it OK to use SA/DA on an IP packet for hashing? If so, why can't I use the same information (as found underneath a label stack) in an MPLS packet to do the same thing? It's not like this is *forwarding*, it's just hashing. eric From owner-mpls@UU.NET Tue Jul 2 10:41:54 2002 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 ESMTP id KAA13360 for ; Tue, 2 Jul 2002 10:41:54 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvty17575 for ; Tue, 2 Jul 2002 14:42:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvty15646; Tue, 2 Jul 2002 14:41:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvty06982 for mpls-outgoing; Tue, 2 Jul 2002 14:41:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvty06977 for ; Tue, 2 Jul 2002 14:41: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 QQmvty00744 for ; Tue, 2 Jul 2002 14:41:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvty15285 for ; Tue, 2 Jul 2002 14:41:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvty15278 for ; Tue, 2 Jul 2002 14:41:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA26493; Tue, 2 Jul 2002 10:41:03 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA12928; Tue, 2 Jul 2002 10:41:03 -0400 (EDT) Message-Id: <200207021441.KAA12928@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Jeff Parker cc: Shahram Davari , "'Eric Osborne'" , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: Re: your mail In-reply-to: Your message of Tue, 02 Jul 2002 10:14:07 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Jul 2002 10:41:03 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Jeff> There are many functions that map your octets onto the range Jeff> from 1 to 6. Based on the distribution of your octets Jeff> (i.e. the flows you expect to see) you might have different Jeff> functions if you tried to spread the load evenly. Jeff> Wouldn't you need some state to remember which function you Jeff> picked? I think the usual implementation technique is to pick a function and compile it into the code ;-) From owner-mpls@UU.NET Tue Jul 2 10:54:48 2002 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 ESMTP id KAA15364 for ; Tue, 2 Jul 2002 10:54:48 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtz05192 for ; Tue, 2 Jul 2002 14:55:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvtz28864; Tue, 2 Jul 2002 14:52:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvtz08246 for mpls-outgoing; Tue, 2 Jul 2002 14:52:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvtz08240 for ; Tue, 2 Jul 2002 14:52: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 QQmvtz12232 for ; Tue, 2 Jul 2002 14:51:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtz00451 for ; Tue, 2 Jul 2002 14:51:36 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQmvtz00446 for ; Tue, 2 Jul 2002 14:51:36 GMT Message-ID: From: Jeff Parker To: "'erosen@cisco.com'" , Jeff Parker Cc: Shahram Davari , "'Eric Osborne'" , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: RE: your mail Date: Tue, 2 Jul 2002 10:51:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Jeff> There are many functions that map your octets onto the range > Jeff> from 1 to 6. Based on the distribution of your octets > Jeff> (i.e. the flows you expect to see) you might have different > Jeff> functions if you tried to spread the load evenly. > Jeff> Wouldn't you need some state to remember which function you > Jeff> picked? > > I think the usual implementation technique is to pick a > function and compile > it into the code ;-) Eric - There are schemes out there that compile a function into code, hash, and then use the result to pick a bucket based on ranges computed to equalize the flow. The state is reduced to N integers, but represents state all the same. Of course, if you don't care about equalizing the flow, you don't need to be so careful. - jeff parker - axiowave networks From owner-mpls@UU.NET Tue Jul 2 10:56:01 2002 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 ESMTP id KAA15558 for ; Tue, 2 Jul 2002 10:56:00 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtz07369 for ; Tue, 2 Jul 2002 14:56:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvtz27340; Tue, 2 Jul 2002 14:51:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvtz08194 for mpls-outgoing; Tue, 2 Jul 2002 14:51:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvtz08189 for ; Tue, 2 Jul 2002 14:51:36 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 QQmvtz29519 for ; Tue, 2 Jul 2002 14:50:11 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvtz26540 for ; Tue, 2 Jul 2002 14:50:10 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvtz26535 for ; Tue, 2 Jul 2002 14:50:10 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA27208; Tue, 2 Jul 2002 10:50:09 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA14330; Tue, 2 Jul 2002 10:50:09 -0400 (EDT) Message-Id: <200207021450.KAA14330@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Hummel Heinrich cc: Shahram Davari , "'Eric Osborne'" , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: Re: AW: your mail In-reply-to: Your message of Tue, 02 Jul 2002 16:25:37 +0200. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Jul 2002 10:50:09 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Heinrich> Independent from what is clean and what is quick&dirty, I cannot Heinrich> detect any sense in giving a hash-meaning to the bottom label at Heinrich> all. The only purpose of the loadbalancing hash is to reduce the likelihood of packets from the same end-to-end stream being sent on different paths, while also not requiring too many unrelated packets to be sent on the same path. Packets from the same end-to-end stream will tend to have the same bottom label, and at the bottom of the stack there hasn't been overly much aggregation. So the bottom label seems like the right thing to look at for this purpose. In both the L2VPN and L3VPN applications, this works out pretty well. From owner-mpls@UU.NET Tue Jul 2 11:02:58 2002 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 ESMTP id LAA16499 for ; Tue, 2 Jul 2002 11:02:58 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvua10823 for ; Tue, 2 Jul 2002 15:03:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvua08207; Tue, 2 Jul 2002 15:02:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvua12982 for mpls-outgoing; Tue, 2 Jul 2002 15:02:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvua12955 for ; Tue, 2 Jul 2002 15:02: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 QQmvua11149 for ; Tue, 2 Jul 2002 15:01:33 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvua15032 for ; Tue, 2 Jul 2002 15:01:32 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvua15018 for ; Tue, 2 Jul 2002 15:01:32 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA27920; Tue, 2 Jul 2002 11:01:31 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA15941; Tue, 2 Jul 2002 11:01:31 -0400 (EDT) Message-Id: <200207021501.LAA15941@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: "'Eric Osborne '" , "'George Sheng '" , "'scullptor@yahoo.com '" , "'mpls@UU.NET '" Subject: Re: your mail In-reply-to: Your message of Tue, 02 Jul 2002 07:20:42 -0700. <4B6D09F3B826D411A67300D0B706EFDEB03728@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Jul 2002 11:01:31 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk SD=> So you do more than one lookup- so what? so you need to parse the whole SD=> packet in the core-so what? so you need to keep state in the core, Please pay attention. There is not more than one lookup; doing the hash does not require looking anything up. Finding the bottom label does not involve parsing the whole packet. There is no state kept in the core. SD=> so you have no longer a simple label swap It is true that the essence of load balancing over equal cost paths is that the outgoing interface is not chosen solely on the basis of the top label. So? SD=> MPLS was designed to have simple forwarding. Hashing takes it to new SD=> levels of simplification never seen before. You might take a peek at section 3.12 of RFC 3031. From owner-mpls@UU.NET Tue Jul 2 11:13:48 2002 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 ESMTP id LAA17969 for ; Tue, 2 Jul 2002 11:13:47 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvua24815 for ; Tue, 2 Jul 2002 15:14:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvua22273; Tue, 2 Jul 2002 15:13:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvua01589 for mpls-outgoing; Tue, 2 Jul 2002 15:12:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvua01574 for ; Tue, 2 Jul 2002 15:12:33 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 QQmvua14609 for ; Tue, 2 Jul 2002 15:11:42 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvua21180 for ; Tue, 2 Jul 2002 15:11:41 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvua21172 for ; Tue, 2 Jul 2002 15:11:41 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA28645 for ; Tue, 2 Jul 2002 11:11:41 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA17570 for mpls@uu.net; Tue, 2 Jul 2002 11:11:41 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvty06169 for ; Tue, 2 Jul 2002 14:34:20 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 QQmvty01991 for ; Tue, 2 Jul 2002 14:32:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvty13215 for ; Tue, 2 Jul 2002 14:32:15 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: madrid.cisco.com [64.103.17.204]) id QQmvty13016 for ; Tue, 2 Jul 2002 14:32:09 GMT Received: from MACHANAW2K (dhcp-mad-wer4-vl11-64-103-19-91.cisco.com [64.103.19.91]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA24794 for ; Tue, 2 Jul 2002 16:32:01 +0200 (MET DST) From: "Miguel Angel Chana" To: Subject: RE: your mail Date: Tue, 2 Jul 2002 16:31:59 +0200 Message-ID: <004a01c221d5$3a9d8e70$5b136740@emea.cisco.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.4807.1700 Importance: Normal In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: Comments in-line: > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jeff > Parker > Sent: Tuesday, July 02, 2002 4:14 PM > To: 'erosen@cisco.com'; Shahram Davari > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > Subject: RE: your mail > > > > A hash is a function that maps some sequence of octets into > > a sequence of integers. If you want to split traffic over > > six paths, while ensuring that all packets with the same > > bottom label travel the same path, you need a > > function that maps a 20 bit quantity into a number from > > 1-6. There is no need to maintain state of any kind. > > Eric - > > There are many functions that map your octets onto the range > from 1 to 6. Based on the distribution of your octets > (i.e. the flows you expect to see) you might have different > functions if you tried to spread the load evenly. > Wouldn't you need some state to remember which function you > picked? > Not at all, you use the same function for all the packets traversing the box. If the hashing function produces many collisions, just pick another one more suitable, but this choice has to be done only once, not per packet. Regards > - jeff parker > - axiowave networks From owner-mpls@UU.NET Tue Jul 2 11:37:58 2002 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 ESMTP id LAA23132 for ; Tue, 2 Jul 2002 11:37:57 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuc13606 for ; Tue, 2 Jul 2002 15:38:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuc10536; Tue, 2 Jul 2002 15:36:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuc05970 for mpls-outgoing; Tue, 2 Jul 2002 15:36:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvuc05964 for ; Tue, 2 Jul 2002 15:36:26 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 QQmvuc11888 for ; Tue, 2 Jul 2002 15:36:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuc09857 for ; Tue, 2 Jul 2002 15:36:10 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 QQmvuc09837 for ; Tue, 2 Jul 2002 15:36:09 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA07470; Tue, 2 Jul 2002 17:35:48 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA24445; Tue, 2 Jul 2002 17:36:02 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 17:36:01 +0200 Message-ID: From: Hummel Heinrich To: "'erosen@cisco.com'" , Shahram Davari Cc: "'Eric Osborne '" , "'George Sheng '" , "'scullptor@yahoo.com '" , "'mpls@UU.NET '" Subject: AW: your mail Date: Tue, 2 Jul 2002 17:36: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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA23132 Eric, Let me cite section 3.12 of RFC 3031: The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used when forwarding packets that arrive unlabeled, but which are to be labeled before being forwarded. If the FTN maps a particular label to a set of NHLFEs that contains more than one element,... What kind of logic is applied in saying : "the FTN maps each FEC to blablabla" followed by "if the FTN maps a particular label to blablabla" All I can conclude is, that a label is equal to a FEC. I am sure, I am not the only one who is lost. And if such kind of logic were written into this RFC intentionally, then I think things are getting out of control. Standards are not made that the one guy interpretes the label as a VC-label,the other one as a hint for load balancing, and a third one as a message from the Captain of the Night. BTW: Which signalling TLV of the LSP-establishment message contains the respective interpretation ? Heinrich -----Ursprüngliche Nachricht----- Von: Eric Rosen [mailto:erosen@cisco.com] Gesendet: Dienstag, 2. Juli 2002 17:02 An: Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: Re: your mail SD=> So you do more than one lookup- so what? so you need to parse the whole SD=> packet in the core-so what? so you need to keep state in the core, Please pay attention. There is not more than one lookup; doing the hash does not require looking anything up. Finding the bottom label does not involve parsing the whole packet. There is no state kept in the core. SD=> so you have no longer a simple label swap It is true that the essence of load balancing over equal cost paths is that the outgoing interface is not chosen solely on the basis of the top label. So? SD=> MPLS was designed to have simple forwarding. Hashing takes it to new SD=> levels of simplification never seen before. You might take a peek at section 3.12 of RFC 3031. From owner-mpls@UU.NET Tue Jul 2 11:42:23 2002 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 ESMTP id LAA23387 for ; Tue, 2 Jul 2002 11:42:23 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuc17979 for ; Tue, 2 Jul 2002 15:43:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuc14802; Tue, 2 Jul 2002 15:41:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuc06608 for mpls-outgoing; Tue, 2 Jul 2002 15:41:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvuc06599 for ; Tue, 2 Jul 2002 15:41:17 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 QQmvuc26101 for ; Tue, 2 Jul 2002 15:41:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuc00508 for ; Tue, 2 Jul 2002 15:41:04 GMT Received: from dfw-gate2.raytheon.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dfw-gate2.raytheon.com [199.46.199.231]) id QQmvuc00501 for ; Tue, 2 Jul 2002 15:41:03 GMT Received: from ds02c00.directory.ray.com (ds02c00.directory.ray.com [147.25.138.118]) by dfw-gate2.raytheon.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id g62Ff2e18547 for ; Tue, 2 Jul 2002 10:41:03 -0500 (CDT) Received: from ds02c00.directory.ray.com (root@localhost) by ds02c00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g62FdeMl008713 for ; Tue, 2 Jul 2002 10:40:58 -0500 (CDT) Received: from ad2-mta02.and.us.ray.com (ad2-mta02.and.us.ray.com [138.127.59.160]) by ds02c00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g62FdN0h008504 for ; Tue, 2 Jul 2002 10:39:34 -0500 (CDT) Subject: QoS Survey Paper To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Navid Yazdani" Date: Tue, 2 Jul 2002 11:26:23 -0400 X-MIMETrack: Serialize by Router on AD2-MTA02/SRV/Raytheon(Release 5.0.10 |March 22, 2002) at 07/02/2002 11:38:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Can anyone recommend a survey paper, article, or book that examines the advantages and disadvantages of different IP QoS schemes? thanks Navid From owner-mpls@UU.NET Tue Jul 2 11:48:56 2002 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 ESMTP id LAA23807 for ; Tue, 2 Jul 2002 11:48:54 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvud28415 for ; Tue, 2 Jul 2002 15:49:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvud25516; Tue, 2 Jul 2002 15:48:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvud07466 for mpls-outgoing; Tue, 2 Jul 2002 15:47:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvud07459 for ; Tue, 2 Jul 2002 15:47: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 QQmvud19711 for ; Tue, 2 Jul 2002 15:47:02 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvud24707 for ; Tue, 2 Jul 2002 15:47:02 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmvud24698 for ; Tue, 2 Jul 2002 15:47:02 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 11:47:01 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022670FB@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Hummel Heinrich'" , "'erosen@cisco.com'" , Shahram Davari Cc: "'Eric Osborne '" , "'George Sheng '" , "'scullptor@yahoo.com '" , "'mpls@UU.NET '" Subject: RE: your mail Date: Tue, 2 Jul 2002 11:47:01 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA23807 Heinrich, What a standard should not do is unnecessarily constrain implementations. If an implementation has more than one NHLFE for the same label, which one it (the implementation) chooses to use _really_ is an implementation local issue. The standard need not (and should not) say anything about it... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] Sent: Tuesday, July 02, 2002 11:36 AM To: 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Subject: AW: your mail Eric, Let me cite section 3.12 of RFC 3031: The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used when forwarding packets that arrive unlabeled, but which are to be labeled before being forwarded. If the FTN maps a particular label to a set of NHLFEs that contains more than one element,... What kind of logic is applied in saying : "the FTN maps each FEC to blablabla" followed by "if the FTN maps a particular label to blablabla" All I can conclude is, that a label is equal to a FEC. I am sure, I am not the only one who is lost. And if such kind of logic were written into this RFC intentionally, then I think things are getting out of control. Standards are not made that the one guy interpretes the label as a VC-label,the other one as a hint for load balancing, and a third one as a message from the Captain of the Night. BTW: Which signalling TLV of the LSP-establishment message contains the respective interpretation ? Heinrich -----Ursprüngliche Nachricht----- Von: Eric Rosen [mailto:erosen@cisco.com] Gesendet: Dienstag, 2. Juli 2002 17:02 An: Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: Re: your mail SD=> So you do more than one lookup- so what? so you need to parse the whole SD=> packet in the core-so what? so you need to keep state in the core, Please pay attention. There is not more than one lookup; doing the hash does not require looking anything up. Finding the bottom label does not involve parsing the whole packet. There is no state kept in the core. SD=> so you have no longer a simple label swap It is true that the essence of load balancing over equal cost paths is that the outgoing interface is not chosen solely on the basis of the top label. So? SD=> MPLS was designed to have simple forwarding. Hashing takes it to new SD=> levels of simplification never seen before. You might take a peek at section 3.12 of RFC 3031. From owner-mpls@UU.NET Tue Jul 2 12:00:50 2002 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 ESMTP id MAA24613 for ; Tue, 2 Jul 2002 12:00:50 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvue10469 for ; Tue, 2 Jul 2002 16:01:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvue08199; Tue, 2 Jul 2002 16:00:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvue08673 for mpls-outgoing; Tue, 2 Jul 2002 16:00:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvud08549 for ; Tue, 2 Jul 2002 15:59: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 QQmvud22769 for ; Tue, 2 Jul 2002 15:58:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvud08757 for ; Tue, 2 Jul 2002 15:58:36 GMT Received: from ams2eusosrv9.ams.ops.eu.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams2eusosrv9.ams.ops.eu.uu.net [146.188.99.14]) id QQmvud08746 for ; Tue, 2 Jul 2002 15:58:35 GMT Received: from ams2eusosrv1.ams.ops.eu.uu.net by ams2eusosrv9.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: ams2eusosrv1.ams.ops.eu.uu.net [146.188.99.6]) id QQmvud11270; Tue, 2 Jul 2002 15:58:34 GMT Received: from ams2eusosrv1.ams.ops.eu.uu.net by ams2eusosrv1.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvud15252; Tue, 2 Jul 2002 15:58:11 GMT Received: from amr1.eu.uu.net by ams2eusosrv1.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: cgen1.cbg.ops.eu.uu.net [62.191.16.229]) id QQmvud15241; Tue, 2 Jul 2002 15:58:11 GMT Received: from SPAMRELAY ([139.4.37.210]) SMTPAUTH: client authenticated: kscharwa/LOGIN by amr1.eu.uu.net (8.11.3/8.11.3) with ESMTP id g62Fw9j18202STARTTLS using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO Tue, 2 Jul 2002 15:58:11 GMT From: "Kai A. Scharwacht" To: "Hummel Heinrich" Cc: Subject: RE: your mail Date: Tue, 2 Jul 2002 17:57:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 V6.00.2600.0000 In-reply-to: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi, what about if this is a simple editing error? In the context of section 3.11 (ILM) it appears to me that "label" in 3.12 and below should rather be replaced by "FEC". That would IMHO make a bit more sense. Especially when looking at the applicability statement "It is used..[for]..packets that arrive unlabeled." Cheers, Kai > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Hummel > Heinrich > Sent: Tuesday, July 02, 2002 5:36 PM > To: 'erosen@cisco.com'; Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; > 'mpls@UU.NET ' > Subject: AW: your mail > > > Eric, > Let me cite section 3.12 of RFC 3031: > The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is > used when forwarding packets that arrive unlabeled, but which are to > be labeled before being forwarded. > If the FTN maps a particular label to a set of NHLFEs that contains > more than one element,... > > What kind of logic is applied in saying : > "the FTN maps each FEC to blablabla" followed by "if the FTN > maps a particular label to blablabla" > > All I can conclude is, that a label is equal to a FEC. > I am sure, I am not the only one who is lost. > > And if such kind of logic were written into this RFC > intentionally, then I think things are > getting out of control. Standards are not made that the one > guy interpretes the label as a VC-label,the other one > as a hint for load balancing, and a third one as a message > from the Captain of the Night. > BTW: Which signalling TLV of the LSP-establishment message > contains the respective interpretation ? > > Heinrich > > > -----Ursprüngliche Nachricht----- > Von: Eric Rosen [mailto:erosen@cisco.com] > Gesendet: Dienstag, 2. Juli 2002 17:02 > An: Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; > 'mpls@UU.NET ' > Betreff: Re: your mail > > > > SD=> So you do more than one lookup- so what? so you need to > parse the whole > SD=> packet in the core-so what? so you need to keep state in > the core, > > Please pay attention. > > There is not more than one lookup; doing the hash does not > require looking > anything up. > > Finding the bottom label does not involve parsing the whole packet. > > There is no state kept in the core. > > SD=> so you have no longer a simple label swap > > It is true that the essence of load balancing over equal > cost paths is that > the outgoing interface is not chosen solely on the basis of > the top label. > So? > > SD=> MPLS was designed to have simple forwarding. Hashing > takes it to new > SD=> levels of simplification never seen before. > > You might take a peek at section 3.12 of RFC 3031. From owner-mpls@UU.NET Tue Jul 2 12:01:06 2002 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 ESMTP id MAA24655 for ; Tue, 2 Jul 2002 12:01:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvue12772 for ; Tue, 2 Jul 2002 16:01:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvue09754; Tue, 2 Jul 2002 16:00:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvud08504 for mpls-outgoing; Tue, 2 Jul 2002 15:59:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvud08457 for ; Tue, 2 Jul 2002 15:59:44 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 QQmvud18068 for ; Tue, 2 Jul 2002 15:59:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvud08961 for ; Tue, 2 Jul 2002 15:59:20 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQmvud08948 for ; Tue, 2 Jul 2002 15:59:19 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 RAA26298; Tue, 2 Jul 2002 17:59:15 +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 RAA27082; Tue, 2 Jul 2002 17:59:16 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 17:59:15 +0200 Message-ID: From: Hummel Heinrich To: "'Gray, Eric'" , Hummel Heinrich , "'erosen@cisco.com'" , Shahram Davari Cc: "'Eric Osborne '" , "'George Sheng '" , "'scullptor@yahoo.com '" , "'mpls@UU.NET '" Subject: AW: your mail Date: Tue, 2 Jul 2002 17:59:10 +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 MAA24655 If there were several NHLFEs there is only one proper interpretation and that is point-to-multipoint i.e. multicast. Either several branches out from the source node, or several branches in the middle of the multicast delivery tree. To interprete whatever pleases you, kills the entire state of the art. Heinrich -----Ursprüngliche Nachricht----- Von: Gray, Eric [mailto:egray@celoxnetworks.com] Gesendet: Dienstag, 2. Juli 2002 17:47 An: 'Hummel Heinrich'; 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: RE: your mail Heinrich, What a standard should not do is unnecessarily constrain implementations. If an implementation has more than one NHLFE for the same label, which one it (the implementation) chooses to use _really_ is an implementation local issue. The standard need not (and should not) say anything about it... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] Sent: Tuesday, July 02, 2002 11:36 AM To: 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Subject: AW: your mail Eric, Let me cite section 3.12 of RFC 3031: The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used when forwarding packets that arrive unlabeled, but which are to be labeled before being forwarded. If the FTN maps a particular label to a set of NHLFEs that contains more than one element,... What kind of logic is applied in saying : "the FTN maps each FEC to blablabla" followed by "if the FTN maps a particular label to blablabla" All I can conclude is, that a label is equal to a FEC. I am sure, I am not the only one who is lost. And if such kind of logic were written into this RFC intentionally, then I think things are getting out of control. Standards are not made that the one guy interpretes the label as a VC-label,the other one as a hint for load balancing, and a third one as a message from the Captain of the Night. BTW: Which signalling TLV of the LSP-establishment message contains the respective interpretation ? Heinrich -----Ursprüngliche Nachricht----- Von: Eric Rosen [mailto:erosen@cisco.com] Gesendet: Dienstag, 2. Juli 2002 17:02 An: Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: Re: your mail SD=> So you do more than one lookup- so what? so you need to parse the whole SD=> packet in the core-so what? so you need to keep state in the core, Please pay attention. There is not more than one lookup; doing the hash does not require looking anything up. Finding the bottom label does not involve parsing the whole packet. There is no state kept in the core. SD=> so you have no longer a simple label swap It is true that the essence of load balancing over equal cost paths is that the outgoing interface is not chosen solely on the basis of the top label. So? SD=> MPLS was designed to have simple forwarding. Hashing takes it to new SD=> levels of simplification never seen before. You might take a peek at section 3.12 of RFC 3031. From owner-mpls@UU.NET Tue Jul 2 12:10:15 2002 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 ESMTP id MAA28013 for ; Tue, 2 Jul 2002 12:10:14 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvue12863 for ; Tue, 2 Jul 2002 16:10:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvue09677; Tue, 2 Jul 2002 16:09:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvue02157 for mpls-outgoing; Tue, 2 Jul 2002 16:08:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvue02008 for ; Tue, 2 Jul 2002 16:08:46 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 QQmvue13616 for ; Tue, 2 Jul 2002 16:08:28 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvue19194 for ; Tue, 2 Jul 2002 16:08:27 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvue19187 for ; Tue, 2 Jul 2002 16:08:27 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA03279; Tue, 2 Jul 2002 12:08:27 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA01204; Tue, 2 Jul 2002 12:08:27 -0400 (EDT) Message-Id: <200207021608.MAA01204@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: "Kai A. Scharwacht" cc: "Hummel Heinrich" , mpls@UU.NET Subject: Re: your mail In-reply-to: Your message of Tue, 02 Jul 2002 17:57:33 +0200. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Jul 2002 12:08:26 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Kai> what about if this is a simple editing error? In the context Kai> of section 3.11 (ILM) it appears to me that "label" in 3.12 Kai> and below should rather be replaced by "FEC". Thank you. Yes this is a cut and paste error. Actually, in the context of this thread the section I should have referenced is 3.11. From owner-mpls@UU.NET Tue Jul 2 12:13:29 2002 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 ESMTP id MAA28429 for ; Tue, 2 Jul 2002 12:13:28 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvue23559 for ; Tue, 2 Jul 2002 16:14:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvue21371; Tue, 2 Jul 2002 16:13:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvue04114 for mpls-outgoing; Tue, 2 Jul 2002 16:12:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvue04104 for ; Tue, 2 Jul 2002 16:12: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 QQmvue18382 for ; Tue, 2 Jul 2002 16:12:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvue20939 for ; Tue, 2 Jul 2002 16:12:26 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQmvue20935 for ; Tue, 2 Jul 2002 16:12:26 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA09070; Tue, 2 Jul 2002 18:12:03 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA03371; Tue, 2 Jul 2002 18:12:18 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 18:12:17 +0200 Message-ID: From: Hummel Heinrich To: "'erosen@cisco.com'" , "Kai A. Scharwacht" Cc: Hummel Heinrich , mpls@UU.NET Subject: AW: your mail Date: Tue, 2 Jul 2002 18:12:17 +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 MAA28429 OK. But still see my email referring to multicast. You cannot kill multicast by doing anycast. Heinrich -----Ursprüngliche Nachricht----- Von: Eric Rosen [mailto:erosen@cisco.com] Gesendet: Dienstag, 2. Juli 2002 18:08 An: Kai A. Scharwacht Cc: Hummel Heinrich; mpls@UU.NET Betreff: Re: your mail Kai> what about if this is a simple editing error? In the context Kai> of section 3.11 (ILM) it appears to me that "label" in 3.12 Kai> and below should rather be replaced by "FEC". Thank you. Yes this is a cut and paste error. Actually, in the context of this thread the section I should have referenced is 3.11. From owner-mpls@UU.NET Tue Jul 2 12:27:35 2002 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 ESMTP id MAA28981 for ; Tue, 2 Jul 2002 12:27:34 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuf04761 for ; Tue, 2 Jul 2002 16:28:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuf02173; Tue, 2 Jul 2002 16:26:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuf06107 for mpls-outgoing; Tue, 2 Jul 2002 16:26:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvuf06102 for ; Tue, 2 Jul 2002 16:26: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 QQmvuf18939 for ; Tue, 2 Jul 2002 16:25:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuf03715 for ; Tue, 2 Jul 2002 16:25:03 GMT Received: from kcmso2.proxy.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQmvuf03708 for ; Tue, 2 Jul 2002 16:25:02 GMT Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g62FW0xq014747 for ; Tue, 2 Jul 2002 11:25:01 -0500 (CDT) Received: from OCCLUST01EVS1.ugd.att.com (135.71.164.6) by attrh3i.attrh.att.com (6.5.019) id 3CE519BE016DE566; Tue, 2 Jul 2002 12:25:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: LDP-MIB & VPN-MIB Date: Tue, 2 Jul 2002 12:25:00 -0400 Message-ID: <5F2B8267D7B55B47BDE2868D227BF50C06A660@OCCLUST01EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: LDP-MIB & VPN-MIB Thread-Index: AcIePWiBS0cT3lNKQ8mcadLVd3rVyADmsRpQ From: "Chung, Li-Jin W, ALCNS" To: "Joan Cucchiara" Cc: , "Ash, Gerald R (Jerry), ALASO" , "Nguyen, Mai-Uyen T, ALCNS" , "D'Souza, Kevin L, ALCNS" , "Lai, Wai S (Waisum), ALASO" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA28981 Joan, Thank you for your feedback. Please see my comments below. Thanks, Li Chung -----Original Message----- From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com] Sent: Thursday, June 27, 2002 8:49 PM To: Chung, Li-Jin W, ALCNS Cc: mpls@UU.NET; Ash, Gerald R (Jerry), ALASO; Nguyen, Mai-Uyen T, ALCNS; D'Souza, Kevin L, ALCNS; Lai, Wai S (Waisum), ALASO Subject: Re: LDP-MIB & VPN-MIB Hello, "Chung, Li-Jin W, ALCNS" wrote: > > Hi., > > I am new to this list. So, if what I say here has been addressed by other means please let me know. > Recently, I have studied draft-ietf-mpls-ldp-mib-08 and draft-ietf-ppvpn-mpls-vpn-mib-03 and have identified some potential enhancement areas for our future considerations. I would like to get your feedback if these areas of observations make sense to you. > > In the LDP-MIB, > (1) The variables in the following two notifications do not have the information related to the IfIndex in the IF-MIB, this will prolong the proactive fault management cycle time for operators. > 1. mplsLdpSessionUp & > 2. mplsLdpSessionDown > > I would like to suggest to include "mplsLdpConfGenericIfIndexOrZero" or equivalent of such variable in the notification object. The mplsLdpEntityLdpId, mplsLdpEntityIndex, and mplsLdpPeerLdpId (which are included) would give an operator a clear indication of which port. Operators would be creating Entities on each LSR and assign the LDP Identifiers, so in this specific case they would have created the Entity (and assigned the mplsLdpEntityLdpId) and the Peer (and assigned the mplsLdpPeerLdpId), so they should have the info needed. * from Li: * A few observations of your suggestions: * (1) The above suggested variables are not in the notification spec. today. So, you and I would agree that some more variables need to be added to the notification. * (2) If there are multiple L2 interfaces between two peers that running LDP, we need to know which physical interface that causes the LDP session down/up trap. The above three variables does not provide specific physical interface information. The logical interface information is useful but they are more difficult for the operator to perform troubleshooting. * (3) Based on the description/definition of the above variables, none of them has any indication of association with IfIndex in the If-MIB. And, IfIndex in the If-MIB will be one object which could provide the mapping between the Physical Interface and logical interface of LDP entity. That is why I would suggest to add IfIndex/IfDescr variable in the notification message. > > (2) There is no specification on how to retain the counters when an LDP-entity/session is broken and then reestablished again. Because of such, some implemenation will remove the entire entry statistics when an LDP-session is broken and when the same session is re-established again the counter will be treated as a new counter. Some accumulation of such old and new counters need to be specified. There are 2 tables of counters. The first table of counters, mplsLdpEntityStatsTable, contain counters of an Entity because these are counters which are received when a session is attempted/initializing. These counters will help determine whether or not the session ever gets established. These counters do not have a discontinuity time associated with them because seeing these is an indication that the Session is not being established. So, in other words, if you see these counters increasing, that could be an indication that something is misconfigured with the corresponding Entity. If you don't see a Session being established on this entity, then these counters are meant to help figure out why. from Li: * How? One possible implementation of such MIB (since one vendor implement such way) is that when a session is established then went down, all records related to this "down" session are removed. These include: all objects in the mplsLdpEntityStatsTable as well as all objects in the mplsLdpSesStatsTable are removed from the statistics. When the same session is re-established again, it assigns to another session number (the next session number in sequence), so from the session number perspective in the LDP-MIB report, it is a brand new session and has no knowledge/linkage that this new session number is associated with an OLD session number. So, your suggestion of the above "help figure out why" does not really work in such implementation. I am looking for a way in the MIB to insure such linkage is guaranteed. Otherwise, the above two statistics table does not provide meaningful information from my perspective. * A suggested linkage is to add IfIndex on top of the Peering entry in the session index. So it will provide a more "solid" mapping relationship. * Another suggestion is to find a way not to remove the OLD session statistics when a session goes down so we are able to "figure out why". The second table of counters, mplsLdpSesStatsTable, contain counters on a session. These counters may have a discontinuity (i.e. session up/down) but that is noted in the mplsLdpSesDiscontinuityTime object which corresponds to the entry. * from Li: * Please see my comment above. Li Chung Hope that help, -Joan > > In the VPN-MIB, > > (1) Although there is a notification of VRF maximum route threshold exceeded, there is no counter of number of routes dropped due to such threshold exceeds. I would like to suggest to add a counter of such dropped routes for capacity planning and for threshold tunning. > > (2) From what I can tell, in the route target table, there is no mapping for the associated RD. I would like to suggest to add such association between VRF, RD and RT in the RT table. > > Please let me know if you have any comments. > > Thanks, > > Li Chung From owner-mpls@UU.NET Tue Jul 2 12:33:52 2002 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 ESMTP id MAA29352 for ; Tue, 2 Jul 2002 12:33:51 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvug14578 for ; Tue, 2 Jul 2002 16:34:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvug12448; Tue, 2 Jul 2002 16:33:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvug06440 for mpls-outgoing; Tue, 2 Jul 2002 16:33:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvug06430 for ; Tue, 2 Jul 2002 16:32: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 QQmvug02341 for ; Tue, 2 Jul 2002 16:32:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvug03113 for ; Tue, 2 Jul 2002 16:32:03 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmvug03107 for ; Tue, 2 Jul 2002 16:32:02 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 12:32:02 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022670FD@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Hummel Heinrich'" Cc: "'mpls@UU.NET '" , "Gray, Eric" Subject: RE: your mail Date: Tue, 2 Jul 2002 12:31:56 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA29352 Heinrich, So, this particular branch has been hashed out several times in the past. Interpretation of labels is an implementation issue. It should be possible for an implementation to interpret its own labels in whatever way it wishes, consistent with the notion of fulfilling its role in forwarding packets. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] Sent: Tuesday, July 02, 2002 11:59 AM To: 'Gray, Eric'; Hummel Heinrich; 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Subject: AW: your mail If there were several NHLFEs there is only one proper interpretation and that is point-to-multipoint i.e. multicast. Either several branches out from the source node, or several branches in the middle of the multicast delivery tree. To interprete whatever pleases you, kills the entire state of the art. Heinrich -----Ursprüngliche Nachricht----- Von: Gray, Eric [mailto:egray@celoxnetworks.com] Gesendet: Dienstag, 2. Juli 2002 17:47 An: 'Hummel Heinrich'; 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: RE: your mail Heinrich, What a standard should not do is unnecessarily constrain implementations. If an implementation has more than one NHLFE for the same label, which one it (the implementation) chooses to use _really_ is an implementation local issue. The standard need not (and should not) say anything about it... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] Sent: Tuesday, July 02, 2002 11:36 AM To: 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Subject: AW: your mail Eric, Let me cite section 3.12 of RFC 3031: The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used when forwarding packets that arrive unlabeled, but which are to be labeled before being forwarded. If the FTN maps a particular label to a set of NHLFEs that contains more than one element,... What kind of logic is applied in saying : "the FTN maps each FEC to blablabla" followed by "if the FTN maps a particular label to blablabla" All I can conclude is, that a label is equal to a FEC. I am sure, I am not the only one who is lost. And if such kind of logic were written into this RFC intentionally, then I think things are getting out of control. Standards are not made that the one guy interpretes the label as a VC-label,the other one as a hint for load balancing, and a third one as a message from the Captain of the Night. BTW: Which signalling TLV of the LSP-establishment message contains the respective interpretation ? Heinrich -----Ursprüngliche Nachricht----- Von: Eric Rosen [mailto:erosen@cisco.com] Gesendet: Dienstag, 2. Juli 2002 17:02 An: Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: Re: your mail SD=> So you do more than one lookup- so what? so you need to parse the whole SD=> packet in the core-so what? so you need to keep state in the core, Please pay attention. There is not more than one lookup; doing the hash does not require looking anything up. Finding the bottom label does not involve parsing the whole packet. There is no state kept in the core. SD=> so you have no longer a simple label swap It is true that the essence of load balancing over equal cost paths is that the outgoing interface is not chosen solely on the basis of the top label. So? SD=> MPLS was designed to have simple forwarding. Hashing takes it to new SD=> levels of simplification never seen before. You might take a peek at section 3.12 of RFC 3031. From owner-mpls@UU.NET Tue Jul 2 12:39:03 2002 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 ESMTP id MAA29713 for ; Tue, 2 Jul 2002 12:39:03 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvug13605 for ; Tue, 2 Jul 2002 16:39:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvug09285; Tue, 2 Jul 2002 16:37:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvug06887 for mpls-outgoing; Tue, 2 Jul 2002 16:37:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvug06872 for ; Tue, 2 Jul 2002 16:37: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 QQmvug05277 for ; Tue, 2 Jul 2002 16:35:49 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvug16789 for ; Tue, 2 Jul 2002 16:35:45 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmvug16740 for ; Tue, 2 Jul 2002 16:35:43 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 12:35:42 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022670FE@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'erosen@cisco.com'" Cc: Shahram Davari , "'mpls@UU.NET '" Subject: RE: your mail Date: Tue, 2 Jul 2002 12:35:37 -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 Eric, I'm guessing that some hardware implementations might be optimized around the need to process at most K labels. For any such implementation, being required to possibly look at the Nth label - where N is the number of labels in the stack and N may be greater than K - may be virtually indistinguishable from being required to parse the entire packet. In such cases, the engineers have to take a hard look at what they might use as a fall back for the N > K case and then do some hard analysis about whether or not such a fall back is guaranteed to work in all cases. Because the consequences of not getting the right answer after all this hard looking and analysis are systemic at the network level, it might be useful if this was hashed out publicly in a little more detail - don't you think? :-) Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Tuesday, July 02, 2002 11:02 AM To: Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Subject: Re: your mail SD=> So you do more than one lookup- so what? so you need to parse the whole SD=> packet in the core-so what? so you need to keep state in the core, Please pay attention. There is not more than one lookup; doing the hash does not require looking anything up. Finding the bottom label does not involve parsing the whole packet. There is no state kept in the core. SD=> so you have no longer a simple label swap It is true that the essence of load balancing over equal cost paths is that the outgoing interface is not chosen solely on the basis of the top label. So? SD=> MPLS was designed to have simple forwarding. Hashing takes it to new SD=> levels of simplification never seen before. You might take a peek at section 3.12 of RFC 3031. From owner-mpls@UU.NET Tue Jul 2 13:06:09 2002 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 ESMTP id NAA01390 for ; Tue, 2 Jul 2002 13:06:09 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvui28273 for ; Tue, 2 Jul 2002 17:06:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvui24618; Tue, 2 Jul 2002 17:04:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvui20867 for mpls-outgoing; Tue, 2 Jul 2002 17:04:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvui20860 for ; Tue, 2 Jul 2002 17:04:12 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 QQmvui05277 for ; Tue, 2 Jul 2002 17:03:00 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvui02035 for ; Tue, 2 Jul 2002 17:03:00 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvui02030 for ; Tue, 2 Jul 2002 17:02:59 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA07103; Tue, 2 Jul 2002 13:02:59 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA08380; Tue, 2 Jul 2002 13:02:59 -0400 (EDT) Message-Id: <200207021702.NAA08380@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: "Gray, Eric" cc: Shahram Davari , "'mpls@UU.NET '" Subject: Re: your mail In-reply-to: Your message of Tue, 02 Jul 2002 12:35:37 -0400. <1117F7D44159934FB116E36F4ABF221B022670FE@celox-ma1-ems1.celoxnetworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Jul 2002 13:02:59 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk EricG.> I'm guessing that some hardware implementations might be EricG.> optimized around the need to process at most K labels. For any EricG.> such implementation, being required to possibly look at the Nth EricG.> label - where N is the number of labels in the stack and N may EricG.> be greater than K - may be virtually indistinguishable from EricG.> being required to parse the entire packet. For load balancing, it should be sufficient to look at the bottommost label which appears in the high speed memory whose intention is to hold the header. That is, if you can only see top K labels, use the bottommost of those. From owner-mpls@UU.NET Tue Jul 2 13:08:15 2002 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 ESMTP id NAA01615 for ; Tue, 2 Jul 2002 13:08:15 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvui01013 for ; Tue, 2 Jul 2002 17:09:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvui26900; Tue, 2 Jul 2002 17:07:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvui22722 for mpls-outgoing; Tue, 2 Jul 2002 17:07:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvui22629 for ; Tue, 2 Jul 2002 17:06:56 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 QQmvui00758 for ; Tue, 2 Jul 2002 17:06:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvui25843 for ; Tue, 2 Jul 2002 17:06:31 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQmvui25830 for ; Tue, 2 Jul 2002 17:06:30 GMT Received: from juniper.net (pptp024.static.jnpr.net [172.24.248.24]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g62H6Om87743; Tue, 2 Jul 2002 10:06:24 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3D21DDB3.7040504@juniper.net> Date: Tue, 02 Jul 2002 10:06:59 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Navid Yazdani CC: mpls@UU.NET Subject: Re: QoS Survey Paper References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Not sure QoS is actually in the context of MPLS, but please take a look at a survey paper from Roch Guerin and Vinod Peris, "Quality-of-Service in Packet Networks: Basic Mechanisms and Directions" in http://www.seas.upenn.edu/~guerin - Ping Navid Yazdani wrote: > Can anyone recommend a survey paper, article, or book that examines the > advantages and disadvantages of different IP QoS schemes? > > thanks > Navid > > > > From owner-mpls@UU.NET Tue Jul 2 13:14:28 2002 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 ESMTP id NAA01972 for ; Tue, 2 Jul 2002 13:14:28 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuj09382 for ; Tue, 2 Jul 2002 17:15:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvui06373; Tue, 2 Jul 2002 17:13:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvui01846 for mpls-outgoing; Tue, 2 Jul 2002 17:13:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvui01820 for ; Tue, 2 Jul 2002 17:12:54 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 QQmvui16808 for ; Tue, 2 Jul 2002 17:12:30 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvui05544 for ; Tue, 2 Jul 2002 17:12:30 GMT Received: from mail2.orchestream.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.orchestream.com [195.153.64.126]) id QQmvui05540 for ; Tue, 2 Jul 2002 17:12:29 GMT Received: from rimmer.orchestream.com (unverified) by mail2.orchestream.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Tue, 2 Jul 2002 18:02:05 +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 SAA19562; Tue, 2 Jul 2002 18:02:22 +0100 Received: by S1000.orchestream.com with Internet Mail Service (5.5.2653.19) id <31D2JFT1>; Tue, 2 Jul 2002 18:02:22 +0100 Message-ID: <8AEA6B34A5AF2D4ABECB4E9351DAE6981CF0C6@S1000.orchestream.com> From: "Gibson, Mark" To: "'mpls@UU.NET '" , "Gray, Eric" Subject: RE: your mail Date: Tue, 2 Jul 2002 18:02:22 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA01972 So pardon me for butting in but isn't this really the nub of the argument here. That an LSR can examine and interpret the labels that it has allocated out of its own label space in any manner it chooses - since it knows what they relate to - but that it should not look any deeper into the label stack than its own allocated labels. If its sent n labels it can look up to n labels into the stack. How it can place any interpretation on the n+1 th label I don't know. And if it can, it kind of destroys all the MPLS-label-based VPN privacy arguments in one fell swoop. If your arguing the top paragraph then I'm fine and I'll go back to lurking. Mark -----Original Message----- From: Gray, Eric [mailto:egray@celoxnetworks.com] Sent: 02 July 2002 17:32 To: 'Hummel Heinrich' Cc: 'mpls@UU.NET '; Gray, Eric Subject: RE: your mail Heinrich, So, this particular branch has been hashed out several times in the past. Interpretation of labels is an implementation issue. It should be possible for an implementation to interpret its own labels in whatever way it wishes, consistent with the notion of fulfilling its role in forwarding packets. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] Sent: Tuesday, July 02, 2002 11:59 AM To: 'Gray, Eric'; Hummel Heinrich; 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Subject: AW: your mail If there were several NHLFEs there is only one proper interpretation and that is point-to-multipoint i.e. multicast. Either several branches out from the source node, or several branches in the middle of the multicast delivery tree. To interprete whatever pleases you, kills the entire state of the art. Heinrich -----Ursprüngliche Nachricht----- Von: Gray, Eric [mailto:egray@celoxnetworks.com] Gesendet: Dienstag, 2. Juli 2002 17:47 An: 'Hummel Heinrich'; 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: RE: your mail Heinrich, What a standard should not do is unnecessarily constrain implementations. If an implementation has more than one NHLFE for the same label, which one it (the implementation) chooses to use _really_ is an implementation local issue. The standard need not (and should not) say anything about it... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] Sent: Tuesday, July 02, 2002 11:36 AM To: 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Subject: AW: your mail Eric, Let me cite section 3.12 of RFC 3031: The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used when forwarding packets that arrive unlabeled, but which are to be labeled before being forwarded. If the FTN maps a particular label to a set of NHLFEs that contains more than one element,... What kind of logic is applied in saying : "the FTN maps each FEC to blablabla" followed by "if the FTN maps a particular label to blablabla" All I can conclude is, that a label is equal to a FEC. I am sure, I am not the only one who is lost. And if such kind of logic were written into this RFC intentionally, then I think things are getting out of control. Standards are not made that the one guy interpretes the label as a VC-label,the other one as a hint for load balancing, and a third one as a message from the Captain of the Night. BTW: Which signalling TLV of the LSP-establishment message contains the respective interpretation ? Heinrich -----Ursprüngliche Nachricht----- Von: Eric Rosen [mailto:erosen@cisco.com] Gesendet: Dienstag, 2. Juli 2002 17:02 An: Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: Re: your mail SD=> So you do more than one lookup- so what? so you need to parse the whole SD=> packet in the core-so what? so you need to keep state in the core, Please pay attention. There is not more than one lookup; doing the hash does not require looking anything up. Finding the bottom label does not involve parsing the whole packet. There is no state kept in the core. SD=> so you have no longer a simple label swap It is true that the essence of load balancing over equal cost paths is that the outgoing interface is not chosen solely on the basis of the top label. So? SD=> MPLS was designed to have simple forwarding. Hashing takes it to new SD=> levels of simplification never seen before. You might take a peek at section 3.12 of RFC 3031. From owner-mpls@UU.NET Tue Jul 2 13:34:31 2002 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 ESMTP id NAA03115 for ; Tue, 2 Jul 2002 13:34:30 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuk26540 for ; Tue, 2 Jul 2002 17:35:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuk23429; Tue, 2 Jul 2002 17:33:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuk03807 for mpls-outgoing; Tue, 2 Jul 2002 17:33:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvuk03802 for ; Tue, 2 Jul 2002 17:33: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 QQmvuk14671 for ; Tue, 2 Jul 2002 17:32:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuk21357 for ; Tue, 2 Jul 2002 17:32:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuk21349 for ; Tue, 2 Jul 2002 17:32:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA09474 for ; Tue, 2 Jul 2002 13:32:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA12617 for mpls@uu.net; Tue, 2 Jul 2002 13:32:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvuk03675 for ; Tue, 2 Jul 2002 17:30: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 QQmvuj03754 for ; Tue, 2 Jul 2002 17:29:54 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuj20114 for ; Tue, 2 Jul 2002 17:29:54 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuj20108 for ; Tue, 2 Jul 2002 17:29:54 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA09258; Tue, 2 Jul 2002 13:29:53 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA05668; Tue, 2 Jul 2002 13:29:53 -0400 (EDT) Date: Tue, 2 Jul 2002 13:29:53 -0400 From: Eric Osborne To: "Gibson, Mark" Cc: "'mpls@UU.NET '" , "Gray, Eric" Subject: Re: your mail Message-ID: <20020702172953.GP4101@eosborne-u10.cisco.com> References: <8AEA6B34A5AF2D4ABECB4E9351DAE6981CF0C6@S1000.orchestream.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8AEA6B34A5AF2D4ABECB4E9351DAE6981CF0C6@S1000.orchestream.com> User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Jul 02, 2002 at 06:02:22PM +0100, Gibson, Mark wrote: > So pardon me for butting in but isn't this really the nub of the argument > here. That an LSR can examine and interpret the labels that it has > allocated out of its own label space in any manner it chooses - since it > knows what they relate to - but that it should not look any deeper into the > label stack than its own allocated labels. I believe the discussion started out as "LDP can't do traffic engineering" and has mutated from there. > If its sent n labels it can look up to n labels into the stack. How it can > place any interpretation on the n+1 th label I don't know. > Because we're not talking about *switching* based on the underlying labels, but about some sort of tie-breaker. It's not like if you send me labels underneath what I gave you that I'll switch the label towards a *different* network exit point; my job, if I'm an LSR, is to switch based on the top label. But if there's more than one way to go to get to the point to which the top label resolves, I need a tie-breaker. This is what hashing (or however you implement it) is for. > And if it can, it kind of destroys all the MPLS-label-based VPN privacy > arguments in one fell swoop. No, it doesn't. The privacy stuff applies not to using data to do some sort of lookup for traffic forwarding, but for things like network seperation and overlapping address space. The data underneath an MPLS stack is just as private whether it's used to hash or not. eric > > If your arguing the top paragraph then I'm fine and I'll go back to lurking. > > > Mark > > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: 02 July 2002 17:32 > To: 'Hummel Heinrich' > Cc: 'mpls@UU.NET '; Gray, Eric > Subject: RE: your mail > > > Heinrich, > > So, this particular branch has been hashed > out several times in the past. Interpretation of > labels is an implementation issue. It should be > possible for an implementation to interpret its own > labels in whatever way it wishes, consistent with > the notion of fulfilling its role in forwarding > packets. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: Tuesday, July 02, 2002 11:59 AM > To: 'Gray, Eric'; Hummel Heinrich; 'erosen@cisco.com'; Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' > Subject: AW: your mail > > If there were several NHLFEs there is only one proper interpretation and > that > is point-to-multipoint i.e. multicast. Either several branches out from the > source node, or several branches > in the middle of the multicast delivery tree. > > To interprete whatever pleases you, kills the entire state of the art. > Heinrich > > -----Ursprüngliche Nachricht----- > Von: Gray, Eric [mailto:egray@celoxnetworks.com] > Gesendet: Dienstag, 2. Juli 2002 17:47 > An: 'Hummel Heinrich'; 'erosen@cisco.com'; Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; > 'mpls@UU.NET ' > Betreff: RE: your mail > > > Heinrich, > > What a standard should not do is unnecessarily > constrain implementations. If an implementation has > more than one NHLFE for the same label, which one it > (the implementation) chooses to use _really_ is an > implementation local issue. The standard need not > (and should not) say anything about it... > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: Tuesday, July 02, 2002 11:36 AM > To: 'erosen@cisco.com'; Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' > Subject: AW: your mail > > Eric, > Let me cite section 3.12 of RFC 3031: > The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is > used when forwarding packets that arrive unlabeled, but which are to > be labeled before being forwarded. > If the FTN maps a particular label to a set of NHLFEs that contains > more than one element,... > > What kind of logic is applied in saying : > "the FTN maps each FEC to blablabla" followed by "if the FTN maps a > particular label to blablabla" > > All I can conclude is, that a label is equal to a FEC. > I am sure, I am not the only one who is lost. > > And if such kind of logic were written into this RFC intentionally, then I > think things are > getting out of control. Standards are not made that the one guy interpretes > the label as a VC-label,the other one > as a hint for load balancing, and a third one as a message from the Captain > of the Night. > BTW: Which signalling TLV of the LSP-establishment message contains the > respective interpretation ? > > Heinrich > > > -----Ursprüngliche Nachricht----- > Von: Eric Rosen [mailto:erosen@cisco.com] > Gesendet: Dienstag, 2. Juli 2002 17:02 > An: Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; > 'mpls@UU.NET ' > Betreff: Re: your mail > > > > SD=> So you do more than one lookup- so what? so you need to parse the whole > SD=> packet in the core-so what? so you need to keep state in the core, > > Please pay attention. > > There is not more than one lookup; doing the hash does not require looking > anything up. > > Finding the bottom label does not involve parsing the whole packet. > > There is no state kept in the core. > > SD=> so you have no longer a simple label swap > > It is true that the essence of load balancing over equal cost paths is that > the outgoing interface is not chosen solely on the basis of the top label. > So? > > SD=> MPLS was designed to have simple forwarding. Hashing takes it to new > SD=> levels of simplification never seen before. > > You might take a peek at section 3.12 of RFC 3031. From owner-mpls@UU.NET Tue Jul 2 13:39:38 2002 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 ESMTP id NAA03398 for ; Tue, 2 Jul 2002 13:39:37 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuk28324 for ; Tue, 2 Jul 2002 17:40:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuk24641; Tue, 2 Jul 2002 17:38:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuk04325 for mpls-outgoing; Tue, 2 Jul 2002 17:37:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvuk04318 for ; Tue, 2 Jul 2002 17:37: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 QQmvuk20955 for ; Tue, 2 Jul 2002 17:37:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuk23994 for ; Tue, 2 Jul 2002 17:37:22 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuk23986 for ; Tue, 2 Jul 2002 17:37:22 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA09943 for ; Tue, 2 Jul 2002 13:37:21 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA13466 for mpls@uu.net; Tue, 2 Jul 2002 13:37:21 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvuk04183 for ; Tue, 2 Jul 2002 17:36: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 QQmvuk20125 for ; Tue, 2 Jul 2002 17:34:41 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuk22608 for ; Tue, 2 Jul 2002 17:34:41 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuk22603 for ; Tue, 2 Jul 2002 17:34:40 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA09726; Tue, 2 Jul 2002 13:34:40 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA05682; Tue, 2 Jul 2002 13:34:40 -0400 (EDT) Date: Tue, 2 Jul 2002 13:34:40 -0400 From: Eric Osborne To: Jeff Parker Cc: "'erosen@cisco.com'" , Shahram Davari , "'Eric Osborne'" , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: Re: your mail Message-ID: <20020702173439.GR4101@eosborne-u10.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Tue, Jul 02, 2002 at 10:51:11AM -0400, Jeff Parker wrote: > > Jeff> There are many functions that map your octets onto the range > > Jeff> from 1 to 6. Based on the distribution of your octets > > Jeff> (i.e. the flows you expect to see) you might have different > > Jeff> functions if you tried to spread the load evenly. > > Jeff> Wouldn't you need some state to remember which function you > > Jeff> picked? > > > > I think the usual implementation technique is to pick a > > function and compile > > it into the code ;-) > > Eric - > There are schemes out there that compile a function > into code, hash, and then use the result to pick a bucket > based on ranges computed to equalize the flow. The > state is reduced to N integers, but represents state all > the same. > Of course, if you don't care about equalizing the > flow, you don't need to be so careful. I guess it depends on what you mean by "state". With the given definition, one also needs to keep state just to switch IP or MPLS packets (state about InLabel/OutLabel/OutIF mapping). Right? Given that, any loadsharing "state" is simply an extension of what already must be kept. Heck, looking at it this way, even simple, co-like TDM boxes need state. I've always looked at state as something computed dynamically based not on the switching tables but on the traffic itself (building a flow cache, for example), and let me make it perfectly clear, I'm not a fan of flow caches[ eric From owner-mpls@UU.NET Tue Jul 2 13:41:33 2002 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 ESMTP id NAA03518 for ; Tue, 2 Jul 2002 13:41:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuk08888 for ; Tue, 2 Jul 2002 17:42:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuk25723; Tue, 2 Jul 2002 17:34:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuk03890 for mpls-outgoing; Tue, 2 Jul 2002 17:34:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvuk03879 for ; Tue, 2 Jul 2002 17:34: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 QQmvuk19183 for ; Tue, 2 Jul 2002 17:34:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuk22281 for ; Tue, 2 Jul 2002 17:34:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuk22276 for ; Tue, 2 Jul 2002 17:34:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA09667 for ; Tue, 2 Jul 2002 13:34:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA12838 for mpls@uu.net; Tue, 2 Jul 2002 13:34:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvuk03809 for ; Tue, 2 Jul 2002 17:33: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 QQmvuk12946 for ; Tue, 2 Jul 2002 17:32:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuk21429 for ; Tue, 2 Jul 2002 17:32:10 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuk21421 for ; Tue, 2 Jul 2002 17:32:09 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA09486; Tue, 2 Jul 2002 13:32:09 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA05674; Tue, 2 Jul 2002 13:32:09 -0400 (EDT) Date: Tue, 2 Jul 2002 13:32:09 -0400 From: Eric Osborne To: Hummel Heinrich Cc: "'erosen@cisco.com'" , Shahram Davari , "'Eric Osborne'" , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: Re: your mail Message-ID: <20020702173208.GQ4101@eosborne-u10.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > It gets weirder and weirder: The MPLS WG invents a label stack, but does not care at all that any of the > deeper nested labels may ever be signalled/carried by means of a Label-TLV/object (no public comments to my > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > However it is ok, to "steal" the deepest nested label and call it "VC-label" for indexing > some VRF at some remote PE. This is not theft; it's using the labels as they were designed. How is using the bottommost label as a VC-labe/VPN label/whatever "stealing"? You seem to be attacking the very idea of label stacking, which is a pretty useful concept. > Furthermore it is ok, to "steal" the very same label for hashing. > What about IP router vendors that do load-balancing based on L4/L5 information like protocol type and port numbers? Is that stealing? eric > Independent from what is clean and what is quick&dirty, I cannot detect any sense in giving a hash-meaning to the bottom label at all. > > > > Heinrich Hummel > Siemens > > -----Ursprüngliche Nachricht----- > Von: Eric Rosen [mailto:erosen@cisco.com] > Gesendet: Dienstag, 2. Juli 2002 16:06 > An: Shahram Davari > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > Betreff: Re: your mail > > > Shahram> To do ECMP, you need to assign hashed values to egress ports. This > Shahram> assignment is the hash state that I said you need. > > A hash is a function that maps some sequence of octets into a sequence of > integers. If you want to split traffic over six paths, while ensuring that > all packets with the same bottom label travel the same path, you need a > function that maps a 20 bit quantity into a number from 1-6. There is no > need to maintain state of any kind. From owner-mpls@UU.NET Tue Jul 2 13:48:56 2002 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 ESMTP id NAA03982 for ; Tue, 2 Jul 2002 13:48:55 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvul10656 for ; Tue, 2 Jul 2002 17:49:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvul07605; Tue, 2 Jul 2002 17:48:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvul05747 for mpls-outgoing; Tue, 2 Jul 2002 17:48:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvul05731 for ; Tue, 2 Jul 2002 17:47: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 QQmvul19681 for ; Tue, 2 Jul 2002 17:47:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvul07537 for ; Tue, 2 Jul 2002 17:47:48 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f138.law4.hotmail.com [216.33.149.138]) id QQmvul07530 for ; Tue, 2 Jul 2002 17:47:47 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Jul 2002 10:47:46 -0700 Received: from 65.174.124.29 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 02 Jul 2002 17:47:46 GMT X-Originating-IP: [65.174.124.29] From: "Tissa Senevirathne" To: Heinrich.Hummel@icn.siemens.de, erosen@cisco.com, Shahram_Davari@pmc-sierra.com Cc: eosborne@cisco.com, george_s97@hotmail.com, scullptor@yahoo.com, mpls@UU.NET Subject: Re: AW: your mail Date: Tue, 02 Jul 2002 17:47:46 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jul 2002 17:47:46.0914 (UTC) FILETIME=[936E4420:01C221F0] Sender: owner-mpls@UU.NET Precedence: bulk Why are we saying ECMP hash is to pick a number between 1 and 6 ? Why not 64 ? In my opinion ECMP is entirely a local implementation issue. And at WG requirement level one sentence to say " Any load balancing policies implemented MUST not mis order packets" is adequate >From: Hummel Heinrich >To: "'erosen@cisco.com'" , Shahram Davari > >CC: "'Eric Osborne'" , George Sheng >, scullptor@yahoo.com, mpls@UU.NET >Subject: AW: your mail Date: Tue, 2 Jul 2002 16:25:37 +0200 > >It gets weirder and weirder: The MPLS WG invents a label stack, but does >not care at all that any of the >deeper nested labels may ever be signalled/carried by means of a >Label-TLV/object (no public comments to my >Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > >However it is ok, to "steal" the deepest nested label and call it >"VC-label" for indexing >some VRF at some remote PE. Furthermore it is ok, to "steal" the very same >label for hashing. > >Independent from what is clean and what is quick&dirty, I cannot detect any >sense in giving a hash-meaning to the bottom label at all. > > > >Heinrich Hummel >Siemens > >-----Ursprüngliche Nachricht----- >Von: Eric Rosen [mailto:erosen@cisco.com] >Gesendet: Dienstag, 2. Juli 2002 16:06 >An: Shahram Davari >Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET >Betreff: Re: your mail > > >Shahram> To do ECMP, you need to assign hashed values to egress ports. >This >Shahram> assignment is the hash state that I said you need. > >A hash is a function that maps some sequence of octets into a sequence >of >integers. If you want to split traffic over six paths, while ensuring >that >all packets with the same bottom label travel the same path, you need >a >function that maps a 20 bit quantity into a number from 1-6. There is >no >need to maintain state of any kind. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Tue Jul 2 14:03:05 2002 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 ESMTP id OAA04617 for ; Tue, 2 Jul 2002 14:03:04 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum22712 for ; Tue, 2 Jul 2002 18:03:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvum19940; Tue, 2 Jul 2002 18:02:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvum15926 for mpls-outgoing; Tue, 2 Jul 2002 18:01:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvum15896 for ; Tue, 2 Jul 2002 18:01: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 QQmvum07922 for ; Tue, 2 Jul 2002 18:01:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum21208 for ; Tue, 2 Jul 2002 18:01:13 GMT Received: from zcars04e.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmvum21199 for ; Tue, 2 Jul 2002 18:01:12 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g62I0XQ13807; Tue, 2 Jul 2002 14:00:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 14:00:32 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C0476BA8C@zcard031.ca.nortel.com> From: "David Allan" To: Tissa Senevirathne , Heinrich.Hummel@icn.siemens.de, erosen@cisco.com, Shahram_Davari@pmc-sierra.com Cc: eosborne@cisco.com, george_s97@hotmail.com, scullptor@yahoo.com, mpls@UU.NET Subject: RE: AW: your mail Date: Tue, 2 Jul 2002 14:00:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C221F2.56208CF2" 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_01C221F2.56208CF2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tissa: I think we need to be a bit stricter. Define mis-ordering...at what granularity ;-). Similarly any path test tool (e.g. ICMP) must follow = the same path as the traffic. cheers Dave > -----Original Message----- > From: Tissa Senevirathne [mailto:tsenevir@hotmail.com] > Sent: Tuesday, July 02, 2002 1:48 PM > To: Heinrich.Hummel@icn.siemens.de; erosen@cisco.com; > Shahram_Davari@pmc-sierra.com > Cc: eosborne@cisco.com; george_s97@hotmail.com; scullptor@yahoo.com; > mpls@UU.NET > Subject: Re: AW: your mail >=20 >=20 > Why are we saying ECMP hash is to pick a number between 1 and=20 > 6 ? Why not 64=20 > ? >=20 > In my opinion ECMP is entirely a local implementation issue.=20 > And at WG=20 > requirement level one sentence to say > " Any load balancing policies implemented MUST not mis order packets" > is adequate >=20 >=20 > >From: Hummel Heinrich > >To: "'erosen@cisco.com'" , Shahram Davari=20 > > > >CC: "'Eric Osborne'" , George Sheng=20 > >, scullptor@yahoo.com, mpls@UU.NET > >Subject: AW: your mail Date: Tue, 2 Jul 2002 16:25:37 +0200 > > > >It gets weirder and weirder: The MPLS WG invents a label=20 > stack, but does=20 > >not care at all that any of the > >deeper nested labels may ever be signalled/carried by means of a=20 > >Label-TLV/object (no public comments to my > >Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > >However it is ok, to "steal" the deepest nested label and call it=20 > >"VC-label" for indexing > >some VRF at some remote PE. Furthermore it is ok, to "steal"=20 > the very same=20 > >label for hashing. > > > >Independent from what is clean and what is quick&dirty, I=20 > cannot detect any=20 > >sense in giving a hash-meaning to the bottom label at all. > > > > > > > >Heinrich Hummel > >Siemens > > > >-----Urspr=FCngliche Nachricht----- > >Von: Eric Rosen [mailto:erosen@cisco.com] > >Gesendet: Dienstag, 2. Juli 2002 16:06 > >An: Shahram Davari > >Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > >Betreff: Re: your mail > > > > > >Shahram> To do ECMP, you need to assign hashed values to=20 > egress ports.=20 > >This > >Shahram> assignment is the hash state that I said you need. > > > >A hash is a function that maps some sequence of octets=20 > into a sequence=20 > >of > >integers. If you want to split traffic over six paths,=20 > while ensuring=20 > >that > >all packets with the same bottom label travel the same=20 > path, you need=20 > >a > >function that maps a 20 bit quantity into a number from=20 > 1-6. There is=20 > >no > >need to maintain state of any kind. >=20 >=20 >=20 >=20 > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com >=20 >=20 ------_=_NextPart_001_01C221F2.56208CF2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AW: your mail

Tissa:

I think we need to be a bit stricter. Define = mis-ordering...at what granularity ;-). Similarly any path test tool = (e.g. ICMP) must follow the same path as the traffic.

cheers
Dave

> -----Original Message-----
> From: Tissa Senevirathne [mailto:tsenevir@hotmail.com]
> Sent: Tuesday, July 02, 2002 1:48 PM
> To: Heinrich.Hummel@icn.siemens.de; = erosen@cisco.com;
> Shahram_Davari@pmc-sierra.com
> Cc: eosborne@cisco.com; george_s97@hotmail.com; = scullptor@yahoo.com;
> mpls@UU.NET
> Subject: Re: AW: your mail
>
>
> Why are we saying ECMP hash is to pick a number = between 1 and
> 6 ? Why not 64
> ?
>
> In my opinion ECMP is entirely a local = implementation issue.
> And at WG
> requirement level one sentence to say
> " Any load balancing policies implemented = MUST not mis order packets"
> is adequate
>
>
> >From: Hummel Heinrich = <Heinrich.Hummel@icn.siemens.de>
> >To: "'erosen@cisco.com'" = <erosen@cisco.com>,        = Shahram Davari
> = ><Shahram_Davari@pmc-sierra.com>
> >CC: "'Eric Osborne'" = <eosborne@cisco.com>,        = George Sheng
> ><george_s97@hotmail.com>, = scullptor@yahoo.com,        = mpls@UU.NET
> >Subject: AW: your mail Date: Tue, 2 Jul = 2002 16:25:37 +0200
> >
> >It  gets weirder  and weirder: = The MPLS WG invents a label
> stack, but does
> >not care at all that any of the
> >deeper nested labels may ever be = signalled/carried by means of a
> >Label-TLV/object (no public comments to = my
> >Hierarchical LSPs, = draft-hummel-mpls-hierarchical-lsp-01.txt).
> >
> >However it is ok, to "steal" the = deepest nested label and call it
> >"VC-label" for indexing
> >some VRF at some remote PE. Furthermore it = is ok, to "steal"
> the very same
> >label for hashing.
> >
> >Independent from what is clean and what is = quick&dirty, I
> cannot detect any
> >sense in giving a hash-meaning to the = bottom label at all.
> >
> >
> >
> >Heinrich Hummel
> >Siemens
> >
> >-----Urspr=FCngliche Nachricht-----
> >Von: Eric Rosen [mailto:erosen@cisco.com]
> >Gesendet: Dienstag, 2. Juli 2002 = 16:06
> >An: Shahram Davari
> >Cc: 'Eric Osborne'; George Sheng; = scullptor@yahoo.com; mpls@UU.NET
> >Betreff: Re: your mail
> >
> >
> >Shahram> To do ECMP, you need to  = assign hashed values to
> egress ports.
> >This
> >Shahram> assignment is the hash state = that I said you need.
> >
> >A hash is  a function that maps  = some sequence of octets
> into  a sequence
> >of
> >integers.  If you want to split  = traffic over six paths,
> while ensuring
> >that
> >all packets  with the  same = bottom label  travel the  same
> path, you  need
> >a
> >function that maps  a 20 bit = quantity  into a number from
> 1-6.   There is
> >no
> >need to maintain state of any kind.
>
>
>
>
> = _________________________________________________________________=
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>

------_=_NextPart_001_01C221F2.56208CF2-- From owner-mpls@UU.NET Tue Jul 2 14:05:55 2002 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 ESMTP id OAA04783 for ; Tue, 2 Jul 2002 14:05:55 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum24067 for ; Tue, 2 Jul 2002 18:05:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvum18437; Tue, 2 Jul 2002 18:03:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvum18446 for mpls-outgoing; Tue, 2 Jul 2002 18:02:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvum18439 for ; Tue, 2 Jul 2002 18:02: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 QQmvum10276 for ; Tue, 2 Jul 2002 18:02:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum17809 for ; Tue, 2 Jul 2002 18:02:05 GMT Received: from mail.timetra.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.timetra.com [63.104.212.2]) id QQmvum17803 for ; Tue, 2 Jul 2002 18:02:04 GMT Received: from vkompella ([192.168.1.253]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 2 Jul 2002 11:01:57 -0700 From: "Vach Kompella" To: "Gibson, Mark" , , "Gray, Eric" Subject: RE: your mail Date: Tue, 2 Jul 2002 11:04:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <8AEA6B34A5AF2D4ABECB4E9351DAE6981CF0C6@S1000.orchestream.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-OriginalArrivalTime: 02 Jul 2002 18:01:57.0940 (UTC) FILETIME=[8EAE8740:01C221F2] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit For ECMP, you have to look at least one label lower (or more precisely, one layer higher). Essentially, you are trying to identify flows and make sure a particular flow goes over the same path, to avoid out-of-sequence issues. The identifiers for a flow lie at least one layer higher than the label stack at which you operate. So, an L2 flow is identified by the VC label, a TCP flow is identified by the port numbers, etc. -Vach > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Gibson, > Mark > Sent: Tuesday, July 02, 2002 10:02 AM > To: 'mpls@UU.NET '; Gray, Eric > Subject: RE: your mail > > > So pardon me for butting in but isn't this really the nub of the argument > here. That an LSR can examine and interpret the labels that it has > allocated out of its own label space in any manner it chooses - since it > knows what they relate to - but that it should not look any deeper into the > label stack than its own allocated labels. > > If its sent n labels it can look up to n labels into the stack. How it can > place any interpretation on the n+1 th label I don't know. > > And if it can, it kind of destroys all the MPLS-label-based VPN privacy > arguments in one fell swoop. > > If your arguing the top paragraph then I'm fine and I'll go back to lurking. > > > Mark > > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: 02 July 2002 17:32 > To: 'Hummel Heinrich' > Cc: 'mpls@UU.NET '; Gray, Eric > Subject: RE: your mail > > > Heinrich, > > So, this particular branch has been hashed > out several times in the past. Interpretation of > labels is an implementation issue. It should be > possible for an implementation to interpret its own > labels in whatever way it wishes, consistent with > the notion of fulfilling its role in forwarding > packets. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: Tuesday, July 02, 2002 11:59 AM > To: 'Gray, Eric'; Hummel Heinrich; 'erosen@cisco.com'; Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' > Subject: AW: your mail > > If there were several NHLFEs there is only one proper interpretation and > that > is point-to-multipoint i.e. multicast. Either several branches out from the > source node, or several branches > in the middle of the multicast delivery tree. > > To interprete whatever pleases you, kills the entire state of the art. > Heinrich > > -----Ursprüngliche Nachricht----- > Von: Gray, Eric [mailto:egray@celoxnetworks.com] > Gesendet: Dienstag, 2. Juli 2002 17:47 > An: 'Hummel Heinrich'; 'erosen@cisco.com'; Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; > 'mpls@UU.NET ' > Betreff: RE: your mail > > > Heinrich, > > What a standard should not do is unnecessarily > constrain implementations. If an implementation has > more than one NHLFE for the same label, which one it > (the implementation) chooses to use _really_ is an > implementation local issue. The standard need not > (and should not) say anything about it... > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: Tuesday, July 02, 2002 11:36 AM > To: 'erosen@cisco.com'; Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' > Subject: AW: your mail > > Eric, > Let me cite section 3.12 of RFC 3031: > The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is > used when forwarding packets that arrive unlabeled, but which are to > be labeled before being forwarded. > If the FTN maps a particular label to a set of NHLFEs that contains > more than one element,... > > What kind of logic is applied in saying : > "the FTN maps each FEC to blablabla" followed by "if the FTN maps a > particular label to blablabla" > > All I can conclude is, that a label is equal to a FEC. > I am sure, I am not the only one who is lost. > > And if such kind of logic were written into this RFC intentionally, then I > think things are > getting out of control. Standards are not made that the one guy interpretes > the label as a VC-label,the other one > as a hint for load balancing, and a third one as a message from the Captain > of the Night. > BTW: Which signalling TLV of the LSP-establishment message contains the > respective interpretation ? > > Heinrich > > > -----Ursprüngliche Nachricht----- > Von: Eric Rosen [mailto:erosen@cisco.com] > Gesendet: Dienstag, 2. Juli 2002 17:02 > An: Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; > 'mpls@UU.NET ' > Betreff: Re: your mail > > > > SD=> So you do more than one lookup- so what? so you need to parse the whole > SD=> packet in the core-so what? so you need to keep state in the core, > > Please pay attention. > > There is not more than one lookup; doing the hash does not require looking > anything up. > > Finding the bottom label does not involve parsing the whole packet. > > There is no state kept in the core. > > SD=> so you have no longer a simple label swap > > It is true that the essence of load balancing over equal cost paths is that > the outgoing interface is not chosen solely on the basis of the top label. > So? > > SD=> MPLS was designed to have simple forwarding. Hashing takes it to new > SD=> levels of simplification never seen before. > > You might take a peek at section 3.12 of RFC 3031. From owner-mpls@UU.NET Tue Jul 2 14:08:54 2002 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 ESMTP id OAA05015 for ; Tue, 2 Jul 2002 14:08:54 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum02192 for ; Tue, 2 Jul 2002 18:09:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvum28689; Tue, 2 Jul 2002 18:07:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvum28323 for mpls-outgoing; Tue, 2 Jul 2002 18:07:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvum28317 for ; Tue, 2 Jul 2002 18:07: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 QQmvum22973 for ; Tue, 2 Jul 2002 18:06:36 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum27692 for ; Tue, 2 Jul 2002 18:06:33 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvum27655 for ; Tue, 2 Jul 2002 18:06:32 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12361 for ; Tue, 2 Jul 2002 14:06:32 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA19471 for mpls@uu.net; Tue, 2 Jul 2002 14:06:32 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvul05671 for ; Tue, 2 Jul 2002 17:46:25 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 QQmvul23155 for ; Tue, 2 Jul 2002 17:45:46 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvul06497 for ; Tue, 2 Jul 2002 17:45:46 GMT Received: from ponyexpress.ee.columbia.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ponyexpress.ee.columbia.edu [128.59.64.61]) id QQmvul06480 for ; Tue, 2 Jul 2002 17:45:45 GMT Received: from merope.comet.columbia.edu (merope.comet.columbia.edu [128.59.67.140]) by ponyexpress.ee.columbia.edu (8.12.1/8.12.1) with ESMTP id g62Hh5Fl018886; Tue, 2 Jul 2002 13:43:05 -0400 Received: from localhost (mk@localhost) by merope.comet.columbia.edu (8.11.6/8.11.6) with ESMTP id g62Hh5t16427; Tue, 2 Jul 2002 13:43:05 -0400 Date: Tue, 2 Jul 2002 13:43:04 -0400 (EDT) From: Michael Kounavis To: Navid Yazdani cc: Subject: Re: QoS Survey Paper In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk There is a book on Quality of Service by P. Ferguson and G. Huston "Quality of Service: Delivering QoS on the Internet and in Corporate Networks" Publisher: John Wiley and Sons For an Overview of packet scheduling techniques look at chapter 9 from S. Keshav's book: "An Engineering approach to Computer Networking", Addison Wesley.i A high level over view of Internet QoS mechanisms is also given at: "Internet QoS: THe Big Picture", by X. Xiao and L. Ni, Michigan State University http://www.cse.msu.edu/~xiaoxipe/papers/msu.inet.qos.bigpicture.pdf And of course an excellent overview is given in Roch's paper, which Ping suggested. Michael On Tue, 2 Jul 2002, Navid Yazdani wrote: > Can anyone recommend a survey paper, article, or book that examines the > advantages and disadvantages of different IP QoS schemes? > > thanks > Navid > > -- -- Michael Kounavis http://www.comet.columbia.edu/~mk From owner-mpls@UU.NET Tue Jul 2 14:13:10 2002 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 ESMTP id OAA05380 for ; Tue, 2 Jul 2002 14:13:10 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum05623 for ; Tue, 2 Jul 2002 18:13:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvum02396; Tue, 2 Jul 2002 18:12:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvum29471 for mpls-outgoing; Tue, 2 Jul 2002 18:11:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvum29447 for ; Tue, 2 Jul 2002 18:11:30 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 QQmvum13192 for ; Tue, 2 Jul 2002 18:11:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum01703 for ; Tue, 2 Jul 2002 18:11:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvum01685 for ; Tue, 2 Jul 2002 18:11:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12773 for ; Tue, 2 Jul 2002 14:11:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA20437 for mpls@uu.net; Tue, 2 Jul 2002 14:11:04 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvum28592 for ; Tue, 2 Jul 2002 18:10: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 QQmvum26451 for ; Tue, 2 Jul 2002 18:09:40 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum00793 for ; Tue, 2 Jul 2002 18:09:40 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvum00777 for ; Tue, 2 Jul 2002 18:09:39 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12662; Tue, 2 Jul 2002 14:09:39 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05997; Tue, 2 Jul 2002 14:09:39 -0400 (EDT) Date: Tue, 2 Jul 2002 14:09:39 -0400 From: Eric Osborne To: David Allan Cc: Tissa Senevirathne , Heinrich.Hummel@icn.siemens.de, erosen@cisco.com, Shahram_Davari@pmc-sierra.com, eosborne@cisco.com, george_s97@hotmail.com, scullptor@yahoo.com, mpls@UU.NET Subject: Re: AW: your mail Message-ID: <20020702180938.GY4101@eosborne-u10.cisco.com> References: <9FBD322B7824D511B36900508BF93C9C0476BA8C@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9FBD322B7824D511B36900508BF93C9C0476BA8C@zcard031.ca.nortel.com> User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Jul 02, 2002 at 02:00:23PM -0400, David Allan wrote: > Tissa: > > I think we need to be a bit stricter. Define mis-ordering...at what > granularity ;-). "during times of network stability (no link flaps causing rerouting, etc), any sequence of packets sent from one host to another must arrive in the order in which they are sent"...or something like that. eric > Similarly any path test tool (e.g. ICMP) must follow the > same path as the traffic. > > cheers > Dave > > > -----Original Message----- > > From: Tissa Senevirathne [mailto:tsenevir@hotmail.com] > > Sent: Tuesday, July 02, 2002 1:48 PM > > To: Heinrich.Hummel@icn.siemens.de; erosen@cisco.com; > > Shahram_Davari@pmc-sierra.com > > Cc: eosborne@cisco.com; george_s97@hotmail.com; scullptor@yahoo.com; > > mpls@UU.NET > > Subject: Re: AW: your mail > > > > > > Why are we saying ECMP hash is to pick a number between 1 and > > 6 ? Why not 64 > > ? > > > > In my opinion ECMP is entirely a local implementation issue. > > And at WG > > requirement level one sentence to say > > " Any load balancing policies implemented MUST not mis order packets" > > is adequate > > > > > > >From: Hummel Heinrich > > >To: "'erosen@cisco.com'" , Shahram Davari > > > > > >CC: "'Eric Osborne'" , George Sheng > > >, scullptor@yahoo.com, mpls@UU.NET > > >Subject: AW: your mail Date: Tue, 2 Jul 2002 16:25:37 +0200 > > > > > >It gets weirder and weirder: The MPLS WG invents a label > > stack, but does > > >not care at all that any of the > > >deeper nested labels may ever be signalled/carried by means of a > > >Label-TLV/object (no public comments to my > > >Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > >However it is ok, to "steal" the deepest nested label and call it > > >"VC-label" for indexing > > >some VRF at some remote PE. Furthermore it is ok, to "steal" > > the very same > > >label for hashing. > > > > > >Independent from what is clean and what is quick&dirty, I > > cannot detect any > > >sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > >Heinrich Hummel > > >Siemens > > > > > >-----Ursprüngliche Nachricht----- > > >Von: Eric Rosen [mailto:erosen@cisco.com] > > >Gesendet: Dienstag, 2. Juli 2002 16:06 > > >An: Shahram Davari > > >Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > >Betreff: Re: your mail > > > > > > > > >Shahram> To do ECMP, you need to assign hashed values to > > egress ports. > > >This > > >Shahram> assignment is the hash state that I said you need. > > > > > >A hash is a function that maps some sequence of octets > > into a sequence > > >of > > >integers. If you want to split traffic over six paths, > > while ensuring > > >that > > >all packets with the same bottom label travel the same > > path, you need > > >a > > >function that maps a 20 bit quantity into a number from > > 1-6. There is > > >no > > >need to maintain state of any kind. > > > > > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > From owner-mpls@UU.NET Tue Jul 2 14:14:57 2002 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 ESMTP id OAA05507 for ; Tue, 2 Jul 2002 14:14:57 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvun04238 for ; Tue, 2 Jul 2002 18:15:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvum00414; Tue, 2 Jul 2002 18:13:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvum29723 for mpls-outgoing; Tue, 2 Jul 2002 18:13:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvum29668 for ; Tue, 2 Jul 2002 18:13:07 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 QQmvum28293 for ; Tue, 2 Jul 2002 18:10:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum01127 for ; Tue, 2 Jul 2002 18:10:16 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvum01119 for ; Tue, 2 Jul 2002 18:10:16 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12724 for ; Tue, 2 Jul 2002 14:10:15 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA20282 for mpls@uu.net; Tue, 2 Jul 2002 14:10:15 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvum28511 for ; Tue, 2 Jul 2002 18:09: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 QQmvum23636 for ; Tue, 2 Jul 2002 18:08:34 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvum29820 for ; Tue, 2 Jul 2002 18:08:33 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvum29789 for ; Tue, 2 Jul 2002 18:08:33 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12567; Tue, 2 Jul 2002 14:08:32 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05989; Tue, 2 Jul 2002 14:08:32 -0400 (EDT) Date: Tue, 2 Jul 2002 14:08:32 -0400 From: Eric Osborne To: Tissa Senevirathne Cc: Heinrich.Hummel@icn.siemens.de, erosen@cisco.com, Shahram_Davari@pmc-sierra.com, eosborne@cisco.com, george_s97@hotmail.com, scullptor@yahoo.com, mpls@UU.NET Subject: Re: AW: your mail Message-ID: <20020702180832.GX4101@eosborne-u10.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Jul 02, 2002 at 05:47:46PM +0000, Tissa Senevirathne wrote: > Why are we saying ECMP hash is to pick a number between 1 and 6 ? Why not > 64 ? > "...between 1 and N, where N in this example is 6". Happy? IETF should not be defining limits for things like these, and I don't believe that's what we're talking about. There happen to be both implementation limits that may constrain N and also real-world limits where the odds of having 64 equal-cost paths to a destination is pretty low. But it's purely a local matter. eric > In my opinion ECMP is entirely a local implementation issue. And at WG > requirement level one sentence to say > " Any load balancing policies implemented MUST not mis order packets" > is adequate > > > >From: Hummel Heinrich > >To: "'erosen@cisco.com'" , Shahram Davari > > > >CC: "'Eric Osborne'" , George Sheng > >, scullptor@yahoo.com, mpls@UU.NET > >Subject: AW: your mail Date: Tue, 2 Jul 2002 16:25:37 +0200 > > > >It gets weirder and weirder: The MPLS WG invents a label stack, but does > >not care at all that any of the > >deeper nested labels may ever be signalled/carried by means of a > >Label-TLV/object (no public comments to my > >Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > >However it is ok, to "steal" the deepest nested label and call it > >"VC-label" for indexing > >some VRF at some remote PE. Furthermore it is ok, to "steal" the very same > >label for hashing. > > > >Independent from what is clean and what is quick&dirty, I cannot detect > >any sense in giving a hash-meaning to the bottom label at all. > > > > > > > >Heinrich Hummel > >Siemens > > > >-----Ursprüngliche Nachricht----- > >Von: Eric Rosen [mailto:erosen@cisco.com] > >Gesendet: Dienstag, 2. Juli 2002 16:06 > >An: Shahram Davari > >Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > >Betreff: Re: your mail > > > > > >Shahram> To do ECMP, you need to assign hashed values to egress ports. > >This > >Shahram> assignment is the hash state that I said you need. > > > >A hash is a function that maps some sequence of octets into a sequence > >of > >integers. If you want to split traffic over six paths, while ensuring > >that > >all packets with the same bottom label travel the same path, you need > >a > >function that maps a 20 bit quantity into a number from 1-6. There is > >no > >need to maintain state of any kind. > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Tue Jul 2 14:25:02 2002 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 ESMTP id OAA06249 for ; Tue, 2 Jul 2002 14:25:02 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvun16882 for ; Tue, 2 Jul 2002 18:25:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvun14484; Tue, 2 Jul 2002 18:24:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvun01601 for mpls-outgoing; Tue, 2 Jul 2002 18:24:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvun01592 for ; Tue, 2 Jul 2002 18:24: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 QQmvun03614 for ; Tue, 2 Jul 2002 18:20:32 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvun16042 for ; Tue, 2 Jul 2002 18:20:31 GMT Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmvun16036 for ; Tue, 2 Jul 2002 18:20:31 GMT Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 2 Jul 2002 19:20:32 +0100 Message-ID: To: eosborne@cisco.com Cc: Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: your mail Date: Tue, 2 Jul 2002 19:15:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Thanks Eric.....please see my further observations and attempted answers to your questions. regards, Neil > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: 02 July 2002 14:12 > To: neil.2.harrison@bt.com > Cc: eosborne@cisco.com; Shahram_Davari@pmc-sierra.com; mpls@UU.NET > Subject: Re: your mail > > > On Tue, Jul 02, 2002 at 10:51:52AM +0100, > neil.2.harrison@bt.com wrote: > > Eric, please see below....I think this is the answer you > seek (though I > > suspect you may not like it). > > > > yeah, probably...:) see inline > > > regards, Neil > > > > > -----Original Message----- > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > Sent: 02 July 2002 03:32 > > > To: Shahram Davari > > > Cc: 'erosen@cisco.com'; Eric Osborne; George Sheng; > > > scullptor@yahoo.com; > > > mpls@UU.NET > > > Subject: Re: your mail > > > "absolute addressing information", to me, sounds like "enough > addressing information to get the packet to its final destination, > i.e. an end station". Right? If so, wouldn't that be true for cases > like IPinIP when the IP core doesn't know about addresses at the IP > edge (a la gre tunnels)? Or do you mean something else? NH=> No, this is precisely what I mean. Within the constraint of a given routing domain, cnls forwarding must use unique addressing. When I say 'absolute' addressing I mean its unique wrt to the whole routing domain and not a single hop within it.....when I say 'relative' addressing its only unique to an interface (like case of labels, VPI/VCI or DLCIs) which is the normal mode of stringing together a set of hops (=link-connections) to create a co trail (though the trail termination points must have absolute addressing). Further, and although it might not be immediately obvious why its relevent here, when one creates trails via concatenated relatively addressed link-connections the pkts alone cannot convey all the required QoS/survivability attributes (as they have to in a cnls mode)......you have to take pkts_+_parent_trail into account, and its the trail entity that is the key/primary focus for proper fault-management. Hope that helps clear up what I mean. > > I also don't see how this turns into a "connectivity verification > function". What about an IP packet (or IPinIP) inherently has more > verification than IPinMPLS? NH=> They are fundamentally different. An IP address means something to the whole of its routing domain. A label only means something to an interface (or at largest a node....though a few labels have been globally reserved for specific/network-wide functions, eg null labels). So if an IP pkt ends up in the wrong place it will (usually) get re-directed back on course....however, if a labelled pkt ends up in the wrong place it may be showing a valid label for its next hop and get misdirected (or if not it will get immediately black-holed....and it will usually get black-holed at some higher levels when labels fail to match anymore or, if it makes to the the client level, than at this highest LSP->clinet adaptation point). So we can get (and have seen) misrouting defects because the same labels are used on different/disjoint hops. > And isn't this turning into an OAM > discussion again, rather than talking about loadsharing? NH=> Well, fault-management is fundamentally important to us operators....and if you fail to get this key-stone right then whatever follows will not have a good foundation. Loadsharing is one by-product of using LDP because there is no felxibility in routing choice.....but its not the only by-product of LDP. > > I'm not sure I buy into the argument that the co paradigm is the only > way to do stuff like qos/survivability/etc. Granted, you are far more > a co-paradigm guy than I am, so you know this area better, but I > suspect that means you're walking around with a co-paradigm-shaped > hammer, looking for a nail. Of course, the same thing could be said > about my connectionless bias, so really there's no easy way out, here. NH=> Not at all....if that is your impression of what I said you have completely misunderstood me. The main message I gave was this: - true cnls = good for certain applications - true p2p co = good for certain applications They both have important roles and neither should be regarded as supplanting the other. I believe we can do the vast majority of networks services with both these modes. What I don't see however is a compelling reason for mp2p LDP over the other modes. > > But whatever the argument, isn't the same is true for IPinIP where the > outer IP address is your PE (or whatever your term is) and the inner > IP is relevant to your customer, right? NH=>No....in both the operator and the customer routing domains the IP addresses relevant to each are unique to the whole of each (disjoint) routing domain. This is not true for labels, VPI/VCI, DLCI when these are link-connection only unique. > > > Here, we need to introduce a signalling or NMS > set-up/tear-down capability, > > and the fundamantal networking concept is the *connection* > itself, and the > > fault/performance management of such is the critical piece. > > ah....OAM again...me and my ten-foot pole are going somewhere else > now... NH=> Where might that be LSP-PING perhaps?......same problem, just far more complex attempt at solution. Seriously though, fault-management of networks is really important to operators. > I guess the fundamental piece I'm still missing is that I don't see > how LDP is any different from IP at the forwarding level. NH=> IP uses memoryless best-match look-up and LDP uses pre-calculated paths that have locally significant 'tags' applied to them (this is a co trait). By definition these are subject to different failures modes....and I know its the OAM stuff you don't like again but LDP data-plane forwarding has new failure modes that don't exist in IP. Why else do you think some of your colleagues are working on LSP-PING? Further, MPLS can carry protocols other than IP....so this raises other aspects that need consideration (and where fault-management solutions really need to client (and server) agnostic). > I'm just trying to understand the basic objection to LDP, > when the forwarding looks the same as IP. NH=> And that is the crux of the point....it may *look* the same when its working but it does not fail the same. > And I don't mean the OAM > side, but the loadsharing side; loadsharing is how we started this > topic (I think), so I'd like to keep it there. NH=> Load-sharing is only 1 aspect of MPLS/LDP they don't tell you about too loudly about at sale time when explaining the 'simple' label-swapping paradigm ;-)......and just focussing on this topic misses the bigger picture anyway. You need to look at the whole space to draw meaningful conclusions. thanks and regards, Neil From owner-mpls@UU.NET Tue Jul 2 14:28:15 2002 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 ESMTP id OAA06469 for ; Tue, 2 Jul 2002 14:28:15 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvun20202 for ; Tue, 2 Jul 2002 18:28:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvun17724; Tue, 2 Jul 2002 18:27:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvun01917 for mpls-outgoing; Tue, 2 Jul 2002 18:27:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvun01905 for ; Tue, 2 Jul 2002 18:27: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 QQmvun19074 for ; Tue, 2 Jul 2002 18:26:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvun21740 for ; Tue, 2 Jul 2002 18:26:30 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 QQmvun21732 for ; Tue, 2 Jul 2002 18:26: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 OAA20684; Tue, 2 Jul 2002 14:26: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 OAA02557; Tue, 2 Jul 2002 14:26:28 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jul 2002 14:26:28 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5576323B@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'David Allan'" , Tissa Senevirathne , Heinrich.Hummel@icn.siemens.de, erosen@cisco.com, Shahram_Davari@pmc-sierra.com Cc: eosborne@cisco.com, george_s97@hotmail.com, scullptor@yahoo.com, mpls@UU.NET Subject: RE: AW: your mail Date: Tue, 2 Jul 2002 14:26:27 -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 Dave, -> Similarly any path test tool (e.g. ICMP) must follow the same path as the traffic. ^^^^ Not true. One can't guarantee that behavior in IP routing. -- Venkata From owner-mpls@UU.NET Tue Jul 2 14:37:25 2002 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 ESMTP id OAA07150 for ; Tue, 2 Jul 2002 14:37:25 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuo02587 for ; Tue, 2 Jul 2002 18:38:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuo00141; Tue, 2 Jul 2002 18:37:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuo02680 for mpls-outgoing; Tue, 2 Jul 2002 18:36:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvuo02671 for ; Tue, 2 Jul 2002 18:36:39 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 QQmvuo11923 for ; Tue, 2 Jul 2002 18:36:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuo27740 for ; Tue, 2 Jul 2002 18:36:18 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQmvuo27734 for ; Tue, 2 Jul 2002 18:36:17 GMT Message-ID: From: Jeff Parker To: "'Eric Osborne'" , Jeff Parker Cc: "'erosen@cisco.com'" , Shahram Davari , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: RE: your mail Date: Tue, 2 Jul 2002 14:35:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > > use the result to pick a bucket > > I guess it depends on what you mean by "state". With the given > definition, one also needs to keep state just to switch IP or MPLS > packets (state about InLabel/OutLabel/OutIF mapping). Right? Given > that, any loadsharing "state" is simply an extension of what already > must be kept. Heck, looking at it this way, even simple, co-like TDM > boxes need state. I've always looked at state as something computed > dynamically based not on the switching tables but on the traffic > itself (building a flow cache, for example), and let me make it > perfectly clear, I'm not a fan of flow caches[ > > eric Eric - I don't have any problem with idea of keeping state. This thread started with a claim that the hashing would not need to keep state. I'm happy to let it stop here. - jeff parker - axiowave networks From owner-mpls@UU.NET Tue Jul 2 14:50:56 2002 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 ESMTP id OAA07950 for ; Tue, 2 Jul 2002 14:50:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvup07875 for ; Tue, 2 Jul 2002 18:51:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvup05547; Tue, 2 Jul 2002 18:50:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvup04131 for mpls-outgoing; Tue, 2 Jul 2002 18:50:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvup04123 for ; Tue, 2 Jul 2002 18:50:16 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 QQmvup12940 for ; Tue, 2 Jul 2002 18:49:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvup14847 for ; Tue, 2 Jul 2002 18:49:29 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 QQmvup14837 for ; Tue, 2 Jul 2002 18:49:29 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 OAA22326; Tue, 2 Jul 2002 14:49:26 -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 OAA07132; Tue, 2 Jul 2002 14:49:27 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jul 2002 14:49:26 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5576323C@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Vach Kompella'" , "Gibson, Mark" , mpls@UU.NET, "Gray, Eric" Subject: RE: your mail Date: Tue, 2 Jul 2002 14:49:26 -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 Vach, -> For ECMP, you have to look at least one label lower (or more -> precisely, one layer higher). Why? It is very difficult to look at the payload of MPLS packets the way the encapsulations are defined. So, a router trying to do load balancing have to know the X in XoverMPLS (all the PPP exts, LLC encapsulations RFCs etc). Very unrealistic... Why can't we do something simple like this: If I know what the LSP semantics are, then I enable load balancing on that LSP - with or with out hashing. With out hashing, I do simple round robin 1 to N scheduler (no state, nothing). Even weighted round robin also you can do. The semantics for that LSP can be: - don't worry about out-of-order packets (higher layers will take care of it) - don't worry about X in XoverMPLS - don't even look at it. - don't do ECMP if EXP bits are set etc etc... Why are you thinking that load balancing or ECMP is a router option. You can have it as per LSP option as well. Just like ECMP for per destination address/flow. When we know what we are doing then the problems will be minimal. Do you agree? -- Venkata. From owner-mpls@UU.NET Tue Jul 2 15:25:17 2002 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 ESMTP id PAA10261 for ; Tue, 2 Jul 2002 15:25:17 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvur24620 for ; Tue, 2 Jul 2002 19:26:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvur22505; Tue, 2 Jul 2002 19:25:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvur28761 for mpls-outgoing; Tue, 2 Jul 2002 19:24:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvur28738 for ; Tue, 2 Jul 2002 19:24: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 QQmvur02114 for ; Tue, 2 Jul 2002 19:24:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvur20794 for ; Tue, 2 Jul 2002 19:24:13 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmvur20774 for ; Tue, 2 Jul 2002 19:24:13 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17PTFu-0002Xs-00; Tue, 02 Jul 2002 20:24:06 +0100 Subject: RE: your mail From: Giles Heron To: "Naidu, Venkata" Cc: "'Vach Kompella'" , "Gibson, Mark" , mpls@UU.NET, "Gray, Eric" In-Reply-To: <39469E08BD83D411A3D900204840EC5576323C@vie-msgusr-01.dc.fore.com> References: <39469E08BD83D411A3D900204840EC5576323C@vie-msgusr-01.dc.fore.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 02 Jul 2002 20:24:07 +0000 Message-Id: <1025641447.1485.165.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2002-07-02 at 18:49, Naidu, Venkata wrote: > Vach, > > -> For ECMP, you have to look at least one label lower (or more > -> precisely, one layer higher). > > Why? It is very difficult to look at the payload of MPLS > packets the way the encapsulations are defined. > > So, a router trying to do load balancing have to know > the X in XoverMPLS (all the PPP exts, LLC encapsulations RFCs etc). > Very unrealistic... [rest snipped] To a router in the core "one layer higher" means the VC label (for the XoverMPLS case). This has MPLS label syntax so the router should be able to parse it :) Whilst to a router at the edge (i.e. on ingress) the X will be known. If there is only one label at the core then it is pretty much a given that you are doing IP over MPLS (the only exception I know to this only works with RSVP-TE assigned labels). In this case you can use standard IP load balancing techniques. Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Tue Jul 2 15:37:34 2002 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 ESMTP id PAA11076 for ; Tue, 2 Jul 2002 15:37:33 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvus24078 for ; Tue, 2 Jul 2002 19:38:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvus21963; Tue, 2 Jul 2002 19:37:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvus00379 for mpls-outgoing; Tue, 2 Jul 2002 19:37:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvus00369 for ; Tue, 2 Jul 2002 19:36: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 QQmvus10578 for ; Tue, 2 Jul 2002 19:35:30 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvus02093 for ; Tue, 2 Jul 2002 19:35:30 GMT Received: from zcars04e.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmvus02085 for ; Tue, 2 Jul 2002 19:35:29 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g62JXwQ27090; Tue, 2 Jul 2002 15:33:58 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 15:33:57 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C0476BBC7@zcard031.ca.nortel.com> From: "David Allan" To: "Naidu, Venkata" , Tissa Senevirathne , Heinrich.Hummel@icn.siemens.de, erosen@cisco.com, Shahram_Davari@pmc-sierra.com Cc: eosborne@cisco.com, george_s97@hotmail.com, scullptor@yahoo.com, mpls@UU.NET Subject: RE: AW: your mail Date: Tue, 2 Jul 2002 15:33:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C221FF.630D229C" 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_01C221FF.630D229C Content-Type: text/plain; charset="iso-8859-1" Lets be a bit more precise, in a converged network a test tool such as ICMP "SHOULD" follow the same path as the traffic. Dave > -----Original Message----- > From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com] > Sent: Tuesday, July 02, 2002 2:26 PM > To: Allan, David [CAR:NS00:EXCH]; Tissa Senevirathne; > Heinrich.Hummel@icn.siemens.de; erosen@cisco.com; > Shahram_Davari@pmc-sierra.com > Cc: eosborne@cisco.com; george_s97@hotmail.com; scullptor@yahoo.com; > mpls@UU.NET > Subject: RE: AW: your mail > > > Dave, > > -> Similarly any path test tool (e.g. ICMP) must follow the > same path as the > traffic. > ^^^^ > > Not true. One can't guarantee that behavior in IP routing. > > -- > Venkata > ------_=_NextPart_001_01C221FF.630D229C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AW: your mail

Lets be a bit more precise, in a converged network a = test tool such as ICMP "SHOULD" follow the same path as the = traffic.

Dave

> -----Original Message-----
> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.c= om]
> Sent: Tuesday, July 02, 2002 2:26 PM
> To: Allan, David [CAR:NS00:EXCH]; Tissa = Senevirathne;
> Heinrich.Hummel@icn.siemens.de; = erosen@cisco.com;
> Shahram_Davari@pmc-sierra.com
> Cc: eosborne@cisco.com; george_s97@hotmail.com; = scullptor@yahoo.com;
> mpls@UU.NET
> Subject: RE: AW: your mail
>
>
> Dave,
>
> -> Similarly any path test tool (e.g. ICMP) = must follow the
> same path as the
> traffic.
>          = ;            = ;            = ;           = ^^^^
>
>   Not true. One can't guarantee that = behavior in IP routing.
>
> --
> Venkata
>

------_=_NextPart_001_01C221FF.630D229C-- From owner-mpls@UU.NET Tue Jul 2 15:40:18 2002 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 ESMTP id PAA11279 for ; Tue, 2 Jul 2002 15:40:17 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvus09072 for ; Tue, 2 Jul 2002 19:41:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvus06551; Tue, 2 Jul 2002 19:39:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvus00449 for mpls-outgoing; Tue, 2 Jul 2002 19:39:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvus00436 for ; Tue, 2 Jul 2002 19:38: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 QQmvus14565 for ; Tue, 2 Jul 2002 19:36:55 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvus21611 for ; Tue, 2 Jul 2002 19:36:55 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmvus21606 for ; Tue, 2 Jul 2002 19:36:55 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 15:36:55 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267100@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Eric Osborne'" Cc: "Gray, Eric" , "'MPLS Mailing list'" Subject: RE: your mail Date: Tue, 2 Jul 2002 15:36:52 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA11279 Eric, To answer your final two questions, yes it probably is stealing. The fact that you can get away with a crime does not make it any less a crime. Who knows, some vendors may not check that the protocol over the top of IP is either UDP or TCP before using the port numbers. I think you can easily imagine what that might lead to if a set of packets carry a higher level protocol where the corresponding fields may vary from packet to packet in a single micro-flow. The real question is how common is this? Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Eric Osborne [mailto:eosborne@cisco.com] Sent: Tuesday, July 02, 2002 1:32 PM To: Hummel Heinrich Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET Subject: Re: your mail On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > It gets weirder and weirder: The MPLS WG invents a label stack, but does not care at all that any of the > deeper nested labels may ever be signalled/carried by means of a Label-TLV/object (no public comments to my > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > However it is ok, to "steal" the deepest nested label and call it "VC-label" for indexing > some VRF at some remote PE. This is not theft; it's using the labels as they were designed. How is using the bottommost label as a VC-labe/VPN label/whatever "stealing"? You seem to be attacking the very idea of label stacking, which is a pretty useful concept. > Furthermore it is ok, to "steal" the very same label for hashing. > What about IP router vendors that do load-balancing based on L4/L5 information like protocol type and port numbers? Is that stealing? eric > Independent from what is clean and what is quick&dirty, I cannot detect any sense in giving a hash-meaning to the bottom label at all. > > > > Heinrich Hummel > Siemens > > -----Ursprüngliche Nachricht----- > Von: Eric Rosen [mailto:erosen@cisco.com] > Gesendet: Dienstag, 2. Juli 2002 16:06 > An: Shahram Davari > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > Betreff: Re: your mail > > > Shahram> To do ECMP, you need to assign hashed values to egress ports. This > Shahram> assignment is the hash state that I said you need. > > A hash is a function that maps some sequence of octets into a sequence of > integers. If you want to split traffic over six paths, while ensuring that > all packets with the same bottom label travel the same path, you need a > function that maps a 20 bit quantity into a number from 1-6. There is no > need to maintain state of any kind. From owner-mpls@UU.NET Tue Jul 2 15:55:21 2002 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 ESMTP id PAA12159 for ; Tue, 2 Jul 2002 15:55:20 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvut13753 for ; Tue, 2 Jul 2002 19:56:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvut11478; Tue, 2 Jul 2002 19:55:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvut01888 for mpls-outgoing; Tue, 2 Jul 2002 19:54:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvut01881 for ; Tue, 2 Jul 2002 19:54: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 QQmvut08698 for ; Tue, 2 Jul 2002 19:53:33 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvut09615 for ; Tue, 2 Jul 2002 19:53:33 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f90.law12.hotmail.com [64.4.19.90]) id QQmvut09611 for ; Tue, 2 Jul 2002 19:53:32 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Jul 2002 12:53:32 -0700 Received: from 155.53.36.107 by lw12fd.law12.hotmail.msn.com with HTTP; Tue, 02 Jul 2002 19:53:30 GMT X-Originating-IP: [155.53.36.107] From: "George Sheng" To: giles@packetexchange.net, Venkata.Naidu@Marconi.com Cc: vkompella@timetra.com, mgibson@orchestream.com, mpls@UU.NET, egray@celoxnetworks.com Subject: RE: your mail Date: Tue, 02 Jul 2002 19:53:30 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jul 2002 19:53:32.0051 (UTC) FILETIME=[24AECE30:01C22202] Sender: owner-mpls@UU.NET Precedence: bulk > >If there is only one label at the core then it is pretty much a given >that you are doing IP over MPLS (the only exception I know to this only >works with RSVP-TE assigned labels). In this case you can use standard >IP load balancing techniques. > >Giles You could have hashed on this top label, which basically give you the loadsharing granularity of ebgp peering nexthops in the case of LDP(prefix label scheme). This sounds more natural for a LSR. -george _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-mpls@UU.NET Tue Jul 2 16:17:44 2002 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 ESMTP id QAA13105 for ; Tue, 2 Jul 2002 16:17:44 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuv01659 for ; Tue, 2 Jul 2002 20:18:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuv00005; Tue, 2 Jul 2002 20:17:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuv26680 for mpls-outgoing; Tue, 2 Jul 2002 20:17:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvuv26672 for ; Tue, 2 Jul 2002 20:17: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 QQmvuv15006 for ; Tue, 2 Jul 2002 20:16:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuv28794 for ; Tue, 2 Jul 2002 20:16:07 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmvuv28770 for ; Tue, 2 Jul 2002 20:16:07 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17PU3x-0002fT-00; Tue, 02 Jul 2002 21:15:49 +0100 Subject: RE: your mail From: Giles Heron To: George Sheng Cc: Venkata.Naidu@Marconi.com, vkompella@timetra.com, mgibson@orchestream.com, mpls@UU.NET, egray@celoxnetworks.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 02 Jul 2002 21:15:49 +0000 Message-Id: <1025644549.1689.23.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA13105 On Tue, 2002-07-02 at 19:53, George Sheng wrote: > > > > > > >If there is only one label at the core then it is pretty much a given > >that you are doing IP over MPLS (the only exception I know to this only > >works with RSVP-TE assigned labels). In this case you can use standard > >IP load balancing techniques. > > > >Giles > > You could have hashed on this top label, which basically give you > the loadsharing granularity of ebgp peering nexthops in the case > of LDP(prefix label scheme). This sounds more natural for a LSR. Hi George, my mail was explaining why "one layer higher" wasn't a problem for load balancing in MPLS - I wasn't suggesting that IP load balancing was necessarily a better choice for IP/MPLS than load balancing on the top label. However, whilst hashing on the top label will work in the core, it doesn't give you anything at the penultimate hop (or at least not in the usual case where you advertise one /32 address prefix FEC for each PE, and have "next-hop self" turned on for your iBGP peering sessions). I suspect many SPs will not wish to inject external links into their IGPs, and advertise a FEC for each such link - even if this gives them better architectural purity for their load balancing than using IP load balancing in MPLS ;-) For SPs who don't want to inject external links into their IGP one other valid option would presumably be to use MP-iBGP so that there is a label for every route - this label could map to the egress interface for example. However that would add 4 bytes to every packet in your network for seemingly marginal benefit? Giles > > -george > > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Tue Jul 2 16:31:08 2002 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 ESMTP id QAA13571 for ; Tue, 2 Jul 2002 16:31:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuw12337 for ; Tue, 2 Jul 2002 20:31:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuv04145; Tue, 2 Jul 2002 20:27:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuv27309 for mpls-outgoing; Tue, 2 Jul 2002 20:26:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvuv27302 for ; Tue, 2 Jul 2002 20:26:44 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 QQmvuv21136 for ; Tue, 2 Jul 2002 20:26:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuv03423 for ; Tue, 2 Jul 2002 20:26:08 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuv03414 for ; Tue, 2 Jul 2002 20:26:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA23771 for ; Tue, 2 Jul 2002 16:26:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA10789 for mpls@uu.net; Tue, 2 Jul 2002 16:26:07 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvuv27195 for ; Tue, 2 Jul 2002 20:24:54 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 QQmvuv29901 for ; Tue, 2 Jul 2002 20:23:42 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuv02402 for ; Tue, 2 Jul 2002 20:23:42 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuv02397 for ; Tue, 2 Jul 2002 20:23:42 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA23562; Tue, 2 Jul 2002 16:23:41 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA06157; Tue, 2 Jul 2002 16:23:41 -0400 (EDT) Date: Tue, 2 Jul 2002 16:23:41 -0400 From: Eric Osborne To: "Gray, Eric" Cc: "'Eric Osborne'" , "'MPLS Mailing list'" Subject: Re: your mail Message-ID: <20020702202341.GB4101@eosborne-u10.cisco.com> References: <1117F7D44159934FB116E36F4ABF221B02267100@celox-ma1-ems1.celoxnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1117F7D44159934FB116E36F4ABF221B02267100@celox-ma1-ems1.celoxnetworks.com> User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > Eric, > > To answer your final two questions, yes it probably > is stealing. The fact that you can get away with a crime > does not make it any less a crime. Who knows, some vendors > may not check that the protocol over the top of IP is either > UDP or TCP before using the port numbers. If a vendor checks the offset where the port numbers should be without checking for the correct protocol type, this is a cruddy implementation and shouldn't exist. My question was really along the lines of "what if we use the values that we *know* are UDP/TCP port numbers"? From what you say above, it seems like that might be OK, as long as we only do this when we're sure? Or is there some inherent architectual layer violation thing that you're objecting to? eric > I think you can > easily imagine what that might lead to if a set of packets > carry a higher level protocol where the corresponding fields > may vary from packet to packet in a single micro-flow. The > real question is how common is this? > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Tuesday, July 02, 2002 1:32 PM > To: Hummel Heinrich > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George Sheng; > scullptor@yahoo.com; mpls@UU.NET > Subject: Re: your mail > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > It gets weirder and weirder: The MPLS WG invents a label stack, but does > not care at all that any of the > > deeper nested labels may ever be signalled/carried by means of a > Label-TLV/object (no public comments to my > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > However it is ok, to "steal" the deepest nested label and call it > "VC-label" for indexing > > some VRF at some remote PE. > > This is not theft; it's using the labels as they were designed. How > is using the bottommost label as a VC-labe/VPN label/whatever > "stealing"? You seem to be attacking the very idea of label stacking, > which is a pretty useful concept. > > > Furthermore it is ok, to "steal" the very same label for hashing. > > > > What about IP router vendors that do load-balancing based on L4/L5 > information like protocol type and port numbers? Is that stealing? > > > > > eric > > > Independent from what is clean and what is quick&dirty, I cannot detect > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > Heinrich Hummel > > Siemens > > > > -----Ursprüngliche Nachricht----- > > Von: Eric Rosen [mailto:erosen@cisco.com] > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > An: Shahram Davari > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > Betreff: Re: your mail > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress ports. > This > > Shahram> assignment is the hash state that I said you need. > > > > A hash is a function that maps some sequence of octets into a sequence > of > > integers. If you want to split traffic over six paths, while ensuring > that > > all packets with the same bottom label travel the same path, you need > a > > function that maps a 20 bit quantity into a number from 1-6. There is > no > > need to maintain state of any kind. From owner-mpls@UU.NET Tue Jul 2 16:37:30 2002 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 ESMTP id QAA13846 for ; Tue, 2 Jul 2002 16:37:29 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuw13246 for ; Tue, 2 Jul 2002 20:38:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuw10212; Tue, 2 Jul 2002 20:36:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuw28348 for mpls-outgoing; Tue, 2 Jul 2002 20:36:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvuw28334 for ; Tue, 2 Jul 2002 20:36:26 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 QQmvuw27515 for ; Tue, 2 Jul 2002 20:35:51 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuw18364 for ; Tue, 2 Jul 2002 20:35:51 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f230.law12.hotmail.com [64.4.19.230]) id QQmvuw18351 for ; Tue, 2 Jul 2002 20:35:50 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Jul 2002 13:35:50 -0700 Received: from 155.53.36.107 by lw12fd.law12.hotmail.msn.com with HTTP; Tue, 02 Jul 2002 20:35:49 GMT X-Originating-IP: [155.53.36.107] From: "George Sheng" To: giles@packetexchange.net Cc: Venkata.Naidu@Marconi.com, vkompella@timetra.com, mgibson@orchestream.com, mpls@UU.NET, egray@celoxnetworks.com Subject: RE: your mail Date: Tue, 02 Jul 2002 20:35:49 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jul 2002 20:35:50.0157 (UTC) FILETIME=[0D830BD0:01C22208] Sender: owner-mpls@UU.NET Precedence: bulk Hi Giles, > > > > You could have hashed on this top label, which basically give you > > the loadsharing granularity of ebgp peering nexthops in the case > > of LDP(prefix label scheme). This sounds more natural for a LSR. > >Hi George, > >my mail was explaining why "one layer higher" wasn't a problem for load >balancing in MPLS - I wasn't suggesting that IP load balancing was >necessarily a better choice for IP/MPLS than load balancing on the top >label. understood. > >However, whilst hashing on the top label will work in the core, it >doesn't give you anything at the penultimate hop (or at least not in the >usual case where you advertise one /32 address prefix FEC for each PE, >and have "next-hop self" turned on for your iBGP peering sessions). I >suspect many SPs will not wish to inject external links into their IGPs, >and advertise a FEC for each such link - even if this gives them better >architectural purity for their load balancing than using IP load >balancing in MPLS ;-) it does not have to be network of "external" links. an ebgp router can optionally announce N loopback /32 addresses and use them as nexthops for their ibgp peers. depends the the network topology, it usually is needed only on the ebgp routers which have parallel links. > >For SPs who don't want to inject external links into their IGP one other >valid option would presumably be to use MP-iBGP so that there is a label >for every route - this label could map to the egress interface for >example. However that would add 4 bytes to every packet in your network >for seemingly marginal benefit? i think that's overkill, i'd rather hashing on the payload. thx. > >Giles > -george _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-mpls@UU.NET Tue Jul 2 16:40:06 2002 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 ESMTP id QAA13954 for ; Tue, 2 Jul 2002 16:40:05 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuw22892 for ; Tue, 2 Jul 2002 20:40:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuw20684; Tue, 2 Jul 2002 20:39:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuw28505 for mpls-outgoing; Tue, 2 Jul 2002 20:39:20 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvuw28479 for ; Tue, 2 Jul 2002 20:39: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 QQmvuw04941 for ; Tue, 2 Jul 2002 20:39:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuw20217 for ; Tue, 2 Jul 2002 20:39:10 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmvuw20211 for ; Tue, 2 Jul 2002 20:39:09 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17PUQQ-0002iY-00; Tue, 02 Jul 2002 21:39:02 +0100 Subject: RE: your mail From: Giles Heron To: George Sheng Cc: Venkata.Naidu@Marconi.com, vkompella@timetra.com, mgibson@orchestream.com, mpls@UU.NET, egray@celoxnetworks.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 02 Jul 2002 20:39:44 +0000 Message-Id: <1025642384.1689.43.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA13954 On Tue, 2002-07-02 at 20:35, George Sheng wrote: > >However, whilst hashing on the top label will work in the core, it > >doesn't give you anything at the penultimate hop (or at least not in the > >usual case where you advertise one /32 address prefix FEC for each PE, > >and have "next-hop self" turned on for your iBGP peering sessions). I > >suspect many SPs will not wish to inject external links into their IGPs, > >and advertise a FEC for each such link - even if this gives them better > >architectural purity for their load balancing than using IP load > >balancing in MPLS ;-) > > it does not have to be network of "external" links. an ebgp router > can optionally announce N loopback /32 addresses and use them as > nexthops for their ibgp peers. depends the the network topology, > it usually is needed only on the ebgp routers which have parallel > links. agreed. But this still adds prefixes to your IGP and FECs to LDP :( > >For SPs who don't want to inject external links into their IGP one other > >valid option would presumably be to use MP-iBGP so that there is a label > >for every route - this label could map to the egress interface for > >example. However that would add 4 bytes to every packet in your network > >for seemingly marginal benefit? > > i think that's overkill, i'd rather hashing on the payload. I hoped you'd say that! Giles > > thx. > > > >Giles > > > > -george > > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Tue Jul 2 16:40:33 2002 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 ESMTP id QAA13982 for ; Tue, 2 Jul 2002 16:40:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuw20347 for ; Tue, 2 Jul 2002 20:41:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuw17589; Tue, 2 Jul 2002 20:39:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuw28508 for mpls-outgoing; Tue, 2 Jul 2002 20:39:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvuw28494 for ; Tue, 2 Jul 2002 20:39: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 QQmvuw16387 for ; Tue, 2 Jul 2002 20:38:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuw14196 for ; Tue, 2 Jul 2002 20:38:38 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmvuw13781 for ; Tue, 2 Jul 2002 20:38:26 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 16:38:25 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267103@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Eric Osborne'" , "Gray, Eric" Cc: "'MPLS Mailing list'" Subject: RE: your mail Date: Tue, 2 Jul 2002 16:38:15 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA13982 Eric, It is in the fact that we have to be sure - just as you suggest. The cost of being sure, however, is that you have to be prepared to deal with occasions when the check fails. What do you do when the higher layer is not UDP or TCP - throw these packets in to a common bucket? What is the expected impact if this traffic might occasionally be significant? Eric W. Gray -----Original Message----- From: Eric Osborne [mailto:eosborne@cisco.com] Sent: Tuesday, July 02, 2002 4:24 PM To: Gray, Eric Cc: 'Eric Osborne'; 'MPLS Mailing list' Subject: Re: your mail On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > Eric, > > To answer your final two questions, yes it probably > is stealing. The fact that you can get away with a crime > does not make it any less a crime. Who knows, some vendors > may not check that the protocol over the top of IP is either > UDP or TCP before using the port numbers. If a vendor checks the offset where the port numbers should be without checking for the correct protocol type, this is a cruddy implementation and shouldn't exist. My question was really along the lines of "what if we use the values that we *know* are UDP/TCP port numbers"? From what you say above, it seems like that might be OK, as long as we only do this when we're sure? Or is there some inherent architectual layer violation thing that you're objecting to? eric > I think you can > easily imagine what that might lead to if a set of packets > carry a higher level protocol where the corresponding fields > may vary from packet to packet in a single micro-flow. The > real question is how common is this? > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Tuesday, July 02, 2002 1:32 PM > To: Hummel Heinrich > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George Sheng; > scullptor@yahoo.com; mpls@UU.NET > Subject: Re: your mail > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > It gets weirder and weirder: The MPLS WG invents a label stack, but does > not care at all that any of the > > deeper nested labels may ever be signalled/carried by means of a > Label-TLV/object (no public comments to my > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > However it is ok, to "steal" the deepest nested label and call it > "VC-label" for indexing > > some VRF at some remote PE. > > This is not theft; it's using the labels as they were designed. How > is using the bottommost label as a VC-labe/VPN label/whatever > "stealing"? You seem to be attacking the very idea of label stacking, > which is a pretty useful concept. > > > Furthermore it is ok, to "steal" the very same label for hashing. > > > > What about IP router vendors that do load-balancing based on L4/L5 > information like protocol type and port numbers? Is that stealing? > > > > > eric > > > Independent from what is clean and what is quick&dirty, I cannot detect > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > Heinrich Hummel > > Siemens > > > > -----Ursprüngliche Nachricht----- > > Von: Eric Rosen [mailto:erosen@cisco.com] > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > An: Shahram Davari > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > Betreff: Re: your mail > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress ports. > This > > Shahram> assignment is the hash state that I said you need. > > > > A hash is a function that maps some sequence of octets into a sequence > of > > integers. If you want to split traffic over six paths, while ensuring > that > > all packets with the same bottom label travel the same path, you need > a > > function that maps a 20 bit quantity into a number from 1-6. There is > no > > need to maintain state of any kind. From owner-mpls@UU.NET Tue Jul 2 16:45:46 2002 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 ESMTP id QAA14422 for ; Tue, 2 Jul 2002 16:45:45 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvux00222 for ; Tue, 2 Jul 2002 20:46:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuw27208; Tue, 2 Jul 2002 20:44:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuw28995 for mpls-outgoing; Tue, 2 Jul 2002 20:44:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvuw28943 for ; Tue, 2 Jul 2002 20:44: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 QQmvuw28369 for ; Tue, 2 Jul 2002 20:44:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuw26012 for ; Tue, 2 Jul 2002 20:44:05 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuw25987 for ; Tue, 2 Jul 2002 20:44:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA25108 for ; Tue, 2 Jul 2002 16:44:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA14512 for mpls@uu.net; Tue, 2 Jul 2002 16:44:03 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvuw28812 for ; Tue, 2 Jul 2002 20: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 QQmvuw10402 for ; Tue, 2 Jul 2002 20:41:50 GMT 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 QQmvus23130 for ; Tue, 2 Jul 2002 19:37:51 GMT Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g62Jblx09781 for ; Tue, 2 Jul 2002 15:37:47 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 20:37:46 +0100 Message-ID: <17BA7A412C4FD311A4B700508B0291AE098B53F6@uk0006exch004u.uk.lucent.com> From: "Mannerstam, David (David)" To: mpls@UU.NET Date: Tue, 2 Jul 2002 20:37:45 +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 owner-mpls@UU.NET Tue Jul 2 16:46:20 2002 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 ESMTP id QAA14472 for ; Tue, 2 Jul 2002 16:46:20 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvux26859 for ; Tue, 2 Jul 2002 20:47:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvux24338; Tue, 2 Jul 2002 20:45:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvux29331 for mpls-outgoing; Tue, 2 Jul 2002 20:45:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvux29269 for ; Tue, 2 Jul 2002 20:45:07 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 QQmvux04614 for ; Tue, 2 Jul 2002 20:45:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvux27506 for ; Tue, 2 Jul 2002 20:45:01 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvux27469 for ; Tue, 2 Jul 2002 20:45:00 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA25172; Tue, 2 Jul 2002 16:44:59 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA14539; Tue, 2 Jul 2002 16:44:59 -0400 (EDT) Message-Id: <200207022044.QAA14539@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Hummel Heinrich cc: "Kai A. Scharwacht" , mpls@UU.NET Subject: Re: AW: your mail In-reply-to: Your message of Tue, 02 Jul 2002 18:12:17 +0200. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Jul 2002 16:44:59 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Heinrich> But still see my email referring to multicast. You cannot kill Heinrich> multicast by doing anycast. Just to clear this up: you can always tell by the label whether a particular packet is a multicast packet or a unicast packet. Thus, if the label lookup gives you more than one route, there is never any confusion about whether you are supposed to multicast the packet over all those routes, or whether you are supposed to choose one over which to unicast the packet. From owner-mpls@UU.NET Tue Jul 2 17:10:48 2002 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 ESMTP id RAA15825 for ; Tue, 2 Jul 2002 17:10:48 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuy16232 for ; Tue, 2 Jul 2002 21:11:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvuy10636; Tue, 2 Jul 2002 21:08:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvuy22602 for mpls-outgoing; Tue, 2 Jul 2002 21:07:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvuy22196 for ; Tue, 2 Jul 2002 21:07: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 QQmvuy04095 for ; Tue, 2 Jul 2002 21:07:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvuy14875 for ; Tue, 2 Jul 2002 21:07:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuy14865 for ; Tue, 2 Jul 2002 21:07:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA26791 for ; Tue, 2 Jul 2002 17:07:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA18553 for mpls@uu.net; Tue, 2 Jul 2002 17:07:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvuy15680 for ; Tue, 2 Jul 2002 21:05: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 QQmvuy03217 for ; Tue, 2 Jul 2002 21:05:22 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvuv05390 for ; Tue, 2 Jul 2002 20:27:46 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA23887; Tue, 2 Jul 2002 16:27:44 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA06167; Tue, 2 Jul 2002 16:27:44 -0400 (EDT) Date: Tue, 2 Jul 2002 16:27:44 -0400 From: Eric Osborne To: neil.2.harrison@bt.com Cc: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: Re: your mail Message-ID: <20020702202744.GC4101@eosborne-u10.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk > > "absolute addressing information", to me, sounds like "enough > > addressing information to get the packet to its final destination, > > i.e. an end station". Right? If so, wouldn't that be true for cases > > like IPinIP when the IP core doesn't know about addresses at the IP > > edge (a la gre tunnels)? Or do you mean something else? > NH=> No, this is precisely what I mean. Within the constraint of a given > routing domain, cnls forwarding must use unique addressing. When I say > 'absolute' addressing I mean its unique wrt to the whole routing domain and > not a single hop within it.....when I say 'relative' addressing its only > unique to an interface (like case of labels, VPI/VCI or DLCIs) which is the > normal mode of stringing together a set of hops (=link-connections) to > create a co trail (though the trail termination points must have absolute > addressing). Further, and although it might not be immediately obvious why > its relevent here, when one creates trails via concatenated relatively > addressed link-connections the pkts alone cannot convey all the required > QoS/survivability attributes (as they have to in a cnls mode)......you have > to take pkts_+_parent_trail into account, and its the trail entity that is > the key/primary focus for proper fault-management. Hope that helps clear up > what I mean. So a few things have happened in this thread. It started off, if I recall, with a statement about "LDP's inability to TE". It then went into hashing and other such stuff. And it appears like it's also touching on OAM. I am familiar with the OAM discussion; it's happened a few times already, as you know. So rather than going down that path again, let me ask a question (particularly to you and Sharam) - is there anything wrong with hashing for loadsharing purposes *other* than the fact that it makes doing OAM the way you've proposed difficult, if not impossible? eric > > > > I also don't see how this turns into a "connectivity verification > > function". What about an IP packet (or IPinIP) inherently has more > > verification than IPinMPLS? > NH=> They are fundamentally different. An IP address means something to the > whole of its routing domain. A label only means something to an interface > (or at largest a node....though a few labels have been globally reserved for > specific/network-wide functions, eg null labels). So if an IP pkt ends up > in the wrong place it will (usually) get re-directed back on > course....however, if a labelled pkt ends up in the wrong place it may be > showing a valid label for its next hop and get misdirected (or if not it > will get immediately black-holed....and it will usually get black-holed at > some higher levels when labels fail to match anymore or, if it makes to the > the client level, than at this highest LSP->clinet adaptation point). So we > can get (and have seen) misrouting defects because the same labels are used > on different/disjoint hops. > > > And isn't this turning into an OAM > > discussion again, rather than talking about loadsharing? > NH=> Well, fault-management is fundamentally important to us > operators....and if you fail to get this key-stone right then whatever > follows will not have a good foundation. Loadsharing is one by-product of > using LDP because there is no felxibility in routing choice.....but its not > the only by-product of LDP. > > > > > I'm not sure I buy into the argument that the co paradigm is the only > > way to do stuff like qos/survivability/etc. Granted, you are far more > > a co-paradigm guy than I am, so you know this area better, but I > > suspect that means you're walking around with a co-paradigm-shaped > > hammer, looking for a nail. Of course, the same thing could be said > > about my connectionless bias, so really there's no easy way out, here. > NH=> Not at all....if that is your impression of what I said you have > completely misunderstood me. The main message I gave was this: > - true cnls = good for certain applications > - true p2p co = good for certain applications > They both have important roles and neither should be regarded as supplanting > the other. I believe we can do the vast majority of networks services with > both these modes. What I don't see however is a compelling reason for mp2p > LDP over the other modes. > > > > > But whatever the argument, isn't the same is true for IPinIP where the > > outer IP address is your PE (or whatever your term is) and the inner > > IP is relevant to your customer, right? > NH=>No....in both the operator and the customer routing domains the IP > addresses relevant to each are unique to the whole of each (disjoint) > routing domain. This is not true for labels, VPI/VCI, DLCI when these are > link-connection only unique. > > > > > Here, we need to introduce a signalling or NMS > > set-up/tear-down capability, > > > and the fundamantal networking concept is the *connection* > > itself, and the > > > fault/performance management of such is the critical piece. > > > > ah....OAM again...me and my ten-foot pole are going somewhere else > > now... > NH=> Where might that be LSP-PING perhaps?......same problem, just far more > complex attempt at solution. Seriously though, fault-management of networks > is really important to operators. > > > I guess the fundamental piece I'm still missing is that I don't see > > how LDP is any different from IP at the forwarding level. > NH=> IP uses memoryless best-match look-up and LDP uses pre-calculated paths > that have locally significant 'tags' applied to them (this is a co trait). > By definition these are subject to different failures modes....and I know > its the OAM stuff you don't like again but LDP data-plane forwarding has new > failure modes that don't exist in IP. Why else do you think some of your > colleagues are working on LSP-PING? Further, MPLS can carry protocols > other than IP....so this raises other aspects that need consideration (and > where fault-management solutions really need to client (and server) > agnostic). > > > I'm just trying to understand the basic objection to LDP, > > when the forwarding looks the same as IP. > NH=> And that is the crux of the point....it may *look* the same when its > working but it does not fail the same. > > And I don't mean the OAM > > side, but the loadsharing side; loadsharing is how we started this > > topic (I think), so I'd like to keep it there. > NH=> Load-sharing is only 1 aspect of MPLS/LDP they don't tell you about too > loudly about at sale time when explaining the 'simple' label-swapping > paradigm ;-)......and just focussing on this topic misses the bigger picture > anyway. You need to look at the whole space to draw meaningful conclusions. > > thanks and regards, Neil From owner-mpls@UU.NET Tue Jul 2 18:39:34 2002 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 ESMTP id SAA19925 for ; Tue, 2 Jul 2002 18:39:34 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvve20770 for ; Tue, 2 Jul 2002 22:40:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvve14299; Tue, 2 Jul 2002 22:36:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvve22380 for mpls-outgoing; Tue, 2 Jul 2002 22:36:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvve22321 for ; Tue, 2 Jul 2002 22:35:55 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 QQmvve20587 for ; Tue, 2 Jul 2002 22:34:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvve22644 for ; Tue, 2 Jul 2002 22:34:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvve22640 for ; Tue, 2 Jul 2002 22:34:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA02439 for ; Tue, 2 Jul 2002 18:34:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA28314 for mpls@uu.net; Tue, 2 Jul 2002 18:34:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvve22232 for ; Tue, 2 Jul 2002 22:33:07 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 QQmvve03662 for ; Tue, 2 Jul 2002 22:31:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvve22001 for ; Tue, 2 Jul 2002 22:31:26 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvve21994 for ; Tue, 2 Jul 2002 22:31:26 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA02243; Tue, 2 Jul 2002 18:31:25 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA06330; Tue, 2 Jul 2002 18:31:25 -0400 (EDT) Date: Tue, 2 Jul 2002 18:31:25 -0400 From: Eric Osborne To: "Gray, Eric" Cc: "'Eric Osborne'" , "'MPLS Mailing list'" Subject: Re: your mail Message-ID: <20020702223125.GH4101@eosborne-u10.cisco.com> References: <1117F7D44159934FB116E36F4ABF221B02267103@celox-ma1-ems1.celoxnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1117F7D44159934FB116E36F4ABF221B02267103@celox-ma1-ems1.celoxnetworks.com> User-Agent: Mutt/1.4i X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > Eric, > > It is in the fact that we have to be sure - > just as you suggest. The cost of being sure, however, > is that you have to be prepared to deal with occasions > when the check fails. What do you do when the higher > layer is not UDP or TCP - throw these packets in to a > common bucket? What is the expected impact if this > traffic might occasionally be significant? Then you need a better load-balancing algorithm. Either IP SA/DA and some randomness, or random sampling from the packet, or (heaven forbid) some sort of flow-based scheme. I'm even dubious about the efficacy of using TCP/UDP ports to hash, given that most traffic is either src or dst TCP port 80, which really only gives you the port in the other direction to play with. But that's not really my problem, as the implementation I'm familiar with doesn't do anything with TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a device that does; I just don't deal with it/them). also, don't forget that this hypothetical algorithm takes into acount IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you probably have very few flows/conversations/whatnot anyways, and either need to move to something like per-packet (ick) or just larger pipes. eric > > > Eric W. Gray > > > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Tuesday, July 02, 2002 4:24 PM > To: Gray, Eric > Cc: 'Eric Osborne'; 'MPLS Mailing list' > Subject: Re: your mail > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > Eric, > > > > To answer your final two questions, yes it probably > > is stealing. The fact that you can get away with a crime > > does not make it any less a crime. Who knows, some vendors > > may not check that the protocol over the top of IP is either > > UDP or TCP before using the port numbers. > > If a vendor checks the offset where the port numbers should be without > checking for the correct protocol type, this is a cruddy > implementation and shouldn't exist. My question was really along the > lines of "what if we use the values that we *know* are UDP/TCP port > numbers"? From what you say above, it seems like that might be OK, as > long as we only do this when we're sure? Or is there some inherent > architectual layer violation thing that you're objecting to? > > > > eric > > > I think you can > > easily imagine what that might lead to if a set of packets > > carry a higher level protocol where the corresponding fields > > may vary from packet to packet in a single micro-flow. The > > real question is how common is this? > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > -----Original Message----- > > From: Eric Osborne [mailto:eosborne@cisco.com] > > Sent: Tuesday, July 02, 2002 1:32 PM > > To: Hummel Heinrich > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George Sheng; > > scullptor@yahoo.com; mpls@UU.NET > > Subject: Re: your mail > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > It gets weirder and weirder: The MPLS WG invents a label stack, but > does > > not care at all that any of the > > > deeper nested labels may ever be signalled/carried by means of a > > Label-TLV/object (no public comments to my > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > However it is ok, to "steal" the deepest nested label and call it > > "VC-label" for indexing > > > some VRF at some remote PE. > > > > This is not theft; it's using the labels as they were designed. How > > is using the bottommost label as a VC-labe/VPN label/whatever > > "stealing"? You seem to be attacking the very idea of label stacking, > > which is a pretty useful concept. > > > > > Furthermore it is ok, to "steal" the very same label for hashing. > > > > > > > What about IP router vendors that do load-balancing based on L4/L5 > > information like protocol type and port numbers? Is that stealing? > > > > > > > > > > eric > > > > > Independent from what is clean and what is quick&dirty, I cannot detect > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > Heinrich Hummel > > > Siemens > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > An: Shahram Davari > > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > > Betreff: Re: your mail > > > > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress ports. > > This > > > Shahram> assignment is the hash state that I said you need. > > > > > > A hash is a function that maps some sequence of octets into a > sequence > > of > > > integers. If you want to split traffic over six paths, while ensuring > > that > > > all packets with the same bottom label travel the same path, you > need > > a > > > function that maps a 20 bit quantity into a number from 1-6. There > is > > no > > > need to maintain state of any kind. From owner-mpls@UU.NET Tue Jul 2 21:23:39 2002 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 ESMTP id VAA26796 for ; Tue, 2 Jul 2002 21:23:39 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvvp27786 for ; Wed, 3 Jul 2002 01:24:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvvp24937; Wed, 3 Jul 2002 01:22:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvvp11505 for mpls-outgoing; Wed, 3 Jul 2002 01:22:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvvp11500 for ; Wed, 3 Jul 2002 01:22:12 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 QQmvvp28884 for ; Wed, 3 Jul 2002 01:22:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvvp00664 for ; Wed, 3 Jul 2002 01:22:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvvp00654 for ; Wed, 3 Jul 2002 01:22:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA09812 for ; Tue, 2 Jul 2002 21:22:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id VAA15710 for mpls@uu.net; Tue, 2 Jul 2002 21:22:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvvp11479 for ; Wed, 3 Jul 2002 01:21:34 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 QQmvvp18055 for ; Wed, 3 Jul 2002 01:21:32 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvvp24193 for ; Wed, 3 Jul 2002 01:21:31 GMT Received: from hawk.CrescentNetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hawk.crescentnetworks.com [66.105.92.144]) id QQmvvp24176 for ; Wed, 3 Jul 2002 01:21:31 GMT Received: from crescentnetworks.com (jcucchiara.in.crescentnets.com [192.168.29.132]) by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id VAA13091; Tue, 2 Jul 2002 21:21:24 -0400 (EDT) Message-ID: <3D225251.72264126@crescentnetworks.com> Date: Tue, 02 Jul 2002 21:24:33 -0400 From: Joan Cucchiara Organization: Crescent Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chung, Li-Jin W, ALCNS" CC: mpls@UU.NET, "Ash, Gerald R (Jerry), ALASO" , "Nguyen, Mai-Uyen T, ALCNS" , "D'Souza, Kevin L, ALCNS" , "Lai, Wai S (Waisum), ALASO" Subject: Re: LDP-MIB & VPN-MIB References: <5F2B8267D7B55B47BDE2868D227BF50C06A660@OCCLUST01EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, "Chung, Li-Jin W, ALCNS" wrote: > > Joan, > > Thank you for your feedback. Please see my comments below. > > Thanks, > > Li Chung > > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com] > Sent: Thursday, June 27, 2002 8:49 PM > To: Chung, Li-Jin W, ALCNS > Cc: mpls@UU.NET; Ash, Gerald R (Jerry), ALASO; Nguyen, Mai-Uyen T, > ALCNS; D'Souza, Kevin L, ALCNS; Lai, Wai S (Waisum), ALASO > Subject: Re: LDP-MIB & VPN-MIB > > Hello, > > "Chung, Li-Jin W, ALCNS" wrote: > > > > Hi., > > > > I am new to this list. So, if what I say here has been addressed by > other means please let me know. > > Recently, I have studied draft-ietf-mpls-ldp-mib-08 and > draft-ietf-ppvpn-mpls-vpn-mib-03 and have identified some potential > enhancement areas for our future considerations. I would like to get > your feedback if these areas of observations make sense to you. > > > > In the LDP-MIB, > > (1) The variables in the following two notifications do not have the > information related to the IfIndex in the IF-MIB, this will prolong the > proactive fault management cycle time for operators. > > 1. mplsLdpSessionUp & > > 2. mplsLdpSessionDown > > > > I would like to suggest to include "mplsLdpConfGenericIfIndexOrZero" > or equivalent of such variable in the notification object. > > The mplsLdpEntityLdpId, mplsLdpEntityIndex, and mplsLdpPeerLdpId > (which are included) would give an operator a clear indication of which > port. Operators would be creating Entities on each LSR and > assign the LDP Identifiers, so in this specific case they would > have created the Entity (and assigned the mplsLdpEntityLdpId) and the > Peer (and assigned the mplsLdpPeerLdpId), so they should have the info > needed. > > * from Li: > * A few observations of your suggestions: > * (1) The above suggested variables are not in the notification > spec. today. So, you and I would agree that some more variables need to > be added to the notification. Since these are indices (mplsLdpEntityLdpId, mplsLdpEntityIndex and mplsLdpPeerId) these are part of the varbind and are available in the notification. > * (2) If there are multiple L2 interfaces between two peers that > running LDP, we need to know which physical interface that causes the > LDP session down/up trap. The above three variables does not provide > specific physical interface information. The logical interface > information is useful but they are more difficult for the operator to > perform troubleshooting. > * (3) Based on the description/definition of the above variables, > none of them has any indication of association with IfIndex in the > If-MIB. And, IfIndex in the If-MIB will be one object which could > provide the mapping between the Physical Interface and logical interface > of LDP entity. That is why I would suggest to add IfIndex/IfDescr > variable in the notification message. For the points 2 and 3 above, you are asking for the ifIndex then of the phy layer, is that correct? This information should already be at the NMS (assuming the NMS is monitoring the device), so why does it need to be included in the notification? In other words, there is the age-old tradeoff between the agent doing this work or the NMS doing it. (In my opinion this is a discussion for the mibs email list -- rather than the MPLS email list). > > > > (2) There is no specification on how to retain the counters when an > LDP-entity/session is broken and then reestablished again. Because of > such, some implemenation will remove the entire entry statistics when an > LDP-session is broken and when the same session is re-established again > the counter will be treated as a new counter. Some accumulation of such > old and new counters need to be specified. > > There are 2 tables of counters. > > The first table of counters, mplsLdpEntityStatsTable, contain counters > of an Entity because these are counters which are received when a > session > is attempted/initializing. These counters will help determine whether > or not the > session ever gets established. These counters do not have a > discontinuity > time associated with them because seeing these is an indication that the > Session is not being established. So, in other words, if you see these > counters increasing, that could be an indication that something is > misconfigured > with the corresponding Entity. If you don't see a Session being > established on > this entity, then these counters are meant to help figure out why. > > from Li: > * How? One possible implementation of such MIB (since one vendor > implement such way) is that when a session is established then went > down, all records related to this "down" session are removed. These > include: all objects in the mplsLdpEntityStatsTable as well as all > objects in the mplsLdpSesStatsTable are removed from the statistics. > When the same session is re-established again, it assigns to another > session number (the next session number in sequence), so from the > session number perspective in the LDP-MIB report, it is a brand new > session and has no knowledge/linkage that this new session number is > associated with an OLD session number. So, your suggestion of the above > "help figure out why" does not really work in such implementation. I am > looking for a way in the MIB to insure such linkage is guaranteed. > Otherwise, the above two statistics table does not provide meaningful > information from my perspective. I don't understand what you mean by "removed". An Entity contains all the config info for a session. The peer table represents the peer to that session and the session table gives you the state and other relevant info learned as the session is negotiated and established. The counters in the mplsLdpEntityStatsTable are errors which denote that the Entity might be misconfigured because the Peer and Entity aren't able to establish the session (at this point there might NOT be any entry in the mplsLdpSessionTable for the session.) Once the session is able to be established (and appears in the mplsLdpSessionTable, a corresponding entry will also appear in the mplsLdpSesStatsTable (note the AUGMENTS relationship). These counters are tied to the discontinuity object which is updated when the session is interrupted (e.g. goes down). This was modeled somewhat after the ifDiscontinuity object in the IF-MIB. > * A suggested linkage is to add IfIndex on top of the Peering > entry in the session index. So it will provide a more "solid" mapping > relationship. Which IfIndex? (What is the ifType that this ifIndex corresponds to?) > * Another suggestion is to find a way not to remove the OLD > session statistics when a session goes down so we are able to "figure > out why". > > The second table of counters, mplsLdpSesStatsTable, contain > counters on a session. These counters may have a discontinuity (i.e. > session up/down) > but that is noted in the mplsLdpSesDiscontinuityTime object which > corresponds to the entry. > * from Li: > * Please see my comment above. If you are asking about having a sort of history table, that would be one way to accomplish what you want, but am not sure this is very meaningful. At any rate, it is outside the scope of the LDP MIB. Although, could certainly be added in subsequent document/MIB module. -thanks, Joan > > Li Chung > > Hope that help, > -Joan > > > > > In the VPN-MIB, > > > > (1) Although there is a notification of VRF maximum route threshold > exceeded, there is no counter of number of routes dropped due to such > threshold exceeds. I would like to suggest to add a counter of such > dropped routes for capacity planning and for threshold tunning. > > > > (2) From what I can tell, in the route target table, there is no > mapping for the associated RD. I would like to suggest to add such > association between VRF, RD and RT in the RT table. > > > > Please let me know if you have any comments. > > > > Thanks, > > > > Li Chung From owner-mpls@UU.NET Tue Jul 2 21:48:45 2002 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 ESMTP id VAA27929 for ; Tue, 2 Jul 2002 21:48:44 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvvr00102 for ; Wed, 3 Jul 2002 01:49:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvvr26894; Wed, 3 Jul 2002 01:48:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvvr13582 for mpls-outgoing; Wed, 3 Jul 2002 01:47:47 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvvr13577 for ; Wed, 3 Jul 2002 01:47: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 QQmvvr16768 for ; Wed, 3 Jul 2002 01:47:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvvr11780 for ; Wed, 3 Jul 2002 01:47:31 GMT Received: from dnsmx2pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQmvvr11776 for ; Wed, 3 Jul 2002 01:47:31 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id VAA05488 for ; Tue, 2 Jul 2002 21:45:36 -0400 (EDT) Subject: What is the bad tspec? To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Tue, 2 Jul 2002 21:45:35 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 07/02/2002 09:45:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, What is the unreasonable request for triggering bad Tspec? If I set the token bucket rate very large, it will send back the patherr msg with 'Requested bandwidth unavailable', it will not send the bad tspec. Thanks, Julia From owner-mpls@UU.NET Wed Jul 3 00:41:49 2002 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 ESMTP id AAA04186 for ; Wed, 3 Jul 2002 00:41:49 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvwc21487 for ; Wed, 3 Jul 2002 04:42:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvwc18472; Wed, 3 Jul 2002 04:41:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvwc02740 for mpls-outgoing; Wed, 3 Jul 2002 04:40:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvwc02735 for ; Wed, 3 Jul 2002 04:40: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 QQmvwc13379 for ; Wed, 3 Jul 2002 04:40:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvwc12066 for ; Wed, 3 Jul 2002 04:40:23 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f187.law15.hotmail.com [64.4.23.187]) id QQmvwc12058 for ; Wed, 3 Jul 2002 04:40:22 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Jul 2002 21:40:22 -0700 Received: from 12.234.67.129 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 03 Jul 2002 04:40:21 GMT X-Originating-IP: [12.234.67.129] From: "Chetan Pinto" To: hliao@telcordia.com, mpls@UU.NET Subject: Re: What is the bad tspec? Date: Tue, 02 Jul 2002 21:40:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jul 2002 04:40:22.0027 (UTC) FILETIME=[BDB25DB0:01C2224B] Sender: owner-mpls@UU.NET Precedence: bulk >Hi, > >What is the unreasonable request for triggering bad Tspec? It is one with invalid values for the fields of the Tspec or a combination of valid ones which portends a bad set. Few examples (1) m should not be 0 (2) m must not be greater than M (3) r must not be greater than p > >If I set the token bucket rate very large, it will send back the patherr >msg with 'Requested bandwidth unavailable', it will not send the bad tspec. > >Thanks, > >Julia ############################################################ Chetan Francis Pinto Phone : Res : 408-244-1352 ############################################################ _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Wed Jul 3 03:09:51 2002 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 ESMTP id DAA00312 for ; Wed, 3 Jul 2002 03:09:51 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvwm23064 for ; Wed, 3 Jul 2002 07:10:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvwm20633; Wed, 3 Jul 2002 07:09:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvwm19278 for mpls-outgoing; Wed, 3 Jul 2002 07:08:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvwm19273 for ; Wed, 3 Jul 2002 07:08:55 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 QQmvwm17408 for ; Wed, 3 Jul 2002 07:07:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvwm19903 for ; Wed, 3 Jul 2002 07:07:37 GMT Received: from gorilla.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQmvwm19893 for ; Wed, 3 Jul 2002 07:07:36 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA12320; Wed, 3 Jul 2002 09:07:27 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA29234; Wed, 3 Jul 2002 09:07:28 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 09:07:28 +0200 Message-ID: From: Hummel Heinrich To: "'Eric Osborne'" , Hummel Heinrich Cc: "'erosen@cisco.com'" , Shahram Davari , George Sheng , scullptor@yahoo.com, mpls@UU.NET Subject: AW: your mail Date: Wed, 3 Jul 2002 09:07:27 +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 DAA00312 Find my response next to HH=> Heinrich On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > It gets weirder and weirder: The MPLS WG invents a label stack, but does not care at all that any of the > deeper nested labels may ever be signalled/carried by means of a Label-TLV/object (no public comments to my > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > However it is ok, to "steal" the deepest nested label and call it "VC-label" for indexing > some VRF at some remote PE. This is not theft; it's using the labels as they were designed. How is using the bottommost label as a VC-labe/VPN label/whatever "stealing"? You seem to be attacking the very idea of label stacking, which is a pretty useful concept. HH=>I am not against the VC-label and I am appreciating the label stack concept more than anybody else. But I cannot understand the absence of interest for concatenations of LSPs i.e. for Hierarchical LSPs while at the same time hash functionality, remote VRF access and maybe Captain-of-the-night news may be put into the labels. I am pretty confident that whatever MPLS is believed today, as to do better than IP, can be reversed. It only takes some smarter algorithm than the old-fashioned SPF and state-less IP forwarding would outperform all MPLS TE. However, the biggest advantage of the label stack cannot be matched by what so ever: Say you have N=10,000. It means N**2 = 100,000,000. 100,000,000 = 100 * 100 * 100 * 100. Each of the four "100" can easily be put into a 20-bit sized Label. Four labels can easily be put into one label stack. 4*100 =400 is ridiculously small compared with 100,1000,000. I admit this is fairly coarse (see more text in my drafts), IMHO, to extent MPLS signalling protocols (and also M-BGP) as to crack this n-square problem would be a much more ambitious goal. > Furthermore it is ok, to "steal" the very same label for hashing. > What about IP router vendors that do load-balancing based on L4/L5 information like protocol type and port numbers? Is that stealing? Why do we do layering at all ?!! Is it a special smartness to outwit all the rules? eric > Independent from what is clean and what is quick&dirty, I cannot detect any sense in giving a hash-meaning to the bottom label at all. > > > > Heinrich Hummel > Siemens > > -----Ursprüngliche Nachricht----- > Von: Eric Rosen [mailto:erosen@cisco.com] > Gesendet: Dienstag, 2. Juli 2002 16:06 > An: Shahram Davari > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > Betreff: Re: your mail > > > Shahram> To do ECMP, you need to assign hashed values to egress ports. This > Shahram> assignment is the hash state that I said you need. > > A hash is a function that maps some sequence of octets into a sequence of > integers. If you want to split traffic over six paths, while ensuring that > all packets with the same bottom label travel the same path, you need a > function that maps a 20 bit quantity into a number from 1-6. There is no > need to maintain state of any kind. From owner-mpls@UU.NET Wed Jul 3 03:24:10 2002 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 ESMTP id DAA00522 for ; Wed, 3 Jul 2002 03:24:09 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvwn05823 for ; Wed, 3 Jul 2002 07:24:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvwn02412; Wed, 3 Jul 2002 07:23:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvwn21467 for mpls-outgoing; Wed, 3 Jul 2002 07:23:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvwn21462 for ; Wed, 3 Jul 2002 07:22: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 QQmvwn18885 for ; Wed, 3 Jul 2002 07:22:38 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvwn13271 for ; Wed, 3 Jul 2002 07:22:38 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmvwn13267 for ; Wed, 3 Jul 2002 07:22:37 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <3B227ARK>; Wed, 3 Jul 2002 12:55:13 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06369DFA@HARITHA> From: "Kannan S (Networking) - CTD, Chennai." To: Eric Osborne Cc: "'MPLS Mailing list'" Subject: RE: your mail Date: Wed, 3 Jul 2002 12:54:39 +0530 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 Eric, About the idea of using the bottom most label for doing ECMP - Wouldnt that restrict the ECMP hashing function, because my hashing function is now totally dependent on how some router in the edge chose to identify a flow? For example, suppose an ingress edge LSR marked the bottom most label using say first 10 bits of the IP - SA, and last 10 bits of IP - DA, then I cant have an hashing algorithm which uses last 10 bits of IP - SA, and first 10 bits of IP - DA, right ? The efficiency of the algorithm (the choice itself) is now very dependent on how the edge LSR identifies flows. My point is, if it is decided that an LSR is going to look beyond whatever depth it is supposed to, the LSR's ECMP hashing function might as well look at the IP header instead of looking at the bottom most label. Am I missing something here? Thanks, Kans. -----Original Message----- From: Eric Osborne [mailto:eosborne@cisco.com] Sent: Wednesday, July 03, 2002 4:01 AM To: Gray, Eric Cc: 'Eric Osborne'; 'MPLS Mailing list' Subject: Re: your mail On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > Eric, > > It is in the fact that we have to be sure - > just as you suggest. The cost of being sure, however, > is that you have to be prepared to deal with occasions > when the check fails. What do you do when the higher > layer is not UDP or TCP - throw these packets in to a > common bucket? What is the expected impact if this > traffic might occasionally be significant? Then you need a better load-balancing algorithm. Either IP SA/DA and some randomness, or random sampling from the packet, or (heaven forbid) some sort of flow-based scheme. I'm even dubious about the efficacy of using TCP/UDP ports to hash, given that most traffic is either src or dst TCP port 80, which really only gives you the port in the other direction to play with. But that's not really my problem, as the implementation I'm familiar with doesn't do anything with TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a device that does; I just don't deal with it/them). also, don't forget that this hypothetical algorithm takes into acount IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you probably have very few flows/conversations/whatnot anyways, and either need to move to something like per-packet (ick) or just larger pipes. eric > > > Eric W. Gray > > > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Tuesday, July 02, 2002 4:24 PM > To: Gray, Eric > Cc: 'Eric Osborne'; 'MPLS Mailing list' > Subject: Re: your mail > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > Eric, > > > > To answer your final two questions, yes it probably > > is stealing. The fact that you can get away with a crime > > does not make it any less a crime. Who knows, some vendors > > may not check that the protocol over the top of IP is either > > UDP or TCP before using the port numbers. > > If a vendor checks the offset where the port numbers should be without > checking for the correct protocol type, this is a cruddy > implementation and shouldn't exist. My question was really along the > lines of "what if we use the values that we *know* are UDP/TCP port > numbers"? From what you say above, it seems like that might be OK, as > long as we only do this when we're sure? Or is there some inherent > architectual layer violation thing that you're objecting to? > > > > eric > > > I think you can > > easily imagine what that might lead to if a set of packets > > carry a higher level protocol where the corresponding fields > > may vary from packet to packet in a single micro-flow. The > > real question is how common is this? > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > -----Original Message----- > > From: Eric Osborne [mailto:eosborne@cisco.com] > > Sent: Tuesday, July 02, 2002 1:32 PM > > To: Hummel Heinrich > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George Sheng; > > scullptor@yahoo.com; mpls@UU.NET > > Subject: Re: your mail > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > It gets weirder and weirder: The MPLS WG invents a label stack, but > does > > not care at all that any of the > > > deeper nested labels may ever be signalled/carried by means of a > > Label-TLV/object (no public comments to my > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > However it is ok, to "steal" the deepest nested label and call it > > "VC-label" for indexing > > > some VRF at some remote PE. > > > > This is not theft; it's using the labels as they were designed. How > > is using the bottommost label as a VC-labe/VPN label/whatever > > "stealing"? You seem to be attacking the very idea of label stacking, > > which is a pretty useful concept. > > > > > Furthermore it is ok, to "steal" the very same label for hashing. > > > > > > > What about IP router vendors that do load-balancing based on L4/L5 > > information like protocol type and port numbers? Is that stealing? > > > > > > > > > > eric > > > > > Independent from what is clean and what is quick&dirty, I cannot detect > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > Heinrich Hummel > > > Siemens > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > An: Shahram Davari > > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > > Betreff: Re: your mail > > > > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress ports. > > This > > > Shahram> assignment is the hash state that I said you need. > > > > > > A hash is a function that maps some sequence of octets into a > sequence > > of > > > integers. If you want to split traffic over six paths, while ensuring > > that > > > all packets with the same bottom label travel the same path, you > need > > a > > > function that maps a 20 bit quantity into a number from 1-6. There > is > > no > > > need to maintain state of any kind. From owner-mpls@UU.NET Wed Jul 3 03:42:00 2002 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 ESMTP id DAA00862 for ; Wed, 3 Jul 2002 03:42:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvwo23552 for ; Wed, 3 Jul 2002 07:42:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvwo22010; Wed, 3 Jul 2002 07:42:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvwo22775 for mpls-outgoing; Wed, 3 Jul 2002 07:41:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvwo22770 for ; Wed, 3 Jul 2002 07:41: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 QQmvwo14008 for ; Wed, 3 Jul 2002 07:41:20 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvwo22151 for ; Wed, 3 Jul 2002 07:41:20 GMT Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmvwo22145 for ; Wed, 3 Jul 2002 07:41:19 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3DLQB4HH>; Wed, 3 Jul 2002 08:41:33 +0100 Message-ID: To: eosborne@cisco.com Cc: Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: your mail Date: Wed, 3 Jul 2002 08:41:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > is there anything > wrong with hashing for loadsharing purposes *other* than the fact that > it makes doing OAM the way you've proposed difficult, if not > impossible? NH=> This is not actually where this all started Eric, and neither is it the main/only reason I have grave concerns over LDP....in fact, I'd assume it makes any OAM difficult (even LSP Ping), but please correct if this is a wrong view. The underlying question (which Shahram posed some time ago) is 'what network problems does mp2p LDP solve (that cannot be better addressed using IP or p2p LSPs)?' I never saw any answer that convinced me LDP is necessary....sure it exists and is out there, but what killer problem is it there to solve? It then expanded (various threads, some even prior to this) that pointed out some of the consequences of LDP for operators.....let me list a few to remind you: - VPN survivability is a function of all cross-VPN traffic and is temporally non-deterministic on a per customer basis per epoch. That is, there is no relationship between a DS codepoint and that pkt's 'survivability priority' vis-a-vis other pkts of same/different DS codepoints in either the same or other VPNs....and that's a consequence of like-DS-class merging across VPN populations. - because of this hard QoS/availability guarantees per VPN customer are not possible - because of this we are forced over-engineer and hope - MPLS introduces new failures modes even in p2p mode (this is the absolute vs relative addressing issue that I mentioned previously), but mp2p LSPs create a new richness of fault-management complexity - the LDP LSPs track the IGP and so the network is not flexible wrt traffic sensitivities......hence, it requires hashing functions at P nodes which not only breaks the MPLS simple label forwarding idea of MPLS but introduces another level of fault-management to deal with. So the fault-management issue (which you think is not important given the tone of your response) is but 1 consequence of LDP. Similarly, the load-balancing issue is another consequence of LDP. And similarly, another consequence of LDP is the inability to decouple VPN performance/availability on a *per customer basis*. So all these aspects are compromised when we use LDP......and for what compelling advantage(s) over using an IPinIP solution (or p2p LSPs as/when necessary)? So please answer that for me so that I can understand what I and others are clearly missing here that makes LDP so wonderful that we simply can't afford to live without it? regards, Neil From owner-mpls@UU.NET Wed Jul 3 08:18:33 2002 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 ESMTP id IAA08768 for ; Wed, 3 Jul 2002 08:18:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxa19222 for ; Wed, 3 Jul 2002 10:35:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvxa18395; Wed, 3 Jul 2002 10:35:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvxa11831 for mpls-outgoing; Wed, 3 Jul 2002 10:35:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvxa11826 for ; Wed, 3 Jul 2002 10: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 QQmvxa17929 for ; Wed, 3 Jul 2002 10:34:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxa04455 for ; Wed, 3 Jul 2002 10:34:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvxa04451 for ; Wed, 3 Jul 2002 10:34:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA02355 for ; Wed, 3 Jul 2002 06:34:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA11419 for mpls@uu.net; Wed, 3 Jul 2002 06:34:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvxa11741 for ; Wed, 3 Jul 2002 10:32: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 QQmvxa02273 for ; Wed, 3 Jul 2002 10:31:50 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxa04070 for ; Wed, 3 Jul 2002 10:31:50 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 QQmvxa04063 for ; Wed, 3 Jul 2002 10:31: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 GAA03909; Wed, 3 Jul 2002 06:31:00 -0400 (EDT) Message-Id: <200207031031.GAA03909@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-bundle-mib-03.txt Date: Wed, 03 Jul 2002 06:31:00 -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 : Link Bundling Management Information Base Author(s) : M. Dubuc et al. Filename : draft-ietf-mpls-bundle-mib-03.txt Pages : 55 Date : 02-Jul-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling link bun- dling as described in the Link Bundling in MPLS Traffic Engineering Internet Draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-bundle-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-bundle-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020702151636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bundle-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bundle-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151636.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 3 08:48:42 2002 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 ESMTP id IAA10343 for ; Wed, 3 Jul 2002 08:48:42 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxj17815 for ; Wed, 3 Jul 2002 12:48:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvxj14707; Wed, 3 Jul 2002 12:47:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvxj06413 for mpls-outgoing; Wed, 3 Jul 2002 12:46:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvxj06397 for ; Wed, 3 Jul 2002 12:46:24 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 QQmvxi09189 for ; Wed, 3 Jul 2002 12:44:55 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxi13649 for ; Wed, 3 Jul 2002 12:44:55 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvxi13639 for ; Wed, 3 Jul 2002 12:44:54 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA07051 for ; Wed, 3 Jul 2002 08:44:54 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA25036 for mpls@uu.net; Wed, 3 Jul 2002 08:44:54 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvxb14003 for ; Wed, 3 Jul 2002 10:56: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 QQmvxb09013 for ; Wed, 3 Jul 2002 10:56:18 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxb03263 for ; Wed, 3 Jul 2002 10:56:18 GMT Received: from mailhost.metro-optix.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.219.248.6]) id QQmvxb03259 for ; Wed, 3 Jul 2002 10:56:18 GMT Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 05:55:21 -0500 Message-ID: <99EC34181384D611BE56000347227B2C01EAA0@MAILHOSTNB> From: Apratim Mukherjee To: mpls@UU.NET Subject: Lsp teardown initiated by egress. Date: Wed, 3 Jul 2002 16:25:01 -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 Hi , If there are multiple lsps in a session ( FF style and many lsps in RSVP-TE) and egress wants to initiate the teardown of a particular lsp ,it inserts an Admin Status object with R and D bits set in the Resv Message. The ingress will recieve a resv message which contains multiple flow descriptors and only one Admin Status object . How will the ingress know which lsp the egress wants to tear down ? At intermediate nodes , there will be multiple cross-connects , one for each lsp in the session . How will the intermediate node find out for which of the lsps in that session , it should disable the alarm ? Thanks, Apratim From owner-mpls@UU.NET Wed Jul 3 09:56:14 2002 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 ESMTP id JAA14007 for ; Wed, 3 Jul 2002 09:56:13 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxn27234 for ; Wed, 3 Jul 2002 13:56:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvxn24920; Wed, 3 Jul 2002 13:55:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvxn02972 for mpls-outgoing; Wed, 3 Jul 2002 13:55:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvxn02967 for ; Wed, 3 Jul 2002 13:55: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 QQmvxn02634 for ; Wed, 3 Jul 2002 13:55:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxn16348 for ; Wed, 3 Jul 2002 13:55:29 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmvxn16335 for ; Wed, 3 Jul 2002 13:55:29 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 09:55:28 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B0226710A@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Kannan S (Networking) - CTD, Chennai.'" , Eric Osborne Cc: "'MPLS Mailing list'" Subject: RE: your mail Date: Wed, 3 Jul 2002 09:55: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 Kans, There are a few things that are non-obvious that have some relevance to your comments. One is that MPLS as a whole relies on a trust model that is dependent on correct behavior of LSP participants. In electing to differentiate the labels used for packets that are likely to be part of a common flow in forwarding them to a downstream peer, an LSR assumes some risk that they will not follow the same physical path (they'd be different label switched paths, after all). This would be wrong. Another is that - if an upstream LSR uses an approach such as you suggest (perhaps to do its own brand of ECMP) - then it will not be at risk of putting packets that are likely to be part of the same flow on different paths. This is OK and - if an LSR receiving these packets decides to use the bottom label (which we have found is 'bottom' by almost any reasonable definition) - then the worst it will do is lump 'similar' (defined for any particular hashing scheme) flows together. It will not result in splitting a flow unless an upstream LSR is guilty of 'BAD behavior' described above. Thirdly, it is definitely inappropriate to assume that the stuff after the last label is an IP header except in the case where the last label is an explicit IPv4 NULL label. It could be any of a lot of things otherwise and - given PHP and a number of defined MPLS applications - the last label is very unlikely to be an IPv4 explicit NULL label. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Kannan S (Networking) - CTD, Chennai. [mailto:kannans@ctd.hcltech.com] Sent: Wednesday, July 03, 2002 3:25 AM To: Eric Osborne Cc: 'MPLS Mailing list' Subject: RE: your mail Eric, About the idea of using the bottom most label for doing ECMP - Wouldnt that restrict the ECMP hashing function, because my hashing function is now totally dependent on how some router in the edge chose to identify a flow? For example, suppose an ingress edge LSR marked the bottom most label using say first 10 bits of the IP - SA, and last 10 bits of IP - DA, then I cant have an hashing algorithm which uses last 10 bits of IP - SA, and first 10 bits of IP - DA, right ? The efficiency of the algorithm (the choice itself) is now very dependent on how the edge LSR identifies flows. My point is, if it is decided that an LSR is going to look beyond whatever depth it is supposed to, the LSR's ECMP hashing function might as well look at the IP header instead of looking at the bottom most label. Am I missing something here? Thanks, Kans. -----Original Message----- From: Eric Osborne [mailto:eosborne@cisco.com] Sent: Wednesday, July 03, 2002 4:01 AM To: Gray, Eric Cc: 'Eric Osborne'; 'MPLS Mailing list' Subject: Re: your mail On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > Eric, > > It is in the fact that we have to be sure - > just as you suggest. The cost of being sure, however, > is that you have to be prepared to deal with occasions > when the check fails. What do you do when the higher > layer is not UDP or TCP - throw these packets in to a > common bucket? What is the expected impact if this > traffic might occasionally be significant? Then you need a better load-balancing algorithm. Either IP SA/DA and some randomness, or random sampling from the packet, or (heaven forbid) some sort of flow-based scheme. I'm even dubious about the efficacy of using TCP/UDP ports to hash, given that most traffic is either src or dst TCP port 80, which really only gives you the port in the other direction to play with. But that's not really my problem, as the implementation I'm familiar with doesn't do anything with TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a device that does; I just don't deal with it/them). also, don't forget that this hypothetical algorithm takes into acount IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you probably have very few flows/conversations/whatnot anyways, and either need to move to something like per-packet (ick) or just larger pipes. eric > > > Eric W. Gray > > > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Tuesday, July 02, 2002 4:24 PM > To: Gray, Eric > Cc: 'Eric Osborne'; 'MPLS Mailing list' > Subject: Re: your mail > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > Eric, > > > > To answer your final two questions, yes it probably > > is stealing. The fact that you can get away with a crime > > does not make it any less a crime. Who knows, some vendors > > may not check that the protocol over the top of IP is either > > UDP or TCP before using the port numbers. > > If a vendor checks the offset where the port numbers should be without > checking for the correct protocol type, this is a cruddy > implementation and shouldn't exist. My question was really along the > lines of "what if we use the values that we *know* are UDP/TCP port > numbers"? From what you say above, it seems like that might be OK, as > long as we only do this when we're sure? Or is there some inherent > architectual layer violation thing that you're objecting to? > > > > eric > > > I think you can > > easily imagine what that might lead to if a set of packets > > carry a higher level protocol where the corresponding fields > > may vary from packet to packet in a single micro-flow. The > > real question is how common is this? > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > -----Original Message----- > > From: Eric Osborne [mailto:eosborne@cisco.com] > > Sent: Tuesday, July 02, 2002 1:32 PM > > To: Hummel Heinrich > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George Sheng; > > scullptor@yahoo.com; mpls@UU.NET > > Subject: Re: your mail > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > It gets weirder and weirder: The MPLS WG invents a label stack, but > does > > not care at all that any of the > > > deeper nested labels may ever be signalled/carried by means of a > > Label-TLV/object (no public comments to my > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > However it is ok, to "steal" the deepest nested label and call it > > "VC-label" for indexing > > > some VRF at some remote PE. > > > > This is not theft; it's using the labels as they were designed. How > > is using the bottommost label as a VC-labe/VPN label/whatever > > "stealing"? You seem to be attacking the very idea of label stacking, > > which is a pretty useful concept. > > > > > Furthermore it is ok, to "steal" the very same label for hashing. > > > > > > > What about IP router vendors that do load-balancing based on L4/L5 > > information like protocol type and port numbers? Is that stealing? > > > > > > > > > > eric > > > > > Independent from what is clean and what is quick&dirty, I cannot detect > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > Heinrich Hummel > > > Siemens > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > An: Shahram Davari > > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > > Betreff: Re: your mail > > > > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress ports. > > This > > > Shahram> assignment is the hash state that I said you need. > > > > > > A hash is a function that maps some sequence of octets into a > sequence > > of > > > integers. If you want to split traffic over six paths, while ensuring > > that > > > all packets with the same bottom label travel the same path, you > need > > a > > > function that maps a 20 bit quantity into a number from 1-6. There > is > > no > > > need to maintain state of any kind. From owner-mpls@UU.NET Wed Jul 3 10:30:51 2002 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 ESMTP id KAA16784 for ; Wed, 3 Jul 2002 10:30:50 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxq22992 for ; Wed, 3 Jul 2002 14:31:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvxp18892; Wed, 3 Jul 2002 14:29:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvxp27845 for mpls-outgoing; Wed, 3 Jul 2002 14:28:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvxp27840 for ; Wed, 3 Jul 2002 14:28: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 QQmvxp00521 for ; Wed, 3 Jul 2002 14:28:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxp18998 for ; Wed, 3 Jul 2002 14:28:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvxp18989 for ; Wed, 3 Jul 2002 14:28:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA12907 for ; Wed, 3 Jul 2002 10:28:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06436 for mpls@uu.net; Wed, 3 Jul 2002 10:28:03 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvxp27757 for ; Wed, 3 Jul 2002 14:26: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 QQmvxp17801 for ; Wed, 3 Jul 2002 14:25:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxp25348 for ; Wed, 3 Jul 2002 14:25:13 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 QQmvxp25344 for ; Wed, 3 Jul 2002 14:25:12 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g63EPcHs015103; Wed, 3 Jul 2002 10:25:38 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (che-vpn1-10.cisco.com [10.86.240.10]) by bucket.cisco.com (Mirapoint) with ESMTP id ABG11702; Wed, 3 Jul 2002 10:25:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20020703102418.01ff1ca0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 Jul 2002 10:25:03 -0400 To: "Zhu, Rupert" From: "Thomas D. Nadeau" Subject: Re: PPVPN-MIB draft Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, Thanks. We will fix these in the future. BTW, in the future please direct comments regarding the PPVPN MPLS VPN MIB to the PPVPN WG's mailing list instead of MPLS. --Tom >Just an editorial note on draft-ietf-ppvpn-mpls-vpn-mib-04.txt. > >The "Table of Contents" and the main text are out of synch. >for example, Section 9.0 in TOC is as follows. > > 9.0 Summary of MPLS-VPN-MIB > >But this section does not exist in the text body. The subsequent >sections are mis-numbered. > >Thanks. > >-- Rupert ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Wed Jul 3 11:40:58 2002 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 ESMTP id LAA18692 for ; Wed, 3 Jul 2002 11:40:58 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxp09402 for ; Wed, 3 Jul 2002 14:23:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvxp07378; Wed, 3 Jul 2002 14:22:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvxp27419 for mpls-outgoing; Wed, 3 Jul 2002 14:22:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvxp27414 for ; Wed, 3 Jul 2002 14:22: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 QQmvxp14408 for ; Wed, 3 Jul 2002 14:20:49 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxp19406 for ; Wed, 3 Jul 2002 14:20:48 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQmvxp19391 for ; Wed, 3 Jul 2002 14:20:48 GMT Message-ID: From: Ling Li To: "'mpls@UU.NET'" Subject: a doubt on the hop-limit constraint in draft-ietf-mpls-fastrerout e-mib-00.txt Date: Wed, 3 Jul 2002 10:20:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The hop-limit constraint is defined as follows in draft-ietf-mpls-fastreroute-mib-00.txt: mplsFrrConstHopLimit OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of hops that the detour LSP may traverse." DEFVAL { 32 } ::= { mplsFrrConstEntry 10 } However, this definition is different from what it is in draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt: Hop-limit The maximum number of extra hops the backup path is allowed to take, from current node (a PLR) to a MP, with PLR and MP excluded in counting. For example, hop-limit of 0 means only direct links between PLR and MP can be considered. Can any of the authors clarify this inconsistency? I have raised a closely related question at http://cell.onecall.net/mhonarc/mpls/2002-Jun/msg00143.html. Thanks, Ling Li Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752 Email: lli@axiowave.com ======================== From owner-mpls@UU.NET Wed Jul 3 12:04:46 2002 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 ESMTP id MAA19742 for ; Wed, 3 Jul 2002 12:04:46 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxw14029 for ; Wed, 3 Jul 2002 16:05:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvxw10857; Wed, 3 Jul 2002 16:03:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvxw08672 for mpls-outgoing; Wed, 3 Jul 2002 16:03:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvxw08651 for ; Wed, 3 Jul 2002 16:03: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 QQmvxw04827 for ; Wed, 3 Jul 2002 16:01:26 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxw15261 for ; Wed, 3 Jul 2002 16:01:26 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmvxw15212 for ; Wed, 3 Jul 2002 16:01:21 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17PmYx-0005tt-00; Wed, 03 Jul 2002 17:01:03 +0100 Subject: RE: your mail From: Giles Heron To: "Gray, Eric" Cc: "'Kannan \"S (Networking) - CTD, \"\"Chennai.'\"" , Eric Osborne , "'MPLS Mailing list'" In-Reply-To: <1117F7D44159934FB116E36F4ABF221B0226710A@celox-ma1-ems1.celoxnetworks.com> References: <1117F7D44159934FB116E36F4ABF221B0226710A@celox-ma1-ems1.celoxnetworks.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 03 Jul 2002 17:01:02 +0000 Message-Id: <1025715662.1450.135.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA19742 On Wed, 2002-07-03 at 13:55, Gray, Eric wrote: [snip] > Thirdly, it is definitely inappropriate to assume that the > stuff after the last label is an IP header except in the > case where the last label is an explicit IPv4 NULL label. > It could be any of a lot of things otherwise and - given > PHP and a number of defined MPLS applications - the last > label is very unlikely to be an IPv4 explicit NULL label. Other than Juniper's CCC (which is dependent on RSVP-TE) I'm not aware of any application putting non-IP traffic directly over an LSP (i.e. without using a label stack). Therefore when there is only one label (other than when an egress LSR using PHP receives a packet - in which case load balancing is somewhat moot) I think we can assume that the payload is IP? Giles > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Kannan S (Networking) - CTD, Chennai. [mailto:kannans@ctd.hcltech.com] > > Sent: Wednesday, July 03, 2002 3:25 AM > To: Eric Osborne > Cc: 'MPLS Mailing list' > Subject: RE: your mail > > Eric, > > About the idea of using the bottom most label for doing ECMP - > > Wouldnt that restrict the ECMP hashing function, because my hashing function > is now totally dependent on how some router in the edge chose to identify a > flow? > > For example, suppose an ingress edge LSR marked the bottom most label using > say first 10 bits of the IP - SA, and last 10 bits of IP - DA, then I cant > have an hashing algorithm which uses last 10 bits of IP - SA, and first 10 > bits of IP - DA, right ? The efficiency of the algorithm (the choice > itself) is now very dependent on how the edge LSR identifies flows. > > My point is, if it is decided that an LSR is going to look beyond whatever > depth it is supposed to, the LSR's ECMP hashing function might as well look > at the IP header instead of looking at the bottom most label. > > Am I missing something here? > > Thanks, > Kans. > > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Wednesday, July 03, 2002 4:01 AM > To: Gray, Eric > Cc: 'Eric Osborne'; 'MPLS Mailing list' > Subject: Re: your mail > > > On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > > Eric, > > > > It is in the fact that we have to be sure - > > just as you suggest. The cost of being sure, however, > > is that you have to be prepared to deal with occasions > > when the check fails. What do you do when the higher > > layer is not UDP or TCP - throw these packets in to a > > common bucket? What is the expected impact if this > > traffic might occasionally be significant? > > Then you need a better load-balancing algorithm. Either IP SA/DA and > some randomness, or random sampling from the packet, or (heaven > forbid) some sort of flow-based scheme. I'm even dubious about the > efficacy of using TCP/UDP ports to hash, given that most traffic is > either src or dst TCP port 80, which really only gives you the port in > the other direction to play with. But that's not really my problem, > as the implementation I'm familiar with doesn't do anything with > TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a > device that does; I just don't deal with it/them). > > also, don't forget that this hypothetical algorithm takes into acount > IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you > probably have very few flows/conversations/whatnot anyways, and either > need to move to something like per-packet (ick) or just larger pipes. > > > > > eric > > > > > > > Eric W. Gray > > > > > > -----Original Message----- > > From: Eric Osborne [mailto:eosborne@cisco.com] > > Sent: Tuesday, July 02, 2002 4:24 PM > > To: Gray, Eric > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > Subject: Re: your mail > > > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > > Eric, > > > > > > To answer your final two questions, yes it probably > > > is stealing. The fact that you can get away with a crime > > > does not make it any less a crime. Who knows, some vendors > > > may not check that the protocol over the top of IP is either > > > UDP or TCP before using the port numbers. > > > > If a vendor checks the offset where the port numbers should be without > > checking for the correct protocol type, this is a cruddy > > implementation and shouldn't exist. My question was really along the > > lines of "what if we use the values that we *know* are UDP/TCP port > > numbers"? From what you say above, it seems like that might be OK, as > > long as we only do this when we're sure? Or is there some inherent > > architectual layer violation thing that you're objecting to? > > > > > > > > eric > > > > > I think you can > > > easily imagine what that might lead to if a set of packets > > > carry a higher level protocol where the corresponding fields > > > may vary from packet to packet in a single micro-flow. The > > > real question is how common is this? > > > > > > Eric W. Gray > > > Systems Architect > > > Celox Networks, Inc. > > > egray@celoxnetworks.com > > > 508 305 7214 > > > > > > > > > -----Original Message----- > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > Sent: Tuesday, July 02, 2002 1:32 PM > > > To: Hummel Heinrich > > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George Sheng; > > > scullptor@yahoo.com; mpls@UU.NET > > > Subject: Re: your mail > > > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > > It gets weirder and weirder: The MPLS WG invents a label stack, but > > does > > > not care at all that any of the > > > > deeper nested labels may ever be signalled/carried by means of a > > > Label-TLV/object (no public comments to my > > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > > > However it is ok, to "steal" the deepest nested label and call it > > > "VC-label" for indexing > > > > some VRF at some remote PE. > > > > > > This is not theft; it's using the labels as they were designed. How > > > is using the bottommost label as a VC-labe/VPN label/whatever > > > "stealing"? You seem to be attacking the very idea of label stacking, > > > which is a pretty useful concept. > > > > > > > Furthermore it is ok, to "steal" the very same label for hashing. > > > > > > > > > > What about IP router vendors that do load-balancing based on L4/L5 > > > information like protocol type and port numbers? Is that stealing? > > > > > > > > > > > > > > > eric > > > > > > > Independent from what is clean and what is quick&dirty, I cannot > detect > > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > > > > > Heinrich Hummel > > > > Siemens > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > > An: Shahram Davari > > > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > > > Betreff: Re: your mail > > > > > > > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress > ports. > > > This > > > > Shahram> assignment is the hash state that I said you need. > > > > > > > > A hash is a function that maps some sequence of octets into a > > sequence > > > of > > > > integers. If you want to split traffic over six paths, while > ensuring > > > that > > > > all packets with the same bottom label travel the same path, you > > need > > > a > > > > function that maps a 20 bit quantity into a number from 1-6. There > > is > > > no > > > > need to maintain state of any kind. > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Wed Jul 3 12:54:39 2002 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 ESMTP id MAA21689 for ; Wed, 3 Jul 2002 12:54:39 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxz10930 for ; Wed, 3 Jul 2002 16:55:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvxz08107; Wed, 3 Jul 2002 16:54:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvxz23384 for mpls-outgoing; Wed, 3 Jul 2002 16:53:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvxz23367 for ; Wed, 3 Jul 2002 16:53:41 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 QQmvxz13852 for ; Wed, 3 Jul 2002 16:52:01 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxz24174 for ; Wed, 3 Jul 2002 16:52:01 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmvxz24169 for ; Wed, 3 Jul 2002 16:52:01 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 12:52:01 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267111@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Giles Heron'" , "Gray, Eric" Cc: "'Kannan \"S (Networking) - CTD, \"\"Chennai.'" , Eric Osborne , "'MPLS Mailing list'" Subject: RE: your mail Date: Wed, 3 Jul 2002 12:51:56 -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 Giles, I was responding to this statement: > My point is, if it is decided that an LSR is going to look beyond > whatever depth it is supposed to, the LSR's ECMP hashing function > might as well look at the IP header instead of looking at the bottom > most label. How does my response to this relate to your comment? :-) Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Giles Heron [mailto:giles@packetexchange.net] Sent: Wednesday, July 03, 2002 1:01 PM To: Gray, Eric Cc: 'Kannan "S (Networking) - CTD, ""Chennai.'; Eric Osborne; 'MPLS Mailing list' Subject: RE: your mail On Wed, 2002-07-03 at 13:55, Gray, Eric wrote: [snip] > Thirdly, it is definitely inappropriate to assume that the > stuff after the last label is an IP header except in the > case where the last label is an explicit IPv4 NULL label. > It could be any of a lot of things otherwise and - given > PHP and a number of defined MPLS applications - the last > label is very unlikely to be an IPv4 explicit NULL label. Other than Juniper's CCC (which is dependent on RSVP-TE) I'm not aware of any application putting non-IP traffic directly over an LSP (i.e. without using a label stack). Therefore when there is only one label (other than when an egress LSR using PHP receives a packet - in which case load balancing is somewhat moot) I think we can assume that the payload is IP? Giles > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Kannan S (Networking) - CTD, Chennai. [mailto:kannans@ctd.hcltech.com] > > Sent: Wednesday, July 03, 2002 3:25 AM > To: Eric Osborne > Cc: 'MPLS Mailing list' > Subject: RE: your mail > > Eric, > > About the idea of using the bottom most label for doing ECMP - > > Wouldnt that restrict the ECMP hashing function, because my hashing function > is now totally dependent on how some router in the edge chose to identify a > flow? > > For example, suppose an ingress edge LSR marked the bottom most label using > say first 10 bits of the IP - SA, and last 10 bits of IP - DA, then I cant > have an hashing algorithm which uses last 10 bits of IP - SA, and first 10 > bits of IP - DA, right ? The efficiency of the algorithm (the choice > itself) is now very dependent on how the edge LSR identifies flows. > > My point is, if it is decided that an LSR is going to look beyond whatever > depth it is supposed to, the LSR's ECMP hashing function might as well look > at the IP header instead of looking at the bottom most label. > > Am I missing something here? > > Thanks, > Kans. > > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Wednesday, July 03, 2002 4:01 AM > To: Gray, Eric > Cc: 'Eric Osborne'; 'MPLS Mailing list' > Subject: Re: your mail > > > On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > > Eric, > > > > It is in the fact that we have to be sure - > > just as you suggest. The cost of being sure, however, > > is that you have to be prepared to deal with occasions > > when the check fails. What do you do when the higher > > layer is not UDP or TCP - throw these packets in to a > > common bucket? What is the expected impact if this > > traffic might occasionally be significant? > > Then you need a better load-balancing algorithm. Either IP SA/DA and > some randomness, or random sampling from the packet, or (heaven > forbid) some sort of flow-based scheme. I'm even dubious about the > efficacy of using TCP/UDP ports to hash, given that most traffic is > either src or dst TCP port 80, which really only gives you the port in > the other direction to play with. But that's not really my problem, > as the implementation I'm familiar with doesn't do anything with > TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a > device that does; I just don't deal with it/them). > > also, don't forget that this hypothetical algorithm takes into acount > IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you > probably have very few flows/conversations/whatnot anyways, and either > need to move to something like per-packet (ick) or just larger pipes. > > > > > eric > > > > > > > Eric W. Gray > > > > > > -----Original Message----- > > From: Eric Osborne [mailto:eosborne@cisco.com] > > Sent: Tuesday, July 02, 2002 4:24 PM > > To: Gray, Eric > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > Subject: Re: your mail > > > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > > Eric, > > > > > > To answer your final two questions, yes it probably > > > is stealing. The fact that you can get away with a crime > > > does not make it any less a crime. Who knows, some vendors > > > may not check that the protocol over the top of IP is either > > > UDP or TCP before using the port numbers. > > > > If a vendor checks the offset where the port numbers should be without > > checking for the correct protocol type, this is a cruddy > > implementation and shouldn't exist. My question was really along the > > lines of "what if we use the values that we *know* are UDP/TCP port > > numbers"? From what you say above, it seems like that might be OK, as > > long as we only do this when we're sure? Or is there some inherent > > architectual layer violation thing that you're objecting to? > > > > > > > > eric > > > > > I think you can > > > easily imagine what that might lead to if a set of packets > > > carry a higher level protocol where the corresponding fields > > > may vary from packet to packet in a single micro-flow. The > > > real question is how common is this? > > > > > > Eric W. Gray > > > Systems Architect > > > Celox Networks, Inc. > > > egray@celoxnetworks.com > > > 508 305 7214 > > > > > > > > > -----Original Message----- > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > Sent: Tuesday, July 02, 2002 1:32 PM > > > To: Hummel Heinrich > > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George Sheng; > > > scullptor@yahoo.com; mpls@UU.NET > > > Subject: Re: your mail > > > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > > It gets weirder and weirder: The MPLS WG invents a label stack, but > > does > > > not care at all that any of the > > > > deeper nested labels may ever be signalled/carried by means of a > > > Label-TLV/object (no public comments to my > > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > > > However it is ok, to "steal" the deepest nested label and call it > > > "VC-label" for indexing > > > > some VRF at some remote PE. > > > > > > This is not theft; it's using the labels as they were designed. How > > > is using the bottommost label as a VC-labe/VPN label/whatever > > > "stealing"? You seem to be attacking the very idea of label stacking, > > > which is a pretty useful concept. > > > > > > > Furthermore it is ok, to "steal" the very same label for hashing. > > > > > > > > > > What about IP router vendors that do load-balancing based on L4/L5 > > > information like protocol type and port numbers? Is that stealing? > > > > > > > > > > > > > > > eric > > > > > > > Independent from what is clean and what is quick&dirty, I cannot > detect > > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > > > > > Heinrich Hummel > > > > Siemens > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > > An: Shahram Davari > > > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > > > Betreff: Re: your mail > > > > > > > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress > ports. > > > This > > > > Shahram> assignment is the hash state that I said you need. > > > > > > > > A hash is a function that maps some sequence of octets into a > > sequence > > > of > > > > integers. If you want to split traffic over six paths, while > ensuring > > > that > > > > all packets with the same bottom label travel the same path, you > > need > > > a > > > > function that maps a 20 bit quantity into a number from 1-6. There > > is > > > no > > > > need to maintain state of any kind. > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Wed Jul 3 12:59:47 2002 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 ESMTP id MAA21819 for ; Wed, 3 Jul 2002 12:59:47 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvya04151 for ; Wed, 3 Jul 2002 17:00:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvxz00357; Wed, 3 Jul 2002 16:58:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvxz23832 for mpls-outgoing; Wed, 3 Jul 2002 16:58:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvxz23822 for ; Wed, 3 Jul 2002 16:58: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 QQmvxz14340 for ; Wed, 3 Jul 2002 16:57:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxz14918 for ; Wed, 3 Jul 2002 16:57:22 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmvxz14236 for ; Wed, 3 Jul 2002 16:57:02 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17PnQs-00066b-00; Wed, 03 Jul 2002 17:56:46 +0100 Subject: RE: your mail From: Giles Heron To: "Gray, Eric" Cc: "'Kannan \"S (Networking) ""- CTD, \"\"Chennai.'" , Eric Osborne , "'MPLS Mailing list'" In-Reply-To: <1117F7D44159934FB116E36F4ABF221B02267111@celox-ma1-ems1.celoxnetworks.com> References: <1117F7D44159934FB116E36F4ABF221B02267111@celox-ma1-ems1.celoxnetworks.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 03 Jul 2002 17:56:45 +0000 Message-Id: <1025719005.3892.2.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA21819 oops, yeah good point. In this case clearly you *can* still look for an IPv4 header - it is just rather uglier. The trick is to look for the value 0100 in the first 4 bits. The risk is, of course, that there may be a client protocol which also sends this :( Giles On Wed, 2002-07-03 at 16:51, Gray, Eric wrote: > Giles, > > I was responding to this statement: > > > My point is, if it is decided that an LSR is going to look beyond > > whatever depth it is supposed to, the LSR's ECMP hashing function > > might as well look at the IP header instead of looking at the bottom > > most label. > > How does my response to this relate to your comment? :-) > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Wednesday, July 03, 2002 1:01 PM > To: Gray, Eric > Cc: 'Kannan "S (Networking) - CTD, ""Chennai.'; Eric Osborne; 'MPLS Mailing > list' > Subject: RE: your mail > > On Wed, 2002-07-03 at 13:55, Gray, Eric wrote: > [snip] > > Thirdly, it is definitely inappropriate to assume that the > > stuff after the last label is an IP header except in the > > case where the last label is an explicit IPv4 NULL label. > > It could be any of a lot of things otherwise and - given > > PHP and a number of defined MPLS applications - the last > > label is very unlikely to be an IPv4 explicit NULL label. > > Other than Juniper's CCC (which is dependent on RSVP-TE) I'm not aware > of any application putting non-IP traffic directly over an LSP (i.e. > without using a label stack). > > Therefore when there is only one label (other than when an egress LSR > using PHP receives a packet - in which case load balancing is somewhat > moot) I think we can assume that the payload is IP? > > Giles > > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > -----Original Message----- > > From: Kannan S (Networking) - CTD, Chennai. > [mailto:kannans@ctd.hcltech.com] > > > > Sent: Wednesday, July 03, 2002 3:25 AM > > To: Eric Osborne > > Cc: 'MPLS Mailing list' > > Subject: RE: your mail > > > > Eric, > > > > About the idea of using the bottom most label for doing ECMP - > > > > Wouldnt that restrict the ECMP hashing function, because my hashing > function > > is now totally dependent on how some router in the edge chose to identify > a > > flow? > > > > For example, suppose an ingress edge LSR marked the bottom most label > using > > say first 10 bits of the IP - SA, and last 10 bits of IP - DA, then I cant > > have an hashing algorithm which uses last 10 bits of IP - SA, and first 10 > > bits of IP - DA, right ? The efficiency of the algorithm (the choice > > itself) is now very dependent on how the edge LSR identifies flows. > > > > My point is, if it is decided that an LSR is going to look beyond whatever > > depth it is supposed to, the LSR's ECMP hashing function might as well > look > > at the IP header instead of looking at the bottom most label. > > > > Am I missing something here? > > > > Thanks, > > Kans. > > > > -----Original Message----- > > From: Eric Osborne [mailto:eosborne@cisco.com] > > Sent: Wednesday, July 03, 2002 4:01 AM > > To: Gray, Eric > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > Subject: Re: your mail > > > > > > On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > > > Eric, > > > > > > It is in the fact that we have to be sure - > > > just as you suggest. The cost of being sure, however, > > > is that you have to be prepared to deal with occasions > > > when the check fails. What do you do when the higher > > > layer is not UDP or TCP - throw these packets in to a > > > common bucket? What is the expected impact if this > > > traffic might occasionally be significant? > > > > Then you need a better load-balancing algorithm. Either IP SA/DA and > > some randomness, or random sampling from the packet, or (heaven > > forbid) some sort of flow-based scheme. I'm even dubious about the > > efficacy of using TCP/UDP ports to hash, given that most traffic is > > either src or dst TCP port 80, which really only gives you the port in > > the other direction to play with. But that's not really my problem, > > as the implementation I'm familiar with doesn't do anything with > > TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a > > device that does; I just don't deal with it/them). > > > > also, don't forget that this hypothetical algorithm takes into acount > > IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you > > probably have very few flows/conversations/whatnot anyways, and either > > need to move to something like per-packet (ick) or just larger pipes. > > > > > > > > > > eric > > > > > > > > > > > Eric W. Gray > > > > > > > > > -----Original Message----- > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > Sent: Tuesday, July 02, 2002 4:24 PM > > > To: Gray, Eric > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > Subject: Re: your mail > > > > > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > > > Eric, > > > > > > > > To answer your final two questions, yes it probably > > > > is stealing. The fact that you can get away with a crime > > > > does not make it any less a crime. Who knows, some vendors > > > > may not check that the protocol over the top of IP is either > > > > UDP or TCP before using the port numbers. > > > > > > If a vendor checks the offset where the port numbers should be without > > > checking for the correct protocol type, this is a cruddy > > > implementation and shouldn't exist. My question was really along the > > > lines of "what if we use the values that we *know* are UDP/TCP port > > > numbers"? From what you say above, it seems like that might be OK, as > > > long as we only do this when we're sure? Or is there some inherent > > > architectual layer violation thing that you're objecting to? > > > > > > > > > > > > eric > > > > > > > I think you can > > > > easily imagine what that might lead to if a set of packets > > > > carry a higher level protocol where the corresponding fields > > > > may vary from packet to packet in a single micro-flow. The > > > > real question is how common is this? > > > > > > > > Eric W. Gray > > > > Systems Architect > > > > Celox Networks, Inc. > > > > egray@celoxnetworks.com > > > > 508 305 7214 > > > > > > > > > > > > -----Original Message----- > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > Sent: Tuesday, July 02, 2002 1:32 PM > > > > To: Hummel Heinrich > > > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George Sheng; > > > > scullptor@yahoo.com; mpls@UU.NET > > > > Subject: Re: your mail > > > > > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > > > It gets weirder and weirder: The MPLS WG invents a label stack, > but > > > does > > > > not care at all that any of the > > > > > deeper nested labels may ever be signalled/carried by means of a > > > > Label-TLV/object (no public comments to my > > > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > > > > > However it is ok, to "steal" the deepest nested label and call it > > > > "VC-label" for indexing > > > > > some VRF at some remote PE. > > > > > > > > This is not theft; it's using the labels as they were designed. How > > > > is using the bottommost label as a VC-labe/VPN label/whatever > > > > "stealing"? You seem to be attacking the very idea of label stacking, > > > > which is a pretty useful concept. > > > > > > > > > Furthermore it is ok, to "steal" the very same label for hashing. > > > > > > > > > > > > > What about IP router vendors that do load-balancing based on L4/L5 > > > > information like protocol type and port numbers? Is that stealing? > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > Independent from what is clean and what is quick&dirty, I cannot > > detect > > > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > > > > > > > > > Heinrich Hummel > > > > > Siemens > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > > > An: Shahram Davari > > > > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > > > > Betreff: Re: your mail > > > > > > > > > > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress > > ports. > > > > This > > > > > Shahram> assignment is the hash state that I said you need. > > > > > > > > > > A hash is a function that maps some sequence of octets into a > > > sequence > > > > of > > > > > integers. If you want to split traffic over six paths, while > > ensuring > > > > that > > > > > all packets with the same bottom label travel the same path, you > > > need > > > > a > > > > > function that maps a 20 bit quantity into a number from 1-6. > There > > > is > > > > no > > > > > need to maintain state of any kind. > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Wed Jul 3 13:50:00 2002 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 ESMTP id NAA23477 for ; Wed, 3 Jul 2002 13:50:00 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyb07402 for ; Wed, 3 Jul 2002 17:29:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvyb00480; Wed, 3 Jul 2002 17:25:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvyb18031 for mpls-outgoing; Wed, 3 Jul 2002 17:25:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvyb18026 for ; Wed, 3 Jul 2002 17:25: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 QQmvyb03729 for ; Wed, 3 Jul 2002 17:24:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyb29187 for ; Wed, 3 Jul 2002 17:24:51 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmvyb29175 for ; Wed, 3 Jul 2002 17:24:51 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 13:24:51 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267112@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Giles Heron'" Cc: "'MPLS Mailing list'" Subject: RE: your mail Date: Wed, 3 Jul 2002 13:24:48 -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 Giles, I should go into this a bit further. One of the reasons to worry about 'layer violations' (oooh, there's that awful word again :-O) is if there has been a conscious decision to punt specification of some uses of a 'layer' because of its assumed inviolability. In MPLS, there has been at least one such punt - the header compression proposal that George Swallow brought forward some time ago. The working group decided that there was no reason to specify this scheme, since it would take place over MPLS between presumably cooperating systems. This is just one example. Another might be IPv6/MPLS. Who knows how many other things people are looking at (or have looked at) as X/MPLS applications? With MPLS, the working group has repeatedly had to consider whether or not to just change the name of the protocol to IP(v4)LS. So far as I know, this has not yet happened. :-) Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Giles Heron [mailto:giles@packetexchange.net] Sent: Wednesday, July 03, 2002 1:57 PM To: Gray, Eric Cc: 'Kannan "S (Networking) ""- CTD, ""Chennai.'; Eric Osborne; 'MPLS Mailing list' Subject: RE: your mail oops, yeah good point. In this case clearly you *can* still look for an IPv4 header - it is just rather uglier. The trick is to look for the value 0100 in the first 4 bits. The risk is, of course, that there may be a client protocol which also sends this :( Giles On Wed, 2002-07-03 at 16:51, Gray, Eric wrote: > Giles, > > I was responding to this statement: > > > My point is, if it is decided that an LSR is going to look beyond > > whatever depth it is supposed to, the LSR's ECMP hashing function > > might as well look at the IP header instead of looking at the bottom > > most label. > > How does my response to this relate to your comment? :-) > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Wednesday, July 03, 2002 1:01 PM > To: Gray, Eric > Cc: 'Kannan "S (Networking) - CTD, ""Chennai.'; Eric Osborne; 'MPLS Mailing > list' > Subject: RE: your mail > > On Wed, 2002-07-03 at 13:55, Gray, Eric wrote: > [snip] > > Thirdly, it is definitely inappropriate to assume that the > > stuff after the last label is an IP header except in the > > case where the last label is an explicit IPv4 NULL label. > > It could be any of a lot of things otherwise and - given > > PHP and a number of defined MPLS applications - the last > > label is very unlikely to be an IPv4 explicit NULL label. > > Other than Juniper's CCC (which is dependent on RSVP-TE) I'm not aware > of any application putting non-IP traffic directly over an LSP (i.e. > without using a label stack). > > Therefore when there is only one label (other than when an egress LSR > using PHP receives a packet - in which case load balancing is somewhat > moot) I think we can assume that the payload is IP? > > Giles > > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > -----Original Message----- > > From: Kannan S (Networking) - CTD, Chennai. > [mailto:kannans@ctd.hcltech.com] > > > > Sent: Wednesday, July 03, 2002 3:25 AM > > To: Eric Osborne > > Cc: 'MPLS Mailing list' > > Subject: RE: your mail > > > > Eric, > > > > About the idea of using the bottom most label for doing ECMP - > > > > Wouldnt that restrict the ECMP hashing function, because my hashing > function > > is now totally dependent on how some router in the edge chose to identify > a > > flow? > > > > For example, suppose an ingress edge LSR marked the bottom most label > using > > say first 10 bits of the IP - SA, and last 10 bits of IP - DA, then I cant > > have an hashing algorithm which uses last 10 bits of IP - SA, and first 10 > > bits of IP - DA, right ? The efficiency of the algorithm (the choice > > itself) is now very dependent on how the edge LSR identifies flows. > > > > My point is, if it is decided that an LSR is going to look beyond whatever > > depth it is supposed to, the LSR's ECMP hashing function might as well > look > > at the IP header instead of looking at the bottom most label. > > > > Am I missing something here? > > > > Thanks, > > Kans. > > > > -----Original Message----- > > From: Eric Osborne [mailto:eosborne@cisco.com] > > Sent: Wednesday, July 03, 2002 4:01 AM > > To: Gray, Eric > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > Subject: Re: your mail > > > > > > On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > > > Eric, > > > > > > It is in the fact that we have to be sure - > > > just as you suggest. The cost of being sure, however, > > > is that you have to be prepared to deal with occasions > > > when the check fails. What do you do when the higher > > > layer is not UDP or TCP - throw these packets in to a > > > common bucket? What is the expected impact if this > > > traffic might occasionally be significant? > > > > Then you need a better load-balancing algorithm. Either IP SA/DA and > > some randomness, or random sampling from the packet, or (heaven > > forbid) some sort of flow-based scheme. I'm even dubious about the > > efficacy of using TCP/UDP ports to hash, given that most traffic is > > either src or dst TCP port 80, which really only gives you the port in > > the other direction to play with. But that's not really my problem, > > as the implementation I'm familiar with doesn't do anything with > > TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a > > device that does; I just don't deal with it/them). > > > > also, don't forget that this hypothetical algorithm takes into acount > > IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you > > probably have very few flows/conversations/whatnot anyways, and either > > need to move to something like per-packet (ick) or just larger pipes. > > > > > > > > > > eric > > > > > > > > > > > Eric W. Gray > > > > > > > > > -----Original Message----- > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > Sent: Tuesday, July 02, 2002 4:24 PM > > > To: Gray, Eric > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > Subject: Re: your mail > > > > > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > > > Eric, > > > > > > > > To answer your final two questions, yes it probably > > > > is stealing. The fact that you can get away with a crime > > > > does not make it any less a crime. Who knows, some vendors > > > > may not check that the protocol over the top of IP is either > > > > UDP or TCP before using the port numbers. > > > > > > If a vendor checks the offset where the port numbers should be without > > > checking for the correct protocol type, this is a cruddy > > > implementation and shouldn't exist. My question was really along the > > > lines of "what if we use the values that we *know* are UDP/TCP port > > > numbers"? From what you say above, it seems like that might be OK, as > > > long as we only do this when we're sure? Or is there some inherent > > > architectual layer violation thing that you're objecting to? > > > > > > > > > > > > eric > > > > > > > I think you can > > > > easily imagine what that might lead to if a set of packets > > > > carry a higher level protocol where the corresponding fields > > > > may vary from packet to packet in a single micro-flow. The > > > > real question is how common is this? > > > > > > > > Eric W. Gray > > > > Systems Architect > > > > Celox Networks, Inc. > > > > egray@celoxnetworks.com > > > > 508 305 7214 > > > > > > > > > > > > -----Original Message----- > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > Sent: Tuesday, July 02, 2002 1:32 PM > > > > To: Hummel Heinrich > > > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George Sheng; > > > > scullptor@yahoo.com; mpls@UU.NET > > > > Subject: Re: your mail > > > > > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > > > It gets weirder and weirder: The MPLS WG invents a label stack, > but > > > does > > > > not care at all that any of the > > > > > deeper nested labels may ever be signalled/carried by means of a > > > > Label-TLV/object (no public comments to my > > > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > > > > > However it is ok, to "steal" the deepest nested label and call it > > > > "VC-label" for indexing > > > > > some VRF at some remote PE. > > > > > > > > This is not theft; it's using the labels as they were designed. How > > > > is using the bottommost label as a VC-labe/VPN label/whatever > > > > "stealing"? You seem to be attacking the very idea of label stacking, > > > > which is a pretty useful concept. > > > > > > > > > Furthermore it is ok, to "steal" the very same label for hashing. > > > > > > > > > > > > > What about IP router vendors that do load-balancing based on L4/L5 > > > > information like protocol type and port numbers? Is that stealing? > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > Independent from what is clean and what is quick&dirty, I cannot > > detect > > > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > > > > > > > > > Heinrich Hummel > > > > > Siemens > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > > > An: Shahram Davari > > > > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > > > > Betreff: Re: your mail > > > > > > > > > > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress > > ports. > > > > This > > > > > Shahram> assignment is the hash state that I said you need. > > > > > > > > > > A hash is a function that maps some sequence of octets into a > > > sequence > > > > of > > > > > integers. If you want to split traffic over six paths, while > > ensuring > > > > that > > > > > all packets with the same bottom label travel the same path, you > > > need > > > > a > > > > > function that maps a 20 bit quantity into a number from 1-6. > There > > > is > > > > no > > > > > need to maintain state of any kind. > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Wed Jul 3 13:50:38 2002 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 ESMTP id NAA23660 for ; Wed, 3 Jul 2002 13:50:38 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxv03338 for ; Wed, 3 Jul 2002 15:59:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvxv00252; Wed, 3 Jul 2002 15:58:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvxv26561 for mpls-outgoing; Wed, 3 Jul 2002 15:57:56 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmvxv26555 for ; Wed, 3 Jul 2002 15:57: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 QQmvxv28234 for ; Wed, 3 Jul 2002 15:57:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxv05947 for ; Wed, 3 Jul 2002 15:57:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvxv05938 for ; Wed, 3 Jul 2002 15:57:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA19315 for ; Wed, 3 Jul 2002 11:57:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA16641 for mpls@uu.net; Wed, 3 Jul 2002 11:57:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvxb14003 for ; Wed, 3 Jul 2002 10:56: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 QQmvxb09013 for ; Wed, 3 Jul 2002 10:56:18 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxb03263 for ; Wed, 3 Jul 2002 10:56:18 GMT Received: from mailhost.metro-optix.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.219.248.6]) id QQmvxb03259 for ; Wed, 3 Jul 2002 10:56:18 GMT Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 05:55:21 -0500 Message-ID: <99EC34181384D611BE56000347227B2C01EAA0@MAILHOSTNB> From: Apratim Mukherjee To: mpls@UU.NET Subject: Lsp teardown initiated by egress. Date: Wed, 3 Jul 2002 16:25:01 -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 Hi , If there are multiple lsps in a session ( FF style and many lsps in RSVP-TE) and egress wants to initiate the teardown of a particular lsp ,it inserts an Admin Status object with R and D bits set in the Resv Message. The ingress will recieve a resv message which contains multiple flow descriptors and only one Admin Status object . How will the ingress know which lsp the egress wants to tear down ? At intermediate nodes , there will be multiple cross-connects , one for each lsp in the session . How will the intermediate node find out for which of the lsps in that session , it should disable the alarm ? Thanks, Apratim From owner-mpls@UU.NET Wed Jul 3 13:54:03 2002 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 ESMTP id NAA24070 for ; Wed, 3 Jul 2002 13:54:02 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyd05337 for ; Wed, 3 Jul 2002 17:54:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvyd27117; Wed, 3 Jul 2002 17:49:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvyd20026 for mpls-outgoing; Wed, 3 Jul 2002 17:48:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmvyd20021 for ; Wed, 3 Jul 2002 17:48: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 QQmvyd09900 for ; Wed, 3 Jul 2002 17:48:33 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyd26314 for ; Wed, 3 Jul 2002 17:48:33 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f192.law12.hotmail.com [64.4.19.192]) id QQmvyd26289 for ; Wed, 3 Jul 2002 17:48:31 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 3 Jul 2002 10:48:31 -0700 Received: from 212.87.114.121 by lw12fd.law12.hotmail.msn.com with HTTP; Wed, 03 Jul 2002 17:48:30 GMT X-Originating-IP: [212.87.114.121] Reply-To: rzappa@ieee.org From: "Rolando Zappacosta" To: Navid_Yazdani@raytheon.com Cc: mpls@UU.NET Subject: Re: QoS Survey Paper Date: Wed, 03 Jul 2002 19:48:30 +0200 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_3bcd_4ea6_17d6" Message-ID: X-OriginalArrivalTime: 03 Jul 2002 17:48:31.0001 (UTC) FILETIME=[D81F2890:01C222B9] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_3bcd_4ea6_17d6 Content-Type: text/plain; format=flowed Navid, I'm currently unemployed and I came to Europe 'cause of a search that finally was cancelled just when I came here. Hence, I'm once again searching for a job. My primary areas of interest are research, development and testing, which was my last one. I know that nowadays it's not so easy as it was to find a job. Do you know about something in America or Europe? Well,... hope not to hind you with my own problem. Sincerely, Rolando. ----Original Message Follows---- From: Ping Pan To: Navid Yazdani CC: mpls@UU.NET Subject: Re: QoS Survey Paper Date: Tue, 02 Jul 2002 10:06:59 -0700 Not sure QoS is actually in the context of MPLS, but please take a look at a survey paper from Roch Guerin and Vinod Peris, "Quality-of-Service in Packet Networks: Basic Mechanisms and Directions" in http://www.seas.upenn.edu/~guerin - Ping Navid Yazdani wrote: >Can anyone recommend a survey paper, article, or book that examines the >advantages and disadvantages of different IP QoS schemes? > >thanks >Navid > > > > _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ------=_NextPart_000_3bcd_4ea6_17d6 Content-Type: application/msword; name="CV14enDA.doc" Content-Disposition: attachment; filename="CV14enDA.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAAeAAAAAAAAAAAEAAAegAAAAEAAAD+////AAAAAHcAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////spcEAWQAKDAAAABK/AAAAAAAAEAAAAAAABAAA SiAAAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAAAAAKDBYAkpMAAJE9AQCR PQEA/xsAAAAAAABKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAA AAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAMAUAAAA AAAAwBQAAMAUAAAAAAAAwBQAAAAAAADAFAAAAAAAAMAUAAAAAAAAwBQAABQA AAAAAAAAAAAAANQUAAAAAAAA1BQAAAAAAADUFAAAAAAAANQUAAA4AAAADBUA ABwAAAAoFQAATAAAANQUAAAAAAAASzQAACwCAACgFQAAAAAAAKAVAAAAAAAA oBUAAAAAAACgFQAAAAAAAKAVAAAAAAAAcxcAAAAAAABzFwAAAAAAAHMXAAAA AAAAEDQAAAIAAAASNAAAAAAAABI0AAAAAAAAEjQAAAAAAAASNAAAAAAAABI0 AAAAAAAAEjQAACQAAAB3NgAA9AEAAGs4AACMAAAANjQAABUAAAAAAAAAAAAA AAAAAAAAAAAAwBQAAAAAAABzFwAAAAAAAAAAAAAAAAAAAAAAAAAAAABRFwAA IgAAAHMXAAAAAAAAcxcAAAAAAABzFwAAAAAAADY0AAAAAAAAXxgAAAAAAADA FAAAAAAAAMAUAAAAAAAAoBUAAAAAAAAAAAAAAAAAAKAVAACxAQAAoBUAAAAA AABfGAAAAAAAAF8YAAAAAAAAXxgAAAAAAABzFwAAdgAAAMAUAAAAAAAAoBUA AAAAAADAFAAAAAAAAKAVAAAAAAAAEDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 1BQAAAAAAADUFAAAAAAAAMAUAAAAAAAAwBQAAAAAAADAFAAAAAAAAMAUAAAA AAAAcxcAAAAAAAAQNAAAAAAAAF8YAACgAwAAXxgAAAAAAAD/GwAAzgUAAHgv AAAoBAAAwBQAAAAAAADAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDQAAAAAAACgFQAA AAAAAHQVAAAsAAAAoACqxUEcwgHUFAAAAAAAANQUAAAAAAAA6RcAAHYAAACg MwAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAUm9sYW5kbyBKb3JnZSBaYXBwYWNvc3RhDQ0IDUNhY2VyZXMgNDEs IDJBDTI4MDQ1LCBNYWRyaWQNU1BBSU4NZS1tYWlsOiByemFwcGFAaWVlZS5v cmcsIHphcHBhY29yQGhvdG1haWwuY29tDQ0NUEVSU09OQUw6Bw1CaXJ0aCBk YXRlOiBNYXJjaCA2LCAxOTcyDUNpdGl6ZW5zaGlwczoNSXRhbHk6IDAxOTY0 MUwNU3BhaW46IFgtNDM1OTI2OS1YDU1hcml0YWwgc2l0dWF0aW9uOiBTaW5n bGUNTWVtYmVyc2hpcHM6DUlFRUUgYW5kIElFRUUgQ29tbXVuaWNhdGlvbnMg U29jaWV0eTogTWVtYmVyIDQxMjg1ODc1DUlFVEY6IFN1Yi1JUCBBcmVhLCBN UExTIFdvcmtpbmcgR3JvdXANTGFuZ3VhZ2VzOg1TcGFuaXNoOiBuYXRpdmUN RW5nbGlzaDogVG90YWwgY29tbWFuZC4gVGVzdCBvZiBFbmdsaXNoIGZvciBJ bnRlcm5hdGlvbmFsIENvbW11bmljYXRpb24gKFRPRUlDKSBzY29yZToNTGlz dGVuaW5nOiA0MDUvNDk1DVJlYWRpbmc6IDQxMC80OTUNSXRhbGlhbjogYmFz aWMNUG9ydHVndWVzZTogYmFzaWMNSG9iYmllczoNQmljeWNsaW5nDU91dGRv b3Igc3BvcnRzDUFtYXRldXIgUmFkaW8NVHJhdmVsaW5nLg0HBw1PQkpFQ1RJ VkU6Bw1UbyBvYnRhaW4gYSBwb3NpdGlvbiB3aXRoaW4gYSB0b3AgY3JlYXRp dmUgYW5kIGdyb3dpbmcgZmlybSByZWFkeSB0byBvZmZlciBjaGFsbGVuZ2Vz IGFuZCBwcm9mZXNzaW9uYWwgZXZvbHV0aW9uIHRoYXQgd2lsbCBhbGxvdyBt ZSB0byBleHBhbmQgdXBvbiBteSBleHBlcmllbmNlIGFuZCBjb250aW51ZSB0 byBhY2N1bXVsYXRlIGtub3dsZWRnZS4NBwcNRVhQRVJJRU5DRToHDVRlbGVm b25pY2E6IE1hcmNoIDE5OTkgliBKYW51YXJ5IDIwMDINCVJlc3BvbnNpYmls aXRpZXMgd2VyZSB0YWtlbiBhdCB0aGUgTGFib3JhdG9yeSBBcmVhLCBhIGtl eSBzZWN0b3Igbm90IG9ubHkgZm9yIGZ1dHVyZSBlbmhhbmNlbWVudHMgYnV0 IGFsc28gZm9yIHRoZSBwcmVzZW50IG9wZXJhdGlvbnMgb2YgdGhhdCB0ZWxl L2RhdGFjb21tIGNvbXBhbnksIHdoaWNoIGlzIGEgc3Vic2lkaWFyeSBvZiBU ZWxlZm9uaWNhIEludGVybmFjaW9uYWwsIG9uZSBvZiB0aGUgbW9zdCBpbXBv cnRhbnQgdGVsZWNvbW11bmljYXRpb25zIGhvbGRpbmdzIGluIEV1cm9wZSBh bmQgYWxsIGFyb3VuZCBMYXRpbiBBbWVyaWNhLg0JVGhpcyBwb3NpdGlvbiB3 YXMgbWFpbmx5IHJlbGF0ZWQgd2l0aCB0YXNrcyBpbiB0aGUgZmllbGQgb2Yg Y29yZSBhbmQgYm9yZGVyIElQIHJvdXRpbmcgYW5kIE1QTFMgc3dpdGNoaW5n IHVzaW5nIEFUTSBhbmQgUE9TLCBidXQgaXQgYWxzbyBpbXBsaWVkIHBhcnRp Y2lwYXRpb24gaW4gSVAgVGVsZXBob255IChOR04sIFZvSVApLCBJbnRlbGxp Z2VudCBOZXR3b3JrcyBhbmQgSVNETiB0ZXN0IHRyaWFscy4NCUR1dGllcyBp bnZvbHZlZCB3ZXJlIHRlc3QgbGlzdHMgZGV2aXNpbmcsIHRoZSBwcm9jZWR1 cmVzIG9uIHRoZW0gZXhwbGFpbmVkIGV4ZWN1dGlvbiwgdGhlaXIgcmVzdWx0 cyBwcmVzZW50YXRpb24gYW5kIHRoZWlyIHRlY2huaWNhbCwgZWNvbm9taWNh bCBhbmQgZGVidWdnaW5nIHJlY29tbWVuZGF0aW9ucyB3cml0aW5nLiBBbHNv LCBkdWUgdG8gYW4gaW4tZGVwdGggdGVjaG5pY2FsIGtub3dsZWRnZSBvbiB0 aG9zZSB0aGVtZXMsIGl0IHdhcyB1c3VhbCB0byBoYXZlIHRvIGRpc2Nsb3Nl IGNvdXJzZXMgYWJvdXQgdGhlIGltcGxpZWQgZGV2aWNlcyBhbmQgdGVjaG5v bG9naWVzIGFzIHdlbGwgYXMgdGhlaXIgdGVzdCBjb25jbHVzaW9ucy4NU2tp bGxzIGFjaGlldmVkOg1Qcm92aWRlcnMgc2hvcnQgbGlzdHMgZ2VuZXJhdGlv biBieSBtZWFucyBvZiB0ZWNobmljYWwgYW5kIGVjb25vbWljYWwgYXNwZWN0 cyBhbmFseXNpcw1UZXN0IGxpc3RzIHdyaXRpbmcgYW5kIGV4ZWN1dGlvbiBh cyB3ZWxsIGFzIGRvY3VtZW50YXRpb24gb2YgaXRzIHJlc3VsdHMNVGVzdCBz Y2VuYXJpb3Mgc2V0IHVwIGFuZCB0ZXN0IGJlZCBjb25maWd1cmF0aW9uDURl bGl2ZXJpbmcgb2YgcHJlc2VudGF0aW9ucyBhbmQgY291cnNlcyB0byBzbWFs bCBhbmQgbWVkaXVtIGF1ZGllbmNlcw1NUExTIGFuZCBpdHMgcHJvdG9jb2xz OiBURFAsIExEUCwgUlNWUC1URSwgTVAtQkdQLCBldGMuDVNldmVyYWwgb3Ro ZXJzIElQIHByb3RvY29sczogUFBQLCBDSEFQLCBQQVAsIEwyVFAsIFBQVFAs IEdSRSwgTUxQUCwgUkFESVVTLCBldGMuDVZQTpJzIGJ5IG1lYW5zIG9mIElQ IGFuZCBNUExTDVFvUyBhbmQgdHJhZmZpYyBlbmdpbmVlcmluZw1JUCBNdWx0 aWNhc3QNU09ORVQvU0RILCBTVE1uL09DbiwgQURNcyBhbmQgUE9TDUFkdmFu Y2VkIHRlc3Qgc3lzdGVtcyBvcGVyYXRpb24sIHN1Y2ggYXMgQWdpbGVudCBS b3V0ZXIgVGVzdGVyLCBTcGlyZW50IFNtYXJ0Yml0cyBhbmQgQWdpbGVudCBC U1RTLiBBbHNvIFRla2VsZWMgTUdUUywgaU5FVCBTcGVjdHJhIGFuZCBUZWtl bGVjIENoYW1lbGVvbiAzMiBhcyB3ZWxsIGFzIGxlc3MgY29tcGxleCBvbmVz IGxpa2UgV1dHIElCVDEwIGFuZCBJQlQ1LCBDb25zdWx0cm9uaWNzIENvQlJB LCBzb21lIG9wdGljYWwgcG93ZXIgbWV0ZXJzIGFuZCBTcGlyZW50IGFuZCBD b25zdWx0cm9uaWNzIElTRE4gYW5kIHhEU0wgd2lyZWxpbmUgc2ltdWxhdG9y cyBiZXR3ZWVuIG90aGVycw1DYXJyaWVyLWNsYXNzIGNvcmUgYW5kIGVkZ2Ug cm91dGVycyBvcGVyYXRpb246IFNlcmllcyAxMjAwMCwgMTI0MDAgYW5kIDEw MDAwIGZyb20gQ2lzY287IEVSWDcwMCBhbmQgRVJYMTQwMCBmcm9tIFVuaXNw aGVyZSBhbmQgTTE2MCwgTTQwLCBNMjAsIE0xMCBhbmQgTTUgZnJvbSBKdW5p cGVyDUFUTSBub2RlczogQ2lzY28gTUdYIGFuZCBCUFgNQ29udGVudCBkZWxp dmVyeSBkZXZpY2VzIChjYWNoZXMgYW5kIGxvYWQgYmFsYW5jZXJzKQ1BY2Nl c3Mgc2VydmVycywgc3VjaCBhcyBDaXNjb5JzIEFTNTMwMCBhbmQgQVM1NDAw DUlQIFRlbGVwaG9ueSAoTkdOKSBhbmQgVm9JUCBwcm90b2NvbHM6IEguMzIz LCBNR0NQLCBTSVAsIE1FR0FDTy9ILjI0OA1DYXJyaWVyIGNsYXNzIE1HknMs IE1HQ5JzIGFuZCBDYWxsIEFnZW50cyBvcGVyYXRpb24NVGVsZXBob255IHNp Z25hbGluZyBwcm90b2NvbHM6IFNTNywgTUZDIFIyDUFsbCBJU0ROIGxheWVy cyBhbmQgUE9UUw1JbnRlbGxpZ2VudCBOZXR3b3JrcyBvcGVyYXRpb24ga25v d2xlZGdlIChTQ1CScywgU1NQknMsIFNNUJJzLCBldGMpDVNRTA1JU0ROIGRl dmljZXMgZnJvbSB2YXJpb3VzIHByb3ZpZGVycy4gRm9yIGluc3RhbmNlLCBk YXRhIGxpbmsgYmFja3VwcywgbW9kZW1zLCBUQZJzLCBOVJJzLCBUQStOVJJz LCBQaWN0dXJlVGVsIGFwcGxpYW5jZXMsIElTRE4gRG9EIElQIHJvdXRlciBs aW5rcywgZXRjLg1CYW5rQm9zdG9uOiBBdWd1c3QgMTk5NiCWIE1hcmNoIDE5 OTkNCVdvcmtpbmcgYXQgdGhlIFRlY2huaWNhbCBTdXBwb3J0IE9mZmljZS4g TGF0ZWx5IGFzIFRlYW0gTGVhZGVyIGluIHRoZSBuZXR3b3JrIGVxdWlwbWVu dCBzZXR1cCBzdGFmZiBmb3IgdGhlIGJyYW5jaGVzIHRoYXQgdGhlIEJhbmsg d2FzIG9wZW5pbmcsIHBvc2l0aW9uIHRoYXQgaW1wbGllZCBzdWdnZXN0aW9u cyBhbmQgZHV0aWVzIGRlbGVnYXRpb24gdG8gb3RoZXIgdGVhbXMsIGVtcGxv eWVlcyByZWxhdGlvbnMgbWFuYWdpbmcgYW5kIGdyb3VwIHBlcnNvbm5lbCBj b29yZGluYXRpb24uIEJlZm9yZSB0aGlzLCBpbiBqb2JzIHJlbGF0ZWQgZnVu ZGFtZW50YWxseSB3aXRoIHRoZSBUb2tlbiBSaW5nIG5ldHdvcmsgc3RhcnR1 cCBhbmQgb3BlcmF0aW9uIGF0IHRoZSBCYW5rIGhlYWRxdWFydGVycyBhbmQg bmVhcmJ5IGJ1aWxkaW5ncywgYWx0aG91Z2ggbWFpbmx5IGluIHRoZSBjb21w dXRpbmcgYW5kIGNvbW11bmljYXRpb25zIGNlbnRlcnMgb2YgdGhlIGZvcm1l ci4gDQlCZXNpZGVzLCBhZnRlciBhIHdlbGwtZG9uZSBqb2IgSSBvYnRhaW5l ZCBhIJNTZXJ2aWNpbyBDdW1icmWULCB3aGljaCBpcyBhbiBob25vciBhd2Fy ZCBncmFudGVkIHRvIHJlY29nbml6ZSB0aGUgZW1wbG95ZWVzkiBleGNlbGxl bmNlLg1Ta2lsbHMgYWNoaWV2ZWQ6DVRlYW13b3JrIGV4cGVyaWVuY2VzIGFu ZCBzdGFmZiBtb3RpdmF0aW5nIHRvIGF0dGFpbiBnb2Fscw1JUCBhbmQgaXRz IElHUJJzIGFuZCBFR1CScyByb3V0aW5nIHByb3RvY29scyAoT1NQRiwgQkdQ LCBSSVAgYW5kIEVJR1JQKQ1BZHZhbmNlZCBMQU4vV0FOIHRlY2hub2xvZ2ll cyBhbmQgcHJvdG9jb2xzIGtub3dsZWRnZQ1FMS9UMSwgRTMvVDMgYW5kIFNU TTEgc3RhbmRhcmRzDVNlY3VyaXR5IGNvbmNlcHRzIGFuZCBmaXJld2FsbHMN SFAgT3BlblZpZXcgYW5kIFRpdm9saQ1Ub2tlbiBSaW5nIExBTiB0b3BvbG9n aWVzLCBpbmNsdWRpbmcgZmliZXItb3B0aWNzIGJhY2tib25lLCBIVUKScywg YnJpZGdlcywgcm91dGVycyBhbmQgZ2F0ZXdheXMNQVRNIGFuZCBGcmFtZSBS ZWxheQ1XQU4gbGlua3M6IG1vZGVtcywgQ1BFknMsIE1haW5TdHJlZXQgKE5l d0JyaWRnZSkgZGV2aWNlcywgZXRjLg1BZ2lsZW50IEludGVybmV0IEFkdmlz b3IuDUNPTVBBUSBBdXRob3JpemVkIEN1c3RvbWVyIFN1cHBvcnQgQ2VudGVy OiBKdW5lIDE5OTIgliBEZWNlbWJlciAxOTkzDQlQb3NpdGlvbiBvYnRhaW5l ZCBkdWUgdG8gYSA2LW1vbnRocyBpbnRlcm5zaGlwIHJlbmV3ZWQgdHdpY2Uu IFRoZSBwb3NpdGlvbiBpbnZvbHZlZCB0aGUgaGFyZHdhcmUgYW5kIHNvZnR3 YXJlIG9yZ2FuaXppbmcsIHBsYW5uaW5nIGFuZCBpbnN0YWxsYXRpb24gbmVl ZGVkIGZvciBFdGhlcm5ldCBuZXR3b3JrcyBhcyB3ZWxsIGFzIHRoZWlyIGFz c29jaWF0ZWQgY29tcHV0ZXJzIGFuZCBwZXJpcGhlcmFscyBjb25uZWN0aXZp dHkuDVNraWxscyBhY2hpZXZlZDoNQ29heCBhbmQgVVRQIG5ldHdvcmtzIGNh YmxpbmcNU3RydWN0dXJlZCBjYWJsaW5nDUxBTiBTd2l0Y2hpbmcNTEFOIGRl dmljZXMsIHN1Y2ggYXMgSFVCknMsIGJyaWRnZXMgYW5kIHN3aXRjaGVzDVBD J3Mgc2VydmljaW5nDUlQWCBhbmQgU1BYDUV0aGVyTmV0IExBTpJzIHByb2pl Y3QgYW5kIGluc3RhbGxhdGlvbiB3aXRoIFBDknMgYW5kIGhpZ2gtZW5kIHNl cnZlcnMsIHByaW1hcmlseSB1c2luZyBOb3ZlbGwgTmV0d2FyZQ1Ob3ZlbGwg TmV0d2FyZS4NBwcNRURVQ0FUSU9OOgcNVGVjbmljbyBVbml2ZXJzaXRhcmlv IGVuIEVsZWN0cm9uaWNhOiBjb3Vyc2UgcHJvZ3JhbXMgYW5kIHRpbWUgbGVu Z3RoIGVxdWl2YWxlbnQgdG8gYSBCYWNoZWxvcnMgb2YgU2NpZW5jZSBkZWdy ZWUuDUluc3RpdHV0aW9uIGFuZCBncmFkdWF0aW9uIGRhdGU6IFVuaXZlcnNp ZGFkIFRlY25vbG9naWNhIE5hY2lvbmFsLCAyMS8yLzE5OTYNSW5nZW5pZXJv IGVuIEVsZWN0cm9uaWNhOiBlcXVpdmFsZW50IHRvIGEgTWFzdGVyIG9mIFNj aWVuY2UgZGVncmVlLg1JbnN0aXR1dGlvbiBhbmQgZ3JhZHVhdGlvbiBkYXRl OiBVbml2ZXJzaWRhZCBUZWNub2xvZ2ljYSBOYWNpb25hbCwgMjMvMTIvMTk5 Nw1Ib25vcnM6DVRlc3RzIGF2ZXJhZ2UgKHJhbmdpbmcgZnJvbSAwIHRvIDEw LCB3b3JzdCB0byBiZXN0KTogOC4yNQ1UaGlyZCB0ZXN0cyBhdmVyYWdlIG9m IHRoZSBncmFkdWF0aW9uDU1vc3Qgb3V0c3RhbmRpbmcgYWNhZGVtaWMgcGVy Zm9ybWFuY2Ugd2hpbGUgd29ya2luZyBmdWxsLXRpbWUuDQcHDUNPVVJTRVM6 Bw1DSVNDTyBHU1IgTWFuYWdlcjogSnVuZSAyMDAxLCBhdCBTb2Z0TmV0DUNJ U0NPIENvbmZpZ3VyaW5nIEdTUjEyMDAwIFNlcmllczogTWF5IDIwMDEsIGF0 IFNvZnROZXQNQ0lTQ08gU3lzdGVtc5IgTUdYIEFjY2VzcyBDb25jZW50cmF0 b3IgQ29uZmlndXJhdGlvbjogTWFyY2ggMjAwMSwgYXQgSVQgQ29sbGVnZQ1D SVNDTyBHU1IxMjAwMC8xMjQwMCBTZXJpZXM6IEphbnVhcnkgMjAwMSwgYXQg Q0lTQ08gU2FuIFBhYmxvDVNTNyBhbmQgSVNETiBzaWduYWxpbmc6IEF0IHRo ZSB0cmFpbmluZyBvZmZpY2Ugb2YgVGVsZWZvbmljYQ1VTklYOiBKdWx5IDE5 OTksIGF0IHRoZSB0cmFpbmluZyBvZmZpY2Ugb2YgVGVsZWZvbmljYQ1Fbmds aXNoIGFzIGEgU2Vjb25kIExhbmd1YWdlOiBGZWJydWFyeSAxOTk5LCBpbiBO ZXd0b24sIE1BLiBBdHRlbmRlZCBhdCBFbWJhc3N5IENFUyB3aGlsZSBzdGF5 aW5nIGF0IHRoZSBDb2xsZWdlIGRvcm1zIHdpdGggQW1lcmljYW4gc3R1ZGVu dHMNTWljcm9zb2Z0IE5ldHdvcmsgRXNzZW50aWFsczogQXMgcGFydCBvZiB0 aGUgTWljcm9zb2Z0IENlcnRpZmllZCBTeXN0ZW0gRW5naW5lZXIgY2FyZWVy DU9TLzIgVjIuMTEsIE9TLzIgV2FycCwgYW5kIE9TLzIgTGFuU2VydmVyOiBG ZWJydWFyeSAtIEFwcmlsIDE5OTcsIGF0IHRoZSBMQU4gTWFuYWdlciBPZmZp Y2Ugb2YgQmFua0Jvc3Rvbg1Xb3JraW5nIGNvbmRpdGlvbnMgYW5kIGVudmly b25tZW50OiBPY3RvYmVyIDE5OTAsIHdpdGggTUFQRlJFIEZvdW5kYXRpb24g KGZyb20gU3BhaW4pIHRlYWNoZXJzLCBhdCBDb2xlZ2lvIFByb2Zlc2lvbmFs IGRlIEhpZ2llbmUgeSBTZWd1cmlkYWQgSW5kdXN0cmlhbC4NUm9ib3RpY3M6 IEp1bmUgMTk4OCwgYXQgVW5pdmVyc2lkYWQgTmFjaW9uYWwgZGUgTG9tYXMg ZGUgWmFtb3JhIHVuZGVyIHRoZSBTZWNyZXRhcmlhIGRlIENpZW5jaWEgeSBU ZWNuaWNhIHN1cGVydmlzaW9uLg0HBw1DT01QVVRFUiBTS0lMTFM6Bw1VTklY DU1pY3Jvc29mdCBXaW5kb3dzIHBsYXRmb3JtczogJzk1LCAnOTgsIDIwMDAg YW5kIE5UDU1pY3Jvc29mdCBPZmZpY2U6IFdvcmQsIFBvd2VyUG9pbnQsIEFj Y2VzcyBhbmQgRXhjZWwNUHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLCBmdW5kYW1l bnRhbGx5IFZpc3VhbCBCYXNpYyBhbmQgQysrDUUtbWFpbCBhbmQgSW50ZXJu ZXQgYnJvd3NlcnMuDQcHDVNUUkVOR1RIUzoHDUNyZWF0aXZpdHkgYW5kIGRl ZGljYXRpb24gYXJlIG15IGdyZWF0ZXN0IHN0cmVuZ3Rocw1NeSBvcmdhbml6 YXRpb25hbCBza2lsbHMgYW5kIHN0dWRpb3VzIG5hdHVyZSBhbGxvdyBtZSBl eGNlbCBhdCB3aGF0ZXZlciBJIGRvDUkgYW0gYWJsZSB0byB1bmRlcnN0YW5k IGFuZCB3b3JrIHdpdGggbmV3IHRlY2hub2xvZ2llcyBxdWlja2x5IGFuZCBl ZmZlY3RpdmVseQ1UcmF2ZWxpbmcgZW5hYmxlZCBtZSB0byBleHBhbmQgbXkg b3V0bG9vayBvbiBsaWZlIGFzIEkgaGF2ZSBlbmNvdW50ZXJlZCBtYW55IHZh bHVhYmxlIGV4cGVyaWVuY2VzLg0HBw1SRUZFUkVOQ0VTOgcNQXZhaWxhYmxl IHVwb24gcmVxdWVzdC4NBwcNUm9sYW5kbyBaYXBwYWNvc3RhDXJ6YXBwYUBp ZWVlLm9yZw0NUm9sYW5kbyBaYXBwYWNvc3RhDXJ6YXBwYUBpbmFtZS5jb20N DQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABAAAGQQAABoEAAAbBAAAHAQAAG0EAABuBAAAbwQA AHkEAAB6BAAAhQQAAJMEAACUBAAAoQQAAKIEAACwBAAAsQQAAMMEAADEBAAA 1gQAAN0EAADeBAAA6gQAAOsEAAAgBQAAIQUAAEYFAABHBQAAUgUAAGEFAABi BQAAywUAAMwFAADcBQAA3QUAAOsFAADsBQAA/QUAAP4FAAAGBgAABwYAABAG AAARBgAAHwYAACAGAAAtBgAALgYAADgGAAA6BgAAOwYAADwGAABHBgAASAYA AA4HAAASBwAAHgcAAB8HAAAqBwAARQcAAEYHAAB8CAAA+/Hk29LJwby2rqfB rqCnwafBrqfBrqCnwafBrqfBp8GnwafBp8GuoKfBp8GnwafBp8G8wafBvKeu p5mnAAAMT0oEAFFKBABtSAoEAAxPSgIAUUoCAG1ICQQADE9KBABRSgQAbUgJ BAAPNQiBT0oCAFFKAgBtSAkECzUIgU9KBABRSgQACE9KAgBRSgIAAA81CIFP SgQAUUoEAG1ICQQQQ0ocAE9KBABRSgQAbUgJBAAQQ0ocAE9KAgBRSgIAbUgJ BAAQQ0oYAE9KBABRSgQAbUgJBAAZA2oAAAAAQ0oYAE9KBABRSgQAVQgBbUgJ BBM1CIFDSiAAT0oEAFFKBABtSAkECE9KAwBRSgMAPAAEAAAZBAAAGgQAABwE AAArBAAAOQQAAD8EAABtBAAAbgQAAG8EAAB5BAAAegQAAJQEAACiBAAAsQQA AMQEAADeBAAA6wQAACEFAABHBQAAUgUAAP0AAAAAAAAAAAAAAADyAAAAAAAA AAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA 6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA3AAAAAAA AAAAAAAAANkAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAzAAAAAAAAAAAAAAA AMwAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAAwgAAAAAAAAAAAAAAALgAAAAA AAAAAAAAAADMAAAAAAAAAAAAAAAAwgAAAAAAAAAAAAAAAMIAAAAAAAAAAAAA AAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAMk AwomAAtGAwAWJAFAJgAKAAADJAMKJgALRiQAD4TQAhYkAQgAAAMkAwomAAtG AwAWJAEABAEAAyQDFiQBAwEAFiQBBgAAAyQDFiQBQCYAAAYAAAMkAQ+EHAFA JgAFAAAPhBwBQCYAAAMAAA+EHAEACgAAAyQBD4QcAUAmAA3GBQABMweAAAEQ AAAUAAQAABkEAAAaBAAAHAQAACsEAAA5BAAAPwQAAG0EAABuBAAAbwQAAHkE AAB6BAAAlAQAAKIEAACxBAAAxAQAAN4EAADrBAAAIQUAAEcFAABSBQAAYgUA ALkFAADMBQAA3QUAAOwFAAD+BQAABwYAAPz69/Tx+vr67OXe1szEurCmnJKI gHhwZlxSSAAAAAAAEwMBBQoGb/7//wgDAAkBCgUAAAATAwEFCgaB/v//CCcA CQEKAgAAABMDAQUKBpD+//8IJwAJAQoBAAAAEwMBBQoGof7//wglAAkBCgEA AAAOAwEFCga0/v//CCUACQEADgMBBQoGC////wgmAAkBAA4DAQUKBhv///8I JwAJAQATAwEFCgYm////CAMACQEKBAAAABMDAQUKBkz///8IJAAJAQoDAAAA EwMBBQoGgv///wgkAAkBCgIAAAATAwEFCgaP////CAMACQEKAwAAABMDAQUK Bqn///8IAwAJAQoCAAAAEwMBBQoGvP///wgkAAkBCgEAAAAOAwEFCgbL//// CCQACQEAEwMBBQoG2f///wgDAAkBCgEAAAAOAwEFCgbz////CAMACQEADAIB AAMBBQoG9P///wAMAgEAAwEFCgb+////AAkDAQUKBv////8FBu7///8FBv3/ //8FBv////8CBQAABQIQAAUAABtSBQAAYgUAALkFAADMBQAA3QUAAOwFAAD+ BQAABwYAABEGAAAgBgAALgYAADkGAAA6BgAAOwYAADwGAABHBgAASAYAAPMA AAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAA AAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADJ AAAAAAAAAAAAAAAAyQAAAAAAAAAAAAAAAMkAAAAAAAAAAAAAAADJAAAAAAAA AAAAAAAAwwAAAAAAAAAAAAAAAJNYAwAAAAAAAAAAAADDAAAAAAAAAAAAAAAA kAAAAAAAAAAAAAAAAIsAAAAAAAAAAAAAAAAAAAAEAAADJAMWJAEDAQAWJAEA LwAAFiQBFyQBApZGAAeUDwIF1hgAAAAAAAAAAAAAAAAAAAAAGBgAAAAAAAAI 1jAAArr/TwjMIgAGlQgYGAAAAAAAABgYAAAAAAAAAAZ9GhgYAAAAAAAAGBgA AAAAAAAGAAADJAMWJAFAJgAKAAADJAMKJgALRiQAD4TQAhYkAQgAAAMkAwom AAtGAwAWJAEACwAAAyQDCiYAC0YlAA+EOAQWJAFAJgAACwAAAyQDCiYAC0Ym AA+E0AIWJAFAJgAACwAAAyQDCiYAC0YnAA+E0AIWJAFAJgAAEAcGAAARBgAA IAYAAC4GAAA5BgAAOgYAADsGAAA8BgAARwYAAEgGAAAPBwAAEAcAABEHAAAS BwAAHgcAAB8HAABFBwAAfAgAAGQJAADSCgAA4woAADoLAACDCwAAtAsAAPoL AAAyDAAAgwwAAKEMAAC9DAAAygwAAOwMAAA9DgAA5A4AAAEPAAA2DwAAaA8A AK4PAADiDwAADRAAACYQAABqEAAAbhAAAAcRAAAsEQAAHBMAAKQTAAC1EwAA 7xMAADcUAABtFAAAjRQAAK0UAADEFAAAJRUAADkVAAB4FQAA9evh19LOycK9 tbCsqaWhnKmpqamXl5eXl5eXl5eXl5eXl5eXl5eXl5eXkqmpqY2NjY2NjY2N jQAAAAkDAQUKCBwACQEJAwEFCggdAAkBCQMBBQoIGgAJAQkDAQUKCAcACQEH AhEAAwEFCgcCAQADAQUKBAMBBQoABwMBBl39//8JAwEFCgZe/f//DgMBBQoG Jf7//wgKAAkBAAkDAQUKBib+//8MAgEAAwEFCgYx/v//AAkDAQUKBjL+//8H AwEGM/7//wkDAQUKBjT+//8TAwEFCgY//v//CCQACQEKBwAAABMDAQUKBk3+ //8IJAAJAQoGAAAAEwMBBQoGXP7//wgkAAkBCgUAAAATAwEFCgZm/v//CCQA CQEKBAAAAAA3SAYAAA8HAAAQBwAAEQcAABIHAAAeBwAAHwcAAEUHAAB8CAAA ZAkAANIKAADjCgAAOgsAAIMLAAC0CwAA+gsAADIMAACDDAAA9wAAAAAAAAAA AAAAAPIAAAAAAAAAAAAAAADCREMAAAAAAAAAAAAAvAAAAAAAAAAAAAAAALkA AAAAAAAAAAAAAACwAAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAAAKEAAAAAAAAA AAAAAAChAAAAAAAAAAAAAAAAoQAAAAAAAAAAAAAAAKEAAAAAAAAAAAAAAACX AAAAAAAAAAAAAAAAlwAAAAAAAAAAAAAAAJcAAAAAAAAAAAAAAACXAAAAAAAA AAAAAAAAlwAAAAAAAAAAAAAAAJcAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAD JAMKJgALRhoAD4TQAhYkAQAGAAADJAMPhGgBFiQBCAAAAyQDCiYAC0YHABYk AQkRAAMkAxYkAQ3GBgJDEYYiAAMBABYkAQYAAAMkAxYkAUAmAAAvAAAWJAEX JAEClkYAB5QPAgXWGAAAAAAAAAAAAAAAAAAAAAAYGAAAAAAAAAjWMAACuv9P CMwiAAaVCBgYAAAAAAAAAAAAAAAAAAAABn0aGBgAAAAAAAAAAAAAAAAAAAAE AAADJAMWJAEIAAADJAMKJgALRgoAFiQBABF8CAAAfQgAAGQJAABlCQAA0goA AOIKAAAHEQAAEhEAACwRAAAtEQAAHBMAAB0TAACkEwAAtBMAAJIVAAC8FQAA 1xUAANgVAADNFgAA3RYAAOIXAADjFwAA7hcAAO8XAAAUGAAAYRgAAGIYAACv GAAAyBgAAPIYAADzGAAAQBkAAEEZAABIGQAASRkAAIIZAACDGQAAqBkAAKkZ AADnGQAA6xkAAPQZAAD1GQAABxoAAB0aAAAeGgAAQBoAAFUaAABWGgAAixoA AKUaAACmGgAAwhoAAOMaAADkGgAA+xoAACAbAAAhGwAAJhsAAFYbAABXGwAA dBsAAOQbAADlGwAAAhwAAD0cAABnHAAApxwAAMocAABBHQAASh0AALgdAAC5 HQAAuh0AALsdAADMHQAAcx4AAHQeAACRHgAAkx4AAJQeAACVHgAAoB4AANYf AADXHwAA+fL58ury4vL58vny6vLi8vny6vLa1dri8try4vLa8trq2vLa8try 2tXy4vLa4vLa4vLa4vLa4vLa4vLa4vLa4vLi8uLy4vLa8trV8try2vLa1fLa AAAIT0oCAFFKAgAADzUIgU9KBABRSgQAbUgJBA81CIFPSgIAUUoCAG1ICQQP PioBT0oEAFFKBABtSAkEDE9KBABRSgQAbUgJBAAMT0oEAFFKBABtSAoEVIMM AAChDAAAvQwAAMoMAADsDAAAPQ4AAOQOAAABDwAANg8AAGgPAACuDwAA4g8A AA0QAAAmEAAAahAAAG4QAAAHEQAALBEAABwTAACkEwAAtRMAAO8TAAA3FAAA bRQAAI0UAACtFAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAO0AAAAA AAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAA AADcAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADcAAAA AAAAAAAAAAAA3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAyQDCiYAC0Yc AA+E0AIWJAEABgAAAyQDD4RoARYkAQgAAAMkAwomAAtGHQAWJAEKAAADJAMK JgALRhoAD4TQAhYkAQAZrRQAAMQUAAAlFQAAORUAAHgVAACSFQAA1xUAAM0W AADeFgAA/BYAAA8XAAAdFwAAThcAAF0XAABpFwAA0BcAAOAXAADhFwAA4hcA APUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAAD1AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOYAAAAAAAAAAAAA AADmAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADcAAAA AAAAAAAAAAAA3AAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADcAAAAAAAAAAAA AAAA3AAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAApyAI AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvAAAWJAEXJAEC lkYAB5QPAgXWGAAAAAAAAAAAAAAAAAAAAAAYGAAAAAAAAAjWMAACuv9PCMwi AAaVCAAAAAAAAAAAAAAAAAAAAAAABn0aAAAAAAAAAAAAAAAAAAAAAAAEAAAD JAMWJAEKAAADJAMKJgALRhYAD4TQAhYkAQAGAAADJAMPhGgBFiQBCAAAAyQD CiYAC0YTABYkAQoAAAMkAwomAAtGHAAPhNACFiQBABJ4FQAAkhUAANcVAADN FgAA3hYAAPwWAAAPFwAAHRcAAE4XAABdFwAAaRcAANAXAADgFwAA4RcAAOIX AADjFwAA7hcAAO8XAABiGAAArxgAAPMYAABBGQAASRkAAIMZAACpGQAA6BkA AOkZAADqGQAA6xkAAPQZAAD1GQAAHhoAAFYaAAD69fLy7e3t7e3t49nU0MvE v7WwqKOeloyCfXl0bWhgVgAAAAAAAAAAEwMBBQoGT+r//wgMAAkBCgEAAAAO AwEFCgZ46v//CAwACQEACQMBBQoGeer//wwCAQADAQUKBoLq//8ACQMBBQoG g+r//wcDAQaE6v//CQMBBQoGher//xMDAQUKBsTq//8IGwAJAQoCAAAAEwMB BQoG6ur//wgbAAkBCgEAAAAOAwEFCgYk6///CBsACQEACQMBBQoGLOv//wkD AQUKBnrr//8OAwEFCga+6///CDUACQEACQMBBQoGC+z//xMDAQUKBn7s//8I CgAJAQoBAAAACQMBBQoGf+z//wwCAQADAQUKBors//8ACQMBBQoGi+z//wcD AQaM7P//CQMBBQoGjez//xMDAQUKBp3s//8IFgAJAQoCAAAAEwMBBQoGBO3/ /wgWAAkBCgEAAAAJAwEFCggWAAkBBAMBBQoACQMBBQoIEwAJAQkDAQUKCBwA CQEAIOIXAADjFwAA7hcAAO8XAABiGAAArxgAAPMYAABBGQAASRkAAIMZAACp GQAA6BkAAOkZAADqGQAA6xkAAPQZAAD1GQAA+QAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOIAAAAAAAAAAAAA AADaAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADJAAAA AAAAAAAAAAAAyQAAAAAAAAAAAAAAAMkAAAAAAAAAAAAAAADxAAAAAAAAAAAA AAAAmUAPAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA8QAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvAAAW JAEXJAEClkYAB5QPAgXWGAAAAAAAAAAAAAAAAAAAAAAYGAAAAAAAAAjWMAAC uv9PCMwiAAaVCAAAAAAAAAAAAAAAAAAAAAAABn0aAAAAAAAAAAAAAAAAAAAA AAoAAAMkAwomAAtGGwAPhNACFiQBAAYAAAMkAw+EaAEWJAEIAAADJAMKJgAL RjUAFiQBAAYAAAMkAw+ExQIWJAEIAAADJAMKJgALRgoAFiQBAAQAAAMkAxYk AQMBABYkAQYAAAMkAxYkAUAmAAAQ9RkAAB4aAABWGgAAphoAAOQaAAAhGwAA VxsAAOUbAAA9HAAApxwAAEEdAAC4HQAAuR0AALodAAC7HQAAzB0AAM0dAADS HQAABR4AADoeAAB0HgAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAwmgDAAAAAAAA AAAAALwAAAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAALEA AAAAAAAAAAAAAACxAAAAAAAAAAAAAAAAsQAAAAAAAAAAAAAAALEAAAAAAAAA AAAAAAAAAAAAAAAAAAAACAAAAyQDCiYAC0YOABYkAQMBABYkAQYAAAMkAxYk AUAmAAAvAAAWJAEXJAEClkYAB5QPAgXWGAAAAAAAAAAAAAAAAAAAAAAYGAAA AAAAAAjWMAACuv9PCMwiAAaVCAAAAAAAAAAAAAAAAAAAAAAABn0aAAAAAAAA AAAAAAAAAAAAAAAEAAADJAMWJAEIAAADJAMKJgALRgwAFiQBABRWGgAAphoA AOQaAAAhGwAAVxsAAOUbAAA9HAAApxwAAEEdAAC4HQAAuR0AALodAAC7HQAA zB0AAM0dAADSHQAABR4AADoeAAB0HgAAkh4AAJMeAACUHgAAlR4AAKAeAACh HgAA9evh183Dua+loJyXkIuDeW9lW1ZSTUY/AAAMAhEAAwEFCgbN5f//AAwC AQADAQUKBtjl//8ACQMBBQoG2eX//wcDAQba5f//CQMBBQoG2+X//xMDAQUK Bvnl//8IDgAJAQoEAAAAEwMBBQoGM+b//wgOAAkBCgMAAAATAwEFCgZo5v// CA4ACQEKAgAAABMDAQUKBpvm//8IDgAJAQoBAAAADgMBBQoGoOb//wgOAAkB AAkDAQUKBqHm//8MAgEAAwEFCgay5v//AAkDAQUKBrPm//8HAwEGtOb//wkD AQUKBrXm//8TAwEFCgYs5///CAwACQEKCgAAABMDAQUKBsbn//8IDAAJAQoJ AAAAEwMBBQoGMOj//wgMAAkBCggAAAATAwEFCgaI6P//CAwACQEKBwAAABMD AQUKBhbp//8IDAAJAQoGAAAAEwMBBQoGTOn//wgMAAkBCgUAAAATAwEFCgaJ 6f//CAwACQEKBAAAABMDAQUKBsfp//8IDAAJAQoDAAAAEwMBBQoGF+r//wgM AAkBCgIAAAAAGHQeAACSHgAAkx4AAJQeAACVHgAAoB4AAKEeAADVHgAAIh8A AHEfAADUHwAA1R8AANYfAADXHwAA9wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAA AADCCAUAAAAAAAAAAAAAvAAAAAAAAAAAAAAAALkAAAAAAAAAAAAAAACwAAAA AAAAAAAAAAAAqAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAACoAAAAAAAAAAAA AAAAqAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAAB4oAAAAAAAAAAAAAAAvAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvAAAWJAEXJAEClkYAB5QPAgXW GAAAAAAAAAAAAAAAAAAAAAAYGAAAAAAAAAjWMAACuv9PCMwiAAaVCAAAAAAA AAAAGBgAAAAAAAAABn0aAAAAAAAAAAAYGAAAAAAAAAgAAAMkAwomAAtGBwAW JAEJEQADJAMWJAENxgYCQxGGIgADAQAWJAEGAAADJAMWJAFAJgAALwAAFiQB FyQBApZGAAeUDwIF1hgAAAAAAAAAAAAAAAAAAAAAGBgAAAAAAAAI1jAAArr/ TwjMIgAGlQgAAAAAAAAAAAAAAAAAAAAAAAZ9GgAAAAAAAAAAAAAAAAAAAAAA BAAAAyQDFiQBCAAAAyQDCiYAC0YOABYkAQANoR4AANUeAAAiHwAAcR8AANQf AADVHwAA1h8AANcfAADjHwAA5B8AAPwfAAD9HwAA/h8AAP8fAAASIAAAIiAA ACMgAAA2IAAARyAAAEggAABJIAAASiAAAPXr4dfQzMfAu7Ouqqimo6Gjo6Gm qAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAINAQAFAhIADQEC AQEAAgUAAAcDAQZw5P//CQMBBQoGceT//w4DAQUKBonk//8IKQAJAQAJAwEF CgaK5P//DAIBAAMBBQoGluT//wAJAwEFCgaX5P//BwMBBpjk//8MAhEAAwEF CgaZ5P//ABMDAQUKBvzk//8IBwAJAQoEAAAAEwMBBQoGS+X//wgHAAkBCgMA AAATAwEFCgaY5f//CAcACQEKAgAAABMDAQUKBszl//8IBwAJAQoBAAAAABXX HwAA4x8AAOQfAAD8HwAA/R8AAP4fAAD/HwAAEiAAACIgAAAjIAAANiAAAEcg AABIIAAASSAAAEogAAD8AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAO8AAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAAvwAAAAAAAAAAAAAAALwAAAAAAAAAAAAA AAC5AAAAAAAAAAAAAAAAuQAAAAAAAAAAAAAAALcAAAAAAAAAAAAAAAC5AAAA AAAAAAAAAAAAuQAAAAAAAAAAAAAAALcAAAAAAAAAAAAAAAC3AAAAAAAAAAAA AAAAvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQAAAxIAAyQBAwAAQCYAAC8AABYkARckAQKWRgAHlA8CBdYYAAAA AAAAAAAAAAAAAAAAABgYAAAAAAAACNYwAAK6/08IzCIABpUIGBgAAAAAAAAY GAAAAAAAAAAGfRoYGAAAAAAAABgYAAAAAAAACAAAAyQDCiYAC0YpABYkAQAE AAADJAMWJAEDAQAWJAEADtcfAADjHwAA/x8AABIgAAAiIAAAIyAAADYgAABH IAAASSAAAEogAAD79PHsAPHsAPQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQ0oQAG1I CiwABG1ICiwADE9KBABRSgQAbUgJBAAIT0oCAFFKAgAJJAAmUAkAH7CDLiCw yEEhsIoFIrCKBSOQGAUkkFEFJbAAABiwUwMAbh7wZEcAAG3pYMIrdN2UpQUu 3xx4Own/iVBORw0KGgoAAAANSUhEUgAAAGEAAAByCAIAAADMJijBAAAABGdB TUEAALGIlZj0pgAAIABJREFUeJxMvGmsbdlxHvZV1Vpr7zPd6d37hu439chu kuIkipIHzRZtSdGQ2InswIJtKHKEWHBsKJNhBUEMOP6TAE6Q2JbyR0BgwzDg SLYkSLCEyKKjpgmJEUWKQ7PZZPfr7je/O55h771WVeXH2qebF92N+/rde84+ a9Wq+uqr71s0/T/+bSq2pCDsg4IZBndmmIECoCiGyHADAEREgiqIAAAEhwgM IIc5GGReYEBkdhggZMTBTY3YDQwTKgFhw7zwcmEBRLACJZAzm1kAE1RZHE5G jGzE3ggGcngiGtwCgrMFZs/uV9nueyBVLq5kMBDIzEEgsUUIKGXjgdhn4Ayw 28Z9bmyMwe2Kl3cKdlj2Ih8JnmTti22MOXDLagoK//vvwknhbhBhdQM51MGB iYwdUGRGIKgBBGEQgw1KEOfBPDFlsgS4gwAlAGBnhjkTLADZET0Y1NidiQ0G oCgHMyNA4AoEUEEBOIAHFAI7nOEGJ6rbFHlWbENmYDJ3MKw+lcEGoWQgd0At UCkUyAqD1AmUYQInmMGZGA4QyF2hBeYAI1vddxDBHQAEzMxGSKTEIGa4wwAl CANmpCgZiGgYpmADACOIwQmiAJmwG1ksQAERDHAFO0B1HRyhAHDkoEgEAFZj MiOK9QJiwCEBVOAADMggAgk4AAAFsLtDGkTNK8CM2Y3IQY7gYMAZNFW4G4MI ZAUCYkdUZhigAUyoz8Vwcgg7HIrU0PhGgZEYwiDChMEMYgdYgDXgCmdTCgiE IHBCXTIRFK1hhSBgBgPZQQoVQOt2YAAUUIAAYSjgChMmC5y9bg5IizoYDCYP FECMicMYzAAABgMxggSeEAhc4AZmCIfEqrGkiCiIZJSMGWAoAwAT2AGG1K1h wOFAdBDXiEBmCMMTiMAB5nC+2tAwMMhhAAjmgIGAHojMxCBiJSIXDwwPYEfW 8T3c4QFO4Bp7hgJAwYA7ikAcddNKgQg4wAADHOC6KmoZRQUOWIEbTADAYIRC DBugAjKUAjc4wwKMAIAU5hgIzigZ8GICVS8MZWYFMhTjhwfBCnKBOdQBA4BC cEVRuAIFhtAWqI1LqVZ/974CDPQGB0xB4yvCgWLm5u5MRIgOY7gCgATAgAIA icaA0oz65QLKEIE4CCAgOJxBGVzApQbMuKzESAwCBAgBziCDGMAwwAwWwQ5h MMMcyBCFOZxQCCIIAYHAAhVoARwCSDZrAYY4YHCAHQhjMNYDCCDS9o0ABBiV XsZSQ0CoH8fBBBDaAHEwQ2sofdMXgYmIPEnwMR8Rgwlg+DZv1YMmBCIwARG0 TQEAChAISNAAYtRiNn4xQwGDbY9hXXx3qMNprIVeF5QAgRICQA42qI7JkQzk gIMNA8CO0gMOj2BsV8HHNygGBQqgACs4ghyBwPUt6j8OONzBgDFY4AATooAd zO+dXDAcQQGGooacMWrJcYcAFBELCuAEUoigOFB/zMf3EmDMN1ahAGT8FmxW /0BjeCHUD2MgJyGCWwjwiAIEwAwNYVCQwiNMYT6+uynIURg8oBM42pQ7DeMb 1e2mAg6wAhIkAwhqoBwCSgmgunUGYrizBWOBb243/Ea2cb/d4RgrLBhutTqF mq2cMeZ8rW8WQT6uutRVZ8ARsI1twBROKEAE3MZnrbtaX00BZ0gNlprmBJHA BIsuRJvz9uGDw3JyslovvJ98/s1+YHrwjr39mC7PfOdm+tPvu/vU7TzbRSvQ BhgAgAZo6CzAFAHIdT8UxuMxh49pVCKKFyNQjwpCCCgKEfP6oPGNbLAAFJCA FMRggAl1f4kBEP/j/5cArRlBCNlgBHaQgyMCMCgEI4KAb89QXRQCGZRBVnHH eNR93NqxWtWUhIgyoDt7fnlf7t1vHzxpvvGW3r2zufdktn94cvLFFS4AN4Cw M8FU4A32iUnSvv3gJ7/xbR9ezq9gyugKoCPOqJ/kXZREhgIIo9iYfakAgAJm HM0GHsuuFCizmLmAHbnAA7yM6KceBfOaWIn+yStk6sJuABFyAQOhLlmEM7zA CFQABjO8jEW6VAxEEKAAYrAKLgwKCMMtiBcTiKDX6aPXrv7B59KnP909uTDc GeCCpSE6OOEwQHrcWQJ7mDOSoeuwBpCBAuzh6vNPP/Pw4AOnP/Qn3771PqSA rq+ZrmaI7XoRtBblMj5YLpAIrRnN4DyGGAyI0D40oeQCY2BAEYgBBGOYQghw mBP9k1cSSm+RycxtfIlcjyQjAMXGclhPP9eANpiBBObbFPZNpyyMaREWkMKt s9cO/uAz9q9/82R9zzDLOBFsCOgAAA1goABxCI81HC3goA6OLZaY4NLLR+8b uL/PL3/5v/gLuHkDQ0Hfj6CBAfMxV9QDYbbNU4pMW+jEgIIFaogMI/CAzCgG J1BdoHdj00EFSkS/8IoTC6DFQNtsD4I6JIJ8ixr4m9aAR5BTjxjLuDM1ztUR HGBwQBOvfvG3bvyLf7H6xqsnGAiJMcu4T9/0cgHs8B0873jyGMcBaEGMSQuP cIMoNsewNSDAArsH8vSJPjh76aeOf+5HERteD2a1mVCoQwGpKKyeFCAA64JG oAyvPwAIIRe4gxmeoRXuydifgsf04k4Mol/4NAwMU5ERR8HhBc4QATFYUWis CwYQwwmBYDbCU66FnGEKY4gABZIwbS793i/v/6P/rcA2WEWkgGmHRz0wwfj8 NWu1iHt4GjhehFtdOe5xnzC5tHhu92hSLp44lBBzj0fnJ/fxZAW9xS+t7NET 8MWf+Fvrv/I9CBFdRQMGdYDGtBIYXvEOjYkJjAIEgxKCIQOkcIKDmY0MfW3X w4hWgpGC8IuvjLkWjmLgACkYHMwQgusIoKkAMuIrc3At8hkeQQCVse+FgQgq SPHmH//qwT/8x49AE7CiPSA69seXcXP/AHG1yTqwaO61Qw+Exb7t8f7hS0/x pvc2RLh7kdm8nbXSpr4ca0fn95+889VHDy7yCZYZswF5g+UEP/zO3/sZXDtE X2AAGSDwAnUQEAaUBK/bZhhqSgW4QCPHjaFFb0ABEwwoDqppyMACMjBR+MVX iEouPIaoGohAW2gHgAQEFKtrgkiwsj10AlNwBBRkUAcRimE2v/z6p/b//v/U owRIQtyR3TTV7uLkyrXDq1MbiI9u7tpKfTbF8iRO50c3jnauLbTjnC+YBGUj 6TL5Zn/vqemMzi+6IsN6PSw3tnl8/Me/8YU/Wr75CJiBH8EY37n5Bz+PSy0G HtOQO9TAPPberhgEEcgMUpAAZWykoiE7lMZGTwmhoNCYTwmQmo8ABllFhhUa VIRNGI9VxdOCLYYmsEF5xIcQWAb5mI+ms9n9z13/b//OgOMLlOfx8vz6/OLh 1w8X+9dvHRxe2d29OV8sdtoYozOAoe9F0qKJkzaFFILFYTM0KVk7rNcDSzh5 fN9TjM18sZPaOD1b57vHp0++/uC3/uVv/j7Wh8AZcPHc/8x/42MWw5hSa72v FWYs6gXOUIAMVAOEAYfVLQcGRwQAFAJqWeSaxQMRTYEV1YTP4ypwBakMfrev qOu6fd165qke24JiCAQJmE7w1mev/vzfXqKLWOyhKVitH5198OatF37o2565 eni0M3UfJnFoEOHOaLgJ3DSECOkjJVOiYVAnth6Hk8ybo/15n7uSi/JuJN+N Eq48dfno+tFHPjj77//X38aZAPGEc6xBZHCB+PjQtcDUdsqAYCgCUjABilxC oMKA8nuwLji0Qt8CN4Qg9KM/XdjdaewksH31WsvCFnFg2+kxj9QXOZhBDq9l VTCfpFdfee5//F8G9C121+jn4HmbvufPfuL93/vBm4d7+7MkXlJCg0RBiJGa 2WSxCAkxxkiBWEUotCkwx9lubCM1Pmuns3k729vfOaCYdps0MJp+0zXUHH3X R9JnHr5anqTNPU8v282D8ZFgKITgI+flOj6n1mInAMMUQcwZKuPJ8EpvEdhR HBTAAnbxH/0pdxmbL2wzUf0GDnWEd/8ngNp2MNy+CSI4AKQJzu7c/Ls/P0Hb 4f6Afo5phP3AJz/y0kdfun7laBJMQrO3szuZhthMJrttK00KraQEbkISmQpi G1Ik8hCbEMViJo4coqsGcQ4SGe6RbWDmYjoLu09/8uP8O199XV9dvPor/Lln 8/fcgAvCFtmOn8hhAnIwQRmhphRCCICDHQpAwP5eW8cyJiQ3oR/5aba6RBVi YKxxXLF8/bltHFk9ho6w7eBH8Mpow+V/9svhzc+e422HECYz2F/+T3/8xQ/e nk7jvJ3OdnZ3GpG2TW0MjYiDJNI0uUSJTgTiJjUN4pSbqUwX1ADGAhKoElMo 4OiUWAyWY5oGKqtuxZauf+/H3vnt3z2H6ep3yh9+yL/75kgkRYZu26IKyQrG ByYDGzqM1ZnCWMsQQYY8flR4ISZ2hnEt6QwJYIIwDChb+OP2Xsu6rWbIgOA9 hiQkXLw1+dSvMLiA5nhugviB6++7/Oxk0k6OdheLnaaJxIknDWJKAoKk2HDg 0jZJQuKm5Tb6bMHthCfCbACjnfK0odDESYppHkLDbCIxzibSynw+399JCymT Hj/xMz9JwAyY3fs5+oNjCIEZ2RDsvSwBjJQWAwKooPE29rB61hhMkILCSARn uCIGBzN5/XvAFBkwG1+aAVcEBgtgI+k3HrfajlXIzYiQaXz6N37PcO8Yj+a4 enj16T3Zf+bD14/mVy8dzieLWZAYIqd2LiEhTGIzbxpw3Gc5cHGOE0471C4k TJmYaYqYeLIbYvRmj/cuh9kUsSEOwiqeQzubNMyS92Zpd08WLe1fv/YdcTrD M7vAlX/2ewgCM0QGeAyAsaEz9AQ3DAxyZnQ5gN5N9kAuIEArhRSQHQ4mp9qB MTPilmGCgGTsu0biDWONqyMFezeyjKWx4Sz9298smO/hMuN09fBBinrzQ8/O 9xfMMw6J29A2E07ssYmTQqmV5kBEJIQwOWBOIgSZcphISoithAk3U57uymSB dgfpgCbzsNgJ6cBDS9LIdHe22A+pbWPYWaRo6aP/8bcbnnzwhe8/HP7N7qMe 0sAMDgsBgbdtJoEKzOrHtO10A0TI9v4pjdSKlZEUYgYj1EZ+TMrvBkuthebf xE9j5JncYGACnMwVg5OgOT3B6rXNSK/PL996apaWk0lMEsMshDhMwgKTlkmZ GdaQEIcJB0dK4OghmLQkA4E07iR3FZfA3mULgUtv0/04bHQ5+DQGE+dgli2S JEwIJfvOdHL1hY8k/M6F4pnbB7h/92zvJqwSp4bKognDDBxgBlY4bVmuAiQE +dK6IAewgggE9IaGoM7GzCRU/2UC1XxWRnqhJrVKDBNQV5ZhTmZlToIgSkxf /coJNi1iwO4UB1c+eHDlqUsHu3smA5sxogQOomYhiktKxObRQapuxkHay838 EiM5a6ChCDhEeONRHOQhsq6L7HmchrQbF/skWVdr685jw0QcWXdmk0mavHh4 pT89+dIbf7Dz5kNwGotPpeQFUK0k5IiKx/BxcBpBj0XImKtQABEoCMQCdxQy J1OMzYyAArKPS6LjaWYH2K0SitEBXpqRkAT3rz6OiIaSsEg4v//5r+9fvxZT THEWQmmaQG1glpjgMbqtOTUATIwtBwnUiKNnajgwKBI7ymC2MUXQgQspBbEB 0pfu1PK5KnHL0k7YRFKKSWI8X+ztPvXcLV2enOH00a9+FpCRzweDZRwaunEw OKACVnglUXUMK87gAh8QBKFym3D3Oo5DYtYKod1HMBnSezw/CaTOSMJI1CpC LXKFdBjS+ekGOaBlLBnt4vLR7tEiwkMTYtpzKpRdBETsrmyuRdyzOSEKtBuW T7TL7ksb1kYE6twHVmOt+5PJzNCTRvPO+j5oJgowIelga5Y28u5OnOx95DYN WoAen5HzHlSbpNqEUy3wluu4TYEIU2iACCjAHRzhAR5QBMVhAmYQMcGDca6o mYlDgDAITA4OgNaWjSVu+ZBxZFjYiQIHRrD8SFu0A3SJriAjSIzeZyXTECE8 c3FHcHcYGQWxMwdzmMEIrlKE0Fu39GHA+gk6Jm4dA9CbFtgam2NkZIJ4BAf4 4IELwzIxT5g1JIuNHhzeYGQHBkRFA8lw2WYJG3FvrN2JwRwhQLaNmxisgPK7 qReonD/YnSoRzIDBrZRKIRksGKQYE5DdaohpgVbeYISZTpBC5WACgOCKjkDd g+PTrpQ8iHsIydkQEicCE5s6inNii4yC2HJaIJIWldCQGqSBFxuWVAwlwwcG eZyyNxHiKbo0aPahRbwHmfkKnr0vyTBrJ3QQBJA6fevDe4OMWpdVoIBjHPyR MwtyBgTGMIKncTLGPCZ7BitBCarFFe7bkawDRoVVJZkQC8EKzEaNBxEMbGRS vKiVzBSBEoAIGOjkdL1554zZJUZEYQRArS9s2bhhmbAnpF45NqKfO9k0Kcnk QHjHfeombOZe4GwOc0aRQOahdZBTE5tdZ9YwcZ5wO3US5xAmDQuIy/nxWQYG PA1XTAhwECEYWBh14rYt3ADMrNKt0FEKIQQROI1DShICAtzEgEDqGFenVnAC iiMYjI0sMIoHuIED3JjJ4SgRlkmou7bf/qEkJEW7KwcXx8d9pxRbTg2XwQlU iFq4C9Q4iLcTV0SZZY7fdpj60BIlnzRxYqYnlJmRqZmIz+Dm5PA9cR1zGfUS Y6KlSdAcU6SeoNoTmr7rH+M8ABN8HHNDp0+lcFcLnAEzA1hG/lscChAjViKc wIU5mm/naKrvigYCA8ocXZUJoDnr0hioE9dto8xULLA7PBj14NY8M5O5SWgs eUwpoRlw0mLvrr62hpasu/M9jsHYMQyeNPuEOUkIHKfE4lEgE0nTPiRioaZ1 m3jJbNEmTmXtcKIJp5mZOHXIKhRIO/SChkVIuqX6pkDcTYgySeCmKjMuJNRD cVfHOABvB1wGBAcJYsFQBwQAE4ZgNZdzgRI8gKwih+DERDrUyYfZsg6IRjav gOvklqugBaQwgefAUENgFFJyzll7rBtQxjljIOwE2YlNsDy4ZwQBRaGUV0tK e4guqhw4BTI9ZV3wYs/Uyd1jAghDz83UiiMEgxM67x8zEcICvl52Ty7OzqgU J8/rVSlx1lA21pKHoj0wB7rbB+NgnRyaEQWDbQkegwZIRmZwBgIUgHNbbBNR HBQRdByyC+AemJCVmCzABhO4jo0YABG4QgkiUGOBOYMJVooBbgWE4h5soX2D 4GgS+g5wyGKnDYE056xFoJPF4tHdN964c7azO1v2gw6nj09OLpZGIXzsQx99 9vkXF5euWOBAUJmDxKCEbLkjmjkKlM5O3vrG61/+9Kc/+9rX7p29fm+6M3np 4x++tDsNqblx48XDnWS+WW+wAQ4g5fEFzs4xm4IL0MAySKAG4ZHeyQIyIIIJ YujdujCd0nrDEIMHCKA181BQNxCYaVCeJl+XbTKqEolKBlgGuw0KIkStEj7A q0KFVrq+NG2wMwEVbBgYcJ4uTVOITjRsNiGmu1/+/NffulOG9IUvn5+tujtf vcfNbuAQqP/sK689/8zRn/nhT77w0ouY7FCzdMDUWDIZTDpbHj+++/lXPvXK 23c29994fHh0be9jz5y9df/BV1/HM8/ncvLO3ePnn3vxqaf2w6Q7AjpoOfuV vS/cPvvuZ33jEIXxmIZNQQTxUR9RFMoghiic172BKuehiDTy2eoBIHYUD0Be +7tiMkAVwnCGZYDgguRQcDarkwMFM5uL25I+fzdiXTAVhA6DQSeTFiKmF/0g 9996c3nRX919Ic3T+yWmWeL/UJrYlNI7qLu4sNL1j77+eOKHt96fpAAaZMds A0dZL7uTdzaPjt9/+6XrV/v07c18p+XUUmAaQJxA5fU7bz64dz7dWczawzzO L9+xh4ObIOaRQmKMkpiKGwPBK38PaB0sG9TAAuNR/xkIDBQLIDIGkyJKlWGN GCoIVMG1FjjgTGxixowyknDmykw+menLN8++wAsMjChAwp4Hi7BBIyfd2718 /eas2d2NQaYT7zdDGXpXseLL8wtyI5f9/SuJLZ/fYX6amwYhiqa+XPj6YXf6 cLncnB3n2eTg6Noem5dMw8VjRdm/dBVt+9Kt56S5lzNijAJEHCmuHd/YH/nZ yvzXDKs6Ev62Jf8rgc8M070JTtdVxlj7lUo01v94JSwdHseWt5JH/O43FNjq dHKcbVolTNiKexl8Fr73/X/pMqYrnBFAsEGJgoBcyBeHlw+uXJs1yP3xnVe/ /vCNty/unw8wifMUN7t9h+Xy/NHx6elQusFtgLQQduqpX10cP777jTvHd1d7 PuxJP0hzonb/9FFRGVb9219/vWyKJ7p86dqlWWgnDQMDHgXcwKWIbECBFZjC dFRsYhtWo4Zii789nG4CxEad2HuzTA9GTpVAMIB0FBQQgDDqcUAwL6OwiIAA AqJAHQVIhCLXdnZ/7D/Y//Tdp05PN6c4adA3YMrKoW2jBhbTdR5Ozu8f6+CP 7r316T/8w7dfffTw7vD8h779O7/vxZvlQbNzKJvN+QnFdkks4mrrR/n0/OGd N3S991T7djdc+fTdR7/0X/69u1hch330z/zoh1/wZz/4gdJtuJnsTCRiOt2E BjgF5vPvxI19kMKAEGGKEMZQMgeFUcTpBKnaNQAZHEaFYFWFZEM0VCzIDiLm yiGQIwSQgAiBQAQnJmIJI51Uwbwx1FmYikPi/Oipg2H5rf/Rd/3nP/bxK9hz SJQQYpzM9xcHl2eLqVLWbrNcP/o3n/rt3797S27f/o3XHpze/v5VSd/yF//W /KPfO53uHj57m5aP18cP/PRxOXtkXdDN0F30166E+d6L1//8z1771vdt8OxT 3/Lx2zc/+pN/57852fCv/atfOzk7zX1HMTVT2ZtPj/auXkKz+DBjuRkn7JUV qwNnOIgRAOg4g6w6JgNCgAHJEQQcQRGJa+FjZvZIEFcBu0N5XkkD2VKx7M7s 7gACjzwkuxOzkTsDedh98xvf991/alPu33mrizwz+KwFUSSWyDFNWnYpnb7z xbeute//6//JD/z5n/jZT37r7qUv/toP/Y2fuXFoe2Gz/9J3SBNKbMqmGJKu N1iduvaBQw7zKNle/a2Xjl76oT+3s/OF3/6+v/1z18LJn/3o+565eu388TFZ SFOOxBPS3cuzv/rSX/nTn5ijxzWSvzQ1lK1qr6qA6xxNC6RSrHnkHsEgRQEK wyrORv0V4R//63CGI0CMGNEGJTgSqxoRgUlqg0eAE7OQO0HcDXvsUwmbou87 P/7LH9+5cmXneHP/K1+7EJ1+/yf/5M0re2HjcZc4NgwNFObXrz59NM8PvjrL +NDHv+eH/trPfuDoYvWlPzx/4y3nZuU9Tk/mzY5YH0RMrT8/K5tuVaaTa7e7 t7+a+vShj3z4u37wzx1u7m3e+tLy/PTK+5678vTVMG+n0z0Ddd3woMNf+6vf ++Yj/5RPlgfTP6Yw9gx1NlF1H+D3fAr8zSmFxyQFjIMPZsBDFQAAUC8cghYw 2NhapuyAmwlIq2CJxzFJAAw77KeVgunWvlmXExwe3P6uP/Wdf/Tv/+jXv2iH +/uqJbaFtLG28Zh4Z7pPpYtB15vcvb3ABKefe3DniRl5u9ev7u+2kxQn3EQz NXUgi7ST+V4s50/e+lLrk/Wj19spT9vJajY0suCrl5rpzt5iahyLuduKO9y6 fHN+af5o5kgtSoECgZDr2Mjh9ZOPw2jA4Fstlut24GqjHWCUoiK4wxVRkCVA IYCyQ3GeFd7QhMKAQh7NMgoZm9Q5ip2ziJnCMZl9rV0s+XBy7daLl8IPf//H vvDW15rJREic4SEFcktzl8SxnYL61XrozmnotV+L7AcJiM1kN+UHb6I9ymUj zZSNipeu76aT3bLpF5fnJ+frxtqS+xRo/9J1It1vEtJC2pYU1G2yT9WPP/zc 0/NLBxtfgnkcrBptZ2rvKthqsa9ktI9ikBpu2gE0Uk6jVhHBCQTLwo1b74CB mZtgG01NoGGgEp2LZifhwFBTAdwF0dBSucgSEr998eTB+sqLreRu8gM/+V9d TP7v4HBVUOtDn72IpBDmzhHWpcUkzmd6/igXp0XbTvZCU4bTM8RLZme6znFx mSKTzQSnm37dNnOmcOPFG93F0C0voJYYNJs1zdSYGe4uvakzXNJkMp+n8MJB 2BYvH91Ao5a0Ml4EslApI4uAwh3so9wNW/lRXUo3rqy1FwwG4vpH24BvxNK7 gZy1WCA4G7QgmrgyQFDgwvlyssIBBwcXyw135z67zUdPfegTL0vJQ1ECeU/B OwLDOijYI5lgc0LE06PFbLqb0uDrNYdZoW5zMjSzBXNflstYYgjt6uRxmbRA piG1s3bn6v5kMWW2uHpSlsfe9d4X9B0RJBPFybpbLt9588bu4dh4MiFbZfFH 5qh+byiFzYw5AwTZTt9CAAS2TSzF4AjBoQE+jrANABFCwVscYc4BqqM+OxoN nuFC7OKsZsLysCgLbO9oOWR7+yu6UMU0NvPzzbnvtK4WJtExJXcHCTYoxraC pygAJ0kJLNyQ98dnX3xy+Mzz88kh4KE5c+tn+9d2czl75+G1D7xsamwsQcL8 oJgBM3HV3Jn0ZtNQqDCY9OT0wUNNq+Y2rAponCPbqGmrUBtgG2lGFzOGlrHZ KmWEBaCxTaFtHJkiCdN2Uh2BTBar4l2VJACBiTOPcl8vns2ITFU5SAqMJlxo p83+8o3XVvfuaZOcAzcNZOIkcONinDNlZpXAB6mdyOJSaHc5zjjN0/zg5M1v 7B3emuzsozUKZMJeOqM8O9jTPDx68+3m0i5P96jZIxZOl3g6Z2QqgZai6y4z BwK0EJIf3XoAhggCwYN5HZB4RcqQCpgLQKAAZsQaYI7Io4yCgd624gDnSsIB EDMYBUECSC2bc1VzO5jNYEQMCRyImAQizMzspoMbYlqtucgiPXPt5Btf1cKw 7HljlCkUKuuig2dHBnPrcebSGrmo3L58AAAgAElEQVTHgGZKu3vLu69yvrRz 43qYJWBAt46zq+HK+wIveNI+/cLLYbnenBzzYiqBIImtSM/eXvUQPTtroazw YrnM93aObh7caA2uRFudjQGos7Gq46iscgYGoEOuordKwNrY0jeMwPXEMYBg cFOmaOSquFBQZDZnraVQzTQYVzeeu4KDshcnY45gN0D43LTbrNL+9adeepHK sgfpuojB1mbK1HW2OUfpXMCuhBjCLsepBfb+SXmy2X3mFuJgZkxz7F+VW5/g G7exy+xNuzjcf+HF/nTtPsX0iBP7xeDCbBrEQIMb6aYrg2sZGgjnoe17RHIH pBoFfaso3hZ9ViCOngdmNLylzBjFkLcCeTcQhRbouaqYNSK4DOZipERMSVnZ RKJQLkUIUDMRtyJghcJocIhD2e9tBt1kX63ipcvxyYm7EzmpezBkd5CsO8wX 4q4+UJy6D1BGM6dh45G643sXD++Hyd7e00+nxPr4S7Q+y2W4+40v5bUf3rgR QBhWaAVhR66LdQ9tUN/0JFN4QemLirItL1bL+6sP8BBxmKsrB9j6dzAqq0sP jluTVhj1R3WNqh5GMzyOVCSDmahywGAbrAyFVHzmQZLAAwORkXMWNzfzij7d tehNZnaKQCIG+O0zC85+cW7v3JtNFxvNFqILeckUWcRoZ8db6xiORKGQFYTE emzaTXfmw52H+5euJ+PHX3lNTx7Yyf3cbU6//qoMl27cuqYP3iE17R5av/Jo RkZxRliUMDPvyXowNOhmoL3DAyrLw/PVt0sa0bE50MNoHEYagxJsi4e1QAvc 4QQriIAESBj1Wu5QD1Uf4QaDJHgGKNsFIwxequfBlCV4URMSG52wSHSnH8Q5 x1BMEdIXjo8TDux8SYdH8/iECBZKVhNyLVlVQ1DxGEm9kaHPwVSEVZ02A0/m uy8+Nzw+5dTO9o4ePXowAfWsZ5v5vC2br12kp2+1B3Arpe+QM8fIHOEXXDoM JTMGkA6esZpODw72Zg+fpFfV0Ah6gxC8GcERC6AwQagGFwIEVoXHZRQUZ0Uk FGxFsh6KOTtASKZdYGc3ZzAXWGMGhMGcIoidPCjlaqCGAjEF4BnTr5FQiF88 Pf/Ma/d+8BPPYZe++PrrJ90kb/o+lThhEQYTSywBMAQrLWFIsaw7lEFKbz25 67rZPc+nO0TN5WcIvWw285kXLXl2GCNZ7tWYohm5qzex8zb66lxFgLWXtnMi TH73M5+9d3n/19+8/uilI/Q2qmDfhZGmqCYawijpDAaXcXAyKt8Jpf7KmMC4 OAo5w5QDuUSPAkqu0QkeFC4EVlcPStpmhwAeqi+uN/+aMxxICc9c+ZH/7l/9 o3/3hX/667/9yZ/4fzbRiUPv/TBszLwMvbrz4zMQZ6WBp2VjQ/HS2cXKV3k4 G3TtGmcHJs7kwqHZ3y+b8yLNhvW4nD5+1K8v1rlTddEBXc5Ah71dXkSl1lvO 6Hbm01/+1//ux//rX/w/7wCRQDLm3XftLGN/i9HtAIJRNdaO6iTjbf/6rkzW QyIMpfScDslWIqqYMwYHgYl9GD2XwmxQ6oKAqvmhGn6IC6qZnm48I1j8zf/h lwAFFquly3WOxbMQ5U4klmGQpA6Q9kVNGX0pTAOaeLHciDSzvfl0mhAWyBt2 pibsXrs9rNZZfNjMNnGVqaH1Zp4WhYZ2yB4nIcmmRC9k3QB1lM1F80F55sf0 u55j24rveFvRKz6q3pkaMqNkLaNnoIwuDmzdnDSOeUM2LxQbszMiL8XAZ8YT 8JodQKPICclgxGZKxK4KEcDMCG7GRERQx9GN8nd/uPn7i/LyczrtH9y7oA8e wbPl5E3rtiKK3k45uHrMxUlm7STkzjiGPV80i7nIjPNA+QIcyvkTGiY7bWMz dZnr3nq9DOsyWGioaYO0Zj44cVFSzeSGLpuXbrb+qZ/RXeaSLRfoSG5sTUDb ST0KLI6i+1FirTCBASIwhRiEkEfJcPWKeiYPJhzIHBFlA2YDjC24Z1ByKmpM 5D46iwgBrEFI1YvWgb68/LH+//oIt1O89qVP/c4rf/G7b84YEO2G9VTYKs+2 tkGm2SiEwfql2yYuEeJcHz0sp0tbdkPXSzNrJ9Pcv71arR3EzYwXUVqZsGxs rcMFNXEo2oSY3RUCJ+fZnE7u9P51y+hgw1jz600DY69fHR3M4/0XI1XEYy63 MrrwnAHBYAhVra+h2uIMEtkyKBgoCI3mr0IITt6peSEJBHczkJCZFiJ0g0tk kKnCoZAZY9P1SO3n3jg/PiuLveQ5ouFiyuQuTaIQ1KSdW360eutr529vVnfv 5SfnLWZNCNAheUPiYW+Xh2G9vii5zzEWkuX6bPrU0+2zV/duepwv2jaqs2vJ uRiTaQfzt7s5Jtt5hlRGEaNpsnb80Pf8SJUdIkedeJpAdPS7uI4WGxiAoJWx hGcDCEXgVgRU2OFxcG/Avdn7W//SoOTshnqRB1QRAyxbiFWayrmsgsAL5hOI fPnO42uXb0RX2ZSSTLxR3kgWsKeUtL2690w6up2Gs+Ph0TnON6GwaAK3Mltw 9DL0h5tVPjsZ2EuScGVGl/eaRlhs0yRQC+tLQV+8XlDSO35/KdiRJDo4jzZN 2HiFAADW0R+kCjaU2u4rCo3WG6WRE4mEzO82+QEOhwmCgBLTmRqYdxmnzpeY Tt0N1hp9eVC4wJ0JBudi1ghyVYMBNACwyrs4ECf40NP//Fe/+ic+8TQpQQN1 Q24HKjOLRTiU3IEyW/Tk8dJeONijPOhFT5sND0QzLSDudLgYbJKa2X57KWhk RkEQJcApIPfF+lJEkK0wfNnjn64YYkNdndqjcxzHPAZAUHTEASLwd62chnqP TKXx2cfBYlXRCDHIyUnZGtiZWSTeZVp5UOAYDncj6sUdgdgJo1LL4OgNJOCM utwhIChAKA6JeN9Tn/38gzceDcSUE6wNqV14Yk2sHob1RqCmSz3v4UZMJvCd tr+6f75jj3w41dUDdMuDHXv2ab+1pw2E4IO5WqY2b/o+D0Pvxl1nPnRDR/57 ry6RZiN7SDQ6GssAyJYJGuf3EEHmbcumMILTtmsxVMs2vzfQF/zYTzspGXdM c/bsGAxEtgcLsLW5FwpCRgSrB31bNUfp7pYDrY7DyiGEAAf+v1e/8O/f/uQP PEPmIbYxEXGBmYWGUTKUNfAscIwEh7QSJbVTCRMW8sHbeTvd3U2LNkWhnBEb ikPpPQ/LtYesXQ9TZVUZSv/OO2/9zU8xPvYcEo/estGARgBGzp91tICYIwEk Wxn+1kBaFQC1p/NqZSe4Cf/ITwPJBS2xsZi5i5v52qUPHIK7kTEDBc6jt1Z4 ZKG2ZgwIAwoK4JEETk2r+ez4lVe//QOL2WymbWAeb1LIZpuh9IOKZaYoREZB YiRAyoD+TC82ASWsLqxfuynH4EFhy2FNKxsuugJmg2hZ5XUZSn+2Wv7CL/3x 689/B27vjw7I97623h8CUOPFOVQeeRtW1b5Yh2UEUJ1WZugIIwNX77FyF6zC JyJULwEpuwmzKgJM3ru9h20M6QrzZQtPfeuhJBpSvPSRF578ylcWau/ceX1S bpXdsDebaFlZmsW+eOI1ua8eY5jJbIcZ1l/0J+dUEKhFSpD5sDkvD0/QbbiN XqgvWkQHlwj3YbkqJSAsN/nJ62+ujz6I5y8zuWlEAGwYK1eNGlN41Tv4eHvF eA2RjwQTGDqM1+1QAQgct4iBBD/2n7kpMc1BmZx0hAzC2Yyd3J1GVzEMkPHe BxGYgQlOIAH5OOCmrY9EZLHfrob+Lzw1/Zan2q/feWxpZ9JO0EQpGDCQGxCI WEQ8994P+aInnmCyj3ZCcS6LKVEowQySlZd5tRx02WkIbOBirgOd9/nhOyfP p3h6+cOfubRwcagh6Lhn4IBiVSWNCKmuRxtzRc3KgVAEtPWHVjEkBliYRwzF QV4l74GJxVy42pDUCwlDIQy1KozkkpgHVWj1ImPU0IXqzfStIMzgVapCD2WB D7/8sPvGx2ezD70w/+M7d/vu7PrT11wouJizRYORETVAaCc0nVEQCnNuhXrH fOqlNOLDpsvoLzbo3GPLG2VVKzlvuv784erZS9PF2pq0QB0VkqFEQIEAL0XS 2HyZjmJ+SfCy7TYYG4AdFhAUitFthgZky6KoAk4GmMUUPVExU4cbg3nwBHZj glQ+mAcEkIAJzqBSL4p4z1nIBi4j4xmqk75gp7lXCoW4t5h++Na1VDZf+fo3 Hj45Ww1WApdsaxcKsizWQwqRpAaTCIPnLh8/cA15Oi+BO/UNc0f08MzPhuH0 fPnwyfn6fPPc0Wy3SRYtQWEGBYzgVR9Sw9wAG1FPjS3dXqWDehUBb1OVg3jk A3hrSmOiINV4NThph3Izytj1wSY0CBSlFoiwTdg8QntjQALrdpReVRIM4zFH Vjf4pP3aKhRSJix2J7cuH92ezTfnF8fHTx6dnZ/kwYqtNisnOl8u+zJsNo/K 8knXrdfoOs3aRM45C7JYINoMKJSGVbda9fut3ZrjYGcWg282m++7sXMpCozA Nt6FVcn4eimS8ZgEQhVEMJwQCcKQ6ie1mpTG31JBIFAEkxt4cIdTMIPTW6Uu eWFCV4IStzTAHZbBBdiqeMZN0VKRiBnMQQpTuI97WBzqSPH3e9PN2gtioMks zufh8mxykFpari9OVw/Wy/PBezUHBs19RrcpfXe26dYb2uTVo1V/PgzaZQs8 KZ5X/fHQb45mswW3u/uL1DCSc+JrB3v/4Pbl8dK5Kk4wQ6H3mKNRzG717hsk hlaWkrdXyVRhjG+xAgGErGNdM0MhYmNByZBqnIEwimdOUEeIo8G73p02pm/e XoNACNUWTqCMQcafAeB8/drNHscxKRsvGhbMs65iSP9/VV8aY9l1nPdVnXPu fUv3dM/0bD2chRyKy5BDjklKFMVEkhcREhRKjiUgsWDYiR3YgZHEsbNH+ZEY cGIEgQwkMhwxiKMAthEHDiRZsiIJsuiEMWluFkVK5FCkOAs5HM6+9PrevedU 5UfVeT3qXwTR8/q+e86p89VXX33FIZRusr62emEy3TacG6bQjtoJ6YCmClIh nfabBRnUF50KXV6/ev3Spe2j7QvDdox+3MT5OMJwkKgrmsJo/q/sbvG9k5Cm 3lYBVJyizQAVWEnW+oTNyMmyjQA3firmRKPuKVMEMYJKJABMQ5Q+hF6j/eo4 lWlRZSpUKyqz483sgML3l9kBWf3XtBlaOwUKSv4XH/94c+4Pp6ubcXujmoaN Lo4G/VTTIOU2zvXl0ub66trqZmrp+goTcSzSlZCoL6UoR4UgTjavRdD+hcVR E1vFsOXBoJExR+m4dIExWJibW2j/2o75r65OkQlqUtEq5QtAtrYi9nKt9T5m RhR0AhB6oyIFhQYJE1c9KkBcSLexbIo3eaMoSNcLZ6ai0Tu/zJXIMhopCKZ+ t0YdQgQiucJQxPsurZcA6UcOhnbn8rTvuBlQQ7FJC6PBaBgGgeeGg23j0VLb zpcOmytt0kGQgXIEoUeTKWQhzTK9tjgcH1hc2jEct4qUdDQaj7alGJrSl9Jv pMUfmd/fpoCfObgLGWi5NnEWzEK2vZ1ZI6O1Qia7pk1ay+7xRJgW9UIAERQ8 IF0pGLGIoqlVNyhDKIYOuUTtPP/Q2uknCuWcIziD2G9WM1ywhkCO9jS3DhYW EhYOPwBMy8aVJOCmaRfmFhbHzYDRdaSThcHinp079s6PBp2wTHOejBJa6ZpA c6SLMR3cvnN3O1gYtcM2jIZz25tB6HqhqNMNQaeb2HvfI4iYFn340K69rZFE xUVWJmOPgDFfEVCXU7mGJlRnFtkK7drB5aQCKOKmEBRTRRuVsiJiJ/iSCAgl UwzI0nIsYlSLkFddqPpo+bE2B7EASaDivYa9/I2lbW0LnlsYL9+ar73Ng/lU iGIIMQyHbcQEfcljijIaDaMiTNZXVYKiL6EhxXDbNqZpLKnTrBzmx6l0GgdN LEqC6UYn6yuDfR+ZO5ykQyEaz7f/7ODuf/TqWaRkHX01xS3uF9MDwXuH/Chp Qsh+3xOQC4DYcraTmBji+RophSx9JobwBhdSiQolkqxgVXOQs85CqjZJpsqw 59CACMcX3hYI9Pzrdx++aZH7gPHyHetvvY68muIAIBo0UpRz5tFcYmpiSwEh NIPRaH6c2tQMh7GNMRYZpBjGPBqNBomJlAchCnHbdN1Kv3qNdn5wzwePSuen B0q7RsPNy5svTibQAnuOQCjFAYEEb4s0VsRf04yqLCgBpKKCQoA5BSHQo79o O5IMH5pbkLKEALBfXkERCJ3YH66prH12Aoor54UckjGhZHThXx67aTRGKWha zB26Z3r+bd1cYY6k3HBECTFoHEIDx9TENjVti9GoiSEMR83coBnPcwpKkVkD AyHFGBBZtEzOvJ72fHj3jx6TDCUvxGZgPEgP7l780Pz8wlT+cmMK6l1IayYR HoUBDohk6AVCruS2NCWg6m0RWYQo0Md+UaGtLYMlpQwoRiQSWXPxVi0lWPfc FjMSnFgwGaG5wUoBA125M85/9q7DR5cTBeetmoR08A4tqb/yBgeAKAQqnDWn GBvEGEDMHGIitsNNFBORxhBUKKVGGVAhEXQrg5s/sf3Bd9mxth+ytquCNAyH l0YP7V96dGHb7p5f7Lu+dCgMBs1ek8VNB5Hk/eYIaBWFAGWGehckUfwvzyhZ x4y6u58CUYEIJuQOHEHkcc4McxSQ7J0SHvwCItBnKD28bduv7Nv38O1zC2NM BBwQY7VUIqSI7lpZf+WburkaR4tCRMq572jQquZIjQYBRQ6QbN2LRUSklJiC dFPVnovGfR8Z3Dyggl5dxMCKIlBFl0FAkxACkuDamp45v/HMmav/7cz5lzbX oAQmYiYyxlmh1kZd3NazFICgJYKyZsqKyBQee7ogkCoAVQVbEm8d7J42g0zX lb10p4QsAJhJLFEsGRQ/MV762+/afXTfcMcCuGrcA0MVidzkwyxjiLBx4mR/ 4hneviMgdNNCVJBJbM9z5ABIZ6kfx0ZyVgrcXdPp9tHRD+rSFggD3NoIij57 vtQGpxVJEIC1KTZW5PiFa4+fuPTZC+elLxgAYcTaSaEA1awEElJVoO8i9zmH RFQoQ4jCY0+TEIgKQ5WBAmuQY/NBtUiswKy8K8hAEipRkZEVCD+9uOOXj950 264UGrSNa6ALgAKN1ucOWFsAOy0hEdMruTv+NbBAI+IQojotIaBHFzQUa9pp msBJcod8rdDh0bEH0qASqvVysrKFB+WZi6p6a1kW57u0oPS4fD0/dfrcZ944 9+rmGkDUBCpg0jJVghJBcoaoMgXJIkRBKT32TCYmVTG1jtSaHRFrELZeCmIA SqJCEFIWAKUDz/3jnTt/6o49B5eobSFA2wJWRmfbakDdSszIvRuYKryTLHfo T7/aXfgB84TDnBYVxEBcJAeChAjSwFlyxvj+8V37zFO4fvDW5eFQsXjbWWT/ HoGg6lYFrpTtwcDmRJ9849Jvv3Lyz69PMFAoxSwM7jVTFg0xaI65lBhUhdJj z/aqIByL5cXcAM5ZI4Ra1cSAaQKgSJBQKEMKSvj08v6fvWfvnl3V3S16T7LZ Ls604L6o5HF/RvDaFwAhROQe/VUpl3+gl99CEGgL4jBdz9Tlfp3aW9rDDw72 ktoNbq+Jtt6RMbGl+EaXDA7ugenucgAszRAIIQpEwUVX1/SZ0xd/++W3nlxb Abhh5MCY5sAas06JhqydFoqPPT1f5CpFz+A5WKoB6ELDY5W+0MWQuIjvncyf Wtz9q/cfuu8WZMFqjzZakRyBKua44Ws4J0y+4JbwzXJGrqBKTbfao3vrRDn9 ElMonBU70x3vH+yFWHuZggCxCqvZxuGHYoC/MeMdKpIThQiaFkWhxc+jfY6J Iqfr5dunLv/Hl0/936srYHJ+snCImackQSh97mloLhKViUIUKSAiBUVE0U4D mtiKTKWg5I80O//pfTe/+3BoWqx3jgcMm6SAApA6QJsVkBHdIsjOAtdKhGmb thxCs0MIBPRXJ/rKc83SnfG2XTkiZL9OXatYnUAFvlutdEjBxTM5IFWHTzMj yAUpVmvN2gurZi9PKBlUdG2te/bk1c+/+uafXr8aCuYaTHoZUJxSobnP/cVa Yb/Lgk87IFUNShTVF66My/B37rz5o/duG0ZsAiE6S1MUTcVo5jbogbSmASCP R2bYHmc0XK3xQbyj3Ey0BUgJGThx6s3R8MDBPVSmmJoXhlaeWoAAgleJpO7W iGpGY8UOcjuIbLboEWriT0YpUKDvQYQEZKAvyr2urk9fOnP5D46f+tLZ9dSo Fo0p0NJjT17JaT50cxTPKoFCIBUmtYXIZXcc/eq+fR87snRgNwiQUNMSU1Uw iFHUo6MFfWK3+wuEbC1ehq7Ib0gSlICQXazBxczhEBr8wf/4rVF511syvfD0 /9Jm/Ojf/LcfeN/y2gRUsYfHXqOGZruVXNZQCmLcYvoKQTO6DAApQglgRK30 mUEiS4HVXMklCK9PN4+fWvny8VP/8/yF2LTh8Mf/zoVMUw2rJNuIemAYuRNF 7hZo9Fu33Pyv333oQ0dGC/MAkNVrMBycUVCrHjH6HpFB1asiAmTiC0IxvEXe 8eubTJ1iT+oYo23w+ssv/Pff/E8Lv/fC94dv75xf2r0UXzqD5UNHdy1YiIBF OC3uEmOVc2bHc0LIGRy8r8xA00xQbMHbYJ/dHgQvHXFwRAJQphJDXN4zeOjA nkf27kHu4pmCW1J+exoOteGSZFFe77sozW/cfOATR/bftAu9oBAKECOC1u9c aTx31VKk6HRArUI6AhC4T5MZJ5l3ANcGaH9fxtM3eP6FJ2g8Wnh4YdyWNnWn z/C+g9/54tcX/+HPfZjZR4SYOM/FZhFRAWxRrBy39Ebum6+giNC7ya8V3Fgh 1Us0RJTi2wqsgYNwYY3DOT02v7Cw49aw42O/8I5iOeA68tWe0PE/Xz74uYfv +Mg92wYDbGYgIiU/Sh5H2G24bOtaImzLZfcau0QJTOCqirYeH4L3H5qaPpD/ ph2i+dG7Tr75LO2YzB2/eCLc9MgjB5588qVy/vkjt/z1nftikXqpzYIdoOR8 9Oy+I3jTvf0JBJRcG6eraMuKO/bAju3N6rJHlgKlwFCUPO3b1PBUoZTeLLiy wf9g+86nHnn3v/rQvv3LWBVkYDRCCMiCXv2mIlOLxGp1nKFWCq5raHXJSE4Q mF1plal4LkjVWEkJISKQi6IP377zp3/+7594bYXeOXL0k3/vmZcXDyxM33zl xF8+913bmExOhM1+rLDjGn7y4hajEqIE9G7XaLeEgbgMsEBDxYJmYcxAJGZW 1bWNrs/gwShF5gAuGxvHeO6LD977bx69/ehB3rARRwGc0HWOYmY30eYUg7CF A41QKrXq6XBxqz/OO3rMdN8d5KuBnF38JsNHhAgmHQ4ePNrtTe8snHnhK8/e 8+P3ne127bnr0IkzrwvQW8u4+GEy3aIVPZ0XqkUgcZSGokD09RBGVmeSzWGL p/7tTGILQmKAKBClFHNB320IiPc27Wfvuvsbn7z3J+6ZU2Ai4AYFyMUr4ERb 74gYyYZDiEcZ2Nmpq2p3OQR0g1pMzNHL+i9n01zsNrGPNrQTQYrFUbj9yIPz 11f2DFdf+9YX33Pr3NW3cNt4h1UVZh6DXtMLkAwEcHZwaA9Wa35bMCoQEoEZ XXYchwJuaxHAnfvBAQ0TMUXiAGVpIMqfvvfwL3xg13CMjYK1DqubWN9At4mc XTRQMoSQzb9eEQiznT67eW1bSY0CYBDQC1KtlaBWIuz2Iar/IT58xa4iy1SP 3n/H9MrlW6Yv751b/7P/c+LWIw+97299WDIg1VPY/HTYF8AAkps2Rh/iwvVC MJI5BA9/5glepNpFSTW1ty+iUEIIRCyJWWMBKb/30MJqj4srk41NbSPmRmgG 4OS2tPGGcUENQWKVYxiUI5fTcXX4DZXxMpRkrooWp2FhngGBmP2wrWGp2wwA IwPc5fSJ+8pdc69/X+577w60h5Z2oyisyco41WgW2IJg+Je22EgL2HaQCYjq fftU7Z+cM1AHujMVjAWBYtR1iAhMAkC5DVif5EEaLCzSuEVsMGwwHKAZeOHA bgQbzVOTSChBM1SQ2QlIa+HxmT8WaKxESp58mOWN/QRxKaL9MtX6qDICMN6+ p3vjxPx/PtvuGqxf16XFNqFKyypjblMyyLRVETH4PDCG7y+t/TSA+w5b0DGT yK5AZxxmLRr5sxvuU6WgFAKIo6oMYhwOfdgNV//QwAgRvcV8IzN1awOjjljw WVKWARhushSs/moRzCBLFq8G+LQL8m9uQUqAWKAJ2Fw/rdv2/tXbL+ny+vXJ nW2xF2qrFQiAN4BmBTpQQKlTeKQCt5kSwUqwtk45wPo+Ac9soaAAVsu4gLoT mVCgRExUOHJoW4c/hbxMgMrom4pGzJBcq1OE/flqxgXUoRPqaVQWP4NUzetn MgWwOyv7FxAPeb4FAgiYTDc/8KG7vnv2uG6e3L5r/sD+Ny9dR0pOSOUMyRXE MgpB1aszeWujezD2aDXbIOriR4g/M9fQwDWA2MyQAooaExMDzBEcq6UY/ED5 fJyafLK4eRnqGCWrSFp/KRV0gChiqHMA4BdiVmjvOJPqDRIZ69WTYFZbttW3 wsSe3XN//Iff/dhP3dodf33h4umv/ckf//m3vtfaHA9BSP6CrTaEWkX2Hc4g YNrfkMrVRbUwHw0HMbLWmVRaD0d9kuLjwFRJQcSWlN/4E5OnwhkQeIgJNpmu WgiQTZuyk2+mnDYLUXx5I9enT2Dyt+n4TTEftshDVXA0kKlEmEw2v/Kd6a/8 +kd/97FXfu7TP7lapnuP3NvONXZhZ4X0vjus5hDV6/vm0G87u01bX2oWRc3Y oIhwgUF2g+b2VHWZ/J7x6YsmYfZrW3wcl8L0JDVYMNq6QtTW6XEAAAbySURB VIm2LjUqLua98e434G+/LaguktVGUk1Eb1rV4jHIak7slzeFgAlNL/6739n8 wslfi4tf/fJTt23f/dAfHb/y9qUEgHxoQGTgBvkcASUjVwJ79jxGBuhsKIFX uZgSmgRAetFiMaTuOCPzbKxaZLKbii1LiMGBsh0xBZAdE5sRkH1nqkPoDMWb koB7XysySki96aAoJFbv/1LnuVl7fQAEauaeFaGIaAy4/s6JyZ3jU8vN/+vW Hjhyz2q3+r333/zq80/18NTPEXy9EyyCCAE2tG9GE89oyVL/VcV3li0G5tx1 yLVeaOBWUAKSVk41EBOx3XyGYiN7IcxOis9GNAJMAa2LD7+/bOOV5IfRPaTM vKtSpf5RFrkJCd52J0bXck0+RQORAt/8xhd3Le9aQx7+2NKla2clzje3xLMX nzt5AilAAap+zL5TBAAS0BGkgK2nk5xTF4GEH0oDnIBSBEJITS8VoCsoIDKC ojebBDWRsfmLh+pAYkfGRB822eeGDMgZFqm8FJzuCgVwkaafbVJI5ytcKvlv L6svEAKXShuoT18UQmjw2qkXX/yzl2OK9M2rpdGVt9dHO3dMz07np6tf+cIf WTFUZn7nluhYKhsRgL6gr3y2PSrU00nUnVfgiTcFEKmQz+OzCaCxHgijmhhQ 4nqx1AhinbeoqbMdN7MxtzdlmDBQnQwhkOBpmmFZsYs8uNifxHNRS69NcWmJ lc/uMqWgUiRcfvxrD28/Mjfs7n7xwv5v753//XOXnlm97ereu798Ol95/MR3 J02CCEpxv6vZhaYFwVphphCdscTQ2eLZG6sLZjsgMZNoEeS8NafS6DDNKIXF JoZeXdcCkIBqxdmYIKeBG5B60QrsVQ0OyIrGZDZm5sE+L5MAJRuVh1jfnXGA MMf3AJWKIep5oV450LDFP/mlX4v5MsY7+stXdj/y88MBzy0eeOeVL51+6gXC O0cPfPLvfuaXNzsEswubATGqbElB7iERsQ5usD+UZ7xV3qJ6s+i5y93OhSC9 pNSE6GfTntZGcTEpUHvgPD2tJ44VMfpZMBxkLJQ1QdjmvBF92MAouxO7WfIp jnY9lRGAtrCMzGbvKURzaPDWhSvLB9Z5uLytXLrjvfdd/up/CKtnzz/+G93Z iw/cs9mOD7947vHnX9oYJJ+dmI1Qrwo6GGSzOZICKVs3TM3GUMMDlHF9RQ/t bWOIYJ3maZGZ7yy0ICZT/vWildcQ3NDIYMdH0USEOtomGhCf3aPkmglPjrYa RRAZofEk07L5EFwA9EM1JQufAtECjYlw7uR3Tr56eaDXOt37+nMv7bn13uvH n5hcHS0Prjz9p/22NB1n/cJ//cxE6hS1uqIOauzQGdQo6MX5cq3hiQEJyOT0 w84l7mymD0cplLseUgU2Nm2WEEISkVgrMVvYx6kZQi+OSmcDVbm43Z+jWALU p2xax4FjX9fn1CSrVBsmuErIAhkFSMlQJQoEfP/7f7Fz77G9D/2Yjuf3yytP f/1b23fds2306vFzw4/+0k+eS4cGF98488TXXnr+/Hvu3zMpsFFnM6rIIzQh RpQM6REaaHE+oGgVJtpwK0LOrhJoQshcOhFksPRMiVSIqIiCisMMh+Q3Xm03 FGmyeNlLtkAJ2HCN3WtV76+V/bBB5Kg8kclM/EKYpUhOJxVQslrT60++8/47 Fn/wv790+lP/Pn/79Lu/fo7o2rX19sePXwzfe+3EZ3//zO+9dP8D+7/xJ18N AwAgMq5hy9rINZ/qD+z4sN4YOYJ7aKgBHFvL3HDU0mvJQqkAqqxmRScECPs8 XnVqyraVzFDsDaDPORD73753IfXNGfK2WCbw8UK4IQ8KgNR0dAb/e2oNvwnw 3pU3n/38i/OXpvM/Onzh+TPnx3Ph6sbCeHhtLb16ZiW1aXd/6uRvvjD/3BNv XkQKKAVFvWYt9Q/Z7LzASA0gTpk6/CmQUAejY2s5lcCJmWk63dReICKYailk A6vB7E4bAiJoZ9fwTAyxhYyy5fEENWNJwIYhmcJPyQfg0UwIKMi1t5BndQgb hGe1tpxBarFfBRub/edXdxz4mbn1w8tzx/pwdN/6R9vV4S7Gxdc+fPuuY5N+ efv8o1F+9n0vTt6+dHrd+uWJvPOMasSwPWVTdGbOD1Sb+2ax1P5BMOjEIJGU onI/mVwppUgJRXOvm1TMyo78jACg6NvSPtGLdnDdrsIFqcXm+tYpJs43kR/Y mTQwVJrFEletebaDF45WyzZisFvb/NQdS2890c3jwtqZURPOtdeYbz9f4uLB V09fWxqMrl5deaIZbJ548O73jAZ5MnGZlD2tkbO2p/0xtE6DQB1pNSMI6z+x qXwWZHKWQG1sG2YGiYFCYSHg/wMA+YxbDCbU9gAAAABJRU5ErkJgggAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEgBYAAoAAQBbAA8AAgAAAAAAAAAwAABA8f8CADAA DAAGAE4AbwByAG0AYQBsAAAAAgAAABAAX0gBBG1ICgxzSAoMdEgKDDgAAUAB AAIAOAAMAAgAVADtAHQAdQBsAG8AIAAxAAAACAABAAYkAUAmAA4ANQiBbUgJ BHNICQR1CABEAAJAAQACAEQADAAIAFQA7QB0AHUAbABvACAAMgAAABAAAgAG JAETpPAAFKQ8AEAmARIANQiBNgiBQ0oYAE9KAgBRSgIAPgADQAEAAgA+AAwA CABUAO0AdAB1AGwAbwAgADMAAAAQAAMABiQBE6TwABSkPABAJgIMAENKGABP SgIAUUoCAEIABEABAAIAQgAMAAgAVADtAHQAdQBsAG8AIAA0AAAAEAAEAAYk AROk8AAUpDwAQCYDDwA1CIFDShgAT0oCAFFKAgAANAAFQAEAAgA0AAwACABU AO0AdAB1AGwAbwAgADUAAAANAAUAE6TwABSkPABAJgQABABDShYAOAAGQAEA AgA4AAwACABUAO0AdAB1AGwAbwAgADYAAAANAAYAE6TwABSkPABAJgUABwA2 CIFDShYAADgAB0ABAAIAOAAMAAgAVADtAHQAdQBsAG8AIAA3AAAADQAHABOk 8AAUpDwAQCYGAAgAT0oCAFFKAgA8AAhAAQACADwADAAIAFQA7QB0AHUAbABv ACAAOAAAAA0ACAATpPAAFKQ8AEAmBwALADYIgU9KAgBRSgIAAEIACUABAAIA QgAMAAgAVADtAHQAdQBsAG8AIAA5AAAADQAJABOk8AAUpDwAQCYIABIANQiB NgiBQ0oSAE9KAgBRSgIARgBBQPL/oQBGAAwAGwBGAHUAZQBuAHQAZQAgAGQA ZQAgAHAA4QByAHIAYQBmAG8AIABwAHIAZQBkAGUAdABlAHIALgAAAAAAAAAA AAAAAAAuAFVAogDxAC4ADAAMAEgAaQBwAGUAcgB2AO0AbgBjAHUAbABvAAAA BgA+KgFCKgJMAD5AAQACAUwADAAGAFQA7QB0AHUAbABvAAAAGwAQAAMkAQ3G BQABMweAD4QcAUAmAF6EHAFhJAEAEgA1CIFDSigAbUgJBHNICQR1CAA0AB9A AQASATQADAAKAEUAbgBjAGEAYgBlAHoAYQBkAG8AAAANABEADcYIAAJDEYYi AQIAAAA6ACBAAQAiAToADAANAFAAaQBlACAAZABlACAAcADhAGcAaQBuAGEA AAANABIADcYIAAJDEYYiAQIAAAAoAD9AAQAyASgADAAGAEMAaQBlAHIAcgBl AAAACgATAA+EnBBehJwQAAA+AERAAQBCAT4ADAAPAEMAbwBuAHQAaQBuAHUA YQByACAAbABpAHMAdABhAAAADgAUAA+EGwEUpHgAXoQbAQAAQgBFQAEAUgFC AAwAEQBDAG8AbgB0AGkAbgB1AGEAcgAgAGwAaQBzAHQAYQAgADIAAAAOABUA D4Q2AhSkeABehDYCAABCAEZAAQBiAUIADAARAEMAbwBuAHQAaQBuAHUAYQBy ACAAbABpAHMAdABhACAAMwAAAA4AFgAPhFEDFKR4AF6EUQMAAEIAR0ABAHIB QgAMABEAQwBvAG4AdABpAG4AdQBhAHIAIABsAGkAcwB0AGEAIAA0AAAADgAX AA+EbAQUpHgAXoRsBAAAQgBIQAEAggFCAAwAEQBDAG8AbgB0AGkAbgB1AGEA cgAgAGwAaQBzAHQAYQAgADUAAAAOABgAD4SHBRSkeABehIcFAABeACRAAQCS AV4ADAAPAEQAaQByAGUAYwBjAGkA8wBuACAAcwBvAGIAcgBlAAAAIQAZAA+E QAsYhPz/GYT0/xqE8B4bJoArRLwHL4SNAF6EQAsADABDShgAT0oCAFFKAgBO AC5AAQACAE4ADAATAEUAbgBjAGEAYgBlAHoAYQBkAG8AIABkAGUAIABsAGkA cwB0AGEAAAAGABoAE6R4AA8ANQiBQ0oYAE9KAgBRSgIAAHYASUABALIBdgAM ABUARQBuAGMAYQBiAGUAegBhAGQAbwAgAGQAZQAgAG0AZQBuAHMAYQBqAGUA AAAuABsAD4RuBBGEkvskZAYBAAElZAYBAAEmZAYBAAEnZAYBAAEtRAAQXoRu BGCEkvsMAENKGABPSgIAUUoCADgAT0ABAAIAOAAMABIARQBuAGMAYQBiAGUA egBhAGQAbwAgAGQAZQAgAG4AbwB0AGEAAAACABwAAAAwACJAAQACADAADAAI AEUAcADtAGcAcgBhAGYAZQAAAAoAHQATpHgAFKR4AAMANQiBAB4ATEABAAIA HgAMAAUARgBlAGMAaABhAAAAAgAeAAAAJgBAQAEA8gEmAAwABQBGAGkAcgBt AGEAAAAKAB8AD4ScEF6EnBAAADQACkABAAIANAANAAgAzQBuAGQAaQBjAGUA IAAxAAAAEgAgAA+EyAARhDj/XoTIAGCEOP8AADQAC0ABAAIANAANAAgAzQBu AGQAaQBjAGUAIAAyAAAAEgAhAA+EkAERhDj/XoSQAWCEOP8AADQADEABAAIA NAANAAgAzQBuAGQAaQBjAGUAIAAzAAAAEgAiAA+EWAIRhDj/XoRYAmCEOP8A ADQADUABAAIANAANAAgAzQBuAGQAaQBjAGUAIAA0AAAAEgAjAA+EIAMRhDj/ XoQgA2CEOP8AADQADkABAAIANAANAAgAzQBuAGQAaQBjAGUAIAA1AAAAEgAk AA+E6AMRhDj/XoToA2CEOP8AADQAD0ABAAIANAANAAgAzQBuAGQAaQBjAGUA IAA2AAAAEgAlAA+EsAQRhDj/XoSwBGCEOP8AADQAEEABAAIANAANAAgAzQBu AGQAaQBjAGUAIAA3AAAAEgAmAA+EeAURhDj/XoR4BWCEOP8AADQAEUABAAIA NAANAAgAzQBuAGQAaQBjAGUAIAA4AAAAEgAnAA+EQAYRhDj/XoRABmCEOP8A ADQAEkABAAIANAANAAgAzQBuAGQAaQBjAGUAIAA5AAAAEgAoAA+ECAcRhDj/ XoQIB2CEOP8AAC4AL0ABAJICLgAMAAUATABpAHMAdABhAAAAEgApAA+EGwER hOX+XoQbAWCE5f4AADIAMkABAKICMgAMAAcATABpAHMAdABhACAAMgAAABIA KgAPhDYCEYTl/l6ENgJghOX+AAAyADNAAQCyAjIADAAHAEwAaQBzAHQAYQAg ADMAAAASACsAD4RRAxGE5f5ehFEDYITl/gAAMgA0QAEAwgIyAAwABwBMAGkA cwB0AGEAIAA0AAAAEgAsAA+EbAQRhOX+XoRsBGCE5f4AADIANUABANICMgAM AAcATABpAHMAdABhACAANQAAABIALQAPhIcFEYTl/l6EhwVghOX+AAA+ADFA AQDiAj4ADAARAEwAaQBzAHQAYQAgAGMAbwBuACAAbgD6AG0AZQByAG8AcwAA AAkALgAKJgALRioAAAAAQgA6QAEA8gJCAAwAEwBMAGkAcwB0AGEAIABjAG8A bgAgAG4A+gBtAGUAcgBvAHMAIAAyAAAACQAvAAomAAtGKwAAAABCADtAAQAC A0IADAATAEwAaQBzAHQAYQAgAGMAbwBuACAAbgD6AG0AZQByAG8AcwAgADMA AAAJADAACiYAC0YsAAAAAEIAPEABABIDQgAMABMATABpAHMAdABhACAAYwBv AG4AIABuAPoAbQBlAHIAbwBzACAANAAAAAkAMQAKJgALRi0AAAAAQgA9QAEA IgNCAAwAEwBMAGkAcwB0AGEAIABjAG8AbgAgAG4A+gBtAGUAcgBvAHMAIAA1 AAAACQAyAAomAAtGLgAAAAA+ADBAAQAyAz4ADQARAEwAaQBzAHQAYQAgAGMA bwBuACAAdgBpAPEAZQB0AGEAcwAAAAkAMwAKJgALRi8AAAAAQgA2QAEAQgNC AA0AEwBMAGkAcwB0AGEAIABjAG8AbgAgAHYAaQDxAGUAdABhAHMAIAAyAAAA CQA0AAomAAtGMAAAAABCADdAAQBSA0IADQATAEwAaQBzAHQAYQAgAGMAbwBu ACAAdgBpAPEAZQB0AGEAcwAgADMAAAAJADUACiYAC0YxAAAAAEIAOEABAGID QgANABMATABpAHMAdABhACAAYwBvAG4AIAB2AGkA8QBlAHQAYQBzACAANAAA AAkANgAKJgALRjIAAAAAQgA5QAEAcgNCAA0AEwBMAGkAcwB0AGEAIABjAG8A bgAgAHYAaQDxAGUAdABhAHMAIAA1AAAACQA3AAomAAtGMwAAAABEAFlAAQCC A0QADAASAE0AYQBwAGEAIABkAGUAbAAgAGQAbwBjAHUAbQBlAG4AdABvAAAA BgA4AC1EIAEIAE9KBQBRSgUAOgAlQAEAkgM6AAwADwBSAGUAbQBpAHQAZQAg AGQAZQAgAHMAbwBiAHIAZQAAAAIAOQAIAE9KAgBRSgIAIABLQAEAAgAgAAwA BgBTAGEAbAB1AGQAbwAAAAIAOgAAAGAAUkABALIDYAAMAB0AUwBhAG4AZwBy AO0AYQAgADIAIABkAGUAIAB0AC4AIABpAG4AZABlAHAAZQBuAGQAaQBlAG4A dABlAAAAFAA7AA+EGwESZOABAQAUpHgAXoQbAQAAXgBTQAEAwgNeAAwAHQBT AGEAbgBnAHIA7QBhACAAMwAgAGQAZQAgAHQALgAgAGkAbgBkAGUAcABlAG4A ZABpAGUAbgB0AGUAAAAOADwAD4QbARSkeABehBsBBABDShAAVgBDQAEA0gNW AAwAGwBTAGEAbgBnAHIA7QBhACAAZABlACAAdAAuACAAaQBuAGQAZQBwAGUA bgBkAGkAZQBuAHQAZQAAAA4APQAPhBsBFKR4AF6EGwEAADgAHEABAOIDOAAM AA4AUwBhAG4AZwByAO0AYQAgAG4AbwByAG0AYQBsAAAACgA+AA+ExAJehMQC AABAAEpAAQDyA0AADAAJAFMAdQBiAHQA7QB0AHUAbABvAAAADwA/AAMkARSk PABAJgFhJAEADABDShgAT0oCAFFKAgBQACNAAQACAFAADAAWAFQAYQBiAGwA YQAgAGQAZQAgAGkAbAB1AHMAdAByAGEAYwBpAG8AbgBlAHMAAAASAEAAD4SQ ARGEcP5ehJABYIRw/gAAHgATQAEAAgAeAA0ABQBUAEQAQwAgADEAAAACAEEA AAAmABRAAQACACYADQAFAFQARABDACAAMgAAAAoAQgAPhMgAXoTIAAAAJgAV QAEAAgAmAA0ABQBUAEQAQwAgADMAAAAKAEMAD4SQAV6EkAEAACYAFkABAAIA JgANAAUAVABEAEMAIAA0AAAACgBEAA+EWAJehFgCAAAmABdAAQACACYADQAF AFQARABDACAANQAAAAoARQAPhCADXoQgAwAAJgAYQAEAAgAmAA0ABQBUAEQA QwAgADYAAAAKAEYAD4ToA16E6AMAACYAGUABAAIAJgANAAUAVABEAEMAIAA3 AAAACgBHAA+EsARehLAEAAAmABpAAQACACYADQAFAFQARABDACAAOAAAAAoA SAAPhHgFXoR4BQAAJgAbQAEAAgAmAA0ABQBUAEQAQwAgADkAAAAKAEkAD4RA Bl6EQAYAADQAHkABAKIENAAMABAAVABlAHgAdABvACAAYwBvAG0AZQBuAHQA YQByAGkAbwAAAAIASgAAAEYALEABAAIARgAMABEAVABlAHgAdABvACAAYwBv AG4AIABzAGEAbgBnAHIA7QBhAAAAEgBLAA+EyAARhDj/XoTIAGCEOP8AAEYA VEABAMIERgAMAA8AVABlAHgAdABvACAAZABlACAAYgBsAG8AcQB1AGUAAAAW AEwADoSgBQ+EoAUUpHgAXYSgBV6EoAUAAD4AQkABANIEPgAMABMAVABlAHgA dABvACAAaQBuAGQAZQBwAGUAbgBkAGkAZQBuAHQAZQAAAAYATQAUpHgAAABI AFBAAQDiBEgADAAVAFQAZQB4AHQAbwAgAGkAbgBkAGUAcABlAG4AZABpAGUA bgB0AGUAIAAyAAAADABOABJk4AEBABSkeAAAAEYAUUABAPIERgAMABUAVABl AHgAdABvACAAaQBuAGQAZQBwAGUAbgBkAGkAZQBuAHQAZQAgADMAAAAGAE8A FKR4AAQAQ0oQAGIATUDRBAIFYgAMACMAVABlAHgAdABvACAAaQBuAGQAZQBw AGUAbgBkAGkAZQBuAHQAZQAgAHAAcgBpAG0AZQByAGEAIABzAGEAbgBnAHIA 7QBhAAAACgBQABGE0gBghNIAAABmAE5A0QMSBWYADAAlAFQAZQB4AHQAbwAg AGkAbgBkAGUAcABlAG4AZABpAGUAbgB0AGUAIABwAHIAaQBtAGUAcgBhACAA cwBhAG4AZwByAO0AYQAgADIAAAAKAFEAEYTSAGCE0gAAAGIALUDx/yIFYgAM AAsAVABlAHgAdABvACAAbQBhAGMAcgBvAAAAIgBSAA3GHQAJ4AHAA6AFgAdg CUALIA0AD+AQAAAAAAAAAAAAGABPSgYAUUoGAF9IAQRtSAoMc0gKDHRICgw6 ACtAAQAyBToADAATAFQAZQB4AHQAbwAgAG4AbwB0AGEAIABhAGwAIABmAGkA bgBhAGwAAAACAFMAAAAwAB1AAQBCBTAADAAOAFQAZQB4AHQAbwAgAG4AbwB0 AGEAIABwAGkAZQAAAAIAVAAAAD4AWkABAFIFPgAMABEAVABlAHgAdABvACAA cwBpAG4AIABmAG8AcgBtAGEAdABvAAAAAgBVAAgAT0oGAFFKBgBAACFAAQAC AkAADAAQAFQA7QB0AHUAbABvACAAZABlACAA7QBuAGQAaQBjAGUAAAACAFYA CwA1CIFPSgIAUUoCAACIAP5PAQByBYgADAAXAEgAVABNAEwAIABjAG8AbgAg AGYAbwByAG0AYQB0AG8AIABwAHIAZQB2AGkAbwAAADcAVwANxjIAEJQDKAe8 ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAAAAQ AE9KBwBQSgcAUUoHAF5KBQAAAAAAShwAABMAAEwAABIA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAAJAAAAEkAAABM AAAAAAQAAHwIAADXHwAASiAAABUAAAAbAAAAJQAAAAAEAABSBQAASAYAAIMM AACtFAAA4hcAAPUZAAB0HgAA1x8AAEogAAAWAAAAGAAAABoAAAAcAAAAHQAA AB8AAAAgAAAAIgAAACQAAAAABAAABwYAAHgVAABWGgAAoR4AAEogAAAXAAAA GQAAAB4AAAAhAAAAIwAAAA8AAPBsAAAAAAAG8BgAAAACCAAAAgAAAAIAAAAB AAAAAQAAAAMAAAAfAAHwLAAAAGIAB/AkAAAABgZt6WDCK3TdlKUFLt8ceDsJ /wBsRwAAAQAAACZMAAAAAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8A AvA0AQAAEAAI8AgAAAACAAAAAgQAAA8AA/DSAAAADwAE8CgAAAABAAnwEAAA AAAADQAAAAwAAAALAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8JoAAACyBArw CAAAAAIEAAAACgAAYwAL8GoAAAAEQQEAAAAFwRgAAAAGAQIAAAD/AQAACACD wy4AAAC/AyAAYABBADoAXABmAG8AdABvAC4AcABjAHgAAAAFAAgACAAh//// AAAAACH///+jUwAAYFQAAKNTAABgVAAAAAAAACH///8AAAAAAAAQ8AQAAAAA AAAAAAAR8AQAAAAuAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4A AAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAAa AAAAShwAAAIEAACXGwAAFAAAAEYhAADCBgAAtEIAAAAAAAAAAB0AAAAeAAAA hggAAIcIAAC+DAAAvwwAAMQMAADFDAAAzQwAAM4MAABcEwAAaBMAAM8TAADf EwAA0RkAANIZAAD/GwAASBwAAEscAAAHAAQABwAEAAcABAAHAAQABwAEAAcA BAAHAAQABwAEAAcABwACAAAAAAAdAAAAHgAAAIYIAACHCAAAvgwAAL8MAADE DAAAxQwAAM0MAADODAAAXBMAAGgTAADPEwAA3xMAANEZAADSGQAA/xsAAEgc AABLHAAABwAEAAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcABAAHAAcAAgD/ /xQAAAACAHAAcAAgAEMAOgBcAFcASQBOAEQATwBXAFMAXABFAHMAYwByAGkA dABvAHIAaQBvAFwAQwBWADEAMABlAG4ALgBkAG8AYwACAHAAcAAiAEMAOgBc AFcASQBOAEQATwBXAFMAXABFAHMAYwByAGkAdABvAHIAaQBvAFwAQwBWADEA MQBlAG4ARABBAC4AZABvAGMAAgBwAHAAIgBDADoAXABXAEkATgBEAE8AVwBT AFwARQBzAGMAcgBpAHQAbwByAGkAbwBcAEMAVgAxADEAZQBuAEQAQQAuAGQA bwBjAAIAcABwACIAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEUAcwBjAHIAaQB0 AG8AcgBpAG8AXABDAFYAMQAxAGUAbgBEAEEALgBkAG8AYwACAHAAcAAiAEMA OgBcAFcASQBOAEQATwBXAFMAXABFAHMAYwByAGkAdABvAHIAaQBvAFwAQwBW ADEAMQBlAG4ARABBAC4AZABvAGMABQBQAEMAMQAwADEAIgBDADoAXABXAEkA TgBEAE8AVwBTAFwARQBzAGMAcgBpAHQAbwByAGkAbwBcAEMAVgAxADIAZQBu AEQAQQAuAGQAbwBjAAUAUABDADEAMAAxAD4AQwA6AFwAVwBJAE4ARABPAFcA UwBcAFQARQBNAFAAXABHAHUAYQByAGQAYQBkAG8AIABjAG8AbgAgAEEAdQB0 AG8AcgByAGUAYwB1AHAAZQByAGEAYwBpAPMAbgAgAGQAZQAgAEMAVgAxADIA ZQBuAEQAQQAuAGEAcwBkAAkAVwBlAGIAIAAmACAAVwBlAG0APgBDADoAXABX AEkATgBEAE8AVwBTAFwAVABFAE0AUABcAEcAdQBhAHIAZABhAGQAbwAgAGMA bwBuACAAQQB1AHQAbwByAHIAZQBjAHUAcABlAHIAYQBjAGkA8wBuACAAZABl ACAAQwBWADEAMwBlAG4ARABBAC4AYQBzAGQACQBXAGUAYgAgACYAIABXAGUA bQAiAEMAOgBcAFcASQBOAEQATwBXAFMAXABFAHMAYwByAGkAdABvAHIAaQBv AFwAQwBWADEAMwBlAG4ARABBAC4AZABvAGMACQBXAGUAYgAgACYAIABXAGUA bQAiAEMAOgBcAFcASQBOAEQATwBXAFMAXABFAHMAYwByAGkAdABvAHIAaQBv AFwAQwBWADEAMwBlAG4ARABBAC4AZABvAGMANQB8////nlAKqTIA/w//D/8P /w//D/8P/w//DwEAff///6JjjHMxAP8P/w//D/8P/w//D/8P/w8BAH7///+O PpB/MAD/D/8P/w//D/8P/w//D/8PAQB/////mFm4hS8A/w//D/8P/w//D/8P /w//DwEAgP///7S9KL43AP8P/w//D/8P/w//D/8P/w8BAIH///8Y2rQaNgD/ D/8P/w//D/8P/w//D/8PAQCC////AJSafDUA/w//D/8P/w//D/8P/w//DwEA g////5IqxoQ0AP8P/w//D/8P/w//D/8P/w8BAIj///8sGLLeLgD/D/8P/w// D/8P/w//D/8PAQCJ////Et9KEjMA/w//D/8P/w//D/8P/w//DwEAai4EBA8A Cgz/DwAAAAAAAAAAAAAAAAAAAAABACNZSgcBAAoM/w8AAAAAAAAAAAAAAAAA AAAAAQDsa1ANVLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEA1XfnDVS3TMD/DwAA AAAAAAAAAAAAAAAAAAABAI1vkQ/Q2hyV/w8AAAAAAAAAAAAAAAAAAAAAAQCG AscPVLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEA1WZBE+5EdJP/DwAAAAAAAAAA AAAAAAAAAAABAD4r5BQBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQDmXh4VAQAK DP8PAAAAAAAAAAAAAAAAAAAAAAEAbCcUGgEACgz/DwAAAAAAAAAAAAAAAAAA AAABAK9WJhoBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQDraZgeAQAKDP8PAAAA AAAAAAAAAAAAAAAAAAEAbjMkIFS3TMD/DwAAAAAAAAAAAAAAAAAAAAABAMhI ZiJUt0zA/w8AAAAAAAAAAAAAAAAAAAAAAQCcJGgqAQAKDP8PAAAAAAAAAAAA AAAAAAAAAAEAb23rLAEACgz/DwAAAAAAAAAAAAAAAAAAAAABAF8eeS5Ut0zA /w8AAAAAAAAAAAAAAAAAAAAAAQCuUrgwuPiKNP8PAAAAAAAAAAAAAAAAAAAA AAEAM347OAEACgz/DwAAAAAAAAAAAAAAAAAAAAABAPgZUzgBAAoM/w8AAAAA AAAAAAAAAAAAAAAAAQD0ERs8AQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA01qy P1S3TMD/DwAAAAAAAAAAAAAAAAAAAAABAO9ANUEBAAoM/w8AAAAAAAAAAAAA AAAAAAAAAQA0GeREAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAtVG0RQEACgz/ DwAAAAAAAAAAAAAAAAAAAAABAMscgUkBAAoM/w8AAAAAAAAAAAAAAAAAAAAA AQA2MolKAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAs2lIUur+UPn/DwAAAAAA AAAAAAAAAAAAAAABAAJxRlcBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQASPExX AQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEATitCXO5EdJP/DwAAAAAAAAAAAAAA AAAAAAABAI4gxl5Ut0zA/w8AAAAAAAAAAAAAAAAAAAAAAQD8DfdhDwAKDP8P AAAAAAAAAAAAAAAAAAAAAAEA4kQcZAEACgz/DwAAAAAAAAAAAAAAAAAAAAAB AGB5+WRUt0zA/w8AAAAAAAAAAAAAAAAAAAAAAQDDV/1pVLdMwP8PAAAAAAAA AAAAAAAAAAAAAAEAvWytbAEACgz/DwAAAAAAAAAAAAAAAAAAAAABAO8b7W8B AAoM/w8AAAAAAAAAAAAAAAAAAAAAAQCKAg1wAQAKDP8PAAAAAAAAAAAAAAAA AAAAAAEA6nMsdQEACgz/DwAAAAAAAAAAAAAAAAAAAAABAHIVAXgBAAoM/w8A AAAAAAAAAAAAAAAAAAAAAQD8NN54VLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEA witVfAEACgz/DwAAAAAAAAAAAAAAAAAAAAABAAEAAAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAYAAAPhNQFEYSY/hXGBQAB1AUGXoTUBWCEmP4CAAAALgABAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4S5BBGEmP4VxgUAAbkEBl6EuQRg hJj+AgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EngMRhJj+ FcYFAAGeAwZehJ4DYISY/gIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAYAAAPhIMCEYSY/hXGBQABgwIGXoSDAmCEmP4CAAAALgABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAALGAAAD4TUBRGEmP4VxgUAAdQFBl6E1AVghJj+T0oB AFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EuQQR hJj+FcYFAAG5BAZehLkEYISY/k9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhJ4DEYSY/hXGBQABngMGXoSeA2CEmP5PSgEA UUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SDAhGE mP4VxgUAAYMCBl6EgwJghJj+T0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/gIAAAAu AAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEG XoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAA AAAAGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+AgAAAC4AAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9K AQBRSgEAbygAAQC38AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgB EYSY/hXGBQABaAEGXoRoAWCEmP5PSgAAUUoAAG8oAAEALQAAAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oA AFFKAABvKAABAC0AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAER hJj+FcYFAAFoAQZehGgBYISY/k9KAQBRSgEAbygAAQC38AAAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgAA UUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RoARGE mP4VxgUAAWgBBl6EaAFghJj+Q0oQAE9KCABRSggAbygAAQCn8AEAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5P SgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4Ro ARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9K AQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgB EYSY/hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oB AFFKAQBvKAABALfwAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAER hJj+FcYFAAFoAQZehGgBYISY/k9KAABRSgAAbygAAQAtAAAAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgAA UUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RoARGE mP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAQBR SgEAbygAAQC38AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY /hXGBQABaAEGXoRoAWCEmP5PSgAAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAASGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+QioAQ0oc AE9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAP hGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+ T0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E aAERhJj+FcYFAAFoAQZehGgBYISY/k9KAQBRSgEAbygAAQC38AAAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5P SgAAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4Ro ARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9K AQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgB EYSY/hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygA AQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQAB aAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAAPGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+Q0oQAE9KAQBRSgEA bygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXG BQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAA AAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBv KAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EaAERhJj+FcYF AAFoAQZehGgBYISY/kNKEABPSggAUUoIAG8oAAEAp/AAAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oAAFFK AABvKAABAC0AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EaAERhJj+ FcYFAAFoAQZehGgBYISY/gIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA AAsYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/AA AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6E aAFghJj+T0oAAFFKAABvKAABAC0AAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAABRSgAAbygAAQAtAAEA AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEGXoRo AWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAL GAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgB YISY/k9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFg hJj+T0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAABRSgAAbygAAQAtAAEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCE mP5PSgEAUUoBAG8oAAEAt/A1AAAA6nMsdQAAAAAAAAAAAAAAAG9t6ywAAAAA AAAAAAAAAAAjWUoHAAAAAAAAAAAAAAAAAnFGVwAAAAAAAAAAAAAAAJwkaCoA AAAAAAAAAAAAAAD4GVM4AAAAAAAAAAAAAAAAchUBeAAAAAAAAAAAAAAAAO8b 7W8AAAAAAAAAAAAAAAC1UbRFAAAAAAAAAAAAAAAA70A1QQAAAAAAAAAAAAAA ADQZ5EQAAAAAAAAAAAAAAADraZgeAAAAAAAAAAAAAAAArlK4MAAAAAAAAAAA AAAAADN+OzgAAAAAAAAAAAAAAAA+K+QUAAAAAAAAAAAAAAAANjKJSgAAAAAA AAAAAAAAAMIrVXwAAAAAAAAAAAAAAAC9bK1sAAAAAAAAAAAAAAAAigINcAAA AAAAAAAAAAAAAGouBAQAAAAAAAAAAAAAAAD8DfdhAAAAAAAAAAAAAAAA01qy PwAAAAAAAAAAAAAAAOZeHhUAAAAAAAAAAAAAAAASPExXAAAAAAAAAAAAAAAA Xx55LgAAAAAAAAAAAAAAAI4gxl4AAAAAAAAAAAAAAACGAscPAAAAAAAAAAAA AAAA/DTeeAAAAAAAAAAAAAAAAOJEHGQAAAAAAAAAAAAAAABOK0JcAAAAAAAA AAAAAAAA1WZBEwAAAAAAAAAAAAAAALNpSFIAAAAAAAAAAAAAAACNb5EPAAAA AAAAAAAAAAAAYHn5ZAAAAAAAAAAAAAAAAGwnFBoAAAAAAAAAAAAAAABuMyQg AAAAAAAAAAAAAAAAyEhmIgAAAAAAAAAAAAAAANV35w0AAAAAAAAAAAAAAADD V/1pAAAAAAAAAAAAAAAA7GtQDQAAAAAAAAAAAAAAAK9WJhoAAAAAAAAAAAAA AACI////AAAAAAAAAAAAAAAAf////wAAAAAAAAAAAAAAAH7///8AAAAAAAAA AAAAAAB9////AAAAAAAAAAAAAAAAfP///wAAAAAAAAAAAAAAAIn///8AAAAA AAAAAAAAAACD////AAAAAAAAAAAAAAAAgv///wAAAAAAAAAAAAAAAIH///8A AAAAAAAAAAAAAACA////AAAAAAAAAAAAAAAA9BEbPAAAAAAAAAAAAAAAAMsc gUkAAAAAAAAAAAAAAAD///////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////NQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/QAOAAQAFAAAABQAAAJiAdwDIAMgA BQAAAAAAAAAFAAAATwjMIgIQAAAAAAAAAEocAAAwAQAIAEAAAAkAAABHFpAB AAACAgYDBQQFAgMEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAVABpAG0AZQBz ACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAA ABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgIC AgIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAQQByAGkAYQBsAAAANyaQAQAA AgsGBAMFBAQCBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAFYAZQByAGQAYQBu AGEAAABBJpABAAACCwUGAgICAwIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAA QQByAGkAYQBsACAATgBhAHIAcgBvAHcAAAA1JpABAAACCwYEAwUEBAIEhzoA AAAAAAAAAAAAAAAAAP8AAAAAAAAAVABhAGgAbwBtAGEAAAA/NZABAAACBwMJ AgIFAgQEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAQwBvAHUAcgBpAGUAcgAg AE4AZQB3AAAASSaQAYAAAgsGBAICAgICBP/////////pPwAAAAAAAAD/AD8A AAAAAEEAcgBpAGEAbAAgAFUAbgBpAGMAbwBkAGUAIABNAFMAAAA7BpABAgAF AAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkA bgBnAHMAAAAiAAQAMQiIGADwxQIAAKkBAAAAADvrZWaNy2ZGSXVhJgsAgAAA AAwEAAAVFwAAAQALAAAABAADEDEAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAA IQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAApQbAB7QAtACAABIwAAAQABkAZAAAABkAAABYHAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/BsAAAAAAAAAAAAAAAAA AAAAAAAAAAIAAAAAAP//EgAAAAAAAAAYAFIAbwBsAGEAbgBkAG8AIABKAG8A cgBnAGUAIABaAGEAcABwAGEAYwBvAHMAdABhAAAAAAAAABAAbQBpAGMAcgBv AGkAbgBmAG8AcgBtAGEAdABpAGMAYQAJAFcAZQBiACAAJgAgAFcAZQBtAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y +U9oEKuRCAArJ7PZMAAAAKQBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADE AAAABAAAANAAAAAFAAAA7AAAAAYAAAD4AAAABwAAAAQBAAAIAAAAGAEAAAkA AAAsAQAAEgAAADgBAAAKAAAAVAEAAAsAAABgAQAADAAAAGwBAAANAAAAeAEA AA4AAACEAQAADwAAAIwBAAAQAAAAlAEAABMAAACcAQAAAgAAAOQEAAAeAAAA GQAAAFJvbGFuZG8gSm9yZ2UgWmFwcGFjb3N0YQAAMAAeAAAAAQAAAABvbGEe AAAAEQAAAG1pY3JvaW5mb3JtYXRpY2EAcGFjHgAAAAEAAAAAaWNyHgAAAAEA AAAAaWNyHgAAAAsAAABOb3JtYWwuZG90AGEeAAAACgAAAFdlYiAmIFdlbQAA YR4AAAADAAAAMTEAIB4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAGNAAAAA AACj4REAAABAAAAAAG407C6dwQFAAAAAALI01v8GwgFAAAAAAC7OpUEcwgED AAAAAQAAAAMAAAAMBAAAAwAAABUXAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN 1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuWAEAABQBAAAMAAAA AQAAAGgAAAAPAAAAcAAAAAUAAACQAAAABgAAAJgAAAARAAAAoAAAABcAAACo AAAACwAAALAAAAAQAAAAuAAAABMAAADAAAAAFgAAAMgAAAANAAAA0AAAAAwA AAD1AAAAAgAAAOQEAAAeAAAAGAAAAFRlbGVm825pY2EgZGUgQXJnZW50aW5h AAMAAAAxAAAAAwAAAAsAAAADAAAAWBwAAAMAAABqEAgACwAAAAAAAAALAAAA AAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAABkAAABSb2xhbmRvIEpvcmdl IFphcHBhY29zdGEADBAAAAIAAAAeAAAABwAAAFTtdHVsbwADAAAAAQAAAAwB AAAEAAAAAAAAACgAAAABAAAAUgAAAAIAAABaAAAAAwAAALIAAAACAAAAAgAA AAoAAABfUElEX0dVSUQAAwAAAAwAAABfUElEX0hMSU5LUwACAAAA5AQAAEEA AABOAAAAewBDADMAMgBBAEYAMgBFADAALQA3ADEAOAAxAC0AMQAxAEQANgAt ADkAMABGAEIALQAwADAAMAAyADQANAAxAEYANQBDADkARQB9AAAAAABBAAAA UAAAAAYAAAADAAAATQBlAAMAAAD/////AwAAAAIEAAADAAAAAQAAAB8AAAAM AAAAQQA6AFwAZgBvAHQAbwAuAHAAYwB4AAAAHwAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA AAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAA ABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAA HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAq AAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUA AAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAA AEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAP7///9LAAAA TAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABX AAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIA AABjAAAAZAAAAGUAAABmAAAA/v///2gAAABpAAAAagAAAGsAAABsAAAAbQAA AG4AAAD+////cAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAP7////9//// eQAAAP7////+/////v////////////////////////9SAG8AbwB0ACAARQBu AHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAA4Iu5 5zAcwgGAybrFQRzCAXsAAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO AAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAASgAAAPc4AAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAkpMAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGcAAAAAEAAA AAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbwAAAAAQAAAAAAAAAQBD AG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAawAAAAAAAABPAGIAagBlAGMA dABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAFgABAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA gMm6xUEcwgGAybrFQRzCAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////8BAP7/AwoA AP////8GCQIAAAAAAMAAAAAAAABGGQAAAERvY3VtZW50byBNaWNyb3NvZnQg V29yZAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA== ------=_NextPart_000_3bcd_4ea6_17d6-- From owner-mpls@UU.NET Wed Jul 3 14:05:23 2002 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 ESMTP id OAA24614 for ; Wed, 3 Jul 2002 14:05:22 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxy11165 for ; Wed, 3 Jul 2002 16:39:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvxy08522; Wed, 3 Jul 2002 16:38:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvxy21805 for mpls-outgoing; Wed, 3 Jul 2002 16:38:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvxy21796 for ; Wed, 3 Jul 2002 16: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 QQmvxy04802 for ; Wed, 3 Jul 2002 16:36:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvxy07692 for ; Wed, 3 Jul 2002 16:36:36 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmvxy07683 for ; Wed, 3 Jul 2002 16:36:36 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17Pmgl-0005vn-00; Wed, 03 Jul 2002 17:09:07 +0100 Subject: RE: your mail From: Giles Heron To: neil.2.harrison@bt.com Cc: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Jul 2002 17:09:07 +0000 Message-Id: <1025716147.1450.149.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2002-07-03 at 07:41, neil.2.harrison@bt.com wrote: > > > is there anything > > wrong with hashing for loadsharing purposes *other* than the fact that > > it makes doing OAM the way you've proposed difficult, if not > > impossible? > NH=> This is not actually where this all started Eric, and neither is it the > main/only reason I have grave concerns over LDP....in fact, I'd assume it > makes any OAM difficult (even LSP Ping), but please correct if this is a > wrong view. The underlying question (which Shahram posed some time ago) is > 'what network problems does mp2p LDP solve (that cannot be better addressed > using IP or p2p LSPs)?' I never saw any answer that convinced me LDP is > necessary....sure it exists and is out there, but what killer problem is it > there to solve? It then expanded (various threads, some even prior to this) > that pointed out some of the consequences of LDP for operators.....let me > list a few to remind you: [rest snipped] so let's to go back to Yakov's email of 31st May: ------ Giles, > 1. Efficient encapsulation of VPN traffic > 2. Ability to run VPN on current hardware > > There are probably other reasons as well... One of the "other reasons" is straightforward protection against packet spoofing. Yakov. ------ whether these are "killer" reasons to deploy LDP rather than "pure IP" or not depends on your point of view, but they are certainly reasons. there are of course others - e.g. the ability to run a BGP free core (which some consider important for running carrier-grade voice and Internet over the same PSN infrastructure). Giles - VPN survivability is a function of all cross-VPN traffic and is > temporally non-deterministic on a per customer basis per epoch. That is, > there is no relationship between a DS codepoint and that pkt's > 'survivability priority' vis-a-vis other pkts of same/different DS > codepoints in either the same or other VPNs....and that's a consequence of > like-DS-class merging across VPN populations. > - because of this hard QoS/availability guarantees per VPN customer > are not possible > - because of this we are forced over-engineer and hope > - MPLS introduces new failures modes even in p2p mode (this is the > absolute vs relative addressing issue that I mentioned previously), but mp2p > LSPs create a new richness of fault-management complexity > - the LDP LSPs track the IGP and so the network is not flexible wrt > traffic sensitivities......hence, it requires hashing functions at P nodes > which not only breaks the MPLS simple label forwarding idea of MPLS but > introduces another level of fault-management to deal with. > > So the fault-management issue (which you think is not important given the > tone of your response) is but 1 consequence of LDP. Similarly, the > load-balancing issue is another consequence of LDP. And similarly, another > consequence of LDP is the inability to decouple VPN performance/availability > on a *per customer basis*. So all these aspects are compromised when we use > LDP......and for what compelling advantage(s) over using an IPinIP solution > (or p2p LSPs as/when necessary)? So please answer that for me so that I can > understand what I and others are clearly missing here that makes LDP so > wonderful that we simply can't afford to live without it? > > regards, Neil > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Wed Jul 3 14:05:46 2002 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 ESMTP id OAA24642 for ; Wed, 3 Jul 2002 14:05:45 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyc06756 for ; Wed, 3 Jul 2002 17:31:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvyc03634; Wed, 3 Jul 2002 17:30:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvyc18416 for mpls-outgoing; Wed, 3 Jul 2002 17:30:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvyc18410 for ; Wed, 3 Jul 2002 17:30: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 QQmvyb16529 for ; Wed, 3 Jul 2002 17:29:28 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyb13897 for ; Wed, 3 Jul 2002 17:29:28 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 QQmvyb13889 for ; Wed, 3 Jul 2002 17:29:28 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 NAA13771 for ; Wed, 3 Jul 2002 13:29:25 -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 NAA09053 for ; Wed, 3 Jul 2002 13:29:27 -0400 (EDT) Message-ID: <3D233483.6040907@marconi.com> Date: Wed, 03 Jul 2002 13:29:39 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: What is the bad tspec? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Chetan Pinto wrote: > > Few examples > (1) m should not be 0 No. Zero means "don't care" in all IntServ objects - including TSPEC, FLOWSPEC and ADSPEC. Zero is legal for all fields. > (2) m must not be greater than M > (3) r must not be greater than p These make sense, as long as you keep in mind that M and p can be zero without violating these rules. >> If I set the token bucket rate very large, it will send back the patherr >> msg with 'Requested bandwidth unavailable', it will not send the bad >> tspec. Keep in mind that a huge value in the TSPEC may not cause a PathErr. Until the Resv message arrives from downstream, the actual size of the reservation could be any value between zero and the value of the TSPEC. If the FLOWSPEC in the Resv is too large, then a PathErr is mandatory. The TSPEC in a PathErr message is optional. More specifically, the entire sender descriptor (SENDER_TEMPLATE, TSPEC and ADSPEC) is optional in PathErr. IMO, the sender descriptor should be sent, because you can't uniquely identify a single LSP within a session without it. A PathErr with a SENDER_TEMPLATE, but no TSPEC doesn't seem to be legal, according to my reading of RFC 2205. (It violates the BNF description of a sender descriptor in section 3.1.3.) I wouldn't reject the message, however, since the TSPEC can be determined by looking at the stored value. (Part of being liberal in what you accept.) -- David From owner-mpls@UU.NET Wed Jul 3 14:22:40 2002 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 ESMTP id OAA25963 for ; Wed, 3 Jul 2002 14:22:40 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyf05493 for ; Wed, 3 Jul 2002 18:23:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvyf03098; Wed, 3 Jul 2002 18:22:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvyf14567 for mpls-outgoing; Wed, 3 Jul 2002 18:22:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvyf14557 for ; Wed, 3 Jul 2002 18:22:08 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 QQmvyf16176 for ; Wed, 3 Jul 2002 18:21:58 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyf02550 for ; Wed, 3 Jul 2002 18:21:58 GMT Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmvyf02544 for ; Wed, 3 Jul 2002 18:21:57 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3F04P5MV>; Wed, 3 Jul 2002 19:22:12 +0100 Message-ID: To: giles@packetexchange.net Cc: mpls@UU.NET Subject: RE: your mail Date: Wed, 3 Jul 2002 19:21:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Giles, Giles Heron wrote 03 July 2002 18:09 > so let's to go back to Yakov's email of 31st May: > > ------ > Giles, > > > 1. Efficient encapsulation of VPN traffic NH=> So the need for forced over-engineering because one can't determine anything with confidence on a per customer basis is efficient is it? That's a novel take on the definition of efficiency. > > 2. Ability to run VPN on current hardware NH=> Just 'who's HW'? This should surely not be a 'compelling reason'. > > > > There are probably other reasons as well... NH=> The appeal to 'etc' when the real reasons dry-up. > > One of the "other reasons" is straightforward protection > against packet > spoofing. NH=> Hardly compelling is it? If you really want strong protection why not use IPSec? From owner-mpls@UU.NET Wed Jul 3 14:23:40 2002 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 ESMTP id OAA26029 for ; Wed, 3 Jul 2002 14:23:39 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyf15211 for ; Wed, 3 Jul 2002 18:24:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvyf12107; Wed, 3 Jul 2002 18:23:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvyf14597 for mpls-outgoing; Wed, 3 Jul 2002 18:22:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvyf14592 for ; Wed, 3 Jul 2002 18:22: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 QQmvyf17405 for ; Wed, 3 Jul 2002 18:22:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyf09118 for ; Wed, 3 Jul 2002 18:22:27 GMT Received: from ariadne.dt.fee.unicamp.br by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dt.fee.unicamp.br [143.106.8.45]) id QQmvyf09094 for ; Wed, 3 Jul 2002 18:22:26 GMT Received: from calipso.dt.fee.unicamp.br (calipso.dt.fee.unicamp.br [143.106.12.37]) by ariadne.dt.fee.unicamp.br (8.9.3/8.9.3) with ESMTP id PAA02818; Wed, 3 Jul 2002 15:31:56 -0300 (EST) Date: Wed, 3 Jul 2002 15:22:03 -0300 (EST) From: Marcos Antonio De Almeida Cora To: mpls@UU.NET, mpls-ops@mplsrc.com, gmpls-ops@mplsrc.com Subject: CR-LDP and RSVP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, I'd like to know if someone have "papers, technical articles" about CR-LDP and RSVP for GMPLS. I have several drafts and some papers as following: GMPLS An Overview of Routing and Management Enhance GMPLS An Overview of Signaling Enhancements and Recovery Techniques Multiprotocol Lambda Switching: Combining MPLS Traffic Engineering Control with Optical CrossConnects But I'm looking for articles that comment on the messages and the characteristics of these protocols (CR-LDP and RSVP). Best regards, Marcos _________________________________________________________________ Marcos Antônio de Almeida Corá School of Electrical and Computer Engineering Departament of Telematics State University of Campinas/Brazil - UNICAMP Phone: +55 (19) 3788.3711 - Branch: 73723 Other e-mail: marcoscora@zipmail.com.br _________________________________________________________________ From owner-mpls@UU.NET Wed Jul 3 14:28:26 2002 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 ESMTP id OAA26425 for ; Wed, 3 Jul 2002 14:28:26 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyf16461 for ; Wed, 3 Jul 2002 18:29:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvyf13566; Wed, 3 Jul 2002 18:27:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvyf15122 for mpls-outgoing; Wed, 3 Jul 2002 18:27:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvyf15117 for ; Wed, 3 Jul 2002 18:27: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 QQmvyf24555 for ; Wed, 3 Jul 2002 18:25:05 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyf09283 for ; Wed, 3 Jul 2002 18:24:59 GMT Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmvyf09249 for ; Wed, 3 Jul 2002 18:24:59 GMT Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 19:25:12 +0100 Message-ID: To: giles@packetexchange.net Cc: mpls@UU.NET Subject: RE: your mail Date: Wed, 3 Jul 2002 19:21:49 +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 Giles......can you please just expand on what you mean here in the case of XoverMPLS PWE3 work? As a min one would see (in order lowest->highest, or outer->inner, the following 'words'): Outer Tunnel LSP header->Inner VC LSP header->Control-word (optional)-> various payload types. regards, Neil > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: 03 July 2002 18:01 > To: Gray, Eric > Cc: 'Kannan "S (Networking) - CTD, " "Chennai.'; Eric Osborne; 'MPLS > Mailing list' > Subject: RE: your mail > > > On Wed, 2002-07-03 at 13:55, Gray, Eric wrote: > [snip] > > Thirdly, it is definitely inappropriate to assume that the > > stuff after the last label is an IP header except in the > > case where the last label is an explicit IPv4 NULL label. > > It could be any of a lot of things otherwise and - given > > PHP and a number of defined MPLS applications - the last > > label is very unlikely to be an IPv4 explicit NULL label. > > Other than Juniper's CCC (which is dependent on RSVP-TE) I'm not aware > of any application putting non-IP traffic directly over an LSP (i.e. > without using a label stack). > > Therefore when there is only one label (other than when an egress LSR > using PHP receives a packet - in which case load balancing is somewhat > moot) I think we can assume that the payload is IP? > > Giles > > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > -----Original Message----- > > From: Kannan S (Networking) - CTD, Chennai. > [mailto:kannans@ctd.hcltech.com] > > > > Sent: Wednesday, July 03, 2002 3:25 AM > > To: Eric Osborne > > Cc: 'MPLS Mailing list' > > Subject: RE: your mail > > > > Eric, > > > > About the idea of using the bottom most label for doing ECMP - > > > > Wouldnt that restrict the ECMP hashing function, because my > hashing function > > is now totally dependent on how some router in the edge > chose to identify a > > flow? > > > > For example, suppose an ingress edge LSR marked the bottom > most label using > > say first 10 bits of the IP - SA, and last 10 bits of IP - > DA, then I cant > > have an hashing algorithm which uses last 10 bits of IP - > SA, and first 10 > > bits of IP - DA, right ? The efficiency of the algorithm > (the choice > > itself) is now very dependent on how the edge LSR identifies flows. > > > > My point is, if it is decided that an LSR is going to look > beyond whatever > > depth it is supposed to, the LSR's ECMP hashing function > might as well look > > at the IP header instead of looking at the bottom most label. > > > > Am I missing something here? > > > > Thanks, > > Kans. > > > > -----Original Message----- > > From: Eric Osborne [mailto:eosborne@cisco.com] > > Sent: Wednesday, July 03, 2002 4:01 AM > > To: Gray, Eric > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > Subject: Re: your mail > > > > > > On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > > > Eric, > > > > > > It is in the fact that we have to be sure - > > > just as you suggest. The cost of being sure, however, > > > is that you have to be prepared to deal with occasions > > > when the check fails. What do you do when the higher > > > layer is not UDP or TCP - throw these packets in to a > > > common bucket? What is the expected impact if this > > > traffic might occasionally be significant? > > > > Then you need a better load-balancing algorithm. Either IP > SA/DA and > > some randomness, or random sampling from the packet, or (heaven > > forbid) some sort of flow-based scheme. I'm even dubious about the > > efficacy of using TCP/UDP ports to hash, given that most traffic is > > either src or dst TCP port 80, which really only gives you > the port in > > the other direction to play with. But that's not really my problem, > > as the implementation I'm familiar with doesn't do anything with > > TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a > > device that does; I just don't deal with it/them). > > > > also, don't forget that this hypothetical algorithm takes > into acount > > IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you > > probably have very few flows/conversations/whatnot anyways, > and either > > need to move to something like per-packet (ick) or just > larger pipes. > > > > > > > > > > eric > > > > > > > > > > > Eric W. Gray > > > > > > > > > -----Original Message----- > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > Sent: Tuesday, July 02, 2002 4:24 PM > > > To: Gray, Eric > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > Subject: Re: your mail > > > > > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > > > Eric, > > > > > > > > To answer your final two questions, yes it probably > > > > is stealing. The fact that you can get away with a crime > > > > does not make it any less a crime. Who knows, some vendors > > > > may not check that the protocol over the top of IP is either > > > > UDP or TCP before using the port numbers. > > > > > > If a vendor checks the offset where the port numbers > should be without > > > checking for the correct protocol type, this is a cruddy > > > implementation and shouldn't exist. My question was > really along the > > > lines of "what if we use the values that we *know* are > UDP/TCP port > > > numbers"? From what you say above, it seems like that > might be OK, as > > > long as we only do this when we're sure? Or is there > some inherent > > > architectual layer violation thing that you're objecting to? > > > > > > > > > > > > eric > > > > > > > I think you can > > > > easily imagine what that might lead to if a set of packets > > > > carry a higher level protocol where the corresponding fields > > > > may vary from packet to packet in a single micro-flow. The > > > > real question is how common is this? > > > > > > > > Eric W. Gray > > > > Systems Architect > > > > Celox Networks, Inc. > > > > egray@celoxnetworks.com > > > > 508 305 7214 > > > > > > > > > > > > -----Original Message----- > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > Sent: Tuesday, July 02, 2002 1:32 PM > > > > To: Hummel Heinrich > > > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; > George Sheng; > > > > scullptor@yahoo.com; mpls@UU.NET > > > > Subject: Re: your mail > > > > > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > > > It gets weirder and weirder: The MPLS WG invents a > label stack, but > > > does > > > > not care at all that any of the > > > > > deeper nested labels may ever be signalled/carried by > means of a > > > > Label-TLV/object (no public comments to my > > > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > > > > > However it is ok, to "steal" the deepest nested label > and call it > > > > "VC-label" for indexing > > > > > some VRF at some remote PE. > > > > > > > > This is not theft; it's using the labels as they were > designed. How > > > > is using the bottommost label as a VC-labe/VPN label/whatever > > > > "stealing"? You seem to be attacking the very idea of > label stacking, > > > > which is a pretty useful concept. > > > > > > > > > Furthermore it is ok, to "steal" the very same label > for hashing. > > > > > > > > > > > > > What about IP router vendors that do load-balancing > based on L4/L5 > > > > information like protocol type and port numbers? Is > that stealing? > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > Independent from what is clean and what is > quick&dirty, I cannot > > detect > > > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > > > > > > > > > Heinrich Hummel > > > > > Siemens > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > > > An: Shahram Davari > > > > > Cc: 'Eric Osborne'; George Sheng; > scullptor@yahoo.com; mpls@UU.NET > > > > > Betreff: Re: your mail > > > > > > > > > > > > > > > Shahram> To do ECMP, you need to assign hashed > values to egress > > ports. > > > > This > > > > > Shahram> assignment is the hash state that I said you need. > > > > > > > > > > A hash is a function that maps some sequence of > octets into a > > > sequence > > > > of > > > > > integers. If you want to split traffic over six paths, while > > ensuring > > > > that > > > > > all packets with the same bottom label travel the > same path, you > > > need > > > > a > > > > > function that maps a 20 bit quantity into a number > from 1-6. There > > > is > > > > no > > > > > need to maintain state of any kind. > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Wed Jul 3 14:28:55 2002 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 ESMTP id OAA26471 for ; Wed, 3 Jul 2002 14:28:55 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyf14768 for ; Wed, 3 Jul 2002 18:29:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvyf11789; Wed, 3 Jul 2002 18:28:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvyf15170 for mpls-outgoing; Wed, 3 Jul 2002 18:28:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvyf15162 for ; Wed, 3 Jul 2002 18:27: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 QQmvyf20252 for ; Wed, 3 Jul 2002 18:26:55 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyf21035 for ; Wed, 3 Jul 2002 18:26:55 GMT Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQmvyf21007 for ; Wed, 3 Jul 2002 18:26:54 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id OAA15957 for ; Wed, 3 Jul 2002 14:21:37 -0400 (EDT) Subject: Re: What is the bad tspec? To: David Charlap Cc: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Wed, 3 Jul 2002 14:21:30 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 07/03/2002 02:21:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Please read inline comments. David Charlap cc: (bcc: Hong Liao/Telcordia) Subject: Re: What is the bad tspec? 07/03/02 01:29 PM Chetan Pinto wrote: > > Few examples > (1) m should not be 0 No. Zero means "don't care" in all IntServ objects - including TSPEC, FLOWSPEC and ADSPEC. Zero is legal for all fields. >>>>>>>>>[Julia] I agree. > (2) m must not be greater than M > (3) r must not be greater than p These make sense, as long as you keep in mind that M and p can be zero without violating these rules. >> If I set the token bucket rate very large, it will send back the patherr >> msg with 'Requested bandwidth unavailable', it will not send the bad >> tspec. Keep in mind that a huge value in the TSPEC may not cause a PathErr. Until the Resv message arrives from downstream, the actual size of the reservation could be any value between zero and the value of the TSPEC. If the FLOWSPEC in the Resv is too large, then a PathErr is mandatory. >>>>>>>>[Julia] If there is something wrong in the resv msg, it should send the ResvErr instead of Patherr, right? The TSPEC in a PathErr message is optional. More specifically, the entire sender descriptor (SENDER_TEMPLATE, TSPEC and ADSPEC) is optional in PathErr. IMO, the sender descriptor should be sent, because you can't uniquely identify a single LSP within a session without it. A PathErr with a SENDER_TEMPLATE, but no TSPEC doesn't seem to be legal, according to my reading of RFC 2205. (It violates the BNF description of a sender descriptor in section 3.1.3.) I wouldn't reject the message, however, since the TSPEC can be determined by looking at the stored value. (Part of being liberal in what you accept.) -- David From owner-mpls@UU.NET Wed Jul 3 14:31:54 2002 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 ESMTP id OAA26926 for ; Wed, 3 Jul 2002 14:31:54 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyg27931 for ; Wed, 3 Jul 2002 18:32:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvyg25226; Wed, 3 Jul 2002 18:31:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvyg15377 for mpls-outgoing; Wed, 3 Jul 2002 18:31:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvyg15334 for ; Wed, 3 Jul 2002 18:30: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 QQmvyg11005 for ; Wed, 3 Jul 2002 18:30:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyg20129 for ; Wed, 3 Jul 2002 18:30:51 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f127.law12.hotmail.com [64.4.19.127]) id QQmvyg20031 for ; Wed, 3 Jul 2002 18:30:49 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 3 Jul 2002 11:30:32 -0700 Received: from 212.87.114.121 by lw12fd.law12.hotmail.msn.com with HTTP; Wed, 03 Jul 2002 18:30:32 GMT X-Originating-IP: [212.87.114.121] Reply-To: rzappa@ieee.org From: "Rolando Zappacosta" To: mpls@UU.NET Subject: Re: QoS Survey Paper Date: Wed, 03 Jul 2002 20:30:32 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jul 2002 18:30:32.0387 (UTC) FILETIME=[B6FC2130:01C222BF] Sender: owner-mpls@UU.NET Precedence: bulk Uppss, I´m really sorry about this mail. It was supposed to be personal and offline but I forgot to delete the WG mail address. Some of you know about my situation, hence I think will understand. However, I apologise for this to all of you. Sincerely, Rolando. ----Original Message Follows---- From: "Rolando Zappacosta" Reply-To: rzappa@ieee.org To: Navid_Yazdani@raytheon.com CC: mpls@UU.NET Subject: Re: QoS Survey Paper Date: Wed, 03 Jul 2002 19:48:30 +0200 Navid, I'm currently unemployed and I came to Europe 'cause of a search that finally was cancelled just when I came here. Hence, I'm once again searching for a job. My primary areas of interest are research, development and testing, which was my last one. I know that nowadays it's not so easy as it was to find a job. Do you know about something in America or Europe? Well,... hope not to hind you with my own problem. Sincerely, Rolando. ----Original Message Follows---- From: Ping Pan To: Navid Yazdani CC: mpls@UU.NET Subject: Re: QoS Survey Paper Date: Tue, 02 Jul 2002 10:06:59 -0700 Not sure QoS is actually in the context of MPLS, but please take a look at a survey paper from Roch Guerin and Vinod Peris, "Quality-of-Service in Packet Networks: Basic Mechanisms and Directions" in http://www.seas.upenn.edu/~guerin - Ping Navid Yazdani wrote: >Can anyone recommend a survey paper, article, or book that examines the >advantages and disadvantages of different IP QoS schemes? > >thanks >Navid > > > > _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx << CV14enDA.doc >> _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Wed Jul 3 14:34:32 2002 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 ESMTP id OAA27141 for ; Wed, 3 Jul 2002 14:34:32 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyg26171 for ; Wed, 3 Jul 2002 18:35:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvyg22139; Wed, 3 Jul 2002 18:33:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvyg15634 for mpls-outgoing; Wed, 3 Jul 2002 18:33:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvyg15629 for ; Wed, 3 Jul 2002 18:33:07 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 QQmvyg14803 for ; Wed, 3 Jul 2002 18:32:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyg27011 for ; Wed, 3 Jul 2002 18:32: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 QQmvyg26908 for ; Wed, 3 Jul 2002 18:32: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 OAA17746 for ; Wed, 3 Jul 2002 14:32: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 OAA20202 for ; Wed, 3 Jul 2002 14:32:01 -0400 (EDT) Message-ID: <3D23432E.80202@marconi.com> Date: Wed, 03 Jul 2002 14:32:14 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: What is the bad tspec? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: >> >> Keep in mind that a huge value in the TSPEC may not cause a PathErr. >> Until the Resv message arrives from downstream, the actual size of the >> reservation could be any value between zero and the value of the TSPEC. >> >> If the FLOWSPEC in the Resv is too large, then a PathErr is mandatory. > > If there is something wrong in the resv msg, it should > send the ResvErr instead of Patherr, right? In straight RSVP, yes. But in section 4.7.3 of RFC 3209, that changed. Note the sixth paragraph of that section: If the requested bandwidth is not available a PathErr message is returned with an Error Code of 01, Admission Control Failure and an Error Value of 0x0002. ... In other words, for LSP-type sessions, PathErr should be generated if resources are unavailable. -- David From owner-mpls@UU.NET Wed Jul 3 16:19:03 2002 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 ESMTP id QAA04561 for ; Wed, 3 Jul 2002 16:19:02 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyn07877 for ; Wed, 3 Jul 2002 20:19:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmvyn05693; Wed, 3 Jul 2002 20:18:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmvyn07121 for mpls-outgoing; Wed, 3 Jul 2002 20:18:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmvyn07116 for ; Wed, 3 Jul 2002 20:18: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 QQmvyn14409 for ; Wed, 3 Jul 2002 20:18:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvyn15878 for ; Wed, 3 Jul 2002 20:18:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmvyn15870 for ; Wed, 3 Jul 2002 20:18:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA08722 for ; Wed, 3 Jul 2002 16:18:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA17886 for mpls@uu.net; Wed, 3 Jul 2002 16:18:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmvym15774 for ; Wed, 3 Jul 2002 20:00: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 QQmvym27816 for ; Wed, 3 Jul 2002 20:00:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmvym03682 for ; Wed, 3 Jul 2002 20:00:07 GMT Received: from edgsvr04.edgeflow.edgeflow.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: owa.meriton.com [209.202.126.190]) id QQmvym03671 for ; Wed, 3 Jul 2002 20:00:07 GMT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: draft-ietf-mpls-bundle-mib-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 3 Jul 2002 15:56:27 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C915C8D8@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: draft-ietf-mpls-bundle-mib-03.txt Thread-Index: AcIiy7fHoFwjt8PhRy+KYViiAZFUXA== From: "Martin Dubuc" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA04561 A new version of the bundle MIB is available at: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-03.txt This version addresses comments received from WG chair in preparation for submission to IESG. Martin Dubuc Meriton Networks From owner-mpls@UU.NET Thu Jul 4 04:47:08 2002 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 ESMTP id EAA11730 for ; Thu, 4 Jul 2002 04:47:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwal03800 for ; Thu, 4 Jul 2002 08:47:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwal29920; Thu, 4 Jul 2002 08:45:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwak10826 for mpls-outgoing; Thu, 4 Jul 2002 08:44:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwak10804 for ; Thu, 4 Jul 2002 08:44:44 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 QQmwak05008 for ; Thu, 4 Jul 2002 08:43:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwak22434 for ; Thu, 4 Jul 2002 08:43:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmwak22425 for ; Thu, 4 Jul 2002 08:43:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id EAA09795 for ; Thu, 4 Jul 2002 04:43:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA01582 for mpls@uu.net; Thu, 4 Jul 2002 04:43:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwak10588 for ; Thu, 4 Jul 2002 08:42:28 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 QQmwak01161 for ; Thu, 4 Jul 2002 08:41:28 GMT From: sven.van_den_bosch@alcatel.be Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwak27971 for ; Thu, 4 Jul 2002 08:41:28 GMT Received: from mail.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQmwak27961 for ; Thu, 4 Jul 2002 08:41:27 GMT Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g648aqd28872; Thu, 4 Jul 2002 10:36:52 +0200 Subject: Re: How many can administrative groups assigned? To: curtis@workhorse.fictitious.org, Venkata.Naidu@Marconi.com, jhyoung.kim@samsung.com, mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 4 Jul 2002 10:40:27 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/04/2002 10:40:39 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, The updated document describing the extension for resource class use with FA has appeared on ID-announce: draft-vandenbosch-mpls-fa-considerations-00.txt We think the draft addresses the issue described in the attached message thread. Best regards, Sven. ---------------------- Forwarded by Sven VAN DEN BOSCH/BE/ALCATEL on 04/07/2002 10:35 --------------------------- Sven VAN DEN BOSCH 13/05/2002 08:36 To: Curtis Villamizar cc: "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL Subject: Re: How many can administrative groups assigned? (Document link: Sven VAN DEN BOSCH) Curtis, I agree with you that the current interpretation is clear. It brings, however, some difficulties regarding Forwarding Adjacency (FA) LSPs. Suppose you have an LSP that includes gold as a resource class. It goes through links A-B (gold), B-C (gold, north) and C-D (gold, south). Imho, the current FA specification would make this a non-coloured FA-link, or alternatively, it could be coloured gold. In both cases, depending on the interpretation of uncoloured links, it could be used for an LSP that specifies e.g. exclude north, which is not what you want. This problem is due to the bitmask operation. We feel that at least one more TLV would be needed (speciying the OR operation on the bit-mask for the FA-LSP). We will document this in the next version of draft-vandenbosch-mpls-fa-considerations-00.txt. Sven. Curtis Villamizar on 08/05/2002 20:22:11 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: "Naidu, Venkata" , "'???'" , mpls@UU.NET, CCAMP , te-wg@ops.ietf.org Subject Re: How many can administrative groups : assigned? [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In message , sven.van_d en_bosch@alcatel.be writes: > Naidu, Kim, > > I think it depends a little bit on the interpretation. In principle the > resource classes can be interpreted either as a bit mask (in which case 32 > 'base' classes can be defined) or as an integer value (in which case 2^32 > values can be used). Even with the bit mask interpretation, derived > resource classes can be built by combining multiple non-mutually exclusive > 'base' classes (you could have 32 generic classes called 1, 2, 3 and so on > and then build your resource classes on top of those). The problem lies of > course in the processing of the resource class information. If they are not > used in a simple bitmask, an AND operation is not sufficient to determine > the resource class of a link. Also, if a link would have multiple derived > classes, different TLVs would be needed. It would make sense to expand a > little bit on these issues in the appropriate documents. In my opinion, > this is a general issue with the TE extensions, so it should be explained > there. > > Sven. The definitions are currently very clear. What you have described differs from the current definitions and therefore would not be a clarification to the use of admin class but a change in semantics. I do not know of anyone using more than a handful of admin class bits and many who do not use them at all. Lets not take any MPLS capability and make it any more complicated than it needs to be or introduce arbitrary change for no good reason. Curtis From owner-mpls@UU.NET Thu Jul 4 04:51:41 2002 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 ESMTP id EAA11798 for ; Thu, 4 Jul 2002 04:51:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwal12035 for ; Thu, 4 Jul 2002 08:52:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwal04933; Thu, 4 Jul 2002 08:48:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwal11451 for mpls-outgoing; Thu, 4 Jul 2002 08:47:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwal11439 for ; Thu, 4 Jul 2002 08:47: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 QQmwal07780 for ; Thu, 4 Jul 2002 08:46:10 GMT From: stefaan.de_cnodder@alcatel.be Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwal24849 for ; Thu, 4 Jul 2002 08:46:10 GMT Received: from mail.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQmwal24839 for ; Thu, 4 Jul 2002 08:46:09 GMT Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g648fXg31082; Thu, 4 Jul 2002 10:41:33 +0200 Received: from alcatel.be ([138.203.197.32]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002070410450681:2725 ; Thu, 4 Jul 2002 10:45:06 +0200 Message-ID: <3D240B15.2FDD4D1E@alcatel.be> Date: Thu, 04 Jul 2002 10:45:09 +0200 Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ling Li Cc: mpls@UU.NET, Riza CETIN Subject: Re: a doubt on the hop-limit constraint in draft-ietf-mpls-fastreroute-mib-00.txt References: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/04/2002 10:45:06, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/04/2002 10:45:09, Serialize complete at 07/04/2002 10:45:09 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ling, The object mplsFrrConstHopLimit is meant to be the same as the hop-limit defined for the FAST-REROUTE object. Description in the MIB will be updated in the next version. thanks for the comment, Stefaan Ling Li wrote: > > The hop-limit constraint is defined as follows in > draft-ietf-mpls-fastreroute-mib-00.txt: > > mplsFrrConstHopLimit OBJECT-TYPE > SYNTAX INTEGER (1..255) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The maximum number of hops that the detour LSP may > traverse." > DEFVAL { 32 } > ::= { mplsFrrConstEntry 10 } > > However, this definition is different from what it is in > draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt: > Hop-limit > > The maximum number of extra hops the backup path is allowed > to take, from current node (a PLR) to a MP, with PLR and MP > excluded in counting. For example, hop-limit of 0 means only > direct links between PLR and MP can be considered. > > Can any of the authors clarify this inconsistency? I have raised a closely > related question > at http://cell.onecall.net/mhonarc/mpls/2002-Jun/msg00143.html. > > Thanks, > > Ling Li > > Axiowave Networks, Inc. > 200 Nickerson Road > Marlborough, MA 01752 > Email: lli@axiowave.com > ======================== From owner-mpls@UU.NET Thu Jul 4 05:50:58 2002 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 ESMTP id FAA12545 for ; Thu, 4 Jul 2002 05:50:58 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwap06889 for ; Thu, 4 Jul 2002 09:51:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwap04520; Thu, 4 Jul 2002 09:50:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwap08208 for mpls-outgoing; Thu, 4 Jul 2002 09:50:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwap08201 for ; Thu, 4 Jul 2002 09:50:20 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 QQmwap17399 for ; Thu, 4 Jul 2002 09:50:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwap04240 for ; Thu, 4 Jul 2002 09:50:03 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmwap04208 for ; Thu, 4 Jul 2002 09:50:02 GMT Received: from utfors.se ([195.58.105.100]) by blooper.utfors.se (Utfors AB) with ESMTP id g649nVqo000633; Thu, 4 Jul 2002 11:49:31 +0200 (MEST) Message-ID: <3D241A2A.8020409@utfors.se> Date: Thu, 04 Jul 2002 11:49:30 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: MPLS wg CC: George Swallow , Martin Dubuc Subject: wg last call - draft-ietf-mpls-bundle-mib-03.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit This message initiates a one week WG last call on: Link Bundling Management Information Base Please send your comments to the mailing list. The draft has been thorugh an earlier wg last and been updated according to comments in that last call, however the changes has been of such a nature that we want to make this last call on the entire draft. Note: This draft uses a MIB boilerplate that will be changed, this will however be taken care of in the the editorial process. This wg last call ends July 12, 2002 at 2400 GMT. /Loa and George -- 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 Jul 4 07:19:51 2002 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 ESMTP id HAA14356 for ; Thu, 4 Jul 2002 07:19:50 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwav04723 for ; Thu, 4 Jul 2002 11:20:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwav02463; Thu, 4 Jul 2002 11:19:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwav29079 for mpls-outgoing; Thu, 4 Jul 2002 11:19:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwav29072 for ; Thu, 4 Jul 2002 11:19: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 QQmwav22353 for ; Thu, 4 Jul 2002 11:19:01 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwav01140 for ; Thu, 4 Jul 2002 11:19:00 GMT Received: from smtp.cwnt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.cwnt.com [192.116.246.129]) id QQmwav01119 for ; Thu, 4 Jul 2002 11:18:59 GMT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: your mail X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 4 Jul 2002 14:18:57 +0300 Message-ID: Thread-Topic: your mail Thread-Index: AcIh+fGRYAYHrGG8QGiJMpN3R9FGcwA5/n0w From: "Amir Hermelin" To: "Naidu, Venkata" , "Vach Kompella" , "Gibson, Mark" , , "Gray, Eric" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA14356 Naidu, out-of-order packets ARE a worry to vendor implementations (regardless of IP or MPLS), even though higher layers take care of that. What you're suggesting has a high potential of misordering EVERY flow encapsulated in MPLS - this would instantly degrade end-to-end performance by tens of percents. Also, the fact that a certain vendor got such bad publicity (IMO unjustly, even though I'm from a competing company) when they misordered packet flows on OC192 links should make you reconsider. -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com] > Sent: Tuesday, July 02, 2002 9:49 PM > To: 'Vach Kompella'; Gibson, Mark; mpls@UU.NET; Gray, Eric > Subject: RE: your mail > > > Vach, > > -> For ECMP, you have to look at least one label lower (or more > -> precisely, one layer higher). > > Why? It is very difficult to look at the payload of MPLS > packets the way the encapsulations are defined. > > So, a router trying to do load balancing have to know > the X in XoverMPLS (all the PPP exts, LLC encapsulations RFCs etc). > Very unrealistic... > > Why can't we do something simple like this: > > If I know what the LSP semantics are, then I enable > load balancing on that LSP - with or with out hashing. > With out hashing, I do simple round robin 1 to N > scheduler (no state, nothing). Even weighted round > robin also you can do. > > The semantics for that LSP can be: > - don't worry about out-of-order packets (higher layers > will take care of it) > - don't worry about X in XoverMPLS - don't even look > at it. > - don't do ECMP if EXP bits are set > etc etc... > > Why are you thinking that load balancing or ECMP is > a router option. You can have it as per LSP option as well. > Just like ECMP for per destination address/flow. > > When we know what we are doing then the problems will be minimal. > > Do you agree? > > -- > Venkata. > From owner-mpls@UU.NET Thu Jul 4 07:43:40 2002 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 ESMTP id HAA14855 for ; Thu, 4 Jul 2002 07:43:40 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwaw07747 for ; Thu, 4 Jul 2002 11:44:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwaw05163; Thu, 4 Jul 2002 11:43:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwaw00635 for mpls-outgoing; Thu, 4 Jul 2002 11:42:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwaw00623 for ; Thu, 4 Jul 2002 11:42: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 QQmwaw27706 for ; Thu, 4 Jul 2002 11:42:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwaw18101 for ; Thu, 4 Jul 2002 11:42:06 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmwaw18090 for ; Thu, 4 Jul 2002 11:42:05 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17Q4zs-0000OB-00; Thu, 04 Jul 2002 12:42:04 +0100 Subject: RE: your mail From: Giles Heron To: neil.2.harrison@bt.com Cc: mpls@UU.NET In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 04 Jul 2002 12:42:03 +0000 Message-Id: <1025786523.2946.79.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2002-07-03 at 18:21, neil.2.harrison@bt.com wrote: > Hi Giles, > > Giles Heron wrote 03 July 2002 18:09 > > so let's to go back to Yakov's email of 31st May: > > > > ------ > > Giles, > > > > > 1. Efficient encapsulation of VPN traffic > NH=> So the need for forced over-engineering because one can't determine > anything with confidence on a per customer basis is efficient is it? That's > a novel take on the definition of efficiency. if "over-engineering" (by which I presume you mean "over-provisioning") means fewer staff to run the network then yes - it is more efficient. As someone once said "bandwidth is cheaper than smart people" (or words to that effect). Incidentally if anyone here knows the original quote then do send it to me offlist... In any case if you run RSVP-TE end to end in a large network you will hit the LSP scaling wall sooner rather than later (particularly if you have different LSP meshes for different classes of customers, as you seem to suggest regularly). LDP end-to-end with RSVP-TE in the core lets you have the best of both worlds - TE in the core to optimise your use of resources (and keep your job secure) and LDP to the edge so you can scale your network ;-) (I'm sure Heinrich can jump in here and remind us about hierarchical LSPs). > > > 2. Ability to run VPN on current hardware > NH=> Just 'who's HW'? This should surely not be a 'compelling reason'. it is compelling to a lot of carriers right now! > > > There are probably other reasons as well... > NH=> The appeal to 'etc' when the real reasons dry-up. that was just me being lazy ;-) > > One of the "other reasons" is straightforward protection > > against packet > > spoofing. > NH=> Hardly compelling is it? If you really want strong protection why not > use IPSec? and why would a carrier want to run IPSec for anti-spoofing? Sledgehammers and walnuts come to mind ;-) Giles > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Thu Jul 4 07:47:38 2002 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 ESMTP id HAA14915 for ; Thu, 4 Jul 2002 07:47:38 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwax24019 for ; Thu, 4 Jul 2002 11:48:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwax20891; Thu, 4 Jul 2002 11:46:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwax01272 for mpls-outgoing; Thu, 4 Jul 2002 11:46:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwax01201 for ; Thu, 4 Jul 2002 11:46: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 QQmwaw20870 for ; Thu, 4 Jul 2002 11:44:43 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwaw16146 for ; Thu, 4 Jul 2002 11:44:43 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmwaw16142 for ; Thu, 4 Jul 2002 11:44:42 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17Q52K-0000OU-00; Thu, 04 Jul 2002 12:44:36 +0100 Subject: RE: your mail From: Giles Heron To: neil.2.harrison@bt.com Cc: mpls@UU.NET In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 04 Jul 2002 12:44:35 +0000 Message-Id: <1025786675.2946.85.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA14915 agreed - this is what you'd expect to see. IMO the only traffic that should ride directly over a tunnel LSP is IP (v4 or v6). however there is one implementation out there (that I know of - there may be others) where layer 2 traffic is carried directly over a tunnel LSP. Giles On Wed, 2002-07-03 at 18:21, neil.2.harrison@bt.com wrote: > Giles......can you please just expand on what you mean here in the case of > XoverMPLS PWE3 work? As a min one would see (in order lowest->highest, or > outer->inner, the following 'words'): > Outer Tunnel LSP header->Inner VC LSP header->Control-word (optional)-> > various payload types. > > regards, Neil > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: 03 July 2002 18:01 > > To: Gray, Eric > > Cc: 'Kannan "S (Networking) - CTD, " "Chennai.'; Eric Osborne; 'MPLS > > Mailing list' > > Subject: RE: your mail > > > > > > On Wed, 2002-07-03 at 13:55, Gray, Eric wrote: > > [snip] > > > Thirdly, it is definitely inappropriate to assume that the > > > stuff after the last label is an IP header except in the > > > case where the last label is an explicit IPv4 NULL label. > > > It could be any of a lot of things otherwise and - given > > > PHP and a number of defined MPLS applications - the last > > > label is very unlikely to be an IPv4 explicit NULL label. > > > > Other than Juniper's CCC (which is dependent on RSVP-TE) I'm not aware > > of any application putting non-IP traffic directly over an LSP (i.e. > > without using a label stack). > > > > Therefore when there is only one label (other than when an egress LSR > > using PHP receives a packet - in which case load balancing is somewhat > > moot) I think we can assume that the payload is IP? > > > > Giles > > > > > > > > Eric W. Gray > > > Systems Architect > > > Celox Networks, Inc. > > > egray@celoxnetworks.com > > > 508 305 7214 > > > > > > > > > -----Original Message----- > > > From: Kannan S (Networking) - CTD, Chennai. > > [mailto:kannans@ctd.hcltech.com] > > > > > > Sent: Wednesday, July 03, 2002 3:25 AM > > > To: Eric Osborne > > > Cc: 'MPLS Mailing list' > > > Subject: RE: your mail > > > > > > Eric, > > > > > > About the idea of using the bottom most label for doing ECMP - > > > > > > Wouldnt that restrict the ECMP hashing function, because my > > hashing function > > > is now totally dependent on how some router in the edge > > chose to identify a > > > flow? > > > > > > For example, suppose an ingress edge LSR marked the bottom > > most label using > > > say first 10 bits of the IP - SA, and last 10 bits of IP - > > DA, then I cant > > > have an hashing algorithm which uses last 10 bits of IP - > > SA, and first 10 > > > bits of IP - DA, right ? The efficiency of the algorithm > > (the choice > > > itself) is now very dependent on how the edge LSR identifies flows. > > > > > > My point is, if it is decided that an LSR is going to look > > beyond whatever > > > depth it is supposed to, the LSR's ECMP hashing function > > might as well look > > > at the IP header instead of looking at the bottom most label. > > > > > > Am I missing something here? > > > > > > Thanks, > > > Kans. > > > > > > -----Original Message----- > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > Sent: Wednesday, July 03, 2002 4:01 AM > > > To: Gray, Eric > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > Subject: Re: your mail > > > > > > > > > On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > > > > Eric, > > > > > > > > It is in the fact that we have to be sure - > > > > just as you suggest. The cost of being sure, however, > > > > is that you have to be prepared to deal with occasions > > > > when the check fails. What do you do when the higher > > > > layer is not UDP or TCP - throw these packets in to a > > > > common bucket? What is the expected impact if this > > > > traffic might occasionally be significant? > > > > > > Then you need a better load-balancing algorithm. Either IP > > SA/DA and > > > some randomness, or random sampling from the packet, or (heaven > > > forbid) some sort of flow-based scheme. I'm even dubious about the > > > efficacy of using TCP/UDP ports to hash, given that most traffic is > > > either src or dst TCP port 80, which really only gives you > > the port in > > > the other direction to play with. But that's not really my problem, > > > as the implementation I'm familiar with doesn't do anything with > > > TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a > > > device that does; I just don't deal with it/them). > > > > > > also, don't forget that this hypothetical algorithm takes > > into acount > > > IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you > > > probably have very few flows/conversations/whatnot anyways, > > and either > > > need to move to something like per-packet (ick) or just > > larger pipes. > > > > > > > > > > > > > > > eric > > > > > > > > > > > > > > > Eric W. Gray > > > > > > > > > > > > -----Original Message----- > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > Sent: Tuesday, July 02, 2002 4:24 PM > > > > To: Gray, Eric > > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > > Subject: Re: your mail > > > > > > > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > > > > Eric, > > > > > > > > > > To answer your final two questions, yes it probably > > > > > is stealing. The fact that you can get away with a crime > > > > > does not make it any less a crime. Who knows, some vendors > > > > > may not check that the protocol over the top of IP is either > > > > > UDP or TCP before using the port numbers. > > > > > > > > If a vendor checks the offset where the port numbers > > should be without > > > > checking for the correct protocol type, this is a cruddy > > > > implementation and shouldn't exist. My question was > > really along the > > > > lines of "what if we use the values that we *know* are > > UDP/TCP port > > > > numbers"? From what you say above, it seems like that > > might be OK, as > > > > long as we only do this when we're sure? Or is there > > some inherent > > > > architectual layer violation thing that you're objecting to? > > > > > > > > > > > > > > > > eric > > > > > > > > > I think you can > > > > > easily imagine what that might lead to if a set of packets > > > > > carry a higher level protocol where the corresponding fields > > > > > may vary from packet to packet in a single micro-flow. The > > > > > real question is how common is this? > > > > > > > > > > Eric W. Gray > > > > > Systems Architect > > > > > Celox Networks, Inc. > > > > > egray@celoxnetworks.com > > > > > 508 305 7214 > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > > Sent: Tuesday, July 02, 2002 1:32 PM > > > > > To: Hummel Heinrich > > > > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; > > George Sheng; > > > > > scullptor@yahoo.com; mpls@UU.NET > > > > > Subject: Re: your mail > > > > > > > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > > > > It gets weirder and weirder: The MPLS WG invents a > > label stack, but > > > > does > > > > > not care at all that any of the > > > > > > deeper nested labels may ever be signalled/carried by > > means of a > > > > > Label-TLV/object (no public comments to my > > > > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > > > > > > > However it is ok, to "steal" the deepest nested label > > and call it > > > > > "VC-label" for indexing > > > > > > some VRF at some remote PE. > > > > > > > > > > This is not theft; it's using the labels as they were > > designed. How > > > > > is using the bottommost label as a VC-labe/VPN label/whatever > > > > > "stealing"? You seem to be attacking the very idea of > > label stacking, > > > > > which is a pretty useful concept. > > > > > > > > > > > Furthermore it is ok, to "steal" the very same label > > for hashing. > > > > > > > > > > > > > > > > What about IP router vendors that do load-balancing > > based on L4/L5 > > > > > information like protocol type and port numbers? Is > > that stealing? > > > > > > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > > > Independent from what is clean and what is > > quick&dirty, I cannot > > > detect > > > > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > > > > > > > > > > > > > Heinrich Hummel > > > > > > Siemens > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > > > > An: Shahram Davari > > > > > > Cc: 'Eric Osborne'; George Sheng; > > scullptor@yahoo.com; mpls@UU.NET > > > > > > Betreff: Re: your mail > > > > > > > > > > > > > > > > > > Shahram> To do ECMP, you need to assign hashed > > values to egress > > > ports. > > > > > This > > > > > > Shahram> assignment is the hash state that I said you need. > > > > > > > > > > > > A hash is a function that maps some sequence of > > octets into a > > > > sequence > > > > > of > > > > > > integers. If you want to split traffic over six paths, while > > > ensuring > > > > > that > > > > > > all packets with the same bottom label travel the > > same path, you > > > > need > > > > > a > > > > > > function that maps a 20 bit quantity into a number > > from 1-6. There > > > > is > > > > > no > > > > > > need to maintain state of any kind. > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Thu Jul 4 07:48:46 2002 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 ESMTP id HAA14991 for ; Thu, 4 Jul 2002 07:48:45 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwax17934 for ; Thu, 4 Jul 2002 11:49:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwax13147; Thu, 4 Jul 2002 11:46:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwax01261 for mpls-outgoing; Thu, 4 Jul 2002 11:46:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwax01197 for ; Thu, 4 Jul 2002 11:46:10 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 QQmwax15404 for ; Thu, 4 Jul 2002 11:46:01 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwax11068 for ; Thu, 4 Jul 2002 11:45:54 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmwax11032 for ; Thu, 4 Jul 2002 11:45:54 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17Q53D-0000Oq-00; Thu, 04 Jul 2002 12:45:31 +0100 Subject: RE: your mail From: Giles Heron To: "Gray, Eric" Cc: "'MPLS Mailing list'" In-Reply-To: <1117F7D44159934FB116E36F4ABF221B02267112@celox-ma1-ems1.celoxnetworks.com> References: <1117F7D44159934FB116E36F4ABF221B02267112@celox-ma1-ems1.celoxnetworks.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 04 Jul 2002 12:45:30 +0000 Message-Id: <1025786730.2948.88.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA14991 Hi Eric, I'd hope that there is no intention to specify anything other than IPv4 or v6 running directly over MPLS. MPLS is, after all, not a layer in its own right (but let's not have that debate again!) Giles On Wed, 2002-07-03 at 17:24, Gray, Eric wrote: > Giles, > > I should go into this a bit further. > > One of the reasons to worry about 'layer violations' > (oooh, there's that awful word again :-O) is if there has > been a conscious decision to punt specification of some > uses of a 'layer' because of its assumed inviolability. In > MPLS, there has been at least one such punt - the header > compression proposal that George Swallow brought forward some > time ago. The working group decided that there was no reason > to specify this scheme, since it would take place over MPLS > between presumably cooperating systems. > > This is just one example. Another might be IPv6/MPLS. > Who knows how many other things people are looking at (or have > looked at) as X/MPLS applications? With MPLS, the working group > has repeatedly had to consider whether or not to just change > the name of the protocol to IP(v4)LS. So far as I know, this > has not yet happened. :-) > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Wednesday, July 03, 2002 1:57 PM > To: Gray, Eric > Cc: 'Kannan "S (Networking) ""- CTD, ""Chennai.'; Eric Osborne; 'MPLS > Mailing list' > Subject: RE: your mail > > oops, yeah good point. > > In this case clearly you *can* still look for an IPv4 header - it is > just rather uglier. The trick is to look for the value 0100 in the > first 4 bits. The risk is, of course, that there may be a client > protocol which also sends this :( > > Giles > > On Wed, 2002-07-03 at 16:51, Gray, Eric wrote: > > Giles, > > > > I was responding to this statement: > > > > > My point is, if it is decided that an LSR is going to look beyond > > > whatever depth it is supposed to, the LSR's ECMP hashing function > > > might as well look at the IP header instead of looking at the bottom > > > most label. > > > > How does my response to this relate to your comment? :-) > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: Wednesday, July 03, 2002 1:01 PM > > To: Gray, Eric > > Cc: 'Kannan "S (Networking) - CTD, ""Chennai.'; Eric Osborne; 'MPLS > Mailing > > list' > > Subject: RE: your mail > > > > On Wed, 2002-07-03 at 13:55, Gray, Eric wrote: > > [snip] > > > Thirdly, it is definitely inappropriate to assume that the > > > stuff after the last label is an IP header except in the > > > case where the last label is an explicit IPv4 NULL label. > > > It could be any of a lot of things otherwise and - given > > > PHP and a number of defined MPLS applications - the last > > > label is very unlikely to be an IPv4 explicit NULL label. > > > > Other than Juniper's CCC (which is dependent on RSVP-TE) I'm not aware > > of any application putting non-IP traffic directly over an LSP (i.e. > > without using a label stack). > > > > Therefore when there is only one label (other than when an egress LSR > > using PHP receives a packet - in which case load balancing is somewhat > > moot) I think we can assume that the payload is IP? > > > > Giles > > > > > > > > Eric W. Gray > > > Systems Architect > > > Celox Networks, Inc. > > > egray@celoxnetworks.com > > > 508 305 7214 > > > > > > > > > -----Original Message----- > > > From: Kannan S (Networking) - CTD, Chennai. > > [mailto:kannans@ctd.hcltech.com] > > > > > > Sent: Wednesday, July 03, 2002 3:25 AM > > > To: Eric Osborne > > > Cc: 'MPLS Mailing list' > > > Subject: RE: your mail > > > > > > Eric, > > > > > > About the idea of using the bottom most label for doing ECMP - > > > > > > Wouldnt that restrict the ECMP hashing function, because my hashing > > function > > > is now totally dependent on how some router in the edge chose to > identify > > a > > > flow? > > > > > > For example, suppose an ingress edge LSR marked the bottom most label > > using > > > say first 10 bits of the IP - SA, and last 10 bits of IP - DA, then I > cant > > > have an hashing algorithm which uses last 10 bits of IP - SA, and first > 10 > > > bits of IP - DA, right ? The efficiency of the algorithm (the choice > > > itself) is now very dependent on how the edge LSR identifies flows. > > > > > > My point is, if it is decided that an LSR is going to look beyond > whatever > > > depth it is supposed to, the LSR's ECMP hashing function might as well > > look > > > at the IP header instead of looking at the bottom most label. > > > > > > Am I missing something here? > > > > > > Thanks, > > > Kans. > > > > > > -----Original Message----- > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > Sent: Wednesday, July 03, 2002 4:01 AM > > > To: Gray, Eric > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > Subject: Re: your mail > > > > > > > > > On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > > > > Eric, > > > > > > > > It is in the fact that we have to be sure - > > > > just as you suggest. The cost of being sure, however, > > > > is that you have to be prepared to deal with occasions > > > > when the check fails. What do you do when the higher > > > > layer is not UDP or TCP - throw these packets in to a > > > > common bucket? What is the expected impact if this > > > > traffic might occasionally be significant? > > > > > > Then you need a better load-balancing algorithm. Either IP SA/DA and > > > some randomness, or random sampling from the packet, or (heaven > > > forbid) some sort of flow-based scheme. I'm even dubious about the > > > efficacy of using TCP/UDP ports to hash, given that most traffic is > > > either src or dst TCP port 80, which really only gives you the port in > > > the other direction to play with. But that's not really my problem, > > > as the implementation I'm familiar with doesn't do anything with > > > TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a > > > device that does; I just don't deal with it/them). > > > > > > also, don't forget that this hypothetical algorithm takes into acount > > > IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you > > > probably have very few flows/conversations/whatnot anyways, and either > > > need to move to something like per-packet (ick) or just larger pipes. > > > > > > > > > > > > > > > eric > > > > > > > > > > > > > > > Eric W. Gray > > > > > > > > > > > > -----Original Message----- > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > Sent: Tuesday, July 02, 2002 4:24 PM > > > > To: Gray, Eric > > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > > Subject: Re: your mail > > > > > > > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > > > > Eric, > > > > > > > > > > To answer your final two questions, yes it probably > > > > > is stealing. The fact that you can get away with a crime > > > > > does not make it any less a crime. Who knows, some vendors > > > > > may not check that the protocol over the top of IP is either > > > > > UDP or TCP before using the port numbers. > > > > > > > > If a vendor checks the offset where the port numbers should be without > > > > checking for the correct protocol type, this is a cruddy > > > > implementation and shouldn't exist. My question was really along the > > > > lines of "what if we use the values that we *know* are UDP/TCP port > > > > numbers"? From what you say above, it seems like that might be OK, as > > > > long as we only do this when we're sure? Or is there some inherent > > > > architectual layer violation thing that you're objecting to? > > > > > > > > > > > > > > > > eric > > > > > > > > > I think you can > > > > > easily imagine what that might lead to if a set of packets > > > > > carry a higher level protocol where the corresponding fields > > > > > may vary from packet to packet in a single micro-flow. The > > > > > real question is how common is this? > > > > > > > > > > Eric W. Gray > > > > > Systems Architect > > > > > Celox Networks, Inc. > > > > > egray@celoxnetworks.com > > > > > 508 305 7214 > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > > Sent: Tuesday, July 02, 2002 1:32 PM > > > > > To: Hummel Heinrich > > > > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; George > Sheng; > > > > > scullptor@yahoo.com; mpls@UU.NET > > > > > Subject: Re: your mail > > > > > > > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > > > > It gets weirder and weirder: The MPLS WG invents a label stack, > > but > > > > does > > > > > not care at all that any of the > > > > > > deeper nested labels may ever be signalled/carried by means of a > > > > > Label-TLV/object (no public comments to my > > > > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > > > > > > > However it is ok, to "steal" the deepest nested label and call it > > > > > "VC-label" for indexing > > > > > > some VRF at some remote PE. > > > > > > > > > > This is not theft; it's using the labels as they were designed. How > > > > > is using the bottommost label as a VC-labe/VPN label/whatever > > > > > "stealing"? You seem to be attacking the very idea of label > stacking, > > > > > which is a pretty useful concept. > > > > > > > > > > > Furthermore it is ok, to "steal" the very same label for hashing. > > > > > > > > > > > > > > > > What about IP router vendors that do load-balancing based on L4/L5 > > > > > information like protocol type and port numbers? Is that stealing? > > > > > > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > > > Independent from what is clean and what is quick&dirty, I cannot > > > detect > > > > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > > > > > > > > > > > > > Heinrich Hummel > > > > > > Siemens > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > > > > An: Shahram Davari > > > > > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET > > > > > > Betreff: Re: your mail > > > > > > > > > > > > > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress > > > ports. > > > > > This > > > > > > Shahram> assignment is the hash state that I said you need. > > > > > > > > > > > > A hash is a function that maps some sequence of octets into a > > > > sequence > > > > > of > > > > > > integers. If you want to split traffic over six paths, while > > > ensuring > > > > > that > > > > > > all packets with the same bottom label travel the same path, > you > > > > need > > > > > a > > > > > > function that maps a 20 bit quantity into a number from 1-6. > > There > > > > is > > > > > no > > > > > > need to maintain state of any kind. > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Thu Jul 4 11:19:31 2002 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 ESMTP id LAA19451 for ; Thu, 4 Jul 2002 11:19:31 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbl00067 for ; Thu, 4 Jul 2002 15:20:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwbl27349; Thu, 4 Jul 2002 15:18:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwbl15378 for mpls-outgoing; Thu, 4 Jul 2002 15:18:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwbl15373 for ; Thu, 4 Jul 2002 15:18: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 QQmwbl07917 for ; Thu, 4 Jul 2002 15:17:17 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbl09370 for ; Thu, 4 Jul 2002 15:17:17 GMT Received: from tama5.ecl.ntt.co.jp by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQmwbl09364 for ; Thu, 4 Jul 2002 15:17:16 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id AAA10914; Fri, 5 Jul 2002 00:17:00 +0900 (JST) (envelope-from yasukawa.seisho@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g64FH0xV024960; Fri, 5 Jul 2002 00:17:00 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g64FGxn5005966; Fri, 5 Jul 2002 00:16:59 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id AAA17732; Fri, 5 Jul 2002 00:16:59 +0900 (JST) Received: from neeiwin-yasukawa by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id AAA08574; Fri, 5 Jul 2002 00:16:58 +0900 (JST) Message-Id: <4.2.0.58.J.20020704233928.021f3530@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 05 Jul 2002 00:35:16 +0900 To: David Charlap , IETF MPLS List From: Seisho Yasukawa Subject: Re: I-D ACTION:draft-yasukawa-mpls-rsvp-multicast-00.txt In-Reply-To: <3D20BFC7.8000007@marconi.com> References: <200206271038.GAA08972@ietf.org> <4.3.2-J.20020701130120.00bc8c58@imc.m.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dear David >>I agree that classical RSVP was designed around multicast and existing >>RSVP-TE can >>cope with multicast in essesntial. But I still think existing RSVP-TE is >>not suitable and >>some modifications are necessary to support multicast because its lack of >>TE function. > >You mean the lack of explicit routes. TE is a very broad and vague term. Yes, I mean that we must add and define the explicit routes function to existing RSVP-TE to enable multicast traffic engineering. We think TE becomes more important when considering multicast application. When considering multicast TE, we want to engineer (control) multicast tree topology. But, as you know, most of conventional IP multicast routing protocol only establish shortest path multicast tree because these protocol utlized RPF mechanism when constructing multicast route. Therefore, we need TERO (Tree Explicit Route Object) that can control multicast LSP topology. We also want the scheme to rerouting the multicast traffic when some error occurs in the network. Some multicast routing mechanism may find these error and find another available route finally. But we think we need more reliable and faster rerouting mechanism in multicast environment. Most of multicast tree has tree topology and the error near the root node cause tragic effect on multicast traffic transmission. To enable first and reliable recovery, we think it is better to devide path setup and multicast routing mechanism seperatory. Therefore, we design multicast MPLS protocol that only use unicast routing information and propose TERO to control the tree topology and Graft/Prune mechanism to setup/release partial multicast tree. >If you think you need to define a multicast ERO, you can do that without >changing the rest of the protocol. We define a TERO with necessary modification in our draft. >In unicast scenarios, there is nothing requiring the traffic to be IP. As >a matter of fact, there are two different explicit mechanisms for non-IP >traffic. One is to specify the Ethertype for the payload in the >LABEL_REQUEST object, and the other is to signal an IP LSP, and use an >extra label on the stack to identify the protocol (the Martini draft). > >Yes, you need to specify an IP address for the tunnel endpoint, but you >need to do that for unicast LSPs as well. We think that specifying an IP mulitcast group address as the tunnel endpoint has completely different meaning compared with unicast case. The unicast IP address is attached to physical IF or node and indicates its physical location in the network. Therefore, we can specify the tunnel endpoint by this address. But multicast group address cannot specify the physical location. As a result, we can not specify the tunnel endpoint by this address. This is a fundamental problem caused by the definition of SESSION object in conventional RSVP-TE protocol. Therefore, we newly redefine MULTICAST SESSION object in our draft. In addition to this problem, it is not convenient to use single IP multicast address because we cannot accommodate several IP multicast group traffic and non-IP traffic in a single multicast LSP tunnel. >Note also that you will need _some_ mechanism for defining the endpoints >of a multicast LSP. If you don't define an IP multicast group and have >your egress routers all join that group, then you'll have to re-invent the >wheel by replicating what existing multicast routing protocols already do. We define the endpoint of a multicast LSP by TERO and TRRO. > Multicast is difficult enough with established protocols (IGMP, DVMRP, > PIM-DM and PIM-SM). Inventing yet another routing protocol, and making > it part of RSVP (which is already enormously complex) is something I > would want to avoid at all costs. We also think that IP multicast routing protocol is difficult to engineer and has problem in its scalablity. And we think it is not good choice to combine the IP multicast routing protocol and conventional RSVP-TE. Therefore, we proposed the combination of extended RSVP-TE protocol that has multicast capability and conventional unicast routing protocol. >And note that you are forcing your multicast to be only p-to-mp. You are >not permitting IP multicast (wich is mp-to-mp) to be used. Which means >you end up with less funcationality than there was before. We propose the mp-to-mp LSP setup mechanism in our draft. Please see, section 7. >There's no big deal if you want to define your own private multicast >groups, for the purpose of establishing TE across your own routing >core. Once the multicast LSPs are in place, you can then transit any >traffic you want across it. > >Remember, you're not interested in setting up LSPs that run from a server >to all of the millions of hosts receiving from that server. You're >interested in setting up LSPs to efficiently transit multicast traffic to >the edges of your network. This is especially true if you're talking >about non-IP traffic. As mentioned above, we are not interested in shortest path tree that is calculated by conventinal IP multicast routing protocol. Although we define the private multicast group, we cannot still control tree topology and multicast traffic across it. We think it is much easier to control traffic by path layer compared with routing layer. MPLS is attractive because it can control traffic by path (LSP) independent to routing protocol when considering TE. Therefore, we think multicast MPLS protocol must support not only multicast LSP that is established by multicast routing protocol but also multicast LSP that is established by TERO. Best regards, Seisho Yasukawa From owner-mpls@UU.NET Thu Jul 4 11:23:36 2002 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 ESMTP id LAA19494 for ; Thu, 4 Jul 2002 11:23:36 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbl05703 for ; Thu, 4 Jul 2002 15:24:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwbl02962; Thu, 4 Jul 2002 15:23:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwbl15707 for mpls-outgoing; Thu, 4 Jul 2002 15:22:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwbl15700 for ; Thu, 4 Jul 2002 15:22: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 QQmwbl03892 for ; Thu, 4 Jul 2002 15:20:15 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbl00525 for ; Thu, 4 Jul 2002 15:20:14 GMT Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmwbl00507 for ; Thu, 4 Jul 2002 15:20:13 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3F04S2ZM>; Thu, 4 Jul 2002 16:20:05 +0100 Message-ID: To: giles@packetexchange.net Cc: mpls@UU.NET Subject: RE: your mail Date: Thu, 4 Jul 2002 16:19:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Thanks Giles.....but I am still puzzled....please see below. regards, Neil Giles Heron explained 04 July 2002 13:45 > agreed - this is what you'd expect to see. > > IMO the only traffic that should ride directly over a tunnel LSP is IP > (v4 or v6). NH=> So an MPLS LSP is not allowed over a tunnel.....is that what you are saying here? But I can't figure your logic at all......'tunnels' can be nested right, so by definition the client of one tunnel can be another tunnel. And the client of the bottom-of-stack LSP (which is the highest tunnel in the LSP stack) can be (i) v4 (ii) v6 (iii) a PWE3 control-word or (since this is optional) some other client layer technology trail, like an ATM VPC, PPP, FR, etc. > > however there is one implementation out there (that I know of - there > may be others) where layer 2 traffic is carried directly over a tunnel > LSP. NH=> Can you explain the difference between an MPLS tunnel and an LSP please? BTW - How does VoverMPLS fit with all this? > > Giles > > On Wed, 2002-07-03 at 18:21, neil.2.harrison@bt.com wrote: > > Giles......can you please just expand on what you mean here > in the case of > > XoverMPLS PWE3 work? As a min one would see (in order > lowest->highest, or > > outer->inner, the following 'words'): > > Outer Tunnel LSP header->Inner VC LSP header->Control-word > (optional)-> > > various payload types. > > > > regards, Neil > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > Sent: 03 July 2002 18:01 > > > To: Gray, Eric > > > Cc: 'Kannan "S (Networking) - CTD, " "Chennai.'; Eric > Osborne; 'MPLS > > > Mailing list' > > > Subject: RE: your mail > > > > > > > > > On Wed, 2002-07-03 at 13:55, Gray, Eric wrote: > > > [snip] > > > > Thirdly, it is definitely inappropriate to assume that the > > > > stuff after the last label is an IP header except in the > > > > case where the last label is an explicit IPv4 NULL label. > > > > It could be any of a lot of things otherwise and - given > > > > PHP and a number of defined MPLS applications - the last > > > > label is very unlikely to be an IPv4 explicit NULL label. > > > > > > Other than Juniper's CCC (which is dependent on RSVP-TE) > I'm not aware > > > of any application putting non-IP traffic directly over > an LSP (i.e. > > > without using a label stack). > > > > > > Therefore when there is only one label (other than when > an egress LSR > > > using PHP receives a packet - in which case load > balancing is somewhat > > > moot) I think we can assume that the payload is IP? > > > > > > Giles > > > > > > > > > > > Eric W. Gray > > > > Systems Architect > > > > Celox Networks, Inc. > > > > egray@celoxnetworks.com > > > > 508 305 7214 > > > > > > > > > > > > -----Original Message----- > > > > From: Kannan S (Networking) - CTD, Chennai. > > > [mailto:kannans@ctd.hcltech.com] > > > > > > > > Sent: Wednesday, July 03, 2002 3:25 AM > > > > To: Eric Osborne > > > > Cc: 'MPLS Mailing list' > > > > Subject: RE: your mail > > > > > > > > Eric, > > > > > > > > About the idea of using the bottom most label for doing ECMP - > > > > > > > > Wouldnt that restrict the ECMP hashing function, because my > > > hashing function > > > > is now totally dependent on how some router in the edge > > > chose to identify a > > > > flow? > > > > > > > > For example, suppose an ingress edge LSR marked the bottom > > > most label using > > > > say first 10 bits of the IP - SA, and last 10 bits of IP - > > > DA, then I cant > > > > have an hashing algorithm which uses last 10 bits of IP - > > > SA, and first 10 > > > > bits of IP - DA, right ? The efficiency of the algorithm > > > (the choice > > > > itself) is now very dependent on how the edge LSR > identifies flows. > > > > > > > > My point is, if it is decided that an LSR is going to look > > > beyond whatever > > > > depth it is supposed to, the LSR's ECMP hashing function > > > might as well look > > > > at the IP header instead of looking at the bottom most label. > > > > > > > > Am I missing something here? > > > > > > > > Thanks, > > > > Kans. > > > > > > > > -----Original Message----- > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > Sent: Wednesday, July 03, 2002 4:01 AM > > > > To: Gray, Eric > > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > > Subject: Re: your mail > > > > > > > > > > > > On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > > > > > Eric, > > > > > > > > > > It is in the fact that we have to be sure - > > > > > just as you suggest. The cost of being sure, however, > > > > > is that you have to be prepared to deal with occasions > > > > > when the check fails. What do you do when the higher > > > > > layer is not UDP or TCP - throw these packets in to a > > > > > common bucket? What is the expected impact if this > > > > > traffic might occasionally be significant? > > > > > > > > Then you need a better load-balancing algorithm. Either IP > > > SA/DA and > > > > some randomness, or random sampling from the packet, or (heaven > > > > forbid) some sort of flow-based scheme. I'm even > dubious about the > > > > efficacy of using TCP/UDP ports to hash, given that > most traffic is > > > > either src or dst TCP port 80, which really only gives you > > > the port in > > > > the other direction to play with. But that's not > really my problem, > > > > as the implementation I'm familiar with doesn't do anything with > > > > TCP/UDP ports (although I'm sure that *somewhere* in > cisco we make a > > > > device that does; I just don't deal with it/them). > > > > > > > > also, don't forget that this hypothetical algorithm takes > > > into acount > > > > IP SA/DA and TCP/UDP SP/DP. So if you have too many > collisions, you > > > > probably have very few flows/conversations/whatnot anyways, > > > and either > > > > need to move to something like per-packet (ick) or just > > > larger pipes. > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > > > > > > > > > > > Eric W. Gray > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > > Sent: Tuesday, July 02, 2002 4:24 PM > > > > > To: Gray, Eric > > > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > > > Subject: Re: your mail > > > > > > > > > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > > > > > Eric, > > > > > > > > > > > > To answer your final two questions, yes it probably > > > > > > is stealing. The fact that you can get away with a crime > > > > > > does not make it any less a crime. Who knows, some vendors > > > > > > may not check that the protocol over the top of IP > is either > > > > > > UDP or TCP before using the port numbers. > > > > > > > > > > If a vendor checks the offset where the port numbers > > > should be without > > > > > checking for the correct protocol type, this is a cruddy > > > > > implementation and shouldn't exist. My question was > > > really along the > > > > > lines of "what if we use the values that we *know* are > > > UDP/TCP port > > > > > numbers"? From what you say above, it seems like that > > > might be OK, as > > > > > long as we only do this when we're sure? Or is there > > > some inherent > > > > > architectual layer violation thing that you're objecting to? > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > > > I think you can > > > > > > easily imagine what that might lead to if a set of packets > > > > > > carry a higher level protocol where the > corresponding fields > > > > > > may vary from packet to packet in a single micro-flow. The > > > > > > real question is how common is this? > > > > > > > > > > > > Eric W. Gray > > > > > > Systems Architect > > > > > > Celox Networks, Inc. > > > > > > egray@celoxnetworks.com > > > > > > 508 305 7214 > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > > > Sent: Tuesday, July 02, 2002 1:32 PM > > > > > > To: Hummel Heinrich > > > > > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; > > > George Sheng; > > > > > > scullptor@yahoo.com; mpls@UU.NET > > > > > > Subject: Re: your mail > > > > > > > > > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel > Heinrich wrote: > > > > > > > It gets weirder and weirder: The MPLS WG invents a > > > label stack, but > > > > > does > > > > > > not care at all that any of the > > > > > > > deeper nested labels may ever be signalled/carried by > > > means of a > > > > > > Label-TLV/object (no public comments to my > > > > > > > Hierarchical LSPs, > draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > > > > > > > > > However it is ok, to "steal" the deepest nested label > > > and call it > > > > > > "VC-label" for indexing > > > > > > > some VRF at some remote PE. > > > > > > > > > > > > This is not theft; it's using the labels as they were > > > designed. How > > > > > > is using the bottommost label as a VC-labe/VPN > label/whatever > > > > > > "stealing"? You seem to be attacking the very idea of > > > label stacking, > > > > > > which is a pretty useful concept. > > > > > > > > > > > > > Furthermore it is ok, to "steal" the very same label > > > for hashing. > > > > > > > > > > > > > > > > > > > What about IP router vendors that do load-balancing > > > based on L4/L5 > > > > > > information like protocol type and port numbers? Is > > > that stealing? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > > > > > Independent from what is clean and what is > > > quick&dirty, I cannot > > > > detect > > > > > > any sense in giving a hash-meaning to the bottom > label at all. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Heinrich Hummel > > > > > > > Siemens > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > > > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > > > > > An: Shahram Davari > > > > > > > Cc: 'Eric Osborne'; George Sheng; > > > scullptor@yahoo.com; mpls@UU.NET > > > > > > > Betreff: Re: your mail > > > > > > > > > > > > > > > > > > > > > Shahram> To do ECMP, you need to assign hashed > > > values to egress > > > > ports. > > > > > > This > > > > > > > Shahram> assignment is the hash state that I said > you need. > > > > > > > > > > > > > > A hash is a function that maps some sequence of > > > octets into a > > > > > sequence > > > > > > of > > > > > > > integers. If you want to split traffic over six > paths, while > > > > ensuring > > > > > > that > > > > > > > all packets with the same bottom label travel the > > > same path, you > > > > > need > > > > > > a > > > > > > > function that maps a 20 bit quantity into a number > > > from 1-6. There > > > > > is > > > > > > no > > > > > > > need to maintain state of any kind. > > > > > > > -- > > > ================================================================= > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > ph: +44 7880 506185 "if you build it they will yawn" > > > ================================================================= > > > > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Thu Jul 4 11:43:12 2002 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 ESMTP id LAA19830 for ; Thu, 4 Jul 2002 11:43:12 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbm27954 for ; Thu, 4 Jul 2002 15:43:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwbm24250; Thu, 4 Jul 2002 15:42:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwbm17036 for mpls-outgoing; Thu, 4 Jul 2002 15:42:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwbm17031 for ; Thu, 4 Jul 2002 15:41:57 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 QQmwbm16776 for ; Thu, 4 Jul 2002 15:41:33 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbm23365 for ; Thu, 4 Jul 2002 15:41:33 GMT Received: from imo-m01.mx.aol.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imo-m01.mx.aol.com [64.12.136.4]) id QQmwbm23361 for ; Thu, 4 Jul 2002 15:41:33 GMT Received: from VladicaStanisic@netscape.net by imo-m01.mx.aol.com (mail_out_v32.21.) id u.13a.28e0fe5 (16226); Thu, 4 Jul 2002 11:41:20 -0400 (EDT) Received: from netscape.net (mow-m21.webmail.aol.com [64.12.180.137]) by air-in02.mx.aol.com (v86_r1.15) with ESMTP id MAILININ22-0704114119; Thu, 04 Jul 2002 11:41:19 -0400 Date: Thu, 04 Jul 2002 11:41:00 -0400 From: vladicastanisic@netscape.net (Vladica Stanisic) To: mk@ee.columbia.edu (Michael Kounavis), Navid_Yazdani@raytheon.com (Navid Yazdani) Cc: mpls@UU.NET Subject: Re: QoS Survey Paper Message-ID: <3369B13C.3253C876.54539896@netscape.net> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit There is a paper on QoS here http://www.ece.ncsu.edu/cacc/tech_reports/abs/abs0109.html Michael Kounavis wrote: > >There is a book on Quality of Service by >P. Ferguson and G. Huston > >"Quality of Service: Delivering QoS on the Internet >and in Corporate Networks" Publisher: John Wiley and Sons > > >For an Overview of packet scheduling techniques >look at chapter 9 from S. Keshav's book: > >"An Engineering approach to Computer Networking", >Addison Wesley.i > > >A high level over view of Internet QoS mechanisms >is also given at: > >"Internet QoS: THe Big Picture", >by  X. Xiao and L. Ni, Michigan State University > >http://www.cse.msu.edu/~xiaoxipe/papers/msu.inet.qos.bigpicture.pdf > >And of course an excellent overview is given in >Roch's paper, which Ping suggested. > >Michael > > > > > > > > >On Tue, 2 Jul 2002, Navid Yazdani wrote: > >> Can anyone recommend a survey paper, article, or book that examines the >> advantages and disadvantages of different IP QoS schemes? >> >> thanks >> Navid >> >> > >-- >-- >Michael Kounavis >http://www.comet.columbia.edu/~mk > > > > > > > > > > > -- Vladica Stanisic Research Assistant North Carolna State University e-mail:vjstanis@eos.ncsu.edu __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ From owner-mpls@UU.NET Thu Jul 4 12:09:22 2002 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 ESMTP id MAA20380 for ; Thu, 4 Jul 2002 12:09:22 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbo27489 for ; Thu, 4 Jul 2002 16:10:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwbo24334; Thu, 4 Jul 2002 16:08:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwbo10242 for mpls-outgoing; Thu, 4 Jul 2002 16:08:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwbo10237 for ; Thu, 4 Jul 2002 16:08:03 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 QQmwbo03968 for ; Thu, 4 Jul 2002 16:07:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbo28525 for ; Thu, 4 Jul 2002 16:07:23 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQmwbo28515 for ; Thu, 4 Jul 2002 16:07:22 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA27396; Thu, 4 Jul 2002 18:07:18 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA12914; Thu, 4 Jul 2002 18:07:20 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 18:07:19 +0200 Message-ID: From: Hummel Heinrich To: "'Kullberg, Alan'" , "MPLS_WG (E-mail)" Subject: AW: comments on draft-yasukawa-mpls-rsvp-multicast-00.txt Date: Thu, 4 Jul 2002 18:07:18 +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 MAA20380 Two comments: 1) Three years ago me and Swee Loke (formerly Nortel) provided perfect algorithms for computing and processing explicit tree route information (each transit LSR could recognize whether or not it was a leaf node itself, which are its proper child links and which part of the received tree route info has to be forwarded via which child link. However that draft-hummel-mpls-explicit-tree-01.txt was grounded by the chairs. 2) Can a node be both a leaf and a branch? For sure, this needs to be enabled. If yes, how does a node know that it is both? We provided a perfect indication in the TREE ROUTE TLV. W.r.t. the data flow, I have nowhere seen some description like: the incoming label may be mapped to more than one outgoing labels by means of a set of NHLFEs bound to the particular incoming label. If one these NHLFEs contains the IPv4_NULL_LABEL then this node is also leaf node. Heinrich Hummel Siemens -----Ursprüngliche Nachricht----- Von: Kullberg, Alan [mailto:akullber@netplane.com] Gesendet: Montag, 1. Juli 2002 22:16 An: MPLS_WG (E-mail) Betreff: comments on draft-yasukawa-mpls-rsvp-multicast-00.txt I think that this draft has technical merit in that an IGMP Multicast protocol is not required. Also, protocols other than IP can be supported since there is no dependence on an IP multicast address as the destination. Here are some specific comments on the draft: 1. What is the expected behavior at the branch point when trying to setup more than one LSP (multiple PATH messages are sent). How long should the branch node wait for all of the returning RESVs to be received and what is the recovery mechanism if the node does not receive an RESV for all PATH messages. 2. For each type of the Notify message, when it reaches the sender node, the sender must update the TERO in the outgoing PATH message to reflect the changes in the multicast tree. This must be stated in the draft. 3. See figure 9 on page 27. The PATH message from node B to node E includes the sub-tree from node E downwards. When the PRUNE message arrives at E, E sends a PATH_TEAR downstream and a PRUNE_NOTIFY to the sender node A. If node B sends a PATH refresh message (with the old TERO), then E will setup the sub-tree again. But if the PRUNE_NOTIFY to node A causes A to remove the sub-tree from the TERO and send the modified PATH, and the PATH is received at B before B sends a PATH refresh to E, then no problem occurs. This is a race condition that is very likely to happen. This race condition exists for both the prune and the leave mechanisms. A similar problem could also exist for the JOIN and GRAFT mechanisms, depending upon what a node should do when a PATH with TERO is received that does not specify an already signaled sub-tree below this node. A possible solution to the prune and leave problems is to implement a D (delete) bit in the TERO sub-objects similar to that in draft-cheng-mpls-rsvp-multicast-er-00.txt, except that when the prune or leave is done, the branch point node sends some kind of NOTIFY message to the sender so that the sub-tree may be removed from the TERO. This requires a leaf node to send the LEAVE request all the way to the sender. A possible solution for the join and graft problems is to signal the join or graft by sending a modified TERO from the sender node and then having the branch point send some kind of NOTIFY message to the sender upon successful signaling of the join or graft. This requires a leaf node to send the JOIN request all the way to the sender. 4. In figure 14, at the bottom, why is a PATH message being sent from node A to node B? Is this a typo? 5. Instead of sending an ADD message for MP-to-MP, why not send a PATH message that has the 2 new objects in the ADD message? 6. On page 36, last paragraph, the TERO is included in the PATH_TEAR message, but the contents of the PATH_TEAR message was not shown to contain the TERO. 7. In figure 7, on GRAFT mechanism, does GRAFT mechanism require that node E was already a branch point? I think yes, otherwise data won't be sent from node B to the node E sub-tree until sender node A updates the TERO and B sends a PATH to E and E sends a RESV to B. 8. Can a node be both a leaf and a branch? If yes, how does a node know that it is both? Alan From owner-mpls@UU.NET Thu Jul 4 12:36:39 2002 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 ESMTP id MAA20893 for ; Thu, 4 Jul 2002 12:36:39 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbq20835 for ; Thu, 4 Jul 2002 16:37:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwbq18164; Thu, 4 Jul 2002 16:35:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwbq13340 for mpls-outgoing; Thu, 4 Jul 2002 16:35:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwbq13329 for ; Thu, 4 Jul 2002 16:35:17 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 QQmwbq14559 for ; Thu, 4 Jul 2002 16:34:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbq17071 for ; Thu, 4 Jul 2002 16:34:13 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmwbq17065 for ; Thu, 4 Jul 2002 16:34:13 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17Q9YW-0001cY-00; Thu, 04 Jul 2002 17:34:08 +0100 Subject: RE: your mail From: Giles Heron To: neil.2.harrison@bt.com Cc: mpls@UU.NET In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 04 Jul 2002 17:34:05 +0000 Message-Id: <1025804045.2948.286.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA20893 On Thu, 2002-07-04 at 15:19, neil.2.harrison@bt.com wrote: > Thanks Giles.....but I am still puzzled....please see below. regards, Neil > > Giles Heron explained 04 July 2002 13:45 > > agreed - this is what you'd expect to see. > > > > IMO the only traffic that should ride directly over a tunnel LSP is IP > > (v4 or v6). > NH=> So an MPLS LSP is not allowed over a tunnel.....is that what you are > saying here? But I can't figure your logic at all......'tunnels' can be > nested right, so by definition the client of one tunnel can be another > tunnel. And the client of the bottom-of-stack LSP (which is the highest > tunnel in the LSP stack) can be (i) v4 (ii) v6 (iii) a PWE3 control-word or > (since this is optional) some other client layer technology trail, like an > ATM VPC, PPP, FR, etc. no. What I'm saying is that if there is a stack depth of one (other than on the last hop in the presence of PHP) then the client ought to be IP. sorry if my wording was sloppy :( Giles > > however there is one implementation out there (that I know of - there > > may be others) where layer 2 traffic is carried directly over a tunnel > > LSP. > NH=> Can you explain the difference between an MPLS tunnel and an LSP > please? > BTW - How does VoverMPLS fit with all this? > > > > Giles > > > > On Wed, 2002-07-03 at 18:21, neil.2.harrison@bt.com wrote: > > > Giles......can you please just expand on what you mean here > > in the case of > > > XoverMPLS PWE3 work? As a min one would see (in order > > lowest->highest, or > > > outer->inner, the following 'words'): > > > Outer Tunnel LSP header->Inner VC LSP header->Control-word > > (optional)-> > > > various payload types. > > > > > > regards, Neil > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > Sent: 03 July 2002 18:01 > > > > To: Gray, Eric > > > > Cc: 'Kannan "S (Networking) - CTD, " "Chennai.'; Eric > > Osborne; 'MPLS > > > > Mailing list' > > > > Subject: RE: your mail > > > > > > > > > > > > On Wed, 2002-07-03 at 13:55, Gray, Eric wrote: > > > > [snip] > > > > > Thirdly, it is definitely inappropriate to assume that the > > > > > stuff after the last label is an IP header except in the > > > > > case where the last label is an explicit IPv4 NULL label. > > > > > It could be any of a lot of things otherwise and - given > > > > > PHP and a number of defined MPLS applications - the last > > > > > label is very unlikely to be an IPv4 explicit NULL label. > > > > > > > > Other than Juniper's CCC (which is dependent on RSVP-TE) > > I'm not aware > > > > of any application putting non-IP traffic directly over > > an LSP (i.e. > > > > without using a label stack). > > > > > > > > Therefore when there is only one label (other than when > > an egress LSR > > > > using PHP receives a packet - in which case load > > balancing is somewhat > > > > moot) I think we can assume that the payload is IP? > > > > > > > > Giles > > > > > > > > > > > > > > Eric W. Gray > > > > > Systems Architect > > > > > Celox Networks, Inc. > > > > > egray@celoxnetworks.com > > > > > 508 305 7214 > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Kannan S (Networking) - CTD, Chennai. > > > > [mailto:kannans@ctd.hcltech.com] > > > > > > > > > > Sent: Wednesday, July 03, 2002 3:25 AM > > > > > To: Eric Osborne > > > > > Cc: 'MPLS Mailing list' > > > > > Subject: RE: your mail > > > > > > > > > > Eric, > > > > > > > > > > About the idea of using the bottom most label for doing ECMP - > > > > > > > > > > Wouldnt that restrict the ECMP hashing function, because my > > > > hashing function > > > > > is now totally dependent on how some router in the edge > > > > chose to identify a > > > > > flow? > > > > > > > > > > For example, suppose an ingress edge LSR marked the bottom > > > > most label using > > > > > say first 10 bits of the IP - SA, and last 10 bits of IP - > > > > DA, then I cant > > > > > have an hashing algorithm which uses last 10 bits of IP - > > > > SA, and first 10 > > > > > bits of IP - DA, right ? The efficiency of the algorithm > > > > (the choice > > > > > itself) is now very dependent on how the edge LSR > > identifies flows. > > > > > > > > > > My point is, if it is decided that an LSR is going to look > > > > beyond whatever > > > > > depth it is supposed to, the LSR's ECMP hashing function > > > > might as well look > > > > > at the IP header instead of looking at the bottom most label. > > > > > > > > > > Am I missing something here? > > > > > > > > > > Thanks, > > > > > Kans. > > > > > > > > > > -----Original Message----- > > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > > Sent: Wednesday, July 03, 2002 4:01 AM > > > > > To: Gray, Eric > > > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > > > Subject: Re: your mail > > > > > > > > > > > > > > > On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > > > > > > Eric, > > > > > > > > > > > > It is in the fact that we have to be sure - > > > > > > just as you suggest. The cost of being sure, however, > > > > > > is that you have to be prepared to deal with occasions > > > > > > when the check fails. What do you do when the higher > > > > > > layer is not UDP or TCP - throw these packets in to a > > > > > > common bucket? What is the expected impact if this > > > > > > traffic might occasionally be significant? > > > > > > > > > > Then you need a better load-balancing algorithm. Either IP > > > > SA/DA and > > > > > some randomness, or random sampling from the packet, or (heaven > > > > > forbid) some sort of flow-based scheme. I'm even > > dubious about the > > > > > efficacy of using TCP/UDP ports to hash, given that > > most traffic is > > > > > either src or dst TCP port 80, which really only gives you > > > > the port in > > > > > the other direction to play with. But that's not > > really my problem, > > > > > as the implementation I'm familiar with doesn't do anything with > > > > > TCP/UDP ports (although I'm sure that *somewhere* in > > cisco we make a > > > > > device that does; I just don't deal with it/them). > > > > > > > > > > also, don't forget that this hypothetical algorithm takes > > > > into acount > > > > > IP SA/DA and TCP/UDP SP/DP. So if you have too many > > collisions, you > > > > > probably have very few flows/conversations/whatnot anyways, > > > > and either > > > > > need to move to something like per-packet (ick) or just > > > > larger pipes. > > > > > > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > > > > > > > > > > > > > > > Eric W. Gray > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > > > Sent: Tuesday, July 02, 2002 4:24 PM > > > > > > To: Gray, Eric > > > > > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > > > > > Subject: Re: your mail > > > > > > > > > > > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > > > > > > Eric, > > > > > > > > > > > > > > To answer your final two questions, yes it probably > > > > > > > is stealing. The fact that you can get away with a crime > > > > > > > does not make it any less a crime. Who knows, some vendors > > > > > > > may not check that the protocol over the top of IP > > is either > > > > > > > UDP or TCP before using the port numbers. > > > > > > > > > > > > If a vendor checks the offset where the port numbers > > > > should be without > > > > > > checking for the correct protocol type, this is a cruddy > > > > > > implementation and shouldn't exist. My question was > > > > really along the > > > > > > lines of "what if we use the values that we *know* are > > > > UDP/TCP port > > > > > > numbers"? From what you say above, it seems like that > > > > might be OK, as > > > > > > long as we only do this when we're sure? Or is there > > > > some inherent > > > > > > architectual layer violation thing that you're objecting to? > > > > > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > > > > > I think you can > > > > > > > easily imagine what that might lead to if a set of packets > > > > > > > carry a higher level protocol where the > > corresponding fields > > > > > > > may vary from packet to packet in a single micro-flow. The > > > > > > > real question is how common is this? > > > > > > > > > > > > > > Eric W. Gray > > > > > > > Systems Architect > > > > > > > Celox Networks, Inc. > > > > > > > egray@celoxnetworks.com > > > > > > > 508 305 7214 > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > > > > > Sent: Tuesday, July 02, 2002 1:32 PM > > > > > > > To: Hummel Heinrich > > > > > > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; > > > > George Sheng; > > > > > > > scullptor@yahoo.com; mpls@UU.NET > > > > > > > Subject: Re: your mail > > > > > > > > > > > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel > > Heinrich wrote: > > > > > > > > It gets weirder and weirder: The MPLS WG invents a > > > > label stack, but > > > > > > does > > > > > > > not care at all that any of the > > > > > > > > deeper nested labels may ever be signalled/carried by > > > > means of a > > > > > > > Label-TLV/object (no public comments to my > > > > > > > > Hierarchical LSPs, > > draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > > > > > > > > > > > However it is ok, to "steal" the deepest nested label > > > > and call it > > > > > > > "VC-label" for indexing > > > > > > > > some VRF at some remote PE. > > > > > > > > > > > > > > This is not theft; it's using the labels as they were > > > > designed. How > > > > > > > is using the bottommost label as a VC-labe/VPN > > label/whatever > > > > > > > "stealing"? You seem to be attacking the very idea of > > > > label stacking, > > > > > > > which is a pretty useful concept. > > > > > > > > > > > > > > > Furthermore it is ok, to "steal" the very same label > > > > for hashing. > > > > > > > > > > > > > > > > > > > > > > What about IP router vendors that do load-balancing > > > > based on L4/L5 > > > > > > > information like protocol type and port numbers? Is > > > > that stealing? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > > > > > > > Independent from what is clean and what is > > > > quick&dirty, I cannot > > > > > detect > > > > > > > any sense in giving a hash-meaning to the bottom > > label at all. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Heinrich Hummel > > > > > > > > Siemens > > > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > > > > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > > > > > > An: Shahram Davari > > > > > > > > Cc: 'Eric Osborne'; George Sheng; > > > > scullptor@yahoo.com; mpls@UU.NET > > > > > > > > Betreff: Re: your mail > > > > > > > > > > > > > > > > > > > > > > > > Shahram> To do ECMP, you need to assign hashed > > > > values to egress > > > > > ports. > > > > > > > This > > > > > > > > Shahram> assignment is the hash state that I said > > you need. > > > > > > > > > > > > > > > > A hash is a function that maps some sequence of > > > > octets into a > > > > > > sequence > > > > > > > of > > > > > > > > integers. If you want to split traffic over six > > paths, while > > > > > ensuring > > > > > > > that > > > > > > > > all packets with the same bottom label travel the > > > > same path, you > > > > > > need > > > > > > > a > > > > > > > > function that maps a 20 bit quantity into a number > > > > from 1-6. There > > > > > > is > > > > > > > no > > > > > > > > need to maintain state of any kind. > > > > > > > > > -- > > > > ================================================================= > > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > > ph: +44 7880 506185 "if you build it they will yawn" > > > > ================================================================= > > > > > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Thu Jul 4 12:41:48 2002 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 ESMTP id MAA21023 for ; Thu, 4 Jul 2002 12:41:48 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwbp19305; Thu, 4 Jul 2002 16:16:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwbp12178 for mpls-outgoing; Thu, 4 Jul 2002 16:16:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwbp12170 for ; Thu, 4 Jul 2002 16:16: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 QQmwbp17069 for ; Thu, 4 Jul 2002 16:16:01 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbp05850 for ; Thu, 4 Jul 2002 16:16:01 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe24.law9.hotmail.com [64.4.8.81]) id QQmwbp05842 for ; Thu, 4 Jul 2002 16:16:00 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 4 Jul 2002 09:16:00 -0700 X-Originating-IP: [212.199.233.65] From: "Doug Degan" To: Subject: FRR question Date: Thu, 4 Jul 2002 19:15:53 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C2238F.37178920" 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 Message-ID: X-OriginalArrivalTime: 04 Jul 2002 16:16:00.0283 (UTC) FILETIME=[160C8EB0:01C22376] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C2238F.37178920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable suppose a router along the path of a protected LSP gets PATH_TEAR=20 should it propagate it and remove this LSP? does he know if it came from Ingress due to user configuration ? I remind you it might be that the previous router doesn't support FRR = and sends the TEAR due to incoming interface failure. thanks doug. ------=_NextPart_000_0045_01C2238F.37178920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
suppose a router along the path of a = protected LSP=20 gets PATH_TEAR
should it propagate it and remove this=20 LSP?
does he know if it came from Ingress = due to user=20 configuration ?
 
I remind you it might be that the = previous router=20 doesn't support FRR and sends the TEAR due to incoming interface=20 failure.
 
 
thanks doug.
------=_NextPart_000_0045_01C2238F.37178920-- From owner-mpls@UU.NET Thu Jul 4 12:49:43 2002 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 ESMTP id MAA21149 for ; Thu, 4 Jul 2002 12:49:42 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbr05222 for ; Thu, 4 Jul 2002 16:50:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwbr03721; Thu, 4 Jul 2002 16:49:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwbr14894 for mpls-outgoing; Thu, 4 Jul 2002 16:49:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwbr14887 for ; Thu, 4 Jul 2002 16:49: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 QQmwbr15198 for ; Thu, 4 Jul 2002 16:47:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbr02138 for ; Thu, 4 Jul 2002 16:47:11 GMT Received: from zcars04e.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmwbr02134 for ; Thu, 4 Jul 2002 16:47:10 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g64Gkik06584; Thu, 4 Jul 2002 12:46:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 12:46:44 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C047E6D78@zcard031.ca.nortel.com> From: "David Allan" To: Giles Heron , neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: RE: your mail Date: Thu, 4 Jul 2002 12:46:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2237A.60A1AECA" 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_01C2237A.60A1AECA Content-Type: text/plain; charset="iso-8859-1" Giles: you wrote > What I'm saying is that if there is a stack depth of one (other than on > the last hop in the presence of PHP) then the client ought to be IP. so far.....;-) Dave ------_=_NextPart_001_01C2237A.60A1AECA Content-Type: text/html; charset="iso-8859-1" RE: your mail

Giles:

you wrote

> What I'm saying is that if there is a stack depth of one (other than on
> the last hop in the presence of PHP) then the client ought to be IP.

so far.....;-)

Dave
 

------_=_NextPart_001_01C2237A.60A1AECA-- From owner-mpls@UU.NET Thu Jul 4 13:25:38 2002 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 ESMTP id NAA21624 for ; Thu, 4 Jul 2002 13:25:37 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbt22448 for ; Thu, 4 Jul 2002 17:26:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwbt19176; Thu, 4 Jul 2002 17:24:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwbt09478 for mpls-outgoing; Thu, 4 Jul 2002 17:24:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwbt09469 for ; Thu, 4 Jul 2002 17:24: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 QQmwbt09644 for ; Thu, 4 Jul 2002 17:23:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbt28990 for ; Thu, 4 Jul 2002 17:23:10 GMT Received: from tama5.ecl.ntt.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQmwbt28979 for ; Thu, 4 Jul 2002 17:23:09 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id CAA08727; Fri, 5 Jul 2002 02:23:05 +0900 (JST) (envelope-from yasukawa.seisho@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g64HN4xV012711; Fri, 5 Jul 2002 02:23:04 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g64HN4n5028638; Fri, 5 Jul 2002 02:23:04 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id CAA20230; Fri, 5 Jul 2002 02:23:03 +0900 (JST) Received: from neeiwin-yasukawa by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id CAA14519; Fri, 5 Jul 2002 02:23:03 +0900 (JST) Message-Id: <4.2.0.58.J.20020705003755.02208470@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 05 Jul 2002 02:41:21 +0900 To: "Kullberg, Alan" , "MPLS_WG (E-mail)" From: Seisho Yasukawa Subject: Re: comments on draft-yasukawa-mpls-rsvp-multicast-00.txt In-Reply-To: <076236BAE727D611943F00508BA0F95906E7B4@XOVER.dedham.mindsp eed.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Alan Thank you for your comments on our draft. >Here are some specific comments on the draft: > >1. What is the expected behavior at the branch point when trying to setup >more than one LSP (multiple PATH messages are sent). How long should the >branch node wait for all of the returning RESVs to be received and what is >the recovery mechanism if the node does not receive an RESV for all PATH >messages. We consider the branch node to wait for all the reply messages coming from downstream leaf nodes to which the branch node send path messages to establish a sub-tree. When the branch node succeeds in total establishment of sub-tree, it is expected that the branch node receives the all of Resv messages corresponds to Path messages before long from the all of downstream leaf nodes. When the branch node succeeds in partial establishment of sub-tree, it is expected that the branch node receives the Resv messages and PathErr messages before long from the all of downstream leaf nodes. But we must assume abnormal case such as link failure between the branch node and downstream leaf nodes. In this case, the branch node not always receives the all the reply messages from the downstream leaf nodes. We think implementing timer is useful for those recovery mechanism. >2. For each type of the Notify message, when it reaches the sender node, the >sender must update the TERO in the outgoing PATH message to reflect the >changes in the multicast tree. This must be stated in the draft. In our design, topological change must be notified to LSP setup initiator at first. And this information must be propagated to all of the nodes within the LSP by updated TERO in the refresh Path message. We will describe this mechanism in our revised draft. >3. See figure 9 on page 27. >The PATH message from node B to node E includes the sub-tree from node E >downwards. When the PRUNE message arrives at E, E sends a PATH_TEAR >downstream and a PRUNE_NOTIFY to the sender node A. If node B sends a PATH >refresh message (with the old TERO), then E will setup the sub-tree again. >But if the PRUNE_NOTIFY to node A causes A to remove the sub-tree from the >TERO and send the modified PATH, and the PATH is received at B before B >sends a PATH refresh to E, then no problem occurs. >This is a race condition that is very likely to happen. This race condition >exists for both the prune and the leave mechanisms. A similar problem could >also exist for the JOIN and GRAFT mechanisms, depending upon what a node >should do when a PATH with TERO is received that does not specify an already >signaled sub-tree below this node. >A possible solution to the prune and leave problems is to implement a D >(delete) bit in the TERO sub-objects similar to that in >draft-cheng-mpls-rsvp-multicast-er-00.txt, except that when the prune or >leave is done, the branch point node sends some kind of NOTIFY message to >the sender so that the sub-tree may be removed from the TERO. This requires >a leaf node to send the LEAVE request all the way to the sender. >A possible solution for the join and graft problems is to signal the join or >graft by sending a modified TERO from the sender node and then having the >branch point send some kind of NOTIFY message to the sender upon successful >signaling of the join or graft. This requires a leaf node to send the JOIN >request all the way to the sender. We think your proposed solution is one of the solutions for race condition. But we think your proposed solution is not suitable in terms of scalability and processing speed. In your proposed design, all of the node must process a new Path message to prune the partial sub-tree. This means that the information of sub-tree must be processed at every intermediate node which have no relation to this partial sub-tree. And we cannot expect quick prune operation of partial sub-tree in this design. #Quick prune operation is important for first path recovery application. Our prune process also can solve this race condition In our design, Graft/Prune/Join/Leave message take precedence over Path refresh message. This means that the Prune node does not send Path messages to the pruned sub-tree in case the contents of TERO in the Path refresh message specifies this sub-tree. Note that we must send Graft message if we want to re-establish pruned sub-tree. Therefore, our proposed mechanism can prevent racing problem. And because those messages are not process at unrelated intermediate nodes, our process can attain quick Graft/Prune operation in a scalable manner. I >4. In figure 14, at the bottom, why is a PATH message being sent from node A >to node B? Is this a typo? Yes, this is a typo. >5. Instead of sending an ADD message for MP-to-MP, why not send a PATH >message that has the 2 new objects in the ADD message? Add message has different function from Path message. So we define new Add message. Do you think Path message with 2 new object is better than Add message ? >6. On page 36, last paragraph, the TERO is included in the PATH_TEAR >message, but the contents of the PATH_TEAR message was not shown to contain >the TERO. Though Path_Tear has the TERO, massage format of Path_Tear in page 22 is lack of TERO. This is typo. We will modify Path_Tear message format in next version. >7. In figure 7, on GRAFT mechanism, does GRAFT mechanism require that node E >was already a branch point? I think yes, otherwise data won't be sent from >node B to the node E sub-tree until sender node A updates the TERO and B >sends a PATH to E and E sends a RESV to B. No, any nodes within the multicast LSP can become graft node in our proposal. Please note that multicast LSP is already established between nodeA, B, D, E, C before node A send a Graft message to node E in figure 7. >8. Can a node be both a leaf and a branch? If yes, how does a node know >that it is both? > We think it is better for a node to be both a leaf and a branch. We think some dicussions are already made in draft-ietf-mpls-multicast-08.txt. We can realize this by adding identification bits in TERO. This identification bits indicate placement (1. Leaf 2. branch 3. Both) of the node. By using this TERO in Path message, we can setup a node to be both a leaf and a branch. We think some another discussion is necessary to realize this mechanism. Seisho From owner-mpls@UU.NET Thu Jul 4 13:45:58 2002 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 ESMTP id NAA21958 for ; Thu, 4 Jul 2002 13:45:58 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbv14981 for ; Thu, 4 Jul 2002 17:46:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwbv13364; Thu, 4 Jul 2002 17:46:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwbv11149 for mpls-outgoing; Thu, 4 Jul 2002 17:45:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwbv11142 for ; Thu, 4 Jul 2002 17:45: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 QQmwbv02244 for ; Thu, 4 Jul 2002 17:45:07 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwbv15119 for ; Thu, 4 Jul 2002 17:45:06 GMT Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmwbv15091 for ; Thu, 4 Jul 2002 17:45:06 GMT Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jul 2002 18:45:09 +0100 Message-ID: To: giles@packetexchange.net Cc: mpls@UU.NET Subject: RE: your mail Date: Thu, 4 Jul 2002 18:44:50 +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 Thanks Giles, but I am still missing the explanation to the points below. regards, Neil > > NH=> Can you explain the difference between an MPLS tunnel > and an LSP please? > > BTW - How does VoverMPLS fit with all this? From owner-mpls@UU.NET Fri Jul 5 00:56:01 2002 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 ESMTP id AAA03130 for ; Fri, 5 Jul 2002 00:56:01 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwdn08811 for ; Fri, 5 Jul 2002 04:56:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwdn06885; Fri, 5 Jul 2002 04:55:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwdn04047 for mpls-outgoing; Fri, 5 Jul 2002 04:55:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwdn04042 for ; Fri, 5 Jul 2002 04:55:29 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 QQmwdn19121 for ; Fri, 5 Jul 2002 04:55:17 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwdn06444 for ; Fri, 5 Jul 2002 04:55:17 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQmwdn06432 for ; Fri, 5 Jul 2002 04:55:16 GMT Received: from juniper.net (pptp043.static.jnpr.net [172.24.248.43]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g654tFm27324; Thu, 4 Jul 2002 21:55:15 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3D2526D6.4040601@juniper.net> Date: Thu, 04 Jul 2002 21:55:50 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Doug Degan CC: mpls@UU.NET Subject: Re: FRR question References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit During fast-reroute, when a PLR gets a PathTear from upstream, it propagates the tear-down messages downstream, and kills off the entire session. If a LSR does not support fast reroute, and something bad has happened.... tough luck! :-) - Ping Doug Degan wrote: > suppose a router along the path of a protected LSP gets PATH_TEAR > > should it propagate it and remove this LSP? > > does he know if it came from Ingress due to user configuration ? > > > > I remind you it might be that the previous router doesn't support FRR > and sends the TEAR due to incoming interface failure. > > > > > > thanks doug. > From owner-mpls@UU.NET Fri Jul 5 04:44:44 2002 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 ESMTP id EAA15263 for ; Fri, 5 Jul 2002 04:44:43 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwed24627 for ; Fri, 5 Jul 2002 08:45:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwec21674; Fri, 5 Jul 2002 08:44:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwec18818 for mpls-outgoing; Fri, 5 Jul 2002 08:43:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwec18813 for ; Fri, 5 Jul 2002 08:43:49 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 QQmwec21584 for ; Fri, 5 Jul 2002 08:43:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwec11506 for ; Fri, 5 Jul 2002 08:43:16 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmwec11495 for ; Fri, 5 Jul 2002 08:43:15 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17QOgL-0003Kw-00; Fri, 05 Jul 2002 09:43:13 +0100 Subject: RE: your mail From: Giles Heron To: neil.2.harrison@bt.com Cc: mpls@UU.NET In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 05 Jul 2002 09:43:13 +0000 Message-Id: <1025862193.1448.12.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2002-07-04 at 17:44, neil.2.harrison@bt.com wrote: > Thanks Giles, but I am still missing the explanation to the points below. > regards, Neil > > > > NH=> Can you explain the difference between an MPLS tunnel > > and an LSP please? none, whatsoever - just my sloppy wording. In draft-martini a "tunnel label" is the outer label associated with the LSP from PE to PE. A "VC label" is the label used to associate the traffic with a given PseudoWire. my contention is that if you *only* have a "tunnel label" (or whatever you should choose to call it) then the client should be IP. > > > BTW - How does VoverMPLS fit with all this? what is VoMPLS? I'd say VoIPoMPLS is a far more likely scenario - at least in the IETF view of the world! If any other organisation chooses to specify a VoMPLS solution that doesn't use IP or a label stack then I'd suggest they don't really "get" MPLS. Giles > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Fri Jul 5 06:24:54 2002 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 ESMTP id GAA16573 for ; Fri, 5 Jul 2002 06:24:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwej29488 for ; Fri, 5 Jul 2002 10:25:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwej27366; Fri, 5 Jul 2002 10:24:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwej10655 for mpls-outgoing; Fri, 5 Jul 2002 10:24:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwej10650 for ; Fri, 5 Jul 2002 10:24:08 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 QQmwej04584 for ; Fri, 5 Jul 2002 10:23:55 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwej27072 for ; Fri, 5 Jul 2002 10:23:55 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmwej27061 for ; Fri, 5 Jul 2002 10:23:54 GMT Received: from utfors.se ([195.58.105.116]) by blooper.utfors.se (Utfors AB) with ESMTP id g65AN3qo017975; Fri, 5 Jul 2002 12:23:03 +0200 (MEST) Message-ID: <3D257387.6080406@utfors.se> Date: Fri, 05 Jul 2002 12:23:03 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: agenda@ietf.org, MPLS wg CC: George Swallow , Scott Bradner , "Wijnen, Bert (Bert)" , Loa Andersson Subject: Draft MPLS agenda for the MPLS wg in Yokohama Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Draft Agenda for MPLS WG at the Yokohama meeting THURSDAY, July 18, 2002 0900-1130 Agenda bashing 10 min Loa and Bob: LDP to draft standard (status) 10 min S Bradner : Current state of the issues in the mpls oam discussion and the ITU-T liasion. 15 min S Bradner: rsvp-te vs. cr-ldp, initiating a discussion 15 min B Wijnen Status and issues with the mpls mibs 20 min B Jensen: General Summary of Interoperability Testing Results and Experiences reading 20 min Kireeti/Ben MTU Signalling Extensions for LDP 10 min A Malis Status of LDP restart and LDP fault tolerance drafts reading Fault Tolerance for LDP and CR-LDP Graceful Restart Mechanism for LDP Note: For the folling drafts it needs to be stated if you are proposing new work for the wg and why you think it should be undrtaken, and whether it i within charter or if the charter changes are needed. J-P Vasseur MPLS Traffic Engineering Fast reroute: backup tunnel path computationfor bandwidth protection 15 min Sven van den Bosch Further considerations for Forwarding Adjacency LSPs 10 min Yasukawa Extended RSVP-TE for Multicast LSP Tunnels 10 min H Hummel: "Hierarchical LSP" 10 min Loa: WG and document status, Questions 10 min 11.30 End of meeting To those of you that have agenda items, plese check that references are correct. For those of you that thought you requested agenda items and is not on the agenda, please let us know. There is also a web-based version of the agenda with "clickable" refrences at: http://62.119.0.68/~loa/mpls_agenda_for_yokohama.htm /Loa and George -- 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 Jul 8 06:41:55 2002 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 ESMTP id GAA09860 for ; Mon, 8 Jul 2002 06:41:55 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwpm08786 for ; Mon, 8 Jul 2002 10:42:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwpm05331; Mon, 8 Jul 2002 10:41:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwpm14900 for mpls-outgoing; Mon, 8 Jul 2002 10:40:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwpm14893 for ; Mon, 8 Jul 2002 10:40: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 QQmwpm12470 for ; Mon, 8 Jul 2002 10:40:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwpm05126 for ; Mon, 8 Jul 2002 10:40:36 GMT Received: from dharti.aplion.stpn.soft.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmwpm05092 for ; Mon, 8 Jul 2002 10:40:32 GMT Received: from cyborg (IDENT:root@localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g68AgeN05476 for ; Mon, 8 Jul 2002 16:12:40 +0530 Reply-To: From: "Mayank Kumar" To: Subject: do we need to have disjoint label space for cr-ldp and rsvp-te Date: Mon, 8 Jul 2002 16:13:30 +0530 Message-ID: <007501c2266c$4d503220$feca64c0@cyborg> 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 hi 1: i wanted to know that do we need to support disjoint label spaces for cr-ldp and rsvp-te in case of their simultaneous operations. If yes , then what is the reason for this ??? 2:is there a specific reason for having interface specific label space for atm and frame relay ???? What is the most basic reason for going for interface specifc label space ??? can a interface like atm which supports interface specifc label space , be not assigned a label from the platform wide label space. thanks and regards From owner-mpls@UU.NET Mon Jul 8 08:37:11 2002 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 ESMTP id IAA12163 for ; Mon, 8 Jul 2002 08:37:10 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwpu09409 for ; Mon, 8 Jul 2002 12:37:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwpu06664; Mon, 8 Jul 2002 12:36:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwpu07968 for mpls-outgoing; Mon, 8 Jul 2002 12:36:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwpu07921 for ; Mon, 8 Jul 2002 12:36:08 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 QQmwpu29634 for ; Mon, 8 Jul 2002 12:35:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwpu25509 for ; Mon, 8 Jul 2002 12:35:32 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmwpu25499 for ; Mon, 8 Jul 2002 12:35:32 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 08:35:31 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267115@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Loa Andersson'" , MPLS wg Cc: George Swallow , Martin Dubuc Subject: RE: wg last call - draft-ietf-mpls-bundle-mib-03.txt Date: Mon, 8 Jul 2002 08:35:30 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA12163 Loa, This is a lousy week for a one week last call... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Loa Andersson [mailto:loa.andersson@utfors.se] Sent: Thursday, July 04, 2002 5:50 AM To: MPLS wg Cc: George Swallow; Martin Dubuc Subject: wg last call - draft-ietf-mpls-bundle-mib-03.txt This message initiates a one week WG last call on: Link Bundling Management Information Base Please send your comments to the mailing list. The draft has been thorugh an earlier wg last and been updated according to comments in that last call, however the changes has been of such a nature that we want to make this last call on the entire draft. Note: This draft uses a MIB boilerplate that will be changed, this will however be taken care of in the the editorial process. This wg last call ends July 12, 2002 at 2400 GMT. /Loa and George -- 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 Jul 8 09:52:36 2002 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 ESMTP id JAA14667 for ; Mon, 8 Jul 2002 09:52:35 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwpz26552 for ; Mon, 8 Jul 2002 13:53:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwpz24470; Mon, 8 Jul 2002 13:52:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwpz06200 for mpls-outgoing; Mon, 8 Jul 2002 13:52:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmwpz06195 for ; Mon, 8 Jul 2002 13:52:09 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 QQmwpz18087 for ; Mon, 8 Jul 2002 13:51:38 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwpz24033 for ; Mon, 8 Jul 2002 13:51:38 GMT Received: from india.mercurykr.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQmwpz24011 for ; Mon, 8 Jul 2002 13:51:34 GMT Received: from amar (ptil-197-143-del.primus-india.net [203.196.143.197] (may be forged)) by india.mercurykr.com (8.11.2/8.11.2) with SMTP id g68DSLo05042; Mon, 8 Jul 2002 18:58:23 +0530 Message-ID: <001501c22686$1f86db40$c58fc4cb@dti.daewoo.co.kr> From: "Amarendra" To: , References: <007501c2266c$4d503220$feca64c0@cyborg> Subject: Re: do we need to have disjoint label space for cr-ldp and rsvp-te Date: Mon, 8 Jul 2002 19:18:14 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Please read inline comments. ----- Original Message ----- From: "Mayank Kumar" To: Sent: Monday, July 08, 2002 4:13 PM Subject: do we need to have disjoint label space for cr-ldp and rsvp-te > hi > 1: i wanted to know that do we need to support disjoint label spaces for > cr-ldp and rsvp-te in case of their simultaneous operations. > If yes , then what is the reason for this ??? ***: No you don't need to have disjoint label space for different label distribution protocols, if you have a central entity responsible for assigning different labels to different protocols. Otherwise you need to. > 2:is there a specific reason for having interface specific label space for > atm and frame relay ???? ***:In the cassse of ATM and Frame realy we encapsulate label in L2 header, e.g in the case of ATM we use VPI/VCI field of ATM header for label. > What is the most basic reason for going for interface specifc label space > ??? > can a interface like atm which supports interface specifc label space , be > not assigned a label from the platform wide label space. >** No. > > thanks > and regards > From owner-mpls@UU.NET Mon Jul 8 10:10:47 2002 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 ESMTP id KAA15490 for ; Mon, 8 Jul 2002 10:10:47 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqa12023 for ; Mon, 8 Jul 2002 14:11:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqa09719; Mon, 8 Jul 2002 14:10:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqa28633 for mpls-outgoing; Mon, 8 Jul 2002 14:10:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwqa28612 for ; Mon, 8 Jul 2002 14:10: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 QQmwqa19451 for ; Mon, 8 Jul 2002 14:09:32 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqa06479 for ; Mon, 8 Jul 2002 14:09:32 GMT Received: from dharti.aplion.stpn.soft.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmwqa06379 for ; Mon, 8 Jul 2002 14:09:23 GMT Received: from cyborg (IDENT:root@localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g68EBCM13065; Mon, 8 Jul 2002 19:41:12 +0530 Reply-To: From: "Mayank Kumar" To: "'Amarendra'" Cc: Subject: RE: do we need to have disjoint label space for cr-ldp and rsvp-te Date: Mon, 8 Jul 2002 19:42:06 +0530 Message-ID: <008301c22689$71c97b80$feca64c0@cyborg> 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: <001501c22686$1f86db40$c58fc4cb@dti.daewoo.co.kr> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi got answer for my first question:- but then the answer to my second ques, does not give me a good reason. Why is it necessary to have interface specific labels for atm or frame relay??? how does it matter that , we have the label encapuslated in the L2 header in case of atm or frame-relay.Am i missing something in saying that ,we can always assign a label from the platform wide label space , as long as that label confirms to be a valid dlci (for frame-relay) or a valid vpi/vci air( for atm). regds Mayank Please read inline comments. ----- Original Message ----- From: "Mayank Kumar" To: Sent: Monday, July 08, 2002 4:13 PM Subject: do we need to have disjoint label space for cr-ldp and rsvp-te > hi > 1: i wanted to know that do we need to support disjoint label spaces for > cr-ldp and rsvp-te in case of their simultaneous operations. > If yes , then what is the reason for this ??? ***: No you don't need to have disjoint label space for different label distribution protocols, if you have a central entity responsible for assigning different labels to different protocols. Otherwise you need to. > 2:is there a specific reason for having interface specific label space for > atm and frame relay ???? ***:In the cassse of ATM and Frame realy we encapsulate label in L2 header, e.g in the case of ATM we use VPI/VCI field of ATM header for label. > What is the most basic reason for going for interface specifc label space > ??? > can a interface like atm which supports interface specifc label space , be > not assigned a label from the platform wide label space. >** No. > > thanks > and regards > From owner-mpls@UU.NET Mon Jul 8 10:51:16 2002 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 ESMTP id KAA17660 for ; Mon, 8 Jul 2002 10:51:15 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqd09602 for ; Mon, 8 Jul 2002 14:52:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqd07378; Mon, 8 Jul 2002 14:51:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqd03145 for mpls-outgoing; Mon, 8 Jul 2002 14:50:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwqd03140 for ; Mon, 8 Jul 2002 14:50: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 QQmwqd27409 for ; Mon, 8 Jul 2002 14:49:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqd03533 for ; Mon, 8 Jul 2002 14:49:39 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 QQmwqd03529 for ; Mon, 8 Jul 2002 14:49:38 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 KAA02689 for ; Mon, 8 Jul 2002 10:49:36 -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 KAA03362 for ; Mon, 8 Jul 2002 10:49:36 -0400 (EDT) Message-ID: <3D29A69F.8020609@marconi.com> Date: Mon, 08 Jul 2002 10:50:07 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: your mail References: <1117F7D44159934FB116E36F4ABF221B02267112@celox-ma1-ems1.celoxnetworks.com> <1025786730.2948.88.camel@gizpad> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Giles Heron wrote: > > I'd hope that there is no intention to specify anything other than IPv4 > or v6 running directly over MPLS. You're confusing the specification with current implementations. This is a very very dangerous assumption to make. RSVP-TE explicitly defines the L3PID field of the LABEL_REQUEST object so that many layer-3 protocols may be run through LSPs. The Martini draft defines a mechanism for running all kinds of different layers through LSPs. There are also some proprietary mechanisms for running layer-2 traffic through LSPs. > MPLS is, after all, not a layer in > its own right (but let's not have that debate again!) Whether you want to call it a layer or not is irrelevant. The fact is that MPLS is specified to support non-IP traffic on the data plane, and there are implementations that are supporting this. If your implementation's design breaks non-IP traffic flows, then your implementation's design is broken. -- David From owner-mpls@UU.NET Mon Jul 8 11:01:43 2002 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 ESMTP id LAA18164 for ; Mon, 8 Jul 2002 11:01:42 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqe22414 for ; Mon, 8 Jul 2002 15:02:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqe19678; Mon, 8 Jul 2002 15:01:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqe06995 for mpls-outgoing; Mon, 8 Jul 2002 15:00:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwqe06754 for ; Mon, 8 Jul 2002 15:00: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 QQmwqd24184 for ; Mon, 8 Jul 2002 14:59:00 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqd18103 for ; Mon, 8 Jul 2002 14:58:59 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 QQmwqd18094 for ; Mon, 8 Jul 2002 14:58: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 KAA03799 for ; Mon, 8 Jul 2002 10:58:57 -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 KAA06327 for ; Mon, 8 Jul 2002 10:58:58 -0400 (EDT) Message-ID: <3D29A8D1.8090108@marconi.com> Date: Mon, 08 Jul 2002 10:59:29 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: do we need to have disjoint label space for cr-ldp and rsvp-te References: <008301c22689$71c97b80$feca64c0@cyborg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mayank Kumar wrote: > but then the answer to my second ques, does not give me a good reason. Why > is it necessary to have interface specific labels for atm or frame relay??? > how does it matter that , we have the label encapuslated in the L2 header in > case of atm or frame-relay.Am i missing something in saying that ,we can > always assign a label from the platform wide label space , as long as that > label confirms to be a valid dlci (for frame-relay) or a valid vpi/vci > air( for atm). The nature of ATM is to assign VCIDs on a per-interface basis. No existing ATM switch supports the concept of per-platform VCIDs, because doing so would break all of the ATM protocols. Since ATM switches, and by extensions ATM interfaces, all use per-interface VCIDs, it makes no sense to specify per-platform labels for these interfaces. You'll just end up specifying something that will never be implemented. I assume a similar argument holds for FR. And, as was already said, label spaces for ATM and FR are fundamentally different from shim-label label spaces. Shim-header label spaces use a 20-bit integer for a label. FR uses two different size DLCIs, neither of which is 20 bits - and there are per-interface range limits. ATM uses the two-dimensional VPI/VCI values, where VPI may be two different widths, and there are per-interface range limits on each dimension. Trying to combine all three of these incompatible technologies into one huge pool of labels is asking for disaster. -- David From owner-mpls@UU.NET Mon Jul 8 11:31:37 2002 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 ESMTP id LAA19860 for ; Mon, 8 Jul 2002 11:31:37 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqg14251 for ; Mon, 8 Jul 2002 15:32:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqf04683; Mon, 8 Jul 2002 15:28:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqf28182 for mpls-outgoing; Mon, 8 Jul 2002 15:27:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwqf28177 for ; Mon, 8 Jul 2002 15:27:57 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 QQmwqf09500 for ; Mon, 8 Jul 2002 15:27:30 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqf14290 for ; Mon, 8 Jul 2002 15:27:30 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmwqf14286 for ; Mon, 8 Jul 2002 15:27:29 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17RaQC-0005KB-00; Mon, 08 Jul 2002 16:27:28 +0100 Subject: Re: your mail From: Giles Heron To: David Charlap Cc: IETF MPLS List In-Reply-To: <3D29A69F.8020609@marconi.com> References: <1117F7D44159934FB116E36F4ABF221B02267112@celox-ma1-ems1.celoxnetworks.com> <1025786730.2948.88.camel@gizpad> <3D29A69F.8020609@marconi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 08 Jul 2002 16:27:26 +0000 Message-Id: <1026145647.1456.35.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-07-08 at 14:50, David Charlap wrote: > Giles Heron wrote: > > > > I'd hope that there is no intention to specify anything other than IPv4 > > or v6 running directly over MPLS. > > You're confusing the specification with current implementations. This > is a very very dangerous assumption to make. > > RSVP-TE explicitly defines the L3PID field of the LABEL_REQUEST object > so that many layer-3 protocols may be run through LSPs. The Martini > draft defines a mechanism for running all kinds of different layers > through LSPs. There are also some proprietary mechanisms for running > layer-2 traffic through LSPs. [rest snipped] LDP load balancing doesn't apply in the RSVP-TE case. And as a co-author of draft-martini I think it is safe to say that I understand how it works ;-) draft-martini allows indeed allows different types of traffic to be run over LSPs, however it does this by means of a label stack. Except in the case of the final hop when running PHP there is always a 2 or more label stack for draft-martini. The one proprietary mechanism I am aware of for L2 over MPLS relies on RSVP-TE, so again LDP load balancing is moot. Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Jul 8 11:44:55 2002 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 ESMTP id LAA20448 for ; Mon, 8 Jul 2002 11:44:54 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqh25300 for ; Mon, 8 Jul 2002 15:45:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqg23058; Mon, 8 Jul 2002 15:44:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqg29272 for mpls-outgoing; Mon, 8 Jul 2002 15:44:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmwqg29265 for ; Mon, 8 Jul 2002 15:44:31 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 QQmwqg29028 for ; Mon, 8 Jul 2002 15:43:19 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqg22260 for ; Mon, 8 Jul 2002 15:43:19 GMT Received: from dharti.aplion.stpn.soft.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmwqg22212 for ; Mon, 8 Jul 2002 15:43:16 GMT Received: from cyborg (IDENT:root@localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g68FjUO15609 for ; Mon, 8 Jul 2002 21:15:30 +0530 Reply-To: From: "Mayank Kumar" To: "Mpls \(E-mail\)" Subject: LER and LSR issue Date: Mon, 8 Jul 2002 21:16:25 +0530 Message-ID: <008501c22696$9eb90270$feca64c0@cyborg> 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 Hi We are implementing a edge router which is going to sit at the edge of Service Providers network. Can anybody advice that, is it worth the effort to implement a LSR's functionality also or only the LER functionality will be enough??? I mean processing of ILM's also instead of just FTN's ??? Also does anybody know of mpls implementations in routers from some vendors (eg cisco,juniper,nortel,etc) where only the LER functionality has been implemented. Also how much extra effort and in terms of what ??? (memory , processsing power, or functionality) is to be made for implementing both. Please reply with some level of detail. thanks in advance. regds Mayank From owner-mpls@UU.NET Mon Jul 8 11:47:19 2002 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 ESMTP id LAA20639 for ; Mon, 8 Jul 2002 11:47:19 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqh00606 for ; Mon, 8 Jul 2002 15:48:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqh24125; Mon, 8 Jul 2002 15:45:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqg29285 for mpls-outgoing; Mon, 8 Jul 2002 15:44:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwqg29280 for ; Mon, 8 Jul 2002 15:44: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 QQmwqg19099 for ; Mon, 8 Jul 2002 15:44:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqg23435 for ; Mon, 8 Jul 2002 15:44:36 GMT Received: from dharti.aplion.stpn.soft.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmwqg23380 for ; Mon, 8 Jul 2002 15:44:32 GMT Received: from cyborg (IDENT:root@localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g68FY2415288; Mon, 8 Jul 2002 21:04:02 +0530 Reply-To: From: "Mayank Kumar" To: "'David Charlap'" Cc: Subject: RE: do we need to have disjoint label space for cr-ldp and rsvp-te Date: Mon, 8 Jul 2002 21:04:57 +0530 Message-ID: <008401c22695$04cad720$feca64c0@cyborg> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3D29A8D1.8090108@marconi.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi ur argument makes sense. Thank you . But i do not understand what do you mean by VCID's. Is it some combination of VPI and VCI . The CISCO shows some vcid kind of thing in its 'show atm vc' command. When u say that VCID's are allocated on aper interface basis , do u mean that vcid's are unique for a specific interface only and thus there can be two identical VCID's on two different atm interfaces or for that matter ports. Then it makes sense to not assign atm vpi/vci (labels) from a platform wide label space. Also then i can infer one more thing that, the platform wide label space contains only shim-labels (that means the generic encapsulation specified in rfc 3032). Also the pw wide label space contains just the 20 bit labels . It does not make sense that the label space contain the 3 bit EXP and the S and the TTl fields too. regds Mayank -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David Charlap Sent: Monday, July 08, 2002 8:29 PM To: IETF MPLS List Subject: Re: do we need to have disjoint label space for cr-ldp and rsvp-te Mayank Kumar wrote: > but then the answer to my second ques, does not give me a good reason. Why > is it necessary to have interface specific labels for atm or frame relay??? > how does it matter that , we have the label encapuslated in the L2 header in > case of atm or frame-relay.Am i missing something in saying that ,we can > always assign a label from the platform wide label space , as long as that > label confirms to be a valid dlci (for frame-relay) or a valid vpi/vci > air( for atm). The nature of ATM is to assign VCIDs on a per-interface basis. No existing ATM switch supports the concept of per-platform VCIDs, because doing so would break all of the ATM protocols. Since ATM switches, and by extensions ATM interfaces, all use per-interface VCIDs, it makes no sense to specify per-platform labels for these interfaces. You'll just end up specifying something that will never be implemented. I assume a similar argument holds for FR. And, as was already said, label spaces for ATM and FR are fundamentally different from shim-label label spaces. Shim-header label spaces use a 20-bit integer for a label. FR uses two different size DLCIs, neither of which is 20 bits - and there are per-interface range limits. ATM uses the two-dimensional VPI/VCI values, where VPI may be two different widths, and there are per-interface range limits on each dimension. Trying to combine all three of these incompatible technologies into one huge pool of labels is asking for disaster. -- David From owner-mpls@UU.NET Mon Jul 8 12:15:02 2002 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 ESMTP id MAA22450 for ; Mon, 8 Jul 2002 12:15:02 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqj10395 for ; Mon, 8 Jul 2002 16:15:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqi07706; Mon, 8 Jul 2002 16:14:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqi23683 for mpls-outgoing; Mon, 8 Jul 2002 16:14:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwqi23678 for ; Mon, 8 Jul 2002 16:14: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 QQmwqi28572 for ; Mon, 8 Jul 2002 16:12:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqi20721 for ; Mon, 8 Jul 2002 16:12:19 GMT Received: from exchange.tropicnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50]) id QQmwqi20704 for ; Mon, 8 Jul 2002 16:12:18 GMT Received: from tropicnetworks.com ([10.1.5.113]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 8 Jul 2002 12:12:15 -0400 Message-ID: <3D29B9DF.CA68F8EF@tropicnetworks.com> Date: Mon, 08 Jul 2002 12:12:15 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: pingpan@juniper.net Subject: LSP Liveliness Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2002 16:12:15.0745 (UTC) FILETIME=[39DDC710:01C2269A] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I noticed that MPLS OAM is again on the agenda for the Yokohama meeting. I'm reposting certain issues and questions relating to the LSP liveliness draft and hoping to hear from the authors and others on the list. 1. Suggest finding a better name for this application than "MPLS Ping". This is for two reasons. First, the app can actually operate in both Ping and TraceRoute modes and 2nd, vendors have icmp echo req and reply running over lsps and sometimes call that lsp ping which is easily confusable with mpls ping. Maybe something like MPLS liveliness or another new term would solve this problem? 2. Why not consider adding a reply mode of ICMP. 3. Why not consider adding a reply mode of bi-directional lsp? i.e for the case of bi-dir lsps, why not try to return the pkt on the bi-dir lsp. 4. If implementing #3 above, suggest returning the labels in the reverse path of the bi-directional LSP. 5. Suggest changing section 3's packet format for the echo request as follows: a) Include an additional 32 bit field called the "identifier field" - this is the same as in ICMP ECHO REQUEST. This allows differentiation for the case of multiple processes. The source port is often used for this but this is only 16 bits while process ids in many OSs are 32bits. Having a separate clear identifier field removes the ambiguity associated with this. 6. Section 5 is essentially the content of v02 of the draft. In that version there was a paragraph or two that explained that there have been previously identified cases where the control plane of an LSP was up (ie PATH and RESV messages were continually refreshed) while packets on the dataplane for that lsp went into a black-hole. It is for precisely this kind of scenario that section 5 is able to provide a solution. I think that such kind of content would be useful to include in this section again. Best, Nabil Seddigh nseddigh@tropicnetworks.com From owner-mpls@UU.NET Mon Jul 8 12:18:10 2002 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 ESMTP id MAA22624 for ; Mon, 8 Jul 2002 12:18:09 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqj27949 for ; Mon, 8 Jul 2002 16:19:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqj26427; Mon, 8 Jul 2002 16:18:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqj24481 for mpls-outgoing; Mon, 8 Jul 2002 16:18:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwqj24457 for ; Mon, 8 Jul 2002 16:17: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 QQmwqj02119 for ; Mon, 8 Jul 2002 16:17:25 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqj13807 for ; Mon, 8 Jul 2002 16:17: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 QQmwqj13422 for ; Mon, 8 Jul 2002 16:17:13 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 MAA10754 for ; Mon, 8 Jul 2002 12:17: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 MAA23931 for ; Mon, 8 Jul 2002 12:17:11 -0400 (EDT) Message-ID: <3D29BB26.8070307@marconi.com> Date: Mon, 08 Jul 2002 12:17:42 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: do we need to have disjoint label space for cr-ldp and rsvp-te References: <008401c22695$04cad720$feca64c0@cyborg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mayank Kumar wrote: > ur argument makes sense. Thank you . But i do not understand what do you > mean by VCID's. Is it some combination of VPI and VCI. Yes. It's the combined VPI/VCI value that represents a single ATM connection. > When u say that VCID's are > allocated on aper interface basis , do u mean that vcid's are unique for a > specific interface only and thus there can be two identical VCID's on two > different atm interfaces or for that matter ports. Yes. The same VCID can exist on two different ports. When this happens, there is absolutely no relationship between the two connections. > Also then i can infer one more thing that, the platform wide label space > contains only shim-labels (that means the generic encapsulation specified in > rfc 3032). Also the pw wide label space contains just the 20 bit labels . This is my understanding. If platform-wide labels are implemented on a platform, then they are used only on interfaces where shim headers are used to store the label. And shim headers only store 20-bit labels. > It does not make sense that the label space contain the 3 bit EXP and the S > and the TTl fields too. EXP and TTL fields are not part of the labels. While your forwarding hardware may manipulate all three of these, they serve different purposes. Labels serve to identify the route from ingress to egress (and may also identify QoS, in the case of an IntServ LSP or a DiffServ L-LSP.) The EXP bits serve to identify the QoS in the case of a DiffServ E-LSP. The TTL is decremented as packets are forwarded and only affects traffic flow if it decrements to zero. -- David From owner-mpls@UU.NET Mon Jul 8 12:40:51 2002 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 ESMTP id MAA23806 for ; Mon, 8 Jul 2002 12:40:51 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqk29761 for ; Mon, 8 Jul 2002 16:41:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqk26844; Mon, 8 Jul 2002 16:40:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqk25886 for mpls-outgoing; Mon, 8 Jul 2002 16:39:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwqk25881 for ; Mon, 8 Jul 2002 16:39: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 QQmwqk29720 for ; Mon, 8 Jul 2002 16:39:43 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqk21228 for ; Mon, 8 Jul 2002 16:39:43 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 QQmwqk21218 for ; Mon, 8 Jul 2002 16:39:42 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 MAA12222 for ; Mon, 8 Jul 2002 12:39: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 MAA28058 for ; Mon, 8 Jul 2002 12:39:42 -0400 (EDT) Message-ID: <3D29C06C.60905@marconi.com> Date: Mon, 08 Jul 2002 12:40:12 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: I-D ACTION:draft-yasukawa-mpls-rsvp-multicast-00.txt References: <200206271038.GAA08972@ietf.org> <4.3.2-J.20020701130120.00bc8c58@imc.m.ecl.ntt.co.jp> <4.2.0.58.J.20020704233928.021f3530@imc.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Seisho Yasukawa wrote: > David Charlap wrote: >> >> You mean the lack of explicit routes. TE is a very broad and vague term. > > Yes, I mean that we must add and define the explicit routes function to > existing RSVP-TE to enable multicast traffic engineering. I agree, that a definition for multicast EROs would be a good idea, although I think such an object will end up consuming a lot of bandwidth. A multicast tree, for a non-trivial network will consume hundreds, if not thousands of bytes. Considering that existing RSVP messages are on the order of 100-200 bytes, this is not something we can just gloss over. > We also want the scheme to rerouting the multicast traffic when some error occurs in the network. > Some multicast routing mechanism may find these error and find another available route finally. > But we think we need more reliable and faster rerouting mechanism in multicast environment. This is where I think you're reinventing the wheel. If there is a problem with existing multicast routing protocols, then I think everyone's effort is best spent trying to improve the routing protocols. I really don't like the idea of adding routing functionality into a signaling protocol. It makes everything much more complicated than it has to be. > We think that specifying an IP mulitcast group address as the tunnel > endpoint has completely different meaning compared with unicast case. > The unicast IP address is attached to physical IF or node and indicates > its physical location in the network. > Therefore, we can specify the tunnel endpoint by this address. > But multicast group address cannot specify the physical location. As a > result, we can not specify the tunnel endpoint by this address. The session address does more than identify an endpoint. It also serves as a key to group together multiple connections within a router. When you eliminate the field from the SESSION object, you end up deleting that key. The tunnel ID and sender address alone are not sufficient to completely specify a multicast session. I realize that you're only interested in point-to-multipoint, but I don't think it's right to declare that this is the one and only form of multicast that MPLS will be allowed to support. > In addition to this problem, it is not convenient to use single IP > multicast address because we cannot accommodate > several IP multicast group traffic and non-IP traffic in a single > multicast LSP tunnel. This doesn't follow. There is no reason why an IP destination address in RSVP must necessarily imply an IP payload in the LSP. There are many different mechanisms where you can specify non-IP payload, even though the endpoint address is IP. >> Note also that you will need _some_ mechanism for defining the >> endpoints of a multicast LSP. If you don't define an IP multicast >> group and have your egress routers all join that group, then you'll >> have to re-invent the wheel by replicating what existing multicast >> routing protocols already do. > > We define the endpoint of a multicast LSP by TERO and TRRO. Which completely redefines a key part of the RSVP protocol. The SESSION is supposed to define the endpoints. The ERO is supposed to be used to override the routing table, where that is necessary. With your draft, you change the semantics of RSVP so much that it isn't even the same protocol anymore. Your semantics are much closer to CR-LDP than they are to RSVP. >> There's no big deal if you want to define your own private multicast >> groups, for the purpose of establishing TE across your own routing >> core. Once the multicast LSPs are in place, you can then transit any >> traffic you want across it. >> >> Remember, you're not interested in setting up LSPs that run from a >> server to all of the millions of hosts receiving from that server. >> You're interested in setting up LSPs to efficiently transit multicast >> traffic to the edges of your network. This is especially true if >> you're talking about non-IP traffic. > > As mentioned above, we are not interested in shortest path tree that is > calculated by conventinal IP multicast routing protocol. > Although we define the private multicast group, we cannot still control > tree topology and multicast traffic across it. This is no different from unicast RSVP, where the ERO object overrides the local routing table. We don't eliminate the endpoint address from the SESSION object just because we're not using the routing table. In a unicast environment, the routing protocols continue to run as always. The ingress nodes use the routing table in order to detect tunnel endpoints, and to construct explicit routes to those endpoints. Multicast behavior can be similar. There is no reason why RSVP has to use the multicast routing table. The ingress nodes can use the multicast routing table to detect endpoints (where the tree leaves the MPLS cloud), and build a TERO based on those endpoints and the unicast routing table. No changes to RSVP, other than the TERO object are necessary for this. -- David From owner-mpls@UU.NET Mon Jul 8 13:22:19 2002 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 ESMTP id NAA26302 for ; Mon, 8 Jul 2002 13:22:18 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqn25089 for ; Mon, 8 Jul 2002 17:23:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqn23520; Mon, 8 Jul 2002 17:22:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqn21630 for mpls-outgoing; Mon, 8 Jul 2002 17:22:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmwqn21625 for ; Mon, 8 Jul 2002 17: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 QQmwqn10794 for ; Mon, 8 Jul 2002 17:21:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqn23737 for ; Mon, 8 Jul 2002 17:21:08 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQmwqn23716 for ; Mon, 8 Jul 2002 17:21:08 GMT Received: from juniper.net (pptp100.static.jnpr.net [172.24.248.100]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g68HL6m43339; Mon, 8 Jul 2002 10:21:06 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3D29CA27.2010308@juniper.net> Date: Mon, 08 Jul 2002 10:21:43 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Nabil Seddigh CC: mpls@UU.NET Subject: Re: LSP Liveliness References: <3D29B9DF.CA68F8EF@tropicnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Nabil Seddigh wrote: > I noticed that MPLS OAM is again on the agenda for the Yokohama > meeting. I'm reposting certain issues and questions relating > to the LSP liveliness draft and hoping to hear from the authors > and others on the list. > > 1. Suggest finding a better name for this application than > "MPLS Ping". This is for two reasons. First, the app can > actually operate in both Ping and TraceRoute modes and > 2nd, vendors have icmp echo req and reply running over lsps > and sometimes call that lsp ping which is easily confusable > with mpls ping. Maybe something like MPLS liveliness or > another new term would solve this problem? > The draft defines the concept and the protocol that are used for LSP monitoring, probing... etc. Depending on the implementation, we could have some commands such as lsping() and tracelsp(), etc. I don't think we should hang up on the naming here. :-) > 2. Why not consider adding a reply mode of ICMP. > Indeed, there is more than one way to transport requests and replies. We chosen UDP long time back based on our unfortunate experience in 'ICMP extension on MPLS'. As a result, IANA had assigned port number 3503 to us (http://www.iana.org/assignments/port-numbers). Actually, using UDP may be easier to implement. > 3. Why not consider adding a reply mode of bi-directional lsp? > i.e for the case of bi-dir lsps, why not try to return > the pkt on the bi-dir lsp. > There are multiple ways to reply the messages as being defined in the draft. One simple way is to reply via the regular IP; another is to use RSVP. If the providers want to set up bi-directional LSP's, we can certainly consider of using the bi-directional LSP for replies. Thanks! > 4. If implementing #3 above, suggest returning the labels > in the reverse path of the bi-directional LSP. > Sure. > 5. Suggest changing section 3's packet format for the > echo request as follows: > > a) Include an additional 32 bit field called the "identifier > field" - this is the same as in ICMP ECHO REQUEST. > This allows differentiation for the case of multiple > processes. The source port is often used for this but > this is only 16 bits while process ids in many OSs are > 32bits. Having a separate clear identifier field > removes the ambiguity associated with this. > In case of ICMP, yes, you need to put the pid in that field (or getpid() & 0xff :-)). For UDP, the source port number is sufficient here. As you may see here, with ICMP, the change in ICMP processing is not as straight-forward as UDP. :-) > 6. Section 5 is essentially the content of v02 of the draft. > In that version there was a paragraph or two that > explained that there have been previously identified cases > where the control plane of an LSP was up (ie PATH and RESV > messages were continually refreshed) while packets on the > dataplane for that lsp went into a black-hole. It is for > precisely this kind of scenario that section 5 is able > to provide a solution. I think that such kind of content > would be useful to include in this section again. > OK. Thanks! - Ping > Best, > Nabil Seddigh > nseddigh@tropicnetworks.com > > From owner-mpls@UU.NET Mon Jul 8 14:48:36 2002 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 ESMTP id OAA01744 for ; Mon, 8 Jul 2002 14:48:36 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqt07588 for ; Mon, 8 Jul 2002 18:49:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwqt04435; Mon, 8 Jul 2002 18:47:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwqt21859 for mpls-outgoing; Mon, 8 Jul 2002 18:47:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwqt21854 for ; Mon, 8 Jul 2002 18:47: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 QQmwqt03103 for ; Mon, 8 Jul 2002 18:47:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqt00011 for ; Mon, 8 Jul 2002 18:47:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmwqt29997 for ; Mon, 8 Jul 2002 18:47:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA14016 for ; Mon, 8 Jul 2002 14:47:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA29468 for mpls@uu.net; Mon, 8 Jul 2002 14:47:07 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwqt21817 for ; Mon, 8 Jul 2002 18:46: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 QQmwqt24774 for ; Mon, 8 Jul 2002 18:46:29 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwqt29772 for ; Mon, 8 Jul 2002 18:46:28 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmwqt29766 for ; Mon, 8 Jul 2002 18:46:28 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA13970; Mon, 8 Jul 2002 14:46:26 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA17687; Mon, 8 Jul 2002 14:46:22 -0400 (EDT) Message-Id: <200207081846.OAA17687@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: mpls wg cc: Loa Andersson Subject: Close of last call on LDP FT & Restart Drafts Date: Mon, 08 Jul 2002 14:46:22 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk The last calls on Fault Tolerance for LDP and CR-LDP Graceful Restart Mechanism for LDP ended July 5, 2002 at 2400 GMT. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Jul 8 18:28:19 2002 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 ESMTP id SAA14526 for ; Mon, 8 Jul 2002 18:28:19 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwrh27276 for ; Mon, 8 Jul 2002 22:29:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwrh24318; Mon, 8 Jul 2002 22:27:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwrh06789 for mpls-outgoing; Mon, 8 Jul 2002 22:27:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwrh06784 for ; Mon, 8 Jul 2002 22:27:41 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 QQmwrh10042 for ; Mon, 8 Jul 2002 22:26:58 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwrh19776 for ; Mon, 8 Jul 2002 22:26:58 GMT Received: from gateway.ipinfusion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.223.109.2]) id QQmwrh19771 for ; Mon, 8 Jul 2002 22:26:57 GMT Received: from ipinfusion.com ([10.10.0.225]) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id g68MQIH11247 for ; Mon, 8 Jul 2002 15:26:18 -0700 Message-ID: <3D2A1177.643A84FD@ipinfusion.com> Date: Mon, 08 Jul 2002 15:26:00 -0700 From: Yuan Gu Organization: IP Infusion Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: RFC3270 - error code for L-LSP? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: In RFC3270 section 5.3, page 39, the error code "Invalid EXP<-->PHB mapping"(instead of "Unsupported PHB") is defined for ELSP when the PHBID encoding is invalid in diffserv obj. My question is: if PHBID(PSC) encoding is invalid in LLSP diffserv obj, should we use "Unsupported PSC" error code or something else? Regards! Yuan From owner-mpls@UU.NET Tue Jul 9 02:47:49 2002 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 ESMTP id CAA13896 for ; Tue, 9 Jul 2002 02:47:49 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwsp10208 for ; Tue, 9 Jul 2002 06:48:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwsp06080; Tue, 9 Jul 2002 06:46:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwsp11018 for mpls-outgoing; Tue, 9 Jul 2002 06:46:20 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmwsp10914 for ; Tue, 9 Jul 2002 06:46:09 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 QQmwsp06339 for ; Tue, 9 Jul 2002 06:46:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwsp05563 for ; Tue, 9 Jul 2002 06:46:08 GMT Received: from dharti.aplion.stpn.soft.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmwsp05506 for ; Tue, 9 Jul 2002 06:46:05 GMT Received: from cyborg (IDENT:root@localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g696mJI07590 for ; Tue, 9 Jul 2002 12:18:19 +0530 Reply-To: From: "Mayank Kumar" To: "Mpls \(E-mail\)" Subject: FW: LER and LSR issue Date: Tue, 9 Jul 2002 12:19:16 +0530 Message-ID: <00b101c22714$bea94a30$feca64c0@cyborg> 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 Hi i have had no replies to my previous mail which is included below. If any body have some information , then please do reply on this. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mayank Kumar Sent: Monday, July 08, 2002 9:16 PM To: Mpls (E-mail) Subject: LER and LSR issue Hi We are implementing a edge router which is going to sit at the edge of Service Providers network. Can anybody advice that, is it worth the effort to implement a LSR's functionality also or only the LER functionality will be enough??? I mean processing of ILM's also instead of just FTN's ??? Also does anybody know of mpls implementations in routers from some vendors (eg cisco,juniper,nortel,etc) where only the LER functionality has been implemented. Also how much extra effort and in terms of what ??? (memory , processsing power, or functionality) is to be made for implementing both. Please reply with some level of detail. thanks in advance. regds Mayank From owner-mpls@UU.NET Tue Jul 9 04:55:58 2002 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 ESMTP id EAA16833 for ; Tue, 9 Jul 2002 04:55:58 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwsx06549 for ; Tue, 9 Jul 2002 08:56:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwsx27856; Tue, 9 Jul 2002 08:51:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwsx04540 for mpls-outgoing; Tue, 9 Jul 2002 08:51:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwsx04534 for ; Tue, 9 Jul 2002 08:51: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 QQmwsx14797 for ; Tue, 9 Jul 2002 08:51:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwsx22979 for ; Tue, 9 Jul 2002 08:51:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmwsx22971 for ; Tue, 9 Jul 2002 08:51:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id EAA28594 for ; Tue, 9 Jul 2002 04:51:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA22948 for mpls@uu.net; Tue, 9 Jul 2002 04:51:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmwsx04349 for ; Tue, 9 Jul 2002 08:50: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 QQmwsx27131 for ; Tue, 9 Jul 2002 08:49:33 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwsx22168 for ; Tue, 9 Jul 2002 08:49:33 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 QQmwsx22156 for ; Tue, 9 Jul 2002 08:49:32 GMT Received: from FLEFAUCH-W2K.cisco.com (dhcp-nic-val-26-117.cisco.com [64.103.26.117]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA22185; Tue, 9 Jul 2002 10:49:24 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020709103408.01cdeb20@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Jul 2002 10:39:47 +0200 To: Yuan Gu From: Francois Le Faucheur Subject: Re: RFC3270 - error code for L-LSP? Cc: mpls@UU.NET In-Reply-To: <3D2A1177.643A84FD@ipinfusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 15:26 08/07/2002 -0700, Yuan Gu wrote: >Hello: > > In RFC3270 section 5.3, page 39, the error code "Invalid EXP<-->PHB >mapping"(instead of "Unsupported PHB") is defined for ELSP when the >PHBID encoding is invalid in diffserv obj. My question is: if PHBID(PSC) >encoding is invalid in LLSP diffserv obj, should we use "Unsupported >PSC" error code Yes, I would suggest using "Unsupported PSC". We could add an "Invalid PSC encoding" error code in the future to disambiguate between the two cases of "bad" PSC. Francois >or something else? > >Regards! >Yuan From owner-mpls@UU.NET Tue Jul 9 09:06:45 2002 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 ESMTP id JAA23423 for ; Tue, 9 Jul 2002 09:06:45 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwto02272 for ; Tue, 9 Jul 2002 13:07:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwto29809; Tue, 9 Jul 2002 13:06:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwto12672 for mpls-outgoing; Tue, 9 Jul 2002 13:06:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwto12604 for ; Tue, 9 Jul 2002 13:06:11 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 QQmwto26422 for ; Tue, 9 Jul 2002 13:04:45 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwto22006 for ; Tue, 9 Jul 2002 13:04:44 GMT Received: from dharti.aplion.stpn.soft.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmwto21917 for ; Tue, 9 Jul 2002 13:04:40 GMT Received: from cyborg (IDENT:root@localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g69CmMs26041 for ; Tue, 9 Jul 2002 18:18:42 +0530 Reply-To: From: "Mayank Kumar" To: "Mpls \(E-mail\)" Subject: Handling of ipv4 packets that are too big Date: Tue, 9 Jul 2002 18:19:02 +0530 Message-ID: <00be01c22747$019071c0$feca64c0@cyborg> 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 hi Can any body tell me of the issues involved in providing both the functionalities of LER and LSR in an MPLS router. Other than the support required for ILM and there processing , what other issues are to be dealt with??? Also please somebody tell if there are implementations from mpls vendors of mpls routers where only the lsr or the ler functionality has been implmented ?? thanks and regds Mayank From owner-mpls@UU.NET Tue Jul 9 09:27:52 2002 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 ESMTP id JAA24242 for ; Tue, 9 Jul 2002 09:27:52 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwtp13641 for ; Tue, 9 Jul 2002 13:28:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwtp10766; Tue, 9 Jul 2002 13:27:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwtp15813 for mpls-outgoing; Tue, 9 Jul 2002 13:26:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmwtp15807 for ; Tue, 9 Jul 2002 13:26:46 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 QQmwtp13667 for ; Tue, 9 Jul 2002 13:26:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwtp10610 for ; Tue, 9 Jul 2002 13:26:44 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmwtp10606 for ; Tue, 9 Jul 2002 13:26:43 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 09:26:43 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267131@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'mkumar@aplion.stpn.soft.net'" Cc: "Mpls (E-mail)" Subject: RE: Handling of ipv4 packets that are too big Date: Tue, 9 Jul 2002 09:26:42 -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 Mayank, If a router has at least one MPLS interface and at least one non MPLS interface which it can route between, it has LER functionality. Any non MPLS interface over which IP packets may be sent (such as a local drop) qualifies. The simplest example of a strict LER implementation is one which has only one MPLS capable interface (it might be an uplink, for example). An LER might have more than one MPLS capable interface if it is not able to route between them. Otherwise, it is also an LSR. If a router has two or more MPLS interfaces which it can route between, it has LSR functionality. The simplest example of a strict LSR is one which has two MPLS interfaces and no non MPLS interfaces. Such a device is of doubtful utility. Hence, most boxes will incorporate both LER and LSR functionality, depending on installed interfaces. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] Sent: Tuesday, July 09, 2002 8:49 AM To: Mpls (E-mail) Subject: Handling of ipv4 packets that are too big hi Can any body tell me of the issues involved in providing both the functionalities of LER and LSR in an MPLS router. Other than the support required for ILM and there processing , what other issues are to be dealt with??? Also please somebody tell if there are implementations from mpls vendors of mpls routers where only the lsr or the ler functionality has been implmented ?? thanks and regds Mayank From owner-mpls@UU.NET Tue Jul 9 10:00:36 2002 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 ESMTP id KAA25666 for ; Tue, 9 Jul 2002 10:00:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwts07971 for ; Tue, 9 Jul 2002 14:01:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwtr04380; Tue, 9 Jul 2002 13:59:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwtr18186 for mpls-outgoing; Tue, 9 Jul 2002 13:59:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwtr18179 for ; Tue, 9 Jul 2002 13:59: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 QQmwtr20157 for ; Tue, 9 Jul 2002 13:58:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwtr04354 for ; Tue, 9 Jul 2002 13:58:37 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmwtr04347 for ; Tue, 9 Jul 2002 13:58:36 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 09:58:36 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267133@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'mkumar@aplion.stpn.soft.net'" Cc: "Mpls (E-mail)" Subject: RE: Handling of ipv4 packets that are too big Date: Tue, 9 Jul 2002 09:58:36 -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 Mayank, As a further note, I am somewhat guilty of oversimplifying in my previous message. Typical MPLS interfaces are capable of forwarding both labeled (MPLS) and unlabeled (IP) traffic. This is what distinguishes an LSR from what we used to refer to as an 'MPLS node'. It is also what an LSR must be able to do in order to be able to participate in routing (in anything more than a lame way). This opens the way to a lazy man's LSR - one which performs no ingress or egress functions but simply forwards packets as it receives them. I.e. labeled packets are forwarded labeled, unlabeled packets are forwarded unlabeled. There are many issues with such an implementation, since it can't provide or maintain labels for which it does not have downstream bindings. I believe such an LSR would be exceptionally fragile and unlikely to be of much use as a result - but I mention it mostly for completeness. While such an LSR might have both MPLS and non MPLS interfaces and still not have LER functionality, I do not know if such an LSR exists. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Gray, Eric [mailto:egray@celoxnetworks.com] Sent: Tuesday, July 09, 2002 9:27 AM To: 'mkumar@aplion.stpn.soft.net' Cc: Mpls (E-mail) Subject: RE: Handling of ipv4 packets that are too big Mayank, If a router has at least one MPLS interface and at least one non MPLS interface which it can route between, it has LER functionality. Any non MPLS interface over which IP packets may be sent (such as a local drop) qualifies. The simplest example of a strict LER implementation is one which has only one MPLS capable interface (it might be an uplink, for example). An LER might have more than one MPLS capable interface if it is not able to route between them. Otherwise, it is also an LSR. If a router has two or more MPLS interfaces which it can route between, it has LSR functionality. The simplest example of a strict LSR is one which has two MPLS interfaces and no non MPLS interfaces. Such a device is of doubtful utility. Hence, most boxes will incorporate both LER and LSR functionality, depending on installed interfaces. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] Sent: Tuesday, July 09, 2002 8:49 AM To: Mpls (E-mail) Subject: Handling of ipv4 packets that are too big hi Can any body tell me of the issues involved in providing both the functionalities of LER and LSR in an MPLS router. Other than the support required for ILM and there processing , what other issues are to be dealt with??? Also please somebody tell if there are implementations from mpls vendors of mpls routers where only the lsr or the ler functionality has been implmented ?? thanks and regds Mayank From owner-mpls@UU.NET Tue Jul 9 11:03:46 2002 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 ESMTP id LAA28219 for ; Tue, 9 Jul 2002 11:03:46 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwtw15077 for ; Tue, 9 Jul 2002 15:04:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwtw12429; Tue, 9 Jul 2002 15:03:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwtw26761 for mpls-outgoing; Tue, 9 Jul 2002 15:03:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmwtw26746 for ; Tue, 9 Jul 2002 15:03: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 QQmwtw00054 for ; Tue, 9 Jul 2002 15:02:32 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwtw11876 for ; Tue, 9 Jul 2002 15:02: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 QQmwtw11871 for ; Tue, 9 Jul 2002 15:02: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 LAA03357 for ; Tue, 9 Jul 2002 11:02: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 LAA28071 for ; Tue, 9 Jul 2002 11:02:29 -0400 (EDT) Message-ID: <3D2AFB28.7020705@marconi.com> Date: Tue, 09 Jul 2002 11:03:04 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Handling of ipv4 packets that are too big References: <1117F7D44159934FB116E36F4ABF221B02267133@celox-ma1-ems1.celoxnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gray, Eric wrote: > > This opens the way to a lazy man's LSR - one > which performs no ingress or egress functions but > simply forwards packets as it receives them. I.e. > labeled packets are forwarded labeled, unlabeled > packets are forwarded unlabeled. There are many > issues with such an implementation, since it can't > provide or maintain labels for which it does not > have downstream bindings. I believe such an LSR > would be exceptionally fragile and unlikely to be > of much use as a result - but I mention it mostly > for completeness. Such a device could be stable if it uses RSVP or CR-LDP (or even LDP if downstream-on-demand/conservative-retention mode is used). If all LSPs are created using strict EROs, you don't even need routing functionality. But you're right that such a product would not be useful to most people. Once you've paid enough money to get good forwarding hardware, you're going to want routing and LER capabilities. -- David From owner-mpls@UU.NET Tue Jul 9 19:48:57 2002 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 ESMTP id TAA22067 for ; Tue, 9 Jul 2002 19:48:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwvf23067 for ; Tue, 9 Jul 2002 23:49:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwvf20427; Tue, 9 Jul 2002 23:48:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwvf14333 for mpls-outgoing; Tue, 9 Jul 2002 23:48:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwvf14326 for ; Tue, 9 Jul 2002 23:48:08 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 QQmwvf08581 for ; Tue, 9 Jul 2002 23:48:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwvf02662 for ; Tue, 9 Jul 2002 23:48:04 GMT Received: from xover.netplane.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cnxt10002.conexant.com [198.62.10.2]) id QQmwvf02517 for ; Tue, 9 Jul 2002 23:47:59 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 19:47:46 -0400 Message-ID: <076236BAE727D611943F00508BA0F95906E7C5@XOVER.dedham.mindspeed.com> From: "Kullberg, Alan" To: "'Seisho Yasukawa'" , "MPLS_WG (E-mail)" Subject: RE: comments on draft-yasukawa-mpls-rsvp-multicast-00.txt Date: Tue, 9 Jul 2002 19:47:46 -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 Hi Seisho, See comments below. Alan > Our prune process also can solve this race condition > In our design, Graft/Prune/Join/Leave message take precedence > over Path > refresh message. > This means that the Prune node does not send Path messages to > the pruned > sub-tree in case the contents of TERO in the Path refresh > message specifies > this sub-tree. > Note that we must send Graft message if we want to re-establish pruned > sub-tree. > Therefore, our proposed mechanism can prevent racing problem. > > And because those messages are not process at unrelated > intermediate nodes, > our process can attain quick Graft/Prune operation in a > scalable manner. Okay, but then does the Prune node "remember" that a prune operation has been performed, and if so, for how long? If not, then there is a race condition whereby the next PATH refresh from the upstream node (containing the old TERO with the pruned sub-tree) could cause the sub-tree to be re-established. > >5. Instead of sending an ADD message for MP-to-MP, why not > send a PATH > >message that has the 2 new objects in the ADD message? > > Add message has different function from Path message. > So we define new Add message. > Do you think Path message with 2 new object is better than > Add message ? I think that adding objects to the PATH message would be easier for an existing implementation. From owner-mpls@UU.NET Wed Jul 10 10:57:43 2002 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 ESMTP id KAA05430 for ; Wed, 10 Jul 2002 10:57:39 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwxk05830; Wed, 10 Jul 2002 14:12:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwxk20317 for mpls-outgoing; Wed, 10 Jul 2002 14:12:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmwxk20290 for ; Wed, 10 Jul 2002 14:12:03 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 QQmwxk13048 for ; Wed, 10 Jul 2002 14:11:47 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwxk28823 for ; Wed, 10 Jul 2002 14:11:46 GMT Received: from dharti.aplion.stpn.soft.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmwxk28806 for ; Wed, 10 Jul 2002 14:11:42 GMT Received: from cyborg (IDENT:root@localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g6AEDmw17590; Wed, 10 Jul 2002 19:43:48 +0530 Reply-To: From: "Mayank Kumar" To: Cc: "Mpls \(E-mail\)" Subject: RE: LER and LSR issue Date: Wed, 10 Jul 2002 19:44:51 +0530 Message-ID: <010b01c2281c$28e9ee10$feca64c0@cyborg> 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: <36FB26FEDE20D511BA9C00508BE050B423BD97@QUANTUMEXCH> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Sudhir, thanks again for the reply .. Now that u have some experience with this MPLS implementation, i wanted to know that does making a decision of implementing LER only mpls router , will in any way affect the implementation of bgp vpns using mpls . I am asking this qeustion , becoz if i plan to later implement BGp vpns's then, will it hamper it in any way. I dont know much about BGP-vpns . Also will it affect the leveraging of diffserv on mpls. Also out there does anybody know of some good and detailed architecture and design guides on MPLS, TE,Diffserv on MPLS,BGP-vpns,etc... thanks regds MAyank From owner-mpls@UU.NET Wed Jul 10 11:37:34 2002 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 ESMTP id LAA07364 for ; Wed, 10 Jul 2002 11:37:34 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwxq24963 for ; Wed, 10 Jul 2002 15:38:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwxq22781; Wed, 10 Jul 2002 15:37:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwxq18854 for mpls-outgoing; Wed, 10 Jul 2002 15:37:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwxq18848 for ; Wed, 10 Jul 2002 15:37: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 QQmwxq27801 for ; Wed, 10 Jul 2002 15:35:55 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwxq21917 for ; Wed, 10 Jul 2002 15:35:55 GMT Received: from dharti.aplion.stpn.soft.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmwxq21900 for ; Wed, 10 Jul 2002 15:35:52 GMT Received: from cyborg (IDENT:root@localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g6AFc4W20291 for ; Wed, 10 Jul 2002 21:08:04 +0530 Reply-To: From: "Mayank Kumar" To: "Mpls \(E-mail\)" Subject: Doubts regarding the mailing list use Date: Wed, 10 Jul 2002 21:09:08 +0530 Message-ID: <011301c22827$eedef560$feca64c0@cyborg> 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 hi i am new to this mailing list and infact new to any mailing list. I wanted to know that while firing questions and having discussions on this mailing list, if somebody replies to me in personal to my query, then do i need to reply him in personal too or all such replies shoould be cc'd to the group too. (i mean does the person replying me in personal expects me to not reply him back in public) I mean any such discussions which are related to mpls (and thats what this mailing list is all about) should be sent to the group as a whole so that every body listens to the discussions and can give there independent and intelligent views. That allows free flow of information and insures that we have many views of the idea . thanks and regds Mayank From owner-mpls@UU.NET Wed Jul 10 11:50:45 2002 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 ESMTP id LAA08075 for ; Wed, 10 Jul 2002 11:50:45 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwxr08425 for ; Wed, 10 Jul 2002 15:51:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwxr05630; Wed, 10 Jul 2002 15:49:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwxr19654 for mpls-outgoing; Wed, 10 Jul 2002 15:49:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwxr19647 for ; Wed, 10 Jul 2002 15:49:30 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 QQmwxr25216 for ; Wed, 10 Jul 2002 15:47:56 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwxr04557 for ; Wed, 10 Jul 2002 15:47:55 GMT Received: from dharti.aplion.stpn.soft.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmwxr04527 for ; Wed, 10 Jul 2002 15:47:51 GMT Received: from cyborg (IDENT:root@localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g6AFniL20574; Wed, 10 Jul 2002 21:19:44 +0530 Reply-To: From: "Mayank Kumar" To: Cc: "Mpls \(E-mail\)" Subject: RE: FW: LER and LSR issue Date: Wed, 10 Jul 2002 21:20:48 +0530 Message-ID: <011401c22829$9044bfb0$feca64c0@cyborg> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0115_01C22857.A9FCFBB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3D2C47C2.34BF568B@nortelnetworks.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0115_01C22857.A9FCFBB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi see inline .. Hi, If it is an LSR, it incorporates most of the functionality found in LER. In LER, you dont need to have FTN tables. [Mayank Kumar] Why we dont need to have FTN tables in an LER. LER needs FTN tables to match FEC's with labels and send them out to next hops. Please clarify ???? For E-LSP support, you need to do the bandwidth reservation in LSRs, while you just mark the packets in the LER and send to the LSR. [Mayank Kumar] So u are saying that if i plan to implement the functionality of a LSR also , then i need to take care of these issues also. Like bandwidth reservation in case of E-LSP's. I think bandwidth reservations need to be dealt with in case of L-lsp's as well as RSVP-TE and CR-LDP. For eg. if an egde router initiates a constrained LSP setup (using any of the signalling protocol) and i am sitting in the core of the mpls , then i need to reserve bandwidth (or provide queuing and scheduling behaviours PHB) as requested by the LSP. This is a very good point that u have opened. So as an LER i didnt need to worry about these things but as an LSR , these bandwidth reservation and qos handling might require some huge efforts. Please tell me if i am right For BGP-MPLS vpns, you need to add the support for MP-BGP in LERs, while it is not required in LSRs. [Mayank Kumar] I dont know what is MP-BGP ???But thanks for the information. Any other extra effort apart from the qos handling , that is required by an lsr and not required by an ler? Rajesh Mayank Kumar wrote: Hi you say that most of the edge routers implement only the ler functionality. So is it worth to leave out the lsr functionality from a mpls switch ??? What deployment limitations will be there if i just implement the ler functionalities. Please reply thinking in terms of the fact that the routers will be used by a service provider. >From the replies i have had from other people , i came to know that other vendors who provide routers for the edge are implementing both the ler and lsr functionalities now. Mayank -----Original Message----- From: rpotti@nortelnetworks.com [mailto:rpotti@nortelnetworks.com] Sent: Tuesday, July 09, 2002 8:10 PM To: mkumar@aplion.stpn.soft.net Subject: Re: FW: LER and LSR issue Hi, Mayank Kumar wrote: > Hi > i have had no replies to my previous mail which is included below. If any > body have some information , then please do reply on this. > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mayank > Kumar > Sent: Monday, July 08, 2002 9:16 PM > To: Mpls (E-mail) > Subject: LER and LSR issue > > Hi > We are implementing a edge router which is going to sit at the edge of > Service Providers network. > Can anybody advice that, is it worth the effort to implement a LSR's > functionality also or only the LER functionality will be enough??? > I mean processing of ILM's also instead of just FTN's ??? Also does anybody Even if it is just LSR, it needs to have both FTN and ILM. The ILM is for processing labelled packets in the incoming direction, and FTN for the outgoing direction. > > know of mpls implementations in routers from some vendors (eg > cisco,juniper,nortel,etc) where only the LER functionality has been Most of the edge routers implement just the LER functionality. > > implemented. Also how much extra effort and in terms of what ??? (memory , > processsing power, or functionality) is to be made for implementing both. > Please reply with some level of detail. > thanks in advance. > > regds > > Mayank -- """ ------------------------------------------------------------------------- - Rajesh Potti rpotti@nortelnetworks.com - Shasta iSOS Software Development - Nortel Networks - 600 Technology Park - Billerica, MA 01821 (O): (978)288-3095 ESN: 248-3095 ------------------------------------------------------------------------- ------=_NextPart_000_0115_01C22857.A9FCFBB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 Hi
see = inline=20 ..
Hi,=20

 If it is an LSR, it incorporates most of the functionality = found in=20 LER. In LER, you dont need to have FTN tables.
[Mayank=20 Kumar]  Why we = dont need to have FTN=20 tables in an LER. LER needs FTN tables=20 to match FEC's with labels and send them out to next=20 hops. Please clarify=20 ????
 For E-LSP support, you need to do the = bandwidth reservation in LSRs, while you just mark the packets in the = LER and=20 send to the
 LSR.
[Mayank = Kumar] 

So u=20 are saying that if i plan to implement the functionality of a LSR also = , then=20 i need to take care of these issues also. Like bandwidth reservation = in case=20 of E-LSP's. I think bandwidth reservations need to be dealt with in = case of=20 L-lsp's as well as RSVP-TE and CR-LDP. For eg. if an egde router = initiates a=20 constrained LSP setup (using any of the signalling protocol) and i am = sitting=20 in the core of the mpls , then i need to reserve bandwidth (or provide = queuing=20 and scheduling behaviours PHB) as requested by the LSP. This is a very = good=20 point that u have opened. So as an LER i didnt need to worry=20 about these things but as an LSR , these bandwidth = reservation and=20 qos handling might require some huge efforts. Please tell me if i am = right=20

    For=20 BGP-MPLS vpns, you need to add the support for MP-BGP in = LERs, while=20 it is not required in LSRs.
[Mayank Kumar] 

I dont=20 know what is MP-BGP ???But thanks for the = information.

Any=20 other extra effort apart from the qos handling , that is required by = an lsr=20 and not required by an ler?

Rajesh=20

Mayank Kumar wrote:=20

Hi
you say that most of the edge routers = implement only the ler functionality.
So is it worth to leave = out the=20 lsr functionality  from a mpls switch ???
What deployment=20 limitations will be there if i just implement the ler =
functionalities.=20 Please reply thinking in terms of the fact that the routers
will = be used=20 by a service provider.
>From the replies i have had from = other people=20 , i came to know that other
vendors who provide routers for the = edge are=20 implementing both the ler and
lsr functionalities now.=20

Mayank=20

-----Original Message-----
From: rpotti@nortelnetworks.com = [mailto:rpotti@nortelnetworks.co= m]=20
Sent: Tuesday, July 09, 2002 8:10 PM
To: = mkumar@aplion.stpn.soft.net=20
Subject: Re: FW: LER and LSR issue=20

Hi,=20

Mayank Kumar wrote:=20

> Hi
> i have had no replies to my previous mail which = is=20 included below. If any
> body have some information , then = please do=20 reply on this.
>
> -----Original Message-----
> = From:=20 owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of=20 Mayank
> Kumar
> Sent: Monday, July 08, 2002 9:16 PM =
>=20 To: Mpls (E-mail)
> Subject: LER and LSR issue
> =
> Hi=20
> We are implementing a edge router which is going to sit at = the edge=20 of
> Service Providers network.
> Can anybody advice = that, is=20 it worth the effort to implement a LSR's
> functionality also = or only=20 the LER functionality will be enough???
> I mean processing = of ILM's=20 also instead of  just FTN's ??? Also does
anybody=20

 Even if it is just LSR, it needs to have both FTN and ILM. = The ILM=20 is for
processing labelled packets in the
 incoming = direction,=20 and FTN for the outgoing direction.=20

>
> know of mpls implementations in routers from some = vendors=20 (eg
> cisco,juniper,nortel,etc) where only the LER = functionality has=20 been=20

 Most of the edge routers implement  just the LER=20 functionality.=20

>
> implemented.  Also how much extra effort and = in terms=20 of what ??? (memory
,
> processsing power, or = functionality) is=20 to be made for implementing both.=20
>         Please = reply with=20 some level of detail.
> thanks in advance.
>
> = regds=20
>
> Mayank

-- 
"""
-------------------------------------------------------------------------=

-  Rajesh =
Potti           &n=
bsp; rpotti@nortelnetworks.com
-  Shasta iSOS Software Development
-  Nortel Networks
-  600 Technology Park 
-  Billerica, MA =
01821          (O): =
(978)288-3095 ESN: 248-3095
-------------------------------------------------------------------------=
 =20
------=_NextPart_000_0115_01C22857.A9FCFBB0-- From owner-mpls@UU.NET Wed Jul 10 12:04:14 2002 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 ESMTP id MAA08702 for ; Wed, 10 Jul 2002 12:04:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwxs03700 for ; Wed, 10 Jul 2002 16:05:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwxs28281; Wed, 10 Jul 2002 16:02:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwxs02240 for mpls-outgoing; Wed, 10 Jul 2002 16:02:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmwxs02230 for ; Wed, 10 Jul 2002 16:02: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 QQmwxs13679 for ; Wed, 10 Jul 2002 16:02:28 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwxs11206 for ; Wed, 10 Jul 2002 16:02:28 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 QQmwxs11200 for ; Wed, 10 Jul 2002 16:02:27 GMT Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6AG2BB01891; Wed, 10 Jul 2002 12:02:11 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NGKKVCH0; Wed, 10 Jul 2002 12:02:10 -0400 Received: from nortelnetworks.com (potti.engeast.baynetworks.com [47.17.140.52]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NSA9G6ZP; Wed, 10 Jul 2002 12:02:10 -0400 Message-ID: <3D2C5A85.2BD05591@nortelnetworks.com> Date: Wed, 10 Jul 2002 12:02:13 -0400 From: Rajesh Potti Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mkumar@aplion.stpn.soft.net CC: mpls@UU.NET Subject: Re: FW: LER and LSR issue References: <011401c22829$9044bfb0$feca64c0@cyborg> Content-Type: multipart/alternative; boundary="------------06E71D686804B5293B1BDD19" Sender: owner-mpls@UU.NET Precedence: bulk --------------06E71D686804B5293B1BDD19 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hisee inline .. > > Hi, > > If it is an LSR, it incorporates most of the functionality > found in LER. In LER, you dont need to have FTN tables. > [Mayank Kumar] Why we dont need to have FTN tables in an > LER. LER needs FTN tables to match FEC's with labels and > send them out to next hops. Please clarify ???? > It was a typo. I meant in LSRs, you dont need FTN tables. Not LERs. Rajesh > > For E-LSP support, you need to do the bandwidth reservation > in LSRs, while you just mark the packets in the LER and send > to the > LSR. > [Mayank Kumar] > > So u are saying that if i plan to implement the > functionality of a LSR also , then i need to take care of > these issues also. Like bandwidth reservation in case of > E-LSP's. I think bandwidth reservations need to be dealt > with in case of L-lsp's as well as RSVP-TE and CR-LDP. For > eg. if an egde router initiates a constrained LSP setup > (using any of the signalling protocol) and i am sitting in > the core of the mpls , then i need to reserve bandwidth (or > provide queuing and scheduling behaviours PHB) as requested > by the LSP. This is a very good point that u have opened. So > as an LER i didnt need to worry about these things but as an > LSR , these bandwidth reservation and qos handling might > require some huge efforts. Please tell me if i am right > > For BGP-MPLS vpns, you need to add the support for MP-BGP > in LERs, while it is not required in LSRs. > [Mayank Kumar] > > I dont know what is MP-BGP ???But thanks for the > information. > > Any other extra effort apart from the qos handling , that is > required by an lsr and not required by an ler? > > Rajesh > > Mayank Kumar wrote: > > > Hi > > you say that most of the edge routers implement only the > > ler functionality. > > So is it worth to leave out the lsr functionality from a > > mpls switch ??? > > What deployment limitations will be there if i just > > implement the ler > > functionalities. Please reply thinking in terms of the > > fact that the routers > > will be used by a service provider. > > >From the replies i have had from other people , i came to > > know that other > > vendors who provide routers for the edge are implementing > > both the ler and > > lsr functionalities now. > > > > Mayank > > > > -----Original Message----- > > From: rpotti@nortelnetworks.com > > [mailto:rpotti@nortelnetworks.com] > > Sent: Tuesday, July 09, 2002 8:10 PM > > To: mkumar@aplion.stpn.soft.net > > Subject: Re: FW: LER and LSR issue > > > > Hi, > > > > Mayank Kumar wrote: > > > > > Hi > > > i have had no replies to my previous mail which is > > included below. If any > > > body have some information , then please do reply on > > this. > > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On > > Behalf Of Mayank > > > Kumar > > > Sent: Monday, July 08, 2002 9:16 PM > > > To: Mpls (E-mail) > > > Subject: LER and LSR issue > > > > > > Hi > > > We are implementing a edge router which is going to sit > > at the edge of > > > Service Providers network. > > > Can anybody advice that, is it worth the effort to > > implement a LSR's > > > functionality also or only the LER functionality will be > > enough??? > > > I mean processing of ILM's also instead of just FTN's > > ??? Also does > > anybody > > > > Even if it is just LSR, it needs to have both FTN and > > ILM. The ILM is for > > processing labelled packets in the > > incoming direction, and FTN for the outgoing direction. > > > > > > > > know of mpls implementations in routers from some > > vendors (eg > > > cisco,juniper,nortel,etc) where only the LER > > functionality has been > > > > Most of the edge routers implement just the LER > > functionality. > > > > > > > > implemented. Also how much extra effort and in terms of > > what ??? (memory > > , > > > processsing power, or functionality) is to be made for > > implementing both. > > > Please reply with some level of detail. > > > thanks in advance. > > > > > > regds > > > > > > Mayank > > -- > """ > ------------------------------------------------------------------------- > - Rajesh Potti rpotti@nortelnetworks.com > - Shasta iSOS Software Development > - Nortel Networks > - 600 Technology Park > - Billerica, MA 01821 (O): (978)288-3095 ESN: 248-3095 > ------------------------------------------------------------------------- > > > -- """ ------------------------------------------------------------------------- - Rajesh Potti rpotti@nortelnetworks.com - Shasta iSOS Software Development - Nortel Networks - 600 Technology Park - Billerica, MA 01821 (O): (978)288-3095 ESN: 248-3095 ------------------------------------------------------------------------- --------------06E71D686804B5293B1BDD19 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hisee inline ..
Hi,

 If it is an LSR, it incorporates most of the functionality found in LER. In LER, you dont need to have FTN tables.
[Mayank Kumar]  Why we dont need to have FTN tables in an LER. LER needs FTN tables to match FEC's with labels and send them out to next hops. Please clarify ????

    It was a typo.  I meant in LSRs, you dont need FTN tables.   Not LERs.
 
Rajesh
 
 For E-LSP support, you need to do the bandwidth reservation in LSRs, while you just mark the packets in the LER and send to the
 LSR.
[Mayank Kumar] 

So u are saying that if i plan to implement the functionality of a LSR also , then i need to take care of these issues also. Like bandwidth reservation in case of E-LSP's. I think bandwidth reservations need to be dealt with in case of L-lsp's as well as RSVP-TE and CR-LDP. For eg. if an egde router initiates a constrained LSP setup (using any of the signalling protocol) and i am sitting in the core of the mpls , then i need to reserve bandwidth (or provide queuing and scheduling behaviours PHB) as requested by the LSP. This is a very good point that u have opened. So as an LER i didnt need to worry about these things but as an LSR , these bandwidth reservation and qos handling might require some huge efforts. Please tell me if i am right 

   For BGP-MPLS vpns, you need to add the support for MP-BGP in LERs, while it is not required in LSRs.
[Mayank Kumar] 

I dont know what is MP-BGP ???But thanks for the information.

Any other extra effort apart from the qos handling , that is required by an lsr and not required by an ler?

Rajesh

Mayank Kumar wrote:

Hi
you say that most of the edge routers implement only the ler functionality.
So is it worth to leave out the lsr functionality  from a mpls switch ???
What deployment limitations will be there if i just implement the ler
functionalities. Please reply thinking in terms of the fact that the routers
will be used by a service provider.
>From the replies i have had from other people , i came to know that other
vendors who provide routers for the edge are implementing both the ler and
lsr functionalities now.

Mayank

-----Original Message-----
From: rpotti@nortelnetworks.com [mailto:rpotti@nortelnetworks.com]
Sent: Tuesday, July 09, 2002 8:10 PM
To: mkumar@aplion.stpn.soft.net
Subject: Re: FW: LER and LSR issue

Hi,

Mayank Kumar wrote:

> Hi
> i have had no replies to my previous mail which is included below. If any
> body have some information , then please do reply on this.
>
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mayank
> Kumar
> Sent: Monday, July 08, 2002 9:16 PM
> To: Mpls (E-mail)
> Subject: LER and LSR issue
>
> Hi
> We are implementing a edge router which is going to sit at the edge of
> Service Providers network.
> Can anybody advice that, is it worth the effort to implement a LSR's
> functionality also or only the LER functionality will be enough???
> I mean processing of ILM's also instead of  just FTN's ??? Also does
anybody

 Even if it is just LSR, it needs to have both FTN and ILM. The ILM is for
processing labelled packets in the
 incoming direction, and FTN for the outgoing direction.

>
> know of mpls implementations in routers from some vendors (eg
> cisco,juniper,nortel,etc) where only the LER functionality has been

 Most of the edge routers implement  just the LER functionality.

>
> implemented.  Also how much extra effort and in terms of what ??? (memory
,
> processsing power, or functionality) is to be made for implementing both.
>         Please reply with some level of detail.
> thanks in advance.
>
> regds
>
> Mayank

-- 
"""
-------------------------------------------------------------------------
-  Rajesh Potti             rpotti@nortelnetworks.com
-  Shasta iSOS Software Development
-  Nortel Networks
-  600 Technology Park 
-  Billerica, MA 01821          (O): (978)288-3095 ESN: 248-3095
-------------------------------------------------------------------------
 
-- 
"""
-------------------------------------------------------------------------
-  Rajesh Potti             rpotti@nortelnetworks.com
-  Shasta iSOS Software Development
-  Nortel Networks
-  600 Technology Park 
-  Billerica, MA 01821          (O): (978)288-3095 ESN: 248-3095
-------------------------------------------------------------------------
  --------------06E71D686804B5293B1BDD19-- From owner-mpls@UU.NET Wed Jul 10 14:09:01 2002 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 ESMTP id OAA13689 for ; Wed, 10 Jul 2002 14:09:01 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwya11001 for ; Wed, 10 Jul 2002 18:09:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwya09204; Wed, 10 Jul 2002 18:09:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwya05531 for mpls-outgoing; Wed, 10 Jul 2002 18:08:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwya05526 for ; Wed, 10 Jul 2002 18:08: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 QQmwya01628 for ; Wed, 10 Jul 2002 18:07:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwya17370 for ; Wed, 10 Jul 2002 18:07:22 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmwya17356 for ; Wed, 10 Jul 2002 18:07:21 GMT Received: from utfors.se ([195.58.105.130]) by blooper.utfors.se (Utfors AB) with ESMTP id g6AI6l5F025445; Wed, 10 Jul 2002 20:06:48 +0200 (MEST) Message-ID: <3D2C77B7.9000008@utfors.se> Date: Wed, 10 Jul 2002 20:06:47 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Loa Andersson CC: MPLS wg , George Swallow , Martin Dubuc , "Wijnen, Bert (Bert)" Subject: extending - wg last call - draft-ietf-mpls-bundle-mib-03.txt References: <3D241A2A.8020409@utfors.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, it has been pointed out that this week is a bad week for a wg last call. This mail extends the wg last call for to July 28, 2002 at 2400 GMT. /Loa Loa Andersson wrote: This message initiates a one week WG last call on: Link Bundling Management Information Base Please send your comments to the mailing list. The draft has been thorugh an earlier wg last and been updated according to comments in that last call, however the changes has been of such a nature that we want to make this last call on the entire draft. Note: This draft uses a MIB boilerplate that will be changed, this will however be taken care of in the the editorial process. This wg last call ends July 12, 2002 at 2400 GMT. /Loa and George -- 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 Jul 10 15:31:26 2002 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 ESMTP id PAA16637 for ; Wed, 10 Jul 2002 15:31:25 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwye06060 for ; Wed, 10 Jul 2002 19:08:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwye05588; Wed, 10 Jul 2002 19:07:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwye02194 for mpls-outgoing; Wed, 10 Jul 2002 19:07:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmwye02185 for ; Wed, 10 Jul 2002 19:07: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 QQmwye27002 for ; Wed, 10 Jul 2002 19:07:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwye22267 for ; Wed, 10 Jul 2002 19:07:16 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmwye22257 for ; Wed, 10 Jul 2002 19:07:15 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA03035 for ; Wed, 10 Jul 2002 15:07:15 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA16973 for mpls@uu.net; Wed, 10 Jul 2002 15:07:15 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmwyc08711 for ; Wed, 10 Jul 2002 18:39: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 QQmwyc02682 for ; Wed, 10 Jul 2002 18:38:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwyc10658 for ; Wed, 10 Jul 2002 18:38:24 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: law2-f31.hotmail.com [216.32.181.31]) id QQmwyc10640 for ; Wed, 10 Jul 2002 18:38:24 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Jul 2002 11:38:23 -0700 Received: from 63.104.212.3 by lw2fd.hotmail.msn.com with HTTP; Wed, 10 Jul 2002 18:38:23 GMT X-Originating-IP: [63.104.212.3] From: "Sandeep B" To: mpls@UU.NET Subject: ERO in PATH message Date: Wed, 10 Jul 2002 18:38:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2002 18:38:23.0405 (UTC) FILETIME=[F8A005D0:01C22840] Sender: owner-mpls@UU.NET Precedence: bulk As per my understanding an ERO in PATH message is not mandatory. Still I see a particular implementation rejecting a PATH message without an ERO - 7w0d: RSVP 10.20.1.101_1-10.20.1.6_17: PATH message for 10.20.1.6(FastEthernet4/5) from 10.10.29.101 7w0d: RSVP 10.20.1.101_1-10.20.1.6_17: PATH message with no ERO; no path meets constraints 7w0d: RSVP session 10.20.1.6_17: send path error to 10.10.29.101 about 10.20.1.6 7w0d: RSVP session 10.20.1.6_0: IP to 10.10.29.101 length=132 checksum=4DC6 TOS=0x0 (FastEthernet4/5) Please clarify!!! I'd be glad if someone from Cisco answers this question. -Sandeep _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Wed Jul 10 18:03:14 2002 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 ESMTP id SAA21561 for ; Wed, 10 Jul 2002 18:03:07 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwyq04322 for ; Wed, 10 Jul 2002 22:03:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwyq03869; Wed, 10 Jul 2002 22:03:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwyq12223 for mpls-outgoing; Wed, 10 Jul 2002 22:03:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmwyq12201 for ; Wed, 10 Jul 2002 22:03: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 QQmwyp21629 for ; Wed, 10 Jul 2002 21:59:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwyp04402 for ; Wed, 10 Jul 2002 21:59:30 GMT Received: from exchange.tropicnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50]) id QQmwyp04392 for ; Wed, 10 Jul 2002 21:59:29 GMT Received: from tropicnetworks.com ([10.1.5.113]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 10 Jul 2002 17:59:29 -0400 Message-ID: <3D2CAE41.BA5C605D@tropicnetworks.com> Date: Wed, 10 Jul 2002 17:59:29 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ping Pan CC: mpls@UU.NET Subject: Re: LSP Liveliness References: <3D29B9DF.CA68F8EF@tropicnetworks.com> <3D29CA27.2010308@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2002 21:59:29.0599 (UTC) FILETIME=[10A31CF0:01C2285D] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ping, I agree that naming is a secondary issue but the standards set the tone for the terminology. Whatever is used in the draft will likely be adopted as the appropriate terminology. There are already deployed boxes out there with Traceroute and Ping over LSPs - using the existing ICMP definitions. It would be nice if this new draft: 1. Could co-exist with the existing LSP Traceroute and Ping. This is from a technology as well as terminology perspective. 2. Could have a technical solution that is a super-set of existing LSP TR and Ping functionality (hence the suggestion of ICMP as a possible return mechanism). --- Best, Nabil Seddigh > > The draft defines the concept and the protocol that are used for LSP > monitoring, probing... etc. Depending on the implementation, we could > have some commands such as lsping() and tracelsp(), etc. I don't think > we should hang up on the naming here. :-) > > > 2. Why not consider adding a reply mode of ICMP. > > > > Indeed, there is more than one way to transport requests and replies. We > chosen UDP long time back based on our unfortunate experience in 'ICMP > extension on MPLS'. As a result, IANA had assigned port number 3503 to > us (http://www.iana.org/assignments/port-numbers). > > Actually, using UDP may be easier to implement. > From owner-mpls@UU.NET Wed Jul 10 18:20:30 2002 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 ESMTP id SAA22036 for ; Wed, 10 Jul 2002 18:20:30 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwyr23580 for ; Wed, 10 Jul 2002 22:21:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwyr23422; Wed, 10 Jul 2002 22:21:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwyr24192 for mpls-outgoing; Wed, 10 Jul 2002 22:20:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwyr24187 for ; Wed, 10 Jul 2002 22:20: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 QQmwyr00980 for ; Wed, 10 Jul 2002 22:20:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwyr21888 for ; Wed, 10 Jul 2002 22:20:11 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQmwyr21883 for ; Wed, 10 Jul 2002 22:20:10 GMT Received: from juniper.net (panther.juniper.net [172.17.12.226]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g6AMK3m12868; Wed, 10 Jul 2002 15:20:09 -0700 (PDT) (envelope-from pingpan@juniper.net) Message-ID: <3D2CB313.90605@juniper.net> Date: Wed, 10 Jul 2002 15:20:03 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20011222 X-Accept-Language: en-us MIME-Version: 1.0 To: Nabil Seddigh CC: mpls@UU.NET Subject: Re: LSP Liveliness References: <3D29B9DF.CA68F8EF@tropicnetworks.com> <3D29CA27.2010308@juniper.net> <3D2CAE41.BA5C605D@tropicnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nabil Seddigh wrote: > Ping, > > I agree that naming is a secondary issue but the standards set the > tone for the terminology. Whatever is used in the draft will likely > be adopted as the appropriate terminology. There are already deployed > boxes out there with Traceroute and Ping over LSPs - using the > existing ICMP definitions. It would be nice if this new draft: > > 1. Could co-exist with the existing LSP Traceroute and Ping. > This is from a technology as well as terminology perspective. > MPLS Ping (for ping and tracing at LSP level) is built on top of UDP. It requires the users to inject probe packets into the testing LSP's. I am certain that they will work indepdently from ping() and traceroute(). > 2. Could have a technical solution that is a super-set of existing > LSP TR and Ping functionality (hence the suggestion of ICMP > as a possible return mechanism). > After what had happened in the last several years, I'm afraid that we are getting over the ICMP solution by now. There are two equally good solutions (ICMP and UDP), and one of them (ICMP) had caused trouble before, let's just develope the darn thing with the other solution. IMHO, the primary task is to solve the actual problem with actual running code as soon as possible. No? :-) Regards, - Ping From owner-mpls@UU.NET Thu Jul 11 01:16:08 2002 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 ESMTP id BAA00562 for ; Thu, 11 Jul 2002 01:16:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwzt26798 for ; Thu, 11 Jul 2002 05:17:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmwzt26463; Thu, 11 Jul 2002 05:16:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmwzt00423 for mpls-outgoing; Thu, 11 Jul 2002 05:16:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmwzt00418 for ; Thu, 11 Jul 2002 05:16: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 QQmwzt18150 for ; Thu, 11 Jul 2002 05:15:46 GMT From: suchauhan@hss.hns.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmwzt25859 for ; Thu, 11 Jul 2002 05:15:45 GMT Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQmwzt25834 for ; Thu, 11 Jul 2002 05:15:43 GMT Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g6B5GFY17244; Thu, 11 Jul 2002 10:46:15 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id g6B5GlK25615; Thu, 11 Jul 2002 10:46:47 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256BF3.003947AA ; Thu, 11 Jul 2002 10:41:42 +0530 X-Lotus-FromDomain: HSS To: mkumar@aplion.stpn.soft.net cc: "Mpls \(E-mail\)" Message-ID: <65256BF3.001C86E8.00@sandesh.hss.hns.com> Date: Thu, 11 Jul 2002 10:43:43 +0530 Subject: Re: Doubts regarding the mailing list use Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi Mayank! Thanks for the great point of view put forth but as common mailing ethics I guess one is desired to reply only to the person who has sent the mail and not to the group whom he/she purposefully wanted to avoid. This I guess is true for all mails and not just the ones here on a mailing list. As for the mailing list a person might reply to you in person and not on the mailing list as he might want to avoid a huge discussion on a trivial issue already covered on the list. He might be sufficiently aware that most members here might already have discussed the issue earlier sometime back and hence we would like to keep the mailing list flowing with information that is new and relevant to the whole group. Ofcourse you are still invited to post all your questions on the list but as basic understanding we would like to limit the counter questions to the people we get mails from and the ones in the mail they sent. I hope you get the point! ciao sumit "Mayank Kumar" on 07/10/2002 09:09:08 PM Please respond to mkumar@aplion.stpn.soft.net To: "Mpls \(E-mail\)" cc: (bcc: Sumit Chauhan/HSS) Subject: Doubts regarding the mailing list use hi i am new to this mailing list and infact new to any mailing list. I wanted to know that while firing questions and having discussions on this mailing list, if somebody replies to me in personal to my query, then do i need to reply him in personal too or all such replies shoould be cc'd to the group too. (i mean does the person replying me in personal expects me to not reply him back in public) I mean any such discussions which are related to mpls (and thats what this mailing list is all about) should be sent to the group as a whole so that every body listens to the discussions and can give there independent and intelligent views. That allows free flow of information and insures that we have many views of the idea . thanks and regds Mayank From owner-mpls@UU.NET Thu Jul 11 07:57:34 2002 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 ESMTP id HAA16261 for ; Thu, 11 Jul 2002 07:57:34 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxat21435 for ; Thu, 11 Jul 2002 11:58:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxat21197; Thu, 11 Jul 2002 11:58:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxat12342 for mpls-outgoing; Thu, 11 Jul 2002 11:57:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmxat12337 for ; Thu, 11 Jul 2002 11:57: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 QQmxat09906 for ; Thu, 11 Jul 2002 11:56:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxat15233 for ; Thu, 11 Jul 2002 11:56:47 GMT Received: from newdev.harvard.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQmxat15229 for ; Thu, 11 Jul 2002 11:56:46 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g6BBufR15928 for mpls@uu.net; Thu, 11 Jul 2002 07:56:41 -0400 (EDT) Date: Thu, 11 Jul 2002 07:56:41 -0400 (EDT) From: Scott Bradner Message-Id: <200207111156.g6BBufR15928@newdev.harvard.edu> To: mpls@UU.NET Subject: message #1 from ITU-T SG 13 Sender: owner-mpls@UU.NET Precedence: bulk we have received some liaison statement from ITU-T SG 13 I will send them in seperate messages they will be discussed during the MPLS session in Yokohama Scott message #1 --------------------------------------- ITU - Telecommunication Standardization Sector 8 July 2002 QUESTIONS: 3/13 SOURCE: ITU-T Working Party 3/13 meeting (Chitose, Japan, 8 July 2002) TITLE: Request for the assignment of a reserved label value of 14 for MPLS OAM packet identification _____________ LIAISON STATEMENT TO: IETF Sub-IP Area (Scott Bradner, Area Co-Director) APPROVAL: Agreed to at WP 3/13 meeting FOR: Action DEADLINE: 31 August 2002 CONTACT: Hiroshi Ohta Tel: +81 422 59 3617 NTT Fax: +81 422 59 3787 3-9-11 Midori-cho Musashino-shi Email: ohta.hiroshi@lab.ntt.co.jp Tokyo 180-8585 Japan ITU-T SG 13 repeats its request that a reserved label value of 14 be assigned for MPLS OAM packet identification as indicated in < draft-ohta-mpls-label-value-01.txt>. This was the only method for OAM packet identification that did not raise any objections when discussed on the MPLS list over a year ago. Using the reserved label value guarantees backward compatibility with all the MPLS standards and implementations. Concerning the development of Recommendations related to MPLS OAM, please also note the followings: (1) draft Recommendations Y.1710/Cor. 1 (MPLS OAM requirements) and Y.1711 (MPLS OAM mechanism) have passed the last call and are planned to be approved at the next SG 13 meeting in October/November 2002; (2) draft Recommendation Y.1720 (MPLS OAM protection) is expected to be approved in November/December 2002 time frame. Attachments: Draft Rec. Y.1710/Cor. 1, draft Rec. Y.1711 and draft Rec. Y.1720 may be reviewed at http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.html From owner-mpls@UU.NET Thu Jul 11 08:05:51 2002 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 ESMTP id IAA16395 for ; Thu, 11 Jul 2002 08:05:51 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxau02918 for ; Thu, 11 Jul 2002 12:06:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxau02590; Thu, 11 Jul 2002 12:06:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxau03639 for mpls-outgoing; Thu, 11 Jul 2002 12:06:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmxau03490 for ; Thu, 11 Jul 2002 12:06: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 QQmxau02192 for ; Thu, 11 Jul 2002 12:04:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxau01551 for ; Thu, 11 Jul 2002 12:04:18 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 QQmxau01547 for ; Thu, 11 Jul 2002 12:04:18 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g6BC4Iw15964 for mpls@uu.net; Thu, 11 Jul 2002 08:04:18 -0400 (EDT) Date: Thu, 11 Jul 2002 08:04:18 -0400 (EDT) From: Scott Bradner Message-Id: <200207111204.g6BC4Iw15964@newdev.harvard.edu> To: mpls@UU.NET Subject: message #3 from ITU-T SG 13 Sender: owner-mpls@UU.NET Precedence: bulk ITU - Telecommunication Standardization Sector TD 13 (WP2/13) STUDY GROUP 13 Chitose, Japan, 8 July 2002 QUESTION: Q.5/13 SOURCE: ITU-T Working Party 2/13 (Chitose, Japan, 8 July 2002) TITLE: SG 13 work on interworking with MPLS _______________ LIAISON STATEMENT TO: IETF (PWE3 WG) APPROVAL: Agreed to at WP 2/13 meeting FOR: Information DEADLINE: N/A ATTACHMENT: None CONTACT: Ghassem Koleyni Tel: +1 613 763 4154 P.O. Box 3511 Station C Fax: +1 613 765 6295 Ottawa, ON Email: ghassem@nortelnetworks.com Canada K1Y 4H7 SG 13 likes to inform you that it is undertaking detailed studies on MPLS inter-networking. Studies include aspects affecting architectures, requirements and user plane protocol. Examples of such studies are ATM and FR interworking with MPLS. SG 13 experts are interested in working with your organization to define the network aspects and requirements for interworking of signalling and management protocols involving MPLS networks. This cooperation would be very important to develop integrated solutions for various interworking scenarios based on MPLS network. We have ongoing work on ATM-MPLS interworking (draft Recommendations Y.atmplsC and Y.atmplsF), which has become mature and we intend to send the draft Recommendations for consent at the next meeting. We intend to work on interworking between MPLS and Ethernet, FR, PSTN and other networks in our future work. We therefore request that you keep us informed of your work on these areas. We will keep you informed of progress on work in SG 13. From owner-mpls@UU.NET Thu Jul 11 08:06:05 2002 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 ESMTP id IAA16410 for ; Thu, 11 Jul 2002 08:06:05 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxau19773 for ; Thu, 11 Jul 2002 12:06:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxau19340; Thu, 11 Jul 2002 12:06:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxau03640 for mpls-outgoing; Thu, 11 Jul 2002 12:06:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmxau03560 for ; Thu, 11 Jul 2002 12:06: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 QQmxau26079 for ; Thu, 11 Jul 2002 12:02:55 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxau00823 for ; Thu, 11 Jul 2002 12:02:55 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 QQmxau00812 for ; Thu, 11 Jul 2002 12:02:54 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g6BC2np15953 for mpls@uu.net; Thu, 11 Jul 2002 08:02:49 -0400 (EDT) Date: Thu, 11 Jul 2002 08:02:49 -0400 (EDT) From: Scott Bradner Message-Id: <200207111202.g6BC2np15953@newdev.harvard.edu> To: mpls@UU.NET Subject: message #2 from ITU-T SG 13 Sender: owner-mpls@UU.NET Precedence: bulk TU - Telecommunication Standardization Sector 8 July 2002 QUESTIONS: 3/13 SOURCE: ITU-T Working Party 3/13 meeting (Chitose, Japan, 8 July 2002) TITLE: Response to Communication from IETF on MPLS OAM packet identification _____________ LIAISON STATEMENT TO: IETF Sub-IP Area (Scott Bradner, Area Co-Director) APPROVAL: Agreed to at WP 3/13 meeting FOR: Action DEADLINE: 31 August 2002 CONTACT: Hiroshi Ohta Tel: +81 422 59 3617 NTT Fax: +81 422 59 3787 3-9-11 Midori-cho Musashino-shi Tokyo 180-8585 Japan Email: ohta.hiroshi@lab.ntt.co.jp This liaison statement is prepared to respond to the Communication from IETF Sub-IP Area (Scott Bradner, Area Co-Director) titled "Response to "Communication on the status of the request on the assignment of a reserved label value for MPLS OAM packet identification". Summary: Any extension to IETF protocols other than the assignment of the reserved label value of 14 for OAM packet identification is purely optional and not essential for the operation of Y.1711 and requires further technical study as well as usability assessment. In any case such extensions are not targeted to the current revision of the Y.1711. Details: The MPLS OAM, as defined in Y.1711, has the following requirements: 1) Identification of OAM packets: A reserved MPLS label (suggested label=14) is REQUIRED for the identification of OAM packets. Without this reserved Label, it is not possible to implement Y.1711. Note that this was discussed on the MPLS list over a year ago and the consensus for OAM packet identification was to use a globally reserved label. 2) Activation/Set up of the Connectivity Verification (CV) processing: Running and monitoring the CV flow on any specific LSP is optional in Y.1711. Since the CV processing is done at the egress LSR, it needs to know whether to look for CV packets on a specific LSP or not. On the other hand there are a number of different CV processing options that may be done at an egress LSR (see appendix I of Y.1711). Currently Y.1711 relies on manual configuration of the egress LSR for setting up the CV processing function. Manual configuration of the egress LSR is currently sufficient for the current version of Y.1711. In future it may be desired to use signaling methods to setup the CV processing at an egress LSR for a specific LSP. The key point here is that OAM activation/deactivation needs to be harmonized with any control-plane set-up/tear-down of LSPs, e.g. to stop OAM processing, and hence consequent action such as alarm generation, when an LSP is consciously removed. The methods to achieve this could be: a) OPTIONAL extension to RSVP-TE and CR-LDP. b) Defining new setup OAM packets using the OAM reserved label (14) c) Configuration via NMS. 3) Knowledge of Server-Client relationship: For the purpose of suppressing down-stream alarms, the FDI (Forward Defect Identifier) must be mapped from a lower layer LSP to a higher layer LSP at the egress LSR. Therefore the egress LSR needs to know which LSPs are tunneled inside a specific LSP. Currently Y.1711 relies on two possible methods for setting up the client-server relationship between LSPs: a) Manual configuration of the egress LSR b) Automatic learning process: If during the establishment of the client LSPs, the signaling is tunneled through the server LSP, then the server trail terminating node (egress) could keep the information about the client LSPs in memory as they occur. In future it may be desired to use signaling methods to setup the Server-Client relationship for a specific LSP. The methods to achieve this could be: c) OPTIONAL extension to RSVP-TE and CR-LDP. d) Defining new setup OAM packets using the OAM reserved label (14) e) Configuration via NMS. Other functions such as Performance (P) flows, loop-back, trace-route, variable CV rate, etc are under study and we can't comment on their requirements at this time. It is also far from certain that all these functions would ever be adopted in any case....this will depend on contributions, especially from operators requesting the development of such functions. Following are ITU's answers to the specific issues raised in your liaison: A) Section 6.1 issue: The egress LSR needs to know the TTSI for a terminating LSP. According to Y.1711, TTSI = Router_ID + LSP_ID. Both the Router_ID and LSP_ID are already signaled in the existing RSVP-TE and CR-LDP protocols in the form of Session Object and LSPID TLV respectively. Therefore there is no need for further extensions to these protocols to signal the TTSI. B) Impact on IETF protocols: We don't foresee any changes to any other IETF protocol except those noted in this correspondence. Specifically we don't foresee any changes required to BGP and PIM. C) Impact on forwarding plane: There is no requirement in Y.1711 to intercept OAM packets or to inspect subsequent header/label when it should not (such as in PHP case). We feel sure that Y.1711 is fully backward compatible with all MPLS standards. D) There is a requirement in Y.1711 to inject an OAM packet (i.e., FDI packet) in the middle of an LSP. However, this should be possible by software upgrade in LSR as is done in Section 2.3.2 of RFC3032 in which an LSR injects an ICMP packet in the middle of an LSP. E) Impact on current systems and ASICs: Y.1711 recommendation has been developed based on input from various leading vendors. Whether it is possible to implement Y.1711 in the current systems and ASICs depends on the specific vendor's implementation. In general, MPLS forwarding devices can inject IP packets. Therefore, it should be possible to inject non-IP packets by software change. Since Y.1711 permits running CV on selected LSPs, overloading of processor can be avoided by reducing the number of LSPs with CV activated. Attachments: Draft Rec. Y.1710/Cor. 1, draft Rec. Y.1711 and draft Rec. Y.1720 may be reviewed at http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.html. From owner-mpls@UU.NET Thu Jul 11 09:46:15 2002 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 ESMTP id JAA18344 for ; Thu, 11 Jul 2002 09:46:15 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxbb11404 for ; Thu, 11 Jul 2002 13:47:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxbb11038; Thu, 11 Jul 2002 13:46:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxbb05458 for mpls-outgoing; Thu, 11 Jul 2002 13:46:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmxbb05453 for ; Thu, 11 Jul 2002 13:46: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 QQmxbb05037 for ; Thu, 11 Jul 2002 13:46:21 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxbb10777 for ; Thu, 11 Jul 2002 13:46:21 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmxbb10766 for ; Thu, 11 Jul 2002 13:46:20 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA29299 for ; Thu, 11 Jul 2002 09:46:20 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05614 for mpls@uu.net; Thu, 11 Jul 2002 09:46:20 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmxao13919 for ; Thu, 11 Jul 2002 10:34:56 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 QQmxao10283 for ; Thu, 11 Jul 2002 10:34:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxao27480 for ; Thu, 11 Jul 2002 10:34:20 GMT Received: from mail1.hd.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hdfdns01.hd.intel.com [192.52.58.10]) id QQmxao27476 for ; Thu, 11 Jul 2002 10:34:20 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by mail1.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6BAYJ019126 for ; Thu, 11 Jul 2002 10:34:19 GMT Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002071103333409278 for ; Thu, 11 Jul 2002 03:33:34 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 12:32:09 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A01FB4A5F@alpha.igk.intel.com> From: "Szymanski, Pawel" To: "'mpls@UU.NET'" Subject: L3 protocol in LSP Date: Thu, 11 Jul 2002 12:32:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-2" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a few questions concerning L3 protocol type for ER LSPs. 1) RSVP-TE has L3PID field indicating the L3 porotocol type send through the path. Does it means that each LSP can carry packets of only one L3 protocol ? 2) Does CR-LDP have a similar field indicating typ eof L3 protocol ? 3) How can I specify in MPLS-TE-MIB the L3 protocol for ER-LSP ? Thanks in advance, Pawel Szymanski From owner-mpls@UU.NET Thu Jul 11 13:56:20 2002 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 ESMTP id NAA28136 for ; Thu, 11 Jul 2002 13:56:20 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxbr28593 for ; Thu, 11 Jul 2002 17:57:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxbr28313; Thu, 11 Jul 2002 17:57:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxbr22867 for mpls-outgoing; Thu, 11 Jul 2002 17:56:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmxbr22862 for ; Thu, 11 Jul 2002 17:56: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 QQmxbr12998 for ; Thu, 11 Jul 2002 17:55:49 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxbr13797 for ; Thu, 11 Jul 2002 17:55:48 GMT Received: from exchange.tropicnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50]) id QQmxbr13792 for ; Thu, 11 Jul 2002 17:55:48 GMT Received: from tropicnetworks.com ([10.1.5.113]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 11 Jul 2002 13:55:47 -0400 Message-ID: <3D2DC6A3.5CBDBCED@tropicnetworks.com> Date: Thu, 11 Jul 2002 13:55:47 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Bradner CC: mpls@UU.NET Subject: Re: message #1 from ITU-T SG 13 References: <200207111156.g6BBufR15928@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2002 17:55:47.0909 (UTC) FILETIME=[2FD80750:01C22904] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The request in message #1 sounds like a reasonable one. I don't see any reason why it should not be approved? Nabil Seddigh Scott Bradner wrote: > > we have received some liaison statement from ITU-T SG 13 > I will send them in seperate messages > > they will be discussed during the MPLS session in Yokohama > > Scott > > message #1 > --------------------------------------- > ITU - Telecommunication Standardization Sector > 8 July 2002 > > QUESTIONS: 3/13 > SOURCE: ITU-T Working Party 3/13 meeting (Chitose, Japan, 8 July 2002) > TITLE: Request for the assignment of a reserved label value of 14 for MPLS > OAM packet identification > _____________ > LIAISON STATEMENT > TO: IETF Sub-IP Area (Scott Bradner, Area Co-Director) > APPROVAL: Agreed to at WP 3/13 meeting > FOR: Action > DEADLINE: 31 August 2002 > CONTACT: Hiroshi Ohta Tel: +81 422 59 3617 > NTT Fax: +81 422 59 3787 > 3-9-11 Midori-cho Musashino-shi > Email: ohta.hiroshi@lab.ntt.co.jp > Tokyo 180-8585 Japan > > ITU-T SG 13 repeats its request that a reserved label value of 14 be > assigned for MPLS OAM packet identification as indicated in < > draft-ohta-mpls-label-value-01.txt>. This was the only method for OAM > packet identification that did not raise any objections when discussed on > the MPLS list over a year ago. Using the reserved label value guarantees > backward compatibility with all the MPLS standards and implementations. > Concerning the development of Recommendations related to MPLS OAM, please > also note the followings: > > (1) draft Recommendations Y.1710/Cor. 1 (MPLS OAM requirements) and Y.1711 > (MPLS OAM mechanism) have passed the last call and are planned to be > approved at the next SG 13 meeting in October/November 2002; > (2) draft Recommendation Y.1720 (MPLS OAM protection) is expected to be > approved in November/December 2002 time frame. > > Attachments: Draft Rec. Y.1710/Cor. 1, draft Rec. Y.1711 and draft Rec. > Y.1720 may be reviewed at > http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.html From owner-mpls@UU.NET Thu Jul 11 14:36:09 2002 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 ESMTP id OAA00221 for ; Thu, 11 Jul 2002 14:36:09 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxbu26676 for ; Thu, 11 Jul 2002 18:36:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxbu26333; Thu, 11 Jul 2002 18:36:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxbu17921 for mpls-outgoing; Thu, 11 Jul 2002 18:36:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmxbu17859 for ; Thu, 11 Jul 2002 18:36:14 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 QQmxbu14248 for ; Thu, 11 Jul 2002 18:35:43 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxbu10732 for ; Thu, 11 Jul 2002 18:35:43 GMT Received: from exchange.tropicnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50]) id QQmxbu10716 for ; Thu, 11 Jul 2002 18:35:43 GMT Received: from tropicnetworks.com ([10.1.5.113]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 11 Jul 2002 14:35:42 -0400 Message-ID: <3D2DCFFE.A4929B7C@tropicnetworks.com> Date: Thu, 11 Jul 2002 14:35:42 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ping Pan CC: mpls@UU.NET Subject: Re: LSP Liveliness References: <3D29B9DF.CA68F8EF@tropicnetworks.com> <3D29CA27.2010308@juniper.net> <3D2CAE41.BA5C605D@tropicnetworks.com> <3D2CB313.90605@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2002 18:35:42.0564 (UTC) FILETIME=[C32B6240:01C22909] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ping, I can see the desire to move on because for some not-too-clear reason the IESG did not approve the ICMP-based approach to MPLS Traceroute. IMHO, the ICMP-based approach to mpls traceroute is cleaner than the UDP method proposed in the draft. It is unfortunate that the IESG cannot revisit the issue in question - especially since there is running deployed code for the icmp-based solution. What was the IETF's motto again: something to do with running code, and no kings :) In any case, the document could benefit from some cleanup wrt terminology. Here is an example paragraph: "In this document, we describe a mechanism, termed "MPLS ping", that accomplishes these goals. This mechanism is modeled after the ICMP echo request/reply, used by ping and traceroute to detect and localize faults in IP networks. " traceroute didn't use icmp echo req/reply and the name MPLS ping is misleading. Suggest the name LSP debug or something like that be used as a term that encompasses ping and traceroute. Best, Nabil > > 2. Could have a technical solution that is a super-set of existing > > LSP TR and Ping functionality (hence the suggestion of ICMP > > as a possible return mechanism). > > > > After what had happened in the last several years, I'm afraid that we > are getting over the ICMP solution by now. There are two equally good > solutions (ICMP and UDP), and one of them (ICMP) had caused trouble > before, let's just develope the darn thing with the other solution. > IMHO, the primary task is to solve the actual problem with actual > running code as soon as possible. No? :-) > > Regards, > > - Ping From owner-mpls@UU.NET Thu Jul 11 14:46:39 2002 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 ESMTP id OAA00779 for ; Thu, 11 Jul 2002 14:46:38 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxbv19263 for ; Thu, 11 Jul 2002 18:47:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxbv18976; Thu, 11 Jul 2002 18:47:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxbv18901 for mpls-outgoing; Thu, 11 Jul 2002 18:46:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmxbv18894 for ; Thu, 11 Jul 2002 18:46: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 QQmxbv18192 for ; Thu, 11 Jul 2002 18:46:26 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxbv07532 for ; Thu, 11 Jul 2002 18:46:26 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQmxbv07523 for ; Thu, 11 Jul 2002 18:46:26 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g6BIkOm73203; Thu, 11 Jul 2002 11:46:24 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200207111846.g6BIkOm73203@merlot.juniper.net> To: Nabil Seddigh cc: Ping Pan , mpls@UU.NET Subject: Re: LSP Liveliness In-Reply-To: Your message of "Thu, 11 Jul 2002 14:35:42 EDT." <3D2DCFFE.A4929B7C@tropicnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59530.1026413184.1@juniper.net> Date: Thu, 11 Jul 2002 11:46:24 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Nabil, > I can see the desire to move on because for some not-too-clear > reason the IESG did not approve the ICMP-based approach to > MPLS Traceroute. IMHO, the ICMP-based approach to mpls traceroute > is cleaner than the UDP method proposed in the draft. It is > unfortunate that the IESG cannot revisit the issue in question - > especially since there is running deployed code for the icmp-based > solution. Given that there is running deployed code (with multiple interoperable implementations), why does it really matter from the *practical* point of view whether the IESG did, or did not approve it ? > What was the IETF's motto again: something to do with > running code, and no kings :) That is the theory of the IETF. But as you know while in theory there is no difference between the theory and the practice, in practice there is :-) Yakov. > > In any case, the document could benefit from some cleanup wrt > terminology. Here is an example paragraph: > > "In this document, we describe a mechanism, termed "MPLS ping", > that accomplishes these goals. This mechanism is modeled > after the ICMP echo request/reply, used by ping and traceroute > to detect and localize faults in IP networks. " > > traceroute didn't use icmp echo req/reply and the name MPLS > ping is misleading. > > Suggest the name LSP debug or something like that be used > as a term that encompasses ping and traceroute. > > Best, > Nabil > > > > 2. Could have a technical solution that is a super-set of existing > > > LSP TR and Ping functionality (hence the suggestion of ICMP > > > as a possible return mechanism). > > > > > > > After what had happened in the last several years, I'm afraid that we > > are getting over the ICMP solution by now. There are two equally good > > solutions (ICMP and UDP), and one of them (ICMP) had caused trouble > > before, let's just develope the darn thing with the other solution. > > IMHO, the primary task is to solve the actual problem with actual > > running code as soon as possible. No? :-) > > > > Regards, > > > > - Ping From owner-mpls@UU.NET Thu Jul 11 18:32:43 2002 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 ESMTP id SAA10178 for ; Thu, 11 Jul 2002 18:32:43 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxck17169 for ; Thu, 11 Jul 2002 22:33:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxck16864; Thu, 11 Jul 2002 22:33:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxck05165 for mpls-outgoing; Thu, 11 Jul 2002 22:33:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmxck05156 for ; Thu, 11 Jul 2002 22:32: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 QQmxck04418 for ; Thu, 11 Jul 2002 22:30:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxck22748 for ; Thu, 11 Jul 2002 22:30:56 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 QQmxck22729 for ; Thu, 11 Jul 2002 22:30:55 GMT Received: from tomp.smb.utfors.se ([127.0.0.1]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GZ3W4200.MPQ for ; Fri, 12 Jul 2002 00:36:02 +0200 From: Loa Andersson To: mpls@UU.NET Message-ID: <9417a0ee.a0ee9417@tomp.smb.utfors.se> Date: Fri, 12 Jul 2002 00:36:02 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Updated: MPLS wg agenda X-Accept-Language: en Content-Type: multipart/mixed; boundary="--687e3e0021442f72" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ----687e3e0021442f72 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit All, I've made some small updates to the mpls wg agenda, will be found at: http://62.119.0.68/~loa/mpls_agenda_for_yokohama.htm the changes are minor, e.g correcting draft versions. You will also notice that the allocated time won't come to exactly the 2.5 hours that we have, will work on that with the people on the agenda. Again, please let me know if you find anything that need to be corrected. I've added a short report from the SG13/Q3, but do not yet know how will make the report. /Loa ----687e3e0021442f72 Content-Type: text/x-vcard; name="loa.andersson.vcf"; charset=us-ascii Content-Disposition: attachment; filename="loa.andersson.vc" Content-Description: Card for Loa Andersson Content-Transfer-Encoding: 7bit begin:vcard version:2.1 end:vcard ----687e3e0021442f72-- From owner-mpls@UU.NET Thu Jul 11 20:20:21 2002 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 ESMTP id UAA15118 for ; Thu, 11 Jul 2002 20:20:21 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxcr04126 for ; Fri, 12 Jul 2002 00:21:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxcr03552; Fri, 12 Jul 2002 00:20:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxcr27271 for mpls-outgoing; Fri, 12 Jul 2002 00:20:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmxcr27262 for ; Fri, 12 Jul 2002 00: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 QQmxcr02984 for ; Fri, 12 Jul 2002 00:16:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxcr01031 for ; Fri, 12 Jul 2002 00:16:28 GMT Received: from gateway.ipinfusion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.223.109.2]) id QQmxcr01020 for ; Fri, 12 Jul 2002 00:16:28 GMT Received: from ipinfusion.com ([10.10.0.225]) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id g6C0F6H05638; Thu, 11 Jul 2002 17:15:06 -0700 Message-ID: <3D2E1F9F.835ACBFD@ipinfusion.com> Date: Thu, 11 Jul 2002 17:15:27 -0700 From: Yuan Gu Organization: IP Infusion Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, mpls-ops@mplsrc.com Subject: rsvp refresh question Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: In RFC2205, the refresh mechanism is defined not only to refresh the state but also to UPDATE the state maintained by RSVP(Section 2.3, page 23). But in RFC3209 or any other document, there is no clearify about this. Is this refresh UPDATE concept automaticly extended to RSVP-TE? If so, beside update the QoS parameters, we also can use refresh msg to update other parameters such as ERO, Session_Attribute and Label? Then we don't need "make before break" any more? What's the pros and cons to use refresh msg to modify the existing LSP? At last, can anybody clearify how cisco and Juniper handle this issue? Do they compare every bit of received refresh msg with exiting states? Thanks alot! Yuan From owner-mpls@UU.NET Fri Jul 12 08:35:51 2002 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 ESMTP id IAA19665 for ; Fri, 12 Jul 2002 08:35:50 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxeo15930 for ; Fri, 12 Jul 2002 12:36:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxeo15571; Fri, 12 Jul 2002 12:36:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxeo16876 for mpls-outgoing; Fri, 12 Jul 2002 12:36:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmxeo16871 for ; Fri, 12 Jul 2002 12:36: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 QQmxeo26082 for ; Fri, 12 Jul 2002 12:34:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxeo14150 for ; Fri, 12 Jul 2002 12:34:09 GMT Received: from osf1.gmu.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQmxeo14146 for ; Fri, 12 Jul 2002 12:34:09 GMT Received: from localhost (bjabbari@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id IAA23660; Fri, 12 Jul 2002 08:34:09 -0400 (EDT) Date: Fri, 12 Jul 2002 08:34:09 -0400 (EDT) From: Bijan Jabbari To: Navid Yazdani cc: mpls@UU.NET Subject: Re: QoS Survey Paper Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Navid, A paper titled Differentiated Services in the Internet, coauthored by Brian Carpenter and Kathleen Nichols (co-chairs of the IETF Diffserv WG) will appear in the September 2002 issue of the Proceedings of the IEEE. The paper reviews various architectures proposed for QoS and then discusses in some detail the Diffserv approach for Internet. This Special Issue of the Proceedings of the IEEE, which we finalized a couple of months ago, focuses on Internet technology and communications services convergence. It has been edited by D. Awduche, Y. Rekhter, J. Walrand and myself. - Bijan Jabbari ----- Original Message ----- From: "Navid Yazdani" Date: Tuesday, July 2, 2002 11:26 am Subject: QoS Survey Paper > Can anyone recommend a survey paper, article, or book that > examines the > advantages and disadvantages of different IP QoS schemes? > > thanks > Navid > > > -------------------------------------- Bijan Jabbari, PhD Professor of Electrical Engineering George Mason University email: bjabbari@gmu.edu From owner-mpls@UU.NET Fri Jul 12 10:32:57 2002 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 ESMTP id KAA24731 for ; Fri, 12 Jul 2002 10:32:56 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxew21191 for ; Fri, 12 Jul 2002 14:33:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxew20574; Fri, 12 Jul 2002 14:33:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxew09792 for mpls-outgoing; Fri, 12 Jul 2002 14:33:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmxew09787 for ; Fri, 12 Jul 2002 14:33:03 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 QQmxew29031 for ; Fri, 12 Jul 2002 14:31:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxew07517 for ; Fri, 12 Jul 2002 14:31:15 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmxew07513 for ; Fri, 12 Jul 2002 14:31:15 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA19079 for ; Fri, 12 Jul 2002 10:31:14 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA25758 for mpls@uu.net; Fri, 12 Jul 2002 10:31:14 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmxdh14176 for ; Fri, 12 Jul 2002 04:26: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 QQmxdh20395 for ; Fri, 12 Jul 2002 04:26:04 GMT From: bjabbari@gmu.edu Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxdh18304 for ; Fri, 12 Jul 2002 04:26:03 GMT 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 QQmxdh18298 for ; Fri, 12 Jul 2002 04:26:03 GMT Received: from gmu.edu (mail03.gmu.edu [129.174.0.113]) by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id AAA07101; Fri, 12 Jul 2002 00:26:02 -0400 (EDT) To: "Navid Yazdani" Cc: mpls@UU.NET Message-ID: <3df4473e334f.3e334f3df447@gmu.edu> Date: Fri, 12 Jul 2002 00:26:01 -0400 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: QoS Survey Paper 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 KAA24731 Navid, A paper titled “Differentiated Services in the Internet,” coauthored by Brian Carpenter and Kathleen Nichols (co-chairs of the IETF Diffserv WG) will appear in the September 2002 issue of the Proceedings of the IEEE. The paper reviews various architectures proposed for QoS and then discusses in some detail the Diffserv approach for Internet. This Special Issue of the Proceedings of the IEEE, which we finalized a couple of months ago, focuses on Internet technology and communications services convergence. It has been edited by D. Awduche, Y. Rekhter, J. Walrand and myself. - Bijan Jabbari ----- Original Message ----- From: "Navid Yazdani" Date: Tuesday, July 2, 2002 11:26 am Subject: QoS Survey Paper > Can anyone recommend a survey paper, article, or book that > examines the > advantages and disadvantages of different IP QoS schemes? > > thanks > Navid > > > > From owner-mpls@UU.NET Fri Jul 12 11:11:42 2002 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 ESMTP id LAA26811 for ; Fri, 12 Jul 2002 11:11:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxey03640 for ; Fri, 12 Jul 2002 15:12:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxey01639; Fri, 12 Jul 2002 15:11:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxey04863 for mpls-outgoing; Fri, 12 Jul 2002 15:11:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmxey04819 for ; Fri, 12 Jul 2002 15:11: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 QQmxey06867 for ; Fri, 12 Jul 2002 15:10:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxey01075 for ; Fri, 12 Jul 2002 15:10:22 GMT Received: from web20805.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20805.mail.yahoo.com [216.136.226.194]) id QQmxey01071 for ; Fri, 12 Jul 2002 15:10:22 GMT Message-ID: <20020712151021.3770.qmail@web20805.mail.yahoo.com> Received: from [134.193.6.40] by web20805.mail.yahoo.com via HTTP; Fri, 12 Jul 2002 08:10:21 PDT Date: Fri, 12 Jul 2002 08:10:21 -0700 (PDT) From: senthil ayyasamy Subject: Re: QoS Survey Paper To: bjabbari@gmu.edu, Navid Yazdani Cc: mpls@UU.NET In-Reply-To: <3df4473e334f.3e334f3df447@gmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk > A paper titled “Differentiated Services in the > Internet,” coauthored > by Brian Carpenter and Kathleen Nichols (co-chairs > of the IETF Diffserv > WG) will appear in the September 2002 issue of the > Proceedings of the > IEEE. The paper reviews various architectures > proposed for QoS and then > discusses in some detail the Diffserv approach for > Internet. http://www.packetdesign.com/publications.html You can get a preprint copy of the above paper from packetdesign or IBM site. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-mpls@UU.NET Fri Jul 12 12:28:41 2002 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 ESMTP id MAA01929 for ; Fri, 12 Jul 2002 12:28:41 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxfd19731 for ; Fri, 12 Jul 2002 16:29:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxfd19387; Fri, 12 Jul 2002 16:29:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxfd07511 for mpls-outgoing; Fri, 12 Jul 2002 16:29:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmxfd07506 for ; Fri, 12 Jul 2002 16:29: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 QQmxfd20331 for ; Fri, 12 Jul 2002 16:28:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxfd18925 for ; Fri, 12 Jul 2002 16:28:31 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmxfd18916 for ; Fri, 12 Jul 2002 16:28:30 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA27781 for ; Fri, 12 Jul 2002 12:28:30 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA08702 for mpls@uu.net; Fri, 12 Jul 2002 12:28:30 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmxfd07033 for ; Fri, 12 Jul 2002 16:23:13 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 QQmxfd17883 for ; Fri, 12 Jul 2002 16:22:22 GMT From: bjabbari@gmu.edu Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxfd22381 for ; Fri, 12 Jul 2002 16:22:22 GMT Received: from portal.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: portalknot.gmu.edu [129.174.0.8]) id QQmxfd22372 for ; Fri, 12 Jul 2002 16:22:21 GMT Received: from gmu.edu (mail03.gmu.edu [129.174.0.113]) by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id MAA09981; Fri, 12 Jul 2002 12:22:19 -0400 (EDT) To: senthil ayyasamy Cc: Navid Yazdani , mpls@UU.NET Message-ID: <3fbbb73f7cb7.3f7cb73fbbb7@gmu.edu> Date: Fri, 12 Jul 2002 12:22:19 -0400 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: QoS Survey Paper 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 MAA01929 This is an earlier version of the submisson, prior to the peer review process. - BJ ----- Original Message ----- From: senthil ayyasamy Date: Friday, July 12, 2002 11:10 am Subject: Re: QoS Survey Paper > > A paper titled “Differentiated Services in the > > Internet,” coauthored > > by Brian Carpenter and Kathleen Nichols (co-chairs > > of the IETF Diffserv > > WG) will appear in the September 2002 issue of the > > Proceedings of the > > IEEE. The paper reviews various architectures > > proposed for QoS and then > > discusses in some detail the Diffserv approach for > > Internet. > http://www.packetdesign.com/publications.html > You can get a preprint copy of the above paper from > packetdesign or IBM site. > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > > From owner-mpls@UU.NET Fri Jul 12 19:02:36 2002 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 ESMTP id TAA18765 for ; Fri, 12 Jul 2002 19:02:36 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxge17331 for ; Fri, 12 Jul 2002 23:03:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxge16734; Fri, 12 Jul 2002 23:03:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxge15193 for mpls-outgoing; Fri, 12 Jul 2002 23:03:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmxge15173 for ; Fri, 12 Jul 2002 23:02:53 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 QQmxge12963 for ; Fri, 12 Jul 2002 23:01:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxge28575 for ; Fri, 12 Jul 2002 23:01:22 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 QQmxge28567 for ; Fri, 12 Jul 2002 23:01:22 GMT Received: from MDUFFY ([10.1.3.119]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 348HGZPY; Fri, 12 Jul 2002 19:01:21 -0400 Message-Id: <3.0.5.32.20020712185758.008d4e20@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Jul 2002 18:57:58 -0400 To: mpls@UU.NET From: Mark Duffy Subject: LDP discovery, generic encap on atm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a question about LDP discovery when running over an NBMA network using generic shim encapsulation. (I.e. *not* LC-ATM) RFC 3036 states in sect 2.4 that Basic Discovery is used to discover LSR neighbors that are directly connected at the link level, and that it does this using multicast addressing. If one wants to run LDP across an NBMA atm network with no multicast capability, one presumably needs to configure the neighbors. Should the Extended Discovery mechanism be used? It seems like just the ticket, other than that rfc 3036 states that it is used to locate LSRs that are not directly connected at the link level. Thanks, Mark From owner-mpls@UU.NET Sun Jul 14 03:50:01 2002 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 ESMTP id DAA27872 for ; Sun, 14 Jul 2002 03:50:01 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxlf25330 for ; Sun, 14 Jul 2002 07:50:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxlf24174; Sun, 14 Jul 2002 07:50:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxlf06227 for mpls-outgoing; Sun, 14 Jul 2002 07:50:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmxlf06218 for ; Sun, 14 Jul 2002 07:49:57 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 QQmxlf04689 for ; Sun, 14 Jul 2002 07:49:37 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxlf24576 for ; Sun, 14 Jul 2002 07:49:36 GMT Received: from smtp.seven7s.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp.gega.net [212.103.160.188]) id QQmxlf24570 for ; Sun, 14 Jul 2002 07:49:36 GMT Received: (qmail 7611 invoked from network); 14 Jul 2002 07:47:38 -0000 Received: from unknown (HELO zozo.tedata.net) (212.103.160.163) by 0 with SMTP; 14 Jul 2002 07:47:38 -0000 Message-Id: <5.1.0.14.0.20020714104537.02a39e80@mailer1.idsc.net.eg> X-Sender: azyousef@mailer1.idsc.net.eg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 14 Jul 2002 10:49:15 +0300 To: majordomo@UU.NET From: Azza Yousef Subject: What is the current state of MPLS Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dear All, I need to know the current state of MPLS as a new technology? Waiting for your reply, Azza Best Regards, Azza Yousef Networks Engineer T.E. DATA Tel: +(202)-7494025 Ext: 1122 Fax : +(202)-3364335 From owner-mpls@UU.NET Sun Jul 14 04:10:55 2002 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 ESMTP id EAA28311 for ; Sun, 14 Jul 2002 04:10:55 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxlg05360 for ; Sun, 14 Jul 2002 08:11:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxlg05143; Sun, 14 Jul 2002 08:11:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxlg29547 for mpls-outgoing; Sun, 14 Jul 2002 08:11:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmxlg29513 for ; Sun, 14 Jul 2002 08:11:09 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 QQmxlg03686 for ; Sun, 14 Jul 2002 08:10:01 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxlg04550 for ; Sun, 14 Jul 2002 08:10:00 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 QQmxlg04522 for ; Sun, 14 Jul 2002 08:09:59 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g6E89ke02784 for ; Sun, 14 Jul 2002 13:39:47 +0530 (IST) Received: from boochi.wipro.com ([10.117.3.144]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GZ8C0100.9TR; Sun, 14 Jul 2002 13:39:37 +0530 Date: Sun, 14 Jul 2002 13:45:27 +0400 (RET) From: "Nagabhushana Ramaswamy Nadig" X-X-Sender: Reply-To: To: Azza Yousef cc: Subject: Re: What is the current state of MPLS In-Reply-To: <5.1.0.14.0.20020714104537.02a39e80@mailer1.idsc.net.eg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Sun, 14 Jul 2002, Azza Yousef wrote: > Dear All, > I need to know the current state of MPLS as a new technology? It is no more a new technology...;) checkup www.mplsrc.com cheers Bhushana > > Waiting for your reply, > Azza > > Best Regards, > Azza Yousef > Networks Engineer > T.E. DATA > Tel: +(202)-7494025 Ext: 1122 > Fax : +(202)-3364335 > > From owner-mpls@UU.NET Tue Jul 16 12:30:04 2002 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 ESMTP id MAA23346 for ; Tue, 16 Jul 2002 12:30:04 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxty02384 for ; Tue, 16 Jul 2002 16:30:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxty02071; Tue, 16 Jul 2002 16:30:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxty23166 for mpls-outgoing; Tue, 16 Jul 2002 16:30:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmxty23161 for ; Tue, 16 Jul 2002 16:30:17 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 QQmxtx22476 for ; Tue, 16 Jul 2002 16:29:28 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxtx13979 for ; Tue, 16 Jul 2002 16:29:28 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 QQmxtx13972 for ; Tue, 16 Jul 2002 16:29:28 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 MAA19238 for ; Tue, 16 Jul 2002 12:29:25 -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 MAA25300 for ; Tue, 16 Jul 2002 12:29:25 -0400 (EDT) Message-ID: <3D3449E5.5030907@marconi.com> Date: Tue, 16 Jul 2002 12:29:25 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: rsvp refresh question References: <3D2E1F9F.835ACBFD@ipinfusion.com> Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yuan Gu wrote: > > In RFC2205, the refresh mechanism is defined not only to refresh the > state but also to UPDATE the state maintained by RSVP(Section 2.3, page 23). Correct. RSVP is a soft-state protocol, which means that state may dynamically change, simply by changing a parameter at the next refresh message. > But in RFC3209 or any other document, there is no clearify about > this. Is this refresh UPDATE concept automaticly extended to RSVP-TE? Yes, but it is not recommended. The make-before-break mechanism is the recommended way to modify an LSP. An RSVP-TE implementation should be prepared to deal with modifications that may take place as a part of refreshes, but edge routers should not expect all transit routers to be able to properly handle such changes. > If so, beside update the QoS parameters, we also can use refresh msg to > update other parameters such as ERO, Session_Attribute and Label? Then > we don't need "make before break" any more? What's the pros and cons to > use refresh msg to modify the existing LSP? At last, can anybody > clearify how cisco and Juniper handle this issue? Do they compare every > bit of received refresh msg with exiting states? Changing innocuous things, like TIME_VALUES, and ADSPEC objects probably won't break anything, since they are usually processed entirely within RSVP. Changing things that affect a connection's properties (like SESSION_ATTRIBUTES, LABEL, FLOWSPEC, etc.) may not be possible on some platforms. Not all forwarding hardware has the ability to modify an in- place connection. Some hardware can only modify a connection by tearing it down, and then creating a new one - which will involve a time period during which the data-plane is broken. This will be unacceptible in a production network. Changing things that affect the LSP's route (like the ERO) will result in a time period where the LSP may flap many times between two different routes, or may even temporarily go down. It's a little bit difficult to explin the situation in e-mail, but I'll try if you insist. Suffice it to say that dynamically changing an ERO will almost certainly result in an interruption of data-plane forwarding, which is unacceptible in a production network. -- David From owner-mpls@UU.NET Tue Jul 16 15:33:13 2002 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 ESMTP id PAA27898 for ; Tue, 16 Jul 2002 15:33:13 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxuk04395 for ; Tue, 16 Jul 2002 19:34:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxuk03835; Tue, 16 Jul 2002 19:33:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxuk24449 for mpls-outgoing; Tue, 16 Jul 2002 19:33:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmxuk24434 for ; Tue, 16 Jul 2002 19:33:08 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 QQmxuk27995 for ; Tue, 16 Jul 2002 19:32:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxuk03380 for ; Tue, 16 Jul 2002 19:32:36 GMT Received: from djswamp.layer8.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: soggy131.drizzle.com [216.162.199.131]) id QQmxuk03338 for ; Tue, 16 Jul 2002 19:32:32 GMT Received: (qmail 49950 invoked by uid 1000); 16 Jul 2002 19:32:26 -0000 Date: Tue, 16 Jul 2002 12:32:26 -0700 From: Ben Black To: mpls@UU.NET Subject: Please advance draft-ietf-mpls-ldp-mtu-extensions-00 to IESG Message-ID: <20020716193226.GC49043@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.99i Sender: owner-mpls@UU.NET Precedence: bulk Chairs: Please submit draft-ietf-mpls-ldp-mtu-extensions-00 to the IESG for comment. It's been well-abused on the list, in private email, and in 2 working group meetings. Ben From owner-mpls@UU.NET Wed Jul 17 03:23:12 2002 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 ESMTP id DAA08343 for ; Wed, 17 Jul 2002 03:23:11 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxwf22733 for ; Wed, 17 Jul 2002 07:24:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxwf22284; Wed, 17 Jul 2002 07:23:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxwf11634 for mpls-outgoing; Wed, 17 Jul 2002 07:23:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmxwf11629 for ; Wed, 17 Jul 2002 07:23:41 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 QQmxwf00131 for ; Wed, 17 Jul 2002 07:22:53 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxwf15046 for ; Wed, 17 Jul 2002 07:22:52 GMT Received: from blooper.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmxwf15030 for ; Wed, 17 Jul 2002 07:22:51 GMT Received: from utfors.se ([195.58.105.85]) by blooper.utfors.se (Utfors AB) with ESMTP id g6H7Mh5F010203 for ; Wed, 17 Jul 2002 09:22:45 +0200 (MEST) Message-ID: <3D351B42.8020806@utfors.se> Date: Wed, 17 Jul 2002 09:22:42 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: MPLS wg Subject: improved agenda for the mpls meeting in Yokohama Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, some slight changes to the agenda for the mpls meeting Yokohama to be found at: http://62.119.0.68/~loa/mpls_agenda_for_yokohama.htm the agenda is still over full, but I hope that some topics may be shorter than the standard 10 min, and that we will be able cram everything in. /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 Jul 17 16:03:18 2002 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 ESMTP id QAA28694 for ; Wed, 17 Jul 2002 16:03:17 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxye26849 for ; Wed, 17 Jul 2002 20:04:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxye26343; Wed, 17 Jul 2002 20:03:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxye23305 for mpls-outgoing; Wed, 17 Jul 2002 20:03:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmxye23300 for ; Wed, 17 Jul 2002 20:03: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 QQmxye29831 for ; Wed, 17 Jul 2002 20:02:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxye24877 for ; Wed, 17 Jul 2002 20:02:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmxye24873 for ; Wed, 17 Jul 2002 20:02:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA02826 for ; Wed, 17 Jul 2002 16:02:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA22618 for mpls@uu.net; Wed, 17 Jul 2002 16:02:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmxye18841 for ; Wed, 17 Jul 2002 20:01: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 QQmxye22205 for ; Wed, 17 Jul 2002 20:01:27 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxye24682 for ; Wed, 17 Jul 2002 20:01:26 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f298.law10.hotmail.com [64.4.14.173]) id QQmxye24670 for ; Wed, 17 Jul 2002 20:01:26 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Jul 2002 13:01:25 -0700 Received: from 198.242.58.71 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 17 Jul 2002 20:01:25 GMT X-Originating-IP: [198.242.58.71] From: "manoj juneja" To: mpls@UU.NET Subject: Sender Template Doubt Date: Wed, 17 Jul 2002 13:01:25 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jul 2002 20:01:25.0703 (UTC) FILETIME=[BB329D70:01C22DCC] Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I have a doubt regarding sender template object in RSVP-TE. Can I fill the sender address in sender template object same as PHOP address (in RSVP_HOP object) at the ingress node in the outgoing path message ? As per my understanding, the PHOP object will change at every hop in the path message but the sender template remanins the same. At the ingress node, should the sender address in sender template object be filled with the IP address of the outgoing interface over which the path message is to be sent out ? Regards, manoj. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Wed Jul 17 17:30:13 2002 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 ESMTP id RAA00281 for ; Wed, 17 Jul 2002 17:30:12 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxyk01190 for ; Wed, 17 Jul 2002 21:31:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxyk00396; Wed, 17 Jul 2002 21:30:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxyk02912 for mpls-outgoing; Wed, 17 Jul 2002 21:30:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmxyk02907 for ; Wed, 17 Jul 2002 21:30:32 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 QQmxyj04198 for ; Wed, 17 Jul 2002 21:29:46 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxyj29652 for ; Wed, 17 Jul 2002 21:29:45 GMT Received: from mlsrv1.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQmxyj29648 for ; Wed, 17 Jul 2002 21:29:45 GMT Received: from jkarthik-pc.avici.com (jkarthik-pc.avici.com [10.2.22.72]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g6HLTZn21327; Wed, 17 Jul 2002 17:29:35 -0400 (EDT) Message-Id: <5.0.2.1.2.20020717171846.00a63310@mailhost.avici.com> X-Sender: jkarthik@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 17 Jul 2002 17:32:20 -0400 To: "manoj juneja" , mpls@UU.NET From: Jay Karthik Subject: Re: Sender Template Doubt Cc: pbeeram@avici.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 01:01 PM 7/17/02 -0700, manoj juneja wrote: >Hi All, > I have a doubt regarding sender template object in RSVP-TE. Can > I fill the sender address in sender template object same as PHOP address > (in RSVP_HOP object) at the ingress node in the outgoing path message ? > >As per my understanding, the PHOP object will change at every hop in the >path message but the sender template remanins the same. > >At the ingress node, should the sender address in sender template object >be filled with the IP address of the outgoing interface over which the >path message is to be sent out ? It is not mandatory to send the IP address of the outgoing i/f. Usually it is the router-id of the Ingress. (However for a backup tunnel you could pick any address besides the router-id, as the sender address in the SENDER_TEMPLATE). Jay >Regards, >manoj. > >_________________________________________________________________ >Send and receive Hotmail on your mobile device: http://mobile.msn.com > From owner-mpls@UU.NET Wed Jul 17 18:02:01 2002 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 ESMTP id SAA00976 for ; Wed, 17 Jul 2002 18:02:01 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxym03171 for ; Wed, 17 Jul 2002 22:02:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxym02673; Wed, 17 Jul 2002 22:02:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxym16774 for mpls-outgoing; Wed, 17 Jul 2002 22:02:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmxym16765 for ; Wed, 17 Jul 2002 22:02: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 QQmxym11798 for ; Wed, 17 Jul 2002 22:02:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxym00936 for ; Wed, 17 Jul 2002 22:02:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmxym00930 for ; Wed, 17 Jul 2002 22:02:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA12059 for ; Wed, 17 Jul 2002 18:02:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA05701 for mpls@uu.net; Wed, 17 Jul 2002 18:02:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmxym07921 for ; Wed, 17 Jul 2002 22:00: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 QQmxym06418 for ; Wed, 17 Jul 2002 22:00:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxym00193 for ; Wed, 17 Jul 2002 22:00:16 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f205.law10.hotmail.com [64.4.15.205]) id QQmxym00188 for ; Wed, 17 Jul 2002 22:00:15 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Jul 2002 15:00:15 -0700 Received: from 198.242.58.71 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 17 Jul 2002 22:00:14 GMT X-Originating-IP: [198.242.58.71] From: "manoj juneja" To: jkarthik@avici.com, mpls@UU.NET Cc: pbeeram@avici.com Subject: Re: Sender Template Doubt Date: Wed, 17 Jul 2002 15:00:14 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jul 2002 22:00:15.0171 (UTC) FILETIME=[54B11930:01C22DDD] Sender: owner-mpls@UU.NET Precedence: bulk Jay, On a node the PSB is identified by the session object and its corresponding sender_template object. Let us take the case where two RSVP-TE tunnels are established between two nodes A and B. The destination address for both the RSVP sessions is same. Furthermore, if the ingress node sends it's router Id in sender template then how a transit node distinguishes between these two PSBs ? Is the distinction between these two PSBs is done on the basis of LSP Id and Tunnel Id as the other fields of SESSION and SENDER_TEMPLATE objects will be same. Regards, manoj. >From: Jay Karthik >To: "manoj juneja" , mpls@UU.NET >CC: pbeeram@avici.com >Subject: Re: Sender Template Doubt >Date: Wed, 17 Jul 2002 17:32:20 -0400 > >At 01:01 PM 7/17/02 -0700, manoj juneja wrote: >>Hi All, >> I have a doubt regarding sender template object in RSVP-TE. Can >>I fill the sender address in sender template object same as PHOP address >>(in RSVP_HOP object) at the ingress node in the outgoing path message ? >> >>As per my understanding, the PHOP object will change at every hop in the >>path message but the sender template remanins the same. >> >>At the ingress node, should the sender address in sender template object >>be filled with the IP address of the outgoing interface over which the >>path message is to be sent out ? > >It is not mandatory to send the IP address of the outgoing i/f. Usually it >is the router-id of the Ingress. (However for a backup tunnel you >could pick any address besides the router-id, as the sender address in the >SENDER_TEMPLATE). > >Jay > > > >>Regards, >>manoj. >> >>_________________________________________________________________ >>Send and receive Hotmail on your mobile device: http://mobile.msn.com >> _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Wed Jul 17 18:04:20 2002 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 ESMTP id SAA01023 for ; Wed, 17 Jul 2002 18:04:20 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxym27160 for ; Wed, 17 Jul 2002 22:05:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxym26535; Wed, 17 Jul 2002 22:04:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxym17649 for mpls-outgoing; Wed, 17 Jul 2002 22:04:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmxym17534 for ; Wed, 17 Jul 2002 22:04:19 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 QQmxym24922 for ; Wed, 17 Jul 2002 22:04:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxym01857 for ; Wed, 17 Jul 2002 22:04: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 QQmxym01853 for ; Wed, 17 Jul 2002 22:04:03 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 SAA13951 for ; Wed, 17 Jul 2002 18:04:01 -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 SAA23179 for ; Wed, 17 Jul 2002 18:04:02 -0400 (EDT) Message-ID: <3D35E9D7.5030404@marconi.com> Date: Wed, 17 Jul 2002 18:04:07 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020717 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Sender Template Doubt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit manoj juneja wrote: > I have a doubt regarding sender template object in RSVP-TE. Can > I fill the sender address in sender template object same as PHOP address > (in RSVP_HOP object) at the ingress node in the outgoing path message ? The sender address in the SENDER_TEMPLATE can be any valid address on the ingress node. My personal preference (and this is _NOT_ a requirement) is to use the address of the interface that the LSP accepts incoming traffic on. In other words, if the LSP only receives unlabeled traffic from one interface, use that address; if the LSP can receive unlabeled traffic from any interface, then use the router address. The reason for this preference is that it makes it a bit easier to see exactly where the traffic in the LSPs is coming from when you're viewing the table of connections. > As per my understanding, the PHOP object will change at every hop in the > path message but the sender template remanins the same. Correct. > At the ingress node, should the sender address in sender template object > be filled with the IP address of the outgoing interface over which the > path message is to be sent out ? That is one legal value you can use. Any other address that is valid for the ingress router is also OK. -- David From owner-mpls@UU.NET Wed Jul 17 18:17:53 2002 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 ESMTP id SAA01210 for ; Wed, 17 Jul 2002 18:17:53 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxyn10668 for ; Wed, 17 Jul 2002 22:18:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxyn09692; Wed, 17 Jul 2002 22:18:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxyn28917 for mpls-outgoing; Wed, 17 Jul 2002 22:18:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmxyn28912 for ; Wed, 17 Jul 2002 22:18: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 QQmxyn27622 for ; Wed, 17 Jul 2002 22:17:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxyn11152 for ; Wed, 17 Jul 2002 22:17:07 GMT Received: from mlsrv1.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQmxyn11140 for ; Wed, 17 Jul 2002 22:17:07 GMT Received: from jkarthik-pc.avici.com (jkarthik-pc.avici.com [10.2.22.72]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g6HMH2n26148; Wed, 17 Jul 2002 18:17:02 -0400 (EDT) Message-Id: <5.0.2.1.2.20020717181810.00a51740@mailhost.avici.com> X-Sender: jkarthik@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 17 Jul 2002 18:19:46 -0400 To: "manoj juneja" , mpls@UU.NET From: Jay Karthik Subject: Re: Sender Template Doubt Cc: pbeeram@avici.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 03:00 PM 7/17/02 -0700, manoj juneja wrote: >Jay, > On a node the PSB is identified by the session object and its >corresponding sender_template object. Let us take the case where two >RSVP-TE tunnels are established between two nodes A and B. The >destination address for both the RSVP sessions is same. Furthermore, if >the ingress node sends it's router Id in sender template then how a >transit node distinguishes between these two PSBs ? Is the distinction >between these two PSBs is done on the basis of LSP Id and Tunnel Id as >the other fields of SESSION and SENDER_TEMPLATE objects will be same. Yes. LSP tunnels are identified by a combination of the SESSION and SENDER_TEMPLATE objects. Regards, Jay >Regards, >manoj. > > >>From: Jay Karthik >>To: "manoj juneja" , mpls@UU.NET >>CC: pbeeram@avici.com >>Subject: Re: Sender Template Doubt >>Date: Wed, 17 Jul 2002 17:32:20 -0400 >> >>At 01:01 PM 7/17/02 -0700, manoj juneja wrote: >>>Hi All, >>> I have a doubt regarding sender template object in RSVP-TE. >>> Can I fill the sender address in sender template object same as PHOP >>> address (in RSVP_HOP object) at the ingress node in the outgoing path message ? >>> >>>As per my understanding, the PHOP object will change at every hop in the >>>path message but the sender template remanins the same. >>> >>>At the ingress node, should the sender address in sender template object >>>be filled with the IP address of the outgoing interface over which the >>>path message is to be sent out ? >> >>It is not mandatory to send the IP address of the outgoing i/f. Usually >>it is the router-id of the Ingress. (However for a backup tunnel >>you could pick any address besides the router-id, as the sender address >>in the SENDER_TEMPLATE). >> >>Jay >> >> >> >>>Regards, >>>manoj. >>> >>>_________________________________________________________________ >>>Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > >_________________________________________________________________ >MSN Photos is the easiest way to share and print your photos: >http://photos.msn.com/support/worldwide.aspx > From owner-mpls@UU.NET Wed Jul 17 18:25:05 2002 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 ESMTP id SAA01326 for ; Wed, 17 Jul 2002 18:25:05 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxyn20973 for ; Wed, 17 Jul 2002 22:25:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxyn20478; Wed, 17 Jul 2002 22:25:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxyn29341 for mpls-outgoing; Wed, 17 Jul 2002 22:25:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmxyn29336 for ; Wed, 17 Jul 2002 22:25:28 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 QQmxyn22762 for ; Wed, 17 Jul 2002 22:25:25 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxyn20124 for ; Wed, 17 Jul 2002 22:25:25 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 QQmxyn20110 for ; Wed, 17 Jul 2002 22:25: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 SAA14463 for ; Wed, 17 Jul 2002 18:25: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 SAA25698 for ; Wed, 17 Jul 2002 18:25:23 -0400 (EDT) Message-ID: <3D35EED8.7030107@marconi.com> Date: Wed, 17 Jul 2002 18:25:28 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020717 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Sender Template Doubt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit manoj juneja wrote: > > On a node the PSB is identified by the session object and its > corresponding sender_template object. Correct. Don't forget, however, that the session object has three values - destination address, tunnel ID and extended tunnel ID, and the sender template has two values - sender address and LSP ID. > Let us take the case where two > RSVP-TE tunnels are established between two nodes A and B. The > destination address for both the RSVP sessions is same. If the two LSPs are going to be in different sessions, then they will have different tunnel IDs. If they are in the same session, then they will have to have different LSP IDs. > Furthermore, if > the ingress node sends it's router Id in sender template then how a > transit node distinguishes between these two PSBs? See above. They will have different tunnel IDs, if they are in different sessions, or different LSP IDs if they are in the same session. > Is the distinction > between these two PSBs is done on the basis of LSP Id and Tunnel Id as > the other fields of SESSION and SENDER_TEMPLATE objects will be same. Yes. -- David From owner-mpls@UU.NET Wed Jul 17 20:36:01 2002 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 ESMTP id UAA03945 for ; Wed, 17 Jul 2002 20:36:01 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxyw25009 for ; Thu, 18 Jul 2002 00:36:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmxyw24466; Thu, 18 Jul 2002 00:36:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmxyw23369 for mpls-outgoing; Thu, 18 Jul 2002 00:36:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmxyw23316 for ; Thu, 18 Jul 2002 00:36:14 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 QQmxyu03409 for ; Thu, 18 Jul 2002 00:14:11 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxyu15391 for ; Thu, 18 Jul 2002 00:14:10 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmxyu15385 for ; Thu, 18 Jul 2002 00:14:10 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA18638 for ; Wed, 17 Jul 2002 20:14:10 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA20341 for mpls@uu.net; Wed, 17 Jul 2002 20:14:10 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmxyn29632 for ; Wed, 17 Jul 2002 22:28: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 QQmxyn25486 for ; Wed, 17 Jul 2002 22:26:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmxyn15593 for ; Wed, 17 Jul 2002 22:26:18 GMT Received: from mail2.hd.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hdfdns02.hd.intel.com [192.52.58.11]) id QQmxyn15588 for ; Wed, 17 Jul 2002 22:26:18 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6HMQHJ01621 for ; Wed, 17 Jul 2002 22:26:17 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002071715260020559 ; Wed, 17 Jul 2002 15:26:01 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 15:26:15 -0700 Message-ID: From: "Feng, Mark" To: "'Jay Karthik'" , manoj juneja , mpls@UU.NET Cc: pbeeram@avici.com Subject: RE: Sender Template Doubt Date: Wed, 17 Jul 2002 15:26:12 -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 Also keep in mind that, with the interfaces "proposed" in RFC2205, the sender address is used to force the message to go out at a particular interface, overwriting the routing module. Obviously, this is implementation dependent. Like David mentioned in the previous message, there is no "standard" way of setting the sender address. - Mark > -----Original Message----- > From: Jay Karthik [mailto:jkarthik@avici.com] > Sent: Wednesday, July 17, 2002 3:20 PM > To: manoj juneja; mpls@UU.NET > Cc: pbeeram@avici.com > Subject: Re: Sender Template Doubt > > > At 03:00 PM 7/17/02 -0700, manoj juneja wrote: > >Jay, > > On a node the PSB is identified by the session object and its > >corresponding sender_template object. Let us take the case where two > >RSVP-TE tunnels are established between two nodes A and B. The > >destination address for both the RSVP sessions is same. > Furthermore, if > >the ingress node sends it's router Id in sender template then how a > >transit node distinguishes between these two PSBs ? Is the > distinction > >between these two PSBs is done on the basis of LSP Id and > Tunnel Id as > >the other fields of SESSION and SENDER_TEMPLATE objects will be same. > > Yes. LSP tunnels are identified by a combination of the SESSION > and SENDER_TEMPLATE objects. > > Regards, > Jay > > >Regards, > >manoj. > > > > > >>From: Jay Karthik > >>To: "manoj juneja" , mpls@UU.NET > >>CC: pbeeram@avici.com > >>Subject: Re: Sender Template Doubt > >>Date: Wed, 17 Jul 2002 17:32:20 -0400 > >> > >>At 01:01 PM 7/17/02 -0700, manoj juneja wrote: > >>>Hi All, > >>> I have a doubt regarding sender template object > in RSVP-TE. > >>> Can I fill the sender address in sender template object > same as PHOP > >>> address (in RSVP_HOP object) at the ingress node in the > outgoing path message ? > >>> > >>>As per my understanding, the PHOP object will change at > every hop in the > >>>path message but the sender template remanins the same. > >>> > >>>At the ingress node, should the sender address in sender > template object > >>>be filled with the IP address of the outgoing interface > over which the > >>>path message is to be sent out ? > >> > >>It is not mandatory to send the IP address of the outgoing > i/f. Usually > >>it is the router-id of the Ingress. (However for a backup > tunnel > >>you could pick any address besides the router-id, as the > sender address > >>in the SENDER_TEMPLATE). > >> > >>Jay > >> > >> > >> > >>>Regards, > >>>manoj. > >>> > >>>_________________________________________________________________ > >>>Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > >_________________________________________________________________ >MSN Photos is the easiest way to share and print your photos: >http://photos.msn.com/support/worldwide.aspx > From owner-mpls@UU.NET Thu Jul 18 04:32:21 2002 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 ESMTP id EAA26047 for ; Thu, 18 Jul 2002 04:32:20 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyac18679 for ; Thu, 18 Jul 2002 08:33:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyac18057; Thu, 18 Jul 2002 08:32:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyac25788 for mpls-outgoing; Thu, 18 Jul 2002 08:32:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyac25780 for ; Thu, 18 Jul 2002 08:32: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 QQmyac08827 for ; Thu, 18 Jul 2002 08:31:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyac17557 for ; Thu, 18 Jul 2002 08:31:37 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmyac17553 for ; Thu, 18 Jul 2002 08:31:36 GMT Received: from utfors.se ([195.58.105.97]) by blooper.utfors.se (Utfors AB) with ESMTP id g6I8VH5F001932; Thu, 18 Jul 2002 10:31:19 +0200 (MEST) Message-ID: <3D367CD4.3040309@utfors.se> Date: Thu, 18 Jul 2002 10:31:16 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: MPLS wg CC: Scott Bradner , George Swallow Subject: comments on the MPLS OAM discussion Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, at the meeting of the MPLS wg today at the 54th IETF in Yokohama the MPLS OAM and the liasion from ITU-T SG13/Q3 were revisted. There were a very clear consensus in the room supporting the the request in "Use of a reserved label value defined in RFC 3032 for MPLS OAM functions" to assign a label value out of the reserved mpls label value space to support MPLS OAM. There were some concerns raised on the "economy of the reserved label space", i.e. are we using this label space most effectively by accepting the request from ITU-T SG13/Q3. It is the intention of the IESG to address the question of moving the to informational on Thursday next, this is to open up the mpls mailing list for comments on this topic to support the IESG in their decission. Ideally the IESG should be able to take the decission on Thursday, but if we have an active discussion on the list the decission will be taken when the discussion vonverges. /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 Thu Jul 18 07:42:30 2002 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 ESMTP id HAA29206 for ; Thu, 18 Jul 2002 07:42:30 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyao15308 for ; Thu, 18 Jul 2002 11:43:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyao14796; Thu, 18 Jul 2002 11:43:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyao16014 for mpls-outgoing; Thu, 18 Jul 2002 11:42:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyao16009 for ; Thu, 18 Jul 2002 11: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 QQmyao14226 for ; Thu, 18 Jul 2002 11:42:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyao21401 for ; Thu, 18 Jul 2002 11:42:20 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmyao21382 for ; Thu, 18 Jul 2002 11:42:19 GMT Received: from utfors.se ([195.58.105.117]) by blooper.utfors.se (Utfors AB) with ESMTP id g6IBg35F003997; Thu, 18 Jul 2002 13:42:04 +0200 (MEST) Message-ID: <3D36A98A.7070103@utfors.se> Date: Thu, 18 Jul 2002 13:42:02 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: MPLS wg CC: George Swallow , scott Giles , "Wijnen, Bert (Bert)" Subject: initiating a discussion on mpls singaling protocols Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, at the mpls wg meeting at the 54th IETF in Yokohama the issue of having two functional similar (not to say overlapping) protocols addressing the same functional space, as rsvp-te and cr-ldp were brought up. The background is that when the signaling protocol for mpls traffic engineering and setting up explicit / constraint based routes were designed, there were two different approaches. One based on rsvp and the other on ldp. It was not at that time possible to resolve the differences between the two approaches and this protocol duplication as been reflected in creation of sometimes functional duplicate specifications. Since then both protocols has been progressed to proposed standard and implemented. However, as has been shown in the survey on signaling protocols for GMPLS the implementations of rsvp-te far out number the cr-ldp implementations. As there are issues with having two similar standards (potentially diverging), and it generates duplicate work in several ietf working groups, the question was asked whether we should make cr-ldp informational (which still make it available and possible to work with) and progress only rsvp-te on the standards track. At the meeting there were a wide spread support for this idea, but it was ruled that it was premature to call wg consensus on this at the meeting and that we wanted to take the discussion on the mpls mailing list. This mail is to initiate this discussion. Please keep the discussion on the mpls list, do not cross post other lists. A separate mail to the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this discussion. /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 Thu Jul 18 10:03:34 2002 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 ESMTP id KAA02902 for ; Thu, 18 Jul 2002 10:03:34 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyay16216 for ; Thu, 18 Jul 2002 14:04:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyay15313; Thu, 18 Jul 2002 14:04:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyay22686 for mpls-outgoing; Thu, 18 Jul 2002 14:03:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyay22679 for ; Thu, 18 Jul 2002 14:03: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 QQmyay04426 for ; Thu, 18 Jul 2002 14:02:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyay13300 for ; Thu, 18 Jul 2002 14:02: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 QQmyay13295 for ; Thu, 18 Jul 2002 14:02: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 KAA10345 for ; Thu, 18 Jul 2002 10:02: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 KAA25467 for ; Thu, 18 Jul 2002 10:02:14 -0400 (EDT) Message-ID: <3D36CA6D.7090709@marconi.com> Date: Thu, 18 Jul 2002 10:02:21 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020717 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Sender Template Doubt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Feng, Mark wrote: > Also keep in mind that, with the interfaces "proposed" in RFC2205, the > sender address is used to force the message to go out at a particular > interface, overwriting the routing module. Obviously, this is implementation > dependent. Like David mentioned in the previous message, there is no > "standard" way of setting the sender address. I don't think this is correct. Without explicit routes (which is how RFC 2205 is defined), Path messages must always follow the routing table's route to the session address. The interfaces in section 3.11.1 of RFC 2205 are _NOT_ describing rules of forming packets. It is proposing one possible API that can be used by applications to make requests of an RSVP protocol stack. The interface selection rule in the SENDER() call is simply to bind a connection to an interface, much like the bind() call does on the server side of an ordinary socket. Note also that it may be left undefined - much like INADDR_ANY can be used in bind(). The implementation is no required to blindly copy this value into the SENDER_TEMPLATE object of the Path message. Section 3.11 of RFC 2205 (and all of RFC 2209) should be seen only as informational. They are defining one possible API/implementation, but are not defining the only possible one. Depending on your switch's overall software architecture, that design may be pretty bad for you. -- David From owner-mpls@UU.NET Thu Jul 18 10:16:25 2002 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 ESMTP id KAA03135 for ; Thu, 18 Jul 2002 10:16:25 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyaz00469 for ; Thu, 18 Jul 2002 14:17:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyaz29609; Thu, 18 Jul 2002 14:16:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyaz04227 for mpls-outgoing; Thu, 18 Jul 2002 14:16:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyaz04220 for ; Thu, 18 Jul 2002 14:16: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 QQmyaz06274 for ; Thu, 18 Jul 2002 14:16:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyaz20287 for ; Thu, 18 Jul 2002 14:16:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyaz20272 for ; Thu, 18 Jul 2002 14:16:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA24844 for ; Thu, 18 Jul 2002 10:16:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA12545 for mpls@uu.net; Thu, 18 Jul 2002 10:16:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyay03714 for ; Thu, 18 Jul 2002 14:12:56 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 QQmyay01464 for ; Thu, 18 Jul 2002 14:12:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyay27673 for ; Thu, 18 Jul 2002 14:12:24 GMT Received: from edgsvr04.edgeflow.edgeflow.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: owa.meriton.com [209.202.126.190]) id QQmyay27668 for ; Thu, 18 Jul 2002 14:12:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: initiating a discussion on mpls singaling protocols Date: Thu, 18 Jul 2002 10:08:37 -0400 Message-ID: <2B192BF55E1A4440A1176A12D86600C91F2A25@edgsvr04.edgeflow.edgeflow.com> Thread-Topic: initiating a discussion on mpls singaling protocols Thread-Index: AcIuUEDfTjZb6lBgQBuswGMgeCylXwAExhfQ From: "George Young" To: Cc: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA03135 As one of the GMPLS Survey respondents in the RSVP-TE camp, I support this proposal. Regards, George R. Young Meriton Networks Inc. 3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9628 email: george.young@meriton.com > -----Original Message----- > From: Loa Andersson [mailto:loa.andersson@utfors.se] > Sent: Thursday, July 18, 2002 7:42 AM > To: MPLS wg > Cc: George Swallow; scott Giles; Wijnen, Bert (Bert) > Subject: initiating a discussion on mpls singaling (sic) protocols > > > However, as has been shown in the survey on signaling protocols for > GMPLS the implementations of rsvp-te far out number the cr-ldp > implementations. As there are issues with having two similar standards > (potentially diverging), and it generates duplicate work in several > ietf working groups, the question was asked whether we should make > cr-ldp informational (which still make it available and possible to > work with) and progress only rsvp-te on the standards track. > > At the meeting there were a wide spread support for this idea, but > it was ruled that it was premature to call wg consensus on this at the > meeting and that we wanted to take the discussion on the mpls mailing > list. > > From owner-mpls@UU.NET Thu Jul 18 10:21:58 2002 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 ESMTP id KAA03220 for ; Thu, 18 Jul 2002 10:21:58 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyaz10647 for ; Thu, 18 Jul 2002 14:22:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyaz09833; Thu, 18 Jul 2002 14:22:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyaz04738 for mpls-outgoing; Thu, 18 Jul 2002 14:22:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyaz04732 for ; Thu, 18 Jul 2002 14:22: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 QQmyaz15969 for ; Thu, 18 Jul 2002 14:19:38 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyaz04242 for ; Thu, 18 Jul 2002 14:19:28 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQmyaz03734 for ; Thu, 18 Jul 2002 14:19:11 GMT Message-ID: From: Dimitry Haskin To: MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Thu, 18 Jul 2002 10:19:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > However, as has been shown in the survey on signaling protocols for > GMPLS the implementations of rsvp-te far out number the cr-ldp > implementations. At this point, a deployment survey would be even more indicative. Dimitry From owner-mpls@UU.NET Thu Jul 18 10:40:16 2002 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 ESMTP id KAA03616 for ; Thu, 18 Jul 2002 10:40:16 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyba00749 for ; Thu, 18 Jul 2002 14:41:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyba29808; Thu, 18 Jul 2002 14:40:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyba06088 for mpls-outgoing; Thu, 18 Jul 2002 14:40:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyba06081 for ; Thu, 18 Jul 2002 14:40: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 QQmyba26074 for ; Thu, 18 Jul 2002 14:39:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyba28406 for ; Thu, 18 Jul 2002 14:39: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 QQmyba28379 for ; Thu, 18 Jul 2002 14:39:07 GMT Received: from m2vwall5.wipro.com ([10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g6IEd5j02156 for ; Thu, 18 Jul 2002 20:09:05 +0530 (IST) Received: from boochi.wipro.com ([10.117.3.144]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GZG8OQ00.7A0 for ; Thu, 18 Jul 2002 20:08:50 +0530 Date: Thu, 18 Jul 2002 20:15:00 +0400 (RET) From: "Nagabhushana Ramaswamy Nadig" X-X-Sender: Reply-To: To: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols In-Reply-To: <3D36A98A.7070103@utfors.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id KAA03616 Hi, A long time pending issue for discussion. To beging with 1. In my opinion the number of implementation can't be a good metric to dictate a standard. A better approach and design matters much more than this. We see more implementations of rsvp rather being taken up as extention to the existing code base. So all those people who would have gone for rsvp-te extention to leverage on this advantage of existing code with them. 2. CR-LDP is designed for a specific purpose of enabling mpls networks forTE. Where as rsvp-te is one which was meant for a different purpose which has been modified for this one. So it has come here with all its drawbacksand limitations. I see CR-LDP as a much cleanner and focussed approach to address specific issues and is more flexible. 3. The scalability issues of rsvp is a known fact today (soft state=20 maintenance, refreshment, error handling etc)...because of which the plain rsvp itself never took off in a big way in internet. The list grows.... So need to say now that I am a CR-LDP man..... regards Bhushana On Thu, 18 Jul 2002, Loa Andersson wrote: > All, > > at the mpls wg meeting at the 54th IETF in Yokohama the issue of having > two functional similar (not to say overlapping) protocols addressing > the same functional space, as rsvp-te and cr-ldp were brought up. > > The background is that when the signaling protocol for mpls traffic > engineering and setting up explicit / constraint based routes were > designed, there were two different approaches. One based on rsvp and > the other on ldp. It was not at that time possible to resolve the > differences between the two approaches and this protocol duplication > as been reflected in creation of sometimes functional duplicate > specifications. > > Since then both protocols has been progressed to proposed standard > and implemented. > > However, as has been shown in the survey on signaling protocols for > GMPLS the implementations of rsvp-te far out number the cr-ldp > implementations. As there are issues with having two similar standards > (potentially diverging), and it generates duplicate work in several > ietf working groups, the question was asked whether we should make > cr-ldp informational (which still make it available and possible to > work with) and progress only rsvp-te on the standards track. > > At the meeting there were a wide spread support for this idea, but > it was ruled that it was premature to call wg consensus on this at the > meeting and that we wanted to take the discussion on the mpls mailing > list. > > This mail is to initiate this discussion. Please keep the discussion > on the mpls list, do not cross post other lists. A separate mail to > the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this > discussion. > > /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 Thu Jul 18 10:59:08 2002 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 ESMTP id KAA04026 for ; Thu, 18 Jul 2002 10:59:08 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybc19030 for ; Thu, 18 Jul 2002 15:00:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybb18211; Thu, 18 Jul 2002 14:59:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybb07927 for mpls-outgoing; Thu, 18 Jul 2002 14:59:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmybb07922 for ; Thu, 18 Jul 2002 14:59: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 QQmybb28792 for ; Thu, 18 Jul 2002 14:59:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybb17836 for ; Thu, 18 Jul 2002 14:59:10 GMT Received: from lightwave.chromisys.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQmybb17829 for ; Thu, 18 Jul 2002 14:59:09 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <3VWHT7GL>; Thu, 18 Jul 2002 07:59:05 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F7FB@nimbus> From: John Drake To: MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Thu, 18 Jul 2002 07:58: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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA04026 'Yes' is a good answer to the question -----Original Message----- From: Loa Andersson [mailto:loa.andersson@utfors.se] Sent: Thursday, July 18, 2002 4:42 AM To: MPLS wg Cc: George Swallow; scott Giles; Wijnen, Bert (Bert) Subject: initiating a discussion on mpls singaling protocols All, at the mpls wg meeting at the 54th IETF in Yokohama the issue of having two functional similar (not to say overlapping) protocols addressing the same functional space, as rsvp-te and cr-ldp were brought up. The background is that when the signaling protocol for mpls traffic engineering and setting up explicit / constraint based routes were designed, there were two different approaches. One based on rsvp and the other on ldp. It was not at that time possible to resolve the differences between the two approaches and this protocol duplication as been reflected in creation of sometimes functional duplicate specifications. Since then both protocols has been progressed to proposed standard and implemented. However, as has been shown in the survey on signaling protocols for GMPLS the implementations of rsvp-te far out number the cr-ldp implementations. As there are issues with having two similar standards (potentially diverging), and it generates duplicate work in several ietf working groups, the question was asked whether we should make cr-ldp informational (which still make it available and possible to work with) and progress only rsvp-te on the standards track. At the meeting there were a wide spread support for this idea, but it was ruled that it was premature to call wg consensus on this at the meeting and that we wanted to take the discussion on the mpls mailing list. This mail is to initiate this discussion. Please keep the discussion on the mpls list, do not cross post other lists. A separate mail to the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this discussion. /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 Thu Jul 18 11:02:59 2002 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 ESMTP id LAA04226 for ; Thu, 18 Jul 2002 11:02:59 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybc10144 for ; Thu, 18 Jul 2002 15:03:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybc09277; Thu, 18 Jul 2002 15:03:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybc19920 for mpls-outgoing; Thu, 18 Jul 2002 15:03:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmybc19909 for ; Thu, 18 Jul 2002 15:03: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 QQmybc14488 for ; Thu, 18 Jul 2002 15:02:36 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybc17866 for ; Thu, 18 Jul 2002 15:02:36 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmybc17862 for ; Thu, 18 Jul 2002 15:02:35 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA28577; Thu, 18 Jul 2002 11:02:32 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA18122; Thu, 18 Jul 2002 11:02:32 -0400 (EDT) Message-Id: <200207181502.LAA18122@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Loa Andersson cc: MPLS wg , George Swallow , scott Giles , "Wijnen, Bert (Bert)" Subject: Re: initiating a discussion on mpls signaling protocols In-reply-to: Your message of Thu, 18 Jul 2002 13:42:02 +0200. <3D36A98A.7070103@utfors.se> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 18 Jul 2002 11:02:32 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Loa> the question was asked whether we should make cr-ldp informational Loa> (which still make it available and possible to work with) and progress Loa> only rsvp-te on the standards track. This seems like a very good idea to me. From owner-mpls@UU.NET Thu Jul 18 11:12:01 2002 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 ESMTP id LAA04370 for ; Thu, 18 Jul 2002 11:12:00 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybc23747 for ; Thu, 18 Jul 2002 15:12:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybc22823; Thu, 18 Jul 2002 15:12:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybc00452 for mpls-outgoing; Thu, 18 Jul 2002 15:11:47 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmybc00442 for ; Thu, 18 Jul 2002 15:11: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 QQmybc01763 for ; Thu, 18 Jul 2002 15:11:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybc22153 for ; Thu, 18 Jul 2002 15:11:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmybc22149 for ; Thu, 18 Jul 2002 15:11:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA29253 for ; Thu, 18 Jul 2002 11:11:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA19445 for mpls@uu.net; Thu, 18 Jul 2002 11:11:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmybc29862 for ; Thu, 18 Jul 2002 15:09:49 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 QQmybc11197 for ; Thu, 18 Jul 2002 15:09:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybc19816 for ; Thu, 18 Jul 2002 15:09:36 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 QQmybc19811 for ; Thu, 18 Jul 2002 15:09:35 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6IFA0CO002319; Thu, 18 Jul 2002 11:10:01 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-157.cisco.com [161.44.134.157]) by bucket.cisco.com (Mirapoint) with ESMTP id ABH70497; Thu, 18 Jul 2002 11:09:26 -0400 (EDT) Message-Id: <4.3.2.7.2.20020718110909.03c79c30@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Jul 2002 11:09:25 -0400 To: Loa Andersson From: "Thomas D. Nadeau" Subject: Re: initiating a discussion on mpls singaling protocols Cc: MPLS wg , George Swallow , scott Giles , "Wijnen, Bert (Bert)" In-Reply-To: <3D36A98A.7070103@utfors.se> 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 LAA04370 Sounds like a pragmatic approach to me. --Tom >at the mpls wg meeting at the 54th IETF in Yokohama the issue of having >two functional similar (not to say overlapping) protocols addressing >the same functional space, as rsvp-te and cr-ldp were brought up. > >The background is that when the signaling protocol for mpls traffic >engineering and setting up explicit / constraint based routes were >designed, there were two different approaches. One based on rsvp and >the other on ldp. It was not at that time possible to resolve the >differences between the two approaches and this protocol duplication >as been reflected in creation of sometimes functional duplicate >specifications. > >Since then both protocols has been progressed to proposed standard >and implemented. > >However, as has been shown in the survey on signaling protocols for >GMPLS the implementations of rsvp-te far out number the cr-ldp >implementations. As there are issues with having two similar standards >(potentially diverging), and it generates duplicate work in several >ietf working groups, the question was asked whether we should make >cr-ldp informational (which still make it available and possible to >work with) and progress only rsvp-te on the standards track. > >At the meeting there were a wide spread support for this idea, but >it was ruled that it was premature to call wg consensus on this at the >meeting and that we wanted to take the discussion on the mpls mailing >list. > >This mail is to initiate this discussion. Please keep the discussion >on the mpls list, do not cross post other lists. A separate mail to >the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this >discussion. > >/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 > ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Thu Jul 18 11:35:33 2002 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 ESMTP id LAA05252 for ; Thu, 18 Jul 2002 11:35:33 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybe14473 for ; Thu, 18 Jul 2002 15:36:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybe13585; Thu, 18 Jul 2002 15:36:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybe03176 for mpls-outgoing; Thu, 18 Jul 2002 15:35:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmybe03171 for ; Thu, 18 Jul 2002 15:35:35 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 QQmybe08570 for ; Thu, 18 Jul 2002 15:34:40 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybe10926 for ; Thu, 18 Jul 2002 15:34:40 GMT Received: from mlsrv1.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQmybe10918 for ; Thu, 18 Jul 2002 15:34:39 GMT Received: from rpapneja-pc.avici.com (rpapneja-pc.avici.com [10.2.22.46]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g6IFYWn17905; Thu, 18 Jul 2002 11:34:32 -0400 (EDT) Message-Id: <5.0.2.1.2.20020718112632.02236e88@mailhost.avici.com> X-Sender: rpapneja@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 18 Jul 2002 11:36:53 -0400 To: Loa Andersson , MPLS wg From: RajivPapneja Subject: Re: initiating a discussion on mpls singaling protocols Cc: George Swallow , scott Giles , "Wijnen, Bert (Bert)" In-Reply-To: <3D36A98A.7070103@utfors.se> 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 LAA05252 >the question was asked whether we should make >cr-ldp informational (which still make it available and possible to >work with) and progress only rsvp-te on the standards track. The answer to this question is "yes" (as we have seen so far in the "discussion" thread) and everyone of us know that based on the actual implementations/deployments. But, I think SPs should step in to make this call because eventually they are the ultimate users for the MPLS-TE protocols. Thanks, -Rajiv At 01:42 PM 7/18/2002 +0200, Loa Andersson wrote: >All, > >at the mpls wg meeting at the 54th IETF in Yokohama the issue of having >two functional similar (not to say overlapping) protocols addressing >the same functional space, as rsvp-te and cr-ldp were brought up. > >The background is that when the signaling protocol for mpls traffic >engineering and setting up explicit / constraint based routes were >designed, there were two different approaches. One based on rsvp and >the other on ldp. It was not at that time possible to resolve the >differences between the two approaches and this protocol duplication >as been reflected in creation of sometimes functional duplicate >specifications. > >Since then both protocols has been progressed to proposed standard >and implemented. > >However, as has been shown in the survey on signaling protocols for >GMPLS the implementations of rsvp-te far out number the cr-ldp >implementations. As there are issues with having two similar standards >(potentially diverging), and it generates duplicate work in several >ietf working groups, the question was asked whether we should make >cr-ldp informational (which still make it available and possible to >work with) and progress only rsvp-te on the standards track. > >At the meeting there were a wide spread support for this idea, but >it was ruled that it was premature to call wg consensus on this at the >meeting and that we wanted to take the discussion on the mpls mailing >list. > >This mail is to initiate this discussion. Please keep the discussion >on the mpls list, do not cross post other lists. A separate mail to >the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this >discussion. > >/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 Thu Jul 18 11:47:31 2002 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 ESMTP id LAA05702 for ; Thu, 18 Jul 2002 11:47:31 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybf20396 for ; Thu, 18 Jul 2002 15:48:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybf19192; Thu, 18 Jul 2002 15:47:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybf04441 for mpls-outgoing; Thu, 18 Jul 2002 15:47:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmybf04434 for ; Thu, 18 Jul 2002 15:47:32 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 QQmybf06864 for ; Thu, 18 Jul 2002 15:47:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybf27700 for ; Thu, 18 Jul 2002 15:47:17 GMT Received: from smtp1.opnet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.opnet.com [141.156.71.6]) id QQmybf27696 for ; Thu, 18 Jul 2002 15:47:17 GMT Received: from wtn10216.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Thu, 18 Jul 2002 11:46:27 -0400 Message-Id: <5.0.0.25.2.20020718114558.02f08b70@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 18 Jul 2002 11:48:17 -0400 To: Loa Andersson , MPLS wg From: Sachin Kalra Subject: Re: initiating a discussion on mpls singaling protocols Cc: George Swallow , scott Giles , "Wijnen, Bert (Bert)" In-Reply-To: <3D36A98A.7070103@utfors.se> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_82387306==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_82387306==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Yes, I support this proposal. Thanks, Sachin Kalra At 01:42 PM 7/18/02 +0200, Loa Andersson wrote: >All, > >at the mpls wg meeting at the 54th IETF in Yokohama the issue of having >two functional similar (not to say overlapping) protocols addressing >the same functional space, as rsvp-te and cr-ldp were brought up. > >The background is that when the signaling protocol for mpls traffic >engineering and setting up explicit / constraint based routes were >designed, there were two different approaches. One based on rsvp and >the other on ldp. It was not at that time possible to resolve the >differences between the two approaches and this protocol duplication >as been reflected in creation of sometimes functional duplicate >specifications. > >Since then both protocols has been progressed to proposed standard >and implemented. > >However, as has been shown in the survey on signaling protocols for >GMPLS the implementations of rsvp-te far out number the cr-ldp >implementations. As there are issues with having two similar standards >(potentially diverging), and it generates duplicate work in several >ietf working groups, the question was asked whether we should make >cr-ldp informational (which still make it available and possible to >work with) and progress only rsvp-te on the standards track. > >At the meeting there were a wide spread support for this idea, but >it was ruled that it was premature to call wg consensus on this at the >meeting and that we wanted to take the discussion on the mpls mailing >list. > >This mail is to initiate this discussion. Please keep the discussion >on the mpls list, do not cross post other lists. A separate mail to >the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this >discussion. > >/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 --=====================_82387306==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, I support this proposal.

Thanks,
Sachin Kalra

At 01:42 PM 7/18/02 +0200, Loa Andersson wrote:
All,

at the mpls wg meeting at the 54th IETF in Yokohama the issue of having
two functional similar (not to say overlapping) protocols=20 addressing
the same functional space, as rsvp-te and cr-ldp were brought up.

The background is that when the signaling protocol for mpls traffic
engineering and setting up explicit / constraint based routes were
designed, there were two different approaches. One  based on rsvp and
the other on ldp. It was not at that time possible to resolve the
differences between the two approaches and this protocol=20 duplication
as been reflected in creation of sometimes functional duplicate
specifications.

Since then both protocols has been progressed to proposed standard
and implemented.

However, as has been shown in the survey on signaling protocols for
GMPLS the implementations of rsvp-te far out number the cr-ldp
implementations. As there are issues with having two similar standards
(potentially diverging), and it generates duplicate work in several
ietf working groups, the question was asked whether we should make
cr-ldp informational (which still make it available and possible to
work with) and progress only rsvp-te on the standards track.

At the meeting there were a wide spread support for this idea, but
it was ruled that it was premature to call wg consensus on this at the
meeting and that we wanted to take the discussion on the mpls mailing
list.

This mail is to initiate this discussion. Please keep the=20 discussion
on the mpls list, do not cross post other lists. A separate mail to
the ccamp, pwe3 and ppvpn has been sent to inform those wg's of=20 this
discussion.

/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 --=====================_82387306==_.ALT-- From owner-mpls@UU.NET Thu Jul 18 11:49:10 2002 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 ESMTP id LAA05755 for ; Thu, 18 Jul 2002 11:49:10 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybf29888 for ; Thu, 18 Jul 2002 15:50:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybf28893; Thu, 18 Jul 2002 15:49:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybf04484 for mpls-outgoing; Thu, 18 Jul 2002 15:49:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmybf04479 for ; Thu, 18 Jul 2002 15:48:55 GMT Received: from imr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybf10494 for ; Thu, 18 Jul 2002 15:48:33 GMT Received: from pmismtp04.wcomnet.com by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pmismtp04.wcomnet.com [166.38.62.39]) id QQmybf10489 for ; Thu, 18 Jul 2002 15:48:32 GMT Received: from CONVERSION-DAEMON.pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) id <0GZG00001BUL7H@pmismtp04.wcomnet.com> for mpls@UU.NET; Thu, 18 Jul 2002 15:48:32 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0GZG00M01BR4Y7@pmismtp04.wcomnet.com> for mpls@UU.NET; Thu, 18 Jul 2002 15:48:24 +0000 (GMT) Received: from rbonica ([166.60.14.55]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0GZG0002CBVS8X@pmismtp04.wcomnet.com>; Thu, 18 Jul 2002 15:47:54 +0000 (GMT) Date: Thu, 18 Jul 2002 11:37:03 -0400 From: Ron Bonica Subject: RE: initiating a discussion on mpls singaling protocols In-reply-to: To: nagabhushana.ramaswamy@wipro.com, MPLS wg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > 3. The scalability issues of rsvp is a known fact today (soft state=20 > maintenance, refreshment, error handling etc)...because of which the > plain rsvp itself never took off in a big way in internet. Many operators have deployed RSVP-TE. Are you aware of any who have deployed it and run into scaling problems? Ron From owner-mpls@UU.NET Thu Jul 18 11:59:53 2002 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 ESMTP id LAA06162 for ; Thu, 18 Jul 2002 11:59:53 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybg03778 for ; Thu, 18 Jul 2002 16:00:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybg02920; Thu, 18 Jul 2002 16:00:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybg06241 for mpls-outgoing; Thu, 18 Jul 2002 16:00:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmybg05454 for ; Thu, 18 Jul 2002 16: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 QQmybf11147 for ; Thu, 18 Jul 2002 15:59:23 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybf02077 for ; Thu, 18 Jul 2002 15:59:23 GMT Received: from mail1.paramanet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.paramanet.com [65.211.83.162]) id QQmybf02063 for ; Thu, 18 Jul 2002 15:59:22 GMT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: initiating a discussion on mpls singaling protocols X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 11:59:18 -0400 Message-ID: <9791A828507D5A418741095C3FD0DDE35EB706@indus> Thread-Topic: initiating a discussion on mpls singaling protocols Thread-Index: AcIuUI93xKKCVA5xRSquBPixjO9wcwAI25pw From: "Cheenu Srinivasan" To: "Loa Andersson" , "MPLS wg" Cc: "George Swallow" , "scott Giles" , "Wijnen, Bert (Bert)" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA06162 I am in favor of this proposal. > -----Original Message----- > From: Loa Andersson [mailto:loa.andersson@utfors.se] > Sent: Thursday, July 18, 2002 7:42 AM > To: MPLS wg > Cc: George Swallow; scott Giles; Wijnen, Bert (Bert) > Subject: initiating a discussion on mpls singaling protocols > > > All, > > at the mpls wg meeting at the 54th IETF in Yokohama the issue > of having > two functional similar (not to say overlapping) protocols addressing > the same functional space, as rsvp-te and cr-ldp were brought up. > > The background is that when the signaling protocol for mpls traffic > engineering and setting up explicit / constraint based routes were > designed, there were two different approaches. One based on rsvp and > the other on ldp. It was not at that time possible to resolve the > differences between the two approaches and this protocol duplication > as been reflected in creation of sometimes functional duplicate > specifications. > > Since then both protocols has been progressed to proposed standard > and implemented. > > However, as has been shown in the survey on signaling protocols for > GMPLS the implementations of rsvp-te far out number the cr-ldp > implementations. As there are issues with having two similar standards > (potentially diverging), and it generates duplicate work in several > ietf working groups, the question was asked whether we should make > cr-ldp informational (which still make it available and possible to > work with) and progress only rsvp-te on the standards track. > > At the meeting there were a wide spread support for this idea, but > it was ruled that it was premature to call wg consensus on this at the > meeting and that we wanted to take the discussion on the mpls mailing > list. > > This mail is to initiate this discussion. Please keep the discussion > on the mpls list, do not cross post other lists. A separate mail to > the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this > discussion. > > /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 Thu Jul 18 14:20:26 2002 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 ESMTP id OAA09729 for ; Thu, 18 Jul 2002 14:20:26 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybp13351 for ; Thu, 18 Jul 2002 18:21:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybp12662; Thu, 18 Jul 2002 18:21:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybp25253 for mpls-outgoing; Thu, 18 Jul 2002 18:20:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmybp25248 for ; Thu, 18 Jul 2002 18:20:23 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 QQmybp15339 for ; Thu, 18 Jul 2002 18:20:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybp09859 for ; Thu, 18 Jul 2002 18:20:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmybp09855 for ; Thu, 18 Jul 2002 18:20:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA14717 for ; Thu, 18 Jul 2002 14:20:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA11285 for mpls@uu.net; Thu, 18 Jul 2002 14:20:04 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmybp25174 for ; Thu, 18 Jul 2002 18:18: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 QQmybp21485 for ; Thu, 18 Jul 2002 18:18:53 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybp08970 for ; Thu, 18 Jul 2002 18:18:53 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.54]) id QQmybp08966 for ; Thu, 18 Jul 2002 18:18:53 GMT Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6IIIqqI011825 for ; Thu, 18 Jul 2002 11:18:52 -0700 (PDT) Received: from cisco.com (dhcp-171-69-39-155.cisco.com [171.69.39.155]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ADM21950; Thu, 18 Jul 2002 11:19:08 -0700 (PDT) Message-ID: <3D37068B.9020601@cisco.com> Date: Thu, 18 Jul 2002 11:18:51 -0700 From: Bora Akyol Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit We went through these same discussions in 1998. It may be argued that RSVP has some scaling problems but in real deployments, none of these materialized. So, I think the market has spoken already. I support making CR-LDP informational and RSVP-TE standard. Bora Ron Bonica wrote: >>3. The scalability issues of rsvp is a known fact today (soft state=20 >>maintenance, refreshment, error handling etc)...because of which the >>plain rsvp itself never took off in a big way in internet. >> >> > >Many operators have deployed RSVP-TE. Are you aware of any who have deployed >it and run into scaling problems? > > Ron > > > > From owner-mpls@UU.NET Thu Jul 18 14:34:59 2002 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 ESMTP id OAA09989 for ; Thu, 18 Jul 2002 14:34:59 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybq14186 for ; Thu, 18 Jul 2002 18:35:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybq13545; Thu, 18 Jul 2002 18:35:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybq26383 for mpls-outgoing; Thu, 18 Jul 2002 18:35:20 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmybq26376 for ; Thu, 18 Jul 2002 18:35: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 QQmybq21102 for ; Thu, 18 Jul 2002 18:34:50 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybq25949 for ; Thu, 18 Jul 2002 18:34:49 GMT Received: from pimout2-int.prodigy.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pimout2-ext.prodigy.net [207.115.63.101]) id QQmybq25945 for ; Thu, 18 Jul 2002 18:34:49 GMT Received: from cs.columbia.edu (adsl-64-175-245-81.dsl.sntc01.pacbell.net [64.175.245.81]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g6IIYd4418612; Thu, 18 Jul 2002 14:34:39 -0400 Message-ID: <3D370A3B.5090107@cs.columbia.edu> Date: Thu, 18 Jul 2002 11:34:35 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: nagabhushana.ramaswamy@wipro.com CC: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nagabhushana Ramaswamy Nadig wrote: > 3. The scalability issues of rsvp is a known fact today (soft state=20 > maintenance, refreshment, error handling etc)...because of which the > plain rsvp itself never took off in a big way in internet. > Hi, You seem to be confused here. RSVP-TE and the classic RSVP are meant for two completely different applications. Generally, "scalability", an over-used term, can be represented in two parameters: the number of connections that a router can handle, and the number of connects that a providers can handle RSVP-TE is used for MPLS, where LSP's normally don't change. Thus, by simply reducing the amount of RSVP refresh messages (via RSVP refresh reduction), a router can handle thousands of sessions without any problem. I think Ron Bonia's network has a couple hundreds of LSP's, and I have seen other networks with a couple thousands of LSP's. By turning on refresh reduction, routers don't seem to have any problem. I have seen routers that can handle 50,000+ LSP's. Note, even when network links and nodes are going up and down, with a proper RSVP-TE fast-reroute implementation, there won't be any performance problem. The one-to-one fast-reroute is to establish LSP's ahead of failure, so no extra RSVP signaling is required when a node or a link is down (other than some error messages once in a while). The facility fast-reroute is to aggregate all RSVP messages into a pre-established bypass LSP at failure time, thus no performance problem here neither. The only problem that I can see so far in MPLS is that there is no efficient method to manage too many LSP's in the network. Remember, the LSP's can be used for VPN's. How to map, monitor and diagnosis network resources, routes and LSP's, etc. is not a simple task. But this manageability problem is the same for both RSVP-TE and LDP. Now, back to RSVP, when it is used to provide QoS signaling for inter-active real-time sessions (such as voice), it does not work well. This is mainly because the duration for real-time sessions is normally short. An average phone call is 3-4 minutes. When you plug in the network topology of an existing SS7 network, and the desired goal of the 3G networks, the number of RSVP session changes (on/off traffic sources) is in the range of a few thousands sessions *per second*. When using RSVP, routers will be under a lot of stress. In this case, RSVP is not sufficient, refresh reduction has no use, and the soft-state approach seems to be a joke. I think this is the problem that NSIS WG is trying to handle. 2 cents, - Ping Pan From owner-mpls@UU.NET Thu Jul 18 15:45:22 2002 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 ESMTP id PAA11528 for ; Thu, 18 Jul 2002 15:45:16 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybv01614 for ; Thu, 18 Jul 2002 19:46:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybv00357; Thu, 18 Jul 2002 19:45:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybv24720 for mpls-outgoing; Thu, 18 Jul 2002 19:45:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmybv24699 for ; Thu, 18 Jul 2002 19:45: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 QQmybu25648 for ; Thu, 18 Jul 2002 19:44:58 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybu01439 for ; Thu, 18 Jul 2002 19:44:58 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmybu01433 for ; Thu, 18 Jul 2002 19:44:57 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA22046 for ; Thu, 18 Jul 2002 15:44:57 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA20987 for mpls@uu.net; Thu, 18 Jul 2002 15:44:57 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmybu23114 for ; Thu, 18 Jul 2002 19:31: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 QQmybu26842 for ; Thu, 18 Jul 2002 19:30:57 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybu23355 for ; Thu, 18 Jul 2002 19:30:57 GMT Received: from mail2.hd.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hdfdns02.hd.intel.com [192.52.58.11]) id QQmybu23348 for ; Thu, 18 Jul 2002 19:30:56 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6IJUs118727 for ; Thu, 18 Jul 2002 19:30:54 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002071812303820316 for ; Thu, 18 Jul 2002 12:30:38 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 12:30:53 -0700 Message-ID: From: "Feng, Mark" To: mpls@UU.NET Subject: RE: Sender Template Doubt Date: Thu, 18 Jul 2002 12:30: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 > -----Original Message----- > From: David Charlap [mailto:david.charlap@marconi.com] > Sent: Thursday, July 18, 2002 7:02 AM > To: mpls@UU.NET > Subject: Re: Sender Template Doubt > > > Feng, Mark wrote: > > Also keep in mind that, with the interfaces "proposed" in > RFC2205, the > > sender address is used to force the message to go out at a > particular > > interface, overwriting the routing module. Obviously, this > is implementation > > dependent. Like David mentioned in the previous message, there is no > > "standard" way of setting the sender address. > > I don't think this is correct. Without explicit routes (which is how > RFC 2205 is defined), Path messages must always follow the routing > table's route to the session address. > I think it is part of the requirement for RSVP. Following is the description for the particular parameter: " - Source_Address This is the address of the interface from which the data will be sent. If it is omitted, a default interface will be used. This parameter is needed only on a multihomed sender host." Following is the excerpt from section 3.11.5 " o Outgoing Link Specification RSVP must be able to force a (multicast) datagram to be sent on a specific outgoing real or virtual link, bypassing the normal routing mechanism. A virtual link might be a multicast tunnel, for example. Outgoing link specification is necessary to send different versions of an outgoing Path message on different interfaces, and to avoid routing loops in some cases. o Source Address and TTL Specification RSVP must be able to specify the IP source address and IP TTL to be used when sending Path messages." > The interfaces in section 3.11.1 of RFC 2205 are _NOT_ > describing rules > of forming packets. It is proposing one possible API that > can be used > by applications to make requests of an RSVP protocol stack. > > The interface selection rule in the SENDER() call is simply to bind a > connection to an interface, much like the bind() call does on > the server > side of an ordinary socket. Note also that it may be left > undefined - > much like INADDR_ANY can be used in bind(). The implementation is no > required to blindly copy this value into the SENDER_TEMPLATE > object of > the Path message. > > Section 3.11 of RFC 2205 (and all of RFC 2209) should be seen only as > informational. They are defining one possible > API/implementation, but > are not defining the only possible one. Depending on your switch's > overall software architecture, that design may be pretty bad for you. > Right. I agree it is only a "proposed" interface. As to the value in sender template, it can be set to whatever sensible values. > -- David > - Mark From owner-mpls@UU.NET Thu Jul 18 16:11:22 2002 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 ESMTP id QAA11892 for ; Thu, 18 Jul 2002 16:11:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybw22909 for ; Thu, 18 Jul 2002 20:12:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmybw22256; Thu, 18 Jul 2002 20:12:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmybw20930 for mpls-outgoing; Thu, 18 Jul 2002 20:11:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmybw20910 for ; Thu, 18 Jul 2002 20:11: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 QQmybw18012 for ; Thu, 18 Jul 2002 20:11:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmybw27879 for ; Thu, 18 Jul 2002 20:11:14 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 QQmybw27857 for ; Thu, 18 Jul 2002 20:11:13 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 QAA13938 for ; Thu, 18 Jul 2002 16:11:11 -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 QAA22692 for ; Thu, 18 Jul 2002 16:11:12 -0400 (EDT) Message-ID: <3D3720E8.30405@marconi.com> Date: Thu, 18 Jul 2002 16:11:20 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a) Gecko/20020613 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Sender Template Doubt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Feng, Mark wrote: > > I think it is part of the requirement for RSVP. > > Following is the description for the particular parameter: > " - Source_Address > > This is the address of the interface from which the > data will be sent. If it is omitted, a default > interface will be used. This parameter is needed > only on a multihomed sender host." This is describing a parameter for an application-to-stack API call. It defines the interface that the Path message willcome from. It doesn't say a thing about whether that interface's address must appear in the SENDER_TEMPLATE object. > Following is the excerpt from section 3.11.5 > > " o Outgoing Link Specification > > RSVP must be able to force a (multicast) datagram to be > sent on a specific outgoing real or virtual link, > bypassing the normal routing mechanism. A virtual link > might be a multicast tunnel, for example. Outgoing link > specification is necessary to send different versions of > an outgoing Path message on different interfaces, and to > avoid routing loops in some cases. This is not an RSVP protocol requirement. This is a requirement that an IP stack must meet in order to be possible to implement RSVP over it. > o Source Address and TTL Specification > > RSVP must be able to specify the IP source address and > IP TTL to be used when sending Path messages." Again, this isn't a requirement for RSVP, but is a requirement for an IP stack, in order to be possible to implement RSVP over it. -- David From owner-mpls@UU.NET Thu Jul 18 20:17:56 2002 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 ESMTP id UAA16475 for ; Thu, 18 Jul 2002 20:17:55 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmycn15455 for ; Fri, 19 Jul 2002 00:18:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmycn14812; Fri, 19 Jul 2002 00:18:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmycn27656 for mpls-outgoing; Fri, 19 Jul 2002 00:18:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmycn27651 for ; Fri, 19 Jul 2002 00: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 QQmycn19738 for ; Fri, 19 Jul 2002 00:17:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmycn14165 for ; Fri, 19 Jul 2002 00:17:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmycn14158 for ; Fri, 19 Jul 2002 00:17:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA08395 for ; Thu, 18 Jul 2002 20:17:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA19111 for mpls@uu.net; Thu, 18 Jul 2002 20:17:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmycn27513 for ; Fri, 19 Jul 2002 00:16:09 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 QQmycn08469 for ; Fri, 19 Jul 2002 00:16:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmycn15551 for ; Fri, 19 Jul 2002 00:16:03 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: amsterdam.cisco.com [144.254.74.238]) id QQmycn15540 for ; Fri, 19 Jul 2002 00:16:03 GMT Received: from MMORROW-W2K2.cisco.com (tokyo-vpn-user285.cisco.com [10.70.83.29]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id CAA10255; Fri, 19 Jul 2002 02:15:58 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020719021538.020bcef8@amsterdam.cisco.com> X-Sender: mmorrow@amsterdam.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Jul 2002 02:15:56 +0200 To: Loa Andersson From: Monique Morrow Subject: Re: initiating a discussion on mpls singaling protocols Cc: MPLS wg , George Swallow , scott Giles , "Wijnen, Bert (Bert)" In-Reply-To: <3D36A98A.7070103@utfors.se> 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 UAA16475 Yes -- reasonable approach >All, > >at the mpls wg meeting at the 54th IETF in Yokohama the issue of having >two functional similar (not to say overlapping) protocols addressing >the same functional space, as rsvp-te and cr-ldp were brought up. > >The background is that when the signaling protocol for mpls traffic >engineering and setting up explicit / constraint based routes were >designed, there were two different approaches. One based on rsvp and >the other on ldp. It was not at that time possible to resolve the >differences between the two approaches and this protocol duplication >as been reflected in creation of sometimes functional duplicate >specifications. > >Since then both protocols has been progressed to proposed standard >and implemented. > >However, as has been shown in the survey on signaling protocols for >GMPLS the implementations of rsvp-te far out number the cr-ldp >implementations. As there are issues with having two similar standards >(potentially diverging), and it generates duplicate work in several >ietf working groups, the question was asked whether we should make >cr-ldp informational (which still make it available and possible to >work with) and progress only rsvp-te on the standards track. > >At the meeting there were a wide spread support for this idea, but >it was ruled that it was premature to call wg consensus on this at the >meeting and that we wanted to take the discussion on the mpls mailing >list. > >This mail is to initiate this discussion. Please keep the discussion >on the mpls list, do not cross post other lists. A separate mail to >the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this >discussion. > >/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 Thu Jul 18 22:50:03 2002 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 ESMTP id WAA19964 for ; Thu, 18 Jul 2002 22:49:58 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmycx11628 for ; Fri, 19 Jul 2002 02:50:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmycx11041; Fri, 19 Jul 2002 02:50:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmycx23840 for mpls-outgoing; Fri, 19 Jul 2002 02:50:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmycx23835 for ; Fri, 19 Jul 2002 02:50: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 QQmycx14223 for ; Fri, 19 Jul 2002 02:49:51 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmycx26165 for ; Fri, 19 Jul 2002 02:49:51 GMT Received: from zcars04e.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmycx26160 for ; Fri, 19 Jul 2002 02:49:51 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6J2niW10173 for ; Thu, 18 Jul 2002 22:49:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 22:49:44 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04A8BB8C@zcard031.ca.nortel.com> From: "David Allan" To: MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Thu, 18 Jul 2002 22:49:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22ECE.EEF13100" 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_01C22ECE.EEF13100 Content-Type: text/plain; charset="iso-8859-1" Swimming upstream ;-) I think it is premature in the GMPLS space to drive CR-LDP into informational. It is not clear to me that soft state is an appropriate solution when considering the holding times for SONET/SDH and optical trails irrepsective of how wonderful refresh reduction is. RSVPs starting point is the opposite end of the spectrum from the POV of flow characteristics. I have no issue with the pragmatics of the packet space. cheers Dave ------_=_NextPart_001_01C22ECE.EEF13100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: initiating a discussion on mpls singaling protocols

Swimming upstream ;-)

I think it is premature in the GMPLS space to drive = CR-LDP into informational. It is not clear to me that soft state is an = appropriate solution when considering the holding times for SONET/SDH = and optical trails irrepsective of how wonderful refresh reduction is. = RSVPs starting point is the opposite end of the spectrum from the POV = of flow characteristics.

I have no issue with the pragmatics of the packet = space.

cheers
Dave

------_=_NextPart_001_01C22ECE.EEF13100-- From owner-mpls@UU.NET Fri Jul 19 01:30:16 2002 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 ESMTP id BAA22002 for ; Fri, 19 Jul 2002 01:30:16 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydi27571 for ; Fri, 19 Jul 2002 05:31:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmydi27084; Fri, 19 Jul 2002 05:30:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmydi09903 for mpls-outgoing; Fri, 19 Jul 2002 05:30:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmydi09898 for ; Fri, 19 Jul 2002 05:30: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 QQmydi03371 for ; Fri, 19 Jul 2002 05:30:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydi26417 for ; Fri, 19 Jul 2002 05:30:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmydi26395 for ; Fri, 19 Jul 2002 05:30:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA22374 for ; Fri, 19 Jul 2002 01:30:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA20264 for mpls@uu.net; Fri, 19 Jul 2002 01:30:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmydh09846 for ; Fri, 19 Jul 2002 05:29:25 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 QQmydh04378 for ; Fri, 19 Jul 2002 05:28:56 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydh25209 for ; Fri, 19 Jul 2002 05:28:55 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmydh25158 for ; Fri, 19 Jul 2002 05:28:54 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 11:04:03 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA064807B2@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: MPLS wg Cc: nagabhushana.ramaswamy@wipro.com Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 19 Jul 2002 11:00:57 +0530 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 I agree with what Bhushana says.We need to look at it from the technical merits apart from who supports RSVP-TE and who does'nt. I think RSVP-TE has become more popular not because of its technical superiority over CR LDP but purely due to the push it has received from a few leading vendors, who choose to use it since they already had RSVP. The support for RSVP-TE is not because of its technical merits but because of the leading vendors choosing it causing others to meekly follow suit. However, it is not too late to weigh its merits against CR LDP. CR LDP is much more cleaner and has lesser scalability issues. Also, when one has LDP it is much easier to have CR LDP than extending RSVP for RSVP-TE. CR LDP is specifically meant for TE in MPLS and hence is advantageous. From an implementors point of view also,having been involved in implementation of both the protocols, I feel CR LDP is much easier to understand, implement and maintain. One also needs to look at other performance issues, which may become critical in GMPLS, I wonder if anyone has checked it. Regards, Vijay -----Original Message----- From: Nagabhushana Ramaswamy Nadig [mailto:nagabhushana.ramaswamy@wipro.com] Sent: Thursday, July 18, 2002 9:45 PM To: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols This message uses a character set that is not supported by the Internet Service. To view the original message content, open the attached message. If the text doesn't display correctly, save the attachment to disk, and then open it using a viewer that can display the original character set. From owner-mpls@UU.NET Fri Jul 19 01:36:11 2002 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 ESMTP id BAA22074 for ; Fri, 19 Jul 2002 01:36:11 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydi11991 for ; Fri, 19 Jul 2002 05:37:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmydi11514; Fri, 19 Jul 2002 05:36:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmydi10240 for mpls-outgoing; Fri, 19 Jul 2002 05:36:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmydi10232 for ; Fri, 19 Jul 2002 05:36: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 QQmydi24095 for ; Fri, 19 Jul 2002 05:36:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydi06163 for ; Fri, 19 Jul 2002 05:36:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmydi06139 for ; Fri, 19 Jul 2002 05:36:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA22815 for ; Fri, 19 Jul 2002 01:36:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA21323 for mpls@uu.net; Fri, 19 Jul 2002 01:36:04 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmydi10155 for ; Fri, 19 Jul 2002 05:35: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 QQmydi00824 for ; Fri, 19 Jul 2002 05:35:02 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydi04327 for ; Fri, 19 Jul 2002 05:35:00 GMT Received: from ganesh.ctd.hctech.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmydi04035 for ; Fri, 19 Jul 2002 05:34:52 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 11:09:56 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA064A2E19@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: Ping Pan Cc: MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 19 Jul 2002 11:06:52 +0530 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 >Now, back to RSVP, when it is used to provide QoS signaling for >inter-active real-time sessions (such as voice), it does not work well. >This is mainly because the duration for real-time sessions is normally >short. An average phone call is 3-4 minutes. When you plug in the >network topology of an existing SS7 network, and the desired goal of the >3G networks, the number of RSVP session changes (on/off traffic sources) >is in the range of a few thousands sessions *per second*. When using >RSVP, routers will be under a lot of stress. In this case, RSVP is not >sufficient, refresh reduction has no use, and the soft-state approach >seems to be a joke. I think this is the problem that NSIS WG is trying >to handle. This is precisely the kind of scalability/performance issue that I ( and probably nagabhushana) were pointing to. Soft state is not scalable always. This problem is likely to be acute when GMPLS networks are fully deployed. Vijay From owner-mpls@UU.NET Fri Jul 19 02:34:23 2002 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 ESMTP id CAA01768 for ; Fri, 19 Jul 2002 02:34:23 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydm02995 for ; Fri, 19 Jul 2002 06:35:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmydm01924; Fri, 19 Jul 2002 06:34:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmydm05030 for mpls-outgoing; Fri, 19 Jul 2002 06:34:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmydm05021 for ; Fri, 19 Jul 2002 06:34: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 QQmydm01673 for ; Fri, 19 Jul 2002 06:32:02 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydm00636 for ; Fri, 19 Jul 2002 06:32:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmydm00632 for ; Fri, 19 Jul 2002 06:32:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA25649 for ; Fri, 19 Jul 2002 02:32:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA27552 for mpls@uu.net; Fri, 19 Jul 2002 02:32:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmydm04918 for ; Fri, 19 Jul 2002 06:31:05 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 QQmydl27392 for ; Fri, 19 Jul 2002 06:29:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydl26602 for ; Fri, 19 Jul 2002 06:29:45 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmydl26596 for ; Fri, 19 Jul 2002 06:29:45 GMT Received: from ZALI-W2K.cisco.com (che-vpn2-9.cisco.com [10.86.244.9]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id CAA24807; Fri, 19 Jul 2002 02:29:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20020719021207.0492ee78@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Jul 2002 02:29:38 -0400 To: Loa Andersson , MPLS wg From: Zafar Ali Subject: Re: initiating a discussion on mpls singaling protocols Cc: George Swallow , scott Giles , "Wijnen, Bert (Bert)" In-Reply-To: <3D36A98A.7070103@utfors.se> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_58987349==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_58987349==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable I favor this notion; BTW I already saw that the majority is in favor of=20 this proposal. Thanks Regards... Zafar At 01:42 PM 7/18/2002 +0200, Loa Andersson wrote: >All, > >at the mpls wg meeting at the 54th IETF in Yokohama the issue of having >two functional similar (not to say overlapping) protocols addressing >the same functional space, as rsvp-te and cr-ldp were brought up. > >The background is that when the signaling protocol for mpls traffic >engineering and setting up explicit / constraint based routes were >designed, there were two different approaches. One based on rsvp and >the other on ldp. It was not at that time possible to resolve the >differences between the two approaches and this protocol duplication >as been reflected in creation of sometimes functional duplicate >specifications. > >Since then both protocols has been progressed to proposed standard >and implemented. > >However, as has been shown in the survey on signaling protocols for >GMPLS the implementations of rsvp-te far out number the cr-ldp >implementations. As there are issues with having two similar standards >(potentially diverging), and it generates duplicate work in several >ietf working groups, the question was asked whether we should make >cr-ldp informational (which still make it available and possible to >work with) and progress only rsvp-te on the standards track. > >At the meeting there were a wide spread support for this idea, but >it was ruled that it was premature to call wg consensus on this at the >meeting and that we wanted to take the discussion on the mpls mailing >list. > >This mail is to initiate this discussion. Please keep the discussion >on the mpls list, do not cross post other lists. A separate mail to >the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this >discussion. > >/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 > > --=====================_58987349==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I favor this notion; BTW I already saw that the majority is in favor of this proposal.

Thanks

Regards... Zafar

At 01:42 PM 7/18/2002 +0200, Loa Andersson wrote:
All,

at the mpls wg meeting at the 54th IETF in Yokohama the issue of having
two functional similar (not to say overlapping) protocols=20 addressing
the same functional space, as rsvp-te and cr-ldp were brought up.

The background is that when the signaling protocol for mpls traffic
engineering and setting up explicit / constraint based routes were
designed, there were two different approaches. One  based on rsvp and
the other on ldp. It was not at that time possible to resolve the
differences between the two approaches and this protocol=20 duplication
as been reflected in creation of sometimes functional duplicate
specifications.

Since then both protocols has been progressed to proposed standard
and implemented.

However, as has been shown in the survey on signaling protocols for
GMPLS the implementations of rsvp-te far out number the cr-ldp
implementations. As there are issues with having two similar standards
(potentially diverging), and it generates duplicate work in several
ietf working groups, the question was asked whether we should make
cr-ldp informational (which still make it available and possible to
work with) and progress only rsvp-te on the standards track.

At the meeting there were a wide spread support for this idea, but
it was ruled that it was premature to call wg consensus on this at the
meeting and that we wanted to take the discussion on the mpls mailing
list.

This mail is to initiate this discussion. Please keep the=20 discussion
on the mpls list, do not cross post other lists. A separate mail to
the ccamp, pwe3 and ppvpn has been sent to inform those wg's of=20 this
discussion.

/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


--=====================_58987349==_.ALT-- From owner-mpls@UU.NET Fri Jul 19 02:51:07 2002 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 ESMTP id CAA01933 for ; Fri, 19 Jul 2002 02:51:06 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydn19929 for ; Fri, 19 Jul 2002 06:52:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmydn19182; Fri, 19 Jul 2002 06:51:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmydn06338 for mpls-outgoing; Fri, 19 Jul 2002 06:51:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmydn06333 for ; Fri, 19 Jul 2002 06:51: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 QQmydn05385 for ; Fri, 19 Jul 2002 06:51:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydn18876 for ; Fri, 19 Jul 2002 06:51:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmydn18871 for ; Fri, 19 Jul 2002 06:51:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA26201 for ; Fri, 19 Jul 2002 02:51:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA00559 for mpls@uu.net; Fri, 19 Jul 2002 02:51:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmydn06309 for ; Fri, 19 Jul 2002 06:50:40 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 QQmydn02887 for ; Fri, 19 Jul 2002 06:49:43 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydn26271 for ; Fri, 19 Jul 2002 06:49:42 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmydn26260 for ; Fri, 19 Jul 2002 06:49:41 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 12:24:49 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA064A2FE2@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: Ping Pan Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 19 Jul 2002 12:21:46 +0530 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, your first couple of paras talk about number of LSPs and failure recovery. But even, for this refresh reduction has to be turned on. Its an additional add on , in terms of complexity,state info and code.This is only one aspect of the scaling. The other is as you said large number of LSPs going on and off. Scalability is not just a question of just whether you can manage, but also if its efficient to do it the way its done. Vijay -----Original Message----- From: Ping Pan [mailto:pingpan@cs.columbia.edu] Sent: Friday, July 19, 2002 12:12 PM To: Vijayanand C - CTD, Chennai. Subject: Re: initiating a discussion on mpls singaling protocols Did you actually read the first two paragraphs of my comment? RSVP-TE does scale. Period. - Ping Vijayanand C - CTD, Chennai. wrote: >>Now, back to RSVP, when it is used to provide QoS signaling for >>inter-active real-time sessions (such as voice), it does not work well. >>This is mainly because the duration for real-time sessions is normally >>short. An average phone call is 3-4 minutes. When you plug in the >>network topology of an existing SS7 network, and the desired goal of the >>3G networks, the number of RSVP session changes (on/off traffic sources) >>is in the range of a few thousands sessions *per second*. When using >>RSVP, routers will be under a lot of stress. In this case, RSVP is not >>sufficient, refresh reduction has no use, and the soft-state approach >>seems to be a joke. I think this is the problem that NSIS WG is trying >>to handle. >> > > This is precisely the kind of scalability/performance issue that I ( and > probably nagabhushana) were pointing to. Soft state is not scalable always. > This problem is likely to be acute when GMPLS networks are fully deployed. > > Vijay > > From owner-mpls@UU.NET Fri Jul 19 03:08:37 2002 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 ESMTP id DAA02139 for ; Fri, 19 Jul 2002 03:08:37 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydo06705 for ; Fri, 19 Jul 2002 07:09:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmydo05931; Fri, 19 Jul 2002 07:09:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmydo28239 for mpls-outgoing; Fri, 19 Jul 2002 07:08:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmydo28233 for ; Fri, 19 Jul 2002 07:08:51 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 QQmydo06050 for ; Fri, 19 Jul 2002 07:08:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydo05218 for ; Fri, 19 Jul 2002 07:08:13 GMT Received: from WS0005.indiatimes.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.199.93.15]) id QQmydo05214 for ; Fri, 19 Jul 2002 07:08:12 GMT Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id LAA00395; Fri, 19 Jul 2002 11:57:10 +0530 From: "Balthazar S" Message-Id: <200207190627.LAA00395@WS0005.indiatimes.com> To: "Vijayanand C - CTD Chennai", "MPLS wg" CC: Reply-To: "Balthazar S" Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 19 Jul 2002 12:04:33 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk I agree with what Vijay and bhushana have to say. IMHO, judging a protocol as redundant just because most of the current implementations (and of course, leading vendors) support RSVP-TE, is not right. As Vijay says, we need to compare the merits-demerits of each protocol before we arrive at a collective decision. Regards, Balthazar. "Vijayanand C - CTD, Chennai." wrote: I agree with what Bhushana says.We need to look at it from the technical merits apart from who supports RSVP-TE and who does'nt. I think RSVP-TE has become more popular not because of its technical superiority over CR LDP but purely due to the push it has received from a few leading vendors, who choose to use it since they already had RSVP. The support for RSVP-TE is not because of its technical merits but because of the leading vendors choosing it causing others to meekly follow suit. However, it is not too late to weigh its merits against CR LDP. CR LDP is much more cleaner and has lesser scalability issues. Also, when one has LDP it is much easier to have CR LDP than extending RSVP for RSVP-TE. CR LDP is specifically meant for TE in MPLS and hence is advantageous. From an implementors point of view also,having been involved in implementation of both the protocols, I feel CR LDP is much easier to understand, implement and maintain. One also needs to look at other performance issues, which may become critical in GMPLS, I wonder if anyone has checked it. Regards, Vijay -----Original Message----- From: Nagabhushana Ramaswamy Nadig [mailto:nagabhushana.ramaswamy@wipro.com] Sent: Thursday, July 18, 2002 9:45 PM To: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols This message uses a character set that is not supported by the Internet Service. To view the original message content, open the attached message. If the text doesn't display correctly, save the attachment to disk, and then open it using a viewer that can display the original character set. Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in From owner-mpls@UU.NET Fri Jul 19 05:12:15 2002 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 ESMTP id FAA03846 for ; Fri, 19 Jul 2002 05:12:14 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydw20376 for ; Fri, 19 Jul 2002 09:13:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmydw19815; Fri, 19 Jul 2002 09:13:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmydw18817 for mpls-outgoing; Fri, 19 Jul 2002 09:12:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmydw18792 for ; Fri, 19 Jul 2002 09:12: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 QQmydw23568 for ; Fri, 19 Jul 2002 09:12:19 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmydw01114 for ; Fri, 19 Jul 2002 09:12:19 GMT Received: from mailrelay2.alcatel.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailrelay1.alcatel.de [194.113.59.75]) id QQmydw01095 for ; Fri, 19 Jul 2002 09:12:18 GMT Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.9.3/8.9.3) with ESMTP id LAA05293; Fri, 19 Jul 2002 11:11:48 +0200 (MET DST) Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 17VTnf-0005KK-00; Fri, 19 Jul 2002 11:11:47 +0200 Received: from sls8s6 ([149.204.30.28] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 17VTnf-0007I2-00; Fri, 19 Jul 2002 11:11:47 +0200 Message-ID: <3D37D7D4.B1F94827@alcatel.de> Date: Fri, 19 Jul 2002 11:11:48 +0200 From: Dieter Beller Organization: Alcatel SEL AG, TND Stuttgart, Germany X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: "Vijayanand C - CTD, Chennai." , Ping Pan CC: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <55E277B99171E041ABF5F4B1C6DDCA064A2E19@haritha.hclt.com> Content-Type: multipart/mixed; boundary="------------E128BB2872739B7351BBFCC2" X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------E128BB2872739B7351BBFCC2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vijay, Ping and all, see my comment below. "Vijayanand C - CTD, Chennai." wrote: > >Now, back to RSVP, when it is used to provide QoS signaling for > >inter-active real-time sessions (such as voice), it does not work well. > >This is mainly because the duration for real-time sessions is normally > >short. An average phone call is 3-4 minutes. When you plug in the > >network topology of an existing SS7 network, and the desired goal of the > >3G networks, the number of RSVP session changes (on/off traffic sources) > >is in the range of a few thousands sessions *per second*. When using > >RSVP, routers will be under a lot of stress. In this case, RSVP is not > >sufficient, refresh reduction has no use, and the soft-state approach > >seems to be a joke. I think this is the problem that NSIS WG is trying > >to handle. > > This is precisely the kind of scalability/performance issue that I ( and > probably nagabhushana) were pointing to. Soft state is not scalable always. > This problem is likely to be acute when GMPLS networks are fully deployed. > > Vijay I disagree with the statement being made for GMPLS above. GMPLS is still a brand new technology in transmission networks and is intended to make them dynamic. But the dynamics you are describing above will not come over night. This will be the result of a rather lengthy evolution from a quasi-static situation which we have today to a fully dynamic network in a couple of years - and I'm not sure whether we will arrive at a situation where thousandsof large pipe connections will appear and dis- appear within a second. This will definitely not happen in the backbone because traffic is expected to be highly aggregated there. Actually, I'm in favour of the proposal how to move forward with RSVP-TE (standars track) and CR-LDP (informational). Cheers, Dieter --------------E128BB2872739B7351BBFCC2 Content-Type: text/x-vcard; charset=us-ascii; name="D.Beller.vcf" Content-Description: Card for Dieter Beller Content-Disposition: attachment; filename="D.Beller.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Beller;Dieter tel;fax:+49 711 821 - 42303 tel;work:+49 711 821 - 43125 x-mozilla-html:FALSE org:Alcatel - Optics Group - Terrestrial Networks Division;US/EA3 version:2.1 email;internet:D.Beller@alcatel.de adr;quoted-printable:;;Alcatel SEL AG,=0D=0ALorenzstrasse 10;Stuttgart;;70435;Germany fn:Beller, Dieter end:vcard --------------E128BB2872739B7351BBFCC2-- From owner-mpls@UU.NET Fri Jul 19 07:18:16 2002 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 ESMTP id HAA05199 for ; Fri, 19 Jul 2002 07:18:16 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyef03085 for ; Fri, 19 Jul 2002 11:19:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyef02393; Fri, 19 Jul 2002 11:18:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyef09347 for mpls-outgoing; Fri, 19 Jul 2002 11:18:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyef09342 for ; Fri, 19 Jul 2002 11:18: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 QQmyef22472 for ; Fri, 19 Jul 2002 11:18:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyef01682 for ; Fri, 19 Jul 2002 11:18:14 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 QQmyef01495 for ; Fri, 19 Jul 2002 11:17:59 GMT Received: from m2vwall5.wipro.com ([10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g6JBHqj28470 for ; Fri, 19 Jul 2002 16:47:53 +0530 (IST) Received: from wipro.com ([10.117.3.140]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GZHU1D00.AX0 for ; Fri, 19 Jul 2002 16:47:37 +0530 Message-ID: <3D37F4A7.6C7BECC9@wipro.com> Date: Fri, 19 Jul 2002 16:44:48 +0530 From: Vinay Vernekar X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 CC: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <3D37068B.9020601@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I don't agree with the proposal of making CR-LDP as informational and RSVP-TE as the standard. The current deployments may not be indicative of CR-LDP not being a standard MPLS protocol. RSVP-TE being an extension to existing RSVP protocol addresses the IntServ model of resource reservation, whereas CR-LDP which is extension to LDP for QoS signalling should be flexible enough to address IntServ and Diffserv over MPLS models. Such a signalling protocol is a need for Next Generation Networks. Vinay Bora Akyol wrote: > We went through these same discussions in 1998. It may be argued that RSVP > has some scaling problems but in real deployments, none of these > materialized. > So, I think the market has spoken already. > > I support making CR-LDP informational and RSVP-TE standard. > > Bora > > Ron Bonica wrote: > > >>3. The scalability issues of rsvp is a known fact today (soft state=20 > >>maintenance, refreshment, error handling etc)...because of which the > >>plain rsvp itself never took off in a big way in internet. > >> > >> > > > >Many operators have deployed RSVP-TE. Are you aware of any who have deployed > >it and run into scaling problems? > > > > Ron > > > > > > > > From owner-mpls@UU.NET Fri Jul 19 08:32:53 2002 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 ESMTP id IAA06774 for ; Fri, 19 Jul 2002 08:32:52 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyek19427 for ; Fri, 19 Jul 2002 12:33:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyek18303; Fri, 19 Jul 2002 12:33:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyek04566 for mpls-outgoing; Fri, 19 Jul 2002 12:32:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyek04561 for ; Fri, 19 Jul 2002 12:32:46 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 QQmyek11055 for ; Fri, 19 Jul 2002 12:32:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyek17443 for ; Fri, 19 Jul 2002 12:32:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyek17439 for ; Fri, 19 Jul 2002 12:32:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA07236 for ; Fri, 19 Jul 2002 08:32:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA05183 for mpls@uu.net; Fri, 19 Jul 2002 08:32:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyek04522 for ; Fri, 19 Jul 2002 12:31: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 QQmyek24043 for ; Fri, 19 Jul 2002 12:31:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyek17245 for ; Fri, 19 Jul 2002 12:31:25 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 QQmyek17241 for ; Fri, 19 Jul 2002 12:31:25 GMT Received: from JVASSEUR-W2K.cisco.com ([10.49.250.169]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA08012; Fri, 19 Jul 2002 14:31:12 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020719140741.01927b90@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Jul 2002 14:31:09 +0200 To: From: Jean Philippe Vasseur Subject: Re: initiating a discussion on mpls singaling protocols Cc: MPLS wg In-Reply-To: References: <3D36A98A.7070103@utfors.se> 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 IAA06774 Hi, At 20:15 18/07/2002 +0400, Nagabhushana Ramaswamy Nadig wrote: >Hi, > A long time pending issue for discussion. To beging with > >1. In my opinion the number of implementation can't be a good metric to >dictate a standard. but the number of deployment might be a good metric ... See bellow >A better approach and design matters much more than >this. We see more implementations of rsvp rather being taken up as >extention to the existing code base. So all those people who would have >gone for rsvp-te extention to leverage on this advantage of existing code >with them. > >2. CR-LDP is designed for a specific purpose of enabling mpls networks >forTE. Where as rsvp-te is one which was meant for a different purpose which >has been modified for this one. So it has come here with all its >drawbacksand limitations. I see CR-LDP as a much cleanner and focussed >approach to address specific issues and is more flexible. > >3. The scalability issues of rsvp is a known fact today (soft state=20 >maintenance, refreshment, error handling etc)...because of which the >plain rsvp itself never took off in a big way in internet. Again sorry to be so pragmatic but my impression was that this argument had been debated a while back and it seems clear this is a non argument. Thousands of TE LSPs have been demonstrated in real-life networks without any scalability problems. If you have any concern with refreshes, just use RFC2961. Then if you want to reduce the number of TE LSPs, introduce hierarchy. Do not confuse RSVP used in the context of Interserv with per-flow reservation and RSVP TE for TE LSP. So the proposal of making CD-LDP informational and progress only RSVP TE on the standards track looks very reasonable to me. JP. >The list grows.... >So need to say now that I am a CR-LDP man..... > > >regards >Bhushana > >On Thu, 18 Jul 2002, Loa Andersson wrote: > > > All, > > > > at the mpls wg meeting at the 54th IETF in Yokohama the issue of having > > two functional similar (not to say overlapping) protocols addressing > > the same functional space, as rsvp-te and cr-ldp were brought up. > > > > The background is that when the signaling protocol for mpls traffic > > engineering and setting up explicit / constraint based routes were > > designed, there were two different approaches. One based on rsvp and > > the other on ldp. It was not at that time possible to resolve the > > differences between the two approaches and this protocol duplication > > as been reflected in creation of sometimes functional duplicate > > specifications. > > > > Since then both protocols has been progressed to proposed standard > > and implemented. > > > > However, as has been shown in the survey on signaling protocols for > > GMPLS the implementations of rsvp-te far out number the cr-ldp > > implementations. As there are issues with having two similar standards > > (potentially diverging), and it generates duplicate work in several > > ietf working groups, the question was asked whether we should make > > cr-ldp informational (which still make it available and possible to > > work with) and progress only rsvp-te on the standards track. > > > > At the meeting there were a wide spread support for this idea, but > > it was ruled that it was premature to call wg consensus on this at the > > meeting and that we wanted to take the discussion on the mpls mailing > > list. > > > > This mail is to initiate this discussion. Please keep the discussion > > on the mpls list, do not cross post other lists. A separate mail to > > the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this > > discussion. > > > > /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 Fri Jul 19 08:36:16 2002 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 ESMTP id IAA06830 for ; Fri, 19 Jul 2002 08:36:16 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyek20692 for ; Fri, 19 Jul 2002 12:37:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyek19832; Fri, 19 Jul 2002 12:36:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyek04746 for mpls-outgoing; Fri, 19 Jul 2002 12:36:23 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyek04725 for ; Fri, 19 Jul 2002 12:36: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 QQmyek22453 for ; Fri, 19 Jul 2002 12:36:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyek18865 for ; Fri, 19 Jul 2002 12:36:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyek18851 for ; Fri, 19 Jul 2002 12:36:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA07397 for ; Fri, 19 Jul 2002 08:36:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA05640 for mpls@uu.net; Fri, 19 Jul 2002 08:36:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyek04638 for ; Fri, 19 Jul 2002 12: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 QQmyek28603 for ; Fri, 19 Jul 2002 12:32:55 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyek18096 for ; Fri, 19 Jul 2002 12:32:55 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 QQmyek18090 for ; Fri, 19 Jul 2002 12:32:54 GMT Received: from JVASSEUR-W2K.cisco.com ([10.49.250.169]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA08173; Fri, 19 Jul 2002 14:32:48 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020719143201.01c96558@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 19 Jul 2002 14:32:46 +0200 To: "Vijayanand C - CTD, Chennai." From: Jean Philippe Vasseur Subject: RE: initiating a discussion on mpls singaling protocols Cc: MPLS wg , nagabhushana.ramaswamy@wipro.com In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA064807B2@haritha.hclt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:00 19/07/2002 +0530, Vijayanand C - CTD, Chennai. wrote: >I agree with what Bhushana says.We need to look at it from the technical >merits apart from who supports RSVP-TE and who does'nt. > >I think RSVP-TE has become more popular not because of its technical >superiority over CR LDP but purely due to the push it has received from a >few leading vendors, who choose to use it since they already had RSVP. The >support for RSVP-TE is not because of its technical merits but because of >the leading vendors choosing it causing others to meekly follow suit. >However, it is not too late to weigh its merits against CR LDP. > >CR LDP is much more cleaner and has lesser scalability issues. Also, when >one has LDP it is much easier to have CR LDP than extending RSVP for >RSVP-TE. CR LDP is specifically meant for TE in MPLS and hence is >advantageous. don't see the technical arguments there ... JP. > From an implementors point of view also,having been involved >in implementation of both the protocols, I feel CR LDP is much easier to >understand, implement and maintain. One also needs to look at other >performance issues, which may become critical in GMPLS, I wonder if anyone >has checked it. > > >Regards, >Vijay > >-----Original Message----- >From: Nagabhushana Ramaswamy Nadig >[mailto:nagabhushana.ramaswamy@wipro.com] >Sent: Thursday, July 18, 2002 9:45 PM >To: MPLS wg >Subject: Re: initiating a discussion on mpls singaling protocols > > >This message uses a character set that is not supported by the Internet >Service. To view the original message content, open the attached message. >If the text doesn't display correctly, save the attachment to disk, and then >open it using a viewer that can display the original character set. From owner-mpls@UU.NET Fri Jul 19 09:12:52 2002 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 ESMTP id JAA07440 for ; Fri, 19 Jul 2002 09:12:51 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyem15101 for ; Fri, 19 Jul 2002 13:13:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyem14076; Fri, 19 Jul 2002 13:13:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyem28564 for mpls-outgoing; Fri, 19 Jul 2002 13:12:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyem28538 for ; Fri, 19 Jul 2002 13:12:30 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 QQmyem20206 for ; Fri, 19 Jul 2002 13:11:02 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyem08317 for ; Fri, 19 Jul 2002 13:11:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyem08306 for ; Fri, 19 Jul 2002 13:11:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09064 for ; Fri, 19 Jul 2002 09:11:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA10195 for mpls@uu.net; Fri, 19 Jul 2002 09:11:01 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyem27853 for ; Fri, 19 Jul 2002 13: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 QQmyem14789 for ; Fri, 19 Jul 2002 13:09:13 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmyek27719 for ; Fri, 19 Jul 2002 12:38:54 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 18:13:36 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA064A3648@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: Jean Philippe Vasseur Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 19 Jul 2002 18:10:34 +0530 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 The technical issues are stated in this and subsequent mails and can be restated as - scalability with efficiency and performance, esp in future GMPLS networks - Ease of implementation and maintenance. A more cleaner protocol than RSVP-TE - Co-existence with LDP Regards, Vijay -----Original Message----- From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] Sent: Friday, July 19, 2002 6:03 PM To: Vijayanand C - CTD, Chennai. Cc: MPLS wg; nagabhushana.ramaswamy@wipro.com Subject: RE: initiating a discussion on mpls singaling protocols At 11:00 19/07/2002 +0530, Vijayanand C - CTD, Chennai. wrote: >I agree with what Bhushana says.We need to look at it from the technical >merits apart from who supports RSVP-TE and who does'nt. > >I think RSVP-TE has become more popular not because of its technical >superiority over CR LDP but purely due to the push it has received from a >few leading vendors, who choose to use it since they already had RSVP. The >support for RSVP-TE is not because of its technical merits but because of >the leading vendors choosing it causing others to meekly follow suit. >However, it is not too late to weigh its merits against CR LDP. > >CR LDP is much more cleaner and has lesser scalability issues. Also, when >one has LDP it is much easier to have CR LDP than extending RSVP for >RSVP-TE. CR LDP is specifically meant for TE in MPLS and hence is >advantageous. don't see the technical arguments there ... JP. > From an implementors point of view also,having been involved >in implementation of both the protocols, I feel CR LDP is much easier to >understand, implement and maintain. One also needs to look at other >performance issues, which may become critical in GMPLS, I wonder if anyone >has checked it. > > >Regards, >Vijay > >-----Original Message----- >From: Nagabhushana Ramaswamy Nadig >[mailto:nagabhushana.ramaswamy@wipro.com] >Sent: Thursday, July 18, 2002 9:45 PM >To: MPLS wg >Subject: Re: initiating a discussion on mpls singaling protocols > > >This message uses a character set that is not supported by the Internet >Service. To view the original message content, open the attached message. >If the text doesn't display correctly, save the attachment to disk, and then >open it using a viewer that can display the original character set. From owner-mpls@UU.NET Fri Jul 19 09:36:03 2002 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 ESMTP id JAA07770 for ; Fri, 19 Jul 2002 09:36:03 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyeo05716 for ; Fri, 19 Jul 2002 13:36:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyeo04980; Fri, 19 Jul 2002 13:36:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyeo00935 for mpls-outgoing; Fri, 19 Jul 2002 13:36:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyeo00930 for ; Fri, 19 Jul 2002 13:36: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 QQmyeo04577 for ; Fri, 19 Jul 2002 13:35:34 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyeo04155 for ; Fri, 19 Jul 2002 13:35:34 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 QQmyeo04145 for ; Fri, 19 Jul 2002 13:35:33 GMT Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6JDZV119020 for ; Fri, 19 Jul 2002 09:35:32 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.38.228]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA21703; Fri, 19 Jul 2002 09:35:30 -0400 (EDT) Message-ID: <3D3815A2.DB62931E@lucent.com> Date: Fri, 19 Jul 2002 09:35:30 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <9FBD322B7824D511B36900508BF93C9C04A8BB8C@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Sorry, a side topic. :-) Cause many folks raise the RSVP-TE soft state issue and its apparent drawbacks for GMPLS environment. Just a question, if we configure the refresh timer very large, disable the refresh reduction and also maximize the time-out multiplier. Will these help, or they make things worse? Thanks, Yangguang From owner-mpls@UU.NET Fri Jul 19 09:46:06 2002 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 ESMTP id JAA07893 for ; Fri, 19 Jul 2002 09:46:06 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyep07773 for ; Fri, 19 Jul 2002 13:46:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyep06988; Fri, 19 Jul 2002 13:46:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyep01660 for mpls-outgoing; Fri, 19 Jul 2002 13:46:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyep01655 for ; Fri, 19 Jul 2002 13:46:09 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 QQmyep10799 for ; Fri, 19 Jul 2002 13:45:51 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyep17441 for ; Fri, 19 Jul 2002 13:45:50 GMT Received: from olympus.noc.uoa.gr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: olympus.noc.uoa.gr [195.134.100.100]) id QQmyep17422 for ; Fri, 19 Jul 2002 13:45:49 GMT Received: from nms2000 (nms-2000.win-2k.noc.uoa.gr [195.134.90.62]) by olympus.noc.uoa.gr (8.11.6/8.11.6) with SMTP id g6JDjlp19266 for ; Fri, 19 Jul 2002 16:45:47 +0300 (EET DST) Message-ID: <05f901c22f2a$9610cad0$3e5a86c3@win2k.noc.uoa.gr> From: "Panos Kolyvas" To: Subject: BASIC LDP between an ERX and a CISCO 3660 (Fast Ethernet) Date: Fri, 19 Jul 2002 16:45:46 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05F6_01C22F43.BB3C4A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Filter-Version: 1.8 (olympus) Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_05F6_01C22F43.BB3C4A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi to all, has anybody tested a basic MPLS configuration (Label exchange with LDP) = between a UNISPHERE ERX and a CISCO 3661 via Fast Ethernet interfaces? Thanks in advance, Panos Kolyvas -------------------------------------------------------------------------= -------------------------------- The ERX has the following configuration: ERX1#sh conf virtual-router PE-FE ! Unisphere Edge Routing Switch ERX-1400 ! Version: 3.2.3 patch-10.2 (May 23, 2002 12:01) ! Copyright (c) 1999-2002 Unisphere Networks, Inc. All rights reserved. ! ! Configuration script generated on FRI JUL 19 2002 16:35:19 UTC ! ! NOTE: This script represents only a subset of the full system = configuration. ! virtual-router PE-FE aaa authentication ppp default radius aaa accounting ppp default radius ! ip address-pool local mpls ! mpls topology-driven-lsp ip-profile "IP-PE-FE" mpls topology-driven-lsp ip-interfaces egress host-only mpls topology-driven-lsp ip-interfaces ingress host-only ! mpls rsvp interface profile default ! mpls ldp interface profile "PE-FE" hello hold-time 10 no cr-ldp ! mpls ldp interface profile default ! interface null 0 interface loopback 0 ip address 4.4.4.4 255.255.255.255 ! interface pos 4/0 pos framing sdh clock source internal chassis no pos scramble-atm encapsulation ppp ! interface atm 9/0 atm sonet stm-1 atm clock internal chassis ! interface atm 9/1 atm sonet stm-1 ! interface atm 9/2 atm sonet stm-1 atm clock internal chassis atm oam 6 end-loopback atm oam 6 seg-loopback ! interface atm 9/3 atm sonet stm-1 atm clock internal chassis ! interface fastEthernet 11/0 ip address 30.30.30.1 255.255.255.0 ip proxy-arp mpls mpls ldp profile "PE-FE" ! interface fastEthernet 11/1 ! no ip source-route router ospf 99 ! Area 0.0.0.0 network 4.4.4.4 0.0.0.0 area 0.0.0.0 network 30.30.30.0 0.0.0.255 area 0.0.0.0 ! where IP-PE-FE is a profile in default virtual router: profile "IP-PE-FE" ip unnumbered loopback 0 The CISCO router has the following configuration: 3662CE1#wr t Building configuration... Current configuration : 5893 bytes ! ! Last configuration change at 13:00:28 UTC Thu Jul 18 2002 by cisco ! NVRAM config last updated at 13:00:30 UTC Thu Jul 18 2002 by cisco ! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname 3662CE1 ! boot system flash c3660-js-mz.122-8.T.bin boot system flash c3660-js-mz.122-7.bin boot system flash c3660-p-mz.122-5a.bin boot system flash c3660-is-mz.121-5.T8 enable password cisco ! username cisco password 0 cisco ip subnet-zero ! ! no ip domain-lookup ! ! ip multicast-routing ip cef clns routing mpls traffic-eng tunnels isdn switch-type basic-net3 isdn voice-call-failure 0 ! ! interface Loopback2 description Kolyvas-7275610-MPLS-me-ERX-2 ip address 5.5.5.5 255.255.255.255 ! interface FastEthernet0/1 ip address 30.30.30.2 255.255.255.0 duplex auto speed auto mpls label protocol ldp tag-switching ip ! interface FastEthernet0/1.1 description **** Link me ton 7500 gia MPLS VPN **** bandwidth 10000000 ! router ospf 3 router-id 3.3.3.3 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0.0.0.0 network 5.5.5.5 0.0.0.0 area 0.0.0.0 network 30.30.30.0 0.0.0.255 area 0.0.0.0 ! 3662CE1# Some show commands follow: 3662CE1# sh ver Cisco Internetwork Operating System Software IOS (tm) 3600 Software (C3660-JS-M), Version 12.2(8)T, RELEASE SOFTWARE = (fc2) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Thu 14-Feb-02 11:03 by ccai Image text-base: 0x60008940, data-base: 0x61880000 ROM: System Bootstrap, Version 12.0(6r)T, RELEASE SOFTWARE (fc1) ROM: 3600 Software (C3660-IS-M), Version 12.1(5)T8, RELEASE SOFTWARE = (fc1) 3662CE1 uptime is 1 week, 3 days, 6 hours, 3 minutes System returned to ROM by power-on System restarted at 07:36:17 UTC Tue Jul 9 2002 System image file is "flash:c3660-js-mz.122-8.T.bin" cisco 3660 (R527x) processor (revision 1.0) with 253952K/8192K bytes of = memory. Processor board ID JAB052281UL R527x CPU at 225Mhz, Implementation 40, Rev 10.0, 2048KB L2 Cache Channelized E1, Version 1.0. Bridging software. X.25 software, Version 3.0.0. SuperLAT software (copyright 1990 by Meridian Technology Corp). TN3270 Emulation software. Primary Rate ISDN software, Version 1.1. Basic Rate ISDN software, Version 1.1. 3660 Chassis type: ENTERPRISE 2 FastEthernet/IEEE 802.3 interface(s) 2 Serial network interface(s) 2 ISDN Basic Rate interface(s) 2 Channelized E1/PRI port(s) 4 Voice TE BRI interface(s) DRAM configuration is 64 bits wide with parity disabled. 125K bytes of non-volatile configuration memory. 65536K bytes of processor board System flash (Read/Write) 3662CE1#sh mpls ldp discovery Local LDP Identifier: 192.168.3.49:0 Discovery Sources: Interfaces: FastEthernet0/1 (ldp): xmit/recv LDP Id: 30.30.30.1:0 =20 From this output it seems that the 3662 has transmitted and received LDP = messages and also it has learned the LDP id of the ERX system. The following show commands are from the Unisphere ERX: ERX1:PE-FE#sh mpls forwarding ERX1:PE-FE#sh mpls ip binding ERX1:PE-FE#sh mpls interface Interface fastEthernet11/0 Up RSVP not configured LDP enabled with profile PE-FE, CR-LDP disabled IP interfaces on this MPLS interface: 30.30.30.1/24 MPLS Statistics: Rcvd: 0 failed lbl lookup, 0 octets, 0 hcOctets 0 pkts, 0 hcPkts, 0 errors, 0 discards Sent: 0 octets, 0 hcOctets, 0 pkts 0 hcPkts, 0 errors, 0 discards ------=_NextPart_000_05F6_01C22F43.BB3C4A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi to all,
 
has anybody tested a basic MPLS = configuration=20 (Label exchange with LDP) between a UNISPHERE ERX and a CISCO 3661 via = Fast=20 Ethernet interfaces?
 
Thanks in advance,
 
Panos Kolyvas
 
 
 
----------------------------------------------------------------= -----------------------------------------
 
The ERX has the following=20 configuration:
 
 
 
ERX1#sh conf virtual-router PE-FE
! = Unisphere=20 Edge Routing Switch ERX-1400
! Version: 3.2.3 patch-10.2 (May 23, = 2002 =20 12:01)
! Copyright (c) 1999-2002 Unisphere Networks, Inc.  All = rights=20 reserved.
!
! Configuration script generated on FRI JUL 19 2002 = 16:35:19=20 UTC
!
! NOTE:  This script represents only a subset of the = full=20 system configuration.
!
virtual-router PE-FE
aaa authentication = ppp=20 default radius
aaa accounting ppp default radius
!
ip = address-pool=20 local
mpls
!
mpls topology-driven-lsp ip-profile = "IP-PE-FE"
mpls=20 topology-driven-lsp ip-interfaces egress host-only
mpls = topology-driven-lsp=20 ip-interfaces ingress host-only
!
mpls rsvp interface profile=20 default
!
mpls ldp interface profile "PE-FE"
 hello = hold-time=20 10
 no cr-ldp
!
mpls ldp interface profile=20 default
!
interface null 0
interface loopback 0
 ip = address=20 4.4.4.4 255.255.255.255
!
interface pos 4/0
 pos framing=20 sdh
 clock source internal chassis
 no pos=20 scramble-atm
 encapsulation ppp
!
interface atm = 9/0
 atm=20 sonet stm-1
 atm clock internal chassis
!
interface atm=20 9/1
 atm sonet stm-1
!
interface atm 9/2
 atm = sonet=20 stm-1
 atm clock internal chassis
 atm oam 6=20 end-loopback
 atm oam 6 seg-loopback
!
interface atm=20 9/3
 atm sonet stm-1
 atm clock internal=20 chassis
!
interface fastEthernet 11/0
 ip address = 30.30.30.1=20 255.255.255.0
 ip proxy-arp
 mpls
 mpls ldp = profile=20 "PE-FE"
!
interface fastEthernet 11/1
!
no ip = source-route
router=20 ospf 99
! Area 0.0.0.0
 network 4.4.4.4 0.0.0.0 area=20 0.0.0.0
 network 30.30.30.0 0.0.0.255 area = 0.0.0.0
!
 
where IP-PE-FE is a profile in default = virtual=20 router:
 
profile "IP-PE-FE"
 ip = unnumbered loopback=20 0
 
 
The CISCO router has the following=20 configuration:
 
3662CE1#wr t
Building=20 configuration...
 
Current configuration : 5893 = bytes
!
! Last=20 configuration change at 13:00:28 UTC Thu Jul 18 2002 by cisco
! NVRAM = config=20 last updated at 13:00:30 UTC Thu Jul 18 2002 by cisco
!
version=20 12.2
service timestamps debug uptime
service timestamps log = uptime
no=20 service password-encryption
!
hostname 3662CE1
!
boot system = flash=20 c3660-js-mz.122-8.T.bin
boot system flash = c3660-js-mz.122-7.bin
boot=20 system flash c3660-p-mz.122-5a.bin
boot system flash=20 c3660-is-mz.121-5.T8
enable password cisco
!
username cisco = password 0=20 cisco
ip subnet-zero
!
!
no ip domain-lookup
!
!
ip = multicast-routing
ip cef
clns routing
mpls traffic-eng = tunnels
isdn=20 switch-type basic-net3
isdn voice-call-failure = 0
!
!
interface=20 Loopback2
 description Kolyvas-7275610-MPLS-me-ERX-2
 ip = address=20 5.5.5.5 255.255.255.255
!
interface FastEthernet0/1
 ip = address=20 30.30.30.2 255.255.255.0
 duplex auto
 speed = auto
 mpls=20 label protocol ldp
 tag-switching ip
!
interface=20 FastEthernet0/1.1
 description **** Link me ton 7500 gia MPLS = VPN=20 ****
 bandwidth 10000000
!
router ospf 3
 router-id=20 3.3.3.3
 log-adjacency-changes
 network 3.3.3.3 0.0.0.0 = area=20 0.0.0.0
 network 5.5.5.5 0.0.0.0 area 0.0.0.0
 network=20 30.30.30.0 0.0.0.255 area 0.0.0.0
!
3662CE1#

Some show commands follow:
 
3662CE1#  sh ver
Cisco Internetwork Operating System=20 Software
IOS (tm) 3600 Software (C3660-JS-M), Version 12.2(8)T,  = RELEASE=20 SOFTWARE (fc2)
TAC Support: http://www.cisco.com/tac
Copyrig= ht (c)=20 1986-2002 by cisco Systems, Inc.
Compiled Thu 14-Feb-02 11:03 by=20 ccai
Image text-base: 0x60008940, data-base: 0x61880000
 
ROM: System Bootstrap, Version 12.0(6r)T, RELEASE SOFTWARE = (fc1)
ROM:=20 3600 Software (C3660-IS-M), Version 12.1(5)T8,  RELEASE SOFTWARE=20 (fc1)
 
3662CE1 uptime is 1 week, 3 days, 6 hours, 3 minutes
System = returned to=20 ROM by power-on
System restarted at 07:36:17 UTC Tue Jul 9 = 2002
System=20 image file is "flash:c3660-js-mz.122-8.T.bin"
 
cisco 3660 (R527x) processor (revision 1.0) with 253952K/8192K = bytes of=20 memory.
Processor board ID JAB052281UL
R527x CPU at 225Mhz, = Implementation=20 40, Rev 10.0, 2048KB L2 Cache
Channelized E1, Version = 1.0.
Bridging=20 software.
X.25 software, Version 3.0.0.
SuperLAT software = (copyright 1990=20 by Meridian Technology Corp).
TN3270 Emulation software.
Primary = Rate ISDN=20 software, Version 1.1.
Basic Rate ISDN software, Version 1.1.
 

3660 Chassis type: ENTERPRISE
2 FastEthernet/IEEE 802.3=20 interface(s)
2 Serial network interface(s)
2 ISDN Basic Rate=20 interface(s)
2 Channelized E1/PRI port(s)
4 Voice TE BRI=20 interface(s)
DRAM configuration is 64 bits wide with parity = disabled.
125K=20 bytes of non-volatile configuration memory.
65536K bytes of processor = board=20 System flash (Read/Write)
 
3662CE1#sh mpls ldp discovery
 Local LDP=20 Identifier:
    192.168.3.49:0
    = Discovery=20 Sources:
   =20 Interfaces:
        = FastEthernet0/1 (ldp):=20 xmit/recv
          =  =20 LDP Id: 30.30.30.1:0
    
From this output it seems that the 3662 has transmitted and = received=20 LDP messages and also it has learned the LDP id of the ERX system.
 
 
 
 
The following show commands are from the Unisphere = ERX:
 
ERX1:PE-FE#sh mpls forwarding
ERX1:PE-FE#sh mpls ip=20 binding
ERX1:PE-FE#sh mpls interface
Interface fastEthernet11/0=20 Up
 RSVP not configured
 LDP enabled with profile PE-FE, = CR-LDP=20 disabled
 IP interfaces on this MPLS = interface:
   =20 30.30.30.1/24
 
 MPLS Statistics:
   Rcvd: 0 failed lbl lookup, 0 = octets,=20 0 hcOctets
         0 pkts, 0 = hcPkts,=20 0 errors, 0 discards
   Sent: 0 octets, 0 hcOctets, 0=20 pkts
         0 hcPkts, 0 = errors, 0=20 discards
 

 
 ------=_NextPart_000_05F6_01C22F43.BB3C4A00-- From owner-mpls@UU.NET Fri Jul 19 10:01:14 2002 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 ESMTP id KAA08630 for ; Fri, 19 Jul 2002 10:01:13 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyeq28133 for ; Fri, 19 Jul 2002 14:02:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyeq27325; Fri, 19 Jul 2002 14:01:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyeq08181 for mpls-outgoing; Fri, 19 Jul 2002 14:01:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyeq08152 for ; Fri, 19 Jul 2002 14:01:22 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 QQmyeq12595 for ; Fri, 19 Jul 2002 14:00:46 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyeq19747 for ; Fri, 19 Jul 2002 14:00:46 GMT Received: from server.nayna.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 67-89-191-66.customer.algx.net [67.89.191.66]) id QQmyeq19743 for ; Fri, 19 Jul 2002 14:00:45 GMT Received: from relay.nayna.com (relay.nayna.com [10.0.128.11]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id HAA00760; Fri, 19 Jul 2002 07:00:44 -0700 Received: from nayna.com (dhcp-131-104.nayna.com [10.0.131.104]) by relay.nayna.com (8.9.3/8.9.3) with ESMTP id HAA04750; Fri, 19 Jul 2002 07:00:15 -0700 Message-ID: <3D381B4F.36571B65@nayna.com> Date: Fri, 19 Jul 2002 06:59:43 -0700 From: Sudheer Dharanikota X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Vijayanand C - CTD, Chennai." CC: Jean Philippe Vasseur , mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <55E277B99171E041ABF5F4B1C6DDCA064A3648@haritha.hclt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Vijayanand C - CTD, Chennai." wrote: > The technical issues are stated in this and subsequent mails and can be > restated as > - scalability with efficiency and performance, esp in future GMPLS networks Why do you think sclability will be a big issue in the GMPLS networks? Remeber GMPLS is meant for transport networks. The number of active connections would be typically less than or equal to the current number of data connections in a core. > > - Ease of implementation and maintenance. A more cleaner protocol than > RSVP-TE Ease of implemenatation if you start from the beginning. If you take an initial code base from a well-known site and modifying it is not a big deal. Or am I missing something here? - sudheer > > - Co-existence with LDP > > Regards, > Vijay > > -----Original Message----- > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > Sent: Friday, July 19, 2002 6:03 PM > To: Vijayanand C - CTD, Chennai. > Cc: MPLS wg; nagabhushana.ramaswamy@wipro.com > Subject: RE: initiating a discussion on mpls singaling protocols > > At 11:00 19/07/2002 +0530, Vijayanand C - CTD, Chennai. wrote: > >I agree with what Bhushana says.We need to look at it from the technical > >merits apart from who supports RSVP-TE and who does'nt. > > > >I think RSVP-TE has become more popular not because of its technical > >superiority over CR LDP but purely due to the push it has received from a > >few leading vendors, who choose to use it since they already had RSVP. The > >support for RSVP-TE is not because of its technical merits but because of > >the leading vendors choosing it causing others to meekly follow suit. > >However, it is not too late to weigh its merits against CR LDP. > > > >CR LDP is much more cleaner and has lesser scalability issues. Also, when > >one has LDP it is much easier to have CR LDP than extending RSVP for > >RSVP-TE. CR LDP is specifically meant for TE in MPLS and hence is > >advantageous. > > don't see the technical arguments there ... > > JP. > > > From an implementors point of view also,having been involved > >in implementation of both the protocols, I feel CR LDP is much easier to > >understand, implement and maintain. One also needs to look at other > >performance issues, which may become critical in GMPLS, I wonder if anyone > >has checked it. > > > > > >Regards, > >Vijay > > > >-----Original Message----- > >From: Nagabhushana Ramaswamy Nadig > >[mailto:nagabhushana.ramaswamy@wipro.com] > >Sent: Thursday, July 18, 2002 9:45 PM > >To: MPLS wg > >Subject: Re: initiating a discussion on mpls singaling protocols > > > > > >This message uses a character set that is not supported by the Internet > >Service. To view the original message content, open the attached message. > >If the text doesn't display correctly, save the attachment to disk, and > then > >open it using a viewer that can display the original character set. From owner-mpls@UU.NET Fri Jul 19 10:18:53 2002 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 ESMTP id KAA09433 for ; Fri, 19 Jul 2002 10:18:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyer16694 for ; Fri, 19 Jul 2002 14:19:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyer16069; Fri, 19 Jul 2002 14:19:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyer27419 for mpls-outgoing; Fri, 19 Jul 2002 14:19:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyer27407 for ; Fri, 19 Jul 2002 14:19: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 QQmyer19507 for ; Fri, 19 Jul 2002 14:18:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyer14856 for ; Fri, 19 Jul 2002 14:18:30 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 QQmyer14848 for ; Fri, 19 Jul 2002 14:18: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 KAA18465 for ; Fri, 19 Jul 2002 10:18:28 -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 KAA10941 for ; Fri, 19 Jul 2002 10:18:29 -0400 (EDT) Message-ID: <3D381FBF.5000305@marconi.com> Date: Fri, 19 Jul 2002 10:18:39 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a) Gecko/20020613 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <9FBD322B7824D511B36900508BF93C9C04A8BB8C@zcard031.ca.nortel.com> <3D3815A2.DB62931E@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yangguang Xu wrote: > > Cause many folks raise the RSVP-TE soft state issue and its apparent drawbacks > for GMPLS environment. Just a question, if we configure the refresh timer very > large, disable the refresh reduction and also maximize the time-out multiplier. > Will these help, or they make things worse? If you do all of these, then you can no longer detect or handle failures that don't cause carrier to be lost in the data-plane. It is possible to safely use a very large refresh timer, but only when refresh reduction and hello are in use on all peers. The message-id part of refresh reduction will allow for retransmission of lost packets, and hellos will detect soft failures. -- David From owner-mpls@UU.NET Fri Jul 19 11:48:50 2002 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 ESMTP id LAA12406 for ; Fri, 19 Jul 2002 11:48:50 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyex12737 for ; Fri, 19 Jul 2002 15:49:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyex12077; Fri, 19 Jul 2002 15:49:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyex00250 for mpls-outgoing; Fri, 19 Jul 2002 15:49:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyex00245 for ; Fri, 19 Jul 2002 15:49: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 QQmyex23733 for ; Fri, 19 Jul 2002 15:47:36 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyex10952 for ; Fri, 19 Jul 2002 15:47:36 GMT Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmyex10948 for ; Fri, 19 Jul 2002 15:47:35 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 19 Jul 2002 16:47:33 +0100 Message-ID: To: david.charlap@marconi.com, mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 19 Jul 2002 16:47:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk David Charlap wrote 19 July 2002 15:19 > Yangguang Xu wrote: > > > > Cause many folks raise the RSVP-TE soft state issue and its > apparent drawbacks > > for GMPLS environment. Just a question, if we configure the > refresh timer very > > large, disable the refresh reduction and also maximize the > time-out multiplier. > > Will these help, or they make things worse? > > If you do all of these, then you can no longer detect or > handle failures > that don't cause carrier to be lost in the data-plane. NH=> Can you elaborate what you mean by this please David, and against which particular user-plane framing structure you are referring to (ie MPLS or SDH or OTN) and whether you are referring to cases where the signalling is in-band or out-of-band wrt to the traffic's user-plane. Thanks, regards, Neil > > It is possible to safely use a very large refresh timer, but > only when > refresh reduction and hello are in use on all peers. The message-id > part of refresh reduction will allow for retransmission of > lost packets, > and hellos will detect soft failures. > > -- David > > From owner-mpls@UU.NET Fri Jul 19 11:57:16 2002 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 ESMTP id LAA12588 for ; Fri, 19 Jul 2002 11:57:15 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyex14497 for ; Fri, 19 Jul 2002 15:58:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyex13810; Fri, 19 Jul 2002 15:57:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyex00627 for mpls-outgoing; Fri, 19 Jul 2002 15:57:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyex00620 for ; Fri, 19 Jul 2002 15:57: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 QQmyex09526 for ; Fri, 19 Jul 2002 15:55:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyex23184 for ; Fri, 19 Jul 2002 15:55:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyex23176 for ; Fri, 19 Jul 2002 15:55:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20852 for ; Fri, 19 Jul 2002 11:55:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA28764 for mpls@uu.net; Fri, 19 Jul 2002 11:55:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyex00500 for ; Fri, 19 Jul 2002 15:54: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 QQmyex07860 for ; Fri, 19 Jul 2002 15:54:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyex22411 for ; Fri, 19 Jul 2002 15:54:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyex22406 for ; Fri, 19 Jul 2002 15:54:06 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20770; Fri, 19 Jul 2002 11:54:06 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA25264; Fri, 19 Jul 2002 11:54:06 -0400 (EDT) Message-Id: <200207191554.LAA25264@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Yangguang Xu cc: MPLS wg , swallow@cisco.com Subject: Re: initiating a discussion on mpls singaling protocols In-reply-to: Your message of "Fri, 19 Jul 2002 09:35:30 EDT." <3D3815A2.DB62931E@lucent.com> Date: Fri, 19 Jul 2002 11:54:05 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Yangguang - > Cause many folks raise the RSVP-TE soft state issue and its apparent drawbacks > for GMPLS environment. Just a question, if we configure the refresh timer very > large, disable the refresh reduction and also maximize the time-out multiplier. > Will these help, or they make things worse? So called hard-state also depends on refreshes. LDP messages depend on the TCP connection staying up to maintain their validity. The TCP connect sends keepalives if there is no other traffic. In effect, a single message (keepalive) refreshes all of the connections. Summary refresh is a mechanism to allow a single message to refresh many connections - you can fit about 300 in an MTU of 1500. So you want to *enable* refresh reduction rather than disable it. The question of refresh timer length is tied to the frequency at which you want to send the refresh messages. The refresh reduction also gives you reliable delivery. So if you set the timers long, you can reliably deliver a tear message if you need to remove the state. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jul 19 12:09:03 2002 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 ESMTP id MAA12805 for ; Fri, 19 Jul 2002 12:09:02 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyey04218 for ; Fri, 19 Jul 2002 16:09:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyey03247; Fri, 19 Jul 2002 16:09:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyey22352 for mpls-outgoing; Fri, 19 Jul 2002 16:09:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyey22314 for ; Fri, 19 Jul 2002 16:08:55 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 QQmyey01927 for ; Fri, 19 Jul 2002 16:07:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyey23266 for ; Fri, 19 Jul 2002 16:07:16 GMT Received: from crufty.research.bell-labs.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns2.research.bell-labs.com [204.178.16.49]) id QQmyey23262 for ; Fri, 19 Jul 2002 16:07:16 GMT Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6JG7FCT045456 for ; Fri, 19 Jul 2002 12:07:16 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6JG79k38968 for ; Fri, 19 Jul 2002 12:07:09 -0400 (EDT) Received: from fanghpcho (fangh-pcho [135.180.160.148]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id MAA15791 for ; Fri, 19 Jul 2002 12:07:09 -0400 (EDT) From: "Fang Hao" To: Subject: Question on MIB info for LSP tunneling Date: Fri, 19 Jul 2002 12:07:08 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi- My question is the following: Suppose LSP L1 uses LSP L2 as a tunnel for some intermediate hop between LSR Ru and Rd, is the correlation between L1 and L2 stored somewhere in one of MIBs (MPLS-TE, MPLS-LSR, etc.) of Ru? In other words, if I know the mplsTunnelIndex of L1, can I somehow get to know the mplsTunnelIndex of L2? Could someone shed some light on this? Thanks. Fang From owner-mpls@UU.NET Fri Jul 19 12:37:45 2002 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 ESMTP id MAA13411 for ; Fri, 19 Jul 2002 12:37:44 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfa08981 for ; Fri, 19 Jul 2002 16:38:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyfa08221; Fri, 19 Jul 2002 16:38:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyfa29811 for mpls-outgoing; Fri, 19 Jul 2002 16:37:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyfa29806 for ; Fri, 19 Jul 2002 16:37:48 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 QQmyfa16711 for ; Fri, 19 Jul 2002 16:37:12 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfa07714 for ; Fri, 19 Jul 2002 16:37:12 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 QQmyfa07707 for ; Fri, 19 Jul 2002 16:37:12 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 MAA29964; Fri, 19 Jul 2002 12:37:09 -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 MAA12470; Fri, 19 Jul 2002 12:37:11 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W986SRK>; Fri, 19 Jul 2002 12:37:10 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55763267@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'neil.2.harrison@bt.com'" , "Charlap, David" , mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 19 Jul 2002 12:37:08 -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 Neil, -> David Charlap wrote 19 July 2002 15:19 -> > Yangguang Xu wrote: -> > > -> > > Cause many folks raise the RSVP-TE soft state issue and its -> > apparent drawbacks -> > > for GMPLS environment. Just a question, if we configure the -> > refresh timer very -> > > large, disable the refresh reduction and also maximize the -> > time-out multiplier. -> > > Will these help, or they make things worse? -> > -> > If you do all of these, then you can no longer detect or -> > handle failures -> > that don't cause carrier to be lost in the data-plane. -> NH=> Can you elaborate what you mean by this please David, -> and against which -> particular user-plane framing structure you are referring to -> (ie MPLS or SDH -> or OTN) and whether you are referring to cases where the -> signalling is -> in-band or out-of-band wrt to the traffic's user-plane. What David meant was "You can't make a protocol so *hard* by increasing timers and time-out values and achieve same dynamics of the *soft-state* protocol". There must be some trade-off between soft-state and hard-state. If soft-state has scaling problems then make it little hard by extensions (that is what RSVP-TE achieved when compared to classical RSVP). If you make the protocol too hard then how can you make the protocol so dynamic to detect failures for better manageability. I think, Loa confused people by mentioning GMPLS :) (unnecessarily) Just consider RSVP-TE applicability as such in core network independent of what transport you are using (as a general case). Did you see any problem with RSVP-TE in different transport networks (when compared to CR-LDP)? I don't think so! -- Venkata. From owner-mpls@UU.NET Fri Jul 19 13:29:54 2002 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 ESMTP id NAA14248 for ; Fri, 19 Jul 2002 13:29:53 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfe08986 for ; Fri, 19 Jul 2002 17:30:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyfe08083; Fri, 19 Jul 2002 17:30:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyfe26255 for mpls-outgoing; Fri, 19 Jul 2002 17:30:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyfe26248 for ; Fri, 19 Jul 2002 17:30: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 QQmyfd24768 for ; Fri, 19 Jul 2002 17:29:40 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfd07460 for ; Fri, 19 Jul 2002 17:29:40 GMT Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQmyfd07456 for ; Fri, 19 Jul 2002 17:29:39 GMT Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6JHTcW00638; Fri, 19 Jul 2002 13:29:38 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.38.228]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA13411; Fri, 19 Jul 2002 13:29:37 -0400 (EDT) Message-ID: <3D384C7A.A70D8431@lucent.com> Date: Fri, 19 Jul 2002 13:29:31 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <200207191554.LAA25264@bifocal.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George, This topic may belong to CCAMP, whatever... I agree with what you and Dave said. Indeed, I don't worry about the refresh part of the soft state too much. It's useful and can be done efficiently. Yet, no matter hard state or soft state, in optical network, a data plane connection should be torn down explicitly by user/operator. i.e. if the connection states in the control plane have errors, rather than sending PathErr/PathTear to tear down the data path, a trap or alarm should be raised to notify network management system. Instead of changing the protocol's default behavior, I was thinking about how to just manipulate configuration to meet this requirement. Now it seems to me that's not a good idea. Thanks, Yangguang George Swallow wrote: > > Yangguang - > > > Cause many folks raise the RSVP-TE soft state issue and its apparent drawbacks > > for GMPLS environment. Just a question, if we configure the refresh timer very > > large, disable the refresh reduction and also maximize the time-out multiplier. > > Will these help, or they make things worse? > > So called hard-state also depends on refreshes. LDP messages depend > on the TCP connection staying up to maintain their validity. The TCP > connect sends keepalives if there is no other traffic. In effect, a > single message (keepalive) refreshes all of the connections. > > Summary refresh is a mechanism to allow a single message to refresh > many connections - you can fit about 300 in an MTU of 1500. So you > want to *enable* refresh reduction rather than disable it. The > question of refresh timer length is tied to the frequency at which you > want to send the refresh messages. > > The refresh reduction also gives you reliable delivery. So if you set > the timers long, you can reliably deliver a tear message if you need > to remove the state. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jul 19 13:35:43 2002 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 ESMTP id NAA14356 for ; Fri, 19 Jul 2002 13:35:43 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfe07108 for ; Fri, 19 Jul 2002 17:36:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyfe06390; Fri, 19 Jul 2002 17:36:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyfe26628 for mpls-outgoing; Fri, 19 Jul 2002 17:36:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyfe26623 for ; Fri, 19 Jul 2002 17:35:52 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 QQmyfe09134 for ; Fri, 19 Jul 2002 17:34:23 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfe16652 for ; Fri, 19 Jul 2002 17:34:23 GMT Received: from mm02snlnto.sandia.gov by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mm02snlnto.sandia.gov [132.175.109.21]) id QQmyfe16629 for ; Fri, 19 Jul 2002 17:34:22 GMT Received: from 132.175.109.4 by mm02snlnto.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Fri, 19 Jul 2002 11:31:24 -0600 X-Server-Uuid: 95b8ca9b-fe4b-44f7-8977-a6cb2d3025ff Received: from ES01SNLNT.sandia.gov (es01snlnt.sandia.gov [134.253.130.4]) by mailgate2.sandia.gov (8.12.3/8.12.3) with ESMTP id g6JHYI2B026118; Fri, 19 Jul 2002 11:34:18 -0600 (MDT) Received: by ES01SNLNT.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Fri, 19 Jul 2002 11:34:19 -0600 Message-ID: <9A4B2157EFDBE546BECD68C62AC3B1C805DA26D8@es05snlnt> From: "Black, Stephen" To: "'Loa Andersson'" , "MPLS wg" Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 19 Jul 2002 11:34:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Filter-Version: 1.8 (sass2426) X-WSS-ID: 112693662013638-01-01 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 NAA14356 I feel this would be the best approach. Stephen Black ----------------------------- Sandia National Laboratories Networked Sys Surv & Assurance email: spblack@sandia.gov -----Original Message----- From: Loa Andersson [mailto:loa.andersson@utfors.se] Sent: Thursday, July 18, 2002 5:42 AM To: MPLS wg Cc: George Swallow; scott Giles; Wijnen, Bert (Bert) Subject: initiating a discussion on mpls singaling protocols All, at the mpls wg meeting at the 54th IETF in Yokohama the issue of having two functional similar (not to say overlapping) protocols addressing the same functional space, as rsvp-te and cr-ldp were brought up. The background is that when the signaling protocol for mpls traffic engineering and setting up explicit / constraint based routes were designed, there were two different approaches. One based on rsvp and the other on ldp. It was not at that time possible to resolve the differences between the two approaches and this protocol duplication as been reflected in creation of sometimes functional duplicate specifications. Since then both protocols has been progressed to proposed standard and implemented. However, as has been shown in the survey on signaling protocols for GMPLS the implementations of rsvp-te far out number the cr-ldp implementations. As there are issues with having two similar standards (potentially diverging), and it generates duplicate work in several ietf working groups, the question was asked whether we should make cr-ldp informational (which still make it available and possible to work with) and progress only rsvp-te on the standards track. At the meeting there were a wide spread support for this idea, but it was ruled that it was premature to call wg consensus on this at the meeting and that we wanted to take the discussion on the mpls mailing list. This mail is to initiate this discussion. Please keep the discussion on the mpls list, do not cross post other lists. A separate mail to the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this discussion. /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 Fri Jul 19 14:40:31 2002 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 ESMTP id OAA15565 for ; Fri, 19 Jul 2002 14:40:30 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfi21440 for ; Fri, 19 Jul 2002 18:41:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyfi20274; Fri, 19 Jul 2002 18:40:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyfi23875 for mpls-outgoing; Fri, 19 Jul 2002 18:40:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyfi23870 for ; Fri, 19 Jul 2002 18:40: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 QQmyfi24205 for ; Fri, 19 Jul 2002 18:38:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfi24586 for ; Fri, 19 Jul 2002 18:38:39 GMT Received: from fep04-mail.bloor.is.net.cable.rogers.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) id QQmyfi24581 for ; Fri, 19 Jul 2002 18:38:38 GMT Received: from [127.0.0.1] by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20020719183750.EZME360107.fep04-mail.bloor.is.net.cable.rogers.com@[127.0.0.1]>; Fri, 19 Jul 2002 14:37:50 -0400 From: Kshitij Kumar To: CC: Subject: Why isn't there an LSC in GMPLS? Date: Fri, 19 Jul 2002 14:37:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep04-mail.bloor.is.net.cable.rogers.com from [127.0.0.1] using ID at Fri, 19 Jul 2002 14:37:50 -0400 Message-Id: <20020719183750.EZME360107.fep04-mail.bloor.is.net.cable.rogers.com@[127.0.0.1]> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I am curious. Please humour my curiousity. There are PSCs, L2SCs, etc. in GMPLS. Take the case of p2p links, GigE for instance. A PSC (for instance an IP router capable of MPLS forwarding) needs to look at the MAC address, then look at the label and make a forwarding decision, changing the MAC SA/DA in the process. An L2SC (for instance an Ethernet switch capable of doing MPLS) checks the MAC destination and presumably make a forwarding decision based on either the MAC or the label. If it is a pure L2SC, I assume it makes the decision based on the label and should not change the MAC SA/DA. Why does an L2SC look at the L2 header? What's the relationship between the L2 header vs. Label for an L2SC? This is never explained in the GMPLS drafts. And, there is no "Label Switch Capable" (LSC) device that I know of, or is there? An LSC would be a device that would simply switch based on labels and labels only. It would have interfaces that would be P2P - for instance GE or FE p2p links, and would not spend cycles looking at the L2 header for making forwarding decisions. The LSC would be a "real" GMPLS device - one that is "Generalized" not just at the control plane, but also at the data plane. (Of course, one can't generalize the implementation, but you get my point). It's big advantage could be that it could be transparent to any L2 bridging or L3 routing - it would work purely based on MPLS tunnels. (Will need some routing for GMPLS signaling, but that's it). Has such a concept been discussed and if so, what happened? If not, why not? Thanks, Kshitij. -- My cure for procrastination: "I wasted time, and now doth time waste me." King Richard-II, Shakespeare. From owner-mpls@UU.NET Fri Jul 19 14:46:31 2002 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 ESMTP id OAA15713 for ; Fri, 19 Jul 2002 14:46:31 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfj00867 for ; Fri, 19 Jul 2002 18:47:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyfj29781; Fri, 19 Jul 2002 18:46:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyfj24746 for mpls-outgoing; Fri, 19 Jul 2002 18:46:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyfj24658 for ; Fri, 19 Jul 2002 18:45: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 QQmyfi28697 for ; Fri, 19 Jul 2002 18:44:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfi28423 for ; Fri, 19 Jul 2002 18:44:50 GMT Received: from dirty.research.bell-labs.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.research.bell-labs.com [204.178.16.6]) id QQmyfi28409 for ; Fri, 19 Jul 2002 18:44:49 GMT Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6JIhT6R071336; Fri, 19 Jul 2002 14:43:29 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6JIigk52267; Fri, 19 Jul 2002 14:44:43 -0400 (EDT) Received: from fanghpcho (fangh-pcho [135.180.160.148]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id OAA22194; Fri, 19 Jul 2002 14:44:42 -0400 (EDT) From: "Fang Hao" To: "Adrian Farrel" Cc: Subject: RE: Question on MIB info for LSP tunneling Date: Fri, 19 Jul 2002 14:44:42 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <002001c22f51$3b74c500$681810ac@movaz.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Adrian, Thanks for your reply. But I am still missing something - the tunnel creation part is fine, but when I need to access information about L2 (the LSP tunnel), I have a problem. What I would need is: given LSP L1 (i.e., knowing its mplsTunnelIndex), I need to find out which tunnel it is going through, how much bandwidth is left on this tunnel L2, what is the ingress/egress LSR id, etc. For those info I would probably need the mplsTunnelIndex for L2. If I am not misunderstanding the MIBs, this mplsTunnelIndex (of L2) does not appear in either interface table or out segment table. - any comments? Thanks, Fang -----Original Message----- From: Adrian Farrel [mailto:afarrel@movaz.com] Sent: Friday, July 19, 2002 2:22 PM To: Fang Hao Subject: Re: Question on MIB info for LSP tunneling Fang, A common approach top this is to install the tunnel as an interface so it shows in the interfaces MIB. The interface would also show in the TE MIB for the tunnel. The tunneled LSP can then be routed down the tunnel (i.e. out of the virtual interface). This would show up in the LSR MIB out segment. Cheers, Adrian ----- Original Message ----- From: "Fang Hao" To: Sent: Friday, July 19, 2002 12:07 PM Subject: Question on MIB info for LSP tunneling > Hi- > > My question is the following: > Suppose LSP L1 uses LSP L2 as a tunnel for some intermediate > hop between LSR Ru and Rd, is the correlation between L1 and > L2 stored somewhere in one of MIBs (MPLS-TE, MPLS-LSR, etc.) > of Ru? In other words, if I know the mplsTunnelIndex of L1, can I > somehow get to know the mplsTunnelIndex of L2? > > Could someone shed some light on this? Thanks. > > Fang From owner-mpls@UU.NET Fri Jul 19 15:00:12 2002 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 ESMTP id PAA15910 for ; Fri, 19 Jul 2002 15:00:11 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfk16502 for ; Fri, 19 Jul 2002 19:01:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyfk15102; Fri, 19 Jul 2002 19:00:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyfk27850 for mpls-outgoing; Fri, 19 Jul 2002 19:00:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyfj27757 for ; Fri, 19 Jul 2002 18: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 QQmyfj23278 for ; Fri, 19 Jul 2002 18:59:41 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyfj06367 for ; Fri, 19 Jul 2002 18:59:41 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 QQmyfj06363 for ; Fri, 19 Jul 2002 18:59: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 OAA09203 for ; Fri, 19 Jul 2002 14:59:38 -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 OAA18710 for ; Fri, 19 Jul 2002 14:59:39 -0400 (EDT) Message-ID: <3D3861A6.2030800@marconi.com> Date: Fri, 19 Jul 2002 14:59:50 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a) Gecko/20020613 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit neil.2.harrison@bt.com wrote: > David Charlap wrote 19 July 2002 15:19 >> >> If you do all of these, then you can no longer detect or >> handle failures that don't cause carrier to be lost in the data-plane. > > Can you elaborate what you mean by this please David, and against which > particular user-plane framing structure you are referring to (ie MPLS or SDH > or OTN) and whether you are referring to cases where the signalling is > in-band or out-of-band wrt to the traffic's user-plane. Simple. Layer-1 protection features will continue to work. If someone pulls a fiber, carrier will be lost and the interface will go down, and RSVP will handle that. But soft-state also detects software failures. Suppose the RSVP protocol crashes on a box. The interface remains up. Packets continue to arrive, but they aren't processed. Classical RSVP will detect the loss of refresh messages and will start deleting state as it times out. If you increase the refresh interval or multiple, then that amount of time will be much greater. With a default interval of 30 seconds and a default multiple of 3, state will time out in 1.5 minutes. This is already too slow for many situations. The other thing that soft-state gets is reliable delivery. If a Path message is sent and lost, it will be retransmitted at the next refresh interval, and the LSP should continue coming up at that point. If the interval is greatly increased, it will take a long time before this retransmission happens. The Hello part of RSVP-TE solves the first problem. When Hellos are used, a failure will be rapidly detected regardless of the refresh interval. The Refresh Reduction RFC solves the second problem. The Message ID part of that RFC will cause trigger messages to be rapidly retransmitted until they are acknowledged (according to an exponential backoff algorithm.) Which means it is safe to use a large refresh interval when both Hellos and Refresh Reduction are in use. But not if they aren't. -- David From owner-mpls@UU.NET Sat Jul 20 01:17:32 2002 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 ESMTP id BAA25789 for ; Sat, 20 Jul 2002 01:17:32 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmygz09809 for ; Sat, 20 Jul 2002 05:18:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmygz08889; Sat, 20 Jul 2002 05:18:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmygz17373 for mpls-outgoing; Sat, 20 Jul 2002 05:17:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmygz17366 for ; Sat, 20 Jul 2002 05:17:26 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 QQmygy15028 for ; Sat, 20 Jul 2002 05:14:41 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmygy07460 for ; Sat, 20 Jul 2002 05:14:41 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmygy07456 for ; Sat, 20 Jul 2002 05:14:40 GMT Received: from utfors.se ([195.58.105.100]) by blooper.utfors.se (Utfors AB) with ESMTP id g6K5EN5F027487; Sat, 20 Jul 2002 07:14:24 +0200 (MEST) Message-ID: <3D38F1AF.8030602@utfors.se> Date: Sat, 20 Jul 2002 07:14:23 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Zafar Ali CC: MPLS wg , RajivPapneja Subject: Re: initiating a discussion on mpls singaling protocols References: <4.3.2.7.2.20020719021207.0492ee78@sword.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Zafar and Rajiv, thanks for comments. A quick word on process, at the meeting in Yokohama it was very clear that we wanted to take a discussion on the mpls mailing list. Talking as a wg chair I think it is pre-mature to try to call consensus just yet, wg chairs will do that when we have the picture, and hopefully it won't drag out to far. Nor did we give the (us) Service Provider any special role in this (apart from what we always have), however you are right and I would like to join you in encouraging SP's to step up and state their mind. /Loa Zafar Ali wrote: > I favor this notion; BTW I already saw that the majority is in favor of > this proposal. > > Thanks > > Regards... Zafar RajivPapneja wrote: > > The answer to this question is "yes" (as we have seen so far in the > "discussion" thread) and everyone of us know that based on the actual > implementations/deployments. But, I think SPs should step in to make > this call because eventually they are the ultimate users for the MPLS-TE > protocols. > > Thanks, > -Rajiv > > At 01:42 PM 7/18/2002 +0200, Loa Andersson wrote: > >> All, >> >> at the mpls wg meeting at the 54th IETF in Yokohama the issue of having >> two functional similar (not to say overlapping) protocols addressing >> the same functional space, as rsvp-te and cr-ldp were brought up. >> >> The background is that when the signaling protocol for mpls traffic >> engineering and setting up explicit / constraint based routes were >> designed, there were two different approaches. One based on rsvp and >> the other on ldp. It was not at that time possible to resolve the >> differences between the two approaches and this protocol duplication >> as been reflected in creation of sometimes functional duplicate >> specifications. >> >> Since then both protocols has been progressed to proposed standard >> and implemented. >> >> However, as has been shown in the survey on signaling protocols for >> GMPLS the implementations of rsvp-te far out number the cr-ldp >> implementations. As there are issues with having two similar standards >> (potentially diverging), and it generates duplicate work in several >> ietf working groups, the question was asked whether we should make >> cr-ldp informational (which still make it available and possible to >> work with) and progress only rsvp-te on the standards track. >> >> At the meeting there were a wide spread support for this idea, but >> it was ruled that it was premature to call wg consensus on this at the >> meeting and that we wanted to take the discussion on the mpls mailing >> list. >> >> This mail is to initiate this discussion. Please keep the discussion >> on the mpls list, do not cross post other lists. A separate mail to >> the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this >> discussion. >> >> /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 >> >> -- 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 Sat Jul 20 04:51:05 2002 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 ESMTP id EAA07281 for ; Sat, 20 Jul 2002 04:51:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyhn01009 for ; Sat, 20 Jul 2002 08:52:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyhn29775; Sat, 20 Jul 2002 08:51:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyhn09220 for mpls-outgoing; Sat, 20 Jul 2002 08:50:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyhn09215 for ; Sat, 20 Jul 2002 08:50: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 QQmyhn26629 for ; Sat, 20 Jul 2002 08:50:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyhn29142 for ; Sat, 20 Jul 2002 08:50:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyhn29106 for ; Sat, 20 Jul 2002 08:50:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id EAA12871 for ; Sat, 20 Jul 2002 04:50:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA11858 for mpls@uu.net; Sat, 20 Jul 2002 04:50:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyhn09150 for ; Sat, 20 Jul 2002 08:49: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 QQmyhn25352 for ; Sat, 20 Jul 2002 08:48:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyhn28197 for ; Sat, 20 Jul 2002 08:48:11 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQmyhn28192 for ; Sat, 20 Jul 2002 08:48:10 GMT Received: from FLEFAUCH-W2K.cisco.com (ams-clip-vpn-dhcp66.cisco.com [10.50.0.65]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA06573; Sat, 20 Jul 2002 10:48:00 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020720173743.01dd4b20@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 20 Jul 2002 17:45:47 +0900 To: Vinay Vernekar From: Francois Le Faucheur Subject: Re: initiating a discussion on mpls singaling protocols Cc: MPLS wg In-Reply-To: <3D37F4A7.6C7BECC9@wipro.com> References: <3D37068B.9020601@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Vinay, At 16:44 19/07/2002 +0530, Vinay Vernekar wrote: >I don't agree with the proposal of making CR-LDP as informational and >RSVP-TE as > >the standard. The current deployments may not be indicative of CR-LDP not >being >a standard MPLS protocol. RSVP-TE being an extension to existing RSVP protocol >addresses the IntServ model of resource reservation, whereas CR-LDP which is >extension to LDP for QoS signalling should be flexible enough to address >IntServ > >and Diffserv over MPLS models. Such a signalling protocol is a need for Next >Generation Networks. You need to read RFC3270 "Support of Diff-Serv over MPLS". You should then realise that Diff-Serv is supported in the exact same manner with both RSVP-TE and CR-LDP. I do not see any benefit of one protocol over the other as far as Diff-Serv support is concerned. Cheers Francois >Vinay >Bora Akyol wrote: > > > We went through these same discussions in 1998. It may be argued that RSVP > > has some scaling problems but in real deployments, none of these > > materialized. > > So, I think the market has spoken already. > > > > I support making CR-LDP informational and RSVP-TE standard. > > > > Bora > > > > Ron Bonica wrote: > > > > >>3. The scalability issues of rsvp is a known fact today (soft state=20 > > >>maintenance, refreshment, error handling etc)...because of which the > > >>plain rsvp itself never took off in a big way in internet. > > >> > > >> > > > > > >Many operators have deployed RSVP-TE. Are you aware of any who have > deployed > > >it and run into scaling problems? > > > > > > Ron > > > > > > > > > > > > From owner-mpls@UU.NET Sat Jul 20 06:56:55 2002 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 ESMTP id GAA08495 for ; Sat, 20 Jul 2002 06:56:54 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyhv22078 for ; Sat, 20 Jul 2002 10:57:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyhv21375; Sat, 20 Jul 2002 10:57:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyhv02769 for mpls-outgoing; Sat, 20 Jul 2002 10:57:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyhv02762 for ; Sat, 20 Jul 2002 10:56:59 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 QQmyhv02390 for ; Sat, 20 Jul 2002 10:55:18 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyhv15299 for ; Sat, 20 Jul 2002 10:55:17 GMT Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmyhv15293 for ; Sat, 20 Jul 2002 10:55:17 GMT Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Sat, 20 Jul 2002 11:55:23 +0100 Message-ID: To: david.charlap@marconi.com, mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Sat, 20 Jul 2002 11:55:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Thanks David....I understand where you are coming from, but there are 2 slants on this depending on whether we are discussing pkt-sw networks (MPLS) or L1 cct-sw networks (GMPLS). The technical (and for sure the commercial) requirements are different in each of these cases. My comments (please see below) are mainly targeted at the latter. regards, Neil David Charlap wrote 19 July 2002 20:00 > neil.2.harrison@bt.com wrote: > > David Charlap wrote 19 July 2002 15:19 > >> > >> If you do all of these, then you can no longer detect or > >> handle failures that don't cause carrier to be lost in the > data-plane. > > > > Can you elaborate what you mean by this please David, and > against which > > particular user-plane framing structure you are referring > to (ie MPLS or SDH > > or OTN) and whether you are referring to cases where the > signalling is > > in-band or out-of-band wrt to the traffic's user-plane. > > Simple. > > Layer-1 protection features will continue to work. If > someone pulls a > fiber, carrier will be lost and the interface will go down, and RSVP > will handle that. NH=> Please note in co cct-sw technologies there can be (and in some cases its forced) disjoint *data-plane networks* carrying the traffic and control (eg signalling) protocols.....and there could be a even a 3rd disjoint network carrying the network management protocols. [This can also be true for co pkt-sw networks, but of course it is not true in cnls networks.] In other words, the fault-management of each of these data-plane networks and the protocols that run on them is functionally/logically disjoint, and one should not assume reliance on a signalling (or routing) protocol to proxy for fault-management of the *traffic's data-plane*.....though of course one can use these as a tool to detect failures on the data-plane network that is carrying the signalling/routing say. However, one should use the failure indicators from the traffic's data-plane as means to inform the control-plane (signalling) to trigger actions such as protection-switching (of the traffic's data-plane) in the case of S-PVC-like trails. Conversely, failures of either (i) the data-plane network that carries the control-plane signalling/routing or (ii) the actual signalling/routing protocol themselves, should *not* take down the traffic data-plane trails. > > But soft-state also detects software failures. NH=> Which is fine for detecting failures of either (i) the data-plane network used to carry the control protocols, or (ii) the control-protocols themselves......though in the case you are giving here this would only apply to the signalling protocol component and not the routing protocol component (that needs, and has, its own fault-management). > > Suppose the RSVP protocol crashes on a box. The interface > remains up. NH=> Which interface? The one over which RSVP is running (ie the control network's data-plane) or the traffic's data-plane? Recall, I am mainly talking about L1 co cct-sw networks here and not L2 co pkt-sw networks....these can have very different requirements. > Packets continue to arrive, but they aren't processed. > > Classical RSVP will detect the loss of refresh messages and > will start > deleting state as it times out. NH=> I agree. RSVP was indeed designed for this environment, and also Rx-end driven not Tx-end driven applications. It was not designed to address the requirements of co cct-sw networks. > If you increase the refresh > interval or > multiple, then that amount of time will be much greater. > With a default > interval of 30 seconds and a default multiple of 3, state > will time out > in 1.5 minutes. This is already too slow for many situations. > > The other thing that soft-state gets is reliable delivery. If a Path > message is sent and lost, it will be retransmitted at the > next refresh > interval, and the LSP should continue coming up at that > point. If the > interval is greatly increased, it will take a long time before this > retransmission happens. NH=> Which is great for the original applications for which RSVP was designed. If however you start from a perspective of saying 'let's choose a best-of-breed signalling protocol for co pkt/cct-sw networks' then it seems hard to believe RSVP would even make the short-list.....pnni/Q.2931 might however, because it takes precisely this networking model as its basis. And the vast majority of the effort here is on exception handling in order to ensure reliability. > > The Hello part of RSVP-TE solves the first problem. When Hellos are > used, a failure will be rapidly detected regardless of the > refresh interval. NH=> This does not work if the signalling is running on a disjoint data-plane network from the traffic's data-plane. However, more generally its not good practice to use a control-plane protocol to proxy for the traffic's data-plane fault-management (and it won't cover all fault types anyway, eg LSP-Ping attempts to address this issue in the case of pkt-sw MPLS). > > The Refresh Reduction RFC solves the second problem. The Message ID > part of that RFC will cause trigger messages to be rapidly > retransmitted > until they are acknowledged (according to an exponential > backoff algorithm.) > > Which means it is safe to use a large refresh interval when > both Hellos > and Refresh Reduction are in use. But not if they aren't. regards, Neil From owner-mpls@UU.NET Sat Jul 20 07:13:01 2002 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 ESMTP id HAA08702 for ; Sat, 20 Jul 2002 07:13:00 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyhw26067 for ; Sat, 20 Jul 2002 11:13:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyhw25342; Sat, 20 Jul 2002 11:13:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyhw25702 for mpls-outgoing; Sat, 20 Jul 2002 11:13:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyhw25697 for ; Sat, 20 Jul 2002 11:13:04 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 QQmyhw27050 for ; Sat, 20 Jul 2002 11:13:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyhw08501 for ; Sat, 20 Jul 2002 11:13:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyhw08497 for ; Sat, 20 Jul 2002 11:13:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA16475 for ; Sat, 20 Jul 2002 07:13:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA26165 for mpls@uu.net; Sat, 20 Jul 2002 07:13:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyhw25669 for ; Sat, 20 Jul 2002 11:12: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 QQmyhw04336 for ; Sat, 20 Jul 2002 11:11:59 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyhw05344 for ; Sat, 20 Jul 2002 11:11:58 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 QQmyhw05337 for ; Sat, 20 Jul 2002 11:11:58 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6KBBpF20512 for ; Sat, 20 Jul 2002 07:11:52 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 20 Jul 2002 07:11:51 -0400 Message-ID: <710197BD5AF9D4119E4400508BCFA13604D0EF89@zcard04u.ca.nortel.com> From: "Osama Aboul-Magd" To: mpls@UU.NET Subject: RE: info: cr-ldp discussion to take place on the mpls list Date: Sat, 20 Jul 2002 07:11:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22FDE.3ED46ACE" 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_01C22FDE.3ED46ACE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable During the MPLS WG meeting in Yokohama the argument made that no = customer is asking for CR-LDP. The argument was basically made by a router vendor = and few carriers, and it was clear it is only applicable in the packet = space. In the context of GMPLS, there hasn't been much deployment of anything. = The survey that has been conducted only reflects vendor preference and is = not indicative of future carrier deployment of RSVP-TE or CR-LDP. In fact = the only carrier that is on the record supports neither. So the question is why is the rush? If a year from now we find out that RSVP-TE is deployed every where in the optical layer, then no one can = argue then. But it is premature to make a decision now. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Loa Andersson [mailto:loa.andersson@utfors.se]=20 Sent: Thursday, July 18, 2002 7:42 AM To: ccamp; pwe3@ietf.org; ppvpn@ppvpn.francetelecom.com Subject: info: cr-ldp discussion to take place on the mpls list All, this message is sent to the ccamp, ppvpn and pwe3 wg mailing lists as information, plese do not reply to the list(s). At the mpls wg meeting today the issue of having two functionally similar protocols for te and setting up expicit routes (rsvp-te and cr-ldp), a discussion were initiated and it was decided that it shall take place on the mpls wg mailing . As separate message will be sent to the mpls list with further background. /Loa --=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 ------_=_NextPart_001_01C22FDE.3ED46ACE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: info: cr-ldp discussion to take place on the mpls = list

During the MPLS WG meeting in Yokohama the argument = made that no customer is asking for CR-LDP. The argument was basically = made by a router vendor and few carriers, and it was clear it is only = applicable in the packet space.

In the context of GMPLS, there hasn't been much = deployment of anything. The survey that has been conducted only = reflects vendor preference and is not indicative of future carrier = deployment of RSVP-TE or CR-LDP. In fact the only carrier that is on = the record supports neither.

So the question is why is the rush? If a year from = now we find out that RSVP-TE is deployed every where in the optical = layer, then no one can argue then. But it is premature to make a = decision now.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Loa Andersson [mailto:loa.andersson@utfors.se]
Sent:   Thursday, July 18, 2002 7:42 = AM
To:     ccamp; pwe3@ietf.org; = ppvpn@ppvpn.francetelecom.com
Subject:        = info:  cr-ldp discussion to take place on the mpls list

All,

this message is sent to the ccamp, ppvpn and pwe3 wg = mailing lists
as information, plese do not reply to the = list(s).

At the mpls wg meeting today the issue of having two = functionally
similar protocols for te and setting up expicit = routes (rsvp-te and
cr-ldp), a discussion were initiated and it was = decided that it shall
take place on the mpls wg mailing = <mpls@uu-net>.

As separate message will be sent to the mpls list = with further
background.

/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           &nb= sp; www.utfors.se



------_=_NextPart_001_01C22FDE.3ED46ACE-- From owner-mpls@UU.NET Sat Jul 20 09:55:17 2002 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 ESMTP id JAA10364 for ; Sat, 20 Jul 2002 09:55:17 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyih21266 for ; Sat, 20 Jul 2002 13:56:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyih20393; Sat, 20 Jul 2002 13:55:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyih22120 for mpls-outgoing; Sat, 20 Jul 2002 13:55:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyih22115 for ; Sat, 20 Jul 2002 13:55:28 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 QQmyih15651 for ; Sat, 20 Jul 2002 13:54:43 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyih27119 for ; Sat, 20 Jul 2002 13:54:42 GMT Received: from mlsrv1.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQmyih27115 for ; Sat, 20 Jul 2002 13:54:42 GMT Received: from vaio ([10.6.100.218]) by mlsrv1.avici.com (8.11.0/8.11.0) with SMTP id g6KDsWn29579; Sat, 20 Jul 2002 09:54:32 -0400 (EDT) Message-ID: <002301c22ff6$092e8860$6401a8c0@isocore.com> From: "Rajiv Papneja" To: "Loa Andersson" , "Zafar Ali" Cc: "MPLS wg" References: <4.3.2.7.2.20020719021207.0492ee78@sword.cisco.com> <3D38F1AF.8030602@utfors.se> Subject: Re: initiating a discussion on mpls singaling protocols Date: Sat, 20 Jul 2002 10:02:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Thanks Loa for recognizing my point. I hope we can have consensus with SPs input. -Rajiv ----- Original Message ----- From: "Loa Andersson" To: "Zafar Ali" Cc: "MPLS wg" ; "RajivPapneja" Sent: Saturday, July 20, 2002 1:14 AM Subject: Re: initiating a discussion on mpls singaling protocols > Zafar and Rajiv, > > thanks for comments. A quick word on process, at the meeting in > Yokohama it was very clear that we wanted to take a discussion on > the mpls mailing list. > Talking as a wg chair I think it is pre-mature to try to call consensus > just yet, wg chairs will do that when we have the picture, and hopefully > it won't drag out to far. > Nor did we give the (us) Service Provider any special role in this > (apart from what we always have), however you are right and I would like > to join you in encouraging SP's to step up and state their mind. > > /Loa > > > > Zafar Ali wrote: > > > I favor this notion; BTW I already saw that the majority is in favor of > > this proposal. > > > > Thanks > > > > Regards... Zafar > > > RajivPapneja wrote: > > > > > The answer to this question is "yes" (as we have seen so far in the > > "discussion" thread) and everyone of us know that based on the actual > > implementations/deployments. But, I think SPs should step in to make > > this call because eventually they are the ultimate users for the MPLS-TE > > protocols. > > > > Thanks, > > -Rajiv > > > > > > > At 01:42 PM 7/18/2002 +0200, Loa Andersson wrote: > > > >> All, > >> > >> at the mpls wg meeting at the 54th IETF in Yokohama the issue of having > >> two functional similar (not to say overlapping) protocols addressing > >> the same functional space, as rsvp-te and cr-ldp were brought up. > >> > >> The background is that when the signaling protocol for mpls traffic > >> engineering and setting up explicit / constraint based routes were > >> designed, there were two different approaches. One based on rsvp and > >> the other on ldp. It was not at that time possible to resolve the > >> differences between the two approaches and this protocol duplication > >> as been reflected in creation of sometimes functional duplicate > >> specifications. > >> > >> Since then both protocols has been progressed to proposed standard > >> and implemented. > >> > >> However, as has been shown in the survey on signaling protocols for > >> GMPLS the implementations of rsvp-te far out number the cr-ldp > >> implementations. As there are issues with having two similar standards > >> (potentially diverging), and it generates duplicate work in several > >> ietf working groups, the question was asked whether we should make > >> cr-ldp informational (which still make it available and possible to > >> work with) and progress only rsvp-te on the standards track. > >> > >> At the meeting there were a wide spread support for this idea, but > >> it was ruled that it was premature to call wg consensus on this at the > >> meeting and that we wanted to take the discussion on the mpls mailing > >> list. > >> > >> This mail is to initiate this discussion. Please keep the discussion > >> on the mpls list, do not cross post other lists. A separate mail to > >> the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this > >> discussion. > >> > >> /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 > >> > >> > > > -- > 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 Sat Jul 20 11:11:46 2002 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 ESMTP id LAA11366 for ; Sat, 20 Jul 2002 11:11:45 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyim23278 for ; Sat, 20 Jul 2002 15:12:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyim22441; Sat, 20 Jul 2002 15:12:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyim11814 for mpls-outgoing; Sat, 20 Jul 2002 15:12:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyim11807 for ; Sat, 20 Jul 2002 15:11: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 QQmyim18458 for ; Sat, 20 Jul 2002 15:10:36 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyim21950 for ; Sat, 20 Jul 2002 15:10:36 GMT Received: from hoemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQmyim21946 for ; Sat, 20 Jul 2002 15:10:35 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6KFAYe01453 for ; Sat, 20 Jul 2002 11:10:34 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <3GTHAJRT>; Sat, 20 Jul 2002 17:10:33 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Dimitry Haskin , MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Sat, 20 Jul 2002 17:10:31 +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 Deployment reports are certainly welcome as input to the process ove trying to answer this question. If you want anonymity, I suggest you send them to Loa privately. Thanks, Bert > -----Original Message----- > From: Dimitry Haskin [mailto:dhaskin@axiowave.com] > Sent: donderdag 18 juli 2002 16:19 > To: MPLS wg > Subject: RE: initiating a discussion on mpls singaling protocols > > > > However, as has been shown in the survey on signaling protocols for > > GMPLS the implementations of rsvp-te far out number the cr-ldp > > implementations. > > At this point, a deployment survey would be even more indicative. > > Dimitry > From owner-mpls@UU.NET Sat Jul 20 16:59:34 2002 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 ESMTP id QAA15253 for ; Sat, 20 Jul 2002 16:59:34 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyjk09717 for ; Sat, 20 Jul 2002 21:00:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyjk08901; Sat, 20 Jul 2002 21:00:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyjj27949 for mpls-outgoing; Sat, 20 Jul 2002 20:59:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyjj27944 for ; Sat, 20 Jul 2002 20:59:44 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 QQmyjj09175 for ; Sat, 20 Jul 2002 20:58:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyjj07954 for ; Sat, 20 Jul 2002 20:58:36 GMT Received: from squirehome.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu57-89-018.nc.rr.com [66.57.89.18]) id QQmyjj07950 for ; Sat, 20 Jul 2002 20:58:36 GMT Received: from acm.org (IDENT:msquire@squid.squirehome.org [192.168.168.2]) by squirehome.org (8.11.6/8.11.0) with ESMTP id g6KKwFP01997; Sat, 20 Jul 2002 16:58:16 -0400 Message-ID: <3D39CEE7.3433DAFD@acm.org> Date: Sat, 20 Jul 2002 16:58:15 -0400 From: Matt Squire Reply-To: mattsquire@acm.org X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Loa Andersson CC: MPLS wg , George Swallow , scott Giles , "Wijnen, Bert (Bert)" Subject: Re: initiating a discussion on mpls singaling protocols References: <3D36A98A.7070103@utfors.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Count me as a big "yes" for the idea. > > However, as has been shown in the survey on signaling protocols for > GMPLS the implementations of rsvp-te far out number the cr-ldp > implementations. As there are issues with having two similar standards > (potentially diverging), and it generates duplicate work in several > ietf working groups, the question was asked whether we should make > cr-ldp informational (which still make it available and possible to > work with) and progress only rsvp-te on the standards track. > > At the meeting there were a wide spread support for this idea, but > it was ruled that it was premature to call wg consensus on this at the > meeting and that we wanted to take the discussion on the mpls mailing > list. > > This mail is to initiate this discussion. Please keep the discussion > on the mpls list, do not cross post other lists. A separate mail to > the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this > discussion. > > /Loa > From owner-mpls@UU.NET Sun Jul 21 14:56:22 2002 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 ESMTP id OAA09052 for ; Sun, 21 Jul 2002 14:56:21 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmymt29026 for ; Sun, 21 Jul 2002 18:57:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmymt27944; Sun, 21 Jul 2002 18:56:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmymt10474 for mpls-outgoing; Sun, 21 Jul 2002 18:56:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmymt10448 for ; Sun, 21 Jul 2002 18:56: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 QQmymt17290 for ; Sun, 21 Jul 2002 18:54:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmymt13867 for ; Sun, 21 Jul 2002 18:54:07 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmymt13843 for ; Sun, 21 Jul 2002 18:54:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11565 for ; Sun, 21 Jul 2002 14:54:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA29168 for mpls@uu.net; Sun, 21 Jul 2002 14:54:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmymt10301 for ; Sun, 21 Jul 2002 18:53: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 QQmymt02592; Sun, 21 Jul 2002 18:53:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmymt13533; Sun, 21 Jul 2002 18:53:06 GMT Received: from crufty.research.bell-labs.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns2.research.bell-labs.com [204.178.16.49]) id QQmymt13520; Sun, 21 Jul 2002 18:53:01 GMT Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6LIqWCT061012; Sun, 21 Jul 2002 14:52:32 -0400 (EDT) Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6LIqPk50405; Sun, 21 Jul 2002 14:52:26 -0400 (EDT) Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by jessie.research.bell-labs.com (8.12.2/8.12.2) with SMTP id g6LIqOoF004498; Sun, 21 Jul 2002 14:52:24 -0400 (EDT) Message-Id: <200207211852.g6LIqOoF004498@jessie.research.bell-labs.com> Date: Sun, 21 Jul 2002 14:52:24 -0400 (EDT) From: "W. S. Cleveland" Reply-To: "W. S. Cleveland" Subject: Re: Where can I find statistics data on traffic over current high speed internet? To: te-wg@UU.NET, jshen@cad.zju.edu.cn Cc: mpls@UU.NET, ippm@advanced.org, irtf-rr@puck.nether.net, end2end-interest@postel.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8cbG27/jfAv/k75zEbHTew== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk The old but still relevant query below made its way to me. Conventional wisdom until recently had it that the LRD of Internet traffic occurred from the edges to the core. The conventional is false in the sense that is relevant for network engineering of the core. We showed that packet inter-arrival times tend from LRD toward Poisson and the packet size process tends from LRD toward independent as the traffic load increases, both due to increased statistical multiplexing. There is always an LRD component in the inter-arrivals and the sizes, but the contribution of the component to the variability of each time process gets less and less. Packet and byte counts in fixed intervals maintain their LRD but their standard deviation relative to the mean decreases toward zero, so the LRD becomes irrelevant because the long excursions due to LRD above and below the mean traffic rate are so small that the excursions are irrelevant for traffic engineering. One might immediately question this on the basis that there is a contradiction. The counts maintain their LRD but the sizes and inter-arrivals do not, even though the former two come from the latter two. The explanation is this. As the traffic load increases, the smaller and smaller LRD components in the sizes and inter-arrivals are magnified more and more in forming the counts because going from sizes and inter-arrivals to counts is an aggregation process across traffic sources, which gets greater as the load increases, and magnifies more. Should we care? The answer is yes. The queueing on links tends to that of Poisson and independent as the load increases. We are in the process of a careful study of queueing and of the utilization (as a function of load) that a link can bear and drop only a very small fraction of packets. We have found so far that for very high traffic rates, say 200 mbps 3-minute average and above (from OC48 traffic measurement), the queueing results (1) for the real data, (2) for our FSD models which fit the real data very well, and (3) for a Poisson/independent model, give identical results for practical purposes. Utilizations can be quite high, around 90%, going higher or lower depending on the strictness of the QoS criterion. The traffic results can be found at stat.bell-labs.com/InternetTraffic/webpapers.html. The latest paper (to be published in a Springer book) is the most readable on this because we are getting better at explaining results. The queueing/utilization results will be available in a few weeks. William S. Cleveland http://www.stat.bell-labs.com/wsc Bell Labs, 600 Mountain Av., Murray Hill, NJ 07974 908-582-6861 (phone) 908-582-3340 (fax) > From: "Jing Shen" > To: > Cc: , , , > > Date: Sun, 17 Mar 2002 15:26:05 +0800 > Subject: [ippm] Where can I find statistics data on traffic over current high > speed internet? > Precedence: bulk > Hi, > I've read some books and papers on network traffic characteristics . But, all > of them seem to be measured before 1999 when > internet is not such a high speed one. ( As I know, from 1996 to 2001 > ChinaNet has involved from 45Mbps to 10Gbps, the subdomain of > it involved from 2Mbps to 2.Gbps , more and more people start to enjoy stream > media, multiuser game > other than only static web pages) . > I'm sure the self-similar character of internet traffic mainteins with the > network speed improvement, > But the distribution of these traffic between different protocols, the size > distribution must have changed > much. ( It seems to no measurement done with ChinaNet) > So, I want to know where I can find statistics data on current high speed > internet? > Thank you very much. > Jing Shen > State Key Lab of CAD&CG > ZheJiang University > P.R.China From owner-mpls@UU.NET Sun Jul 21 19:10:13 2002 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 ESMTP id TAA11748 for ; Sun, 21 Jul 2002 19:10:13 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmynk07978 for ; Sun, 21 Jul 2002 23:11:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmynk07048; Sun, 21 Jul 2002 23:10:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmynk18718 for mpls-outgoing; Sun, 21 Jul 2002 23:10:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmynk18665 for ; Sun, 21 Jul 2002 23:10: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 QQmynk18448 for ; Sun, 21 Jul 2002 23:08:37 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmynk13582 for ; Sun, 21 Jul 2002 23:08:37 GMT Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQmynk13570 for ; Sun, 21 Jul 2002 23:08:37 GMT Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 21 Jul 2002 19:08:35 -0400 Message-ID: <005501c2310b$8ea9f720$9b13588a@movaz.com> From: "Adrian Farrel" To: "Fang Hao" Cc: "'mpls@uu.net'" References: Subject: Re: Question on MIB info for LSP tunneling Date: Sun, 21 Jul 2002 11:38:08 -0400 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 X-OriginalArrivalTime: 21 Jul 2002 23:08:36.0092 (UTC) FILETIME=[8AAEFBC0:01C2310B] Sender: owner-mpls@UU.NET Precedence: bulk Hi Fang, L1 is tunneled through L2. L2 is installed in the TE MIB with an ifindex using mplsTunnelIsIf and mplsTunnelIfIndex. This means that it can be found within the implementation as an interface and available bandwidth can be examined just as though it was a physical interface. L1 shows in the LSR MIB with an outsegment that contains mplsOutSegmentIfIndex. This is the outgoing interface for L1 and is not the physical interface - it is the interface index of L2. So, from L1 you can get to L2. Adrian ----- Original Message ----- From: "Fang Hao" To: "Adrian Farrel" Cc: Sent: Friday, July 19, 2002 2:44 PM Subject: RE: Question on MIB info for LSP tunneling > Adrian, > > Thanks for your reply. But I am still missing something - > the tunnel creation part is fine, but when I need to > access information about L2 (the LSP tunnel), I have a problem. > What I would need is: given LSP L1 (i.e., knowing its > mplsTunnelIndex), I need to find out which tunnel it is > going through, how much bandwidth is left on this tunnel L2, > what is the ingress/egress LSR id, etc. For those info > I would probably need the mplsTunnelIndex for L2. > > If I am not misunderstanding the MIBs, this mplsTunnelIndex > (of L2) does not appear in either interface table or > out segment table. - any comments? > > Thanks, > Fang From owner-mpls@UU.NET Mon Jul 22 00:49:07 2002 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 ESMTP id AAA16667 for ; Mon, 22 Jul 2002 00:49:07 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyoh08506 for ; Mon, 22 Jul 2002 04:50:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyoh07623; Mon, 22 Jul 2002 04:49:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyoh05897 for mpls-outgoing; Mon, 22 Jul 2002 04:49:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyoh05892 for ; Mon, 22 Jul 2002 04:49: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 QQmyoh07341 for ; Mon, 22 Jul 2002 04:49:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyoh19430 for ; Mon, 22 Jul 2002 04:49:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyoh19423 for ; Mon, 22 Jul 2002 04:49:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA27762 for ; Mon, 22 Jul 2002 00:49:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA27535 for mpls@uu.net; Mon, 22 Jul 2002 00:49:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyoh05796 for ; Mon, 22 Jul 2002 04:48: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 QQmyoh04622 for ; Mon, 22 Jul 2002 04:47:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyoh18928 for ; Mon, 22 Jul 2002 04:47:35 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmyoh18919 for ; Mon, 22 Jul 2002 04:47:35 GMT Received: from ZALI-W2K.cisco.com (che-vpn1-27.cisco.com [10.86.240.27]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id AAA17876; Mon, 22 Jul 2002 00:47:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20020722004608.01fec890@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Jul 2002 00:47:27 -0400 To: Loa Andersson From: Zafar Ali Subject: Re: initiating a discussion on mpls singaling protocols Cc: MPLS wg , RajivPapneja In-Reply-To: <3D38F1AF.8030602@utfors.se> References: <4.3.2.7.2.20020719021207.0492ee78@sword.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8033411==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_8033411==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Loa, Thanks for the follow-up. I completely agree with you. Regards... Zafar At 07:14 AM 7/20/2002 +0200, Loa Andersson wrote: >Zafar and Rajiv, > >thanks for comments. A quick word on process, at the meeting in >Yokohama it was very clear that we wanted to take a discussion on >the mpls mailing list. >Talking as a wg chair I think it is pre-mature to try to call consensus >just yet, wg chairs will do that when we have the picture, and hopefully >it won't drag out to far. >Nor did we give the (us) Service Provider any special role in this >(apart from what we always have), however you are right and I would like >to join you in encouraging SP's to step up and state their mind. > >/Loa > > > >Zafar Ali wrote: > >>I favor this notion; BTW I already saw that the majority is in favor of=20 >>this proposal. >>Thanks >>Regards... Zafar > > >RajivPapneja wrote: > > > > > The answer to this question is "yes" (as we have seen so far in the > > "discussion" thread) and everyone of us know that based on the actual > > implementations/deployments. But, I think SPs should step in to make > > this call because eventually they are the ultimate users for the MPLS-TE > > protocols. > > > > Thanks, > > -Rajiv > > > >>At 01:42 PM 7/18/2002 +0200, Loa Andersson wrote: >> >>>All, >>> >>>at the mpls wg meeting at the 54th IETF in Yokohama the issue of having >>>two functional similar (not to say overlapping) protocols addressing >>>the same functional space, as rsvp-te and cr-ldp were brought up. >>> >>>The background is that when the signaling protocol for mpls traffic >>>engineering and setting up explicit / constraint based routes were >>>designed, there were two different approaches. One based on rsvp and >>>the other on ldp. It was not at that time possible to resolve the >>>differences between the two approaches and this protocol duplication >>>as been reflected in creation of sometimes functional duplicate >>>specifications. >>> >>>Since then both protocols has been progressed to proposed standard >>>and implemented. >>> >>>However, as has been shown in the survey on signaling protocols for >>>GMPLS the implementations of rsvp-te far out number the cr-ldp >>>implementations. As there are issues with having two similar standards >>>(potentially diverging), and it generates duplicate work in several >>>ietf working groups, the question was asked whether we should make >>>cr-ldp informational (which still make it available and possible to >>>work with) and progress only rsvp-te on the standards track. >>> >>>At the meeting there were a wide spread support for this idea, but >>>it was ruled that it was premature to call wg consensus on this at the >>>meeting and that we wanted to take the discussion on the mpls mailing >>>list. >>> >>>This mail is to initiate this discussion. Please keep the discussion >>>on the mpls list, do not cross post other lists. A separate mail to >>>the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this >>>discussion. >>> >>>/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 >>> > > >-- > 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 > > --=====================_8033411==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Loa,

Thanks for the follow-up. I completely agree with you.

Regards... Zafar

At 07:14 AM 7/20/2002 +0200, Loa Andersson wrote:
Zafar and Rajiv,

thanks for comments. A quick word on process, at the meeting in
Yokohama it was very clear that we wanted to take a discussion on
the mpls mailing list.
Talking as a wg chair I think it is pre-mature to try to call consensus
just yet, wg chairs will do that when we have the picture, and hopefully
it won't drag out to far.
Nor did we give the (us) Service Provider any special role in this
(apart from what we always have), however you are right and I would like
to join you in encouraging SP's to step up and state their mind.

/Loa



Zafar Ali wrote:

I favor this notion; BTW I already saw that the majority is in favor of this proposal.
Thanks
Regards... Zafar


RajivPapneja wrote:

>
> The answer to this question is "yes" (as we have seen so far in the
> "discussion" thread) and everyone of us know that based on the actual
> implementations/deployments.  But, I think SPs should step in to make
> this call because eventually they are the ultimate users for the MPLS-TE
> protocols.
>
>  Thanks,
>   -Rajiv



At 01:42 PM 7/18/2002 +0200, Loa Andersson wrote:

All,

at the mpls wg meeting at the 54th IETF in Yokohama the issue of having
two functional similar (not to say overlapping) protocols=20 addressing
the same functional space, as rsvp-te and cr-ldp were brought up.

The background is that when the signaling protocol for mpls traffic
engineering and setting up explicit / constraint based routes were
designed, there were two different approaches. One  based on rsvp and
the other on ldp. It was not at that time possible to resolve the
differences between the two approaches and this protocol=20 duplication
as been reflected in creation of sometimes functional duplicate
specifications.

Since then both protocols has been progressed to proposed standard
and implemented.

However, as has been shown in the survey on signaling protocols for
GMPLS the implementations of rsvp-te far out number the cr-ldp
implementations. As there are issues with having two similar standards
(potentially diverging), and it generates duplicate work in several
ietf working groups, the question was asked whether we should make
cr-ldp informational (which still make it available and possible to
work with) and progress only rsvp-te on the standards track.

At the meeting there were a wide spread support for this idea, but
it was ruled that it was premature to call wg consensus on this at the
meeting and that we wanted to take the discussion on the mpls mailing
list.

This mail is to initiate this discussion. Please keep the=20 discussion
on the mpls list, do not cross post other lists. A separate mail to
the ccamp, pwe3 and ppvpn has been sent to inform those wg's of=20 this
discussion.

/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 <http://www.utfors.se/>



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


--=====================_8033411==_.ALT-- From owner-mpls@UU.NET Mon Jul 22 04:32:42 2002 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 ESMTP id EAA28335 for ; Mon, 22 Jul 2002 04:32:42 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyow08108 for ; Mon, 22 Jul 2002 08:33:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyow06213; Mon, 22 Jul 2002 08:32:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyow20553 for mpls-outgoing; Mon, 22 Jul 2002 08:32:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyow20545 for ; Mon, 22 Jul 2002 08:32: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 QQmyow09311 for ; Mon, 22 Jul 2002 08:30:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyow07987 for ; Mon, 22 Jul 2002 08:30:31 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQmyow07970 for ; Mon, 22 Jul 2002 08:30:30 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 22 Jul 2002 14:22:43 +0530 Received: from sailendram (sailendram.future.futsoft.com [10.4.8.18]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id g6M8U0C7031720; Mon, 22 Jul 2002 14:00:01 +0530 Reply-To: From: "sailendra mahanty" To: "'Loa Andersson'" Cc: "'MPLS wg'" , Subject: RE: initiating a discussion on mpls signaling protocols Date: Mon, 22 Jul 2002 13:41:37 +0530 Message-Id: <005201c23157$675d9fe0$1208040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200207181502.LAA18122@erosen-u10.cisco.com> Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This looks a good idea to me too as to the majority of the group. I believe that we can scale efficiently with RSVP. Regards, -Sailendra -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Eric Rosen Sent: Thursday, July 18, 2002 8:33 PM To: Loa Andersson Cc: MPLS wg; George Swallow; scott Giles; Wijnen, Bert (Bert) Subject: Re: initiating a discussion on mpls signaling protocols Loa> the question was asked whether we should make cr-ldp informational Loa> (which still make it available and possible to work with) and progress Loa> only rsvp-te on the standards track. This seems like a very good idea to me. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Mon Jul 22 07:05:19 2002 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 ESMTP id HAA00811 for ; Mon, 22 Jul 2002 07:05:18 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypg11723 for ; Mon, 22 Jul 2002 11:06:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypg10497; Mon, 22 Jul 2002 11:05:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypg06315 for mpls-outgoing; Mon, 22 Jul 2002 11:05:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmypg05825 for ; Mon, 22 Jul 2002 11:05:23 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 QQmypg09155 for ; Mon, 22 Jul 2002 11:05:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypg18066 for ; Mon, 22 Jul 2002 11:05:12 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQmypg18056 for ; Mon, 22 Jul 2002 11:05:11 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA21882 for ; Mon, 22 Jul 2002 13:05:03 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA04864 for ; Mon, 22 Jul 2002 13:05:04 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 13:05:01 +0200 Message-ID: From: Hummel Heinrich To: mpls@UU.NET Subject: AW: initiating a discussion on mpls singaling protocols Date: Mon, 22 Jul 2002 13:04:56 +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 I think, the IETF can only speak for itself. There may be other standardization bodies (ITU-T, MPLS Forum) which may fill the gap. Heinrich Hummel Siemens AG From owner-mpls@UU.NET Mon Jul 22 08:23:31 2002 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 ESMTP id IAA02209 for ; Mon, 22 Jul 2002 08:23:31 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypl21349 for ; Mon, 22 Jul 2002 12:24:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypl20572; Mon, 22 Jul 2002 12:24:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypl26725 for mpls-outgoing; Mon, 22 Jul 2002 12:23:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmypl26720 for ; Mon, 22 Jul 2002 12:23:52 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 QQmypl27524 for ; Mon, 22 Jul 2002 12:22:40 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypl21009 for ; Mon, 22 Jul 2002 12:22:40 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmypl21004 for ; Mon, 22 Jul 2002 12:22:39 GMT Received: from utfors.se ([195.58.105.129]) by blooper.utfors.se (Utfors AB) with ESMTP id g6MCMa5F018948; Mon, 22 Jul 2002 14:22:36 +0200 (MEST) Message-ID: <3D3BF90C.5060405@utfors.se> Date: Mon, 22 Jul 2002 14:22:36 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Hummel Heinrich CC: mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Heinrich, in my opinion the question is very clearly stated - is there support for us (the ietf) to move the cr-ldp from standard track to informational. We're "speaking for the ietf", it is more a matter of what we say ;) All, As usual we are trying to reach a rough consensus. Everyone (i.e. the mpls wg) can help create this consensus by answering the question above. Especially it will be helpful if you were involved in specifying the mpls protocols, have implemented or deployed (SP) those protocols, and take the time to respond. I will be ready to give the first extensive tally mid this week. Currently the count is yes: 30 no: 7, if you normalize those e.g. by counting each company once it is yes: 21 no: 4 Disclaimer: Given that I've managed to decipher the sometimes cryptic mails correctly :o) /Loa Hummel Heinrich wrote: > I think, the IETF can only speak for itself. There may be other standardization >bodies (ITU-T, MPLS Forum) which may fill > the gap. > > Heinrich Hummel > Siemens AG > -- 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 Jul 22 08:38:26 2002 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 ESMTP id IAA02492 for ; Mon, 22 Jul 2002 08:38:26 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypm10692 for ; Mon, 22 Jul 2002 12:39:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypm09413; Mon, 22 Jul 2002 12:38:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypm27281 for mpls-outgoing; Mon, 22 Jul 2002 12:38:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmypm27276 for ; Mon, 22 Jul 2002 12:38: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 QQmypm13559 for ; Mon, 22 Jul 2002 12:38:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypm27311 for ; Mon, 22 Jul 2002 12:38:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmypm27306 for ; Mon, 22 Jul 2002 12:38:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA14513 for ; Mon, 22 Jul 2002 08:38:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA14355 for mpls@uu.net; Mon, 22 Jul 2002 08:38:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmypm27240 for ; Mon, 22 Jul 2002 12:37: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 QQmypm14540 for ; Mon, 22 Jul 2002 12:37:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypm08376 for ; Mon, 22 Jul 2002 12:37:17 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmypm08363 for ; Mon, 22 Jul 2002 12:37:16 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 18:13:10 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA064C2E13@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: sudheer@nayna.com Cc: mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols Date: Mon, 22 Jul 2002 18:09:21 +0530 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 In a network where you need to handle hundreds of thousands of LSPs, with a significant percentage of them going on and off frequently, would the soft state approach scale effectively ? By making the behaviour harder by introducing work arounds will we losing/missing something or killing performance. I think a thorough performance analysis has to be done on this between CR LDP and RSVP-TE before coming to a conclusion purely based on numbers in a survey. Numbers usually come from what the leaders do. Implementation ease - I meant, CR LDP is much easier to undestand, implement and maintain than RSVP-TE( take into account RSVP+LSP_Tunneling + its addons like Refresh reduction to make it scalable). Also if LDP exists, then CRLDP is a small add on. Having LDP and CR LDP together and maintaining and managing it is much easier than LDP+RSVP_TE. Regards, Vijay -----Original Message----- From: Sudheer Dharanikota [mailto:sudheer@nayna.com] Sent: Friday, July 19, 2002 7:30 PM To: Vijayanand C - CTD, Chennai. Cc: Jean Philippe Vasseur; mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols "Vijayanand C - CTD, Chennai." wrote: > The technical issues are stated in this and subsequent mails and can be > restated as > - scalability with efficiency and performance, esp in future GMPLS networks Why do you think sclability will be a big issue in the GMPLS networks? Remeber GMPLS is meant for transport networks. The number of active connections would be typically less than or equal to the current number of data connections in a core. > > - Ease of implementation and maintenance. A more cleaner protocol than > RSVP-TE Ease of implemenatation if you start from the beginning. If you take an initial code base from a well-known site and modifying it is not a big deal. Or am I missing something here? - sudheer > > - Co-existence with LDP > > Regards, > Vijay > > -----Original Message----- > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > Sent: Friday, July 19, 2002 6:03 PM > To: Vijayanand C - CTD, Chennai. > Cc: MPLS wg; nagabhushana.ramaswamy@wipro.com > Subject: RE: initiating a discussion on mpls singaling protocols > > At 11:00 19/07/2002 +0530, Vijayanand C - CTD, Chennai. wrote: > >I agree with what Bhushana says.We need to look at it from the technical > >merits apart from who supports RSVP-TE and who does'nt. > > > >I think RSVP-TE has become more popular not because of its technical > >superiority over CR LDP but purely due to the push it has received from a > >few leading vendors, who choose to use it since they already had RSVP. The > >support for RSVP-TE is not because of its technical merits but because of > >the leading vendors choosing it causing others to meekly follow suit. > >However, it is not too late to weigh its merits against CR LDP. > > > >CR LDP is much more cleaner and has lesser scalability issues. Also, when > >one has LDP it is much easier to have CR LDP than extending RSVP for > >RSVP-TE. CR LDP is specifically meant for TE in MPLS and hence is > >advantageous. > > don't see the technical arguments there ... > > JP. > > > From an implementors point of view also,having been involved > >in implementation of both the protocols, I feel CR LDP is much easier to > >understand, implement and maintain. One also needs to look at other > >performance issues, which may become critical in GMPLS, I wonder if anyone > >has checked it. > > > > > >Regards, > >Vijay > > > >-----Original Message----- > >From: Nagabhushana Ramaswamy Nadig > >[mailto:nagabhushana.ramaswamy@wipro.com] > >Sent: Thursday, July 18, 2002 9:45 PM > >To: MPLS wg > >Subject: Re: initiating a discussion on mpls singaling protocols > > > > > >This message uses a character set that is not supported by the Internet > >Service. To view the original message content, open the attached message. > >If the text doesn't display correctly, save the attachment to disk, and > then > >open it using a viewer that can display the original character set. From owner-mpls@UU.NET Mon Jul 22 09:06:32 2002 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 ESMTP id JAA03212 for ; Mon, 22 Jul 2002 09:06:32 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypo01271 for ; Mon, 22 Jul 2002 13:07:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypo29966; Mon, 22 Jul 2002 13:06:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypo20437 for mpls-outgoing; Mon, 22 Jul 2002 13:06:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmypo20416 for ; Mon, 22 Jul 2002 13:06: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 QQmypo22341 for ; Mon, 22 Jul 2002 13:06:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypo09091 for ; Mon, 22 Jul 2002 13:06:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmypo09074 for ; Mon, 22 Jul 2002 13:06:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA15778 for ; Mon, 22 Jul 2002 09:06:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA17668 for mpls@uu.net; Mon, 22 Jul 2002 09:06:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmypo19933 for ; Mon, 22 Jul 2002 13:05: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 QQmypo11420 for ; Mon, 22 Jul 2002 13:05:02 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypo08639 for ; Mon, 22 Jul 2002 13:05:02 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 QQmypo08633 for ; Mon, 22 Jul 2002 13:05:01 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6MD4buv021846; Mon, 22 Jul 2002 09:04:38 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (che-vpn2-39.cisco.com [10.86.244.39]) by bucket.cisco.com (Mirapoint) with ESMTP id ABI04579; Mon, 22 Jul 2002 09:04:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20020722084421.0393bd28@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Jul 2002 09:04:03 -0400 To: "Vijayanand C - CTD, Chennai." From: "Thomas D. Nadeau" Subject: Re: initiating a discussion on mpls singaling protocols Cc: sudheer@nayna.com, mpls@UU.NET In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA064C2E13@haritha.hclt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >In a network where you need to handle hundreds of thousands of LSPs, with a >significant percentage of them going on and off frequently, would the soft >state approach scale effectively ? >By making the behaviour harder by introducing work arounds will we >losing/missing something or killing performance. I think a thorough >performance analysis has to be done on this between CR LDP and RSVP-TE >before coming to a conclusion purely based on numbers in a survey. Numbers >usually come from what the leaders do. >Implementation ease - I meant, CR LDP is much easier to undestand, implement >and maintain than RSVP-TE( take into account RSVP+LSP_Tunneling + its addons >like Refresh reduction to make it scalable). >Also if LDP exists, then CRLDP is a small add on. >Having LDP and CR LDP together and maintaining and >managing it is much easier than LDP+RSVP_TE. Difficulty of implementation is of little concern at this point in the game. The point is that customers want to pay for these features so vendors that want to sell routers will implement whatever their customers tell them to. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Mon Jul 22 09:16:17 2002 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 ESMTP id JAA03449 for ; Mon, 22 Jul 2002 09:16:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypp15130 for ; Mon, 22 Jul 2002 13:17:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypp13834; Mon, 22 Jul 2002 13:16:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypp23060 for mpls-outgoing; Mon, 22 Jul 2002 13:16:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmypp23011 for ; Mon, 22 Jul 2002 13:16: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 QQmypp13589 for ; Mon, 22 Jul 2002 13:15:48 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypp14336 for ; Mon, 22 Jul 2002 13:15:48 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmypp14319 for ; Mon, 22 Jul 2002 13:15:48 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA16275 for ; Mon, 22 Jul 2002 09:15:47 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA19409 for mpls@uu.net; Mon, 22 Jul 2002 09:15:47 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyom24707 for ; Mon, 22 Jul 2002 06:08:14 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 QQmyom03727 for ; Mon, 22 Jul 2002 06:07:35 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyom25286 for ; Mon, 22 Jul 2002 06:07:35 GMT Received: from omta05.mta.everyone.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sitemail3.everyone.net [216.200.145.37]) id QQmyom25274 for ; Mon, 22 Jul 2002 06:07:34 GMT Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta05.mta.everyone.net (Postfix) with ESMTP id 359EC48C1E for ; Sun, 21 Jul 2002 23:07:34 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id 1AB6A394A; Sun, 21 Jul 2002 23:07:34 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Sun, 21 Jul 2002 23:07:34 -0700 (PDT) From: Gary Blankenship To: mpls@UU.NET Subject: MPLS L2VPN Multiple Packet (Broadcast/Multicast/UnkUnicast) Problem Reply-To: ccie@k.st X-Originating-Ip: [202.221.54.179] Message-Id: <20020722060734.1AB6A394A@sitemail.everyone.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS WG, I was wondering what the current direction of the MPLS WG is for solving the duplicate copy over single link problem for L2VPN. Problem definition: In a multipoint environment a full mesh of LSP's is required (classic N(N-1)/2). If the packet is duplicated at the head end it results in multiple copies of the same packet traveling over the same wire (bad thing). Questions: What is the current thinking for solving this problem? Draft Yasukawa (RSVP Multicast LSPs)? Hierarchical LSPs? Can someone please give me a status summary on work to resolve this? Comments from anyone on the Lasserre-VKompella draft? Any ideas leading the pack? Thanks, Gary _____________________________________________________________ Powered by a short email address ... http://www.k.st _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag From owner-mpls@UU.NET Mon Jul 22 09:18:06 2002 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 ESMTP id JAA03489 for ; Mon, 22 Jul 2002 09:18:06 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypp06277 for ; Mon, 22 Jul 2002 13:18:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypp04719; Mon, 22 Jul 2002 13:18:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypp23116 for mpls-outgoing; Mon, 22 Jul 2002 13:17:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmypp23104 for ; Mon, 22 Jul 2002 13:17: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 QQmypp19483 for ; Mon, 22 Jul 2002 13:17:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypp15252 for ; Mon, 22 Jul 2002 13:17:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmypp15239 for ; Mon, 22 Jul 2002 13:17:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA16332 for ; Mon, 22 Jul 2002 09:17:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA19617 for mpls@uu.net; Mon, 22 Jul 2002 09:17:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmypk14887 for ; Mon, 22 Jul 2002 12:03:20 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 QQmypk20477 for ; Mon, 22 Jul 2002 12:03:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypk08013 for ; Mon, 22 Jul 2002 12:03:09 GMT Received: from apollo.nbase.co.il by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: apollo.nbase.co.il [194.90.137.2]) id QQmypk07990 for ; Mon, 22 Jul 2002 12:03:08 GMT Received: from mike.nbase.co.il ([194.90.136.58]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with ESMTP id AAA749 for ; Mon, 22 Jul 2002 15:09:40 +0200 Received: by mike.nbase.co.il (Postfix, from userid 1000) id 2818B2DEEC; Mon, 22 Jul 2002 15:03:05 +0300 (IDT) Date: Mon, 22 Jul 2002 15:03:04 +0300 From: mike@nbase.co.il (Michael Rozhavsky) To: mpls@UU.NET Subject: mpls menagement overview Message-ID: <20020722120304.GA31386@nbase.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-mpls@UU.NET Precedence: bulk Hi, I think there is a mistake in draft-ietf-mpls-mgmt-overview-02.txt. In section 5.4 of management overview it is stated that entries in mplsLabelStackTable table of LSR MIB are referenced to from mplsOutSegmentTable table, but in reality they are referenced to from mplsXCTable. -- Best regards. Michael Rozhavsky Tel: +972-4-9936248 mrozhavsky@opticalaccess.com Fax: +972-4-9890564 Optical Access Senior Software Engineer www.opticalaccess.com From owner-mpls@UU.NET Mon Jul 22 09:18:11 2002 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 ESMTP id JAA03502 for ; Mon, 22 Jul 2002 09:18:10 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypp17081 for ; Mon, 22 Jul 2002 13:19:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypp16183; Mon, 22 Jul 2002 13:18:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypp23141 for mpls-outgoing; Mon, 22 Jul 2002 13:18:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmypp23136 for ; Mon, 22 Jul 2002 13: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 QQmypp01598 for ; Mon, 22 Jul 2002 13:17:33 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypp15712 for ; Mon, 22 Jul 2002 13:17:27 GMT Received: from mail.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQmypp15510 for ; Mon, 22 Jul 2002 13:17:20 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g6MDD0h22716; Mon, 22 Jul 2002 15:13:00 +0200 Received: from alcatel.be ([138.203.67.231]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002072215171214:4416 ; Mon, 22 Jul 2002 15:17:12 +0200 Message-ID: <3D3C05D8.9A08A8C4@alcatel.be> Date: Mon, 22 Jul 2002 15:17:12 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Loa Andersson Cc: MPLS wg , George Swallow , scott Giles , "Wijnen, Bert (Bert)" Subject: Re: initiating a discussion on mpls singaling protocols References: <3D36A98A.7070103@utfors.se> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/22/2002 15:17:12, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/22/2002 15:17:13 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 JAA03502 i definitely support the idea to progress rsvp-te on the standard track and cr-ldp as informational only deployment reports (from the user community) can also help here (in addition, development report as delivered by the gmpls survey should also give a good orientation to the discussion) - dimitri. Loa Andersson wrote: > > All, > > at the mpls wg meeting at the 54th IETF in Yokohama the issue of having > two functional similar (not to say overlapping) protocols addressing > the same functional space, as rsvp-te and cr-ldp were brought up. > > The background is that when the signaling protocol for mpls traffic > engineering and setting up explicit / constraint based routes were > designed, there were two different approaches. One based on rsvp and > the other on ldp. It was not at that time possible to resolve the > differences between the two approaches and this protocol duplication > as been reflected in creation of sometimes functional duplicate > specifications. > > Since then both protocols has been progressed to proposed standard > and implemented. > > However, as has been shown in the survey on signaling protocols for > GMPLS the implementations of rsvp-te far out number the cr-ldp > implementations. As there are issues with having two similar standards > (potentially diverging), and it generates duplicate work in several > ietf working groups, the question was asked whether we should make > cr-ldp informational (which still make it available and possible to > work with) and progress only rsvp-te on the standards track. > > At the meeting there were a wide spread support for this idea, but > it was ruled that it was premature to call wg consensus on this at the > meeting and that we wanted to take the discussion on the mpls mailing > list. > > This mail is to initiate this discussion. Please keep the discussion > on the mpls list, do not cross post other lists. A separate mail to > the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this > discussion. > > /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 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Mon Jul 22 09:22:42 2002 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 ESMTP id JAA03572 for ; Mon, 22 Jul 2002 09:22:42 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypp14950 for ; Mon, 22 Jul 2002 13:23:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypp08173; Mon, 22 Jul 2002 13:19:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypp23210 for mpls-outgoing; Mon, 22 Jul 2002 13:19:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmypp23203 for ; Mon, 22 Jul 2002 13:19: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 QQmypp10695 for ; Mon, 22 Jul 2002 13:17:12 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypp15304 for ; Mon, 22 Jul 2002 13:17:12 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmypp15300 for ; Mon, 22 Jul 2002 13:17:11 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA16347 for ; Mon, 22 Jul 2002 09:17:11 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA19705 for mpls@uu.net; Mon, 22 Jul 2002 09:17:11 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmypo11923 for ; Mon, 22 Jul 2002 13:04: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 QQmypo09088 for ; Mon, 22 Jul 2002 13:04:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypo24728 for ; Mon, 22 Jul 2002 13:04:16 GMT Received: from mail1.hd.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hdfdns01.hd.intel.com [192.52.58.10]) id QQmypo24724 for ; Mon, 22 Jul 2002 13:04:16 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by mail1.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6MD4Fc04819 for ; Mon, 22 Jul 2002 13:04:15 GMT Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002072206032602665 for ; Mon, 22 Jul 2002 06:03:26 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 15:00:37 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A01FB4A85@alpha.igk.intel.com> From: "Szymanski, Pawel" To: "'mpls@uu.net'" Subject: mplsIngressLsrId in MPLS TE MIB Date: Mon, 22 Jul 2002 15:00:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have two questions concerning mplsIngressLsrId in MPLS TE MIB: 1) The mplsTunnelTable vriable is defined as MplsLsrIdentifier. This type is defined in MPLS TC MIB as 4-octets string. Description for the variable says that for RSVP-TE it should mimic Extended Tunnel ID field. However if RSVP-TE for IPv6 is used, the field is 16-bytes long. It seems to me that the MplsLsrIdentifier definition shall be extended. 2) Is it permissible to set mplsIngressLsrId variable on the ingress router to value other than local LSR ID or 0 ? Thanks in advance, Pawel Szymanski Software Engineer at Intel Technology Poland mailto:pawel.szymanski@intel.com From owner-mpls@UU.NET Mon Jul 22 09:48:32 2002 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 ESMTP id JAA04208 for ; Mon, 22 Jul 2002 09:48:31 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypr09472 for ; Mon, 22 Jul 2002 13:49:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypr08055; Mon, 22 Jul 2002 13:48:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypr25135 for mpls-outgoing; Mon, 22 Jul 2002 13:48:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmypr25128 for ; Mon, 22 Jul 2002 13:48: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 QQmypr13471 for ; Mon, 22 Jul 2002 13:48:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypr07716 for ; Mon, 22 Jul 2002 13:48:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmypr07704 for ; Mon, 22 Jul 2002 13:48:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18107 for ; Mon, 22 Jul 2002 09:48:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA25797 for mpls@uu.net; Mon, 22 Jul 2002 09:48:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmypr25082 for ; Mon, 22 Jul 2002 13:47:17 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 QQmypr25432 for ; Mon, 22 Jul 2002 13:46:57 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypr12382 for ; Mon, 22 Jul 2002 13:46: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.24.11]) id QQmypr12375 for ; Mon, 22 Jul 2002 13:46:56 GMT Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6MD8ThI006455; Mon, 22 Jul 2002 06:08:29 -0700 (PDT) Received: from cisco.com (ams-rraszuk2-vpn5.cisco.com [10.61.160.14]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFM40932; Mon, 22 Jul 2002 06:11:03 -0700 (PDT) Message-ID: <3D3C03C9.67B8BBC9@cisco.com> Date: Mon, 22 Jul 2002 15:08:25 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Loa Andersson CC: Hummel Heinrich , mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <3D3BF90C.5060405@utfors.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi Loa, You can add my vote: CRLDP experiment to be declared informational, RSVP-TE proceeds on standards track. R. > Loa Andersson wrote: > > Heinrich, > > in my opinion the question is very clearly stated - is there support for > us (the ietf) to move the cr-ldp from standard track to informational. > We're "speaking for the ietf", it is more a matter of what we say ;) > > All, > > As usual we are trying to reach a rough consensus. Everyone (i.e. the > mpls wg) can help create this consensus by answering the question > above. > > Especially it will be helpful if you were involved in specifying the > mpls protocols, have implemented or deployed (SP) those protocols, and > take the time to respond. > > I will be ready to give the first extensive tally mid this week. > Currently the count is > yes: 30 no: 7, > if you normalize those e.g. by counting each company once it is > yes: 21 no: 4 > > Disclaimer: Given that I've managed to decipher the sometimes cryptic > mails correctly :o) > > /Loa > > Hummel Heinrich wrote: > > > I think, the IETF can only speak for itself. There may be other standardization > > >bodies (ITU-T, MPLS Forum) which may fill > > the gap. > > > > Heinrich Hummel > > Siemens AG > > > > -- > 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 Jul 22 09:53:39 2002 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 ESMTP id JAA04296 for ; Mon, 22 Jul 2002 09:53:39 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypr18157 for ; Mon, 22 Jul 2002 13:54:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypr12631; Mon, 22 Jul 2002 13:51:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypr25260 for mpls-outgoing; Mon, 22 Jul 2002 13:50:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmypr25232 for ; Mon, 22 Jul 2002 13:50:03 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 QQmypr19203 for ; Mon, 22 Jul 2002 13:49:56 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypr10337 for ; Mon, 22 Jul 2002 13:49:53 GMT Received: from gorilla.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQmypr10140 for ; Mon, 22 Jul 2002 13:49:46 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA07917; Mon, 22 Jul 2002 15:49:33 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA21307; Mon, 22 Jul 2002 15:49:34 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 15:49:32 +0200 Message-ID: From: Hummel Heinrich To: "'Vijayanand C - CTD, Chennai.'" , sudheer@nayna.com Cc: mpls@UU.NET Subject: AW: initiating a discussion on mpls singaling protocols Date: Mon, 22 Jul 2002 15:49:24 +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 JAA04296 Vijay, just because you mentioned hundreds of thousands of LSPs, here are my thoughts why it makes sense to preserve CR-LDP: In Yokohame I presented the results of a comparison between four methods as to overcome the O(n**2)-problem when VPNs shall be built using MPLS tunneling. By far, the best solution is to interconnect the n PEs with n-1 pairs of mutually inverse-directed elementary LSPs, and then to build merging mp2p H-LSPs as to concatenate some of them to different sink trees of LSPs. However, these mp2p H-LSPs were to be built in Downstream-Unsolicited mode which requires LDP syntax ! Next, as to identify the (already existing) sub H-LSPs, which are to be concatenated and/or are to be used as Control-Plane tunnels, their LSP-IDs are to be known and dealt with. However, LSP-IDs are only provided by CR-LDP, not by LDP. And if they should be built using explicit routing, some little extensions to the ER-HOP TLV will do. It is easier to take the ingrediences from LDP and CR-LDP rather than from LDP and RSVP-TE. Heinrich -----Ursprüngliche Nachricht----- Von: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com] Gesendet: Montag, 22. Juli 2002 14:39 An: sudheer@nayna.com Cc: mpls@UU.NET Betreff: Re: initiating a discussion on mpls singaling protocols In a network where you need to handle hundreds of thousands of LSPs, with a significant percentage of them going on and off frequently, would the soft state approach scale effectively ? By making the behaviour harder by introducing work arounds will we losing/missing something or killing performance. I think a thorough performance analysis has to be done on this between CR LDP and RSVP-TE before coming to a conclusion purely based on numbers in a survey. Numbers usually come from what the leaders do. Implementation ease - I meant, CR LDP is much easier to undestand, implement and maintain than RSVP-TE( take into account RSVP+LSP_Tunneling + its addons like Refresh reduction to make it scalable). Also if LDP exists, then CRLDP is a small add on. Having LDP and CR LDP together and maintaining and managing it is much easier than LDP+RSVP_TE. Regards, Vijay -----Original Message----- From: Sudheer Dharanikota [mailto:sudheer@nayna.com] Sent: Friday, July 19, 2002 7:30 PM To: Vijayanand C - CTD, Chennai. Cc: Jean Philippe Vasseur; mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols "Vijayanand C - CTD, Chennai." wrote: > The technical issues are stated in this and subsequent mails and can be > restated as > - scalability with efficiency and performance, esp in future GMPLS networks Why do you think sclability will be a big issue in the GMPLS networks? Remeber GMPLS is meant for transport networks. The number of active connections would be typically less than or equal to the current number of data connections in a core. > > - Ease of implementation and maintenance. A more cleaner protocol than > RSVP-TE Ease of implemenatation if you start from the beginning. If you take an initial code base from a well-known site and modifying it is not a big deal. Or am I missing something here? - sudheer > > - Co-existence with LDP > > Regards, > Vijay > > -----Original Message----- > From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com] > Sent: Friday, July 19, 2002 6:03 PM > To: Vijayanand C - CTD, Chennai. > Cc: MPLS wg; nagabhushana.ramaswamy@wipro.com > Subject: RE: initiating a discussion on mpls singaling protocols > > At 11:00 19/07/2002 +0530, Vijayanand C - CTD, Chennai. wrote: > >I agree with what Bhushana says.We need to look at it from the technical > >merits apart from who supports RSVP-TE and who does'nt. > > > >I think RSVP-TE has become more popular not because of its technical > >superiority over CR LDP but purely due to the push it has received from a > >few leading vendors, who choose to use it since they already had RSVP. The > >support for RSVP-TE is not because of its technical merits but because of > >the leading vendors choosing it causing others to meekly follow suit. > >However, it is not too late to weigh its merits against CR LDP. > > > >CR LDP is much more cleaner and has lesser scalability issues. Also, when > >one has LDP it is much easier to have CR LDP than extending RSVP for > >RSVP-TE. CR LDP is specifically meant for TE in MPLS and hence is > >advantageous. > > don't see the technical arguments there ... > > JP. > > > From an implementors point of view also,having been involved > >in implementation of both the protocols, I feel CR LDP is much easier to > >understand, implement and maintain. One also needs to look at other > >performance issues, which may become critical in GMPLS, I wonder if anyone > >has checked it. > > > > > >Regards, > >Vijay > > > >-----Original Message----- > >From: Nagabhushana Ramaswamy Nadig > >[mailto:nagabhushana.ramaswamy@wipro.com] > >Sent: Thursday, July 18, 2002 9:45 PM > >To: MPLS wg > >Subject: Re: initiating a discussion on mpls singaling protocols > > > > > >This message uses a character set that is not supported by the Internet > >Service. To view the original message content, open the attached message. > >If the text doesn't display correctly, save the attachment to disk, and > then > >open it using a viewer that can display the original character set. From owner-mpls@UU.NET Mon Jul 22 10:00:17 2002 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 ESMTP id KAA04460 for ; Mon, 22 Jul 2002 10:00:17 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyps16208 for ; Mon, 22 Jul 2002 14:01:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyps15025; Mon, 22 Jul 2002 14:00:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyps28646 for mpls-outgoing; Mon, 22 Jul 2002 14:00:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyps28581 for ; Mon, 22 Jul 2002 14:00:26 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 QQmypr20605 for ; Mon, 22 Jul 2002 13:59:56 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypr25862 for ; Mon, 22 Jul 2002 13:59: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 QQmypr25854 for ; Mon, 22 Jul 2002 13: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 JAA01984 for ; Mon, 22 Jul 2002 09:59: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 JAA12949 for ; Mon, 22 Jul 2002 09:59:53 -0400 (EDT) Message-ID: <3D3C0FEE.6000906@marconi.com> Date: Mon, 22 Jul 2002 10:00:14 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: initiating a discussion on mpls singaling protocols References: <55E277B99171E041ABF5F4B1C6DDCA064C2E13@haritha.hclt.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijayanand C - CTD, Chennai. wrote: > In a network where you need to handle hundreds of thousands of LSPs, with a > significant percentage of them going on and off frequently, would the soft > state approach scale effectively ? If refresh reduction (RFC 2961) is implemented, it will scale just as well as any other approach will. Keep in mind that CR-LDP's seeming similicity is hiding all of the overhead inherent in using TCP for reliable delivery of control-plane packets. -- David From owner-mpls@UU.NET Mon Jul 22 10:32:05 2002 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 ESMTP id KAA05239 for ; Mon, 22 Jul 2002 10:32:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypu10790 for ; Mon, 22 Jul 2002 14:33:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypu09760; Mon, 22 Jul 2002 14:32:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypu21264 for mpls-outgoing; Mon, 22 Jul 2002 14:32:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmypu21256 for ; Mon, 22 Jul 2002 14:32: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 QQmypu18723 for ; Mon, 22 Jul 2002 14:31:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypu08943 for ; Mon, 22 Jul 2002 14:31:06 GMT Received: from crufty.research.bell-labs.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns2.research.bell-labs.com [204.178.16.49]) id QQmypu08937 for ; Mon, 22 Jul 2002 14:31:06 GMT Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6MEUpCT066790; Mon, 22 Jul 2002 10:30:55 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6MEUjo81782; Mon, 22 Jul 2002 10:30:45 -0400 (EDT) Received: from fanghpcho (fangh-pcho [135.180.160.148]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id KAA05206; Mon, 22 Jul 2002 10:30:42 -0400 (EDT) From: "Fang Hao" To: "Adrian Farrel" Cc: "'mpls@uu.net'" Subject: RE: Question on MIB info for LSP tunneling Date: Mon, 22 Jul 2002 10:30:42 -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) In-Reply-To: <005501c2310b$8ea9f720$9b13588a@movaz.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Adrian, Here is what I am still missing - From L1, I may get mplsOutSegmentIfIndex(L1), which is the interface index of L2, as you suggested. Let's call this index i2. Now the problem is how to get the L2 entry in mplsTunnelTable in TE MIB, by using i2. Look up the interface table does not help since this table only contains the LSP name of L2, but not the mplsTunnelIndex. It seems to me that unless we scan the entire mplsTunnelTable and compare each mplsTunnelIfIndex with i2, there is no way to "directly" access the entry of L2 - this is what I was trying to avoid. I hope this is not true. Otherwise it seems to be an unfortunate consequence of the current MIB structure. Thanks, Fang -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adrian Farrel Sent: Sunday, July 21, 2002 11:38 AM To: Fang Hao Cc: 'mpls@uu.net' Subject: Re: Question on MIB info for LSP tunneling Hi Fang, L1 is tunneled through L2. L2 is installed in the TE MIB with an ifindex using mplsTunnelIsIf and mplsTunnelIfIndex. This means that it can be found within the implementation as an interface and available bandwidth can be examined just as though it was a physical interface. L1 shows in the LSR MIB with an outsegment that contains mplsOutSegmentIfIndex. This is the outgoing interface for L1 and is not the physical interface - it is the interface index of L2. So, from L1 you can get to L2. Adrian ----- Original Message ----- From: "Fang Hao" To: "Adrian Farrel" Cc: Sent: Friday, July 19, 2002 2:44 PM Subject: RE: Question on MIB info for LSP tunneling > Adrian, > > Thanks for your reply. But I am still missing something - > the tunnel creation part is fine, but when I need to > access information about L2 (the LSP tunnel), I have a problem. > What I would need is: given LSP L1 (i.e., knowing its > mplsTunnelIndex), I need to find out which tunnel it is > going through, how much bandwidth is left on this tunnel L2, > what is the ingress/egress LSR id, etc. For those info > I would probably need the mplsTunnelIndex for L2. > > If I am not misunderstanding the MIBs, this mplsTunnelIndex > (of L2) does not appear in either interface table or > out segment table. - any comments? > > Thanks, > Fang From owner-mpls@UU.NET Mon Jul 22 11:23:05 2002 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 ESMTP id LAA07157 for ; Mon, 22 Jul 2002 11:23:04 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypx15087 for ; Mon, 22 Jul 2002 15:24:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypx13844; Mon, 22 Jul 2002 15:23:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypx17578 for mpls-outgoing; Mon, 22 Jul 2002 15:23:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmypx17565 for ; Mon, 22 Jul 2002 15:23: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 QQmypx19898 for ; Mon, 22 Jul 2002 15:23:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypx15906 for ; Mon, 22 Jul 2002 15:23:06 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQmypx15886 for ; Mon, 22 Jul 2002 15:23:05 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 22 Jul 2002 21:15:15 +0530 Received: from sailendram (sailendram.future.futsoft.com [10.4.8.18]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id g6MFMXC7006103; Mon, 22 Jul 2002 20:52:33 +0530 Reply-To: From: "sailendra mahanty" To: "'David Charlap'" , "'Vijayanand C - CTD, Chennai.'" Cc: "'IETF MPLS List'" Subject: RE: initiating a discussion on mpls singaling protocols Date: Mon, 22 Jul 2002 20:32:45 +0530 Message-Id: <006101c23190$d6daa460$1208040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3D3C0FEE.6000906@marconi.com> Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit When hundreds of thousands of LSPs going ON and OFF, CRLDP implementation may have scalability issues. As CRLDP implementation has to pay for this with Label withdraw/release message when RSVP has to pay for this with path/resv tear messages. -sailendra -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of David Charlap Sent: Monday, July 22, 2002 7:30 PM To: IETF MPLS List Subject: Re: initiating a discussion on mpls singaling protocols Vijayanand C - CTD, Chennai. wrote: > In a network where you need to handle hundreds of thousands of LSPs, with a > significant percentage of them going on and off frequently, would the soft > state approach scale effectively ? If refresh reduction (RFC 2961) is implemented, it will scale just as well as any other approach will. Keep in mind that CR-LDP's seeming similicity is hiding all of the overhead inherent in using TCP for reliable delivery of control-plane packets. -- David *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Mon Jul 22 11:25:38 2002 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 ESMTP id LAA07268 for ; Mon, 22 Jul 2002 11:25:38 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypx09694 for ; Mon, 22 Jul 2002 15:26:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypx08873; Mon, 22 Jul 2002 15:26:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypx17762 for mpls-outgoing; Mon, 22 Jul 2002 15:25:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmypx17721 for ; Mon, 22 Jul 2002 15:25: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 QQmypx04726 for ; Mon, 22 Jul 2002 15:22:30 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 QQmypp08886 for ; Mon, 22 Jul 2002 13:20:19 GMT Received: from m2vwall5.wipro.com ([10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g6MDK5j06246 for ; Mon, 22 Jul 2002 18:50:05 +0530 (IST) Received: from boochi.wipro.com ([10.117.3.144]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GZNJP200.0LE; Mon, 22 Jul 2002 18:49:50 +0530 Date: Mon, 22 Jul 2002 18:56:12 +0400 (RET) From: "Nagabhushana Ramaswamy Nadig" X-X-Sender: Reply-To: To: "Thomas D. Nadeau" cc: "Vijayanand C - CTD Chennai." , Subject: Re: initiating a discussion on mpls singaling protocols In-Reply-To: <4.3.2.7.2.20020722084421.0393bd28@bucket.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 22 Jul 2002, Thomas D. Nadeau wrote: > > Difficulty of implementation is of little concern at this point > in the > game. The point is that customers want to pay for these features so > vendors that want to sell routers will implement whatever their customers > tell them to. > > --Tom Of Course we never have an issue with this, after all money is what can have a final say in any business. But at the service level what is that, that makes RSVP-TE a better option!! That being the case we "have" to look at the other aspects of ease of implementation (which may be insignificant today, but I am not sure we may still have some implementations in future), support for future enhancements, and the whole lot of product life cycle management issues. Just my thought.... regards Bhushana > > > > > ------------------------------------------------------------------------ > Mathematics is the supreme nostalgia of our time. > > From owner-mpls@UU.NET Mon Jul 22 11:38:08 2002 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 ESMTP id LAA07794 for ; Mon, 22 Jul 2002 11:38:07 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypy22399 for ; Mon, 22 Jul 2002 15:39:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmypy21323; Mon, 22 Jul 2002 15:38:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmypy18760 for mpls-outgoing; Mon, 22 Jul 2002 15:38:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmypy18755 for ; Mon, 22 Jul 2002 15:38: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 QQmypy15432 for ; Mon, 22 Jul 2002 15:37:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmypy29846 for ; Mon, 22 Jul 2002 15:37:49 GMT Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQmypy29842 for ; Mon, 22 Jul 2002 15:37:49 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 11:37:47 -0400 Message-ID: <002101c23195$bb11a8a0$681810ac@movaz.com> From: "Adrian Farrel" To: "Fang Hao" Cc: "'mpls@uu.net'" References: Subject: Re: Question on MIB info for LSP tunneling Date: Mon, 22 Jul 2002 11:37:47 -0400 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 X-OriginalArrivalTime: 22 Jul 2002 15:37:47.0736 (UTC) FILETIME=[BB052580:01C23195] Sender: owner-mpls@UU.NET Precedence: bulk I agree. It is an unfortunate consequence. There are some things you can do. For example, you can use ifName in the interface MIB with something that makes keying into the TE MIB more simple. (Note that ifAlias is provided to give a secondary name that is printable and convenient). Adrian ----- Original Message ----- From: "Fang Hao" To: "Adrian Farrel" Cc: "'mpls@uu.net'" Sent: Monday, July 22, 2002 10:30 AM Subject: RE: Question on MIB info for LSP tunneling > Hi Adrian, > > Here is what I am still missing - > From L1, I may get mplsOutSegmentIfIndex(L1), which is the interface index > of L2, as you suggested. Let's call this index i2. Now the problem > is how to get the L2 entry in mplsTunnelTable in TE MIB, by using i2. > Look up the interface table does not help since this table only contains > the LSP name of L2, but not the mplsTunnelIndex. It seems to me that > unless we scan the entire mplsTunnelTable and compare each mplsTunnelIfIndex > with i2, there is no way to "directly" access the entry of L2 - this > is what I was trying to avoid. > > I hope this is not true. Otherwise it seems to be an unfortunate > consequence of the current MIB structure. > > Thanks, > Fang > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adrian > Farrel > Sent: Sunday, July 21, 2002 11:38 AM > To: Fang Hao > Cc: 'mpls@uu.net' > Subject: Re: Question on MIB info for LSP tunneling > > > Hi Fang, > > L1 is tunneled through L2. > > L2 is installed in the TE MIB with an ifindex using mplsTunnelIsIf and > mplsTunnelIfIndex. This means that it can be found within the > implementation as > an interface and available bandwidth can be examined just as though it was a > physical interface. > > L1 shows in the LSR MIB with an outsegment that contains > mplsOutSegmentIfIndex. > This is the outgoing interface for L1 and is not the physical interface - it > is > the interface index of L2. > > So, from L1 you can get to L2. > > Adrian > > ----- Original Message ----- > From: "Fang Hao" > To: "Adrian Farrel" > Cc: > Sent: Friday, July 19, 2002 2:44 PM > Subject: RE: Question on MIB info for LSP tunneling > > > > Adrian, > > > > Thanks for your reply. But I am still missing something - > > the tunnel creation part is fine, but when I need to > > access information about L2 (the LSP tunnel), I have a problem. > > What I would need is: given LSP L1 (i.e., knowing its > > mplsTunnelIndex), I need to find out which tunnel it is > > going through, how much bandwidth is left on this tunnel L2, > > what is the ingress/egress LSR id, etc. For those info > > I would probably need the mplsTunnelIndex for L2. > > > > If I am not misunderstanding the MIBs, this mplsTunnelIndex > > (of L2) does not appear in either interface table or > > out segment table. - any comments? > > > > Thanks, > > Fang > > > > From owner-mpls@UU.NET Mon Jul 22 12:17:30 2002 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 ESMTP id MAA10466 for ; Mon, 22 Jul 2002 12:17:30 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqb19978 for ; Mon, 22 Jul 2002 16:18:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqb18683; Mon, 22 Jul 2002 16:17:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqb14044 for mpls-outgoing; Mon, 22 Jul 2002 16:17:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyqb14039 for ; Mon, 22 Jul 2002 16:17: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 QQmyqb13800 for ; Mon, 22 Jul 2002 16:16:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqb24197 for ; Mon, 22 Jul 2002 16:16:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyqb24187 for ; Mon, 22 Jul 2002 16:16:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA29408 for ; Mon, 22 Jul 2002 12:16:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA13532 for mpls@uu.net; Mon, 22 Jul 2002 12:16:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyqb13620 for ; Mon, 22 Jul 2002 16:15:40 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 QQmyqb04813 for ; Mon, 22 Jul 2002 16:15:02 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqb15085 for ; Mon, 22 Jul 2002 16:15:01 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmyqb15073 for ; Mon, 22 Jul 2002 16:15:01 GMT Received: (qmail 13696 invoked by uid 104); 22 Jul 2002 16:15:00 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 0.478748 secs); 22 Jul 2002 16:15:00 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 22 Jul 2002 16:14:59 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6MGExc07515 for ; Mon, 22 Jul 2002 09:14:59 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 09:14:58 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03742@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Mon, 22 Jul 2002 09:14: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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10466 Hi, As a neutral observer, I think the choice of a protocol for standardization must be based on technical merits, rather than market share. Imagine standardizing Windows95 as the only standard! Yours, -Shahram > -----Original Message----- > From: Loa Andersson [mailto:loa.andersson@utfors.se] > Sent: Thursday, July 18, 2002 7:42 AM > To: MPLS wg > Cc: George Swallow; scott Giles; Wijnen, Bert (Bert) > Subject: initiating a discussion on mpls singaling protocols > > > All, > > at the mpls wg meeting at the 54th IETF in Yokohama the issue > of having > two functional similar (not to say overlapping) protocols addressing > the same functional space, as rsvp-te and cr-ldp were brought up. > > The background is that when the signaling protocol for mpls traffic > engineering and setting up explicit / constraint based routes were > designed, there were two different approaches. One based on rsvp and > the other on ldp. It was not at that time possible to resolve the > differences between the two approaches and this protocol duplication > as been reflected in creation of sometimes functional duplicate > specifications. > > Since then both protocols has been progressed to proposed standard > and implemented. > > However, as has been shown in the survey on signaling protocols for > GMPLS the implementations of rsvp-te far out number the cr-ldp > implementations. As there are issues with having two similar standards > (potentially diverging), and it generates duplicate work in several > ietf working groups, the question was asked whether we should make > cr-ldp informational (which still make it available and possible to > work with) and progress only rsvp-te on the standards track. > > At the meeting there were a wide spread support for this idea, but > it was ruled that it was premature to call wg consensus on this at the > meeting and that we wanted to take the discussion on the mpls mailing > list. > > This mail is to initiate this discussion. Please keep the discussion > on the mpls list, do not cross post other lists. A separate mail to > the ccamp, pwe3 and ppvpn has been sent to inform those wg's of this > discussion. > > /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 Jul 22 13:55:08 2002 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 ESMTP id NAA22100 for ; Mon, 22 Jul 2002 13:55:07 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqh28348 for ; Mon, 22 Jul 2002 17:56:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqh27096; Mon, 22 Jul 2002 17:55:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqh00498 for mpls-outgoing; Mon, 22 Jul 2002 17:54:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyqh00401 for ; Mon, 22 Jul 2002 17:54:44 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 QQmyqh22670 for ; Mon, 22 Jul 2002 17:53:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqh18797 for ; Mon, 22 Jul 2002 17:53:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyqh18782 for ; Mon, 22 Jul 2002 17:53:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA06814 for ; Mon, 22 Jul 2002 13:53:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA23737 for mpls@uu.net; Mon, 22 Jul 2002 13:53:05 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyqb14362 for ; Mon, 22 Jul 2002 16:22:28 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 QQmyqb25633 for ; Mon, 22 Jul 2002 16:22:26 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqb25812 for ; Mon, 22 Jul 2002 16:22:16 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 QQmyqb24845 for ; Mon, 22 Jul 2002 16:21:36 GMT Received: (qmail 16164 invoked by uid 104); 22 Jul 2002 16:21:01 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 0.465966 secs); 22 Jul 2002 16:21:01 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 22 Jul 2002 16:21:00 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6MGL0c13876; Mon, 22 Jul 2002 09:21:00 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 09:21:00 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03744@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Eric Osborne'" , neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: RE: your mail Date: Mon, 22 Jul 2002 09:20:58 -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 Eric, > I am familiar with the OAM discussion; it's happened a few times > already, as you know. So rather than going down that path again, let > me ask a question (particularly to you and Sharam) - is there anything > wrong with hashing for loadsharing purposes *other* than the fact that > it makes doing OAM the way you've proposed difficult, if not > impossible? 1) Y.1711 applies onlt to ER LSPs. 2) ECMP creates problem for your own proposed MPLS-ping 3) ECMP doesn't work if you have traffic with various label stack depth and various type of payload. And you need deep packet parsing. -Shahram From owner-mpls@UU.NET Mon Jul 22 13:59:30 2002 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 ESMTP id NAA22520 for ; Mon, 22 Jul 2002 13:59:30 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqi25987 for ; Mon, 22 Jul 2002 18:00:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqh24483; Mon, 22 Jul 2002 17:59:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqh01003 for mpls-outgoing; Mon, 22 Jul 2002 17:58:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyqh00854 for ; Mon, 22 Jul 2002 17:56:26 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 QQmyqh04825 for ; Mon, 22 Jul 2002 17:56:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqh21679 for ; Mon, 22 Jul 2002 17:56:23 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyqh21632 for ; Mon, 22 Jul 2002 17:56:21 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA07078 for ; Mon, 22 Jul 2002 13:56:21 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA24531 for mpls@uu.net; Mon, 22 Jul 2002 13:56:21 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyqh00442 for ; Mon, 22 Jul 2002 17:54: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 QQmyqg00092 for ; Mon, 22 Jul 2002 17:34:46 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqg24719 for ; Mon, 22 Jul 2002 17:34:46 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmyqg24712 for ; Mon, 22 Jul 2002 17:34:46 GMT Received: (qmail 18930 invoked by uid 104); 22 Jul 2002 17:34:45 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 0.534886 secs); 22 Jul 2002 17:34:45 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 22 Jul 2002 17:34:44 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6MHYdc04671; Mon, 22 Jul 2002 10:34:44 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 10:34:38 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03746@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Giles Heron'" , neil.2.harrison@bt.com Cc: eosborne@cisco.com, mpls@UU.NET Subject: RE: your mail Date: Mon, 22 Jul 2002 10:34:37 -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 Giles, > > so let's to go back to Yakov's email of 31st May: > > ------ > Giles, > > > 1. Efficient encapsulation of VPN traffic Correct, if you mean compared to IP forwarding. > > 2. Ability to run VPN on current hardware Who's hardware? the one who has the most market share? As I said in another email market share should not be used as the basis for a standard organization. Otherwise whoever has the biggest market share could make ANY thing they like to be a standard. > > > > There are probably other reasons as well... > > One of the "other reasons" is straightforward protection > against packet > spoofing. The packet spoofing that Yakov mentioned relies on the fact that an edge router never accepts an MPLS packet (which is not always true) and that it never terminates the MPLS tunnel in an inetrior LSR. The same thing could be said for IP tunnels: The edge router never forwards the incoming packets without encapsulating them in IP tunnel, and it never terminates an IP tunnel in an interior router. So IP tunnels have exactly the same packet spoofing prevention level as LDP LSPs. The only advantage I see using LDP as compared to IP tunneling is 16 bytes BW saving per packet, at the expense of implementing MPLS signaling and control-plane, as well as inability to decouple availability and QoS and creating new failure modes that are very hard to detect (even with MPLS-ping). I think somewhere you mentioned that sparing some extra BW may make sense if it makes the network easier to manage. -Shahram > > Yakov. > ------ > > whether these are "killer" reasons to deploy LDP rather than "pure IP" > or not depends on your point of view, but they are certainly reasons. > > there are of course others - e.g. the ability to run a BGP free core > (which some consider important for running carrier-grade voice and > Internet over the same PSN infrastructure). > > Giles > > - VPN survivability is a function of all cross-VPN traffic and is > > temporally non-deterministic on a per customer basis per > epoch. That is, > > there is no relationship between a DS codepoint and that pkt's > > 'survivability priority' vis-a-vis other pkts of same/different DS > > codepoints in either the same or other VPNs....and that's a > consequence of > > like-DS-class merging across VPN populations. > > - because of this hard QoS/availability guarantees per > VPN customer > > are not possible > > - because of this we are forced over-engineer and hope > > - MPLS introduces new failures modes even in p2p mode (this is the > > absolute vs relative addressing issue that I mentioned > previously), but mp2p > > LSPs create a new richness of fault-management complexity > > - the LDP LSPs track the IGP and so the network is not > flexible wrt > > traffic sensitivities......hence, it requires hashing > functions at P nodes > > which not only breaks the MPLS simple label forwarding idea > of MPLS but > > introduces another level of fault-management to deal with. > > > > So the fault-management issue (which you think is not > important given the > > tone of your response) is but 1 consequence of LDP. Similarly, the > > load-balancing issue is another consequence of LDP. And > similarly, another > > consequence of LDP is the inability to decouple VPN > performance/availability > > on a *per customer basis*. So all these aspects are > compromised when we use > > LDP......and for what compelling advantage(s) over using an > IPinIP solution > > (or p2p LSPs as/when necessary)? So please answer that for > me so that I can > > understand what I and others are clearly missing here that > makes LDP so > > wonderful that we simply can't afford to live without it? > > > > regards, Neil > > > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Mon Jul 22 14:01:00 2002 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 ESMTP id OAA22650 for ; Mon, 22 Jul 2002 14:00:59 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqi09127 for ; Mon, 22 Jul 2002 18:01:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqh29996; Mon, 22 Jul 2002 17:57:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqh00508 for mpls-outgoing; Mon, 22 Jul 2002 17:54:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyqh00368 for ; Mon, 22 Jul 2002 17:54: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 QQmyqc28780 for ; Mon, 22 Jul 2002 16:36:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqc08447 for ; Mon, 22 Jul 2002 16:36:30 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmyqc08439 for ; Mon, 22 Jul 2002 16:36:29 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1K46>; Mon, 22 Jul 2002 12:36:29 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267163@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Shahram Davari'" Cc: "'mpls@UU.NET '" Subject: RE: your mail Date: Mon, 22 Jul 2002 12:36:29 -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 Shahram, Not sure you meant this as a reply to me. Technically, you are correct - though the parsing operation associated with finding the bottom of stack is trivial, consisting of a 'grammar' in which only one bit per word is not noise. Moreover, Eric Rosen already responded to me on the mailing list with an answer I felt was sufficient - i.e. - bottom of stack, or last label looked at (in the event that the bottom of stack bit is not set in any label 'looked at'). Having hashed this out to my own satisfaction on the mailing list, I was hoping to let this thread expire. :-) Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Monday, July 22, 2002 12:16 PM To: 'Gray, Eric'; 'erosen@cisco.com' Cc: 'mpls@UU.NET ' Subject: RE: your mail To find the bottom of the stack you need parsing. -Shahram > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Tuesday, July 02, 2002 12:36 PM > To: 'erosen@cisco.com' > Cc: Shahram Davari; 'mpls@UU.NET ' > Subject: RE: your mail > > > Eric, > > I'm guessing that some hardware implementations might be > optimized around the need to process at most K labels. For any > such implementation, being required to possibly look at the Nth > label - where N is the number of labels in the stack and N may > be greater than K - may be virtually indistinguishable from > being required to parse the entire packet. > > In such cases, the engineers have to take a hard look at > what they might use as a fall back for the N > K case and then > do some hard analysis about whether or not such a fall back is > guaranteed to work in all cases. Because the consequences of > not getting the right answer after all this hard looking and > analysis are systemic at the network level, it might be useful > if this was hashed out publicly in a little more detail - don't > you think? :-) > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, July 02, 2002 11:02 AM > To: Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; > 'mpls@UU.NET ' > Subject: Re: your mail > > > SD=> So you do more than one lookup- so what? so you need to > parse the whole > SD=> packet in the core-so what? so you need to keep state in > the core, > > Please pay attention. > > There is not more than one lookup; doing the hash does not > require looking > anything up. > > Finding the bottom label does not involve parsing the whole packet. > > There is no state kept in the core. > > SD=> so you have no longer a simple label swap > > It is true that the essence of load balancing over equal > cost paths is that > the outgoing interface is not chosen solely on the basis of > the top label. > So? > > SD=> MPLS was designed to have simple forwarding. Hashing > takes it to new > SD=> levels of simplification never seen before. > > You might take a peek at section 3.12 of RFC 3031. > From owner-mpls@UU.NET Mon Jul 22 14:03:09 2002 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 ESMTP id OAA22854 for ; Mon, 22 Jul 2002 14:03:09 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqi12973 for ; Mon, 22 Jul 2002 18:04:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqi07219; Mon, 22 Jul 2002 18:00:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqh01028 for mpls-outgoing; Mon, 22 Jul 2002 17:58:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyqh00856 for ; Mon, 22 Jul 2002 17:56:26 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 QQmyqh04821 for ; Mon, 22 Jul 2002 17:56:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqh21674 for ; Mon, 22 Jul 2002 17:56:22 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyqh21656 for ; Mon, 22 Jul 2002 17:56:22 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA07083 for ; Mon, 22 Jul 2002 13:56:22 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA24548 for mpls@uu.net; Mon, 22 Jul 2002 13:56:22 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyqh00417 for ; Mon, 22 Jul 2002 17:54: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 QQmyqb28731 for ; Mon, 22 Jul 2002 16:23:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqb27048 for ; Mon, 22 Jul 2002 16:23:05 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 QQmyqb26764 for ; Mon, 22 Jul 2002 16:22:54 GMT Received: (qmail 16980 invoked by uid 104); 22 Jul 2002 16:22:52 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 0.508071 secs); 22 Jul 2002 16:22:52 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 22 Jul 2002 16:22:51 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6MGMpc14489; Mon, 22 Jul 2002 09:22:51 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 09:22:51 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03745@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kannan S (Networking) - CTD, Chennai.'" , Eric Osborne Cc: "'MPLS Mailing list'" Subject: RE: your mail Date: Mon, 22 Jul 2002 09:22:49 -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 > > My point is, if it is decided that an LSR is going to look > beyond whatever > depth it is supposed to, the LSR's ECMP hashing function > might as well look > at the IP header instead of looking at the bottom most label. What if the traffic is not IP? -Shahram > > Am I missing something here? > > Thanks, > Kans. > > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Wednesday, July 03, 2002 4:01 AM > To: Gray, Eric > Cc: 'Eric Osborne'; 'MPLS Mailing list' > Subject: Re: your mail > > > On Tue, Jul 02, 2002 at 04:38:15PM -0400, Gray, Eric wrote: > > Eric, > > > > It is in the fact that we have to be sure - > > just as you suggest. The cost of being sure, however, > > is that you have to be prepared to deal with occasions > > when the check fails. What do you do when the higher > > layer is not UDP or TCP - throw these packets in to a > > common bucket? What is the expected impact if this > > traffic might occasionally be significant? > > Then you need a better load-balancing algorithm. Either IP SA/DA and > some randomness, or random sampling from the packet, or (heaven > forbid) some sort of flow-based scheme. I'm even dubious about the > efficacy of using TCP/UDP ports to hash, given that most traffic is > either src or dst TCP port 80, which really only gives you the port in > the other direction to play with. But that's not really my problem, > as the implementation I'm familiar with doesn't do anything with > TCP/UDP ports (although I'm sure that *somewhere* in cisco we make a > device that does; I just don't deal with it/them). > > also, don't forget that this hypothetical algorithm takes into acount > IP SA/DA and TCP/UDP SP/DP. So if you have too many collisions, you > probably have very few flows/conversations/whatnot anyways, and either > need to move to something like per-packet (ick) or just larger pipes. > > > > > eric > > > > > > > Eric W. Gray > > > > > > -----Original Message----- > > From: Eric Osborne [mailto:eosborne@cisco.com] > > Sent: Tuesday, July 02, 2002 4:24 PM > > To: Gray, Eric > > Cc: 'Eric Osborne'; 'MPLS Mailing list' > > Subject: Re: your mail > > > > On Tue, Jul 02, 2002 at 03:36:52PM -0400, Gray, Eric wrote: > > > Eric, > > > > > > To answer your final two questions, yes it probably > > > is stealing. The fact that you can get away with a crime > > > does not make it any less a crime. Who knows, some vendors > > > may not check that the protocol over the top of IP is either > > > UDP or TCP before using the port numbers. > > > > If a vendor checks the offset where the port numbers should > be without > > checking for the correct protocol type, this is a cruddy > > implementation and shouldn't exist. My question was really > along the > > lines of "what if we use the values that we *know* are UDP/TCP port > > numbers"? From what you say above, it seems like that > might be OK, as > > long as we only do this when we're sure? Or is there some inherent > > architectual layer violation thing that you're objecting to? > > > > > > > > eric > > > > > I think you can > > > easily imagine what that might lead to if a set of packets > > > carry a higher level protocol where the corresponding fields > > > may vary from packet to packet in a single micro-flow. The > > > real question is how common is this? > > > > > > Eric W. Gray > > > Systems Architect > > > Celox Networks, Inc. > > > egray@celoxnetworks.com > > > 508 305 7214 > > > > > > > > > -----Original Message----- > > > From: Eric Osborne [mailto:eosborne@cisco.com] > > > Sent: Tuesday, July 02, 2002 1:32 PM > > > To: Hummel Heinrich > > > Cc: 'erosen@cisco.com'; Shahram Davari; 'Eric Osborne'; > George Sheng; > > > scullptor@yahoo.com; mpls@UU.NET > > > Subject: Re: your mail > > > > > > On Tue, Jul 02, 2002 at 04:25:37PM +0200, Hummel Heinrich wrote: > > > > It gets weirder and weirder: The MPLS WG invents a > label stack, but > > does > > > not care at all that any of the > > > > deeper nested labels may ever be signalled/carried by means of a > > > Label-TLV/object (no public comments to my > > > > Hierarchical LSPs, draft-hummel-mpls-hierarchical-lsp-01.txt). > > > > > > > > However it is ok, to "steal" the deepest nested label > and call it > > > "VC-label" for indexing > > > > some VRF at some remote PE. > > > > > > This is not theft; it's using the labels as they were > designed. How > > > is using the bottommost label as a VC-labe/VPN label/whatever > > > "stealing"? You seem to be attacking the very idea of > label stacking, > > > which is a pretty useful concept. > > > > > > > Furthermore it is ok, to "steal" the very same label > for hashing. > > > > > > > > > > What about IP router vendors that do load-balancing based on L4/L5 > > > information like protocol type and port numbers? Is that > stealing? > > > > > > > > > > > > > > > eric > > > > > > > Independent from what is clean and what is quick&dirty, I cannot > detect > > > any sense in giving a hash-meaning to the bottom label at all. > > > > > > > > > > > > > > > > Heinrich Hummel > > > > Siemens > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Eric Rosen [mailto:erosen@cisco.com] > > > > Gesendet: Dienstag, 2. Juli 2002 16:06 > > > > An: Shahram Davari > > > > Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; > mpls@UU.NET > > > > Betreff: Re: your mail > > > > > > > > > > > > Shahram> To do ECMP, you need to assign hashed values to egress > ports. > > > This > > > > Shahram> assignment is the hash state that I said you need. > > > > > > > > A hash is a function that maps some sequence of octets into a > > sequence > > > of > > > > integers. If you want to split traffic over six paths, while > ensuring > > > that > > > > all packets with the same bottom label travel the > same path, you > > need > > > a > > > > function that maps a 20 bit quantity into a number > from 1-6. There > > is > > > no > > > > need to maintain state of any kind. > From owner-mpls@UU.NET Mon Jul 22 14:16:57 2002 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 ESMTP id OAA24210 for ; Mon, 22 Jul 2002 14:16:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqj16445 for ; Mon, 22 Jul 2002 18:17:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqj14705; Mon, 22 Jul 2002 18:17:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqj24891 for mpls-outgoing; Mon, 22 Jul 2002 18:16:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyqj24881 for ; Mon, 22 Jul 2002 18:16: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 QQmyqi27862 for ; Mon, 22 Jul 2002 18:14:45 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqi12073 for ; Mon, 22 Jul 2002 18:14:45 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyqi12069 for ; Mon, 22 Jul 2002 18:14:45 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA08652; Mon, 22 Jul 2002 14:14:44 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA00913; Mon, 22 Jul 2002 14:14:44 -0400 (EDT) Message-Id: <200207221814.OAA00913@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: "'Eric Osborne'" , neil.2.harrison@bt.com, mpls@UU.NET Subject: Re: your mail In-reply-to: Your message of Mon, 22 Jul 2002 09:20:58 -0700. <4B6D09F3B826D411A67300D0B706EFDEB03744@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 22 Jul 2002 14:14:44 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Shahram> And you need deep packet parsing. A procedure wherein you make a decision based on the contents of the header would not generally be known as "deep packet parsing". From owner-mpls@UU.NET Mon Jul 22 14:26:56 2002 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 ESMTP id OAA25228 for ; Mon, 22 Jul 2002 14:26:55 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqj29176 for ; Mon, 22 Jul 2002 18:27:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqj27551; Mon, 22 Jul 2002 18:26:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqj25693 for mpls-outgoing; Mon, 22 Jul 2002 18:26:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyqj25683 for ; Mon, 22 Jul 2002 18:26: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 QQmyqj07820 for ; Mon, 22 Jul 2002 18:24:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqj25363 for ; Mon, 22 Jul 2002 18:24:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyqj25342 for ; Mon, 22 Jul 2002 18:24:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA09431 for ; Mon, 22 Jul 2002 14:24:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA02184 for mpls@uu.net; Mon, 22 Jul 2002 14:24:03 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyqj25317 for ; Mon, 22 Jul 2002 18:22:27 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 QQmyqj28600 for ; Mon, 22 Jul 2002 18:21:45 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqj28920 for ; Mon, 22 Jul 2002 18:21:44 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 QQmyqj28896 for ; Mon, 22 Jul 2002 18:21:43 GMT Received: (qmail 24978 invoked by uid 104); 22 Jul 2002 18:21:43 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 0.483337 secs); 22 Jul 2002 18:21:43 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 22 Jul 2002 18:21:42 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6MILgc08491; Mon, 22 Jul 2002 11:21:42 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 11:21:42 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03747@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'Eric Osborne'" , neil.2.harrison@bt.com, mpls@UU.NET Subject: RE: your mail Date: Mon, 22 Jul 2002 11:21:40 -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 A header that has no length field (as is in case of MPLS) requires parsing to find out the end of the header. -Shahram > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, July 22, 2002 2:15 PM > To: Shahram Davari > Cc: 'Eric Osborne'; neil.2.harrison@bt.com; mpls@UU.NET > Subject: Re: your mail > > > > Shahram> And you need deep packet parsing. > > A procedure wherein you make a decision based on the > contents of the header > would not generally be known as "deep packet parsing". > From owner-mpls@UU.NET Mon Jul 22 14:56:37 2002 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 ESMTP id OAA27900 for ; Mon, 22 Jul 2002 14:56:35 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyql10809 for ; Mon, 22 Jul 2002 18:57:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyql10260; Mon, 22 Jul 2002 18:57:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyql28467 for mpls-outgoing; Mon, 22 Jul 2002 18:57:03 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyql28459 for ; Mon, 22 Jul 2002 18:56:50 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 QQmyql19411 for ; Mon, 22 Jul 2002 18:56:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyql22555 for ; Mon, 22 Jul 2002 18:56:10 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyql22546 for ; Mon, 22 Jul 2002 18:56:10 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11941; Mon, 22 Jul 2002 14:55:59 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA07358; Mon, 22 Jul 2002 14:55:58 -0400 (EDT) Message-Id: <200207221855.OAA07358@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: "'Giles Heron'" , neil.2.harrison@bt.com, eosborne@cisco.com, mpls@UU.NET Subject: Re: your mail In-reply-to: Your message of Mon, 22 Jul 2002 10:34:37 -0700. <4B6D09F3B826D411A67300D0B706EFDEB03746@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 22 Jul 2002 14:55:58 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Shahram> The same thing could be said for IP tunnels: The edge router never Shahram> forwards the incoming packets without encapsulating them in IP Shahram> tunnel Of course, brilliant idea! Configure your edge routers so that they don't forward incoming IP packets, and then you don't have to worry about spoofed packets at all. I wonder why no one else ever thought of that. (Well, no, actually I don't wonder.) Shahram> The only advantage I see using LDP as compared to IP tunneling is Shahram> 16 bytes BW saving per packet That's because you're not thinking about the ways in which LSPs can be nested in each other. Start combining pseudowires, VPNs, traffic engineering, apply various aggregation strategies, and you can end up building a label stack with a few more than two label entries on it, and a label stack whose size changes as the packet goes about its travels. A strategy which says "just replace the top label with an IP header" isn't really coherent. You either have to replace all but the bottom label with an IP header, or you have to have hardware which can push/pop/replace on a stack some of whose entries are labels and some of whose entries are IP headers. Oh yes, what a simplification. A few nested IP headers on the stack and your high speed hardware probably won't even be able to see all the headers! And the resulting packet size increase is not 16 bytes, but 16 times n. (Even 16 is not to be laughed off, because of its effect on the packet MTU.) There are quite a few advantages to having a single, general, flexible, and efficient encapsulation protocol which can be put to a variety of different uses. Frankly, I do not believe this thread is being pursued for technical reasons. To wit: Eric> A procedure wherein you make a decision based on the contents of the Eric> header would not generally be known as "deep packet parsing". Shahram> A header that has no length field (as is in case of MPLS) requires Shahram> parsing to find out the end of the header. Most forwarding procedures require understanding the header formats and being able to find the header fields. I cannot believe that anyone seriously doesn't understand the difference between parsing the header and "deep packet parsing". It's hard to take this seriously. I know, I know, if Y.1711 doesn't apply to the world, then it's the world that has to change, right? I have heard that there are vendors who are afraid of getting stuck with a bunch of Y.1711 chips if it turns out that Y.1711 is not adopted, but I'm sure you wouldn't want the standards process polluted with such irrelevancies. From owner-mpls@UU.NET Mon Jul 22 15:08:45 2002 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 ESMTP id PAA28824 for ; Mon, 22 Jul 2002 15:08:44 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqm03689 for ; Mon, 22 Jul 2002 19:09:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqm02132; Mon, 22 Jul 2002 19:08:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqm20239 for mpls-outgoing; Mon, 22 Jul 2002 19:08:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyqm20234 for ; Mon, 22 Jul 2002 19:08: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 QQmyqm29251 for ; Mon, 22 Jul 2002 19:08:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqm01814 for ; Mon, 22 Jul 2002 19:08:08 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyqm01807 for ; Mon, 22 Jul 2002 19:08:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA12930 for ; Mon, 22 Jul 2002 15:08:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA09176 for mpls@uu.net; Mon, 22 Jul 2002 15:08:07 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyqm19978 for ; Mon, 22 Jul 2002 19:07:09 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 QQmyqm25590 for ; Mon, 22 Jul 2002 19:07:01 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqm21925 for ; Mon, 22 Jul 2002 19:07:01 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmyqm21918 for ; Mon, 22 Jul 2002 19:07:00 GMT Received: (qmail 29962 invoked by uid 104); 22 Jul 2002 19:07:00 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 0.481203 secs); 22 Jul 2002 19:07:00 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 22 Jul 2002 19:06:59 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6MJ6wc11165; Mon, 22 Jul 2002 12:06:59 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 12:06:59 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03749@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'Giles Heron'" , neil.2.harrison@bt.com, eosborne@cisco.com, mpls@UU.NET Subject: RE: your mail Date: Mon, 22 Jul 2002 12:06:57 -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 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, July 22, 2002 2:56 PM > To: Shahram Davari > Cc: 'Giles Heron'; neil.2.harrison@bt.com; eosborne@cisco.com; > mpls@UU.NET > Subject: Re: your mail > > > > Shahram> The same thing could be said for IP tunnels: The > edge router never > Shahram> forwards the incoming packets without > encapsulating them in IP > Shahram> tunnel > > Of course, brilliant idea! Configure your edge routers so > that they don't > forward incoming IP packets, and then you don't have to > worry about spoofed > packets at all. I wonder why no one else ever thought of > that. (Well, no, > actually I don't wonder.) This was just a theoretical suggestion. You could always do ACL. > > Shahram> The only advantage I see using LDP as compared to > IP tunneling is > Shahram> 16 bytes BW saving per packet > > That's because you're not thinking about the ways in > which LSPs can be > nested in each other. Start combining pseudowires, > VPNs, traffic > engineering, apply various aggregation strategies, and > you can end up > building a label stack with a few more than two label > entries on it, and a > label stack whose size changes as the packet goes about > its travels. I haven't seen that in PWE3 or PPVPN yet. A > strategy which says "just replace the top label with an IP > header" isn't > really coherent. You either have to replace all but the > bottom label with > an IP header, or you have to have hardware which can > push/pop/replace on a > stack some of whose entries are labels and some of whose > entries are IP > headers. Oh yes, what a simplification. A few nested IP > headers on the > stack and your high speed hardware probably won't even be > able to see all > the headers! And the resulting packet size increase is not > 16 bytes, but 16 > times n. (Even 16 is not to be laughed off, because of its > effect on the > packet MTU.) > > There are quite a few advantages to having a single, > general, flexible, and > efficient encapsulation protocol which can be put to a > variety of different > uses. > > Frankly, I do not believe this thread is being pursued > for technical > reasons. To wit: Let's stick to the issue. > > Eric> A procedure wherein you make a decision based on the > contents of the > Eric> header would not generally be known as "deep packet parsing". > > Shahram> A header that has no length field (as is in case of > MPLS) requires > Shahram> parsing to find out the end of the header. > > Most forwarding procedures require understanding the > header formats and > being able to find the header fields. I cannot > believe that anyone > seriously doesn't understand the difference between parsing > the header and > "deep packet parsing". It's hard to take this seriously. "Deep" or "not deep" you need potentially unlimited packet parsing (uo to MTU size), since as you said the number of labels are not limited to 2. > > I know, I know, if Y.1711 doesn't apply to the world, then > it's the world > that has to change, right? What is the relevance? > > I have heard that there are vendors who are afraid of > getting stuck with a > bunch of Y.1711 chips if it turns out that Y.1711 is not > adopted, but I'm > sure you wouldn't want the standards process > polluted with such > irrelevancies. Please stick to the technical issue. -Shahram > > > > > > From owner-mpls@UU.NET Mon Jul 22 15:16:54 2002 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 ESMTP id PAA29572 for ; Mon, 22 Jul 2002 15:16:54 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqn16931 for ; Mon, 22 Jul 2002 19:17:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqn15617; Mon, 22 Jul 2002 19:17:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqn22020 for mpls-outgoing; Mon, 22 Jul 2002 19:16:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyqn22011 for ; Mon, 22 Jul 2002 19:16:41 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 QQmyqn01706 for ; Mon, 22 Jul 2002 19:15:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqn13857 for ; Mon, 22 Jul 2002 19:15:16 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyqn13833 for ; Mon, 22 Jul 2002 19:15:15 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA13456; Mon, 22 Jul 2002 15:15:13 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA10699; Mon, 22 Jul 2002 15:15:13 -0400 (EDT) Message-Id: <200207221915.PAA10699@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: "'Giles Heron'" , neil.2.harrison@bt.com, eosborne@cisco.com, mpls@UU.NET Subject: Re: your mail In-reply-to: Your message of Mon, 22 Jul 2002 12:06:57 -0700. <4B6D09F3B826D411A67300D0B706EFDEB03749@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 22 Jul 2002 15:15:13 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Shahram> "Deep" or "not deep" you need potentially unlimited packet parsing Shahram> (uo to MTU size), since as you said the number of labels are not Shahram> limited to 2. To the MTU size? That would be for the case where the entire packet contains the MPLS label stack and there is no payload? As has been made clear repeatedly, you can hash on any label, you just get more fine-grained load balancing the further down you go. So generally you would look at the bottom-most label that you can easily see, given your particular forwarding architecture. From owner-mpls@UU.NET Mon Jul 22 15:26:00 2002 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 ESMTP id PAA00582 for ; Mon, 22 Jul 2002 15:25:59 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqb19598; Mon, 22 Jul 2002 16:18:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqb14063 for mpls-outgoing; Mon, 22 Jul 2002 16:17:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyqb14054 for ; Mon, 22 Jul 2002 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 QQmyqb00278 for ; Mon, 22 Jul 2002 16:17:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqb24976 for ; Mon, 22 Jul 2002 16:17:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyqb24968 for ; Mon, 22 Jul 2002 16:17:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA29483 for ; Mon, 22 Jul 2002 12:17:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA13633 for mpls@uu.net; Mon, 22 Jul 2002 12:17:05 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyqb14012 for ; Mon, 22 Jul 2002 16:16: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 QQmyqb07814 for ; Mon, 22 Jul 2002 16:16:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqb24418 for ; Mon, 22 Jul 2002 16:16: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 QQmyqb24408 for ; Mon, 22 Jul 2002 16:16:15 GMT Received: (qmail 14125 invoked by uid 104); 22 Jul 2002 16:16:14 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 0.728077 secs); 22 Jul 2002 16:16:14 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 22 Jul 2002 16:16:13 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6MGG2c08023; Mon, 22 Jul 2002 09:16:13 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 09:16:02 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03743@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Gray, Eric'" , "'erosen@cisco.com'" Cc: "'mpls@UU.NET '" Subject: RE: your mail Date: Mon, 22 Jul 2002 09:16:00 -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 To find the bottom of the stack you need parsing. -Shahram > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Tuesday, July 02, 2002 12:36 PM > To: 'erosen@cisco.com' > Cc: Shahram Davari; 'mpls@UU.NET ' > Subject: RE: your mail > > > Eric, > > I'm guessing that some hardware implementations might be > optimized around the need to process at most K labels. For any > such implementation, being required to possibly look at the Nth > label - where N is the number of labels in the stack and N may > be greater than K - may be virtually indistinguishable from > being required to parse the entire packet. > > In such cases, the engineers have to take a hard look at > what they might use as a fall back for the N > K case and then > do some hard analysis about whether or not such a fall back is > guaranteed to work in all cases. Because the consequences of > not getting the right answer after all this hard looking and > analysis are systemic at the network level, it might be useful > if this was hashed out publicly in a little more detail - don't > you think? :-) > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, July 02, 2002 11:02 AM > To: Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; > 'mpls@UU.NET ' > Subject: Re: your mail > > > SD=> So you do more than one lookup- so what? so you need to > parse the whole > SD=> packet in the core-so what? so you need to keep state in > the core, > > Please pay attention. > > There is not more than one lookup; doing the hash does not > require looking > anything up. > > Finding the bottom label does not involve parsing the whole packet. > > There is no state kept in the core. > > SD=> so you have no longer a simple label swap > > It is true that the essence of load balancing over equal > cost paths is that > the outgoing interface is not chosen solely on the basis of > the top label. > So? > > SD=> MPLS was designed to have simple forwarding. Hashing > takes it to new > SD=> levels of simplification never seen before. > > You might take a peek at section 3.12 of RFC 3031. > From owner-mpls@UU.NET Mon Jul 22 15:41:01 2002 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 ESMTP id PAA02108 for ; Mon, 22 Jul 2002 15:41:01 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqo09045 for ; Mon, 22 Jul 2002 19:41:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqo07672; Mon, 22 Jul 2002 19:41:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqo23669 for mpls-outgoing; Mon, 22 Jul 2002 19:41:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyqo23635 for ; Mon, 22 Jul 2002 19:41: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 QQmyqo10031 for ; Mon, 22 Jul 2002 19:39:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqo06578 for ; Mon, 22 Jul 2002 19:39:50 GMT Received: from ls405.hinet.hr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ls405.hinet.hr [195.29.150.97]) id QQmyqo06566 for ; Mon, 22 Jul 2002 19:39:49 GMT Received: from ls401.hinet.hr (ls401.hinet.hr [195.29.150.2]) by ls405.hinet.hr (0.0.0/8.11.6) with ESMTP id g6MJdmw24932 for ; Mon, 22 Jul 2002 21:39:48 +0200 Received: from strippy (ad2-m64.net.hinet.hr [195.29.130.64]) by ls401.hinet.hr (8.11.6/8.11.3) with SMTP id g6MJdmj19743 for ; Mon, 22 Jul 2002 21:39:48 +0200 Message-ID: <001f01c231b8$2ab7fe80$0100a8c0@strippy> From: "Neven Milinovic" To: Subject: Routing protocols implemented in ns-2 Date: Mon, 22 Jul 2002 21:44:16 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C231C8.ED867F30" 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_001C_01C231C8.ED867F30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to implement Minimum Interference Routing Algorithm (MIRA) = and Profile Based Routing (PBR) in ns-2 with applications to Traffic = Engineering in MPLS. My question is are there any source codes already = available (Tcl, c++). I would appreciate any kind of help or discussion = on the above topic. Neven Milinovic neven.milinovic@zg.hinet.hr ------=_NextPart_000_001C_01C231C8.ED867F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am trying to implement Minimum = Interference=20 Routing Algorithm (MIRA) and Profile Based Routing (PBR) in ns-2 with=20 applications to Traffic Engineering in MPLS. My question is are there = any source=20 codes already available (Tcl, c++). I would appreciate any kind of = help or=20 discussion on the above topic.
 
 
Neven Milinovic
neven.milinovic@zg.hinet.hr
------=_NextPart_000_001C_01C231C8.ED867F30-- From owner-mpls@UU.NET Mon Jul 22 15:46:52 2002 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 ESMTP id PAA02770 for ; Mon, 22 Jul 2002 15:46:52 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqp18417 for ; Mon, 22 Jul 2002 19:45:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqp17693; Mon, 22 Jul 2002 19:45:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqp24183 for mpls-outgoing; Mon, 22 Jul 2002 19:45:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyqo23909 for ; Mon, 22 Jul 2002 19:44:59 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 QQmyqo01367 for ; Mon, 22 Jul 2002 19:43:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqo13901 for ; Mon, 22 Jul 2002 19:43: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 QQmyqo13875 for ; Mon, 22 Jul 2002 19:43:53 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MJhle14746 for ; Mon, 22 Jul 2002 15:43:47 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 15:43:46 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E601BA4E0D@zcard0ke.ca.nortel.com> From: "Stephen Shew" To: MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Mon, 22 Jul 2002 15:43:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231B5.BD090CE6" 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_01C231B5.BD090CE6 Content-Type: text/plain; charset="iso-8859-1" I would like to speak against the proposal to make CR-LDP informational. Signalling is not the only function in IP in which there are multiple (standards track) protocols. Why insist on converging to one? Also, CR-LDP is found in other specifications (e.g., OIF UNI 1.0, ITU-T Y.1310) whose bodies want to continue evolving its functionality. In particular, the ITU-T is using GMPLS CR-LDP in its draft recommendation G.7713.3 (CR-LDP based signalling for ASON). ------_=_NextPart_001_01C231B5.BD090CE6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: initiating a discussion on mpls singaling protocols

I would like to speak against the proposal to make = CR-LDP informational.  Signalling is not the only function in IP = in which there are multiple (standards track) protocols.  Why = insist on converging to one?  Also, CR-LDP is found in other = specifications (e.g., OIF UNI 1.0, ITU-T Y.1310) whose bodies want to = continue evolving its functionality.  In particular, the ITU-T is = using GMPLS CR-LDP in its draft recommendation G.7713.3 (CR-LDP based = signalling for ASON).

------_=_NextPart_001_01C231B5.BD090CE6-- From owner-mpls@UU.NET Mon Jul 22 15:51:13 2002 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 ESMTP id PAA03127 for ; Mon, 22 Jul 2002 15:51:13 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqp16859 for ; Mon, 22 Jul 2002 19:52:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqp14395; Mon, 22 Jul 2002 19:50:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqp24622 for mpls-outgoing; Mon, 22 Jul 2002 19:50:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyqp24615 for ; Mon, 22 Jul 2002 19:50: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 QQmyqp02741 for ; Mon, 22 Jul 2002 19:50:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqp28177 for ; Mon, 22 Jul 2002 19:50:19 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmyqp28173 for ; Mon, 22 Jul 2002 19:50:19 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1LGF>; Mon, 22 Jul 2002 15:50:19 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267164@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: Loa Andersson Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Mon, 22 Jul 2002 15:50:18 -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 Loa, An amusing thread. I'm not sure whether the topic was actually a typo, or a mental transmission 'slip' resulting in the "MPLS sing-along" it seems to have inspired. :-) I am not sure that Informational is the right way to go. Perhaps Experimental or Historical is better. I think it is important to understand exactly what is intended by this proposal. As I understand it, making one of the two proposals informational is intended to reduce the effort required to implement MPLS and to reduce the work needed to make additional signaling extension proposals into standards. These are more concrete 'corollary' effects of the abstract goal of having a single 'standard' signaling approach. Reducing effort is good. However, changing a Proposed Standard to an Informational RFC seems unprecedented. Does anyone know of a precedent for this? Hasn't it previously been the case that - once we have decided not to treat a proposed standard as a standard any more - we change it to an Historical (or Experimental) RFC? If this has been done before, how well did it work that time? One reason for choosing to go the Informational route is because we would like to focus on development of standards, implementations and deployment of a single MPLS signaling protocol (RSVP-TE) without necessarily preventing parallel development (CR-LDP) as non-standard, information only, effort. Will it actually work this way, or will we still have to read drafts in the MPLS (and/or) CCAMP working groups for these parallel efforts? It seems likely that these efforts will continue. Are we saying - as a working group - we will no longer need to concern ourselves with CR-LDP related work? If so, then we should make this intention clear. We will also have to do some work to make this happen, since we will have to define how IANA allocates numbers for CR-LDP extensions without WG participation (currently, IETF consensus action is required - which generally means WG participation). If the WG continues to need to be involved, then simply declaring CR-LDP to be Informational doesn't change anything in any useful sort of way. It won't change who implements it, it won't change who deploys it and it won't change who has to work on it in the IETF. If the real goal is to simply make the intentions of the IETF clearer, then I believe is accomplished better by making CR-LDP a (set of) Experimental RFC(s). Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com P.S. - not responding to Robert - his was just the last post that seemed to stick to the topic. -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com] Sent: Monday, July 22, 2002 9:08 AM To: Loa Andersson Cc: Hummel Heinrich; mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols Hi Loa, You can add my vote: CRLDP experiment to be declared informational, RSVP-TE proceeds on standards track. R. > Loa Andersson wrote: > > Heinrich, > > in my opinion the question is very clearly stated - is there support for > us (the ietf) to move the cr-ldp from standard track to informational. > We're "speaking for the ietf", it is more a matter of what we say ;) > > All, > > As usual we are trying to reach a rough consensus. Everyone (i.e. the > mpls wg) can help create this consensus by answering the question > above. > > Especially it will be helpful if you were involved in specifying the > mpls protocols, have implemented or deployed (SP) those protocols, and > take the time to respond. > > I will be ready to give the first extensive tally mid this week. > Currently the count is > yes: 30 no: 7, > if you normalize those e.g. by counting each company once it is > yes: 21 no: 4 > > Disclaimer: Given that I've managed to decipher the sometimes cryptic > mails correctly :o) > > /Loa > > Hummel Heinrich wrote: > > > I think, the IETF can only speak for itself. There may be other standardization > > >bodies (ITU-T, MPLS Forum) which may fill > > the gap. > > > > Heinrich Hummel > > Siemens AG > > > > -- > 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 Jul 22 16:32:39 2002 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 ESMTP id QAA06516 for ; Mon, 22 Jul 2002 16:32:39 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqs17416 for ; Mon, 22 Jul 2002 20:33:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqs16075; Mon, 22 Jul 2002 20:33:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqs19400 for mpls-outgoing; Mon, 22 Jul 2002 20:32:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyqs19395 for ; Mon, 22 Jul 2002 20:32: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 QQmyqs01996 for ; Mon, 22 Jul 2002 20:31:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqs24332 for ; Mon, 22 Jul 2002 20:31:13 GMT Received: from panorama.Covad.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host-66-134-72-15.covad.com [66.134.72.15] (may be forged)) id QQmyqs24322 for ; Mon, 22 Jul 2002 20:31:12 GMT Received: from SJCXMB01.corp.covad.com (sjcxmb01b.corp.covad.com [172.16.2.78]) by panorama.Covad.COM (8.9.3/8.8.7) with ESMTP id NAA12691; Mon, 22 Jul 2002 13:27:14 -0700 (PDT) Received: by sjcxmb01.corp.covad.com with Internet Mail Service (5.5.2653.19) id <37JZPK6T>; Mon, 22 Jul 2002 13:31:03 -0700 Message-ID: <336655BB7E20D411900200508BC2710D0CF779E7@sjcxmb02.corp.covad.com> From: "Hsu, Vicky" To: "'Gray, Eric '" , "''Shahram Davari' '" Cc: "''mpls@UU.NET ' '" Subject: RE: your mail Date: Mon, 22 Jul 2002 13: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 Hi: I think the thread has been long enough and the topics interesting enough to spawn off to other new, specific and meaningful subject lines. So that it is easier to keep track of the categories and not mistake for potential junk mail by reading the subject of "your mail" Just a thought. Regards - Vicky HSU -----Original Message----- From: Gray, Eric To: 'Shahram Davari' Cc: 'mpls@UU.NET ' Sent: 7/22/02 9:36 AM Subject: RE: your mail Shahram, Not sure you meant this as a reply to me. Technically, you are correct - though the parsing operation associated with finding the bottom of stack is trivial, consisting of a 'grammar' in which only one bit per word is not noise. Moreover, Eric Rosen already responded to me on the mailing list with an answer I felt was sufficient - i.e. - bottom of stack, or last label looked at (in the event that the bottom of stack bit is not set in any label 'looked at'). Having hashed this out to my own satisfaction on the mailing list, I was hoping to let this thread expire. :-) Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Monday, July 22, 2002 12:16 PM To: 'Gray, Eric'; 'erosen@cisco.com' Cc: 'mpls@UU.NET ' Subject: RE: your mail To find the bottom of the stack you need parsing. -Shahram > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Tuesday, July 02, 2002 12:36 PM > To: 'erosen@cisco.com' > Cc: Shahram Davari; 'mpls@UU.NET ' > Subject: RE: your mail > > > Eric, > > I'm guessing that some hardware implementations might be > optimized around the need to process at most K labels. For any > such implementation, being required to possibly look at the Nth > label - where N is the number of labels in the stack and N may > be greater than K - may be virtually indistinguishable from > being required to parse the entire packet. > > In such cases, the engineers have to take a hard look at > what they might use as a fall back for the N > K case and then > do some hard analysis about whether or not such a fall back is > guaranteed to work in all cases. Because the consequences of > not getting the right answer after all this hard looking and > analysis are systemic at the network level, it might be useful > if this was hashed out publicly in a little more detail - don't > you think? :-) > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, July 02, 2002 11:02 AM > To: Shahram Davari > Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; > 'mpls@UU.NET ' > Subject: Re: your mail > > > SD=> So you do more than one lookup- so what? so you need to > parse the whole > SD=> packet in the core-so what? so you need to keep state in > the core, > > Please pay attention. > > There is not more than one lookup; doing the hash does not > require looking > anything up. > > Finding the bottom label does not involve parsing the whole packet. > > There is no state kept in the core. > > SD=> so you have no longer a simple label swap > > It is true that the essence of load balancing over equal > cost paths is that > the outgoing interface is not chosen solely on the basis of > the top label. > So? > > SD=> MPLS was designed to have simple forwarding. Hashing > takes it to new > SD=> levels of simplification never seen before. > > You might take a peek at section 3.12 of RFC 3031. > From owner-mpls@UU.NET Mon Jul 22 16:50:57 2002 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 ESMTP id QAA08059 for ; Mon, 22 Jul 2002 16:50:56 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqt09654 for ; Mon, 22 Jul 2002 20:51:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqt08213; Mon, 22 Jul 2002 20:50:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqt20969 for mpls-outgoing; Mon, 22 Jul 2002 20:50:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyqt20920 for ; Mon, 22 Jul 2002 20:50: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 QQmyqt27757 for ; Mon, 22 Jul 2002 20:50:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqt07538 for ; Mon, 22 Jul 2002 20:50:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyqt07522 for ; Mon, 22 Jul 2002 20:50:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA20635 for ; Mon, 22 Jul 2002 16:50:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA23221 for mpls@uu.net; Mon, 22 Jul 2002 16:50:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyqt20877 for ; Mon, 22 Jul 2002 20:48: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 QQmyqt11382 for ; Mon, 22 Jul 2002 20:47:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqt03755 for ; Mon, 22 Jul 2002 20:47:52 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 QQmyqt03745 for ; Mon, 22 Jul 2002 20:47:51 GMT Received: (qmail 13497 invoked by uid 104); 22 Jul 2002 20:47:50 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 1.272943 secs); 22 Jul 2002 20:47:50 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 22 Jul 2002 20:47:49 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6MKlmc16404; Mon, 22 Jul 2002 13:47:49 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 13:47:49 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0374A@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'Giles Heron'" , neil.2.harrison@bt.com, eosborne@cisco.com, mpls@UU.NET Subject: RE: your mail Date: Mon, 22 Jul 2002 13:47:47 -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 Eric, If I understand you correctly, what you are saying is that assume a number such as "N", and hash the Nth label, regardless of whether it is the real bottom-most label (i.e. with S=1) or not. If so then: 1) How do you know that at least N labels exist in all packets? 2) The Nth label can not identify a flow by itself, rather you need to hash the whole label stack from the top, up to the Nth label, in order to identify a flow. 3) I have heard that some implementations hash the IP header too? How does that fit in to your model? How do you know that the payload is IP? And don't you need to find the real bottom of stack (S=1) in order to include the IP header in the hash? Yours, -Shahram > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, July 22, 2002 3:15 PM > To: Shahram Davari > Cc: 'Giles Heron'; neil.2.harrison@bt.com; eosborne@cisco.com; > mpls@UU.NET > Subject: Re: your mail > > > > Shahram> "Deep" or "not deep" you need potentially unlimited > packet parsing > Shahram> (uo to MTU size), since as you said the number of > labels are not > Shahram> limited to 2. > > To the MTU size? That would be for the case where the > entire packet > contains the MPLS label stack and there is no payload? > > As has been made clear repeatedly, you can hash on any > label, you just get > more fine-grained load balancing the further down you go. > So generally you > would look at the bottom-most label that you can easily > see, given your > particular forwarding architecture. > > > > From owner-mpls@UU.NET Mon Jul 22 17:07:24 2002 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 ESMTP id RAA09334 for ; Mon, 22 Jul 2002 17:07:23 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqu17926 for ; Mon, 22 Jul 2002 21:08:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqu16595; Mon, 22 Jul 2002 21:07:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqu04757 for mpls-outgoing; Mon, 22 Jul 2002 21:07:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyqu04725 for ; Mon, 22 Jul 2002 21:07: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 QQmyqu14180 for ; Mon, 22 Jul 2002 21:06:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqu23711 for ; Mon, 22 Jul 2002 21:06:18 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmyqu23706 for ; Mon, 22 Jul 2002 21:06:18 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1LM9>; Mon, 22 Jul 2002 17:06:18 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267169@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Shahram Davari'" , "'erosen@cisco.com'" Cc: mpls@UU.NET Subject: RE: your mail Date: Mon, 22 Jul 2002 17:06:17 -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 Shahram, There is nothing to be fearful, uncertain or doubtful about here. If an implementation can handle up to N labels, then it can use either the bottom-of-stack label or the Nth label for a hash key. With respect to flows, this will be consistent. It will also tend to give the greatest degree of entropy in hashing possible for a specific labeled packet. It doesn't guarantee even distribution any worse than any other 'guess'. Use of the IP header as well is a) unnecessary, b) unhelpful and c) not a good idea. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Monday, July 22, 2002 4:48 PM To: 'erosen@cisco.com' Cc: 'Giles Heron'; neil.2.harrison@bt.com; eosborne@cisco.com; mpls@UU.NET Subject: RE: your mail Hi Eric, If I understand you correctly, what you are saying is that assume a number such as "N", and hash the Nth label, regardless of whether it is the real bottom-most label (i.e. with S=1) or not. If so then: 1) How do you know that at least N labels exist in all packets? 2) The Nth label can not identify a flow by itself, rather you need to hash the whole label stack from the top, up to the Nth label, in order to identify a flow. 3) I have heard that some implementations hash the IP header too? How does that fit in to your model? How do you know that the payload is IP? And don't you need to find the real bottom of stack (S=1) in order to include the IP header in the hash? Yours, -Shahram > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, July 22, 2002 3:15 PM > To: Shahram Davari > Cc: 'Giles Heron'; neil.2.harrison@bt.com; eosborne@cisco.com; > mpls@UU.NET > Subject: Re: your mail > > > > Shahram> "Deep" or "not deep" you need potentially unlimited > packet parsing > Shahram> (uo to MTU size), since as you said the number of > labels are not > Shahram> limited to 2. > > To the MTU size? That would be for the case where the > entire packet > contains the MPLS label stack and there is no payload? > > As has been made clear repeatedly, you can hash on any > label, you just get > more fine-grained load balancing the further down you go. > So generally you > would look at the bottom-most label that you can easily > see, given your > particular forwarding architecture. > > > > From owner-mpls@UU.NET Mon Jul 22 17:58:28 2002 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 ESMTP id RAA13857 for ; Mon, 22 Jul 2002 17:58:28 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqx28874 for ; Mon, 22 Jul 2002 21:59:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyqx27526; Mon, 22 Jul 2002 21:58:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyqx17766 for mpls-outgoing; Mon, 22 Jul 2002 21:58:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyqx17761 for ; Mon, 22 Jul 2002 21:58: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 QQmyqx01232 for ; Mon, 22 Jul 2002 21:58:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyqx26691 for ; Mon, 22 Jul 2002 21:58:04 GMT Received: from blooper.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmyqx26684 for ; Mon, 22 Jul 2002 21:58:03 GMT Received: from utfors.se ([195.58.105.102]) by blooper.utfors.se (Utfors AB) with ESMTP id g6MLw15F023763; Mon, 22 Jul 2002 23:58:01 +0200 (MEST) Message-ID: <3D3C7FE8.2000807@utfors.se> Date: Mon, 22 Jul 2002 23:58:00 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "Gray, Eric" CC: mpls@UU.NET Subject: spelling - initiating a discussion on mpls singaling protocols References: <1117F7D44159934FB116E36F4ABF221B02267164@celox-ma1-ems1.celoxnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Eric, sorry - it would have been funier if it hadn't been a typo, but when it comes to my spelling it gave my teachers gray hair already in school, and it has become a lot worse since ... /Loa Gray, Eric wrote: > Loa, > > An amusing thread. I'm not sure whether the > topic was actually a typo, or a mental transmission > 'slip' resulting in the "MPLS sing-along" it seems > to have inspired. :-) 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 Jul 22 19:02:05 2002 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 ESMTP id TAA19091 for ; Mon, 22 Jul 2002 19:02:05 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyrc28116 for ; Mon, 22 Jul 2002 23:03:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyrc27088; Mon, 22 Jul 2002 23:02:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyrc25826 for mpls-outgoing; Mon, 22 Jul 2002 23:02:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyrc25775 for ; Mon, 22 Jul 2002 23:02: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 QQmyrc26205 for ; Mon, 22 Jul 2002 23:01:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyrc16723 for ; Mon, 22 Jul 2002 23:01:43 GMT Received: from pulsar.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cbshost-12-107-16-205.sbcox.net [12.107.16.205]) id QQmyrc16700 for ; Mon, 22 Jul 2002 23:01:43 GMT Received: by pulsar.chromisys.com with Internet Mail Service (5.5.2655.55) id ; Mon, 22 Jul 2002 15:53:15 -0700 Message-ID: From: Jonathan Lang To: "'Loa Andersson'" Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Mon, 22 Jul 2002 15:53:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 TAA19091 I agree with the proposal to make cr-ldp informational and progress RSVP-TE as standards track. Thanks, Jonathan > -----Original Message----- > From: Loa Andersson [mailto:loa.andersson@utfors.se] > Sent: Monday, July 22, 2002 5:23 AM > To: Hummel Heinrich > Cc: mpls@UU.NET > Subject: Re: initiating a discussion on mpls singaling protocols > > > Heinrich, > > in my opinion the question is very clearly stated - is there > support for > us (the ietf) to move the cr-ldp from standard track to informational. > We're "speaking for the ietf", it is more a matter of what we say ;) > > All, > > As usual we are trying to reach a rough consensus. Everyone (i.e. the > mpls wg) can help create this consensus by answering the question > above. > > Especially it will be helpful if you were involved in specifying the > mpls protocols, have implemented or deployed (SP) those protocols, and > take the time to respond. > > I will be ready to give the first extensive tally mid this week. > Currently the count is > yes: 30 no: 7, > if you normalize those e.g. by counting each company once it is > yes: 21 no: 4 > > Disclaimer: Given that I've managed to decipher the sometimes cryptic > mails correctly :o) > > /Loa > > Hummel Heinrich wrote: > > > I think, the IETF can only speak for itself. There may be > other standardization > > >bodies (ITU-T, MPLS Forum) which may fill > > the gap. > > > > Heinrich Hummel > > Siemens AG > > > > > -- > 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 Tue Jul 23 01:12:18 2002 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 ESMTP id BAA19716 for ; Tue, 23 Jul 2002 01:12:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysa06581 for ; Tue, 23 Jul 2002 05:13:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmysa05350; Tue, 23 Jul 2002 05:12:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmysa12254 for mpls-outgoing; Tue, 23 Jul 2002 05:12:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmysa12249 for ; Tue, 23 Jul 2002 05:12:12 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 QQmysa01102 for ; Tue, 23 Jul 2002 05:12:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysa08336 for ; Tue, 23 Jul 2002 05:12:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmysa08325 for ; Tue, 23 Jul 2002 05:12:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA16499 for ; Tue, 23 Jul 2002 01:12:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA15017 for mpls@uu.net; Tue, 23 Jul 2002 01:12:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmysa11865 for ; Tue, 23 Jul 2002 05:10: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 QQmysa06011 for ; Tue, 23 Jul 2002 05:10:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysa07614 for ; Tue, 23 Jul 2002 05:10:30 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmysa07603 for ; Tue, 23 Jul 2002 05:10:29 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 10:46:21 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA064C326A@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: nagabhushana.ramaswamy@wipro.com, "Thomas D. Nadeau" Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 10:42:35 +0530 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 One more point here - A customer/end-user is only going to ask for TE LSPs/quality of service. I wonder if any end user would name the specific protocol, or he would care if RSVP-TE or CR LDP is used as long as he gets the features wants. When two protocols can give the same features, I think their performance should be the key. Analysis such as those done by Heinrich would throw more light on the solution. Vijay On Mon, 22 Jul 2002, Thomas D. Nadeau wrote: > > Difficulty of implementation is of little concern at this point > in the > game. The point is that customers want to pay for these features so > vendors that want to sell routers will implement whatever their customers > tell them to. > > --Tom Of Course we never have an issue with this, after all money is what can have a final say in any business. But at the service level what is that, that makes RSVP-TE a better option!! That being the case we "have" to look at the other aspects of ease of implementation (which may be insignificant today, but I am not sure we may still have some implementations in future), support for future enhancements, and the whole lot of product life cycle management issues. Just my thought.... regards Bhushana > > > > > ------------------------------------------------------------------------ > Mathematics is the supreme nostalgia of our time. > > From owner-mpls@UU.NET Tue Jul 23 03:23:26 2002 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 ESMTP id DAA01827 for ; Tue, 23 Jul 2002 03:23:24 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysj22724 for ; Tue, 23 Jul 2002 07:24:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmysj21517; Tue, 23 Jul 2002 07:23:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmysj04833 for mpls-outgoing; Tue, 23 Jul 2002 07:23:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmysj04828 for ; Tue, 23 Jul 2002 07:23: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 QQmysj07809 for ; Tue, 23 Jul 2002 07:23:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysj21228 for ; Tue, 23 Jul 2002 07:23:14 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 QQmysj21187 for ; Tue, 23 Jul 2002 07:23:11 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g6N7MxC08087; Tue, 23 Jul 2002 12:53:01 +0530 (IST) Received: from sasken.com (pcz-soumen.sasken.com [10.1.64.68]) by sunsv2.sasken.com (8.11.6/8.11.6) with ESMTP id g6N7MxP17645; Tue, 23 Jul 2002 12:52:59 +0530 (IST) Message-ID: <3D3D052F.F39937DE@sasken.com> Date: Tue, 23 Jul 2002 12:56:40 +0530 From: Soumen Sarkar X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Loa Andersson , mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <3D3BF90C.5060405@utfors.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Loa, The response so far heavily indicated for RSVP-TE ( obviously not because of the merits of RSVP-TE over LDP-CR ). If one has to accept the basic ground-rule, which is, how many major players are pushing for RSVP-TE, one would blindly vote for RSVP-TE. The more esoteric view, which is, single signaling protocol would help everyone to concentrate better in addressing unresolved problems in MPLS, is also appreciably reasonable to accept. But looking from holistic perspective, is it not too premature at this time to conclude on this issue unilaterally (even if there is 3/4 majority in favour if it ) when this particular issue affects other standard bodies too ? We know for sure, OIF is still tracking LDP-CR as an alternative signaling protocol for optical control plane. Are we not pushing something without even considering future implication of it ? One might say, we are not stopping anyone to use LDP-CR as such. But none would disagree that making IETF take a stand itself is deterrant enough and if not that much, it is bound to create conflict of interest between IETF and others. Are we really ready for this ? IETF traditionally has been more a forum for vouching technical solutions, not imposing it. Are we deviating from that path with full understanding ? -best regards, Soumen Loa Andersson wrote: > Heinrich, > > in my opinion the question is very clearly stated - is there support for > us (the ietf) to move the cr-ldp from standard track to informational. > We're "speaking for the ietf", it is more a matter of what we say ;) > > All, > > As usual we are trying to reach a rough consensus. Everyone (i.e. the > mpls wg) can help create this consensus by answering the question > above. > > Especially it will be helpful if you were involved in specifying the > mpls protocols, have implemented or deployed (SP) those protocols, and > take the time to respond. > > I will be ready to give the first extensive tally mid this week. > Currently the count is > yes: 30 no: 7, > if you normalize those e.g. by counting each company once it is > yes: 21 no: 4 > > Disclaimer: Given that I've managed to decipher the sometimes cryptic > mails correctly :o) > > /Loa > > Hummel Heinrich wrote: > > > I think, the IETF can only speak for itself. There may be other standardization > > >bodies (ITU-T, MPLS Forum) which may fill > > the gap. > > > > Heinrich Hummel > > Siemens AG > > > > -- > 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 Tue Jul 23 03:32:15 2002 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 ESMTP id DAA02017 for ; Tue, 23 Jul 2002 03:32:14 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysk06927 for ; Tue, 23 Jul 2002 07:33:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmysk05400; Tue, 23 Jul 2002 07:32:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmysk05363 for mpls-outgoing; Tue, 23 Jul 2002 07:31:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmysk05358 for ; Tue, 23 Jul 2002 07:31:43 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 QQmysk00868 for ; Tue, 23 Jul 2002 07:30:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysk04682 for ; Tue, 23 Jul 2002 07:30:08 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmysk04676 for ; Tue, 23 Jul 2002 07:30:08 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA24296 for ; Tue, 23 Jul 2002 03:30:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA29404 for mpls@uu.net; Tue, 23 Jul 2002 03:30:07 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmysj05125 for ; Tue, 23 Jul 2002 07:29:04 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 QQmysj03366 for ; Tue, 23 Jul 2002 07:28:59 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysj04123 for ; Tue, 23 Jul 2002 07:28:58 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQmysj04116 for ; Tue, 23 Jul 2002 07:28:58 GMT Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6N7SvD14349 for ; Tue, 23 Jul 2002 03:28:57 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2653.19) id <3R196K28>; Tue, 23 Jul 2002 03:28:56 -0400 Message-ID: From: "Singh, Amritpal (Amritpal)** CTR **" To: Loa Andersson , mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 03:28:55 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA02017 In my view, the best approach is to keep focussing on the already pervasive signaling standard that is RSVP-TE and let CR-LDP be kept as "informational". Focus is the keyword here. So I support this idea. My 2 cents Amrit -----Original Message----- From: Soumen Sarkar [mailto:soumen@sasken.com] Sent: Tuesday, July 23, 2002 12:57 PM To: Loa Andersson; mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols Loa, The response so far heavily indicated for RSVP-TE ( obviously not because of the merits of RSVP-TE over LDP-CR ). If one has to accept the basic ground-rule, which is, how many major players are pushing for RSVP-TE, one would blindly vote for RSVP-TE. The more esoteric view, which is, single signaling protocol would help everyone to concentrate better in addressing unresolved problems in MPLS, is also appreciably reasonable to accept. But looking from holistic perspective, is it not too premature at this time to conclude on this issue unilaterally (even if there is 3/4 majority in favour if it ) when this particular issue affects other standard bodies too ? We know for sure, OIF is still tracking LDP-CR as an alternative signaling protocol for optical control plane. Are we not pushing something without even considering future implication of it ? One might say, we are not stopping anyone to use LDP-CR as such. But none would disagree that making IETF take a stand itself is deterrant enough and if not that much, it is bound to create conflict of interest between IETF and others. Are we really ready for this ? IETF traditionally has been more a forum for vouching technical solutions, not imposing it. Are we deviating from that path with full understanding ? -best regards, Soumen Loa Andersson wrote: > Heinrich, > > in my opinion the question is very clearly stated - is there support for > us (the ietf) to move the cr-ldp from standard track to informational. > We're "speaking for the ietf", it is more a matter of what we say ;) > > All, > > As usual we are trying to reach a rough consensus. Everyone (i.e. the > mpls wg) can help create this consensus by answering the question > above. > > Especially it will be helpful if you were involved in specifying the > mpls protocols, have implemented or deployed (SP) those protocols, and > take the time to respond. > > I will be ready to give the first extensive tally mid this week. > Currently the count is > yes: 30 no: 7, > if you normalize those e.g. by counting each company once it is > yes: 21 no: 4 > > Disclaimer: Given that I've managed to decipher the sometimes cryptic > mails correctly :o) > > /Loa > > Hummel Heinrich wrote: > > > I think, the IETF can only speak for itself. There may be other standardization > > >bodies (ITU-T, MPLS Forum) which may fill > > the gap. > > > > Heinrich Hummel > > Siemens AG > > > > -- > 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 Tue Jul 23 03:39:01 2002 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 ESMTP id DAA02155 for ; Tue, 23 Jul 2002 03:39:00 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysk16859 for ; Tue, 23 Jul 2002 07:39:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmysk15235; Tue, 23 Jul 2002 07:39:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmysk05833 for mpls-outgoing; Tue, 23 Jul 2002 07:38:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmysk05818 for ; Tue, 23 Jul 2002 07:38: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 QQmysk26603 for ; Tue, 23 Jul 2002 07:36:56 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysk06398 for ; Tue, 23 Jul 2002 07:36:56 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQmysk06382 for ; Tue, 23 Jul 2002 07:36:54 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 23 Jul 2002 13:24:23 +0530 Received: from sailendram (sailendram.future.futsoft.com [10.4.8.18]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id g6N7VeC7015278; Tue, 23 Jul 2002 13:01:40 +0530 Reply-To: From: "sailendra mahanty" To: "'Vijayanand C - CTD, Chennai.'" Cc: Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 12:38:05 +0530 Message-Id: <001801c23217$b1f2a120$1208040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA064C33BF@haritha.hclt.com> Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Vijay, I agree in a stable scenario (LSPs not going ON and OFF) CR-LDP is more scaleable than RSVP-TE because of it(CRLDP)'s hard state approach. if n LSPs are configured with CR-LDP it's 1 Hello and 1 KA per hold time per pair of neighbour n Label Req (not present in DU) and n Label Map per pair of neighbour if n LSPs are configured with RSVP-TE it's n Path per hold time per pair of neighbour n Resv per hold time per pair of neighbour The scalability issue of RSVP-TE can be resolved by refresh reduction. But the concern is when significant LSPs, X(say) going ON and OFF. With CR-LDP implementation it's X Label withdraw and X Release per pair of neighbour with RSVP-TE also it's X Path Tear and X Resv Tear per pair of neighbour OR X Path err and X Resv err per pair of neighbour To me both the implementations looks more or less same. Am i missing some thing. Regards, -sailendra -----Original Message----- From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com] Sent: Tuesday, July 23, 2002 12:09 PM To: sailendram@future.futsoft.com Subject: RE: initiating a discussion on mpls singaling protocols CR LDP willbe more stable in this situation. RSVP-TE uses a soft state approach while CR LDP uses hard states and cleaner way of maintaining and communicating changes VIjay -----Original Message----- From: sailendra mahanty [mailto:sailendram@future.futsoft.com] Sent: Monday, July 22, 2002 8:33 PM To: 'David Charlap'; 'Vijayanand C - CTD, Chennai.' Cc: 'IETF MPLS List' Subject: RE: initiating a discussion on mpls singaling protocols When hundreds of thousands of LSPs going ON and OFF, CRLDP implementation may have scalability issues. As CRLDP implementation has to pay for this with Label withdraw/release message when RSVP has to pay for this with path/resv tear messages. -sailendra -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of David Charlap Sent: Monday, July 22, 2002 7:30 PM To: IETF MPLS List Subject: Re: initiating a discussion on mpls singaling protocols Vijayanand C - CTD, Chennai. wrote: > In a network where you need to handle hundreds of thousands of LSPs, with a > significant percentage of them going on and off frequently, would the soft > state approach scale effectively ? If refresh reduction (RFC 2961) is implemented, it will scale just as well as any other approach will. Keep in mind that CR-LDP's seeming similicity is hiding all of the overhead inherent in using TCP for reliable delivery of control-plane packets. -- David *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue Jul 23 04:03:28 2002 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 ESMTP id EAA02940 for ; Tue, 23 Jul 2002 04:03:28 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysm03849 for ; Tue, 23 Jul 2002 08:04:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmysm02366; Tue, 23 Jul 2002 08:03:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmysm19115 for mpls-outgoing; Tue, 23 Jul 2002 08:03:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmysm19105 for ; Tue, 23 Jul 2002 08:03:27 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 QQmysm23561 for ; Tue, 23 Jul 2002 08:02:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysm21337 for ; Tue, 23 Jul 2002 08:02:03 GMT Received: from dharti.aplion.stpn.soft.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmysm21249 for ; Tue, 23 Jul 2002 08:02:00 GMT Received: from cyborg (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g6N83nH07936 for ; Tue, 23 Jul 2002 13:33:49 +0530 Reply-To: From: "Mayank Kumar" To: "Mpls \(E-mail\)" Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 13:34:59 +0530 Message-ID: <005401c2321f$a4bed520$feca64c0@cyborg> 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 In-Reply-To: <001801c23217$b1f2a120$1208040a@future.futsoft.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi i am new to this field.But i wanted to point out that RSVP-TE supports only DownStream on Demand model whereas the CR-LDP supports both . Does that not seem another disadvantage of rsvp-te from the perspective of Hop-by-Hop routted tunnels ,etc I hope i am not wrong thanks and regards mayank From owner-mpls@UU.NET Tue Jul 23 06:04:55 2002 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 ESMTP id GAA04874 for ; Tue, 23 Jul 2002 06:04:55 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysu29274 for ; Tue, 23 Jul 2002 10:05:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmysu27807; Tue, 23 Jul 2002 10:05:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmysu14214 for mpls-outgoing; Tue, 23 Jul 2002 10:04:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmysu12489 for ; Tue, 23 Jul 2002 10:04:36 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 QQmysu13285 for ; Tue, 23 Jul 2002 10:03:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysu06668 for ; Tue, 23 Jul 2002 10:03:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmysu06660 for ; Tue, 23 Jul 2002 10:03:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA29087 for ; Tue, 23 Jul 2002 06:03:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA15809 for mpls@uu.net; Tue, 23 Jul 2002 06:03:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmysu10867 for ; Tue, 23 Jul 2002 10:02: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 QQmysu03086 for ; Tue, 23 Jul 2002 10:01:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysu24289 for ; Tue, 23 Jul 2002 10:01:25 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmysu24272 for ; Tue, 23 Jul 2002 10:01:24 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 15:37:14 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA064C365F@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: sailendram@future.futsoft.com Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 15:33:28 +0530 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 Apply the refresh reduction procedures to the scenario taking into account the amount of state you need to store for summary refresh, triggers, refresh msgs , ACKs/NACKs and associated back off mechanisms in RSVP-TE. Sure, you might be able to manage but are you efficient considering that you could do the same thing easily with CR LDP. Vijay -----Original Message----- From: sailendra mahanty [mailto:sailendram@future.futsoft.com] Sent: Tuesday, July 23, 2002 12:38 PM To: 'Vijayanand C - CTD, Chennai.' Cc: mpls@uu.net Subject: RE: initiating a discussion on mpls singaling protocols Hello Vijay, I agree in a stable scenario (LSPs not going ON and OFF) CR-LDP is more scaleable than RSVP-TE because of it(CRLDP)'s hard state approach. if n LSPs are configured with CR-LDP it's 1 Hello and 1 KA per hold time per pair of neighbour n Label Req (not present in DU) and n Label Map per pair of neighbour if n LSPs are configured with RSVP-TE it's n Path per hold time per pair of neighbour n Resv per hold time per pair of neighbour The scalability issue of RSVP-TE can be resolved by refresh reduction. But the concern is when significant LSPs, X(say) going ON and OFF. With CR-LDP implementation it's X Label withdraw and X Release per pair of neighbour with RSVP-TE also it's X Path Tear and X Resv Tear per pair of neighbour OR X Path err and X Resv err per pair of neighbour To me both the implementations looks more or less same. Am i missing some thing. Regards, -sailendra -----Original Message----- From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com] Sent: Tuesday, July 23, 2002 12:09 PM To: sailendram@future.futsoft.com Subject: RE: initiating a discussion on mpls singaling protocols CR LDP willbe more stable in this situation. RSVP-TE uses a soft state approach while CR LDP uses hard states and cleaner way of maintaining and communicating changes VIjay -----Original Message----- From: sailendra mahanty [mailto:sailendram@future.futsoft.com] Sent: Monday, July 22, 2002 8:33 PM To: 'David Charlap'; 'Vijayanand C - CTD, Chennai.' Cc: 'IETF MPLS List' Subject: RE: initiating a discussion on mpls singaling protocols When hundreds of thousands of LSPs going ON and OFF, CRLDP implementation may have scalability issues. As CRLDP implementation has to pay for this with Label withdraw/release message when RSVP has to pay for this with path/resv tear messages. -sailendra -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of David Charlap Sent: Monday, July 22, 2002 7:30 PM To: IETF MPLS List Subject: Re: initiating a discussion on mpls singaling protocols Vijayanand C - CTD, Chennai. wrote: > In a network where you need to handle hundreds of thousands of LSPs, with a > significant percentage of them going on and off frequently, would the soft > state approach scale effectively ? If refresh reduction (RFC 2961) is implemented, it will scale just as well as any other approach will. Keep in mind that CR-LDP's seeming similicity is hiding all of the overhead inherent in using TCP for reliable delivery of control-plane packets. -- David *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-mpls@UU.NET Tue Jul 23 08:54:35 2002 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 ESMTP id IAA09494 for ; Tue, 23 Jul 2002 08:54:35 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytf28492 for ; Tue, 23 Jul 2002 12:55:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytf27296; Tue, 23 Jul 2002 12:54:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytf16618 for mpls-outgoing; Tue, 23 Jul 2002 12:54:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytf16611 for ; Tue, 23 Jul 2002 12:54: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 QQmytf14336 for ; Tue, 23 Jul 2002 12:54:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytf08314 for ; Tue, 23 Jul 2002 12:54:10 GMT Received: from emerson.torrentnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: emerson.torrentnet.com [198.78.51.110]) id QQmytf08310 for ; Tue, 23 Jul 2002 12:54:09 GMT Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g6NCrt230657; Tue, 23 Jul 2002 08:53:55 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g6NCrtC63231; Tue, 23 Jul 2002 08:53:55 -0400 (EDT) Received: from oldmonk (oldmonk.torrentnet.com [4.18.161.44]) by castillo.torrentnet.com (8.9.3/8.9.3) with SMTP id IAA29778; Tue, 23 Jul 2002 08:53:55 -0400 (EDT) From: "Sumit Garg" To: , "'Mpls \(E-mail\)'" Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 08:53:54 -0400 Message-ID: <000001c23248$00ac4840$2ca11204@torrentnet.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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <005401c2321f$a4bed520$feca64c0@cyborg> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit LDP supports both DU & DoD. CR-LDP is DoD /Sumit > > Hi > i am new to this field.But i wanted to point out that RSVP-TE > supports only > DownStream on Demand model whereas the CR-LDP supports both . > Does that not > seem another disadvantage of rsvp-te from the perspective of > Hop-by-Hop > routted tunnels ,etc > I hope i am not wrong > > thanks and regards > mayank > > > > From owner-mpls@UU.NET Tue Jul 23 09:00:07 2002 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 ESMTP id JAA09720 for ; Tue, 23 Jul 2002 09:00:07 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytg08924 for ; Tue, 23 Jul 2002 13:01:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytg07338; Tue, 23 Jul 2002 13:00:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytg17048 for mpls-outgoing; Tue, 23 Jul 2002 13:00:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytf16926 for ; Tue, 23 Jul 2002 12:59:59 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 QQmytf06157 for ; Tue, 23 Jul 2002 12:59:57 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytf10540 for ; Tue, 23 Jul 2002 12:59:57 GMT Received: from emerson.torrentnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: emerson.torrentnet.com [198.78.51.110]) id QQmytf10533 for ; Tue, 23 Jul 2002 12:59:57 GMT Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g6NCxt230715; Tue, 23 Jul 2002 08:59:55 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g6NCxsC63283; Tue, 23 Jul 2002 08:59:54 -0400 (EDT) Received: from oldmonk (oldmonk.torrentnet.com [4.18.161.44]) by castillo.torrentnet.com (8.9.3/8.9.3) with SMTP id IAA29842; Tue, 23 Jul 2002 08:59:54 -0400 (EDT) From: "Sumit Garg" To: "'Loa Andersson'" Cc: Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 08:59:53 -0400 Message-ID: <000101c23248$d6aad830$2ca11204@torrentnet.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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <1117F7D44159934FB116E36F4ABF221B02267164@celox-ma1-ems1.celoxnetworks.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi I lean towards not making the CR-LDP spec informational. My objections (none really technical, more political i.e. too premature to kill -9 CR-LDP etc.) are summed up by Eric Gray, Stephen Shew, Soumen Sarkar and others that I miss. To add to the list of other bodies using CR-LDP - MPLS Forums uses a CR-LDP derivative for the MPLS UNI spec. Regards /Sumit From owner-mpls@UU.NET Tue Jul 23 09:58:31 2002 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 ESMTP id JAA12313 for ; Tue, 23 Jul 2002 09:58:30 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytj16239 for ; Tue, 23 Jul 2002 13:59:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytj14801; Tue, 23 Jul 2002 13:58:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytj12819 for mpls-outgoing; Tue, 23 Jul 2002 13:58:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytj12809 for ; Tue, 23 Jul 2002 13:58: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 QQmytj27517 for ; Tue, 23 Jul 2002 13:58:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytj28126 for ; Tue, 23 Jul 2002 13:58:16 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytj28110 for ; Tue, 23 Jul 2002 13:58:15 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09228 for ; Tue, 23 Jul 2002 09:58:15 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09945 for mpls@uu.net; Tue, 23 Jul 2002 09:58:15 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyry18124 for ; Tue, 23 Jul 2002 04:36: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 QQmyry04271 for ; Tue, 23 Jul 2002 04:36:17 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyry27238 for ; Tue, 23 Jul 2002 04:36:17 GMT Received: from bosvwl02.infy.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: bosvwl02.infy.com [216.52.49.36]) id QQmyry27234 for ; Tue, 23 Jul 2002 04:36:16 GMT Received: from 192.168.200.81 by bosvwl02.infy.com (InterScan E-Mail VirusWall NT); Tue, 23 Jul 2002 00:35:15 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 10:06:08 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 10:06:08 +0530 Received: from ITLPC16450 ([135.254.199.114]) by kecmsg06.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 10:06:08 +0530 Message-ID: <002401c23203$f012cd90$72c7fe87@ITLPC16450> From: "Amritpal Singh" To: Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 09:32:46 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-a0d6e032-985a-45d6-80c2-3edba9add4ac" 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 X-OriginalArrivalTime: 23 Jul 2002 04:36:08.0394 (UTC) FILETIME=[76C80AA0:01C23202] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-a0d6e032-985a-45d6-80c2-3edba9add4ac Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C2322B.E70E6CE0" ------=_NextPart_000_0019_01C2322B.E70E6CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Loa on this. I think we need to be focussed in our = approach. Making CR-LDP as informational will allow more focus on developing an = already pervasive standard to be more refined. My 2 cents Amrit > -----Original Message----- > From: Loa Andersson [mailto:loa.andersson@utfors.se] > Sent: Thursday, July 18, 2002 7:42 AM > To: MPLS wg > Cc: George Swallow; scott Giles; Wijnen, Bert (Bert) > Subject: initiating a discussion on mpls singaling (sic) protocols >=20 >=20 > However, as has been shown in the survey on signaling protocols for > GMPLS the implementations of rsvp-te far out number the cr-ldp > implementations. As there are issues with having two similar standards > (potentially diverging), and it generates duplicate work in several > ietf working groups, the question was asked whether we should make > cr-ldp informational (which still make it available and possible to > work with) and progress only rsvp-te on the standards track. >=20 > At the meeting there were a wide spread support for this idea, but > it was ruled that it was premature to call wg consensus on this at the > meeting and that we wanted to take the discussion on the mpls mailing > list. >=20 > ------=_NextPart_000_0019_01C2322B.E70E6CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree with Loa on this. I think we need to be focussed in our = approach.

Making CR-LDP as informational will allow more focus on developing an = already=20 pervasive standard to be more refined.

My 2 cents

Amrit

 

 

> -----Original Message-----

> From: Loa Andersson [mailto:loa.andersson@utfors.se]

> Sent: Thursday, July 18, 2002 7:42 AM

> To: MPLS wg

> Cc: George Swallow; scott Giles; Wijnen, Bert (Bert)

> Subject: initiating a discussion on mpls singaling (sic) = protocols

>

>

<snip>

> However, as has been shown in the survey on signaling protocols = for

> GMPLS the implementations of rsvp-te far out number the = cr-ldp

> implementations. As there are issues with having two similar=20 standards

> (potentially diverging), and it generates duplicate work in = several

> ietf working groups, the question was asked whether we should = make

> cr-ldp informational (which still make it available and possible = to

> work with) and progress only rsvp-te on the standards track.

>

> At the meeting there were a wide spread support for this idea, = but

> it was ruled that it was premature to call wg consensus on this = at=20 the

> meeting and that we wanted to take the discussion on the mpls=20 mailing

> list.

>

> <snip>

------=_NextPart_000_0019_01C2322B.E70E6CE0-- ------=_NextPartTM-000-a0d6e032-985a-45d6-80c2-3edba9add4ac-- From owner-mpls@UU.NET Tue Jul 23 09:58:31 2002 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 ESMTP id JAA12326 for ; Tue, 23 Jul 2002 09:58:31 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytj00514 for ; Tue, 23 Jul 2002 13:59:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytj28724; Tue, 23 Jul 2002 13:58:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytj12814 for mpls-outgoing; Tue, 23 Jul 2002 13:58:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytj12808 for ; Tue, 23 Jul 2002 13:58: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 QQmytj25352 for ; Tue, 23 Jul 2002 13:57:40 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytj27447 for ; Tue, 23 Jul 2002 13:57:40 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytj27443 for ; Tue, 23 Jul 2002 13:57:39 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09199 for ; Tue, 23 Jul 2002 09:57:39 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09847 for mpls@uu.net; Tue, 23 Jul 2002 09:57:39 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyrn01280 for ; Tue, 23 Jul 2002 01:56: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 QQmyrn18743 for ; Tue, 23 Jul 2002 01:56:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyrn02070 for ; Tue, 23 Jul 2002 01:56:12 GMT Received: from sina.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.106.187.143]) id QQmyrn02053 for ; Tue, 23 Jul 2002 01:56:10 GMT Received: (qmail 1832 invoked by alias); 23 Jul 2002 01:47:47 -0000 Received: from unknown (HELO rick) (211.150.230.113) by 202.106.187.143 with SMTP; 23 Jul 2002 01:47:47 -0000 From: "rick king" To: Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 09:57:18 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3D3C03C9.67B8BBC9@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA12326 I agree with the propose too. rick China Telecom -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Robert Raszuk Sent: Monday, July 22, 2002 9:08 PM To: Loa Andersson Cc: Hummel Heinrich; mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols Hi Loa, You can add my vote: CRLDP experiment to be declared informational, RSVP-TE proceeds on standards track. R. > Loa Andersson wrote: > > Heinrich, > > in my opinion the question is very clearly stated - is there support for > us (the ietf) to move the cr-ldp from standard track to informational. > We're "speaking for the ietf", it is more a matter of what we say ;) > > All, > > As usual we are trying to reach a rough consensus. Everyone (i.e. the > mpls wg) can help create this consensus by answering the question > above. > > Especially it will be helpful if you were involved in specifying the > mpls protocols, have implemented or deployed (SP) those protocols, and > take the time to respond. > > I will be ready to give the first extensive tally mid this week. > Currently the count is > yes: 30 no: 7, > if you normalize those e.g. by counting each company once it is > yes: 21 no: 4 > > Disclaimer: Given that I've managed to decipher the sometimes cryptic > mails correctly :o) > > /Loa > > Hummel Heinrich wrote: > > > I think, the IETF can only speak for itself. There may be other standardization > > >bodies (ITU-T, MPLS Forum) which may fill > > the gap. > > > > Heinrich Hummel > > Siemens AG > > > > -- > 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 Tue Jul 23 10:01:08 2002 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 ESMTP id KAA12468 for ; Tue, 23 Jul 2002 10:01:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytk19431 for ; Tue, 23 Jul 2002 14:02:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytk17978; Tue, 23 Jul 2002 14:01:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytk17679 for mpls-outgoing; Tue, 23 Jul 2002 14:00:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmytk14679 for ; Tue, 23 Jul 2002 14:00: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 QQmytj00361 for ; Tue, 23 Jul 2002 13:59:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytj01102 for ; Tue, 23 Jul 2002 13:59:44 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytj29811 for ; Tue, 23 Jul 2002 13:59:09 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09288 for ; Tue, 23 Jul 2002 09:59:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA10054 for mpls@uu.net; Tue, 23 Jul 2002 09:59:07 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyth10895 for ; Tue, 23 Jul 2002 13:27: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 QQmyth10327 for ; Tue, 23 Jul 2002 13:27:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyth22374 for ; Tue, 23 Jul 2002 13:27:05 GMT Received: from sm.luth.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ny.sm.luth.se [130.240.3.1]) id QQmyth22370 for ; Tue, 23 Jul 2002 13:27:05 GMT Received: from sm.luth.se (sm-pc301.sm.luth.se [130.240.45.27]) by sm.luth.se (8.12.3/8.12.3) with ESMTP id g6NDQh6D026763 for ; Tue, 23 Jul 2002 15:26:45 +0200 (MET DST) Message-ID: <3D3D596B.9080509@sm.luth.se> Date: Tue, 23 Jul 2002 15:26:03 +0200 From: avri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <3D36A98A.7070103@utfors.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.11 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This seems to me a very strange proposal. And in fact seems to be a perversion of the IETF standards process as i understand it. If things are as argued, then RSVP-TE will progress to draft standard and then to standard, while CR-LDP remains a proposed standard. If it languishes long enough in the proposed state, without significant deployment or utility, then it would seem appropriate to transition it to historic at some point in the future. Taking it to informational at this point seems a fairly blatant political move without technical merit. At best it is an administrative sleight of hand that could strange repercussions as a precedent. Is the IETF going to embark next on an effort to define all protocol duplication out of existence by voting on which alternative to make informational? I would suggest (as voting is not something I thought the IETF did) that both protocols remain as ps. If CR-LDP withers on the vine because it has no utility, so be it. Voting to change its status seems inappropriate to me. a. From owner-mpls@UU.NET Tue Jul 23 10:22:38 2002 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 ESMTP id KAA13376 for ; Tue, 23 Jul 2002 10:22:36 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytl03011 for ; Tue, 23 Jul 2002 14:23:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytl28237; Tue, 23 Jul 2002 14:21:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytl06819 for mpls-outgoing; Tue, 23 Jul 2002 14:20:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytl06806 for ; Tue, 23 Jul 2002 14:20: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 QQmytl28731 for ; Tue, 23 Jul 2002 14:20:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytl26949 for ; Tue, 23 Jul 2002 14:20:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytl26927 for ; Tue, 23 Jul 2002 14:20:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA10902 for ; Tue, 23 Jul 2002 10:20:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA13698 for mpls@uu.net; Tue, 23 Jul 2002 10:20:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytl06741 for ; Tue, 23 Jul 2002 14:18: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 QQmytl22687 for ; Tue, 23 Jul 2002 14:18:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytl25949 for ; Tue, 23 Jul 2002 14:18:19 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmytl25937 for ; Tue, 23 Jul 2002 14:18:18 GMT Received: from ZALI-W2K.cisco.com (che-vpn1-88.cisco.com [10.86.240.88]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id KAA23132; Tue, 23 Jul 2002 10:18:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20020723100337.022b0498@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Jul 2002 10:18:07 -0400 To: "Stephen Shew" , MPLS wg From: Zafar Ali Subject: RE: initiating a discussion on mpls singaling protocols In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E601BA4E0D@zcard0ke.ca.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5506818==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_5506818==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable At 03:43 PM 7/22/2002 -0400, Stephen Shew wrote: >I would like to speak against the proposal to make CR-LDP=20 >informational. Signalling is not the only function in IP in which there=20 >are multiple (standards track) protocols. Why insist on converging to=20 >one? Also, CR-LDP is found in other specifications (e.g., OIF UNI 1.0,=20 >ITU-T Y.1310) whose bodies want to continue evolving its=20 >functionality. In particular, the ITU-T is using GMPLS CR-LDP in its=20 >draft recommendation G.7713.3 (CR-LDP based signalling for ASON). Couple of points here=85 O-UNI (rightly) provides alternative of using RSVP-TE signaling and if you= =20 do a survey on O-UNI implementation, I can bet you that you will find the=20 similar results that RSVP-TE is by-far the common implementation. By making the CR-LDP informational, one is NOT removing all the references= =20 to it. This is an already matured activity. So, all the references made by= =20 the other standardization activities will still hold. In fact, such=20 organizations will have more control and be happier to know that they are=20 NOT working on a ground that is in flux. Not to mention, I don't think IETF= =20 is bound to other standardization committees in making its decision. Thanks Regards=85 Zafar --=====================_5506818==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 03:43 PM 7/22/2002 -0400, Stephen Shew wrote:

I would like to speak against the proposal to make CR-LDP informational.  Signalling is not the only function in IP in which there are multiple (standards track) protocols.  Why insist on converging to one?  Also, CR-LDP is found in other specifications (e.g., OIF UNI 1.0, ITU-T Y.1310) whose bodies want to continue evolving its functionality.  In particular, the ITU-T is using GMPLS CR-LDP in its draft recommendation G.7713.3 (CR-LDP based signalling for ASON).

Couple of points here=85=

O-UNI (rightly) provides alternative of using RSVP-TE signaling and if you do a survey on O-UNI implementation, I can bet you that you will find the similar results that RSVP-TE is by-far the common implementation.

By making the CR-LDP informational, one is NOT removing all the references to it. This is an already matured activity. So, all the references made by the other standardization activities will still hold. In fact, such organizations will have more control and be happier to know that they are NOT working on a ground that is in flux. Not to mention, I don't think IETF is bound to other standardization committees in making its decision. 

Thanks

Regards=85 Zafar 
--=====================_5506818==_.ALT-- From owner-mpls@UU.NET Tue Jul 23 10:23:55 2002 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 ESMTP id KAA13474 for ; Tue, 23 Jul 2002 10:23:55 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytl14100 for ; Tue, 23 Jul 2002 14:24:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytl13198; Tue, 23 Jul 2002 14:24:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytl07280 for mpls-outgoing; Tue, 23 Jul 2002 14:24:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytl07258 for ; Tue, 23 Jul 2002 14:24: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 QQmytl29186 for ; Tue, 23 Jul 2002 14:24:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytl04201 for ; Tue, 23 Jul 2002 14:24:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytl04152 for ; Tue, 23 Jul 2002 14:24:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA11226 for ; Tue, 23 Jul 2002 10:24:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA14304 for mpls@uu.net; Tue, 23 Jul 2002 10:24:04 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytl06827 for ; Tue, 23 Jul 2002 14:21: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 QQmytl01272 for ; Tue, 23 Jul 2002 14:20:46 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytl27576 for ; Tue, 23 Jul 2002 14:20:45 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmytl27556 for ; Tue, 23 Jul 2002 14:20:45 GMT Received: from ZALI-W2K.cisco.com (che-vpn1-88.cisco.com [10.86.240.88]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id KAA23292; Tue, 23 Jul 2002 10:20:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20020723100213.022c0358@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Jul 2002 10:20:28 -0400 To: "Sumit Garg" , "'Loa Andersson'" From: Zafar Ali Subject: RE: initiating a discussion on mpls singaling protocols Cc: In-Reply-To: <000101c23248$d6aad830$2ca11204@torrentnet.com> References: <1117F7D44159934FB116E36F4ABF221B02267164@celox-ma1-ems1.celoxnetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5648422==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_5648422==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:59 AM 7/23/2002 -0400, Sumit Garg wrote: >Hi > >I lean towards not making the CR-LDP spec informational. My objections >(none really technical, more political i.e. too premature to kill -9 >CR-LDP etc.) are summed up by Eric Gray, Stephen Shew, Soumen Sarkar and >others that I miss. > >To add to the list of other bodies using CR-LDP - MPLS Forums uses a >CR-LDP derivative for the MPLS UNI spec. Please see my reply to Stephen's email, on the same (non)argument. Thanks Regards... Zafar >Regards >/Sumit --=====================_5648422==_.ALT Content-Type: text/html; charset="us-ascii" At 08:59 AM 7/23/2002 -0400, Sumit Garg wrote:
Hi

I lean towards not making the CR-LDP spec informational.  My objections
(none really technical, more political i.e. too premature to kill -9
CR-LDP etc.) are summed up by Eric Gray, Stephen Shew, Soumen Sarkar and
others that I miss.

To add to the list of other bodies using CR-LDP - MPLS Forums uses a
CR-LDP derivative for the MPLS UNI spec.

Please see my reply to Stephen's email, on the same (non)argument.

Thanks

Regards... Zafar


Regards
/Sumit
--=====================_5648422==_.ALT-- From owner-mpls@UU.NET Tue Jul 23 10:49:34 2002 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 ESMTP id KAA14907 for ; Tue, 23 Jul 2002 10:49:33 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytn24964 for ; Tue, 23 Jul 2002 14:49:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytn23176; Tue, 23 Jul 2002 14:48:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytn09596 for mpls-outgoing; Tue, 23 Jul 2002 14:48:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytn09591 for ; Tue, 23 Jul 2002 14:48:12 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 QQmytn15112 for ; Tue, 23 Jul 2002 14:45:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytn21295 for ; Tue, 23 Jul 2002 14:45:05 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytn21287 for ; Tue, 23 Jul 2002 14:45:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA12792 for ; Tue, 23 Jul 2002 10:45:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA18429 for mpls@uu.net; Tue, 23 Jul 2002 10:45:04 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmytm08790 for ; Tue, 23 Jul 2002 14:43: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 QQmytm15701 for ; Tue, 23 Jul 2002 14:43:24 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 QQmytk10696 for ; Tue, 23 Jul 2002 14:04:19 GMT Received: (qmail 26122 invoked by uid 104); 23 Jul 2002 14:04:17 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 0.475039 secs); 23 Jul 2002 14:04:17 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 23 Jul 2002 14:04:16 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6NE4Gc27426; Tue, 23 Jul 2002 07:04:16 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 07:04:17 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0374D@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Gray, Eric'" , "'erosen@cisco.com'" Cc: mpls@UU.NET Subject: RE: your mail Date: Tue, 23 Jul 2002 07:04:12 -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 Thanks Eric, Your response seems reasonable. However, I have heard that some implementation hash the label stack, up to the Nth label or bottom-label (if the stack has less than N labels). Does that mean that the hashing algorithm should operate on a variable length input? And if so does such an algorithm exist? Yours, -Shahram > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Monday, July 22, 2002 5:06 PM > To: Shahram Davari; 'erosen@cisco.com' > Cc: mpls@UU.NET > Subject: RE: your mail > > > Shahram, > > There is nothing to be fearful, uncertain or > doubtful about here. > > If an implementation can handle up to N labels, > then it can use either the bottom-of-stack label or > the Nth label for a hash key. With respect to flows, > this will be consistent. It will also tend to give > the greatest degree of entropy in hashing possible > for a specific labeled packet. It doesn't guarantee > even distribution any worse than any other 'guess'. > > Use of the IP header as well is a) unnecessary, > b) unhelpful and c) not a good idea. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, July 22, 2002 4:48 PM > To: 'erosen@cisco.com' > Cc: 'Giles Heron'; neil.2.harrison@bt.com; > eosborne@cisco.com; mpls@UU.NET > Subject: RE: your mail > > Hi Eric, > > If I understand you correctly, what you are saying is that > assume a number > such as "N", and hash the Nth label, regardless of whether it is the > real bottom-most label (i.e. with S=1) or not. If so then: > > 1) How do you know that at least N labels exist in all packets? > 2) The Nth label can not identify a flow by itself, rather > you need to hash > the whole label stack from the top, up to the Nth label, in order to > identify a flow. > 3) I have heard that some implementations hash the IP header > too? How does > that fit in to your model? How do you know that the payload > is IP? And don't > you need to find the real bottom of stack (S=1) in order to > include the IP > header in the hash? > > Yours, > -Shahram > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Monday, July 22, 2002 3:15 PM > > To: Shahram Davari > > Cc: 'Giles Heron'; neil.2.harrison@bt.com; eosborne@cisco.com; > > mpls@UU.NET > > Subject: Re: your mail > > > > > > > > Shahram> "Deep" or "not deep" you need potentially unlimited > > packet parsing > > Shahram> (uo to MTU size), since as you said the number of > > labels are not > > Shahram> limited to 2. > > > > To the MTU size? That would be for the case where the > > entire packet > > contains the MPLS label stack and there is no payload? > > > > As has been made clear repeatedly, you can hash on any > > label, you just get > > more fine-grained load balancing the further down you go. > > So generally you > > would look at the bottom-most label that you can easily > > see, given your > > particular forwarding architecture. > > > > > > > > > From owner-mpls@UU.NET Tue Jul 23 10:54:50 2002 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 ESMTP id KAA15344 for ; Tue, 23 Jul 2002 10:54:48 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytn11331 for ; Tue, 23 Jul 2002 14:55:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytn06635; Tue, 23 Jul 2002 14:53:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytn09944 for mpls-outgoing; Tue, 23 Jul 2002 14:53:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytn09912 for ; Tue, 23 Jul 2002 14:52: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 QQmytn03379 for ; Tue, 23 Jul 2002 14:52:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytn28514 for ; Tue, 23 Jul 2002 14:51:50 GMT 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 QQmytn28431 for ; Tue, 23 Jul 2002 14:51:47 GMT Received: from ihmail.ih.lucent.com (h135-185-56-8.lucent.com [135.185.56.8]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6NEpQV20052; Tue, 23 Jul 2002 10:51:26 -0400 (EDT) Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.23]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA17943; Tue, 23 Jul 2002 09:51:25 -0500 (CDT) Message-ID: <3D3D6D6C.28BB4427@lucent.com> Date: Tue, 23 Jul 2002 08:51:24 -0600 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Zafar Ali CC: Stephen Shew , MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <4.3.2.7.2.20020723100337.022b0498@sword.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Zafar, (snip) > So, all the references made by the other standardization activities will still > hold. In fact, for references from ITU-T Recommendations, reclassification as informational does raise an issue: According to Recommendation A.5, ITU-T Recommendations may not have normative references to informational, historical, or experimental RFCs (or IDs of any kind). Regards, Steve Trowbridge Vice-chairman, ITU-T Study Group 15 From owner-mpls@UU.NET Tue Jul 23 10:55:24 2002 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 ESMTP id KAA15394 for ; Tue, 23 Jul 2002 10:55:22 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytn05742 for ; Tue, 23 Jul 2002 14:56:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytn03324; Tue, 23 Jul 2002 14:55:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytn10158 for mpls-outgoing; Tue, 23 Jul 2002 14:54:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmytn10139 for ; Tue, 23 Jul 2002 14:54: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 QQmytn10611 for ; Tue, 23 Jul 2002 14:54:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytn02316 for ; Tue, 23 Jul 2002 14:54:30 GMT Received: from mlsrv1.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQmytn02287 for ; Tue, 23 Jul 2002 14:54:29 GMT Received: from prometheus.avici.com (ssh-int.avici.com [10.6.0.28]) by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g6NEsG107841; Tue, 23 Jul 2002 10:54:16 -0400 (EDT) Message-Id: <5.0.2.1.2.20020723105135.00a8ec60@localhost> X-Sender: aatlas@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 23 Jul 2002 10:54:22 -0400 To: Shahram Davari From: Alia Atlas Subject: RE: your mail Cc: "'Gray, Eric'" , "'erosen@cisco.com'" , mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB0374D@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Shahram, By hashing on the label stack up to the Nth label, one obtains better diversity. All the information to indicate a flow is included in the resulting hash. There certainly are algorithms which can operate on a variable length input. Also, if one desires to use the IP information potentially underneath an MPLS packet, it is possible to attempt to differentiate IP from non-IP using the IP checksum and version number. Alia At 07:04 AM 7/23/02 -0700, Shahram Davari wrote: >Thanks Eric, > >Your response seems reasonable. However, I have heard that >some implementation hash the label stack, up to the Nth >label or bottom-label (if the stack has less than N labels). >Does that mean that the hashing algorithm should operate on a >variable length input? And if so does such an algorithm exist? > >Yours, >-Shahram > > > -----Original Message----- > > From: Gray, Eric [mailto:egray@celoxnetworks.com] > > Sent: Monday, July 22, 2002 5:06 PM > > To: Shahram Davari; 'erosen@cisco.com' > > Cc: mpls@UU.NET > > Subject: RE: your mail > > > > > > Shahram, > > > > There is nothing to be fearful, uncertain or > > doubtful about here. > > > > If an implementation can handle up to N labels, > > then it can use either the bottom-of-stack label or > > the Nth label for a hash key. With respect to flows, > > this will be consistent. It will also tend to give > > the greatest degree of entropy in hashing possible > > for a specific labeled packet. It doesn't guarantee > > even distribution any worse than any other 'guess'. > > > > Use of the IP header as well is a) unnecessary, > > b) unhelpful and c) not a good idea. > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, July 22, 2002 4:48 PM > > To: 'erosen@cisco.com' > > Cc: 'Giles Heron'; neil.2.harrison@bt.com; > > eosborne@cisco.com; mpls@UU.NET > > Subject: RE: your mail > > > > Hi Eric, > > > > If I understand you correctly, what you are saying is that > > assume a number > > such as "N", and hash the Nth label, regardless of whether it is the > > real bottom-most label (i.e. with S=1) or not. If so then: > > > > 1) How do you know that at least N labels exist in all packets? > > 2) The Nth label can not identify a flow by itself, rather > > you need to hash > > the whole label stack from the top, up to the Nth label, in order to > > identify a flow. > > 3) I have heard that some implementations hash the IP header > > too? How does > > that fit in to your model? How do you know that the payload > > is IP? And don't > > you need to find the real bottom of stack (S=1) in order to > > include the IP > > header in the hash? > > > > Yours, > > -Shahram > > > > > -----Original Message----- > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > Sent: Monday, July 22, 2002 3:15 PM > > > To: Shahram Davari > > > Cc: 'Giles Heron'; neil.2.harrison@bt.com; eosborne@cisco.com; > > > mpls@UU.NET > > > Subject: Re: your mail > > > > > > > > > > > > Shahram> "Deep" or "not deep" you need potentially unlimited > > > packet parsing > > > Shahram> (uo to MTU size), since as you said the number of > > > labels are not > > > Shahram> limited to 2. > > > > > > To the MTU size? That would be for the case where the > > > entire packet > > > contains the MPLS label stack and there is no payload? > > > > > > As has been made clear repeatedly, you can hash on any > > > label, you just get > > > more fine-grained load balancing the further down you go. > > > So generally you > > > would look at the bottom-most label that you can easily > > > see, given your > > > particular forwarding architecture. > > > > > > > > > > > > > > From owner-mpls@UU.NET Tue Jul 23 10:57:25 2002 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 ESMTP id KAA15568 for ; Tue, 23 Jul 2002 10:57:25 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytn17272 for ; Tue, 23 Jul 2002 14:58:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytn29834; Tue, 23 Jul 2002 14:51:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytn09776 for mpls-outgoing; Tue, 23 Jul 2002 14:50:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytn09756 for ; Tue, 23 Jul 2002 14:50: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 QQmytn24365 for ; Tue, 23 Jul 2002 14:49:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytn28607 for ; Tue, 23 Jul 2002 14:49:20 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmytn28603 for ; Tue, 23 Jul 2002 14:49:20 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6NEnFx23835; Tue, 23 Jul 2002 10:49:16 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 10:49:15 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E603104DE6@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Loa Andersson , MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 10:49:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23258.191EC816" 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_01C23258.191EC816 Content-Type: text/plain Hi Loa I am against the proposal on the belief it is too soon to take this step. If we had applied this policy to the original classical RSVP protocol it would have been information some 5 years ago. Cheers, Don ------_=_NextPart_001_01C23258.191EC816 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: initiating a discussion on mpls singaling protocols

Hi Loa

I am against the proposal on the belief it is too = soon to take this step. If we had applied this policy to the original = classical RSVP protocol it would have been information some 5 years = ago.

Cheers,
Don 

------_=_NextPart_001_01C23258.191EC816-- From owner-mpls@UU.NET Tue Jul 23 11:12:51 2002 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 ESMTP id LAA16822 for ; Tue, 23 Jul 2002 11:12:50 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyto16385 for ; Tue, 23 Jul 2002 15:13:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyto15047; Tue, 23 Jul 2002 15:13:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyto05392 for mpls-outgoing; Tue, 23 Jul 2002 15:12:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyto05209 for ; Tue, 23 Jul 2002 15:12: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 QQmyto26187 for ; Tue, 23 Jul 2002 15:12:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyto21165 for ; Tue, 23 Jul 2002 15:12:16 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 QQmyto21158 for ; Tue, 23 Jul 2002 15:12:16 GMT Received: from MDUFFY ([10.1.3.119]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PF3BTRL1; Tue, 23 Jul 2002 11:12:14 -0400 Message-Id: <3.0.5.32.20020723110726.007be720@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 23 Jul 2002 11:07:26 -0400 To: ben@layer8.net, kireeti@juniper.net, mpls@UU.NET From: Mark Duffy Subject: issues in draft-ietf-mpls-ldp-mtu-extensions-00 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi, In draft-ietf-mpls-ldp-mtu-extensions-00 I believe there are several problems with the example in section 3. At the very end of the example it states: At t[2]: 1) Rx receives a Mapping for F from Ry with an MTU of 9216. Rx compares 9212 (9216 - 4) to 4466, and sends a Mapping message for F with an MTU of 4466 to Ri. 2) Ri has not received Mappings for F. At t[3]: 1) Ri receives a Mapping for F from Rx with an MTU of 4462. Ri compares 4466 to 9216, and sets the MTU for P1 to 4462 (4466 minus the overhead of 1 label pushed onto the stack). The last step looks to me like it has several errors. At t[2] item 1 Rx sends a mapping with mtu of 4466 to Ri. Therefore at t[3] step 1 Ri should receive a mapping from Rx with an mtu of 4466. Also in this same step Ri should subtract 4 bytes from both the MTU it learned from Rx, as well as its local interface MTU, in making the calculation (to account for the label pushed at Ri). So it looks to me like the correct text for t[3] is: 1) Ri receives a Mapping for F from Rx with an MTU of *4466*. Ri compares *4462* to *9212*, and sets the MTU for P1 to 4462 (4466 minus the overhead of 1 label pushed onto the stack). --------------------- Also, the example doesn't seem to correctly account for the encapsulation of LSP P1 inside LSP P2 from Rx to Re. It discusses mappings for FEC F to LSP P1 distributed to Ry, however Ry may be unaware of FEC F, since LSP P1 is encapsulated in P2 at this point. I think the way to fix this would be to: Let FEC G represent traffic mapped to LSP P2. Change t[0] and t[1] items #1 to discuss G rather than F. Change t[0] and t[1] items #2 to include G. Chnage t[2] item #1 to receive mapping for G from Ry, send mapping for F to Ri. Adding another column to the table at the right of the figure would help as well, giving the "MTU with P1 and P2 overhead". Apologies if I am misunderstanding this, or if this has already been pointed out. --Mark From owner-mpls@UU.NET Tue Jul 23 11:16:25 2002 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 ESMTP id LAA17053 for ; Tue, 23 Jul 2002 11:16:24 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytp23705 for ; Tue, 23 Jul 2002 15:17:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyto16856; Tue, 23 Jul 2002 15:14:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyto05757 for mpls-outgoing; Tue, 23 Jul 2002 15:13:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyto05632 for ; Tue, 23 Jul 2002 15:13:07 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 QQmyto26459 for ; Tue, 23 Jul 2002 15:12:46 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyto21394 for ; Tue, 23 Jul 2002 15:12:46 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 QQmyto21381 for ; Tue, 23 Jul 2002 15:12:45 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA13631; Tue, 23 Jul 2002 17:12:23 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA24683; Tue, 23 Jul 2002 17:12:40 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 17:12:37 +0200 Message-ID: From: Hummel Heinrich To: "'avri'" Cc: MPLS wg Subject: AW: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 17:12: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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17053 Well spoken. Additionally, all those who do not care for CR-LDP have hardly contributed in the past nor will they contribute in the future to extend routing protocols for the sake of CR-LDP. This sweat is up to the CR-LDP supporters. It is not honest to complain about the burden carried by the others. Heinrich -----Ursprüngliche Nachricht----- Von: avri [mailto:avri@sm.luth.se] Gesendet: Dienstag, 23. Juli 2002 15:26 Cc: MPLS wg Betreff: Re: initiating a discussion on mpls singaling protocols This seems to me a very strange proposal. And in fact seems to be a perversion of the IETF standards process as i understand it. If things are as argued, then RSVP-TE will progress to draft standard and then to standard, while CR-LDP remains a proposed standard. If it languishes long enough in the proposed state, without significant deployment or utility, then it would seem appropriate to transition it to historic at some point in the future. Taking it to informational at this point seems a fairly blatant political move without technical merit. At best it is an administrative sleight of hand that could strange repercussions as a precedent. Is the IETF going to embark next on an effort to define all protocol duplication out of existence by voting on which alternative to make informational? I would suggest (as voting is not something I thought the IETF did) that both protocols remain as ps. If CR-LDP withers on the vine because it has no utility, so be it. Voting to change its status seems inappropriate to me. a. From owner-mpls@UU.NET Tue Jul 23 11:20:40 2002 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 ESMTP id LAA17221 for ; Tue, 23 Jul 2002 11:20:38 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytp01376 for ; Tue, 23 Jul 2002 15:21:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytp26996; Tue, 23 Jul 2002 15:19:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytp06760 for mpls-outgoing; Tue, 23 Jul 2002 15:18:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytp06747 for ; Tue, 23 Jul 2002 15:18:23 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 QQmytp12755 for ; Tue, 23 Jul 2002 15:17:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytp29917 for ; Tue, 23 Jul 2002 15:17:35 GMT Received: from auemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQmytp29913 for ; Tue, 23 Jul 2002 15:17:35 GMT Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with SMTP id g6NFHX118608; Tue, 23 Jul 2002 11:17:33 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA08497; Tue, 23 Jul 2002 11:17:33 -0400 Message-ID: <3D3D739A.2060609@lucent.com> Date: Tue, 23 Jul 2002 11:17:46 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fedyk CC: Loa Andersson , MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <0D7FC1D8D861D511AEA70002A52CE5E603104DE6@zcard0ke.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I believe that making a decision on whether RSVP-TE or CR-LDP should be on standards track based upon marketshare should NOT be how a standards organization works... As another person commented, if we're making our decision based on marketshare then Microsoft Windows would be the standard for OS, and probably also need to switch to using Word as the default format for documents... Zhi Don Fedyk wrote: > Hi Loa > > I am against the proposal on the belief it is too soon to take this > step. If we had applied this policy to the original classical RSVP > protocol it would have been information some 5 years ago. > > Cheers, > Don > From owner-mpls@UU.NET Tue Jul 23 11:21:56 2002 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 ESMTP id LAA17277 for ; Tue, 23 Jul 2002 11:21:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytp06294 for ; Tue, 23 Jul 2002 15:22:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytp04806; Tue, 23 Jul 2002 15:22:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytp06911 for mpls-outgoing; Tue, 23 Jul 2002 15:21:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytp06894 for ; Tue, 23 Jul 2002 15:21: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 QQmytp08307 for ; Tue, 23 Jul 2002 15:20:46 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytp27046 for ; Tue, 23 Jul 2002 15:20:46 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmytp27039 for ; Tue, 23 Jul 2002 15:20:45 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1NJK>; Tue, 23 Jul 2002 11:20:45 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267170@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Shahram Davari'" , "'erosen@cisco.com'" Cc: mpls@UU.NET Subject: RE: your mail Date: Tue, 23 Jul 2002 11:20:44 -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 Shahram, As you said (or implied) earlier, using the entire MPLS stack identifies the inner-most LSP. This might be considered a 'flow', by some definitions of flow. It is an interesting fact that containing LSPs are 'flows' by a coarser definition and even the inner most LSP is likely to be an aggregation of 'flows' by some finer definition of flow. One could seek to get to an even finer definition of flow by going beyond the bottom of stack label. One question is whether or not this is necessary, or even helpful to at least the extent that it might be hard to do. A separate questions is whether or not it can even be done correctly. The key considerations in picking an approach to doing ECMP are maximizing the extent to which traffic is (expected to be) evenly distributed while avoiding risk of scattering traffic in doing so. An example of traffic scattering would be what would happen if you attempt to use IP DA/SA as part of your hash key (bucket selector) with non IP packets (particularly if the bit positions corresponding to IP DA/SA happen to be associated with fields that change from one packet to the next in any specific flow under consideration). While developing a hash based on identifying flows is a sufficient means to ensure that individual flows do not get scattered, it is not necessary (the usual formal definition of necessary and sufficient apply here). If it is known that flows will be bucketed in any aggregate form, then individual flows will be bucketed that way as well and will not be scattered. After some thought, it becomes clear that one way to bucket flows in such an aggregate form is to use the first and last label in the stack (where last means any label that can be consistently selected based on either the bottom of stack indication or some number N that is the highest number of labels that can be examined by a particular implementation). This is what was proposed. This reduces the question to whether or not there is anything to gain - in terms of distribution equity - from using a finer aggregate. The answer to this is something each implementer has to decide for themselves based on specifics of their own implementation. A very important consideration is how much information their implementation wants to - or even can - know about the quantity of traffic that is associated with individual flows at whatever granularity they choose to use. I believe the proposal describes a reasonable basis for doing ECMP that will fit many/most implementations. Incidentally, there are many algorithms that will generate a hash from a bit stream of nearly arbitrary length (it cannot be infinite, for example). That's a completely unrelated topic, in my opinion. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Tuesday, July 23, 2002 10:04 AM To: 'Gray, Eric'; 'erosen@cisco.com' Cc: mpls@UU.NET Subject: RE: your mail Thanks Eric, Your response seems reasonable. However, I have heard that some implementation hash the label stack, up to the Nth label or bottom-label (if the stack has less than N labels). Does that mean that the hashing algorithm should operate on a variable length input? And if so does such an algorithm exist? Yours, -Shahram > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Monday, July 22, 2002 5:06 PM > To: Shahram Davari; 'erosen@cisco.com' > Cc: mpls@UU.NET > Subject: RE: your mail > > > Shahram, > > There is nothing to be fearful, uncertain or > doubtful about here. > > If an implementation can handle up to N labels, > then it can use either the bottom-of-stack label or > the Nth label for a hash key. With respect to flows, > this will be consistent. It will also tend to give > the greatest degree of entropy in hashing possible > for a specific labeled packet. It doesn't guarantee > even distribution any worse than any other 'guess'. > > Use of the IP header as well is a) unnecessary, > b) unhelpful and c) not a good idea. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, July 22, 2002 4:48 PM > To: 'erosen@cisco.com' > Cc: 'Giles Heron'; neil.2.harrison@bt.com; > eosborne@cisco.com; mpls@UU.NET > Subject: RE: your mail > > Hi Eric, > > If I understand you correctly, what you are saying is that > assume a number > such as "N", and hash the Nth label, regardless of whether it is the > real bottom-most label (i.e. with S=1) or not. If so then: > > 1) How do you know that at least N labels exist in all packets? > 2) The Nth label can not identify a flow by itself, rather > you need to hash > the whole label stack from the top, up to the Nth label, in order to > identify a flow. > 3) I have heard that some implementations hash the IP header > too? How does > that fit in to your model? How do you know that the payload > is IP? And don't > you need to find the real bottom of stack (S=1) in order to > include the IP > header in the hash? > > Yours, > -Shahram > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Monday, July 22, 2002 3:15 PM > > To: Shahram Davari > > Cc: 'Giles Heron'; neil.2.harrison@bt.com; eosborne@cisco.com; > > mpls@UU.NET > > Subject: Re: your mail > > > > > > > > Shahram> "Deep" or "not deep" you need potentially unlimited > > packet parsing > > Shahram> (uo to MTU size), since as you said the number of > > labels are not > > Shahram> limited to 2. > > > > To the MTU size? That would be for the case where the > > entire packet > > contains the MPLS label stack and there is no payload? > > > > As has been made clear repeatedly, you can hash on any > > label, you just get > > more fine-grained load balancing the further down you go. > > So generally you > > would look at the bottom-most label that you can easily > > see, given your > > particular forwarding architecture. > > > > > > > > > From owner-mpls@UU.NET Tue Jul 23 11:27:56 2002 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 ESMTP id LAA17593 for ; Tue, 23 Jul 2002 11:27:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytp15711 for ; Tue, 23 Jul 2002 15:28:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytp14466; Tue, 23 Jul 2002 15:28:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytp07681 for mpls-outgoing; Tue, 23 Jul 2002 15:27:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytp07675 for ; Tue, 23 Jul 2002 15:27: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 QQmytp29230 for ; Tue, 23 Jul 2002 15:27:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytp13782 for ; Tue, 23 Jul 2002 15:27:06 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmytp13778 for ; Tue, 23 Jul 2002 15:27:05 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1NKP>; Tue, 23 Jul 2002 11:27:05 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267171@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Hummel Heinrich'" , "'avri'" Cc: MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 11:26:56 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17593 Heinrich, I don't think this is a fair characterization. Several draft authors have participated in work to develop CR-LDP extensions who have no real interest in CR-LDP. This has been done - IMO - out of a sense of responsible protocol development rather than out of interest in progressing both signaling protocols. Perhaps this is what really needs to change. If a specific draft author only wishes to work with one signaling protocol, then he or she should be able to simply do so. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] Sent: Tuesday, July 23, 2002 11:13 AM To: 'avri' Cc: MPLS wg Subject: AW: initiating a discussion on mpls singaling protocols Well spoken. Additionally, all those who do not care for CR-LDP have hardly contributed in the past nor will they contribute in the future to extend routing protocols for the sake of CR-LDP. This sweat is up to the CR-LDP supporters. It is not honest to complain about the burden carried by the others. Heinrich -----Ursprüngliche Nachricht----- Von: avri [mailto:avri@sm.luth.se] Gesendet: Dienstag, 23. Juli 2002 15:26 Cc: MPLS wg Betreff: Re: initiating a discussion on mpls singaling protocols This seems to me a very strange proposal. And in fact seems to be a perversion of the IETF standards process as i understand it. If things are as argued, then RSVP-TE will progress to draft standard and then to standard, while CR-LDP remains a proposed standard. If it languishes long enough in the proposed state, without significant deployment or utility, then it would seem appropriate to transition it to historic at some point in the future. Taking it to informational at this point seems a fairly blatant political move without technical merit. At best it is an administrative sleight of hand that could strange repercussions as a precedent. Is the IETF going to embark next on an effort to define all protocol duplication out of existence by voting on which alternative to make informational? I would suggest (as voting is not something I thought the IETF did) that both protocols remain as ps. If CR-LDP withers on the vine because it has no utility, so be it. Voting to change its status seems inappropriate to me. a. From owner-mpls@UU.NET Tue Jul 23 11:31:59 2002 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 ESMTP id LAA17913 for ; Tue, 23 Jul 2002 11:31:58 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytq13283 for ; Tue, 23 Jul 2002 15:32:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytq11867; Tue, 23 Jul 2002 15:32:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytq07998 for mpls-outgoing; Tue, 23 Jul 2002 15:31:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytq07990 for ; Tue, 23 Jul 2002 15: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 QQmytp22980 for ; Tue, 23 Jul 2002 15:29:53 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytp02955 for ; Tue, 23 Jul 2002 15:29:53 GMT Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQmytp02949 for ; Tue, 23 Jul 2002 15:29:52 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <3VWH4DKQ>; Tue, 23 Jul 2002 08:29:48 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F815@nimbus> From: John Drake To: "'Zhi-Wei Lin'" , Don Fedyk Cc: Loa Andersson , MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 08:29:43 -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 I thought that the original comment about Windows was rather odd, since I didn't think it was up for standardization. Also, I don't think that any one is proposing to use marketshare as a metric. There was some discussion of the GMPLS implementation survey, which seemed to indicate that not too many people were interested in building products that had CR-LDP capabilities. -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Tuesday, July 23, 2002 8:18 AM To: Don Fedyk Cc: Loa Andersson; MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols Hi all, I believe that making a decision on whether RSVP-TE or CR-LDP should be on standards track based upon marketshare should NOT be how a standards organization works... As another person commented, if we're making our decision based on marketshare then Microsoft Windows would be the standard for OS, and probably also need to switch to using Word as the default format for documents... Zhi Don Fedyk wrote: > Hi Loa > > I am against the proposal on the belief it is too soon to take this > step. If we had applied this policy to the original classical RSVP > protocol it would have been information some 5 years ago. > > Cheers, > Don > From owner-mpls@UU.NET Tue Jul 23 11:42:50 2002 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 ESMTP id LAA19031 for ; Tue, 23 Jul 2002 11:42:50 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytq29728 for ; Tue, 23 Jul 2002 15:43:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytq23202; Tue, 23 Jul 2002 15:41:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytq08885 for mpls-outgoing; Tue, 23 Jul 2002 15:41:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmytq08805 for ; Tue, 23 Jul 2002 15:40: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 QQmytq18765 for ; Tue, 23 Jul 2002 15:38:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytq21602 for ; Tue, 23 Jul 2002 15:38:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytq21591 for ; Tue, 23 Jul 2002 15:38:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA16768 for ; Tue, 23 Jul 2002 11:38:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA27609 for mpls@uu.net; Tue, 23 Jul 2002 11:38:04 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmytq08693 for ; Tue, 23 Jul 2002 15:36:53 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 QQmytq13525 for ; Tue, 23 Jul 2002 15:35:28 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytq06862 for ; Tue, 23 Jul 2002 15:35:28 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmytq06856 for ; Tue, 23 Jul 2002 15:35:28 GMT Received: from ZALI-W2K.cisco.com (che-vpn1-88.cisco.com [10.86.240.88]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA29256; Tue, 23 Jul 2002 11:35:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20020723113321.0635c7f0@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Jul 2002 11:35:14 -0400 To: , "'David Charlap'" , "'Vijayanand C - CTD, Chennai.'" From: Zafar Ali Subject: RE: initiating a discussion on mpls singaling protocols Cc: "'IETF MPLS List'" In-Reply-To: <006101c23190$d6daa460$1208040a@future.futsoft.com> References: <3D3C0FEE.6000906@marconi.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10133871==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_10133871==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:32 PM 7/22/2002 +0530, sailendra mahanty wrote: >When hundreds of thousands of LSPs going ON and OFF, CRLDP implementation >may have scalability issues. As CRLDP implementation has to pay for this >with Label withdraw/release message when RSVP has to pay for this with >path/resv tear messages. Furthermore, the CPU and control bandwidth usage matters more in the transit case, than in steady state case. Thanks Regards... Zafar >-sailendra > >-----Original Message----- >From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of David >Charlap >Sent: Monday, July 22, 2002 7:30 PM >To: IETF MPLS List >Subject: Re: initiating a discussion on mpls singaling protocols > > >Vijayanand C - CTD, Chennai. wrote: > > In a network where you need to handle hundreds of thousands of LSPs, with >a > > significant percentage of them going on and off frequently, would the soft > > state approach scale effectively ? > >If refresh reduction (RFC 2961) is implemented, it will scale just as >well as any other approach will. > >Keep in mind that CR-LDP's seeming similicity is hiding all of the >overhead inherent in using TCP for reliable delivery of control-plane >packets. > >-- David > >*************************************************************************** >This message is proprietary to Future Software Limited (FSL) >and is intended solely for the use of the individual to whom it >is addressed. It may contain privileged or confidential information >and should not be circulated or used for any purpose other than for >what it is intended. > >If you have received this message in error, please notify the >originator immediately. If you are not the intended recipient, >you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. >FSL accepts no responsibility for loss or damage arising from >the use of the information transmitted by this email including >damage from virus. >*************************************************************************** --=====================_10133871==_.ALT Content-Type: text/html; charset="us-ascii" At 08:32 PM 7/22/2002 +0530, sailendra mahanty wrote:
When hundreds of thousands of LSPs going ON and OFF, CRLDP implementation
may have scalability issues. As CRLDP implementation has to pay for this
with Label withdraw/release message when RSVP has to pay for this with
path/resv tear messages.

Furthermore, the CPU and control bandwidth usage matters more in the transit case, than in steady state case.

Thanks

Regards... Zafar

-sailendra

-----Original Message-----
From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of David
Charlap
Sent: Monday, July 22, 2002 7:30 PM
To: IETF MPLS List
Subject: Re: initiating a discussion on mpls singaling protocols


Vijayanand C - CTD, Chennai. wrote:
> In a network where you need to handle hundreds of thousands of LSPs, with
a
> significant percentage of them going on and off frequently, would the soft
> state approach scale effectively ?

If refresh reduction (RFC 2961) is implemented, it will scale just as
well as any other approach will.

Keep in mind that CR-LDP's seeming similicity is hiding all of the
overhead inherent in using TCP for reliable delivery of control-plane
packets.

-- David

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
--=====================_10133871==_.ALT-- From owner-mpls@UU.NET Tue Jul 23 11:43:02 2002 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 ESMTP id LAA19044 for ; Tue, 23 Jul 2002 11:43:01 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytk18897; Tue, 23 Jul 2002 14:00:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytj12828 for mpls-outgoing; Tue, 23 Jul 2002 13:58:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytj12823 for ; Tue, 23 Jul 2002 13:58: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 QQmytj28201 for ; Tue, 23 Jul 2002 13:58:27 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytj28386 for ; Tue, 23 Jul 2002 13:58:27 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytj28368 for ; Tue, 23 Jul 2002 13:58:26 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09242 for ; Tue, 23 Jul 2002 09:58:26 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09949 for mpls@uu.net; Tue, 23 Jul 2002 09:58:26 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmysf08986 for ; Tue, 23 Jul 2002 06:24: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 QQmysf21840 for ; Tue, 23 Jul 2002 06:22:35 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmysf19542 for ; Tue, 23 Jul 2002 06:22:35 GMT Received: from mailhost.metro-optix.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.219.248.6]) id QQmysf19537 for ; Tue, 23 Jul 2002 06:22:34 GMT Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2653.19) id <3QAWM93A>; Tue, 23 Jul 2002 01:20:39 -0500 Message-ID: <99EC34181384D611BE56000347227B2C01EAB2@MAILHOSTNB> From: Apratim Mukherjee To: "'eric.gray@sandburst.com'" , "'ssaha@netplane.com'" , "'ccamp@ops.ietf.org'" Cc: "'mpls@uu.net'" Subject: Admin Status object and Style object Date: Tue, 23 Jul 2002 11:50:44 -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 Hi , A few questions on the Admin Status object and style of reservation in Generalized RSVP-TE. Lets assume that SE style is not required in GMPLS network , and we are using only FF style .In the FF style , lets say that there are lsps 1 , 2 , 3 and 4 between an ingress A and an egress B . (Of course this is possible only if multiple lsps are allowed in an FF style session in Generalized RSVP-Te but there is no specific mention in the draft that this is prohibited ). Now , egress B wants to delete lsp 2 only . It appears that this is not possible looking at the BNF of the Resv Message where there is one Admin Status _PER_ Resv Message as opposed to One Admin Status per _FLOW_DESC_ which would solve the FF problem mentioned above or One Admin Status per _FILTER_DESC_ which would solve the problem of indicating which lsp is going down for both SE and FF . Is the assumption that for all Gmpls constructed sessions using RSVP-Te there will always be a single FF lsp per session and no other combination is possible , e.g multiple lsps in _ONE_ FF Session or mutiple lsps in one SE style session ? I could find only one thread of some relevance to this discussion in the archives and so am attaching that with this mail .I would be grateful if someone could clear up this doubt . Thanks Apratim ============================================================================ ===================== < Attached mail from archive > Re: position of ADMIN_STATUS object in RESV message ---------------------------------------------------------------------------- ---- To: "Saha, Sayandeb" Subject: Re: position of ADMIN_STATUS object in RESV message From: Eric Gray Date: Mon, 19 Nov 2001 10:40:31 -0500 Cc: "'ccamp@ops.ietf.org'" References: <87009604743AD411B1F600508BA0F95971BC17@XOVER.dedham.mindspeed.com> ---------------------------------------------------------------------------- ---- Sayan, I may be looking at this somewhat simply, but I know of no reason why a transit node would need to disable an SE LSP because one of the reservations sharing the LSP at that node sets its admin status to down. Even in the case where the D bit is set, this should have the effect of removing the transit node from the particular reservation being torn down, rather than tearing down all reservations sharing resources at that transit node. You wrote: > Hi, > Section 10.1 of draft-ietf-mpls-generalized-rsvp-te-05.txt describes the > admin_status as not being a > part of the in the RESV message. > This works fine for the FF style of reservation. > But for the SE style of reservation if just one filter is taken out by > setting the D bit in admin status, > all others must go down because the admin_status applies for the entire RESV > instead of just the particular > filter in question. > Or for that matter if only one filter's state(LSP) is taken administratively > down( by setting A bit), it will now apply to all filters > Is this intended? Or is it the optical world will never do SE style > reservations? Am I missing something here? > -Sayan -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-mpls@UU.NET Tue Jul 23 11:44:03 2002 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 ESMTP id LAA19086 for ; Tue, 23 Jul 2002 11:44:02 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytq13710 for ; Tue, 23 Jul 2002 15:44:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytq12081; Tue, 23 Jul 2002 15:44:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytq09085 for mpls-outgoing; Tue, 23 Jul 2002 15:43:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytq09062 for ; Tue, 23 Jul 2002 15:43: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 QQmytq17643 for ; Tue, 23 Jul 2002 15:43:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytq00348 for ; Tue, 23 Jul 2002 15:43:16 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmytq00342 for ; Tue, 23 Jul 2002 15:43:15 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1NNK>; Tue, 23 Jul 2002 11:43:15 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267174@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'John Drake'" , "'Zhi-Wei Lin'" , Don Fedyk Cc: Loa Andersson , MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 11:43:09 -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 John, This also is not a fair characterization. :-) The survey indicates current implementations. It is not possible to infer from such a survey exactly what the surveyed vendor's interests are. Speaking as one person who has worked with several vendors now in this area, it seems much more a question of priorities rather than interests and these priorities are driven by many factors other than interest. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Tuesday, July 23, 2002 11:30 AM To: 'Zhi-Wei Lin'; Don Fedyk Cc: Loa Andersson; MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols I thought that the original comment about Windows was rather odd, since I didn't think it was up for standardization. Also, I don't think that any one is proposing to use marketshare as a metric. There was some discussion of the GMPLS implementation survey, which seemed to indicate that not too many people were interested in building products that had CR-LDP capabilities. -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Tuesday, July 23, 2002 8:18 AM To: Don Fedyk Cc: Loa Andersson; MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols Hi all, I believe that making a decision on whether RSVP-TE or CR-LDP should be on standards track based upon marketshare should NOT be how a standards organization works... As another person commented, if we're making our decision based on marketshare then Microsoft Windows would be the standard for OS, and probably also need to switch to using Word as the default format for documents... Zhi Don Fedyk wrote: > Hi Loa > > I am against the proposal on the belief it is too soon to take this > step. If we had applied this policy to the original classical RSVP > protocol it would have been information some 5 years ago. > > Cheers, > Don > From owner-mpls@UU.NET Tue Jul 23 11:45:38 2002 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 ESMTP id LAA19126 for ; Tue, 23 Jul 2002 11:45:37 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr03401 for ; Tue, 23 Jul 2002 15:46:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytr01895; Tue, 23 Jul 2002 15:45:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytr09475 for mpls-outgoing; Tue, 23 Jul 2002 15:45:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmytr09424 for ; Tue, 23 Jul 2002 15:45: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 QQmytq02336 for ; Tue, 23 Jul 2002 15:44:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytq00882 for ; Tue, 23 Jul 2002 15:44:18 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 QQmytq00874 for ; Tue, 23 Jul 2002 15:44: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 LAA09528 for ; Tue, 23 Jul 2002 11:44:16 -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 LAA05105 for ; Tue, 23 Jul 2002 11:44:17 -0400 (EDT) Message-ID: <3D3D79EA.1020200@marconi.com> Date: Tue, 23 Jul 2002 11:44:42 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <55E277B99171E041ABF5F4B1C6DDCA064C365F@haritha.hclt.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijayanand C - CTD, Chennai. wrote: > Apply the refresh reduction procedures to the scenario taking into account > the amount of state you need to store for summary refresh, triggers, refresh > msgs , ACKs/NACKs and associated back off mechanisms in RSVP-TE. Sure, you > might be able to manage but are you efficient considering that you could do > the same thing easily with CR LDP. You are forgetting about the overhead of the TCP protocol, which has to do all the same things to ensure reliable message delivery. This overhead must be added to CR-LDP, since it uses TCP. It is not added to RSVP-TE, which works over raw sockets. The fact that overhead is hidden in a different protocol layer doesn't mean it doesn't exist. -- David From owner-mpls@UU.NET Tue Jul 23 11:47:47 2002 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 ESMTP id LAA19228 for ; Tue, 23 Jul 2002 11:47:47 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr04717 for ; Tue, 23 Jul 2002 15:48:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytr03475; Tue, 23 Jul 2002 15:48:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytr09794 for mpls-outgoing; Tue, 23 Jul 2002 15:47:42 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytr09788 for ; Tue, 23 Jul 2002 15:47: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 QQmytr20840 for ; Tue, 23 Jul 2002 15:46:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr02505 for ; Tue, 23 Jul 2002 15:46:26 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytr02501 for ; Tue, 23 Jul 2002 15:46:26 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA17366; Tue, 23 Jul 2002 11:46:25 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA28972; Tue, 23 Jul 2002 11:46:25 -0400 (EDT) Message-Id: <200207231546.LAA28972@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Zhi-Wei Lin cc: Don Fedyk , Loa Andersson , MPLS wg Subject: Re: initiating a discussion on mpls signaling protocols In-reply-to: Your message of Tue, 23 Jul 2002 11:17:46 -0400. <3D3D739A.2060609@lucent.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 23 Jul 2002 11:46:25 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk > I believe that making a decision on whether RSVP-TE or CR-LDP should be on > standards track based upon marketshare should NOT be how a standards > organization works This is really a misrepresentation. They are both on the standards track. The question is whether a marketshare of approximately zero is reason to remove a document from the standards track. In fact, it's fairly common to remove documents from the standards track for just this reason. The only real issue is whether there is any realistic prospect (as opposed to, say, wishful thinking) that CR-LDP will ever gain significant deployment. A few of the folks favoring CR-LDP have actually addressed this issue, but not, it seems to me, with any great degree of confidence. From owner-mpls@UU.NET Tue Jul 23 11:53:35 2002 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 ESMTP id LAA19510 for ; Tue, 23 Jul 2002 11:53:35 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr14286 for ; Tue, 23 Jul 2002 15:54:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytr12780; Tue, 23 Jul 2002 15:53:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytr10146 for mpls-outgoing; Tue, 23 Jul 2002 15:53:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmytr10109 for ; Tue, 23 Jul 2002 15:53: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 QQmytr17425 for ; Tue, 23 Jul 2002 15:51:51 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr12123 for ; Tue, 23 Jul 2002 15:51:50 GMT Received: from lightwave.chromisys.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQmytr12116 for ; Tue, 23 Jul 2002 15:51:50 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <3VWH4DNZ>; Tue, 23 Jul 2002 08:51:49 -0700 Message-ID: <9D42C6E086250248810DCADA39CE7EFC59F817@nimbus> From: John Drake To: "'Gray, Eric'" , "'Zhi-Wei Lin'" , Don Fedyk Cc: Loa Andersson , MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 08:51:43 -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 Eric, I was using the word 'interest' in the sense of 'regard for one's advantage or benefit'. Based upon the GMPLS implementation survey, I came to the conclusion that a number of vendors thought it was to their advantage or benefit to implement RSVP-TE. Thanks, John -----Original Message----- From: Gray, Eric [mailto:egray@celoxnetworks.com] Sent: Tuesday, July 23, 2002 8:43 AM To: John Drake; 'Zhi-Wei Lin'; Don Fedyk Cc: Loa Andersson; MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols John, This also is not a fair characterization. :-) The survey indicates current implementations. It is not possible to infer from such a survey exactly what the surveyed vendor's interests are. Speaking as one person who has worked with several vendors now in this area, it seems much more a question of priorities rather than interests and these priorities are driven by many factors other than interest. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Tuesday, July 23, 2002 11:30 AM To: 'Zhi-Wei Lin'; Don Fedyk Cc: Loa Andersson; MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols I thought that the original comment about Windows was rather odd, since I didn't think it was up for standardization. Also, I don't think that any one is proposing to use marketshare as a metric. There was some discussion of the GMPLS implementation survey, which seemed to indicate that not too many people were interested in building products that had CR-LDP capabilities. -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Tuesday, July 23, 2002 8:18 AM To: Don Fedyk Cc: Loa Andersson; MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols Hi all, I believe that making a decision on whether RSVP-TE or CR-LDP should be on standards track based upon marketshare should NOT be how a standards organization works... As another person commented, if we're making our decision based on marketshare then Microsoft Windows would be the standard for OS, and probably also need to switch to using Word as the default format for documents... Zhi Don Fedyk wrote: > Hi Loa > > I am against the proposal on the belief it is too soon to take this > step. If we had applied this policy to the original classical RSVP > protocol it would have been information some 5 years ago. > > Cheers, > Don > From owner-mpls@UU.NET Tue Jul 23 11:54:20 2002 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 ESMTP id LAA19562 for ; Tue, 23 Jul 2002 11:54:20 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr15016 for ; Tue, 23 Jul 2002 15:55:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytr13506; Tue, 23 Jul 2002 15:54:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytr10471 for mpls-outgoing; Tue, 23 Jul 2002 15:54:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytr10411 for ; Tue, 23 Jul 2002 15:53: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 QQmytr04461 for ; Tue, 23 Jul 2002 15:53:33 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr12518 for ; Tue, 23 Jul 2002 15:53:32 GMT Received: from auemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQmytr12510 for ; Tue, 23 Jul 2002 15:53:32 GMT Received: from ihmail.ih.lucent.com (h135-185-56-8.lucent.com [135.185.56.8]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6NFrU108568; Tue, 23 Jul 2002 11:53:31 -0400 (EDT) Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.23]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA14036; Tue, 23 Jul 2002 10:53:29 -0500 (CDT) Message-ID: <3D3D7BF8.849D1A88@lucent.com> Date: Tue, 23 Jul 2002 09:53:28 -0600 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Zafar Ali CC: Stephen Shew , MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <4.3.2.7.2.20020723100337.022b0498@sword.cisco.com> <4.3.2.7.2.20020723110846.0220d0f0@sword.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Zafar, Not at all - just questioning your assertion that references made by other standards organizations still hold, which is not true. If IETF were to reclassify CR-LDP as informational, it would have an impact on other standards organizations considering CR-LDP based solutions. Regards, Steve Zafar Ali wrote: > > At 08:51 AM 7/23/2002 -0600, Stephen Trowbridge wrote: > > > Zafar, > > (snip) > > > So, all the references made by the other standardization activities will still > > > hold. > > In fact, for references from ITU-T Recommendations, reclassification as informational > > does raise an issue: According to Recommendation A.5, ITU-T Recommendations may not > > have normative references to informational, historical, or experimental RFCs (or > > IDs of any kind). > > Hi Stephen, > > Do you see this as a valid reason for IETF to stop "optimizing" it's progress path? > > Thanks > > Regards... Zafar > > > Regards, > > Steve Trowbridge > > Vice-chairman, ITU-T Study Group 15 From owner-mpls@UU.NET Tue Jul 23 11:56:14 2002 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 ESMTP id LAA19636 for ; Tue, 23 Jul 2002 11:56:14 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr28509 for ; Tue, 23 Jul 2002 15:57:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytr26880; Tue, 23 Jul 2002 15:56:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytr11608 for mpls-outgoing; Tue, 23 Jul 2002 15:56:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytr10694 for ; Tue, 23 Jul 2002 15:54: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 QQmytr08324 for ; Tue, 23 Jul 2002 15:53:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr25090 for ; Tue, 23 Jul 2002 15:53:48 GMT Received: from pop018.verizon.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pop018pub.verizon.net [206.46.170.212]) id QQmytr25086 for ; Tue, 23 Jul 2002 15:53:47 GMT Received: from Laptop-marty ([151.203.13.80]) by pop018.verizon.net (InterMail vM.5.01.05.05 201-253-122-126-105-20020426) with ESMTP id <20020723155347.BODS26295.pop018.verizon.net@Laptop-marty> for ; Tue, 23 Jul 2002 10:53:47 -0500 Message-ID: <200207231153470222.03E9E28D@outgoing.verizon.net> In-Reply-To: <4.3.2.7.2.20020723113321.0635c7f0@sword.cisco.com> References: <3D3C0FEE.6000906@marconi.com> <4.3.2.7.2.20020723113321.0635c7f0@sword.cisco.com> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Tue, 23 Jul 2002 11:53:47 -0400 Reply-To: mborden@acm.org From: "Marty Borden" To: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====_102743962724464=_" Sender: owner-mpls@UU.NET Precedence: bulk --=====_102743962724464=_ Content-Type: text/plain; charset="us-ascii" I am in favor of the proposal of progressing rsvp-te as standards track and making cr-ldp as informational. marty --=====_102743962724464=_ Content-Type: text/html; charset="us-ascii"
I am in favor of the proposal of progressing rsvp-te as standards track
and making cr-ldp as informational.
marty
 
--=====_102743962724464=_-- From owner-mpls@UU.NET Tue Jul 23 11:58:19 2002 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 ESMTP id LAA19707 for ; Tue, 23 Jul 2002 11:58:18 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr23630 for ; Tue, 23 Jul 2002 15:59:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytr18867; Tue, 23 Jul 2002 15:56:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytr10512 for mpls-outgoing; Tue, 23 Jul 2002 15:54:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytr10431 for ; Tue, 23 Jul 2002 15:53:59 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 QQmytr04657 for ; Tue, 23 Jul 2002 15:53:37 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr25033 for ; Tue, 23 Jul 2002 15:53:37 GMT Received: from alpha2.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.125.55.125]) id QQmytr25029 for ; Tue, 23 Jul 2002 15:53:37 GMT Received: from mail3.tellium.com (mail3.tellium.com) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 11:51:59 -0400 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id <3819ASWT>; Tue, 23 Jul 2002 11:48:20 -0400 Message-ID: <05707214338CD5119BFF0040A5B170D3E822E2@mail3.tellium.com> From: Bala Rajagopalan To: "'Soumen Sarkar'" , Loa Andersson , mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 11:48:19 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA19707 In response to the comment on OIF tracking CR-LDP: Life would be simplified for OIF and ITU-T if there were only a single standard signaling protocol. But because there are two IETF protocols, the rest of the world has to track the two (in addition to other non-IETF protocols). Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Soumen Sarkar [mailto:soumen@sasken.com] > Sent: Tuesday, July 23, 2002 3:27 AM > To: Loa Andersson; mpls@UU.NET > Subject: Re: initiating a discussion on mpls singaling protocols > > > Loa, > The response so far heavily indicated for RSVP-TE ( obviously > not because of the > merits of RSVP-TE over LDP-CR ). If one has to accept the > basic ground-rule, which is, > how many major players are pushing for RSVP-TE, one would > blindly vote for RSVP-TE. > The more esoteric view, which is, single signaling > protocol would help > everyone to concentrate better in addressing unresolved > problems in MPLS, is also > appreciably reasonable to accept. > But looking from holistic perspective, is it not too > premature at this time to > conclude on this issue unilaterally (even if there is 3/4 > majority in favour if it ) > when this particular issue affects other standard bodies too > ? We know for sure, OIF > is still tracking LDP-CR as an alternative signaling protocol > for optical control > plane. Are we not pushing something without even considering > future implication of it > ? One might say, we are not stopping anyone to use LDP-CR as > such. But none would > disagree that making IETF take a stand itself is deterrant > enough and if not that > much, it is bound to create conflict of interest between IETF > and others. > Are we really ready for this ? IETF traditionally has been > more a forum for vouching > technical solutions, not imposing it. Are we deviating from > that path with full > understanding ? > -best regards, > Soumen > > Loa Andersson wrote: > > > Heinrich, > > > > in my opinion the question is very clearly stated - is > there support for > > us (the ietf) to move the cr-ldp from standard track to > informational. > > We're "speaking for the ietf", it is more a matter of what we say ;) > > > > All, > > > > As usual we are trying to reach a rough consensus. Everyone > (i.e. the > > mpls wg) can help create this consensus by answering the question > > above. > > > > Especially it will be helpful if you were involved in specifying the > > mpls protocols, have implemented or deployed (SP) those > protocols, and > > take the time to respond. > > > > I will be ready to give the first extensive tally mid this week. > > Currently the count is > > yes: 30 no: 7, > > if you normalize those e.g. by counting each company once it is > > yes: 21 no: 4 > > > > Disclaimer: Given that I've managed to decipher the > sometimes cryptic > > mails correctly :o) > > > > /Loa > > > > Hummel Heinrich wrote: > > > > > I think, the IETF can only speak for itself. There may > be other standardization > > > > >bodies (ITU-T, MPLS Forum) which may fill > > > the gap. > > > > > > Heinrich Hummel > > > Siemens AG > > > > > > > -- > > 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 Tue Jul 23 12:00:32 2002 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 ESMTP id MAA19876 for ; Tue, 23 Jul 2002 12:00:31 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyts09186 for ; Tue, 23 Jul 2002 16:01:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyts07597; Tue, 23 Jul 2002 16:00:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyts13211 for mpls-outgoing; Tue, 23 Jul 2002 16:00:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytr13196 for ; Tue, 23 Jul 2002 15:59: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 QQmytr01487 for ; Tue, 23 Jul 2002 15:58:18 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytr21937 for ; Tue, 23 Jul 2002 15:58:14 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQmytr21257 for ; Tue, 23 Jul 2002 15:57:54 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA16021; Tue, 23 Jul 2002 17:57:28 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA15625; Tue, 23 Jul 2002 17:57:46 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 17:57:43 +0200 Message-ID: From: Hummel Heinrich To: "'Gray, Eric'" , "'avri'" Cc: MPLS wg Subject: AW: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 17:57:44 +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 MAA19876 Eric, So excuse me. I accept your notes. But let me repeat my technical point: Building hierarchical mp2p LSPs, from the egress towards a set of ingress nodes, i.e. building a sink tree out of LSPs. Here downstream unsolicited mode is appropriate. So we need LDP. But because existing LSPs have to be concatenated (by label switching) we need their LSP-IDs. And this is provided by CR-LDP. It takes a lot more to create RSVP-TE Downstream Unsolicited mode. Heinrich -----Ursprüngliche Nachricht----- Von: Gray, Eric [mailto:egray@celoxnetworks.com] Gesendet: Dienstag, 23. Juli 2002 17:27 An: 'Hummel Heinrich'; 'avri' Cc: MPLS wg Betreff: RE: initiating a discussion on mpls singaling protocols Heinrich, I don't think this is a fair characterization. Several draft authors have participated in work to develop CR-LDP extensions who have no real interest in CR-LDP. This has been done - IMO - out of a sense of responsible protocol development rather than out of interest in progressing both signaling protocols. Perhaps this is what really needs to change. If a specific draft author only wishes to work with one signaling protocol, then he or she should be able to simply do so. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] Sent: Tuesday, July 23, 2002 11:13 AM To: 'avri' Cc: MPLS wg Subject: AW: initiating a discussion on mpls singaling protocols Well spoken. Additionally, all those who do not care for CR-LDP have hardly contributed in the past nor will they contribute in the future to extend routing protocols for the sake of CR-LDP. This sweat is up to the CR-LDP supporters. It is not honest to complain about the burden carried by the others. Heinrich -----Ursprüngliche Nachricht----- Von: avri [mailto:avri@sm.luth.se] Gesendet: Dienstag, 23. Juli 2002 15:26 Cc: MPLS wg Betreff: Re: initiating a discussion on mpls singaling protocols This seems to me a very strange proposal. And in fact seems to be a perversion of the IETF standards process as i understand it. If things are as argued, then RSVP-TE will progress to draft standard and then to standard, while CR-LDP remains a proposed standard. If it languishes long enough in the proposed state, without significant deployment or utility, then it would seem appropriate to transition it to historic at some point in the future. Taking it to informational at this point seems a fairly blatant political move without technical merit. At best it is an administrative sleight of hand that could strange repercussions as a precedent. Is the IETF going to embark next on an effort to define all protocol duplication out of existence by voting on which alternative to make informational? I would suggest (as voting is not something I thought the IETF did) that both protocols remain as ps. If CR-LDP withers on the vine because it has no utility, so be it. Voting to change its status seems inappropriate to me. a. From owner-mpls@UU.NET Tue Jul 23 12:06:40 2002 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 ESMTP id MAA20308 for ; Tue, 23 Jul 2002 12:06:40 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyts04863 for ; Tue, 23 Jul 2002 16:07:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyts02854; Tue, 23 Jul 2002 16:06:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyts26463 for mpls-outgoing; Tue, 23 Jul 2002 16:05:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyts26452 for ; Tue, 23 Jul 2002 16:05: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 QQmyts13545 for ; Tue, 23 Jul 2002 16:04:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyts01747 for ; Tue, 23 Jul 2002 16:04:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyts01740 for ; Tue, 23 Jul 2002 16:04:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA18800 for ; Tue, 23 Jul 2002 12:04:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA02887 for mpls@uu.net; Tue, 23 Jul 2002 12:04:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyts18838 for ; Tue, 23 Jul 2002 16:02:27 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 QQmyts07596 for ; Tue, 23 Jul 2002 16:01:29 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyts28060 for ; Tue, 23 Jul 2002 16:01:23 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmyts27565 for ; Tue, 23 Jul 2002 16:01:10 GMT Received: (qmail 26436 invoked by uid 104); 23 Jul 2002 16:01:04 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 0.475662 secs); 23 Jul 2002 16:01:04 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 23 Jul 2002 16:01:03 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6NG13c14058; Tue, 23 Jul 2002 09:01:03 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 09:01:03 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0374F@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'John Drake'" , "'Gray, Eric'" , "'Zhi-Wei Lin'" , Don Fedyk Cc: Loa Andersson , MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 09:00:53 -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 > Based upon the GMPLS implementation survey, I came to the > conclusion that a > number of vendors thought it was to their advantage or > benefit to implement > RSVP-TE. That advantage or benefit could have been related to the existing RSVP-TE market share. -Shahram > > Thanks, > > John > > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Tuesday, July 23, 2002 8:43 AM > To: John Drake; 'Zhi-Wei Lin'; Don Fedyk > Cc: Loa Andersson; MPLS wg > Subject: RE: initiating a discussion on mpls singaling protocols > > > John, > > This also is not a fair characterization. :-) > > The survey indicates current implementations. It > is not possible to infer from such a survey exactly what > the surveyed vendor's interests are. Speaking as one > person who has worked with several vendors now in this > area, it seems much more a question of priorities rather > than interests and these priorities are driven by many > factors other than interest. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Tuesday, July 23, 2002 11:30 AM > To: 'Zhi-Wei Lin'; Don Fedyk > Cc: Loa Andersson; MPLS wg > Subject: RE: initiating a discussion on mpls singaling protocols > > I thought that the original comment about Windows was rather > odd, since I > didn't think it was up for standardization. > > Also, I don't think that any one is proposing to use marketshare as a > metric. There was some discussion of the GMPLS > implementation survey, which > seemed to indicate that not too many people were interested > in building > products that had CR-LDP capabilities. > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Tuesday, July 23, 2002 8:18 AM > To: Don Fedyk > Cc: Loa Andersson; MPLS wg > Subject: Re: initiating a discussion on mpls singaling protocols > > > Hi all, > > I believe that making a decision on whether RSVP-TE or CR-LDP > should be on > standards track based upon marketshare should NOT be how a standards > organization works... As another person commented, if we're > making our > decision based on marketshare then Microsoft Windows would be > the standard > for OS, and probably also need to switch to using Word as the > default format > for documents... > > Zhi > > > Don Fedyk wrote: > > > Hi Loa > > > > I am against the proposal on the belief it is too soon to take this > > step. If we had applied this policy to the original classical RSVP > > protocol it would have been information some 5 years ago. > > > > Cheers, > > Don > > > From owner-mpls@UU.NET Tue Jul 23 12:10:10 2002 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 ESMTP id MAA20651 for ; Tue, 23 Jul 2002 12:10:10 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyts02823 for ; Tue, 23 Jul 2002 16:11:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyts01497; Tue, 23 Jul 2002 16:10:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyts06452 for mpls-outgoing; Tue, 23 Jul 2002 16:10:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyts06276 for ; Tue, 23 Jul 2002 16:10: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 QQmyts20905 for ; Tue, 23 Jul 2002 16:07:17 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyts04222 for ; Tue, 23 Jul 2002 16:07:12 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyts04076 for ; Tue, 23 Jul 2002 16:07:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA19057 for ; Tue, 23 Jul 2002 12:07:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA03523 for mpls@uu.net; Tue, 23 Jul 2002 12:07:03 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyts26541 for ; Tue, 23 Jul 2002 16:06:12 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 QQmyts24882 for ; Tue, 23 Jul 2002 16:05:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyts16569 for ; Tue, 23 Jul 2002 16:05:28 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmyts16531 for ; Tue, 23 Jul 2002 16:05:27 GMT Received: from ZALI-W2K.cisco.com (che-vpn1-88.cisco.com [10.86.240.88]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id MAA01378; Tue, 23 Jul 2002 12:05:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20020723115506.022c0250@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Jul 2002 12:05:13 -0400 To: Loa Andersson , MPLS wg From: Zafar Ali Subject: Re: initiating a discussion on mpls singaling protocols Cc: George Swallow , scott Giles , "Wijnen, Bert (Bert)" In-Reply-To: <3D36A98A.7070103@utfors.se> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11932427==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_11932427==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Fellows, Since the myth that CR-LDP is more scalable than RSVP-TE or that CR-LDP is technical more sound idea than RSVP-TE is mentioned many times on this tread, a few key points that are already raised by many on this list, but I see people keep making bold statements like CR-LDP is more scalable than RSVP-TE or is technically better than its RSVP-TE counter part. By just moving the responsibilities from one layer (signaling) to another layer (TCP), one cannot say that they have a technically more profound solution. Not to mention TCP also have refreshes and acknowledgements, but it's just that they are hidden. In short, when people say that CR-LDP is more scalable, are they stating that building a reliable layer on top of an unreliable network comes for FREE? Not to mention, relaying on the TCP layer to ensure data validity is an issue on its own (E.g., just look at the fault tolerant draft (I'll be back type of scheme), where signaling layer try to solve the problem of relying on TCP). With refresh reduction, the amount of traffic is minimized and we have evidence from field, practical experiments (not simulations) that this is NOT an issue. So, I think the argument that RSVP-TE does not scale due to refreshes is only academic in nature. Anyone who argues that CR-LDP is more scalable should provide evidence based on every packet that is sent by CR-LDP (including TCP control traffic) vs. every packet that is sent by RSVP, both in steady state and in transient conditions. Please also don't forget that CPU and control bandwidth usage matters more in the transit case, than in steady state case. In transit, in general, you will see more packets flowing in CR-LDP case than in RSVP-TE case. RSVP refreshes is a FEATURE and is in sprite of making the protocol soft state in nature. Soft state vs. (so-called) hard state is another non-issue. Each approach has its advantages and anyone stating hard state is better than soft state can never proof it quantitatively. Thanks Regards... Zafar --=====================_11932427==_.ALT Content-Type: text/html; charset="us-ascii" Dear Fellows,

Since the myth that CR-LDP is more scalable than RSVP-TE or that CR-LDP is technical more sound idea than RSVP-TE is mentioned many times on this tread, a few key points that are already raised by many on this list, but I see people keep making bold statements like CR-LDP is more scalable than RSVP-TE or is technically better than its RSVP-TE counter part.

By just moving the responsibilities from one layer (signaling) to another layer (TCP), one cannot say that they have a technically more profound solution. Not to mention TCP also have refreshes and acknowledgements, but it’s just that they are hidden.

In short, when people say that CR-LDP is more scalable, are they stating that building a reliable layer on top of an unreliable network comes for FREE? Not to mention, relaying on the TCP layer to ensure data validity is an issue on its own (E.g., just look at the fault tolerant draft (I’ll be back type of scheme), where signaling layer try to solve the problem of relying on TCP). 

With refresh reduction, the amount of traffic is minimized and we have evidence from field, practical experiments (not simulations) that this is NOT an issue. So, I think the argument that RSVP-TE does not scale due to refreshes is only academic in nature.

Anyone who argues that CR-LDP is more scalable should provide evidence based on every packet that is sent by CR-LDP (including TCP control traffic) vs. every packet that is sent by RSVP, both in steady state and in transient conditions. Please also don't forget that CPU and control bandwidth usage matters more in the transit case, than in steady state case. In transit, in general, you will see more packets flowing in CR-LDP case than in RSVP-TE case.

RSVP refreshes is a FEATURE and is in sprite of making the protocol soft state in nature.

Soft state vs. (so-called) hard state is another non-issue. Each approach has its advantages and anyone stating hard state is better than soft state can never proof it quantitatively.

Thanks

Regards... Zafar
--=====================_11932427==_.ALT-- From owner-mpls@UU.NET Tue Jul 23 12:10:20 2002 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 ESMTP id MAA20693 for ; Tue, 23 Jul 2002 12:10:19 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyts22170 for ; Tue, 23 Jul 2002 16:11:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyts20429; Tue, 23 Jul 2002 16:10:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyts06364 for mpls-outgoing; Tue, 23 Jul 2002 16:10:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyts06275 for ; Tue, 23 Jul 2002 16:09: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 QQmyts18824 for ; Tue, 23 Jul 2002 16:09:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyts19764 for ; Tue, 23 Jul 2002 16:09:57 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmyts19760 for ; Tue, 23 Jul 2002 16:09:57 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1NS5>; Tue, 23 Jul 2002 12:09:56 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267178@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'avri'" Cc: MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 12:09:51 -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 Avri makes a very good point here. I think the implementation survey makes it obvious that we should progress RSVP-TE (and related work) to Draft Standard. It seems equally clear that we should not do so for CR-LDP at this point. Letting CR-LDP die on the vine certainly seems in keeping with what the IETF has done in the past. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: avri [mailto:avri@sm.luth.se] Sent: Tuesday, July 23, 2002 9:26 AM Cc: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols This seems to me a very strange proposal. And in fact seems to be a perversion of the IETF standards process as i understand it. If things are as argued, then RSVP-TE will progress to draft standard and then to standard, while CR-LDP remains a proposed standard. If it languishes long enough in the proposed state, without significant deployment or utility, then it would seem appropriate to transition it to historic at some point in the future. Taking it to informational at this point seems a fairly blatant political move without technical merit. At best it is an administrative sleight of hand that could strange repercussions as a precedent. Is the IETF going to embark next on an effort to define all protocol duplication out of existence by voting on which alternative to make informational? I would suggest (as voting is not something I thought the IETF did) that both protocols remain as ps. If CR-LDP withers on the vine because it has no utility, so be it. Voting to change its status seems inappropriate to me. a. From owner-mpls@UU.NET Tue Jul 23 12:15:23 2002 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 ESMTP id MAA20945 for ; Tue, 23 Jul 2002 12:15:23 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytt16184 for ; Tue, 23 Jul 2002 16:16:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytt15066; Tue, 23 Jul 2002 16:16:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytt08005 for mpls-outgoing; Tue, 23 Jul 2002 16:15:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytt07999 for ; Tue, 23 Jul 2002 16:15: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 QQmytt14120 for ; Tue, 23 Jul 2002 16:15:21 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytp25104 for ; Tue, 23 Jul 2002 15:18:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA15289 for ; Tue, 23 Jul 2002 11:18:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA24282 for mpls@uu.net; Tue, 23 Jul 2002 11:18:04 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytp06459 for ; Tue, 23 Jul 2002 15:15: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 QQmyto29791 for ; Tue, 23 Jul 2002 15:13:45 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyto21984 for ; Tue, 23 Jul 2002 15:13:45 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmyto21979 for ; Tue, 23 Jul 2002 15:13:45 GMT Received: from ZALI-W2K.cisco.com (che-vpn1-88.cisco.com [10.86.240.88]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA27508; Tue, 23 Jul 2002 11:12:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20020723110846.0220d0f0@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Jul 2002 11:12:52 -0400 To: Stephen Trowbridge From: Zafar Ali Subject: Re: initiating a discussion on mpls singaling protocols Cc: Stephen Shew , MPLS wg In-Reply-To: <3D3D6D6C.28BB4427@lucent.com> References: <4.3.2.7.2.20020723100337.022b0498@sword.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8792442==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_8792442==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:51 AM 7/23/2002 -0600, Stephen Trowbridge wrote: >Zafar, >(snip) > > So, all the references made by the other standardization activities > will still > > hold. >In fact, for references from ITU-T Recommendations, reclassification as >informational >does raise an issue: According to Recommendation A.5, ITU-T >Recommendations may not >have normative references to informational, historical, or experimental >RFCs (or >IDs of any kind). Hi Stephen, Do you see this as a valid reason for IETF to stop "optimizing" it's progress path? Thanks Regards... Zafar >Regards, >Steve Trowbridge >Vice-chairman, ITU-T Study Group 15 --=====================_8792442==_.ALT Content-Type: text/html; charset="us-ascii" At 08:51 AM 7/23/2002 -0600, Stephen Trowbridge wrote:
Zafar,
(snip)
> So, all the references made by the other standardization activities will still
> hold.
In fact, for references from ITU-T Recommendations, reclassification as informational
does raise an issue: According to Recommendation A.5, ITU-T Recommendations may not
have normative references to informational, historical, or experimental RFCs (or
IDs of any kind).

Hi Stephen,

Do you see this as a valid reason for IETF to stop "optimizing" it's progress path?

Thanks

Regards... Zafar

Regards,
Steve Trowbridge
Vice-chairman, ITU-T Study Group 15
--=====================_8792442==_.ALT-- From owner-mpls@UU.NET Tue Jul 23 12:17:02 2002 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 ESMTP id MAA21036 for ; Tue, 23 Jul 2002 12:17:02 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytt06612 for ; Tue, 23 Jul 2002 16:18:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyts26531; Tue, 23 Jul 2002 16:13:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyts07171 for mpls-outgoing; Tue, 23 Jul 2002 16:12:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyts06889 for ; Tue, 23 Jul 2002 16:11: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 QQmyts28994 for ; Tue, 23 Jul 2002 16:10:45 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyts21055 for ; Tue, 23 Jul 2002 16:10:42 GMT Received: from griffin.host4u.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQmyts20956 for ; Tue, 23 Jul 2002 16:10:39 GMT Received: from LB-LAPTOP.labn.net (labn.net [209.204.240.82]) by griffin.host4u.net (8.11.6/8.11.6) with ESMTP id g6NGAZE32292; Tue, 23 Jul 2002 11:10:35 -0500 Message-Id: <4.3.2.7.2.20020723113755.0341b508@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Jul 2002 12:10:28 -0400 To: Hummel Heinrich From: Lou Berger Subject: Re: AW: initiating a discussion on mpls singaling protocols Cc: MPLS wg 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 MAA21036 Heinrich, This is not really correct. I (and others) have spent quite a bit of time to ensure that functionality added to one protocol is added to the other. The reason for this has been so that the technology can advance without having to get mired down in the protocol wars that we went through in the early days of MPLS. At this point, I think both protocols deliver equivalent functionality. Both protocols have their plusses and minuses that can be argued for as long as folks have energy. But IMO, we're at the point where differences in robustness and scalability are now in the domain of the quality of implementation and not resulting of the base protocol. Going forward, I think that having just one protocol to deliver a piece of functionality so that we don't have to duplicate work is goodness. Based on the GMPLS implementation survey, I think that GMPLS-CR-LDP should move forward as informational. I think that reclassifying CR-LDP to informational (or historic, if that's the right procedural thing) also makes sense based on market acceptance. Lou At 11:12 AM 7/23/2002, Hummel Heinrich wrote: >Well spoken. >Additionally, all those who do not care for CR-LDP have hardly contributed >in the past nor will they contribute >in the future to extend routing protocols for the sake of CR-LDP. This >sweat is up to the CR-LDP supporters. >It is not honest to complain about the burden carried by the others. >Heinrich > >-----Ursprüngliche Nachricht----- >Von: avri [mailto:avri@sm.luth.se] >Gesendet: Dienstag, 23. Juli 2002 15:26 >Cc: MPLS wg >Betreff: Re: initiating a discussion on mpls singaling protocols > > > > >This seems to me a very strange proposal. And in fact seems to be >a perversion of the IETF standards process as i understand it. > >If things are as argued, then RSVP-TE will progress to draft standard >and then to standard, while CR-LDP remains a proposed standard. If >it languishes long enough in the proposed state, without significant >deployment or utility, then it would seem appropriate to transition it >to historic at some point in the future. > >Taking it to informational at this point seems a fairly blatant political >move without technical merit. At best it is an administrative sleight >of hand that could strange repercussions as a precedent. Is the IETF >going to embark next on an effort to define all protocol duplication >out of existence by voting on which alternative to make informational? > >I would suggest (as voting is not something I thought the IETF did) that >both protocols remain as ps. If CR-LDP withers on the vine because it has >no utility, so be it. Voting to change its status seems inappropriate to >me. > >a. From owner-mpls@UU.NET Tue Jul 23 12:20:41 2002 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 ESMTP id MAA21273 for ; Tue, 23 Jul 2002 12:20:41 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytt12160 for ; Tue, 23 Jul 2002 16:21:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytt11501; Tue, 23 Jul 2002 16:21:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytt08649 for mpls-outgoing; Tue, 23 Jul 2002 16:20:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytt08641 for ; Tue, 23 Jul 2002 16:20:07 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 QQmytt27712 for ; Tue, 23 Jul 2002 16:19:24 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytt13566 for ; Tue, 23 Jul 2002 16:19:23 GMT Received: from zcars04e.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmytt13562 for ; Tue, 23 Jul 2002 16:19:23 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6NGIrU27172; Tue, 23 Jul 2002 12:18:53 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 12:18:53 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E603104F6D@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: George Swallow Cc: Loa Andersson , MPLS wg , swallow@cisco.com Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 12:18:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23264.A0749AF0" 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_01C23264.A0749AF0 Content-Type: text/plain George September 1997 - July 2002 4.8 years then, I rounded up. The point was, it is too soon IMHO. Don -----Original Message----- From: George Swallow [mailto:swallow@cisco.com] S > I am against the proposal on the belief it is too soon to take this > step. If we had applied this policy to the original classical RSVP > protocol it would have been information some 5 years ago. Wow! RSVP wasn't even an RFC then. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 ------_=_NextPart_001_01C23264.A0749AF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: initiating a discussion on mpls singaling protocols

George

September 1997 - July 2002  4.8 years then, I = rounded up.
The point was, it is too soon IMHO.

Don

-----Original Message-----
From: George Swallow [mailto:swallow@cisco.com]
S


> I am against the proposal on the belief it is = too soon to take this
> step. If we had applied this policy to the = original classical RSVP
> protocol it would have been information some 5 = years ago.

Wow! RSVP wasn't even an RFC then.

...George

=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=3D=3D=3D=3D=3D=3D
George Swallow       = Cisco = Systems           = ;       (978) 497-8143
          &nb= sp;          250 Apollo = Drive
          &nb= sp;          Chelmsford, = Ma 01824

------_=_NextPart_001_01C23264.A0749AF0-- From owner-mpls@UU.NET Tue Jul 23 12:22:45 2002 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 ESMTP id MAA21373 for ; Tue, 23 Jul 2002 12:22:45 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytt17061 for ; Tue, 23 Jul 2002 16:23:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytt13216; Tue, 23 Jul 2002 16:22:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytt08662 for mpls-outgoing; Tue, 23 Jul 2002 16:20:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytt08657 for ; Tue, 23 Jul 2002 16:20: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 QQmytt14357 for ; Tue, 23 Jul 2002 16:19:43 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytt08692 for ; Tue, 23 Jul 2002 16:19:42 GMT Received: from mail2.orchestream.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.orchestream.com [195.153.64.126]) id QQmytt08683 for ; Tue, 23 Jul 2002 16:19:42 GMT Received: from rimmer.orchestream.com (unverified) by mail2.orchestream.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 23 Jul 2002 17:19:32 +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 RAA00977 for ; Tue, 23 Jul 2002 17:19:41 +0100 Received: by S1000.orchestream.com with Internet Mail Service (5.5.2653.19) id <31D2MJ6V>; Tue, 23 Jul 2002 17:19:41 +0100 Message-ID: <8AEA6B34A5AF2D4ABECB4E9351DAE6981CF176@S1000.orchestream.com> From: "Gibson, Mark" Cc: MPLS wg Subject: RE: initiating a discussion on mpls signaling protocols Date: Tue, 23 Jul 2002 17:19:41 +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 > I believe that making a decision on whether RSVP-TE or CR-LDP should be on > standards track based upon marketshare should NOT be how a standards > organization works This is really a misrepresentation. They are both on the standards track. The question is whether a marketshare of approximately zero is reason to remove a document from the standards track. In fact, it's fairly common to remove documents from the standards track for just this reason. The only real issue is whether there is any realistic prospect (as opposed to, say, wishful thinking) that CR-LDP will ever gain significant deployment. A few of the folks favoring CR-LDP have actually addressed this issue, but not, it seems to me, with any great degree of confidence. [MG] The fact that CR-LDP has little market share should be no surprise at all. Given that the two dominant core router manufacturers offer only the RSVP-TE solution will tend to ensure this becomes the de facto standard whatever the technical rights and wrongs of the implementation. To stop this process would require the IETF to enforce a fair fight-off by requiring all MPLS-TE LSR manufacturers to supply both protocols and have the market decide. This is clearly an unsustainable situation. Also, given that, from a service point of view, both offer broadly the same functions, there is no drive from service providers to require one over the other to drive the need for CR-LDP support. (Neither have vrf-to-tunnel mapping support but that's another issue...) [MG] So, using the absence of a clear service requirement *and* support from vendors for the implementation of both protocols, there seems little point in progressing two standards. That's what the market share would dictate. [MG] But surely the IETF is not in the business of deciding which protocols should be used, rather ensuring that those developed are done so to the most exacting of standards. Therefore there should be no decision to move CR-LDP to informational but move it to historical once it becomes so. [MG] If not, can we only have one PWE3 protocol please, one IGP please, one L2VPN discovery protocol please.... Mark From owner-mpls@UU.NET Tue Jul 23 12:28:07 2002 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 ESMTP id MAA21581 for ; Tue, 23 Jul 2002 12:28:07 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytt00385 for ; Tue, 23 Jul 2002 16:29:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytt28658; Tue, 23 Jul 2002 16:28:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytt09280 for mpls-outgoing; Tue, 23 Jul 2002 16:27:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytt09266 for ; Tue, 23 Jul 2002 16:27: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 QQmytt26286 for ; Tue, 23 Jul 2002 16:24:44 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytt17187 for ; Tue, 23 Jul 2002 16:24:44 GMT Received: from auemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQmytt17177 for ; Tue, 23 Jul 2002 16:24:43 GMT Received: from ihmail.ih.lucent.com (h135-185-56-8.lucent.com [135.185.56.8]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6NGOf123668; Tue, 23 Jul 2002 12:24:41 -0400 (EDT) Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.23]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA26961; Tue, 23 Jul 2002 11:24:39 -0500 (CDT) Message-ID: <3D3D8346.526BFAD4@lucent.com> Date: Tue, 23 Jul 2002 10:24:38 -0600 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bala Rajagopalan CC: "'Soumen Sarkar'" , Loa Andersson , mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <05707214338CD5119BFF0040A5B170D3E822E2@mail3.tellium.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 MAA21581 Bala, There is certainly no issue if both organizations make the same decision about which protocol(s) is/are standards track. There is only an issue if they make different decisions. If a change is to be made in IETF with respect to which protocol(s) is/are standards track, it would be worth sending a communication to ITU-T with the proposal and reasoning before this is finalized to see if an aligned decision could be reached. Regards, Steve Bala Rajagopalan wrote: > > In response to the comment on OIF tracking CR-LDP: > > Life would be simplified for OIF and ITU-T if > there were only a single standard signaling protocol. > But because there are two IETF protocols, the rest of the > world has to track the two (in addition to other > non-IETF protocols). > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > > -----Original Message----- > > From: Soumen Sarkar [mailto:soumen@sasken.com] > > Sent: Tuesday, July 23, 2002 3:27 AM > > To: Loa Andersson; mpls@UU.NET > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > > > Loa, > > The response so far heavily indicated for RSVP-TE ( obviously > > not because of the > > merits of RSVP-TE over LDP-CR ). If one has to accept the > > basic ground-rule, which is, > > how many major players are pushing for RSVP-TE, one would > > blindly vote for RSVP-TE. > > The more esoteric view, which is, single signaling > > protocol would help > > everyone to concentrate better in addressing unresolved > > problems in MPLS, is also > > appreciably reasonable to accept. > > But looking from holistic perspective, is it not too > > premature at this time to > > conclude on this issue unilaterally (even if there is 3/4 > > majority in favour if it ) > > when this particular issue affects other standard bodies too > > ? We know for sure, OIF > > is still tracking LDP-CR as an alternative signaling protocol > > for optical control > > plane. Are we not pushing something without even considering > > future implication of it > > ? One might say, we are not stopping anyone to use LDP-CR as > > such. But none would > > disagree that making IETF take a stand itself is deterrant > > enough and if not that > > much, it is bound to create conflict of interest between IETF > > and others. > > Are we really ready for this ? IETF traditionally has been > > more a forum for vouching > > technical solutions, not imposing it. Are we deviating from > > that path with full > > understanding ? > > -best regards, > > Soumen > > > > Loa Andersson wrote: > > > > > Heinrich, > > > > > > in my opinion the question is very clearly stated - is > > there support for > > > us (the ietf) to move the cr-ldp from standard track to > > informational. > > > We're "speaking for the ietf", it is more a matter of what we say ;) > > > > > > All, > > > > > > As usual we are trying to reach a rough consensus. Everyone > > (i.e. the > > > mpls wg) can help create this consensus by answering the question > > > above. > > > > > > Especially it will be helpful if you were involved in specifying the > > > mpls protocols, have implemented or deployed (SP) those > > protocols, and > > > take the time to respond. > > > > > > I will be ready to give the first extensive tally mid this week. > > > Currently the count is > > > yes: 30 no: 7, > > > if you normalize those e.g. by counting each company once it is > > > yes: 21 no: 4 > > > > > > Disclaimer: Given that I've managed to decipher the > > sometimes cryptic > > > mails correctly :o) > > > > > > /Loa > > > > > > Hummel Heinrich wrote: > > > > > > > I think, the IETF can only speak for itself. There may > > be other standardization > > > > > > >bodies (ITU-T, MPLS Forum) which may fill > > > > the gap. > > > > > > > > Heinrich Hummel > > > > Siemens AG > > > > > > > > > > -- > > > 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 Tue Jul 23 12:32:26 2002 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 ESMTP id MAA21813 for ; Tue, 23 Jul 2002 12:32:22 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytu02719 for ; Tue, 23 Jul 2002 16:33:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytu00955; Tue, 23 Jul 2002 16:32:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytu09588 for mpls-outgoing; Tue, 23 Jul 2002 16:32:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytu09582 for ; Tue, 23 Jul 2002 16:32:02 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 QQmytu08726 for ; Tue, 23 Jul 2002 16:31:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytu20852 for ; Tue, 23 Jul 2002 16:31:58 GMT Received: from mail.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQmytu20836 for ; Tue, 23 Jul 2002 16:31:58 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g6NGQEc05471; Tue, 23 Jul 2002 18:26:15 +0200 Received: from alcatel.be ([138.203.67.226]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002072318284671:5390 ; Tue, 23 Jul 2002 18:28:46 +0200 Message-ID: <3D3D8458.A2543AAC@alcatel.be> Date: Tue, 23 Jul 2002 18:29:12 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Zafar Ali Cc: Stephen Shew , MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <4.3.2.7.2.20020723100337.022b0498@sword.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/23/2002 18:28:46, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/23/2002 18:30:34 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 MAA21813 hi zafar, you have made a major point here "Not to mention, I don't think IETF is bound to other standardization committees in making its decision." i should also add "implementation bodies"... take for instance the oif uni as mentioned before it was clear since the london meeting that potential changes may occur in these i-ds taken by the oif community... it was clearly said at that time that decisions taken at the ietf will be fully and completely independent of the usage of the corresponding documents in other bodies... same rules should be applicable now as well... thanks, - dimitri. Zafar Ali wrote: > > At 03:43 PM 7/22/2002 -0400, Stephen Shew wrote: > > > I would like to speak against the proposal to make CR-LDP > > informational. Signalling is not the only function in IP in which > > there are multiple (standards track) protocols. Why insist on > > converging to one? Also, CR-LDP is found in other specifications > > (e.g., OIF UNI 1.0, ITU-T Y.1310) whose bodies want to continue > > evolving its functionality. In particular, the ITU-T is using GMPLS > > CR-LDP in its draft recommendation G.7713.3 (CR-LDP based signalling > > for ASON). > > Couple of points here… > > O-UNI (rightly) provides alternative of using RSVP-TE signaling and if > you do a survey on O-UNI implementation, I can bet you that you will > find the similar results that RSVP-TE is by-far the common > implementation. > > By making the CR-LDP informational, one is NOT removing all the > references to it. This is an already matured activity. So, all the > references made by the other standardization activities will still > hold. In fact, such organizations will have more control and be > happier to know that they are NOT working on a ground that is in flux. > Not to mention, I don't think IETF is bound to other standardization > committees in making its decision. > > Thanks > > Regards… Zafar -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Tue Jul 23 12:34:45 2002 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 ESMTP id MAA21931 for ; Tue, 23 Jul 2002 12:34:45 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytu10447 for ; Tue, 23 Jul 2002 16:35:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytu08529; Tue, 23 Jul 2002 16:34:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytu09615 for mpls-outgoing; Tue, 23 Jul 2002 16:33:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytu09606 for ; Tue, 23 Jul 2002 16:32: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 QQmytu20884 for ; Tue, 23 Jul 2002 16:32:19 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytu21003 for ; Tue, 23 Jul 2002 16:32:18 GMT Received: from mail.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQmytu20998 for ; Tue, 23 Jul 2002 16:32:18 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g6NGQDc05464; Tue, 23 Jul 2002 18:26:13 +0200 Received: from alcatel.be ([138.203.67.226]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002072318262274:5385 ; Tue, 23 Jul 2002 18:26:22 +0200 Message-ID: <3D3D83C8.3DE0AA1A@alcatel.be> Date: Tue, 23 Jul 2002 18:26:48 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bala Rajagopalan Cc: "'Soumen Sarkar'" , Loa Andersson , mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <05707214338CD5119BFF0040A5B170D3E822E2@mail3.tellium.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/23/2002 18:26:22, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/23/2002 18:30:28 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 MAA21931 i concur with you in addition, it will avoid for these bodies to have to consider at some point in time an interworking function... - dimitri. Bala Rajagopalan wrote: > > In response to the comment on OIF tracking CR-LDP: > > Life would be simplified for OIF and ITU-T if > there were only a single standard signaling protocol. > But because there are two IETF protocols, the rest of the > world has to track the two (in addition to other > non-IETF protocols). > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > > -----Original Message----- > > From: Soumen Sarkar [mailto:soumen@sasken.com] > > Sent: Tuesday, July 23, 2002 3:27 AM > > To: Loa Andersson; mpls@UU.NET > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > > > Loa, > > The response so far heavily indicated for RSVP-TE ( obviously > > not because of the > > merits of RSVP-TE over LDP-CR ). If one has to accept the > > basic ground-rule, which is, > > how many major players are pushing for RSVP-TE, one would > > blindly vote for RSVP-TE. > > The more esoteric view, which is, single signaling > > protocol would help > > everyone to concentrate better in addressing unresolved > > problems in MPLS, is also > > appreciably reasonable to accept. > > But looking from holistic perspective, is it not too > > premature at this time to > > conclude on this issue unilaterally (even if there is 3/4 > > majority in favour if it ) > > when this particular issue affects other standard bodies too > > ? We know for sure, OIF > > is still tracking LDP-CR as an alternative signaling protocol > > for optical control > > plane. Are we not pushing something without even considering > > future implication of it > > ? One might say, we are not stopping anyone to use LDP-CR as > > such. But none would > > disagree that making IETF take a stand itself is deterrant > > enough and if not that > > much, it is bound to create conflict of interest between IETF > > and others. > > Are we really ready for this ? IETF traditionally has been > > more a forum for vouching > > technical solutions, not imposing it. Are we deviating from > > that path with full > > understanding ? > > -best regards, > > Soumen > > > > Loa Andersson wrote: > > > > > Heinrich, > > > > > > in my opinion the question is very clearly stated - is > > there support for > > > us (the ietf) to move the cr-ldp from standard track to > > informational. > > > We're "speaking for the ietf", it is more a matter of what we say ;) > > > > > > All, > > > > > > As usual we are trying to reach a rough consensus. Everyone > > (i.e. the > > > mpls wg) can help create this consensus by answering the question > > > above. > > > > > > Especially it will be helpful if you were involved in specifying the > > > mpls protocols, have implemented or deployed (SP) those > > protocols, and > > > take the time to respond. > > > > > > I will be ready to give the first extensive tally mid this week. > > > Currently the count is > > > yes: 30 no: 7, > > > if you normalize those e.g. by counting each company once it is > > > yes: 21 no: 4 > > > > > > Disclaimer: Given that I've managed to decipher the > > sometimes cryptic > > > mails correctly :o) > > > > > > /Loa > > > > > > Hummel Heinrich wrote: > > > > > > > I think, the IETF can only speak for itself. There may > > be other standardization > > > > > > >bodies (ITU-T, MPLS Forum) which may fill > > > > the gap. > > > > > > > > Heinrich Hummel > > > > Siemens AG > > > > > > > > > > -- > > > 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 > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Tue Jul 23 12:37:29 2002 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 ESMTP id MAA22037 for ; Tue, 23 Jul 2002 12:37:29 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytu12041 for ; Tue, 23 Jul 2002 16:38:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytu10261; Tue, 23 Jul 2002 16:37:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytu09945 for mpls-outgoing; Tue, 23 Jul 2002 16:36:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmytu09929 for ; Tue, 23 Jul 2002 16:36: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 QQmytu22951 for ; Tue, 23 Jul 2002 16:35:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytu09469 for ; Tue, 23 Jul 2002 16:35:10 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytu09279 for ; Tue, 23 Jul 2002 16:35:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA21217 for ; Tue, 23 Jul 2002 12:35:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10346 for mpls@uu.net; Tue, 23 Jul 2002 12:35:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytu09638 for ; Tue, 23 Jul 2002 16:33:35 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 QQmytu18307 for ; Tue, 23 Jul 2002 16:33:32 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytq27503 for ; Tue, 23 Jul 2002 15:42:56 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA17149; Tue, 23 Jul 2002 11:42:55 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA24812; Tue, 23 Jul 2002 11:42:55 -0400 (EDT) Message-Id: <200207231542.LAA24812@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "Don Fedyk" cc: Loa Andersson , MPLS wg , swallow@cisco.com Subject: Re: initiating a discussion on mpls singaling protocols In-reply-to: Your message of "Tue, 23 Jul 2002 10:49:07 EDT." <0D7FC1D8D861D511AEA70002A52CE5E603104DE6@zcard0ke.ca.nortel.com> Date: Tue, 23 Jul 2002 11:42:55 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > I am against the proposal on the belief it is too soon to take this step. If > we had applied this policy to the original classical RSVP protocol it would > have been information some 5 years ago. Wow! RSVP wasn't even an RFC then. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Jul 23 12:39:31 2002 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 ESMTP id MAA22127 for ; Tue, 23 Jul 2002 12:39:29 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytu17932 for ; Tue, 23 Jul 2002 16:40:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytu16338; Tue, 23 Jul 2002 16:39:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytu10014 for mpls-outgoing; Tue, 23 Jul 2002 16:38:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytu09998 for ; Tue, 23 Jul 2002 16:38: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 QQmytu29659 for ; Tue, 23 Jul 2002 16:38:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytu25797 for ; Tue, 23 Jul 2002 16:38:09 GMT Received: from pop018.verizon.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pop018pub.verizon.net [206.46.170.212]) id QQmytu25793 for ; Tue, 23 Jul 2002 16:38:09 GMT Received: from Laptop-marty ([151.203.13.80]) by pop018.verizon.net (InterMail vM.5.01.05.05 201-253-122-126-105-20020426) with ESMTP id <20020723163809.BQXU26295.pop018.verizon.net@Laptop-marty>; Tue, 23 Jul 2002 11:38:09 -0500 Message-ID: <200207231238080746.04127FA6@outgoing.verizon.net> In-Reply-To: <1117F7D44159934FB116E36F4ABF221B02267178@celox-ma1-ems1.celoxnetworks.com> References: <1117F7D44159934FB116E36F4ABF221B02267178@celox-ma1-ems1.celoxnetworks.com> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Tue, 23 Jul 2002 12:38:08 -0400 Reply-To: mborden@acm.org From: "Marty Borden" To: egray@celoxnetworks.com, "'avri'" Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Eric, Well that would be good if it were acceptable for a draft to not have to cover both approaches. Is that really acceptable? marty On 7/23/2002 at 12:09 PM Gray, Eric wrote: |Avri makes a very good point here. | |I think the implementation survey makes it obvious that |we should progress RSVP-TE (and related work) to Draft |Standard. It seems equally clear that we should not do |so for CR-LDP at this point. | |Letting CR-LDP die on the vine certainly seems in keeping |with what the IETF has done in the past. | |Eric W. Gray |Systems Architect |Celox Networks, Inc. |egray@celoxnetworks.com |508 305 7214 | | |-----Original Message----- |From: avri [mailto:avri@sm.luth.se] |Sent: Tuesday, July 23, 2002 9:26 AM |Cc: MPLS wg |Subject: Re: initiating a discussion on mpls singaling protocols | | | |This seems to me a very strange proposal. And in fact seems to be |a perversion of the IETF standards process as i understand it. | |If things are as argued, then RSVP-TE will progress to draft standard |and then to standard, while CR-LDP remains a proposed standard. If |it languishes long enough in the proposed state, without significant |deployment or utility, then it would seem appropriate to transition it |to historic at some point in the future. | |Taking it to informational at this point seems a fairly blatant political |move without technical merit. At best it is an administrative sleight |of hand that could strange repercussions as a precedent. Is the IETF |going to embark next on an effort to define all protocol duplication |out of existence by voting on which alternative to make informational? | |I would suggest (as voting is not something I thought the IETF did) that |both protocols remain as ps. If CR-LDP withers on the vine because it has |no utility, so be it. Voting to change its status seems inappropriate to |me. | |a. From owner-mpls@UU.NET Tue Jul 23 12:40:30 2002 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 ESMTP id MAA22207 for ; Tue, 23 Jul 2002 12:40:30 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytu28852 for ; Tue, 23 Jul 2002 16:41:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytu27446; Tue, 23 Jul 2002 16:40:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytu10055 for mpls-outgoing; Tue, 23 Jul 2002 16:39:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytu10035 for ; Tue, 23 Jul 2002 16:39: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 QQmytu10985 for ; Tue, 23 Jul 2002 16:38:37 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytu15835 for ; Tue, 23 Jul 2002 16:38:36 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytu15823 for ; Tue, 23 Jul 2002 16:38:36 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA21491; Tue, 23 Jul 2002 12:38:35 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA11084; Tue, 23 Jul 2002 12:38:35 -0400 (EDT) Message-Id: <200207231638.MAA11084@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: "Gibson, Mark" cc: MPLS wg Subject: Re: initiating a discussion on mpls signaling protocols In-reply-to: Your message of Tue, 23 Jul 2002 17:19:41 +0100. <8AEA6B34A5AF2D4ABECB4E9351DAE6981CF176@S1000.orchestream.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 23 Jul 2002 12:38:35 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk [MG] If not, can we only have one PWE3 protocol please, one IGP please, one [MG] L2VPN discovery protocol please.... Certainly, let's drop all the IGPs that have zero deployment ;-) In the PWE3/PPVPN context, if we find in a few years that some of the alternatives have zero deployment, we should consider dropping the undeployed alternatives. From owner-mpls@UU.NET Tue Jul 23 12:46:22 2002 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 ESMTP id MAA22609 for ; Tue, 23 Jul 2002 12:46:22 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytv24267 for ; Tue, 23 Jul 2002 16:47:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytv22687; Tue, 23 Jul 2002 16:46:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytv10962 for mpls-outgoing; Tue, 23 Jul 2002 16:46:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytv10836 for ; Tue, 23 Jul 2002 16:45: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 QQmytv18628 for ; Tue, 23 Jul 2002 16:45:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytv06336 for ; Tue, 23 Jul 2002 16:45:39 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 QQmytv06332 for ; Tue, 23 Jul 2002 16:45:39 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 MAA14260 for ; Tue, 23 Jul 2002 12:45:38 -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 MAA21607 for ; Tue, 23 Jul 2002 12:45:38 -0400 (EDT) Message-ID: <3D3D884C.4030009@marconi.com> Date: Tue, 23 Jul 2002 12:46:04 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: AW: initiating a discussion on mpls singaling protocols References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hummel Heinrich wrote: > > But let me repeat my technical point: > Building hierarchical mp2p LSPs, from the egress towards a set of ingress nodes, i.e. > building a sink tree out of LSPs. > Here downstream unsolicited mode is appropriate. So we need LDP. But because existing LSPs have to be concatenated > (by label switching) we need their LSP-IDs. And this is provided by CR-LDP. > > It takes a lot more to create RSVP-TE Downstream Unsolicited mode. I think you are misunderstanding CR-LDP. It doesn't support downstream unsolicited mode either. -- David From owner-mpls@UU.NET Tue Jul 23 12:56:58 2002 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 ESMTP id MAA23250 for ; Tue, 23 Jul 2002 12:56:57 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytv07834 for ; Tue, 23 Jul 2002 16:57:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytv06545; Tue, 23 Jul 2002 16:57:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytv11923 for mpls-outgoing; Tue, 23 Jul 2002 16:57:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmytv11915 for ; Tue, 23 Jul 2002 16:56:56 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 QQmytv01168 for ; Tue, 23 Jul 2002 16:54:37 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytv04696 for ; Tue, 23 Jul 2002 16:54:37 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmytv04691 for ; Tue, 23 Jul 2002 16:54:37 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1NYF>; Tue, 23 Jul 2002 12:54:36 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B0226717A@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'mborden@acm.org'" , "Gray, Eric" , "'avri'" Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 12:54:34 -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 Marty, Very acceptable, IMO. Many drafts have been deliberately broken up to define functional signaling requirements and then separate drafts were written for signaling. I would actually have preferred that the draft authors ONLY worked on signaling drafts for whichever signaling approach they were actually implementing. This does not seem to have been the case, based on author lists for the various drafts. I have not been involved in design teams when they were making the decision to write signaling specifications for both protocols, so I only assume they did so in order to accelerate acceptance by the WG. A secondary goal of ensuring consistency I think was more than adequately addressed by having functional requirements drafts (which are useful in their own rights). I think it is perfectly acceptable to define a signaling extension for some application that we intend to implement using only RSVP-TE. The problem from the start has been the insidious assumption that anything developed for one _has_ to be developed for the other. I think this is what's broken here and this is what needs to be fixed. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Marty Borden [mailto:m.borden@verizon.net] Sent: Tuesday, July 23, 2002 12:38 PM To: egray@celoxnetworks.com; 'avri' Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Eric, Well that would be good if it were acceptable for a draft to not have to cover both approaches. Is that really acceptable? marty On 7/23/2002 at 12:09 PM Gray, Eric wrote: |Avri makes a very good point here. | |I think the implementation survey makes it obvious that |we should progress RSVP-TE (and related work) to Draft |Standard. It seems equally clear that we should not do |so for CR-LDP at this point. | |Letting CR-LDP die on the vine certainly seems in keeping |with what the IETF has done in the past. | |Eric W. Gray |Systems Architect |Celox Networks, Inc. |egray@celoxnetworks.com |508 305 7214 | | |-----Original Message----- |From: avri [mailto:avri@sm.luth.se] |Sent: Tuesday, July 23, 2002 9:26 AM |Cc: MPLS wg |Subject: Re: initiating a discussion on mpls singaling protocols | | | |This seems to me a very strange proposal. And in fact seems to be |a perversion of the IETF standards process as i understand it. | |If things are as argued, then RSVP-TE will progress to draft standard |and then to standard, while CR-LDP remains a proposed standard. If |it languishes long enough in the proposed state, without significant |deployment or utility, then it would seem appropriate to transition it |to historic at some point in the future. | |Taking it to informational at this point seems a fairly blatant political |move without technical merit. At best it is an administrative sleight |of hand that could strange repercussions as a precedent. Is the IETF |going to embark next on an effort to define all protocol duplication |out of existence by voting on which alternative to make informational? | |I would suggest (as voting is not something I thought the IETF did) that |both protocols remain as ps. If CR-LDP withers on the vine because it has |no utility, so be it. Voting to change its status seems inappropriate to |me. | |a. From owner-mpls@UU.NET Tue Jul 23 13:01:39 2002 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 ESMTP id NAA23677 for ; Tue, 23 Jul 2002 13:01:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytw17674 for ; Tue, 23 Jul 2002 17:02:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytw15623; Tue, 23 Jul 2002 17:01:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytw17154 for mpls-outgoing; Tue, 23 Jul 2002 17:01:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytw17081 for ; Tue, 23 Jul 2002 17:01: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 QQmytw27444 for ; Tue, 23 Jul 2002 17:01:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytw14909 for ; Tue, 23 Jul 2002 17:01:14 GMT Received: from c2.ciena.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQmytw14884 for ; Tue, 23 Jul 2002 17:01:13 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id NAA16903; Tue, 23 Jul 2002 13:01:12 -0400 (EDT) Received: from wntcsdexg02.csd.ciena.com(10.128.2.168) by c2.ciena.com via smap (V2.0) id xma016686; Tue, 23 Jul 02 13:00:38 -0400 Received: by wntcsdexg02.csd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 10:00:37 -0700 Message-ID: <2135200C183FD5119588009027DE5723FD3228@wntcsdexg02.csd.ciena.com> From: "Ong, Lyndon" To: "'mborden@acm.org'" , egray@celoxnetworks.com, "'avri'" Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 10:00:36 -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 This might be actually a reasonable solution, to "cap" the work on CR-LDP. I'd have the same concern as Avri with taking an approved standard and "de-standardizing" it, although it would help to know if this has been done before. Cheers, Lyndon Ong Ciena -----Original Message----- From: Marty Borden [mailto:m.borden@verizon.net] Sent: Tuesday, July 23, 2002 9:38 AM To: egray@celoxnetworks.com; 'avri' Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Eric, Well that would be good if it were acceptable for a draft to not have to cover both approaches. Is that really acceptable? marty On 7/23/2002 at 12:09 PM Gray, Eric wrote: |Avri makes a very good point here. | |I think the implementation survey makes it obvious that |we should progress RSVP-TE (and related work) to Draft |Standard. It seems equally clear that we should not do |so for CR-LDP at this point. | |Letting CR-LDP die on the vine certainly seems in keeping |with what the IETF has done in the past. | |Eric W. Gray |Systems Architect |Celox Networks, Inc. |egray@celoxnetworks.com |508 305 7214 | | |-----Original Message----- |From: avri [mailto:avri@sm.luth.se] |Sent: Tuesday, July 23, 2002 9:26 AM |Cc: MPLS wg |Subject: Re: initiating a discussion on mpls singaling protocols | | | |This seems to me a very strange proposal. And in fact seems to be |a perversion of the IETF standards process as i understand it. | |If things are as argued, then RSVP-TE will progress to draft standard |and then to standard, while CR-LDP remains a proposed standard. If |it languishes long enough in the proposed state, without significant |deployment or utility, then it would seem appropriate to transition it |to historic at some point in the future. | |Taking it to informational at this point seems a fairly blatant political |move without technical merit. At best it is an administrative sleight |of hand that could strange repercussions as a precedent. Is the IETF |going to embark next on an effort to define all protocol duplication |out of existence by voting on which alternative to make informational? | |I would suggest (as voting is not something I thought the IETF did) that |both protocols remain as ps. If CR-LDP withers on the vine because it has |no utility, so be it. Voting to change its status seems inappropriate to |me. | |a. From owner-mpls@UU.NET Tue Jul 23 13:12:16 2002 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 ESMTP id NAA24389 for ; Tue, 23 Jul 2002 13:12:16 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytw22412 for ; Tue, 23 Jul 2002 17:12:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytw20500; Tue, 23 Jul 2002 17:11:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytw06363 for mpls-outgoing; Tue, 23 Jul 2002 17:11:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytw06356 for ; Tue, 23 Jul 2002 17:11: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 QQmytw16652 for ; Tue, 23 Jul 2002 17:11:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytw28682 for ; Tue, 23 Jul 2002 17:11:25 GMT Received: from alpha2.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.125.55.125]) id QQmytw28676 for ; Tue, 23 Jul 2002 17:11:24 GMT Received: from mail3.tellium.com (mail3.tellium.com) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 13:09:24 -0400 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id <3819ATGV>; Tue, 23 Jul 2002 13:07:17 -0400 Message-ID: <05707214338CD5119BFF0040A5B170D3E822E4@mail3.tellium.com> From: Bala Rajagopalan To: "'Stephen Trowbridge'" , Bala Rajagopalan Cc: "'Soumen Sarkar'" , Loa Andersson , mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 13:07:16 -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 Steve, Isn't it the case that the only reason that ITU-T (or OIF for that matter) considers RSVP-TE and CR-LDP because they're both approved standards from IETF? In other words, the ITU-T and OIF merely adapt (or adopt) "existing" protocols for the IP-based control plane. If IETF decides to stop progressing one of these protocols further, wouldn't it lighten the (redundant) work that goes on in the ITU-T? I also don't see why there ought to be a joint decision between ITU-T and IETF on this. Given that the ITU-T is at a stage where the protocol work is still evolving and no deployment is at stake, it makes good sense to welcome the move from the IETF to clarify the signaling protocol picture. Regards, Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Tuesday, July 23, 2002 12:25 PM > To: Bala Rajagopalan > Cc: 'Soumen Sarkar'; Loa Andersson; mpls@UU.NET > Subject: Re: initiating a discussion on mpls singaling protocols > > > Bala, > There is certainly no issue if both organizations make the same > decision about which protocol(s) is/are standards track. There is > only an issue if they make different decisions. > > If a change is to be made in IETF with respect to which protocol(s) > is/are standards track, it would be worth sending a > communication to ITU-T > with the proposal and reasoning before this is finalized to see if > an aligned decision could be reached. > Regards, > Steve > > Bala Rajagopalan wrote: > > > > In response to the comment on OIF tracking CR-LDP: > > > > Life would be simplified for OIF and ITU-T if > > there were only a single standard signaling protocol. > > But because there are two IETF protocols, the rest of the > > world has to track the two (in addition to other > > non-IETF protocols). > > > > Bala Rajagopalan > > Tellium, Inc. > > 2 Crescent Place > > P.O. Box 901 > > Oceanport, NJ 07757-0901 > > Tel: (732) 923-4237 > > Fax: (732) 923-9804 > > Email: braja@tellium.com > > > > > -----Original Message----- > > > From: Soumen Sarkar [mailto:soumen@sasken.com] > > > Sent: Tuesday, July 23, 2002 3:27 AM > > > To: Loa Andersson; mpls@UU.NET > > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > > > > > > Loa, > > > The response so far heavily indicated for RSVP-TE ( obviously > > > not because of the > > > merits of RSVP-TE over LDP-CR ). If one has to accept the > > > basic ground-rule, which is, > > > how many major players are pushing for RSVP-TE, one would > > > blindly vote for RSVP-TE. > > > The more esoteric view, which is, single signaling > > > protocol would help > > > everyone to concentrate better in addressing unresolved > > > problems in MPLS, is also > > > appreciably reasonable to accept. > > > But looking from holistic perspective, is it not too > > > premature at this time to > > > conclude on this issue unilaterally (even if there is 3/4 > > > majority in favour if it ) > > > when this particular issue affects other standard bodies too > > > ? We know for sure, OIF > > > is still tracking LDP-CR as an alternative signaling protocol > > > for optical control > > > plane. Are we not pushing something without even considering > > > future implication of it > > > ? One might say, we are not stopping anyone to use LDP-CR as > > > such. But none would > > > disagree that making IETF take a stand itself is deterrant > > > enough and if not that > > > much, it is bound to create conflict of interest between IETF > > > and others. > > > Are we really ready for this ? IETF traditionally has been > > > more a forum for vouching > > > technical solutions, not imposing it. Are we deviating from > > > that path with full > > > understanding ? > > > -best regards, > > > Soumen > > > > > > Loa Andersson wrote: > > > > > > > Heinrich, > > > > > > > > in my opinion the question is very clearly stated - is > > > there support for > > > > us (the ietf) to move the cr-ldp from standard track to > > > informational. > > > > We're "speaking for the ietf", it is more a matter of > what we say ;) > > > > > > > > All, > > > > > > > > As usual we are trying to reach a rough consensus. Everyone > > > (i.e. the > > > > mpls wg) can help create this consensus by answering > the question > > > > above. > > > > > > > > Especially it will be helpful if you were involved in > specifying the > > > > mpls protocols, have implemented or deployed (SP) those > > > protocols, and > > > > take the time to respond. > > > > > > > > I will be ready to give the first extensive tally mid this week. > > > > Currently the count is > > > > yes: 30 no: 7, > > > > if you normalize those e.g. by counting each company once it is > > > > yes: 21 no: 4 > > > > > > > > Disclaimer: Given that I've managed to decipher the > > > sometimes cryptic > > > > mails correctly :o) > > > > > > > > /Loa > > > > > > > > Hummel Heinrich wrote: > > > > > > > > > I think, the IETF can only speak for itself. There may > > > be other standardization > > > > > > > > >bodies (ITU-T, MPLS Forum) which may fill > > > > > the gap. > > > > > > > > > > Heinrich Hummel > > > > > Siemens AG > > > > > > > > > > > > > -- > > > > 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 Tue Jul 23 13:19:51 2002 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 ESMTP id NAA24775 for ; Tue, 23 Jul 2002 13:19:51 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytx07417 for ; Tue, 23 Jul 2002 17:20:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytx03803; Tue, 23 Jul 2002 17:19:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytx07317 for mpls-outgoing; Tue, 23 Jul 2002 17:18:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmytx07294 for ; Tue, 23 Jul 2002 17:18: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 QQmytx06858 for ; Tue, 23 Jul 2002 17:17:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytx00379 for ; Tue, 23 Jul 2002 17:17:13 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmytx00359 for ; Tue, 23 Jul 2002 17:17:12 GMT Received: from utfors.se ([195.58.105.122]) by blooper.utfors.se (Utfors AB) with ESMTP id g6NHGu5F002727; Tue, 23 Jul 2002 19:16:56 +0200 (MEST) Message-ID: <3D3D8F88.4050105@utfors.se> Date: Tue, 23 Jul 2002 19:16:56 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "Ong, Lyndon" CC: "'mborden@acm.org'" , egray@celoxnetworks.com, "'avri'" , mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <2135200C183FD5119588009027DE5723FD3228@wntcsdexg02.csd.ciena.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, (off list for clarification) it seems like you are agreeing based on two very different approaches. 1. don't do anyhting about the doc status to cr-ldp, but stop all work on it (Lyndon) 2. don't do anything to doc status, but require (encoruage) that id authors work only on one singalling protocol at a time (Eric). 1 is very close to what was proposed at the mpls wg meeting, 2 is actually a decission to continue develop cr-ldp. /Loa Ong, Lyndon wrote: > This might be actually a reasonable solution, to "cap" the > work on CR-LDP. I'd have the same concern as Avri with > taking an approved standard and "de-standardizing" it, > although it would help to know if this has been done > before. > > Cheers, > > Lyndon Ong > Ciena > > -----Original Message----- > From: Marty Borden [mailto:m.borden@verizon.net] > Sent: Tuesday, July 23, 2002 9:38 AM > To: egray@celoxnetworks.com; 'avri' > Cc: mpls@UU.NET > Subject: RE: initiating a discussion on mpls singaling protocols > > > Eric, > Well that would be good if it were acceptable for a draft > to not have to cover both approaches. Is that really acceptable? > marty > > > On 7/23/2002 at 12:09 PM Gray, Eric wrote: > > |Avri makes a very good point here. > | > |I think the implementation survey makes it obvious that > |we should progress RSVP-TE (and related work) to Draft > |Standard. It seems equally clear that we should not do > |so for CR-LDP at this point. > | > |Letting CR-LDP die on the vine certainly seems in keeping > |with what the IETF has done in the past. > | > |Eric W. Gray > |Systems Architect > |Celox Networks, Inc. > |egray@celoxnetworks.com > |508 305 7214 > | > | > |-----Original Message----- > |From: avri [mailto:avri@sm.luth.se] > |Sent: Tuesday, July 23, 2002 9:26 AM > |Cc: MPLS wg > |Subject: Re: initiating a discussion on mpls singaling protocols > | > | > | > |This seems to me a very strange proposal. And in fact seems to be > |a perversion of the IETF standards process as i understand it. > | > |If things are as argued, then RSVP-TE will progress to draft standard > |and then to standard, while CR-LDP remains a proposed standard. If > |it languishes long enough in the proposed state, without significant > |deployment or utility, then it would seem appropriate to transition it > |to historic at some point in the future. > | > |Taking it to informational at this point seems a fairly blatant political > |move without technical merit. At best it is an administrative sleight > |of hand that could strange repercussions as a precedent. Is the IETF > |going to embark next on an effort to define all protocol duplication > |out of existence by voting on which alternative to make informational? > | > |I would suggest (as voting is not something I thought the IETF did) that > |both protocols remain as ps. If CR-LDP withers on the vine because it has > |no utility, so be it. Voting to change its status seems inappropriate to > |me. > | > |a. > > > > -- 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 Tue Jul 23 13:20:50 2002 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 ESMTP id NAA24801 for ; Tue, 23 Jul 2002 13:20:50 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytx19609 for ; Tue, 23 Jul 2002 17:21:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmytx14206; Tue, 23 Jul 2002 17:19:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmytx07328 for mpls-outgoing; Tue, 23 Jul 2002 17:19:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmytx07321 for ; Tue, 23 Jul 2002 17:19:06 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 QQmytx27718 for ; Tue, 23 Jul 2002 17:18:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytx03088 for ; Tue, 23 Jul 2002 17:18:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmytx03082 for ; Tue, 23 Jul 2002 17:18:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA24610 for ; Tue, 23 Jul 2002 13:18:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA17822 for mpls@uu.net; Tue, 23 Jul 2002 13:18:03 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmytx07185 for ; Tue, 23 Jul 2002 17:16:43 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 QQmytx04264 for ; Tue, 23 Jul 2002 17:16:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmytx02214 for ; Tue, 23 Jul 2002 17:16:31 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmytx02207 for ; Tue, 23 Jul 2002 17:16:30 GMT Received: from ZALI-W2K.cisco.com (che-vpn1-88.cisco.com [10.86.240.88]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id NAA06532; Tue, 23 Jul 2002 13:16:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20020723121125.02222618@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Jul 2002 13:16:15 -0400 To: Stephen Trowbridge From: Zafar Ali Subject: Re: initiating a discussion on mpls singaling protocols Cc: Stephen Shew , MPLS wg , braja@tellium.com In-Reply-To: <3D3D7BF8.849D1A88@lucent.com> References: <4.3.2.7.2.20020723100337.022b0498@sword.cisco.com> <4.3.2.7.2.20020723110846.0220d0f0@sword.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_16195437==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_16195437==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:53 AM 7/23/2002 -0600, Stephen Trowbridge wrote: >Zafar, >Not at all - just questioning your assertion that references made by >other standards organizations still hold, which is not true. Stephen, This is what I meant that this is not a valid reason for IETF to stop making decision independently. So, we are agreeing. Now on the possible logistics. BTW Bala just mentioned that OIF is forced to maintain two standards, just because IETF does so. So, we may have one less on the list. If anything, why not the other standardization committee can take a snap shot of the most recent CR-LDP spec. and evolve it further (if desired so). OIF does some "copying" of a snap-shot version in the past. Thanks Regards... Zafar >If IETF were to reclassify CR-LDP as informational, it would have an >impact on other standards organizations considering CR-LDP based solutions. >Regards, >Steve > >Zafar Ali wrote: > > > > At 08:51 AM 7/23/2002 -0600, Stephen Trowbridge wrote: > > > > > Zafar, > > > (snip) > > > > So, all the references made by the other standardization activities > will still > > > > hold. > > > In fact, for references from ITU-T Recommendations, reclassification > as informational > > > does raise an issue: According to Recommendation A.5, ITU-T > Recommendations may not > > > have normative references to informational, historical, or > experimental RFCs (or > > > IDs of any kind). > > > > Hi Stephen, > > > > Do you see this as a valid reason for IETF to stop "optimizing" it's > progress path? > > > > Thanks > > > > Regards... Zafar > > > > > Regards, > > > Steve Trowbridge > > > Vice-chairman, ITU-T Study Group 15 --=====================_16195437==_.ALT Content-Type: text/html; charset="us-ascii" At 09:53 AM 7/23/2002 -0600, Stephen Trowbridge wrote:
Zafar,
Not at all - just questioning your assertion that references made by
other standards organizations still hold, which is not true.

Stephen,

This is what I meant that this is not a valid reason for IETF to stop making decision independently. So, we are agreeing.

Now on the possible logistics. BTW Bala just mentioned that OIF is forced to maintain two standards, just because IETF does so. So, we may have one less on the list. If anything, why not the other standardization committee can take a snap shot of the most recent CR-LDP spec. and evolve it further (if desired so). OIF does some "copying" of a snap-shot version in the past.

Thanks

Regards... Zafar

If IETF were to reclassify CR-LDP as informational, it would have an
impact on other standards organizations considering CR-LDP based solutions.
Regards,
Steve

Zafar Ali wrote:
>
> At 08:51 AM 7/23/2002 -0600, Stephen Trowbridge wrote:
>
> > Zafar,
> > (snip)
> > > So, all the references made by the other standardization activities will still
> > > hold.
> > In fact, for references from ITU-T Recommendations, reclassification as informational
> > does raise an issue: According to Recommendation A.5, ITU-T Recommendations may not
> > have normative references to informational, historical, or experimental RFCs (or
> > IDs of any kind).
>
> Hi Stephen,
>
> Do you see this as a valid reason for IETF to stop "optimizing" it's progress path?
>
> Thanks
>
> Regards... Zafar
>
> > Regards,
> > Steve Trowbridge
> > Vice-chairman, ITU-T Study Group 15
--=====================_16195437==_.ALT-- From owner-mpls@UU.NET Tue Jul 23 15:04:58 2002 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 ESMTP id PAA29639 for ; Tue, 23 Jul 2002 15:04:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyue04375 for ; Tue, 23 Jul 2002 19:05:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyue02928; Tue, 23 Jul 2002 19:05:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyue23493 for mpls-outgoing; Tue, 23 Jul 2002 19:04:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyue23090 for ; Tue, 23 Jul 2002 19:04: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 QQmyue00804 for ; Tue, 23 Jul 2002 19:03:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyue01999 for ; Tue, 23 Jul 2002 19:03:11 GMT Received: from pimout5-int.prodigy.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pimout5-ext.prodigy.net [207.115.63.98]) id QQmyue01994 for ; Tue, 23 Jul 2002 19:03:10 GMT Received: from cs.columbia.edu (adsl-64-175-245-81.dsl.sntc01.pacbell.net [64.175.245.81]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g6NJ37208376; Tue, 23 Jul 2002 15:03:07 -0400 Message-ID: <3D3DA868.1030902@cs.columbia.edu> Date: Tue, 23 Jul 2002 12:03:04 -0700 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Zafar Ali CC: MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <4.3.2.7.2.20020723115506.022c0250@sword.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Zafar, While I agree with your assessment in general, I don't think TCP oervhead is a big deal. TCP sockets or IP raw sockets (which RSVP may use) do not impose that much of processing overhead. UNIX VM has done wonders! In fact, under stress condition, both socket types will have the similar performance problem, that is, PCB's are queuing at socket level.... Regards, - Ping From owner-mpls@UU.NET Tue Jul 23 19:13:01 2002 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 ESMTP id TAA07028 for ; Tue, 23 Jul 2002 19:13:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyuu20187 for ; Tue, 23 Jul 2002 23:13:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyuu19021; Tue, 23 Jul 2002 23:13:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyuu17390 for mpls-outgoing; Tue, 23 Jul 2002 23:13:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyuu17376 for ; Tue, 23 Jul 2002 23:12: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 QQmyuu09630 for ; Tue, 23 Jul 2002 23:12:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyuu09010 for ; Tue, 23 Jul 2002 23:12:54 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmyuu09000 for ; Tue, 23 Jul 2002 23:12:53 GMT Received: from [213.208.123.104] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17X8pn-000643-00; Wed, 24 Jul 2002 00:12:51 +0100 Subject: Re: AW: initiating a discussion on mpls singaling protocols From: Giles Heron To: Lou Berger Cc: MPLS wg In-Reply-To: <4.3.2.7.2.20020723113755.0341b508@mail.labn.net> References: <4.3.2.7.2.20020723113755.0341b508@mail.labn.net> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 24 Jul 2002 00:12:42 +0000 Message-Id: <1027469562.1996.81.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA07028 nice summary. I'd agree that given the lack of market acceptance of CR-LDP it would be good to focus effort on RSVP-TE from here on in. I can't see the value in spending time writing drafts that will never be deployed - let alone implementing those drafts with no SP requirement to do so. Giles On Tue, 2002-07-23 at 16:10, Lou Berger wrote: > > Heinrich, > > This is not really correct. I (and others) have spent quite a bit of time > to ensure that functionality added to one protocol is added to the > other. The reason for this has been so that the technology can advance > without having to get mired down in the protocol wars that we went through > in the early days of MPLS. > > At this point, I think both protocols deliver equivalent > functionality. Both protocols have their plusses and minuses that can be > argued for as long as folks have energy. But IMO, we're at the point where > differences in robustness and scalability are now in the domain of the > quality of implementation and not resulting of the base protocol. > > Going forward, I think that having just one protocol to deliver a piece of > functionality so that we don't have to duplicate work is goodness. Based > on the GMPLS implementation survey, I think that GMPLS-CR-LDP should move > forward as informational. I think that reclassifying CR-LDP to > informational (or historic, if that's the right procedural thing) also > makes sense based on market acceptance. > > Lou > > At 11:12 AM 7/23/2002, Hummel Heinrich wrote: > >Well spoken. > >Additionally, all those who do not care for CR-LDP have hardly contributed > >in the past nor will they contribute > >in the future to extend routing protocols for the sake of CR-LDP. This > >sweat is up to the CR-LDP supporters. > >It is not honest to complain about the burden carried by the others. > >Heinrich > > > >-----Ursprüngliche Nachricht----- > >Von: avri [mailto:avri@sm.luth.se] > >Gesendet: Dienstag, 23. Juli 2002 15:26 > >Cc: MPLS wg > >Betreff: Re: initiating a discussion on mpls singaling protocols > > > > > > > > > >This seems to me a very strange proposal. And in fact seems to be > >a perversion of the IETF standards process as i understand it. > > > >If things are as argued, then RSVP-TE will progress to draft standard > >and then to standard, while CR-LDP remains a proposed standard. If > >it languishes long enough in the proposed state, without significant > >deployment or utility, then it would seem appropriate to transition it > >to historic at some point in the future. > > > >Taking it to informational at this point seems a fairly blatant political > >move without technical merit. At best it is an administrative sleight > >of hand that could strange repercussions as a precedent. Is the IETF > >going to embark next on an effort to define all protocol duplication > >out of existence by voting on which alternative to make informational? > > > >I would suggest (as voting is not something I thought the IETF did) that > >both protocols remain as ps. If CR-LDP withers on the vine because it has > >no utility, so be it. Voting to change its status seems inappropriate to > >me. > > > >a. > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Tue Jul 23 20:02:57 2002 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 ESMTP id UAA07992 for ; Tue, 23 Jul 2002 20:02:56 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyuy18637 for ; Wed, 24 Jul 2002 00:03:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyuy17813; Wed, 24 Jul 2002 00:03:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyuy02652 for mpls-outgoing; Wed, 24 Jul 2002 00:03:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyuy02647 for ; Wed, 24 Jul 2002 00:03:11 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 QQmyuy02337 for ; Wed, 24 Jul 2002 00:02:12 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyuy07584 for ; Wed, 24 Jul 2002 00:02:12 GMT Received: from newdev.harvard.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQmyuy07576 for ; Wed, 24 Jul 2002 00:02:12 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g6O02CX11150 for mpls@UU.NET; Tue, 23 Jul 2002 20:02:12 -0400 (EDT) Date: Tue, 23 Jul 2002 20:02:12 -0400 (EDT) From: Scott Bradner Message-Id: <200207240002.g6O02CX11150@newdev.harvard.edu> To: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Sender: owner-mpls@UU.NET Precedence: bulk the question has been asked about reclassifying a already published RFC from Proposed Standard to Informational (i.e. de-standardization) A/ I do not know of a case where this has been done B/ RFC 2026 talks about moving to historic not info (in my opinion moving to historc should be done where there is a specific strong reason (or reasons) such as security (see RFC 1923 for an example of stating reasons).) my own opinion is that it would set a very precedent to de-standardize at all and a very bad one to do such a short time after the RFC was published I expect we can tell for sure in 4 or 5 years how a technology will be received but I doubt that we can tell much in just 6 months I think the more important question is about on-going CR-LDP work -- should be CR-LPD work be relegated to non-standards track? specific questions: A/ should IETF working group charters be modified to remove a requirement to work on CR-LPD technologies? B/ if there is CR-LDP work already in progress, what should happen to it? C/ if a working group requests publication of RFCs about CR-LPD technology on the standards track what should we do? D/ if someone requests independent publication of RFCs about CR-LPD technology on the standards track (as permitted by RFC 2026) what should we do? (I see no way for the IETF to refuse to publish CR-LDP related infor or experimental RFCs - the IETF is not in teh business of suppressing technology) Scott From owner-mpls@UU.NET Tue Jul 23 20:27:47 2002 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 ESMTP id UAA08446 for ; Tue, 23 Jul 2002 20:27:47 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyuz18031 for ; Wed, 24 Jul 2002 00:28:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyuz17142; Wed, 24 Jul 2002 00:28:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyuz14911 for mpls-outgoing; Wed, 24 Jul 2002 00:27:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyuz14904 for ; Wed, 24 Jul 2002 00:27: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 QQmyuz01821 for ; Wed, 24 Jul 2002 00:26:01 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyuz06167 for ; Wed, 24 Jul 2002 00:26:00 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmyuz06151 for ; Wed, 24 Jul 2002 00:26:00 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1382>; Tue, 23 Jul 2002 20:26:00 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267186@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Scott Bradner'" , mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Tue, 23 Jul 2002 20:25: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 Scott, I think it is perfectly acceptable that ongoing work on CR-LDP - both current and immediately anticipated - should be targeted for Informational RFCs. The focus needs to be on what people who are writing the drafts are implementing and it is clear that this is RSVP-TE in nearly every case. I believe most people will agree that this should remove any perception that there is a requirement to define everything twice in MPLS signaling. In addition, if the CR-LDP drafts are targeted for Informational status, this relieves the WG of some of the distraction associated with having to do a thorough review of each signaling protocols extension twice. Please see responses to your specific questions below. Thanks for putting the issues in a clear perspective! Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Scott Bradner [mailto:sob@harvard.edu] Sent: Tuesday, July 23, 2002 8:02 PM To: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols the question has been asked about reclassifying a already published RFC from Proposed Standard to Informational (i.e. de-standardization) A/ I do not know of a case where this has been done B/ RFC 2026 talks about moving to historic not info (in my opinion moving to historc should be done where there is a specific strong reason (or reasons) such as security (see RFC 1923 for an example of stating reasons).) my own opinion is that it would set a very precedent to de-standardize at all and a very bad one to do such a short time after the RFC was published I expect we can tell for sure in 4 or 5 years how a technology will be received but I doubt that we can tell much in just 6 months I think the more important question is about on-going CR-LDP work -- should be CR-LPD work be relegated to non-standards track? specific questions: A/ should IETF working group charters be modified to remove a requirement to work on CR-LPD technologies? Yes. B/ if there is CR-LDP work already in progress, what should happen to it? It should be targeted for Informational RFC status. Since these drafts are mostly of the form of - if you were going to do the same thing using CR-LDP, this is how you would do it - therefore, informational status makes more sense. C/ if a working group requests publication of RFCs about CR-LDP technology on the standards track what should we do? Use the usual procedure of IESG review. Was the WG chartered to do this work? If so, how did this happen? I think it is not necessary to erect some type of contrived barrier as there will be a sufficiently high natural barrier to inappropriate work of this kind. D/ if someone requests independent publication of RFCs about CR-LPD technology on the standards track (as permitted by RFC 2026) what should we do? Again, this would fall under usual procedures. The RFC Editor would typically kick this to the IESG hence causing it to be assigned to the appropriate working group (or not) as the IESG determines to be appropriate. As I understand it, the RFC Editor is not obliged to publish anything as a standards track RFC and will not unless satisfied that the right thing is being done by doing so. (I see no way for the IETF to refuse to publish CR-LDP related infor or experimental RFCs - the IETF is not in the business of suppressing technology) Scott From owner-mpls@UU.NET Tue Jul 23 21:25:01 2002 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 ESMTP id VAA09494 for ; Tue, 23 Jul 2002 21:25:01 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvd06761 for ; Wed, 24 Jul 2002 01:25:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyvd05482; Wed, 24 Jul 2002 01:25:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyvd11244 for mpls-outgoing; Wed, 24 Jul 2002 01:24:56 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyvd11239 for ; Wed, 24 Jul 2002 01:24: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 QQmyvd17734 for ; Wed, 24 Jul 2002 01:24:29 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvd14362 for ; Wed, 24 Jul 2002 01:24:29 GMT Received: from griffin.host4u.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQmyvd14358 for ; Wed, 24 Jul 2002 01:24:29 GMT Received: from labn.net (labn.net [209.204.240.82]) by griffin.host4u.net (8.11.6/8.11.6) with ESMTP id g6O1OSc21802; Tue, 23 Jul 2002 20:24:28 -0500 Message-ID: <3D3E02F8.9080105@labn.net> Date: Tue, 23 Jul 2002 21:29:28 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@UU.NET CC: "Gray, Eric" , "'Scott Bradner'" Subject: Re: initiating a discussion on mpls singaling protocols References: <1117F7D44159934FB116E36F4ABF221B02267186@celox-ma1-ems1.celoxnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I like Scott's summary of the issues and choices and 100% agree with Eric's response. Assuming that we follow this one step further, and make future CR-LDP work informational, shouldn't this decision be documented somewhere? Maybe in an updated CR-LDP applicability statement? Is the issue of how to indicate this decision the reason that reclassification of CR-LDP came up? Lou Gray, Eric wrote: > Scott, > > I think it is perfectly acceptable that ongoing work > on CR-LDP - both current and immediately anticipated - should > be targeted for Informational RFCs. The focus needs to be on > what people who are writing the drafts are implementing and > it is clear that this is RSVP-TE in nearly every case. I > believe most people will agree that this should remove any > perception that there is a requirement to define everything > twice in MPLS signaling. In addition, if the CR-LDP drafts > are targeted for Informational status, this relieves the WG > of some of the distraction associated with having to do a > thorough review of each signaling protocols extension twice. > > Please see responses to your specific questions below. > > Thanks for putting the issues in a clear perspective! > > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Tuesday, July 23, 2002 8:02 PM > To: mpls@UU.NET > Subject: RE: initiating a discussion on mpls singaling protocols > > > the question has been asked about reclassifying a already published > RFC from Proposed Standard to Informational (i.e. de-standardization) > > A/ I do not know of a case where this has been done > B/ RFC 2026 talks about moving to historic not info > > (in my opinion moving to historc should be done where there is > a specific strong reason (or reasons) such as security (see RFC 1923 > for an example of stating reasons).) > > my own opinion is that it would set a very precedent to de-standardize at > all > and a very bad one to do such a short time after the RFC was published > > I expect we can tell for sure in 4 or 5 years how a technology will be > received but I doubt that we can tell much in just 6 months > > I think the more important question is about on-going CR-LDP work -- > should be CR-LPD work be relegated to non-standards track? > > specific questions: > A/ should IETF working group charters be modified to remove a requirement > to work on CR-LPD technologies? > > Yes. > > B/ if there is CR-LDP work already in progress, what should happen to it? > > It should be targeted for Informational RFC status. > Since these drafts are mostly of the form of - if you were going > to do the same thing using CR-LDP, this is how you would do it - > therefore, informational status makes more sense. > > C/ if a working group requests publication of RFCs about CR-LDP > technology on the standards track what should we do? > > Use the usual procedure of IESG review. Was the WG chartered to > do this work? If so, how did this happen? I think it is not > necessary to erect some type of contrived barrier as there will > be a sufficiently high natural barrier to inappropriate work of > this kind. > > D/ if someone requests independent publication of RFCs about CR-LPD > technology on the standards track (as permitted by RFC 2026) what > should we do? > > Again, this would fall under usual procedures. The RFC Editor > would typically kick this to the IESG hence causing it to be > assigned to the appropriate working group (or not) as the IESG > determines to be appropriate. As I understand it, the RFC > Editor is not obliged to publish anything as a standards track > RFC and will not unless satisfied that the right thing is being > done by doing so. > > (I see no way for the IETF to refuse to publish CR-LDP related infor or > experimental RFCs - the IETF is not in the business of suppressing > technology) > > Scott > From owner-mpls@UU.NET Wed Jul 24 01:26:26 2002 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 ESMTP id BAA15799 for ; Wed, 24 Jul 2002 01:26:25 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvt05454 for ; Wed, 24 Jul 2002 05:27:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyvt04275; Wed, 24 Jul 2002 05:26:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyvt27135 for mpls-outgoing; Wed, 24 Jul 2002 05:26:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyvt27128 for ; Wed, 24 Jul 2002 05:26:26 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 QQmyvt17996 for ; Wed, 24 Jul 2002 05:25:55 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvt13539 for ; Wed, 24 Jul 2002 05:25:54 GMT Received: from samar.sasken.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQmyvt13525 for ; Wed, 24 Jul 2002 05:25:51 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g6O5PiC21400; Wed, 24 Jul 2002 10:55:45 +0530 (IST) Received: from sasken.com (pcz-soumen.sasken.com [10.1.64.68]) by sunsv2.sasken.com (8.11.6/8.11.6) with ESMTP id g6O5PfP12480; Wed, 24 Jul 2002 10:55:41 +0530 (IST) Message-ID: <3D3E3B33.14B283A7@sasken.com> Date: Wed, 24 Jul 2002 10:59:24 +0530 From: Soumen Sarkar X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bala Rajagopalan CC: Loa Andersson , mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <05707214338CD5119BFF0040A5B170D3E822E2@mail3.tellium.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit So, In effect you are saying that since OIF and ITU-T are not able to decide which one to pick (based on their requirements), it is benefecial for them that IETF decide which one they want to promote and others will follow! I thought ITU-T and OIF work independently and they have their own parameters to choose the technological alternative. Bala Rajagopalan wrote: > In response to the comment on OIF tracking CR-LDP: > > Life would be simplified for OIF and ITU-T if > there were only a single standard signaling protocol. > But because there are two IETF protocols, the rest of the > world has to track the two (in addition to other > non-IETF protocols). > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > > -----Original Message----- > > From: Soumen Sarkar [mailto:soumen@sasken.com] > > Sent: Tuesday, July 23, 2002 3:27 AM > > To: Loa Andersson; mpls@UU.NET > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > > > Loa, > > The response so far heavily indicated for RSVP-TE ( obviously > > not because of the > > merits of RSVP-TE over LDP-CR ). If one has to accept the > > basic ground-rule, which is, > > how many major players are pushing for RSVP-TE, one would > > blindly vote for RSVP-TE. > > The more esoteric view, which is, single signaling > > protocol would help > > everyone to concentrate better in addressing unresolved > > problems in MPLS, is also > > appreciably reasonable to accept. > > But looking from holistic perspective, is it not too > > premature at this time to > > conclude on this issue unilaterally (even if there is 3/4 > > majority in favour if it ) > > when this particular issue affects other standard bodies too > > ? We know for sure, OIF > > is still tracking LDP-CR as an alternative signaling protocol > > for optical control > > plane. Are we not pushing something without even considering > > future implication of it > > ? One might say, we are not stopping anyone to use LDP-CR as > > such. But none would > > disagree that making IETF take a stand itself is deterrant > > enough and if not that > > much, it is bound to create conflict of interest between IETF > > and others. > > Are we really ready for this ? IETF traditionally has been > > more a forum for vouching > > technical solutions, not imposing it. Are we deviating from > > that path with full > > understanding ? > > -best regards, > > Soumen > > > > Loa Andersson wrote: > > > > > Heinrich, > > > > > > in my opinion the question is very clearly stated - is > > there support for > > > us (the ietf) to move the cr-ldp from standard track to > > informational. > > > We're "speaking for the ietf", it is more a matter of what we say ;) > > > > > > All, > > > > > > As usual we are trying to reach a rough consensus. Everyone > > (i.e. the > > > mpls wg) can help create this consensus by answering the question > > > above. > > > > > > Especially it will be helpful if you were involved in specifying the > > > mpls protocols, have implemented or deployed (SP) those > > protocols, and > > > take the time to respond. > > > > > > I will be ready to give the first extensive tally mid this week. > > > Currently the count is > > > yes: 30 no: 7, > > > if you normalize those e.g. by counting each company once it is > > > yes: 21 no: 4 > > > > > > Disclaimer: Given that I've managed to decipher the > > sometimes cryptic > > > mails correctly :o) > > > > > > /Loa > > > > > > Hummel Heinrich wrote: > > > > > > > I think, the IETF can only speak for itself. There may > > be other standardization > > > > > > >bodies (ITU-T, MPLS Forum) which may fill > > > > the gap. > > > > > > > > Heinrich Hummel > > > > Siemens AG > > > > > > > > > > -- > > > 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 Jul 24 01:44:47 2002 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 ESMTP id BAA16294 for ; Wed, 24 Jul 2002 01:44:46 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvv21358 for ; Wed, 24 Jul 2002 05:45:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyvv20534; Wed, 24 Jul 2002 05:45:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyvu27989 for mpls-outgoing; Wed, 24 Jul 2002 05:44:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyvu27984 for ; Wed, 24 Jul 2002 05:44: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 QQmyvu02391 for ; Wed, 24 Jul 2002 05:44:31 GMT From: suchauhan@hss.hns.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvu19972 for ; Wed, 24 Jul 2002 05:44:30 GMT Received: from hindon.hss.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQmyvu19948 for ; Wed, 24 Jul 2002 05:44:29 GMT Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g6O5inY22065; Wed, 24 Jul 2002 11:14:49 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id g6O5jRP13280; Wed, 24 Jul 2002 11:15:27 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C00.001F2179 ; Wed, 24 Jul 2002 11:10:01 +0530 X-Lotus-FromDomain: HSS To: Soumen Sarkar cc: Bala Rajagopalan , Loa Andersson , mpls@UU.NET Message-ID: <65256C00.001F200E.00@sandesh.hss.hns.com> Date: Wed, 24 Jul 2002 11:11:47 +0530 Subject: Re: initiating a discussion on mpls singaling protocols Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=5IcP6K6KB9Gt369R7P9GDgDSocBl9sqawQLH1ACQyN4LX8fxfQv8OYBn" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk --0__=5IcP6K6KB9Gt369R7P9GDgDSocBl9sqawQLH1ACQyN4LX8fxfQv8OYBn Content-type: text/plain; charset=us-ascii Content-Disposition: inline hi soumen! I agree with you to a large extent as the basis of evaluation for the two authorities should (I think is) be different and hence irrespective of the fact that whether IETF chooses RSVP-TE, OIF may still go ahead and refine CR-LDP if it feels the need. But, I think Bala's point was made with respect to a mail earlier which referred to OIF using CR-LDP primarily for its work right now. Now this discussion here should (going by your logic and mine above) should at all discuss what would be the effect to discontinuing CR-LDP in IETF on others. As a result of this decision someone like OIF/ITU-T may decide their future course of action but for us (IETF this decision should in no way be influenced by them as of now. When at the cross-roads its best not to go hand in hand with someone as lost as you are, but you might guide others once you (carefully) choose the path you want to walk ! cheers, sumit Soumen Sarkar on 07/24/2002 10:59:24 AM To: Bala Rajagopalan cc: Loa Andersson , mpls@UU.NET (bcc: Sumit Chauhan/HSS) Subject: Re: initiating a discussion on mpls singaling protocols So, In effect you are saying that since OIF and ITU-T are not able to decide which one to pick (based on their requirements), it is benefecial for them that IETF decide which one they want to promote and others will follow! I thought ITU-T and OIF work independently and they have their own parameters to choose the technological alternative. Bala Rajagopalan wrote: > In response to the comment on OIF tracking CR-LDP: > > Life would be simplified for OIF and ITU-T if > there were only a single standard signaling protocol. > But because there are two IETF protocols, the rest of the > world has to track the two (in addition to other > non-IETF protocols). > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > > -----Original Message----- > > From: Soumen Sarkar [mailto:soumen@sasken.com] > > Sent: Tuesday, July 23, 2002 3:27 AM > > To: Loa Andersson; mpls@UU.NET > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > > > Loa, > > The response so far heavily indicated for RSVP-TE ( obviously > > not because of the > > merits of RSVP-TE over LDP-CR ). If one has to accept the > > basic ground-rule, which is, > > how many major players are pushing for RSVP-TE, one would > > blindly vote for RSVP-TE. > > The more esoteric view, which is, single signaling > > protocol would help > > everyone to concentrate better in addressing unresolved > > problems in MPLS, is also > > appreciably reasonable to accept. > > But looking from holistic perspective, is it not too > > premature at this time to > > conclude on this issue unilaterally (even if there is 3/4 > > majority in favour if it ) > > when this particular issue affects other standard bodies too > > ? We know for sure, OIF > > is still tracking LDP-CR as an alternative signaling protocol > > for optical control > > plane. Are we not pushing something without even considering > > future implication of it > > ? One might say, we are not stopping anyone to use LDP-CR as > > such. But none would > > disagree that making IETF take a stand itself is deterrant > > enough and if not that > > much, it is bound to create conflict of interest between IETF > > and others. > > Are we really ready for this ? IETF traditionally has been > > more a forum for vouching > > technical solutions, not imposing it. Are we deviating from > > that path with full > > understanding ? > > -best regards, > > Soumen > > > > Loa Andersson wrote: > > > > > Heinrich, > > > > > > in my opinion the question is very clearly stated - is > > there support for > > > us (the ietf) to move the cr-ldp from standard track to > > informational. > > > We're "speaking for the ietf", it is more a matter of what we say ;) > > > > > > All, > > > > > > As usual we are trying to reach a rough consensus. Everyone > > (i.e. the > > > mpls wg) can help create this consensus by answering the question > > > above. > > > > > > Especially it will be helpful if you were involved in specifying the > > > mpls protocols, have implemented or deployed (SP) those > > protocols, and > > > take the time to respond. > > > > > > I will be ready to give the first extensive tally mid this week. > > > Currently the count is > > > yes: 30 no: 7, > > > if you normalize those e.g. by counting each company once it is > > > yes: 21 no: 4 > > > > > > Disclaimer: Given that I've managed to decipher the > > sometimes cryptic > > > mails correctly :o) > > > > > > /Loa > > > > > > Hummel Heinrich wrote: > > > > > > > I think, the IETF can only speak for itself. There may > > be other standardization > > > > > > >bodies (ITU-T, MPLS Forum) which may fill > > > > the gap. > > > > > > > > Heinrich Hummel > > > > Siemens AG > > > > > > > > > > -- > > > Loa Andersson > > > Chief Architect, > > > Utfors Research, Architecture and Future Lab (URAX) > > > Utfors AB > > > R --0__=5IcP6K6KB9Gt369R7P9GDgDSocBl9sqawQLH1ACQyN4LX8fxfQv8OYBn Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =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 > > = --0__=5IcP6K6KB9Gt369R7P9GDgDSocBl9sqawQLH1ACQyN4LX8fxfQv8OYBn-- From owner-mpls@UU.NET Wed Jul 24 01:57:58 2002 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 ESMTP id BAA16659 for ; Wed, 24 Jul 2002 01:57:57 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvv24789 for ; Wed, 24 Jul 2002 05:58:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyvv23106; Wed, 24 Jul 2002 05:57:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyvv29079 for mpls-outgoing; Wed, 24 Jul 2002 05:57:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyvv29074 for ; Wed, 24 Jul 2002 05:57:28 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 QQmyvv18067 for ; Wed, 24 Jul 2002 05:57:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvv22719 for ; Wed, 24 Jul 2002 05:57:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyvv22714 for ; Wed, 24 Jul 2002 05:57:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA10714 for ; Wed, 24 Jul 2002 01:57:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA05786 for mpls@uu.net; Wed, 24 Jul 2002 01:57:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyvv29055 for ; Wed, 24 Jul 2002 05:56: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 QQmyvv16480 for ; Wed, 24 Jul 2002 05:56:21 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvv15077 for ; Wed, 24 Jul 2002 05:56:21 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmyvv15031 for ; Wed, 24 Jul 2002 05:56:15 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 11:32:03 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA064DFF14@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: David Charlap Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Wed, 24 Jul 2002 11:28:21 +0530 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 TCP being a relaible transport protocol is meant to do just that. It can and has been optimised repeatedly for this purpose. The presence of TCP is almost default in all the stacks. So, there is no need to duplicate a part of its functionality in another protocol and try to optimise it repeatedly in a new thread. Trying to build a semi reliable transport layer inside RSVP-TE with all its paraphenelia to make it harder is another form of duplication so to speak. Also, refreshing a number of LSPs even through summaries is avoided by a single keep alive in CR LDP. Regards, Vijay -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Tuesday, July 23, 2002 9:14 PM To: Vijayanand C - CTD, Chennai. Subject: Re: initiating a discussion on mpls singaling protocols Vijayanand C - CTD, Chennai. wrote: > Apply the refresh reduction procedures to the scenario taking into account > the amount of state you need to store for summary refresh, triggers, refresh > msgs , ACKs/NACKs and associated back off mechanisms in RSVP-TE. Sure, you > might be able to manage but are you efficient considering that you could do > the same thing easily with CR LDP. You are forgetting about the overhead of the TCP protocol, which has to do all the same things to ensure reliable message delivery. This overhead must be added to CR-LDP, since it uses TCP. It is not added to RSVP-TE, which works over raw sockets. The fact that overhead is hidden in a different protocol layer doesn't mean it doesn't exist. -- David From owner-mpls@UU.NET Wed Jul 24 08:09:27 2002 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 ESMTP id IAA02738 for ; Wed, 24 Jul 2002 08:09:27 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywu00467 for ; Wed, 24 Jul 2002 12:10:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmywu29252; Wed, 24 Jul 2002 12:09:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmywu00059 for mpls-outgoing; Wed, 24 Jul 2002 12:09:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmywu00029 for ; Wed, 24 Jul 2002 12:09: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 QQmywu04469 for ; Wed, 24 Jul 2002 12:09:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywu20726 for ; Wed, 24 Jul 2002 12:09:05 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmywu20720 for ; Wed, 24 Jul 2002 12:09:03 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 17:45:45 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA064E0537@haritha.hclt.com> From: "Kannan S (Networking) - CTD, Chennai." Cc: mpls@UU.NET Subject: RE: your mail Date: Wed, 24 Jul 2002 17:41:03 +0530 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 Just a couple of points. Since LSPs are identified as flows, it only goes to show, what should achieved with signalling is being done with ECMP. Signalling protocol should have taken care of distributing different top label(s) to different LSPs(or group of LSPs that would be identified as a 'flow' by ECMP, unless ofcourse the hashing algorithm keeps changing). Also with ECMP, as long as there are label(s) below the top most label(s) identified by the LSR doing ECMP, the EC-paths should end at a point, where the bottom label(s) are recognized. The EC-paths cannot be end to end. Kans. -----Original Message----- From: Gray, Eric [mailto:egray@celoxnetworks.com] Sent: Tuesday, July 23, 2002 8:51 PM To: 'Shahram Davari'; 'erosen@cisco.com' Cc: mpls@UU.NET Subject: RE: your mail Shahram, As you said (or implied) earlier, using the entire MPLS stack identifies the inner-most LSP. This might be considered a 'flow', by some definitions of flow. It is an interesting fact that containing LSPs are 'flows' by a coarser definition and even the inner most LSP is likely to be an aggregation of 'flows' by some finer definition of flow. One could seek to get to an even finer definition of flow by going beyond the bottom of stack label. One question is whether or not this is necessary, or even helpful to at least the extent that it might be hard to do. A separate questions is whether or not it can even be done correctly. The key considerations in picking an approach to doing ECMP are maximizing the extent to which traffic is (expected to be) evenly distributed while avoiding risk of scattering traffic in doing so. An example of traffic scattering would be what would happen if you attempt to use IP DA/SA as part of your hash key (bucket selector) with non IP packets (particularly if the bit positions corresponding to IP DA/SA happen to be associated with fields that change from one packet to the next in any specific flow under consideration). While developing a hash based on identifying flows is a sufficient means to ensure that individual flows do not get scattered, it is not necessary (the usual formal definition of necessary and sufficient apply here). If it is known that flows will be bucketed in any aggregate form, then individual flows will be bucketed that way as well and will not be scattered. After some thought, it becomes clear that one way to bucket flows in such an aggregate form is to use the first and last label in the stack (where last means any label that can be consistently selected based on either the bottom of stack indication or some number N that is the highest number of labels that can be examined by a particular implementation). This is what was proposed. This reduces the question to whether or not there is anything to gain - in terms of distribution equity - from using a finer aggregate. The answer to this is something each implementer has to decide for themselves based on specifics of their own implementation. A very important consideration is how much information their implementation wants to - or even can - know about the quantity of traffic that is associated with individual flows at whatever granularity they choose to use. I believe the proposal describes a reasonable basis for doing ECMP that will fit many/most implementations. Incidentally, there are many algorithms that will generate a hash from a bit stream of nearly arbitrary length (it cannot be infinite, for example). That's a completely unrelated topic, in my opinion. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Tuesday, July 23, 2002 10:04 AM To: 'Gray, Eric'; 'erosen@cisco.com' Cc: mpls@UU.NET Subject: RE: your mail Thanks Eric, Your response seems reasonable. However, I have heard that some implementation hash the label stack, up to the Nth label or bottom-label (if the stack has less than N labels). Does that mean that the hashing algorithm should operate on a variable length input? And if so does such an algorithm exist? Yours, -Shahram > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Monday, July 22, 2002 5:06 PM > To: Shahram Davari; 'erosen@cisco.com' > Cc: mpls@UU.NET > Subject: RE: your mail > > > Shahram, > > There is nothing to be fearful, uncertain or > doubtful about here. > > If an implementation can handle up to N labels, > then it can use either the bottom-of-stack label or > the Nth label for a hash key. With respect to flows, > this will be consistent. It will also tend to give > the greatest degree of entropy in hashing possible > for a specific labeled packet. It doesn't guarantee > even distribution any worse than any other 'guess'. > > Use of the IP header as well is a) unnecessary, > b) unhelpful and c) not a good idea. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, July 22, 2002 4:48 PM > To: 'erosen@cisco.com' > Cc: 'Giles Heron'; neil.2.harrison@bt.com; > eosborne@cisco.com; mpls@UU.NET > Subject: RE: your mail > > Hi Eric, > > If I understand you correctly, what you are saying is that > assume a number > such as "N", and hash the Nth label, regardless of whether it is the > real bottom-most label (i.e. with S=1) or not. If so then: > > 1) How do you know that at least N labels exist in all packets? > 2) The Nth label can not identify a flow by itself, rather > you need to hash > the whole label stack from the top, up to the Nth label, in order to > identify a flow. > 3) I have heard that some implementations hash the IP header > too? How does > that fit in to your model? How do you know that the payload > is IP? And don't > you need to find the real bottom of stack (S=1) in order to > include the IP > header in the hash? > > Yours, > -Shahram > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Monday, July 22, 2002 3:15 PM > > To: Shahram Davari > > Cc: 'Giles Heron'; neil.2.harrison@bt.com; eosborne@cisco.com; > > mpls@UU.NET > > Subject: Re: your mail > > > > > > > > Shahram> "Deep" or "not deep" you need potentially unlimited > > packet parsing > > Shahram> (uo to MTU size), since as you said the number of > > labels are not > > Shahram> limited to 2. > > > > To the MTU size? That would be for the case where the > > entire packet > > contains the MPLS label stack and there is no payload? > > > > As has been made clear repeatedly, you can hash on any > > label, you just get > > more fine-grained load balancing the further down you go. > > So generally you > > would look at the bottom-most label that you can easily > > see, given your > > particular forwarding architecture. > > > > > > > > > From owner-mpls@UU.NET Wed Jul 24 08:25:05 2002 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 ESMTP id IAA07271 for ; Wed, 24 Jul 2002 08:25:05 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywh26126 for ; Wed, 24 Jul 2002 08:46:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmywh25093; Wed, 24 Jul 2002 08:45:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmywg17573 for mpls-outgoing; Wed, 24 Jul 2002 08:44:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmywg17467 for ; Wed, 24 Jul 2002 08:44: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 QQmywg25867 for ; Wed, 24 Jul 2002 08:42:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywg06383 for ; Wed, 24 Jul 2002 08:42:23 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 QQmywg06362 for ; Wed, 24 Jul 2002 08:42:20 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g6O8gEC01249; Wed, 24 Jul 2002 14:12:16 +0530 (IST) Received: from sasken.com (pcz-soumen.sasken.com [10.1.64.68]) by sunsv2.sasken.com (8.11.6/8.11.6) with ESMTP id g6O8gBP09621; Wed, 24 Jul 2002 14:12:11 +0530 (IST) Message-ID: <3D3E6941.9D5BBFBE@sasken.com> Date: Wed, 24 Jul 2002 14:15:53 +0530 From: Soumen Sarkar X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Zafar Ali CC: Bala Rajagopalan , Loa Andersson , mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <05707214338CD5119BFF0040A5B170D3E822E2@mail3.tellium.com> <4.3.2.7.2.20020724021806.020b8948@sword.cisco.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Zafar,
        My intention was not at all to pick on Bala's statement. And my  appology if I have hurt anyone here.
        With due respect to all of you, I just wanted to stress on the fact that, we should not create a counter-logic based on our inclination on particular choice. From IETF's perspective, it would only be consistent, if the decision to put some activity in standard/informational track is taken based on purely technical merits. Anything else would be a deviation and that deviation is bound to impact other standard bodies too if they are working on similar thread. And it would be unfortunate if that impact proves more costly to the industry at later point of time.
-best regards,
Soumen

Zafar Ali wrote:

At 10:59 AM 7/24/2002 +0530, Soumen Sarkar wrote:
So, In effect you are saying that since OIF and ITU-T are not able to decide
which one to pick (based on their requirements), it is beneficial for them
that IETF decide which one they want to promote and others will follow!


Hi Soumen,

This would be a very unfair reading of Bala's email. You should read it in the context that some folks argued that since OIF uses CR-LDP, IETF should not proceed on this notion.

There is no argument that both  IETF, OIF and ITU-T are independent bodies. However, it should not surprise anyone that implementation survey for CR-LDP vs. RSVP-TE for OIF UNI would follow the same sample point. So, yes, OIF can independently make the same decision; not because of the IETF influence but using the same rule of wisdom. But this should be separate discussion at the right mailing alias/ with the right authorities.

Thanks

Regards... Zafar
 

I
thought ITU-T and OIF work independently and they have their own parameters
to choose the technological alternative.

Bala Rajagopalan wrote:

> In response to the comment on OIF tracking CR-LDP:
>
> Life would be simplified for OIF and ITU-T if
> there were only a single standard signaling protocol.
> But because there are two IETF protocols, the rest of the
> world has to track the two (in addition to other
> non-IETF protocols).
>
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: braja@tellium.com
>
> > -----Original Message-----
> > From: Soumen Sarkar [mailto:soumen@sasken.com]
> > Sent: Tuesday, July 23, 2002 3:27 AM
> > To: Loa Andersson; mpls@UU.NET
> > Subject: Re: initiating a discussion on mpls singaling protocols
> >
> >
> > Loa,
> > The response so far heavily indicated for RSVP-TE ( obviously
> > not because of the
> > merits of RSVP-TE over LDP-CR ). If one has to accept the
> > basic ground-rule, which is,
> > how many major players are pushing for RSVP-TE, one would
> > blindly vote for RSVP-TE.
> >         The more esoteric view, which is, single signaling
> > protocol would help
> > everyone to concentrate better in addressing unresolved
> > problems in MPLS, is also
> > appreciably reasonable to accept.
> > But looking from holistic perspective, is it not too
> > premature at this time to
> > conclude on this issue unilaterally (even if there is 3/4
> > majority in favour if it )
> > when this particular issue affects other standard bodies too
> > ? We know for sure, OIF
> > is still tracking LDP-CR as an alternative signaling protocol
> > for optical control
> > plane. Are we not pushing something without even considering
> > future implication of it
> > ? One might say, we are not stopping anyone to use LDP-CR as
> > such. But none would
> > disagree that making IETF take a stand itself is deterrant
> > enough and if not that
> > much, it is bound to create conflict of interest between IETF
> > and others.
> >   Are we really ready for this ? IETF traditionally has been
> > more a forum for vouching
> > technical solutions, not imposing it. Are we deviating from
> > that path with full
> > understanding ?
> > -best regards,
> > Soumen
> >
> > Loa Andersson wrote:
> >
> > > Heinrich,
> > >
> > > in my opinion the question is very clearly stated - is
> > there support for
> > > us (the ietf) to move the cr-ldp from standard track to
> > informational.
> > > We're "speaking for the ietf", it is more a matter of what we say ;)
> > >
> > > All,
> > >
> > > As usual we are trying to reach a rough consensus. Everyone
> > (i.e. the
> > > mpls wg) can help create this consensus by answering the question
> > > above.
> > >
> > > Especially it will be helpful if you were involved in specifying the
> > > mpls protocols, have implemented or deployed (SP) those
> > protocols, and
> > > take the time to respond.
> > >
> > > I will be ready to give the first extensive tally mid this week.
> > > Currently the count is
> > > yes: 30 no: 7,
> > > if you normalize those e.g. by counting each company once it is
> > > yes: 21 no: 4
> > >
> > > Disclaimer: Given that I've managed to decipher the
> > sometimes cryptic
> > > mails correctly :o)
> > >
> > > /Loa
> > >
> > > Hummel Heinrich wrote:
> > >
> > > >  I think, the IETF can only speak for itself. There may
> > be other standardization
> > >
> > > >bodies (ITU-T, MPLS Forum) which may fill
> > > > the gap.
> > > >
> > > > Heinrich Hummel
> > > > Siemens AG
> > > >
> > >
> > > --
> > >      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 Jul 24 08:56:02 2002 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 ESMTP id IAA13776 for ; Wed, 24 Jul 2002 08:56:02 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywx26742 for ; Wed, 24 Jul 2002 12:56:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmywx24213; Wed, 24 Jul 2002 12:55:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmywx04139 for mpls-outgoing; Wed, 24 Jul 2002 12:55:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmywx04132 for ; Wed, 24 Jul 2002 12:55:06 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 QQmywx23502 for ; Wed, 24 Jul 2002 12:53:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywx12888 for ; Wed, 24 Jul 2002 12:53:12 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmywx12882 for ; Wed, 24 Jul 2002 12:53:12 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1P8L>; Wed, 24 Jul 2002 08:53:12 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B0226718A@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Lou Berger'" , mpls@UU.NET Cc: "Gray, Eric" , "'Scott Bradner'" Subject: RE: initiating a discussion on mpls singaling protocols Date: Wed, 24 Jul 2002 08:53:04 -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 Lou, It should be sufficient to update the MPLS working group charter. Suggesting an update to the CR-LDP Applicability indicates agreement in words rather than in spirit, since the precedent set by re-writing an applicability statement to indicate that an RFC is not applicable is not different - in spirit - than the precedent set by simply changing the RFC to an Informational RFC. Nice try, though! :-) Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Tuesday, July 23, 2002 9:29 PM To: mpls@UU.NET Cc: Gray, Eric; 'Scott Bradner' Subject: Re: initiating a discussion on mpls singaling protocols I like Scott's summary of the issues and choices and 100% agree with Eric's response. Assuming that we follow this one step further, and make future CR-LDP work informational, shouldn't this decision be documented somewhere? Maybe in an updated CR-LDP applicability statement? Is the issue of how to indicate this decision the reason that reclassification of CR-LDP came up? Lou Gray, Eric wrote: > Scott, > > I think it is perfectly acceptable that ongoing work > on CR-LDP - both current and immediately anticipated - should > be targeted for Informational RFCs. The focus needs to be on > what people who are writing the drafts are implementing and > it is clear that this is RSVP-TE in nearly every case. I > believe most people will agree that this should remove any > perception that there is a requirement to define everything > twice in MPLS signaling. In addition, if the CR-LDP drafts > are targeted for Informational status, this relieves the WG > of some of the distraction associated with having to do a > thorough review of each signaling protocols extension twice. > > Please see responses to your specific questions below. > > Thanks for putting the issues in a clear perspective! > > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Tuesday, July 23, 2002 8:02 PM > To: mpls@UU.NET > Subject: RE: initiating a discussion on mpls singaling protocols > > > the question has been asked about reclassifying a already published > RFC from Proposed Standard to Informational (i.e. de-standardization) > > A/ I do not know of a case where this has been done > B/ RFC 2026 talks about moving to historic not info > > (in my opinion moving to historc should be done where there is > a specific strong reason (or reasons) such as security (see RFC 1923 > for an example of stating reasons).) > > my own opinion is that it would set a very precedent to de-standardize at > all > and a very bad one to do such a short time after the RFC was published > > I expect we can tell for sure in 4 or 5 years how a technology will be > received but I doubt that we can tell much in just 6 months > > I think the more important question is about on-going CR-LDP work -- > should be CR-LPD work be relegated to non-standards track? > > specific questions: > A/ should IETF working group charters be modified to remove a requirement > to work on CR-LPD technologies? > > Yes. > > B/ if there is CR-LDP work already in progress, what should happen to it? > > It should be targeted for Informational RFC status. > Since these drafts are mostly of the form of - if you were going > to do the same thing using CR-LDP, this is how you would do it - > therefore, informational status makes more sense. > > C/ if a working group requests publication of RFCs about CR-LDP > technology on the standards track what should we do? > > Use the usual procedure of IESG review. Was the WG chartered to > do this work? If so, how did this happen? I think it is not > necessary to erect some type of contrived barrier as there will > be a sufficiently high natural barrier to inappropriate work of > this kind. > > D/ if someone requests independent publication of RFCs about CR-LPD > technology on the standards track (as permitted by RFC 2026) what > should we do? > > Again, this would fall under usual procedures. The RFC Editor > would typically kick this to the IESG hence causing it to be > assigned to the appropriate working group (or not) as the IESG > determines to be appropriate. As I understand it, the RFC > Editor is not obliged to publish anything as a standards track > RFC and will not unless satisfied that the right thing is being > done by doing so. > > (I see no way for the IETF to refuse to publish CR-LDP related infor or > experimental RFCs - the IETF is not in the business of suppressing > technology) > > Scott > From owner-mpls@UU.NET Wed Jul 24 09:18:27 2002 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 ESMTP id JAA14902 for ; Wed, 24 Jul 2002 09:18:27 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywn05974 for ; Wed, 24 Jul 2002 10:17:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmywn05009; Wed, 24 Jul 2002 10:17:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmywn08996 for mpls-outgoing; Wed, 24 Jul 2002 10:16:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmywn08991 for ; Wed, 24 Jul 2002 10:16: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 QQmywn04852 for ; Wed, 24 Jul 2002 10:16:23 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywn04571 for ; Wed, 24 Jul 2002 10:16:23 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQmywn04562 for ; Wed, 24 Jul 2002 10:16:22 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA14052; Wed, 24 Jul 2002 12:15:58 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA14897; Wed, 24 Jul 2002 12:16:15 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 12:16:13 +0200 Message-ID: From: Hummel Heinrich To: "'David Charlap'" , IETF MPLS List Subject: AW: initiating a discussion on mpls singaling protocols Date: Wed, 24 Jul 2002 12:16:14 +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 JAA14902 I know. But LDP does. It takes a little bit from LDP, and a little bit from CR-LDP. But of course, I acknowledge, that both could be taken and combined, even if CR-LDP becomes informational. Heinrich -----Ursprüngliche Nachricht----- Von: David Charlap [mailto:david.charlap@marconi.com] Gesendet: Dienstag, 23. Juli 2002 18:46 An: IETF MPLS List Betreff: Re: AW: initiating a discussion on mpls singaling protocols Hummel Heinrich wrote: > > But let me repeat my technical point: > Building hierarchical mp2p LSPs, from the egress towards a set of ingress nodes, i.e. > building a sink tree out of LSPs. > Here downstream unsolicited mode is appropriate. So we need LDP. But because existing LSPs have to be concatenated > (by label switching) we need their LSP-IDs. And this is provided by CR-LDP. > > It takes a lot more to create RSVP-TE Downstream Unsolicited mode. I think you are misunderstanding CR-LDP. It doesn't support downstream unsolicited mode either. -- David From owner-mpls@UU.NET Wed Jul 24 10:03:22 2002 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 ESMTP id KAA17610 for ; Wed, 24 Jul 2002 10:03:22 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywo22168 for ; Wed, 24 Jul 2002 10:40:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmywo20455; Wed, 24 Jul 2002 10:39:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmywo10065 for mpls-outgoing; Wed, 24 Jul 2002 10:39:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmywo10058 for ; Wed, 24 Jul 2002 10:39:30 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 QQmywo11963 for ; Wed, 24 Jul 2002 10:37:25 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywo29044 for ; Wed, 24 Jul 2002 10:37:25 GMT Received: from mail1.hd.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hdfdns01.hd.intel.com [192.52.58.10]) id QQmywo29034 for ; Wed, 24 Jul 2002 10:37:24 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by mail1.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6OAbOM13114 for ; Wed, 24 Jul 2002 10:37:24 GMT Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002072403363322999 ; Wed, 24 Jul 2002 03:36:34 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 12:33:45 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0329C5FE@alpha.igk.intel.com> From: "Bisewski, Radoslaw" To: IETF MPLS List Cc: "'Hummel Heinrich'" Subject: RE: initiating a discussion on mpls singaling protocols Date: Wed, 24 Jul 2002 12:33:42 +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 KAA17610 There is at least one additional advantage of the CR-LDP over the RSVP-TE: CR-LDP is defined as an extensions to the MPLS LDP protocol, while RSVP-TE has nothing in common with MPLS LDP. It is much easier to implement MPLS LDP with CR-LDP extensions than to implement two distinct protocols MPLS LDP and RSVP-TE. Regards Radek > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: Wednesday, July 24, 2002 12:16 PM > To: 'David Charlap'; IETF MPLS List > Subject: AW: initiating a discussion on mpls singaling protocols > > > I know. But LDP does. It takes a little bit from LDP, and a > little bit from CR-LDP. > > But of course, I acknowledge, that both could be taken and > combined, even if CR-LDP becomes informational. > Heinrich > > -----Ursprüngliche Nachricht----- > Von: David Charlap [mailto:david.charlap@marconi.com] > Gesendet: Dienstag, 23. Juli 2002 18:46 > An: IETF MPLS List > Betreff: Re: AW: initiating a discussion on mpls singaling protocols > > > Hummel Heinrich wrote: > > > > But let me repeat my technical point: > > Building hierarchical mp2p LSPs, from the egress towards a > set of ingress nodes, i.e. > > building a sink tree out of LSPs. > > Here downstream unsolicited mode is appropriate. So we need > LDP. But because existing LSPs have to be concatenated > > (by label switching) we need their LSP-IDs. And this is > provided by CR-LDP. > > > > It takes a lot more to create RSVP-TE Downstream Unsolicited mode. > > I think you are misunderstanding CR-LDP. It doesn't support > downstream > unsolicited mode either. > > -- David > From owner-mpls@UU.NET Wed Jul 24 10:10:00 2002 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 ESMTP id KAA18028 for ; Wed, 24 Jul 2002 10:09:59 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxc28247 for ; Wed, 24 Jul 2002 14:10:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxc26747; Wed, 24 Jul 2002 14:10:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxc23371 for mpls-outgoing; Wed, 24 Jul 2002 14:09:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyxc23305 for ; Wed, 24 Jul 2002 14:09: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 QQmyxc28049 for ; Wed, 24 Jul 2002 14:07:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxc03018 for ; Wed, 24 Jul 2002 14:07:10 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyxc02992 for ; Wed, 24 Jul 2002 14:07:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA29341 for ; Wed, 24 Jul 2002 10:07:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA26090 for mpls@uu.net; Wed, 24 Jul 2002 10:07:05 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyxc14470 for ; Wed, 24 Jul 2002 14:06:11 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 QQmyxc25046 for ; Wed, 24 Jul 2002 14:05:51 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxc02460 for ; Wed, 24 Jul 2002 14:05:50 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 QQmyxc02455 for ; Wed, 24 Jul 2002 14:05:50 GMT Received: (qmail 8202 invoked by uid 104); 24 Jul 2002 14:05:49 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4213. . Clean. Processed in 0.455829 secs); 24 Jul 2002 14:05:49 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 24 Jul 2002 14:05:49 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6OE5mc23840; Wed, 24 Jul 2002 07:05:48 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 07:05:49 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0375D@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Scott Bradner'" , mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Wed, 24 Jul 2002 07:05: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 Scott, If future work on CR-LDP is decided to be Informational, will IETF still be concerned with extensions to CR-LDP by other standard organizations? Yours, -Shahram > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Tuesday, July 23, 2002 8:02 PM > To: mpls@UU.NET > Subject: RE: initiating a discussion on mpls singaling protocols > > > > the question has been asked about reclassifying a already published > RFC from Proposed Standard to Informational (i.e. de-standardization) > > A/ I do not know of a case where this has been done > B/ RFC 2026 talks about moving to historic not info > > (in my opinion moving to historc should be done where there is > a specific strong reason (or reasons) such as security (see RFC 1923 > for an example of stating reasons).) > > my own opinion is that it would set a very precedent to > de-standardize at all > and a very bad one to do such a short time after the RFC was published > > I expect we can tell for sure in 4 or 5 years how a technology will be > received but I doubt that we can tell much in just 6 months > > I think the more important question is about on-going CR-LDP work -- > should be CR-LPD work be relegated to non-standards track? > > specific questions: > A/ should IETF working group charters be modified to remove a > requirement > to work on CR-LPD technologies? > B/ if there is CR-LDP work already in progress, what should > happen to it? > C/ if a working group requests publication of RFCs about CR-LPD > technology on the standards track what should we do? > D/ if someone requests independent publication of RFCs about CR-LPD > technology on the standards track (as permitted by RFC 2026) what > should we do? > > (I see no way for the IETF to refuse to publish CR-LDP > related infor or > experimental RFCs - the IETF is not in teh business of suppressing > technology) > > Scott > From owner-mpls@UU.NET Wed Jul 24 10:26:32 2002 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 ESMTP id KAA18708 for ; Wed, 24 Jul 2002 10:26:32 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxd15906 for ; Wed, 24 Jul 2002 14:27:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxd14174; Wed, 24 Jul 2002 14:26:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxd25785 for mpls-outgoing; Wed, 24 Jul 2002 14:26:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyxd25734 for ; Wed, 24 Jul 2002 14:25: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 QQmyxd10050 for ; Wed, 24 Jul 2002 14:25:13 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxd12368 for ; Wed, 24 Jul 2002 14:25:13 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyxd12364 for ; Wed, 24 Jul 2002 14:25:12 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA00739 for ; Wed, 24 Jul 2002 10:25:12 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA29277 for mpls@uu.net; Wed, 24 Jul 2002 10:25:12 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyva15502 for ; Wed, 24 Jul 2002 00:39: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 QQmyva19845 for ; Wed, 24 Jul 2002 00:37:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyva10946 for ; Wed, 24 Jul 2002 00:37:24 GMT Received: from fsbsd.thefsb.org by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: dsl092-074-154.bos1.dsl.speakeasy.net [66.92.74.154]) id QQmyva10934 for ; Wed, 24 Jul 2002 00:37:23 GMT Received: (qmail 87089 invoked from network); 24 Jul 2002 00:37:18 -0000 Received: from unknown (HELO ?192.168.65.105?) (192.168.65.105) by dsl092-074-154.bos1.dsl.speakeasy.net with SMTP; 24 Jul 2002 00:37:18 -0000 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 23 Jul 2002 20:37:15 -0400 Subject: Re: initiating a discussion on mpls singaling protocols From: tom worster To: , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit eric wrote: > I am not sure that Informational is the right > way to go. Perhaps Experimental or Historical is > better. i looked through 2026. it makes it clear that the procedure for retiring a standards track spec is for the iesg to change its status to historic and that a wg may request the change. the text in there also says that the informational rfc type is intended for "timely publication" of pertinent information. it doesn't sound to me like it was intended as a receptacle for obsolete standards. but what do i know? if my reading were accurate then the ad would have pointed this out by now. c u fsb From owner-mpls@UU.NET Wed Jul 24 10:26:33 2002 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 ESMTP id KAA18718 for ; Wed, 24 Jul 2002 10:26:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxd18331 for ; Wed, 24 Jul 2002 14:27:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxd16723; Wed, 24 Jul 2002 14:26:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxd25807 for mpls-outgoing; Wed, 24 Jul 2002 14:26:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyxd25755 for ; Wed, 24 Jul 2002 14:26: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 QQmyxd06495 for ; Wed, 24 Jul 2002 14:24:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxd15778 for ; Wed, 24 Jul 2002 14:24:30 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmyxd15757 for ; Wed, 24 Jul 2002 14:24:30 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6OENxp24804; Wed, 24 Jul 2002 10:23:59 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 10:23:58 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04B1033C@zcard031.ca.nortel.com> From: "David Allan" To: Soumen Sarkar , Loa Andersson Cc: "Ong, Lyndon" , "'mborden@acm.org'" , egray@celoxnetworks.com, "'avri'" , mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Wed, 24 Jul 2002 10:23:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2331D.BF208D88" 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_01C2331D.BF208D88 Content-Type: text/plain; charset="iso-8859-1" I also think Avri has raised an important point, and when I saw this item on the WG agenda, I expected the discussion to be about a move to historical and not informational status (which I would have considered premature). I share the expressed concern about de-standardization. Seems to me there should be a third path. That is no change to status, and no longer require or encourage that these protocols be joined at the hip. If they cross pollinate, so be it, but it is by desire not fiat. Seems to me that this artificial joining is the actual problem both from a "failure to differentiate" and "make work" POV. cheers Dave > -----Original Message----- > From: Soumen Sarkar [mailto:soumen@sasken.com] > Sent: Wednesday, July 24, 2002 6:04 AM > To: Loa Andersson > Cc: Ong, Lyndon; 'mborden@acm.org'; egray@celoxnetworks.com; 'avri'; > mpls@UU.NET > Subject: Re: initiating a discussion on mpls singaling protocols > > > Loa, > Thanks for summarizing. I would support the 2nd approach > on the ground that > Avri has nicely has put forth. > 2ndly, this approach is very much aligned to IETF's way of working. > -best regards, > Soumen > > Loa Andersson wrote: > > > All, > > > > (off list for clarification) > > it seems like you are agreeing based on two very different > approaches. > > > > 1. don't do anyhting about the doc status to cr-ldp, but stop all > > work on it (Lyndon) > > 2. don't do anything to doc status, but require (encoruage) that id > > authors work only on one singalling protocol at a time (Eric). > > > > 1 is very close to what was proposed at the mpls wg meeting, 2 is > > actually a decission to continue develop cr-ldp. > > > > /Loa > > > > Ong, Lyndon wrote: > > > > > This might be actually a reasonable solution, to "cap" the > > > work on CR-LDP. I'd have the same concern as Avri with > > > taking an approved standard and "de-standardizing" it, > > > although it would help to know if this has been done > > > before. > > > > > > Cheers, > > > > > > Lyndon Ong > > > Ciena > > > > > > -----Original Message----- > > > From: Marty Borden [mailto:m.borden@verizon.net] > > > Sent: Tuesday, July 23, 2002 9:38 AM > > > To: egray@celoxnetworks.com; 'avri' > > > Cc: mpls@UU.NET > > > Subject: RE: initiating a discussion on mpls singaling protocols > > > > > > > > > Eric, > > > Well that would be good if it were acceptable for a draft > > > to not have to cover both approaches. Is that really acceptable? > > > marty > > > > > > > > > On 7/23/2002 at 12:09 PM Gray, Eric wrote: > > > > > > |Avri makes a very good point here. > > > | > > > |I think the implementation survey makes it obvious that > > > |we should progress RSVP-TE (and related work) to Draft > > > |Standard. It seems equally clear that we should not do > > > |so for CR-LDP at this point. > > > | > > > |Letting CR-LDP die on the vine certainly seems in keeping > > > |with what the IETF has done in the past. > > > | > > > |Eric W. Gray > > > |Systems Architect > > > |Celox Networks, Inc. > > > |egray@celoxnetworks.com > > > |508 305 7214 > > > | > > > | > > > |-----Original Message----- > > > |From: avri [mailto:avri@sm.luth.se] > > > |Sent: Tuesday, July 23, 2002 9:26 AM > > > |Cc: MPLS wg > > > |Subject: Re: initiating a discussion on mpls singaling protocols > > > | > > > | > > > | > > > |This seems to me a very strange proposal. And in fact > seems to be > > > |a perversion of the IETF standards process as i understand it. > > > | > > > |If things are as argued, then RSVP-TE will progress to > draft standard > > > |and then to standard, while CR-LDP remains a proposed > standard. If > > > |it languishes long enough in the proposed state, without > significant > > > |deployment or utility, then it would seem appropriate to > transition it > > > |to historic at some point in the future. > > > | > > > |Taking it to informational at this point seems a fairly > blatant political > > > |move without technical merit. At best it is an > administrative sleight > > > |of hand that could strange repercussions as a precedent. > Is the IETF > > > |going to embark next on an effort to define all protocol > duplication > > > |out of existence by voting on which alternative to make > informational? > > > | > > > |I would suggest (as voting is not something I thought > the IETF did) that > > > |both protocols remain as ps. If CR-LDP withers on the > vine because it has > > > |no utility, so be it. Voting to change its status seems > inappropriate to > > > |me. > > > | > > > |a. > > > > > > > > > > > > > > > > -- > > 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 > > ------_=_NextPart_001_01C2331D.BF208D88 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: initiating a discussion on mpls singaling protocols

I also think Avri has raised an important point, and = when I saw this item on the WG agenda, I expected the discussion to be = about a move to historical and not informational status (which I would = have considered premature). I share the expressed concern about = de-standardization.

Seems to me there should be a third path. That is no = change to status, and no longer require or encourage that these = protocols be joined at the hip. If they cross pollinate, so be it, but = it is by desire not fiat. Seems to me that this artificial joining is = the actual problem both from a "failure to differentiate" and = "make work" POV.

cheers
Dave

> -----Original Message-----
> From: Soumen Sarkar [mailto:soumen@sasken.com]
> Sent: Wednesday, July 24, 2002 6:04 AM
> To: Loa Andersson
> Cc: Ong, Lyndon; 'mborden@acm.org'; = egray@celoxnetworks.com; 'avri';
> mpls@UU.NET
> Subject: Re: initiating a discussion on mpls = singaling protocols
>
>
> Loa,
>     Thanks for summarizing. = I would support the 2nd approach
> on the ground that
> Avri has nicely has put forth.
>   2ndly, this approach is very much = aligned to IETF's way of working.
> -best regards,
> Soumen
>
> Loa Andersson wrote:
>
> > All,
> >
> > (off list for clarification)
> > it seems like you are agreeing based on = two very different
> approaches.
> >
> > 1. don't do anyhting about the doc status = to cr-ldp, but stop all
> >     work on it = (Lyndon)
> > 2. don't do anything to doc status, but = require (encoruage) that id
> >     authors work only = on one singalling protocol at a time (Eric).
> >
> > 1 is very close to what was proposed at = the mpls wg meeting, 2 is
> > actually a decission to continue develop = cr-ldp.
> >
> > /Loa
> >
> > Ong, Lyndon wrote:
> >
> > > This might be actually a reasonable = solution, to "cap" the
> > > work on CR-LDP.  I'd have the = same concern as Avri with
> > > taking an approved standard and = "de-standardizing" it,
> > > although it would help to know if = this has been done
> > > before.
> > >
> > > Cheers,
> > >
> > > Lyndon Ong
> > > Ciena
> > >
> > > -----Original Message-----
> > > From: Marty Borden [mailto:m.borden@verizon.net]
> > > Sent: Tuesday, July 23, 2002 9:38 = AM
> > > To: egray@celoxnetworks.com; = 'avri'
> > > Cc: mpls@UU.NET
> > > Subject: RE: initiating a discussion = on mpls singaling protocols
> > >
> > >
> > > Eric,
> > > Well that would be good if it were = acceptable for a draft
> > > to not have to cover both = approaches.  Is that really acceptable?
> > > marty
> > >
> > >
> > > On 7/23/2002 at 12:09 PM Gray, Eric = wrote:
> > >
> > > |Avri makes a very good point = here.
> > > |
> > > |I think the implementation survey = makes it obvious that
> > > |we should progress RSVP-TE (and = related work) to Draft
> > > |Standard.  It seems equally = clear that we should not do
> > > |so for CR-LDP at this point.
> > > |
> > > |Letting CR-LDP die on the vine = certainly seems in keeping
> > > |with what the IETF has done in the = past.
> > > |
> > > |Eric W. Gray
> > > |Systems Architect
> > > |Celox Networks, Inc.
> > > |egray@celoxnetworks.com
> > > |508 305 7214
> > > |
> > > |
> > > |-----Original Message-----
> > > |From: avri [mailto:avri@sm.luth.se]
> > > |Sent: Tuesday, July 23, 2002 9:26 = AM
> > > |Cc: MPLS wg
> > > |Subject: Re: initiating a discussion = on mpls singaling protocols
> > > |
> > > |
> > > |
> > > |This seems to me a very strange = proposal.  And in fact
> seems to be
> > > |a perversion of the IETF standards = process as i understand it.
> > > |
> > > |If things are as argued, then = RSVP-TE will progress to
> draft standard
> > > |and then to standard, while CR-LDP = remains a proposed
> standard.  If
> > > |it languishes long enough in the = proposed state, without
> significant
> > > |deployment or utility, then it would = seem appropriate to
> transition it
> > > |to historic at some point in the = future.
> > > |
> > > |Taking it to informational at this = point seems a fairly
> blatant political
> > > |move without technical merit.  = At best it is an
> administrative sleight
> > > |of hand that could strange = repercussions as a precedent.
>  Is the IETF
> > > |going to embark next on an effort to = define all protocol
> duplication
> > > |out of existence by voting on which = alternative to make
> informational?
> > > |
> > > |I would suggest (as voting is not = something I thought
> the IETF did) that
> > > |both protocols remain as ps. If = CR-LDP withers on the
> vine because it has
> > > |no utility, so be it.  Voting = to change its status seems
> inappropriate to
> > > |me.
> > > |
> > > |a.
> > >
> > >
> > >
> > >
> >
> > --
> >      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_01C2331D.BF208D88-- From owner-mpls@UU.NET Wed Jul 24 10:30:35 2002 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 ESMTP id KAA19139 for ; Wed, 24 Jul 2002 10:30:35 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywa16128 for ; Wed, 24 Jul 2002 07:01:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmywa14786; Wed, 24 Jul 2002 07:00:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmywa27681 for mpls-outgoing; Wed, 24 Jul 2002 07:00:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmywa26571 for ; Wed, 24 Jul 2002 07:00: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 QQmyvz16506 for ; Wed, 24 Jul 2002 06:58:38 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvz27432 for ; Wed, 24 Jul 2002 06:58:38 GMT Received: from web20905.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20905.mail.yahoo.com [216.136.226.227]) id QQmyvz27428 for ; Wed, 24 Jul 2002 06:58:38 GMT Message-ID: <20020724065837.11747.qmail@web20905.mail.yahoo.com> Received: from [203.200.20.226] by web20905.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 23:58:37 PDT Date: Tue, 23 Jul 2002 23:58:37 -0700 (PDT) From: Atul Gupta Subject: Notification process To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, In GMPLS we use Notification Message to avoid the large propagation delays of the error messages. Can we use same message in MPLS so that existing Path/Resv States can be removed quikly and resources are also preserved. Atul Samsung ===== Atul Gupta Samsung Software __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-mpls@UU.NET Wed Jul 24 10:45:53 2002 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 ESMTP id KAA19807 for ; Wed, 24 Jul 2002 10:45:48 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxf05537 for ; Wed, 24 Jul 2002 14:46:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxf03284; Wed, 24 Jul 2002 14:45:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxf27352 for mpls-outgoing; Wed, 24 Jul 2002 14:45:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyxf27347 for ; Wed, 24 Jul 2002 14:45: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 QQmyxe15525 for ; Wed, 24 Jul 2002 14:44:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxe02478 for ; Wed, 24 Jul 2002 14:44:52 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 QQmyxe02472 for ; Wed, 24 Jul 2002 14:44:51 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 KAA02805 for ; Wed, 24 Jul 2002 10:44:49 -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 KAA26605 for ; Wed, 24 Jul 2002 10:44:50 -0400 (EDT) Message-ID: <3D3EBD7F.4020603@marconi.com> Date: Wed, 24 Jul 2002 10:45:19 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: initiating a discussion on mpls singaling protocols References: <55E277B99171E041ABF5F4B1C6DDCA064DFF14@haritha.hclt.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijayanand C - CTD, Chennai. wrote: > TCP being a relaible transport protocol is meant to do just that. It can and > has been optimised repeatedly for this purpose. The presence of TCP is > almost default in all the stacks. So, there is no need to duplicate a part > of its functionality in another protocol and try to optimise it repeatedly > in a new thread. Trying to build a semi reliable transport layer inside > RSVP-TE with all its paraphenelia to make it harder is another form of > duplication so to speak. Also, refreshing a number of LSPs even through > summaries is avoided by a single keep alive in CR LDP. Thanks for changing the subject here. You were talking about protocol complexity, not implementation stability. Of course a new protocol implementation will be less stable than something 20 years old. Does this mean we should avoid developing anything new ever again? As for the rest, TCP is not an appropriate transport for signaling protocols in the first place. RSVP-TE, LDP and CR-LDP all use a message-passing mechanism. They are not designed around streaming data. Use of a streaming protocol means that the protocol has to deal with the issue of detecting message boundaries and half-received messages. Unfortunately, there is no standard for anything resembling reliable UDP - that would be ideal. The message-ID part of RSVP refresh reduction is designed to fill this void. Packets can't be half-received, and message boundaries are preserved. Retransmission is on a per-message basis instead of for the entire flow, so one dropped message doesn't cause all subsequent messages to back up waiting for the retransmission. It also recognizes the fact that not all messages need to be delivered reliably, and allows RSVP to not use the mechanism for those messages that don't result in state changes. With regard to refreshing, you don't seem to appreciate what the refresh reduction extension buys. There is no need to generate summary refreshes every 30 seconds. As I have said before, when refresh reduction and hellos are both in place, there is no need for frequent refreshes. Under this circumstance, you can set the refresh interval to something on the order of hours, or even days without any ill effect. How is this have any more overhead than what CR-LDP does. -- David From owner-mpls@UU.NET Wed Jul 24 10:56:53 2002 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 ESMTP id KAA20241 for ; Wed, 24 Jul 2002 10:56:52 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxf09418 for ; Wed, 24 Jul 2002 14:57:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxf07515; Wed, 24 Jul 2002 14:57:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxf28388 for mpls-outgoing; Wed, 24 Jul 2002 14:56:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyxf28383 for ; Wed, 24 Jul 2002 14:56: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 QQmyxf23898 for ; Wed, 24 Jul 2002 14:56:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxf16228 for ; Wed, 24 Jul 2002 14:56:07 GMT Received: from dharti.aplion.stpn.soft.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.133.225]) id QQmyxf16201 for ; Wed, 24 Jul 2002 14:56:04 GMT Received: from cyborg (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g6OEvqO16398 for ; Wed, 24 Jul 2002 20:27:52 +0530 Reply-To: From: "Mayank Kumar" To: "Mpls \(E-mail\)" Subject: Penultimate hop popping in rsvp Date: Wed, 24 Jul 2002 20:29:12 +0530 Message-ID: <00d701c23322$acb59080$feca64c0@cyborg> 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 hi can any body tell me if Penultimate hop popping is supported in rsvp-te thanks and regards Mayank From owner-mpls@UU.NET Wed Jul 24 11:05:13 2002 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 ESMTP id LAA20562 for ; Wed, 24 Jul 2002 11:05:12 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxg23634 for ; Wed, 24 Jul 2002 15:06:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxg21695; Wed, 24 Jul 2002 15:05:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxg10973 for mpls-outgoing; Wed, 24 Jul 2002 15:04:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyxg10966 for ; Wed, 24 Jul 2002 15:04: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 QQmyxg21373 for ; Wed, 24 Jul 2002 15:04:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxg00815 for ; Wed, 24 Jul 2002 15:04:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyxg00811 for ; Wed, 24 Jul 2002 15:04:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA03711 for ; Wed, 24 Jul 2002 11:04:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA05125 for mpls@uu.net; Wed, 24 Jul 2002 11:04:04 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyxg08547 for ; Wed, 24 Jul 2002 15:02: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 QQmyxg02729 for ; Wed, 24 Jul 2002 15:02:35 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxg00015 for ; Wed, 24 Jul 2002 15:02:35 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyxg00011 for ; Wed, 24 Jul 2002 15:02:35 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA03590; Wed, 24 Jul 2002 11:02:34 -0400 (EDT) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA16587; Wed, 24 Jul 2002 11:02:34 -0400 (EDT) Message-Id: <200207241502.LAA16587@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: mkumar@aplion.stpn.soft.net cc: "Mpls \(E-mail\)" , swallow@cisco.com Subject: Re: Penultimate hop popping in rsvp In-reply-to: Your message of "Wed, 24 Jul 2002 20:29:12 +0530." <00d701c23322$acb59080$feca64c0@cyborg> Date: Wed, 24 Jul 2002 11:02:34 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > can any body tell me if Penultimate hop popping is supported in > rsvp-te Yes. The receiver simply puts the implicit null label in the label object of the resv message. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jul 24 11:11:25 2002 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 ESMTP id LAA20802 for ; Wed, 24 Jul 2002 11:11:24 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxg24326 for ; Wed, 24 Jul 2002 15:12:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxg22241; Wed, 24 Jul 2002 15:11:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxg21335 for mpls-outgoing; Wed, 24 Jul 2002 15:10:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyxg21280 for ; Wed, 24 Jul 2002 15:10: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 QQmyxg05188 for ; Wed, 24 Jul 2002 15:09:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxg28733 for ; Wed, 24 Jul 2002 15:09:13 GMT Received: from alpha2.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.125.55.125]) id QQmyxg28711 for ; Wed, 24 Jul 2002 15:09:12 GMT Received: from mail3.tellium.com (mail3.tellium.com) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Jul 2002 11:07:41 -0400 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id <3819AXDK>; Wed, 24 Jul 2002 11:05:33 -0400 Message-ID: <05707214338CD5119BFF0040A5B170D3E822ED@mail3.tellium.com> From: Bala Rajagopalan To: "'Soumen Sarkar'" , Bala Rajagopalan Cc: Loa Andersson , mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Wed, 24 Jul 2002 11:05:24 -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 The problem (at least the way I see it) is that both protocols satisfy the requirements and neither OIF nor ITU-T has tried to pick one (and only one) protocol. In effect, these organizations (IMO) have taken the path of least resistance, not getting into the messy issue of selecting "a" protocol. And since the work is usually done by different groups of people, this choice of allowing everything is easy, regardless of what gets finally implemented. Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Soumen Sarkar [mailto:soumen@sasken.com] > Sent: Wednesday, July 24, 2002 1:29 AM > To: Bala Rajagopalan > Cc: Loa Andersson; mpls@UU.NET > Subject: Re: initiating a discussion on mpls singaling protocols > > > So, In effect you are saying that since OIF and ITU-T are not > able to decide > which one to pick (based on their requirements), it is > benefecial for them > that IETF decide which one they want to promote and others > will follow! I > thought ITU-T and OIF work independently and they have their > own parameters > to choose the technological alternative. > > Bala Rajagopalan wrote: > > > In response to the comment on OIF tracking CR-LDP: > > > > Life would be simplified for OIF and ITU-T if > > there were only a single standard signaling protocol. > > But because there are two IETF protocols, the rest of the > > world has to track the two (in addition to other > > non-IETF protocols). > > > > Bala Rajagopalan > > Tellium, Inc. > > 2 Crescent Place > > P.O. Box 901 > > Oceanport, NJ 07757-0901 > > Tel: (732) 923-4237 > > Fax: (732) 923-9804 > > Email: braja@tellium.com > > > > > -----Original Message----- > > > From: Soumen Sarkar [mailto:soumen@sasken.com] > > > Sent: Tuesday, July 23, 2002 3:27 AM > > > To: Loa Andersson; mpls@UU.NET > > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > > > > > > Loa, > > > The response so far heavily indicated for RSVP-TE ( obviously > > > not because of the > > > merits of RSVP-TE over LDP-CR ). If one has to accept the > > > basic ground-rule, which is, > > > how many major players are pushing for RSVP-TE, one would > > > blindly vote for RSVP-TE. > > > The more esoteric view, which is, single signaling > > > protocol would help > > > everyone to concentrate better in addressing unresolved > > > problems in MPLS, is also > > > appreciably reasonable to accept. > > > But looking from holistic perspective, is it not too > > > premature at this time to > > > conclude on this issue unilaterally (even if there is 3/4 > > > majority in favour if it ) > > > when this particular issue affects other standard bodies too > > > ? We know for sure, OIF > > > is still tracking LDP-CR as an alternative signaling protocol > > > for optical control > > > plane. Are we not pushing something without even considering > > > future implication of it > > > ? One might say, we are not stopping anyone to use LDP-CR as > > > such. But none would > > > disagree that making IETF take a stand itself is deterrant > > > enough and if not that > > > much, it is bound to create conflict of interest between IETF > > > and others. > > > Are we really ready for this ? IETF traditionally has been > > > more a forum for vouching > > > technical solutions, not imposing it. Are we deviating from > > > that path with full > > > understanding ? > > > -best regards, > > > Soumen > > > > > > Loa Andersson wrote: > > > > > > > Heinrich, > > > > > > > > in my opinion the question is very clearly stated - is > > > there support for > > > > us (the ietf) to move the cr-ldp from standard track to > > > informational. > > > > We're "speaking for the ietf", it is more a matter of > what we say ;) > > > > > > > > All, > > > > > > > > As usual we are trying to reach a rough consensus. Everyone > > > (i.e. the > > > > mpls wg) can help create this consensus by answering > the question > > > > above. > > > > > > > > Especially it will be helpful if you were involved in > specifying the > > > > mpls protocols, have implemented or deployed (SP) those > > > protocols, and > > > > take the time to respond. > > > > > > > > I will be ready to give the first extensive tally mid this week. > > > > Currently the count is > > > > yes: 30 no: 7, > > > > if you normalize those e.g. by counting each company once it is > > > > yes: 21 no: 4 > > > > > > > > Disclaimer: Given that I've managed to decipher the > > > sometimes cryptic > > > > mails correctly :o) > > > > > > > > /Loa > > > > > > > > Hummel Heinrich wrote: > > > > > > > > > I think, the IETF can only speak for itself. There may > > > be other standardization > > > > > > > > >bodies (ITU-T, MPLS Forum) which may fill > > > > > the gap. > > > > > > > > > > Heinrich Hummel > > > > > Siemens AG > > > > > > > > > > > > > -- > > > > 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 Jul 24 11:14:20 2002 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 ESMTP id LAA20927 for ; Wed, 24 Jul 2002 11:14:20 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywm10873 for ; Wed, 24 Jul 2002 10:02:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmywm09787; Wed, 24 Jul 2002 10:01:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmywm20716 for mpls-outgoing; Wed, 24 Jul 2002 10:01:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmywm20235 for ; Wed, 24 Jul 2002 10:01:12 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 QQmywm19448 for ; Wed, 24 Jul 2002 10:01:00 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmywm09124 for ; Wed, 24 Jul 2002 10:01:00 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 QQmywm09117 for ; Wed, 24 Jul 2002 10:00:57 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g6OA0bC07006; Wed, 24 Jul 2002 15:30:39 +0530 (IST) Received: from sasken.com (pcz-soumen.sasken.com [10.1.64.68]) by sunsv2.sasken.com (8.11.6/8.11.6) with ESMTP id g6OA0YP21925; Wed, 24 Jul 2002 15:30:34 +0530 (IST) Message-ID: <3D3E7B9F.7F5258E8@sasken.com> Date: Wed, 24 Jul 2002 15:34:16 +0530 From: Soumen Sarkar X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Loa Andersson CC: "Ong, Lyndon" , "'mborden@acm.org'" , egray@celoxnetworks.com, "'avri'" , mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <2135200C183FD5119588009027DE5723FD3228@wntcsdexg02.csd.ciena.com> <3D3D8F88.4050105@utfors.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Loa, Thanks for summarizing. I would support the 2nd approach on the ground that Avri has nicely has put forth. 2ndly, this approach is very much aligned to IETF's way of working. -best regards, Soumen Loa Andersson wrote: > All, > > (off list for clarification) > it seems like you are agreeing based on two very different approaches. > > 1. don't do anyhting about the doc status to cr-ldp, but stop all > work on it (Lyndon) > 2. don't do anything to doc status, but require (encoruage) that id > authors work only on one singalling protocol at a time (Eric). > > 1 is very close to what was proposed at the mpls wg meeting, 2 is > actually a decission to continue develop cr-ldp. > > /Loa > > Ong, Lyndon wrote: > > > This might be actually a reasonable solution, to "cap" the > > work on CR-LDP. I'd have the same concern as Avri with > > taking an approved standard and "de-standardizing" it, > > although it would help to know if this has been done > > before. > > > > Cheers, > > > > Lyndon Ong > > Ciena > > > > -----Original Message----- > > From: Marty Borden [mailto:m.borden@verizon.net] > > Sent: Tuesday, July 23, 2002 9:38 AM > > To: egray@celoxnetworks.com; 'avri' > > Cc: mpls@UU.NET > > Subject: RE: initiating a discussion on mpls singaling protocols > > > > > > Eric, > > Well that would be good if it were acceptable for a draft > > to not have to cover both approaches. Is that really acceptable? > > marty > > > > > > On 7/23/2002 at 12:09 PM Gray, Eric wrote: > > > > |Avri makes a very good point here. > > | > > |I think the implementation survey makes it obvious that > > |we should progress RSVP-TE (and related work) to Draft > > |Standard. It seems equally clear that we should not do > > |so for CR-LDP at this point. > > | > > |Letting CR-LDP die on the vine certainly seems in keeping > > |with what the IETF has done in the past. > > | > > |Eric W. Gray > > |Systems Architect > > |Celox Networks, Inc. > > |egray@celoxnetworks.com > > |508 305 7214 > > | > > | > > |-----Original Message----- > > |From: avri [mailto:avri@sm.luth.se] > > |Sent: Tuesday, July 23, 2002 9:26 AM > > |Cc: MPLS wg > > |Subject: Re: initiating a discussion on mpls singaling protocols > > | > > | > > | > > |This seems to me a very strange proposal. And in fact seems to be > > |a perversion of the IETF standards process as i understand it. > > | > > |If things are as argued, then RSVP-TE will progress to draft standard > > |and then to standard, while CR-LDP remains a proposed standard. If > > |it languishes long enough in the proposed state, without significant > > |deployment or utility, then it would seem appropriate to transition it > > |to historic at some point in the future. > > | > > |Taking it to informational at this point seems a fairly blatant political > > |move without technical merit. At best it is an administrative sleight > > |of hand that could strange repercussions as a precedent. Is the IETF > > |going to embark next on an effort to define all protocol duplication > > |out of existence by voting on which alternative to make informational? > > | > > |I would suggest (as voting is not something I thought the IETF did) that > > |both protocols remain as ps. If CR-LDP withers on the vine because it has > > |no utility, so be it. Voting to change its status seems inappropriate to > > |me. > > | > > |a. > > > > > > > > > > -- > 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 Jul 24 11:16:53 2002 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 ESMTP id LAA20985 for ; Wed, 24 Jul 2002 11:16:52 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxh08604 for ; Wed, 24 Jul 2002 15:17:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxg27828; Wed, 24 Jul 2002 15:13:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxg21970 for mpls-outgoing; Wed, 24 Jul 2002 15:12:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyxg21898 for ; Wed, 24 Jul 2002 15:12:32 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 QQmyxg04361 for ; Wed, 24 Jul 2002 15:12:15 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxg06215 for ; Wed, 24 Jul 2002 15:12:15 GMT Received: from smtp1.opnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.opnet.com [141.156.71.6]) id QQmyxg06211 for ; Wed, 24 Jul 2002 15:12:15 GMT Received: from wtn10216.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Wed, 24 Jul 2002 11:11:29 -0400 Message-Id: <5.0.0.25.2.20020724111023.02de7ba0@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 24 Jul 2002 11:13:24 -0400 To: , "Mpls \(E-mail\)" From: Sachin Kalra Subject: Re: Penultimate hop popping in rsvp In-Reply-To: <00d701c23322$acb59080$feca64c0@cyborg> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_81009886==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_81009886==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Yes, it is supported. The egress LER does not assign any label (Actually assigns a NULL) while RESV is coming back. -SK At 08:29 PM 7/24/02 +0530, Mayank Kumar wrote: >hi >can any body tell me if Penultimate hop popping is supported in rsvp-te > >thanks and regards >Mayank --=====================_81009886==_.ALT Content-Type: text/html; charset="us-ascii" Yes, it is supported. The egress LER does not assign any label (Actually assigns a NULL) while RESV is coming back.

-SK

At 08:29 PM 7/24/02 +0530, Mayank Kumar wrote:
hi
can any body tell me if Penultimate hop popping is supported in rsvp-te

thanks and regards
Mayank
--=====================_81009886==_.ALT-- From owner-mpls@UU.NET Wed Jul 24 13:08:11 2002 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 ESMTP id NAA24546 for ; Wed, 24 Jul 2002 13:08:11 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvy17144 for ; Wed, 24 Jul 2002 06:43:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyvy15166; Wed, 24 Jul 2002 06:41:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyvy24408 for mpls-outgoing; Wed, 24 Jul 2002 06:41:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyvy24403 for ; Wed, 24 Jul 2002 06:41: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 QQmyvy06114 for ; Wed, 24 Jul 2002 06:41:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvy14897 for ; Wed, 24 Jul 2002 06:41:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyvy14893 for ; Wed, 24 Jul 2002 06:41:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA12418 for ; Wed, 24 Jul 2002 02:41:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA10518 for mpls@uu.net; Wed, 24 Jul 2002 02:41:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyvy24210 for ; Wed, 24 Jul 2002 06:39: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 QQmyvy10914 for ; Wed, 24 Jul 2002 06:38:46 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyvy14041 for ; Wed, 24 Jul 2002 06:38:45 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sword.cisco.com [161.44.208.100]) id QQmyvy14031 for ; Wed, 24 Jul 2002 06:38:45 GMT Received: from ZALI-W2K.cisco.com (che-vpn2-51.cisco.com [10.86.244.51]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id CAA22986; Wed, 24 Jul 2002 02:38:20 -0400 (EDT) Message-Id: <4.3.2.7.2.20020724021806.020b8948@sword.cisco.com> X-Sender: zali@sword.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jul 2002 02:38:18 -0400 To: Soumen Sarkar , Bala Rajagopalan From: Zafar Ali Subject: Re: initiating a discussion on mpls singaling protocols Cc: Loa Andersson , mpls@UU.NET In-Reply-To: <3D3E3B33.14B283A7@sasken.com> References: <05707214338CD5119BFF0040A5B170D3E822E2@mail3.tellium.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_37278493==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_37278493==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable At 10:59 AM 7/24/2002 +0530, Soumen Sarkar wrote: >So, In effect you are saying that since OIF and ITU-T are not able to= decide >which one to pick (based on their requirements), it is benefecial for them >that IETF decide which one they want to promote and others will follow! Hi Soumen, This would be a very unfair reading of Bala's email. You should read it in= =20 the context that some folks argued that since OIF uses CR-LDP, IETF should= =20 not proceed on this notion. There is no argument that both IETF, OIF and ITU-T are independent bodies.= =20 However, it should not surprise anyone that implementation survey for=20 CR-LDP vs. RSVP-TE for OIF UNI would follow the same sample point. So, yes,= =20 OIF can independently make the same decision; not because of the IETF=20 influence but using the same rule of wisdom. But this should be separate=20 discussion at the right mailing alias/ with the right authorities. Thanks Regards... Zafar >I >thought ITU-T and OIF work independently and they have their own parameters >to choose the technological alternative. > >Bala Rajagopalan wrote: > > > In response to the comment on OIF tracking CR-LDP: > > > > Life would be simplified for OIF and ITU-T if > > there were only a single standard signaling protocol. > > But because there are two IETF protocols, the rest of the > > world has to track the two (in addition to other > > non-IETF protocols). > > > > Bala Rajagopalan > > Tellium, Inc. > > 2 Crescent Place > > P.O. Box 901 > > Oceanport, NJ 07757-0901 > > Tel: (732) 923-4237 > > Fax: (732) 923-9804 > > Email: braja@tellium.com > > > > > -----Original Message----- > > > From: Soumen Sarkar [mailto:soumen@sasken.com] > > > Sent: Tuesday, July 23, 2002 3:27 AM > > > To: Loa Andersson; mpls@UU.NET > > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > > > > > > Loa, > > > The response so far heavily indicated for RSVP-TE ( obviously > > > not because of the > > > merits of RSVP-TE over LDP-CR ). If one has to accept the > > > basic ground-rule, which is, > > > how many major players are pushing for RSVP-TE, one would > > > blindly vote for RSVP-TE. > > > The more esoteric view, which is, single signaling > > > protocol would help > > > everyone to concentrate better in addressing unresolved > > > problems in MPLS, is also > > > appreciably reasonable to accept. > > > But looking from holistic perspective, is it not too > > > premature at this time to > > > conclude on this issue unilaterally (even if there is 3/4 > > > majority in favour if it ) > > > when this particular issue affects other standard bodies too > > > ? We know for sure, OIF > > > is still tracking LDP-CR as an alternative signaling protocol > > > for optical control > > > plane. Are we not pushing something without even considering > > > future implication of it > > > ? One might say, we are not stopping anyone to use LDP-CR as > > > such. But none would > > > disagree that making IETF take a stand itself is deterrant > > > enough and if not that > > > much, it is bound to create conflict of interest between IETF > > > and others. > > > Are we really ready for this ? IETF traditionally has been > > > more a forum for vouching > > > technical solutions, not imposing it. Are we deviating from > > > that path with full > > > understanding ? > > > -best regards, > > > Soumen > > > > > > Loa Andersson wrote: > > > > > > > Heinrich, > > > > > > > > in my opinion the question is very clearly stated - is > > > there support for > > > > us (the ietf) to move the cr-ldp from standard track to > > > informational. > > > > We're "speaking for the ietf", it is more a matter of what we say ;) > > > > > > > > All, > > > > > > > > As usual we are trying to reach a rough consensus. Everyone > > > (i.e. the > > > > mpls wg) can help create this consensus by answering the question > > > > above. > > > > > > > > Especially it will be helpful if you were involved in specifying the > > > > mpls protocols, have implemented or deployed (SP) those > > > protocols, and > > > > take the time to respond. > > > > > > > > I will be ready to give the first extensive tally mid this week. > > > > Currently the count is > > > > yes: 30 no: 7, > > > > if you normalize those e.g. by counting each company once it is > > > > yes: 21 no: 4 > > > > > > > > Disclaimer: Given that I've managed to decipher the > > > sometimes cryptic > > > > mails correctly :o) > > > > > > > > /Loa > > > > > > > > Hummel Heinrich wrote: > > > > > > > > > I think, the IETF can only speak for itself. There may > > > be other standardization > > > > > > > > >bodies (ITU-T, MPLS Forum) which may fill > > > > > the gap. > > > > > > > > > > Heinrich Hummel > > > > > Siemens AG > > > > > > > > > > > > > -- > > > > 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 > > > --=====================_37278493==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 10:59 AM 7/24/2002 +0530, Soumen Sarkar wrote:
So, In effect you are saying that since OIF and ITU-T are not able to decide
which one to pick (based on their requirements), it is benefecial for them
that IETF decide which one they want to promote and others will follow!

Hi Soumen,

This would be a very unfair reading of Bala's email. You should read it in the context that some folks argued that since OIF uses CR-LDP, IETF should not proceed on this notion.

There is no argument that both  IETF, OIF and ITU-T are independent bodies. However, it should not surprise anyone that implementation survey for CR-LDP vs. RSVP-TE for OIF UNI would follow the same sample point. So, yes, OIF can independently make the same decision; not because of the IETF influence but using the same rule of wisdom. But this should be separate discussion at the right mailing alias/ with the right authorities.

Thanks

Regards... Zafar

I
thought ITU-T and OIF work independently and they have their own parameters
to choose the technological alternative.

Bala Rajagopalan wrote:

> In response to the comment on OIF tracking CR-LDP:
>
> Life would be simplified for OIF and ITU-T if
> there were only a single standard signaling protocol.
> But because there are two IETF protocols, the rest of the
> world has to track the two (in addition to other
> non-IETF protocols).
>
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: braja@tellium.com
>
> > -----Original Message-----
> > From: Soumen Sarkar [mailto:soumen@sasken.com]
> > Sent: Tuesday, July 23, 2002 3:27 AM
> > To: Loa Andersson; mpls@UU.NET
> > Subject: Re: initiating a discussion on mpls singaling protocols
> >
> >
> > Loa,
> > The response so far heavily indicated for RSVP-TE ( obviously
> > not because of the
> > merits of RSVP-TE over LDP-CR ). If one has to accept the
> > basic ground-rule, which is,
> > how many major players are pushing for RSVP-TE, one would
> > blindly vote for RSVP-TE.
> >         The more esoteric view, which is, single signaling
> > protocol would help
> > everyone to concentrate better in addressing unresolved
> > problems in MPLS, is also
> > appreciably reasonable to accept.
> > But looking from holistic perspective, is it not too
> > premature at this time to
> > conclude on this issue unilaterally (even if there is 3/4
> > majority in favour if it )
> > when this particular issue affects other standard bodies too
> > ? We know for sure, OIF
> > is still tracking LDP-CR as an alternative signaling protocol
> > for optical control
> > plane. Are we not pushing something without even considering
> > future implication of it
> > ? One might say, we are not stopping anyone to use LDP-CR as
> > such. But none would
> > disagree that making IETF take a stand itself is=20 deterrant
> > enough and if not that
> > much, it is bound to create conflict of interest between IETF
> > and others.
> >   Are we really ready for this ? IETF traditionally has been
> > more a forum for vouching
> > technical solutions, not imposing it. Are we deviating from
> > that path with full
> > understanding ?
> > -best regards,
> > Soumen
> >
> > Loa Andersson wrote:
> >
> > > Heinrich,
> > >
> > > in my opinion the question is very clearly stated - is
> > there support for
> > > us (the ietf) to move the cr-ldp from standard track to
> > informational.
> > > We're "speaking for the ietf", it is more a matter of what we say ;)
> > >
> > > All,
> > >
> > > As usual we are trying to reach a rough consensus. Everyone
> > (i.e. the
> > > mpls wg) can help create this consensus by answering the question
> > > above.
> > >
> > > Especially it will be helpful if you were involved in specifying the
> > > mpls protocols, have implemented or deployed (SP) those
> > protocols, and
> > > take the time to respond.
> > >
> > > I will be ready to give the first extensive tally mid this week.
> > > Currently the count is
> > > yes: 30 no: 7,
> > > if you normalize those e.g. by counting each company once it is
> > > yes: 21 no: 4
> > >
> > > Disclaimer: Given that I've managed to decipher the
> > sometimes cryptic
> > > mails correctly :o)
> > >
> > > /Loa
> > >
> > > Hummel Heinrich wrote:
> > >
> > > >  I think, the IETF can only speak for itself. There may
> > be other standardization
> > >
> > > >bodies (ITU-T, MPLS Forum) which may fill
> > > > the gap.
> > > >
> > > > Heinrich Hummel
> > > > Siemens AG
> > > >
> > >
> > > --
> > >      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
> >
--=====================_37278493==_.ALT-- From owner-mpls@UU.NET Wed Jul 24 13:13:00 2002 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 ESMTP id NAA24653 for ; Wed, 24 Jul 2002 13:13:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxo04187 for ; Wed, 24 Jul 2002 17:13:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxo02620; Wed, 24 Jul 2002 17:13:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxo16358 for mpls-outgoing; Wed, 24 Jul 2002 17:12:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyxo16353 for ; Wed, 24 Jul 2002 17:12: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 QQmyxo00056 for ; Wed, 24 Jul 2002 17:12:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxo01993 for ; Wed, 24 Jul 2002 17:12:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyxo01985 for ; Wed, 24 Jul 2002 17:12:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA13659 for ; Wed, 24 Jul 2002 13:12:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA20310 for mpls@uu.net; Wed, 24 Jul 2002 13:12:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyxo16189 for ; Wed, 24 Jul 2002 17:11: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 QQmyxo06953 for ; Wed, 24 Jul 2002 17:11:02 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxo01587 for ; Wed, 24 Jul 2002 17:11:01 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 QQmyxo01580 for ; Wed, 24 Jul 2002 17:11:01 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OHBPmc022036; Wed, 24 Jul 2002 13:11:29 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (dhcp-161-44-145-7.cisco.com [161.44.145.7]) by bucket.cisco.com (Mirapoint) with ESMTP id ABI42737; Wed, 24 Jul 2002 13:10:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20020724130908.05a6cc10@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jul 2002 13:10:49 -0400 To: mike@nbase.co.il (Michael Rozhavsky) From: "Thomas D. Nadeau" Subject: Re: mpls menagement overview Cc: mpls@UU.NET In-Reply-To: <20020722120304.GA31386@nbase.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, That is correct. We will fix this in the next revision. --Tom >I think there is a mistake in draft-ietf-mpls-mgmt-overview-02.txt. > >In section 5.4 of management overview it is stated that entries in >mplsLabelStackTable table of LSR MIB are referenced to from >mplsOutSegmentTable table, but in reality they are referenced to from >mplsXCTable. > > >-- >Best regards. > > Michael Rozhavsky Tel: +972-4-9936248 > mrozhavsky@opticalaccess.com Fax: +972-4-9890564 > Optical Access > Senior Software Engineer www.opticalaccess.com ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Wed Jul 24 13:22:15 2002 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 ESMTP id NAA24989 for ; Wed, 24 Jul 2002 13:22:15 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxp29699 for ; Wed, 24 Jul 2002 17:23:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxp27827; Wed, 24 Jul 2002 17:22:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxp17398 for mpls-outgoing; Wed, 24 Jul 2002 17:21:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyxp17393 for ; Wed, 24 Jul 2002 17:21: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 QQmyxp17029 for ; Wed, 24 Jul 2002 17:21:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxp13546 for ; Wed, 24 Jul 2002 17:21:07 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyxp13527 for ; Wed, 24 Jul 2002 17:21:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14426 for ; Wed, 24 Jul 2002 13:21:06 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA22126 for mpls@uu.net; Wed, 24 Jul 2002 13:21:06 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyxp17349 for ; Wed, 24 Jul 2002 17:20:00 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 QQmyxp06485 for ; Wed, 24 Jul 2002 17:19:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxp12650 for ; Wed, 24 Jul 2002 17:19:53 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 QQmyxp12641 for ; Wed, 24 Jul 2002 17:19:52 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OHKOTx023032; Wed, 24 Jul 2002 13:20:24 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (dhcp-161-44-145-7.cisco.com [161.44.145.7]) by bucket.cisco.com (Mirapoint) with ESMTP id ABI42916; Wed, 24 Jul 2002 13:19:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20020724131144.05a901f0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jul 2002 13:19:42 -0400 To: "Szymanski, Pawel" From: "Thomas D. Nadeau" Subject: Re: mplsIngressLsrId in MPLS TE MIB Cc: "'mpls@uu.net'" In-Reply-To: <413FBB0BA5AED1119122000083234B1A01FB4A85@alpha.igk.intel.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dzien dobry Pawel, >I have two questions concerning mplsIngressLsrId in MPLS TE MIB: > >1) The mplsTunnelTable vriable is defined as MplsLsrIdentifier. >This type is defined in MPLS TC MIB as 4-octets string. >Description for the variable says that for RSVP-TE it should mimic Extended >Tunnel ID field. >However if RSVP-TE for IPv6 is used, the field is 16-bytes long. >It seems to me that the MplsLsrIdentifier definition shall be extended. We are addressing this during the MPLS MIB's MIB Doctor review. >2) Is it permissible to set mplsIngressLsrId variable on the ingress router >to value other than local LSR ID or 0 ? The values taken by this object should reflect the Extended Tunnel Id field in the RSVP-TE Session object. Dziekuja, --Tom >Thanks in advance, > >Pawel Szymanski >Software Engineer at Intel Technology Poland >mailto:pawel.szymanski@intel.com ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Wed Jul 24 13:27:03 2002 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 ESMTP id NAA25075 for ; Wed, 24 Jul 2002 13:27:02 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxp20655 for ; Wed, 24 Jul 2002 17:27:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxp18780; Wed, 24 Jul 2002 17:26:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxp17809 for mpls-outgoing; Wed, 24 Jul 2002 17:26:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyxp17785 for ; Wed, 24 Jul 2002 17:26:15 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 QQmyxp15552 for ; Wed, 24 Jul 2002 17:26:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxp18002 for ; Wed, 24 Jul 2002 17:26:11 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyxp17972 for ; Wed, 24 Jul 2002 17:26:08 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14832 for ; Wed, 24 Jul 2002 13:26:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA22970 for mpls@uu.net; Wed, 24 Jul 2002 13:26:07 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyxp17587 for ; Wed, 24 Jul 2002 17:24: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 QQmyxp20379 for ; Wed, 24 Jul 2002 17:24:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxp16835 for ; Wed, 24 Jul 2002 17:24:17 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 QQmyxp16826 for ; Wed, 24 Jul 2002 17:24:17 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OHOfoO023523; Wed, 24 Jul 2002 13:24:42 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (dhcp-161-44-145-7.cisco.com [161.44.145.7]) by bucket.cisco.com (Mirapoint) with ESMTP id ABI43020; Wed, 24 Jul 2002 13:24:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20020724132035.05a67a30@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jul 2002 13:24:06 -0400 To: "Fang Hao" From: "Thomas D. Nadeau" Subject: RE: Question on MIB info for LSP tunneling Cc: "Adrian Farrel" , In-Reply-To: References: <002001c22f51$3b74c500$681810ac@movaz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Thanks for your reply. But I am still missing something - >the tunnel creation part is fine, but when I need to >access information about L2 (the LSP tunnel), I have a problem. >What I would need is: given LSP L1 (i.e., knowing its >mplsTunnelIndex), I need to find out which tunnel it is >going through, how much bandwidth is left on this tunnel L2, >what is the ingress/egress LSR id, etc. For those info >I would probably need the mplsTunnelIndex for L2. What you are asking is for a reverse mapping from XCEntry->TunnelEntry. This is not available directly. What you would have to do is traverse your tunnel heads (we recommend that the tunnelInstance = 0 for these for ease of look up). Then for this set check the tunnelXCpointer. >If I am not misunderstanding the MIBs, this mplsTunnelIndex >(of L2) does not appear in either interface table or >out segment table. - any comments? The tunnel's ifIndex (if implemented as an interface) is specified in the tunnelEntry. The tunnel's ifIndex can (and must) appear in the ifEntry if the tunnel is implemented as a ifIndex. TunnelEntries were not indexed by ifIndex because some implementations did not want to implement them that way, which would have made the indexing useless for them. --Tom >Thanks, >Fang > >-----Original Message----- >From: Adrian Farrel [mailto:afarrel@movaz.com] >Sent: Friday, July 19, 2002 2:22 PM >To: Fang Hao >Subject: Re: Question on MIB info for LSP tunneling > > >Fang, > >A common approach top this is to install the tunnel as an interface so it >shows >in the interfaces MIB. The interface would also show in the TE MIB for the >tunnel. > >The tunneled LSP can then be routed down the tunnel (i.e. out of the virtual >interface). This would show up in the LSR MIB out segment. > >Cheers, >Adrian >----- Original Message ----- >From: "Fang Hao" >To: >Sent: Friday, July 19, 2002 12:07 PM >Subject: Question on MIB info for LSP tunneling > > > > Hi- > > > > My question is the following: > > Suppose LSP L1 uses LSP L2 as a tunnel for some intermediate > > hop between LSR Ru and Rd, is the correlation between L1 and > > L2 stored somewhere in one of MIBs (MPLS-TE, MPLS-LSR, etc.) > > of Ru? In other words, if I know the mplsTunnelIndex of L1, can I > > somehow get to know the mplsTunnelIndex of L2? > > > > Could someone shed some light on this? Thanks. > > > > Fang ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Wed Jul 24 13:57:17 2002 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 ESMTP id NAA25840 for ; Wed, 24 Jul 2002 13:57:17 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxr00576 for ; Wed, 24 Jul 2002 17:58:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxr28597; Wed, 24 Jul 2002 17:57:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxr20066 for mpls-outgoing; Wed, 24 Jul 2002 17:56:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyxr20059 for ; Wed, 24 Jul 2002 17:56:23 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 QQmyxr00555 for ; Wed, 24 Jul 2002 17:55:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxr27379 for ; Wed, 24 Jul 2002 17:55:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyxr27370 for ; Wed, 24 Jul 2002 17:55:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA17253 for ; Wed, 24 Jul 2002 13:55:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA27586 for mpls@uu.net; Wed, 24 Jul 2002 13:55:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyxr19979 for ; Wed, 24 Jul 2002 17:54:10 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 QQmyxr01702 for ; Wed, 24 Jul 2002 17:53:24 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxr08260 for ; Wed, 24 Jul 2002 17:53:23 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 QQmyxr08249 for ; Wed, 24 Jul 2002 17:53:23 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OHrqdG026961; Wed, 24 Jul 2002 13:53:53 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (dhcp-161-44-145-7.cisco.com [161.44.145.7]) by bucket.cisco.com (Mirapoint) with ESMTP id ABI43706; Wed, 24 Jul 2002 13:53:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20020724135124.05a66ca8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jul 2002 13:53:17 -0400 To: "Fang Hao" From: "Thomas D. Nadeau" Subject: RE: Question on MIB info for LSP tunneling Cc: "Adrian Farrel" , "'mpls@uu.net'" In-Reply-To: References: <005501c2310b$8ea9f720$9b13588a@movaz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Here is what I am still missing - > From L1, I may get mplsOutSegmentIfIndex(L1), which is the interface index >of L2, as you suggested. Let's call this index i2. Now the problem >is how to get the L2 entry in mplsTunnelTable in TE MIB, by using i2. >Look up the interface table does not help since this table only contains >the LSP name of L2, but not the mplsTunnelIndex. It seems to me that >unless we scan the entire mplsTunnelTable and compare each mplsTunnelIfIndex >with i2, there is no way to "directly" access the entry of L2 - this >is what I was trying to avoid. I think that if you follow the convention that the heads use tunnelInstance = 0, that you can prune your search down quite a bit. If the tunnelTable is implemented correctly, your searches should be fairly quick. >I hope this is not true. Otherwise it seems to be an unfortunate >consequence of the current MIB structure. Unfortunately, putting in a back pointer for every application that uses the TFIB would have been quite complicated for implementations. --Tom >Thanks, >Fang > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adrian >Farrel >Sent: Sunday, July 21, 2002 11:38 AM >To: Fang Hao >Cc: 'mpls@uu.net' >Subject: Re: Question on MIB info for LSP tunneling > > >Hi Fang, > >L1 is tunneled through L2. > >L2 is installed in the TE MIB with an ifindex using mplsTunnelIsIf and >mplsTunnelIfIndex. This means that it can be found within the >implementation as >an interface and available bandwidth can be examined just as though it was a >physical interface. > >L1 shows in the LSR MIB with an outsegment that contains >mplsOutSegmentIfIndex. >This is the outgoing interface for L1 and is not the physical interface - it >is >the interface index of L2. > >So, from L1 you can get to L2. > >Adrian > >----- Original Message ----- >From: "Fang Hao" >To: "Adrian Farrel" >Cc: >Sent: Friday, July 19, 2002 2:44 PM >Subject: RE: Question on MIB info for LSP tunneling > > > > Adrian, > > > > Thanks for your reply. But I am still missing something - > > the tunnel creation part is fine, but when I need to > > access information about L2 (the LSP tunnel), I have a problem. > > What I would need is: given LSP L1 (i.e., knowing its > > mplsTunnelIndex), I need to find out which tunnel it is > > going through, how much bandwidth is left on this tunnel L2, > > what is the ingress/egress LSR id, etc. For those info > > I would probably need the mplsTunnelIndex for L2. > > > > If I am not misunderstanding the MIBs, this mplsTunnelIndex > > (of L2) does not appear in either interface table or > > out segment table. - any comments? > > > > Thanks, > > Fang ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Wed Jul 24 14:02:29 2002 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 ESMTP id OAA25964 for ; Wed, 24 Jul 2002 14:02:29 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxs15649 for ; Wed, 24 Jul 2002 18:03:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxs13409; Wed, 24 Jul 2002 18:02:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxs24691 for mpls-outgoing; Wed, 24 Jul 2002 18:02:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmyxs24350 for ; Wed, 24 Jul 2002 18:01: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 QQmyxs12034 for ; Wed, 24 Jul 2002 18:00:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxs11709 for ; Wed, 24 Jul 2002 18:00:10 GMT Received: from c2.ciena.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQmyxs11700 for ; Wed, 24 Jul 2002 18:00:09 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id OAA14829; Wed, 24 Jul 2002 14:00:09 -0400 (EDT) Received: from wntcsdexg02.csd.ciena.com(10.128.2.168) by c2.ciena.com via smap (V2.0) id xma014671; Wed, 24 Jul 02 13:59:46 -0400 Received: by wntcsdexg02.csd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 10:59:46 -0700 Message-ID: <2135200C183FD5119588009027DE5723FD3239@wntcsdexg02.csd.ciena.com> From: "Ong, Lyndon" To: "'David Charlap'" , IETF MPLS List Subject: RE: initiating a discussion on mpls singaling protocols Date: Wed, 24 Jul 2002 10:59:36 -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 David, Actually, SCTP is an alternative that supports message passing and boundary preservation, plus other features for reliability and detection of signaling path failure. It was intended to relieve the application from having to do continual verification of the signaling path and support of a backup path. However, it was being defined at about the same time as MPLS, so it was never considered as an alternative for transport of MPLS signaling. A reliable UDP was one of the alternatives considered when doing SCTP, but it still leaves the application to do testing of the signaling path and message rerouting if that fails, and does not have congestion control built in. Cheers, Lyndon -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Wednesday, July 24, 2002 7:45 AM To: IETF MPLS List Subject: Re: initiating a discussion on mpls singaling protocols As for the rest, TCP is not an appropriate transport for signaling protocols in the first place. RSVP-TE, LDP and CR-LDP all use a message-passing mechanism. They are not designed around streaming data. Use of a streaming protocol means that the protocol has to deal with the issue of detecting message boundaries and half-received messages. Unfortunately, there is no standard for anything resembling reliable UDP - that would be ideal. From owner-mpls@UU.NET Wed Jul 24 14:22:57 2002 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 ESMTP id OAA26504 for ; Wed, 24 Jul 2002 14:22:56 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxt03201 for ; Wed, 24 Jul 2002 18:23:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxt01476; Wed, 24 Jul 2002 18:23:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxt14614 for mpls-outgoing; Wed, 24 Jul 2002 18:22:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyxt14607 for ; Wed, 24 Jul 2002 18:22:34 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 QQmyxt05186 for ; Wed, 24 Jul 2002 18:22:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxt06159 for ; Wed, 24 Jul 2002 18:22:07 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQmyxt06153 for ; Wed, 24 Jul 2002 18:22:06 GMT Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6OIM5220880 for ; Wed, 24 Jul 2002 14:22:05 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 14:22:05 -0400 Message-ID: From: "Jothilingam, Vasudevan (Vasu)" To: IETF MPLS List Subject: RE: initiating a discussion on mpls singaling protocols Date: Wed, 24 Jul 2002 14:22:03 -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 Going back to the question of making CR-LDP informational RFC. First, I stronlgy support the thought that ,the Industry should evolve to One Signaling protocol. At this economy it is costly to develop two competing protocols. Also, extending the protcols to do other applicatons will also double the work load on research and implementation. Having multiple protocols to do single Application will lead us into the same problem of OSPF or ISIS. Now that we are in that trap, that every extension we do, we need to do both IGPs. I would like to say, yeah RSVP-TE is the way adn CR-LDP could be informational RFC. Being said that, there is lots of work going of L2 Transportation over MPLS, using LDP. Well, even though I am not for that approach of using RSVP-TE and LDP ( two big protocols ??) for L2 transport, we need to see where that goes.. Thanks Vasu Vasu Jothilingam Lucent Technologies 1 Robbins Rd Westford, MA-01886 PH: (978)-952-7533 FAX: (978)-952-7977 -----Original Message----- From: Ong, Lyndon [mailto:LyOng@ciena.com] Sent: Wednesday, July 24, 2002 2:00 PM To: 'David Charlap'; IETF MPLS List Subject: RE: initiating a discussion on mpls singaling protocols Hi David, Actually, SCTP is an alternative that supports message passing and boundary preservation, plus other features for reliability and detection of signaling path failure. It was intended to relieve the application from having to do continual verification of the signaling path and support of a backup path. However, it was being defined at about the same time as MPLS, so it was never considered as an alternative for transport of MPLS signaling. A reliable UDP was one of the alternatives considered when doing SCTP, but it still leaves the application to do testing of the signaling path and message rerouting if that fails, and does not have congestion control built in. Cheers, Lyndon -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Wednesday, July 24, 2002 7:45 AM To: IETF MPLS List Subject: Re: initiating a discussion on mpls singaling protocols As for the rest, TCP is not an appropriate transport for signaling protocols in the first place. RSVP-TE, LDP and CR-LDP all use a message-passing mechanism. They are not designed around streaming data. Use of a streaming protocol means that the protocol has to deal with the issue of detecting message boundaries and half-received messages. Unfortunately, there is no standard for anything resembling reliable UDP - that would be ideal. From owner-mpls@UU.NET Wed Jul 24 14:50:05 2002 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 ESMTP id OAA27476 for ; Wed, 24 Jul 2002 14:50:04 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxv22720 for ; Wed, 24 Jul 2002 18:51:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxv20944; Wed, 24 Jul 2002 18:50:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxv16737 for mpls-outgoing; Wed, 24 Jul 2002 18:50:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyxv16685 for ; Wed, 24 Jul 2002 18:49: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 QQmyxv07887 for ; Wed, 24 Jul 2002 18:48:49 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxv07523 for ; Wed, 24 Jul 2002 18:48:49 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmyxv07515 for ; Wed, 24 Jul 2002 18:48:48 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17XRBl-0000Zy-00; Wed, 24 Jul 2002 19:48:45 +0100 Subject: RE: initiating a discussion on mpls singaling protocols From: Giles Heron To: "Jothilingam, Vasudevan ""(Vasu)" Cc: IETF MPLS List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 24 Jul 2002 19:48:34 +0000 Message-Id: <1027540114.5341.108.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2002-07-24 at 18:22, Jothilingam, Vasudevan (Vasu) wrote: [snip] > I would like to say, yeah RSVP-TE is the way adn CR-LDP could be > informational RFC. > Being said that, there is lots of work going of L2 Transportation over MPLS, > using LDP. LDP != CR-LSP Giles > Well, even though I am not for that approach of using RSVP-TE and LDP ( two > big protocols ??) > for L2 transport, we need to see where that goes.. > > Thanks > Vasu > > > > > Vasu Jothilingam > Lucent Technologies > 1 Robbins Rd > Westford, MA-01886 > PH: (978)-952-7533 > FAX: (978)-952-7977 > > > -----Original Message----- > From: Ong, Lyndon [mailto:LyOng@ciena.com] > Sent: Wednesday, July 24, 2002 2:00 PM > To: 'David Charlap'; IETF MPLS List > Subject: RE: initiating a discussion on mpls singaling protocols > > > Hi David, > > Actually, SCTP is an alternative that supports message > passing and boundary preservation, plus other features > for reliability and detection of signaling path failure. > It was intended to relieve the application from having to > do continual verification of the signaling path and support > of a backup path. However, it was being defined at about > the same time as MPLS, so it was never considered as an > alternative for transport of MPLS signaling. > > A reliable UDP was one of the alternatives considered when doing > SCTP, but it still leaves the application to do testing > of the signaling path and message rerouting if that fails, > and does not have congestion control built in. > > Cheers, > > Lyndon > > -----Original Message----- > From: David Charlap [mailto:david.charlap@marconi.com] > Sent: Wednesday, July 24, 2002 7:45 AM > To: IETF MPLS List > Subject: Re: initiating a discussion on mpls singaling protocols > > As for the rest, TCP is not an appropriate transport for signaling > protocols in the first place. RSVP-TE, LDP and CR-LDP all use a > message-passing mechanism. They are not designed around streaming data. > Use of a streaming protocol means that the protocol has to deal with > the issue of detecting message boundaries and half-received messages. > > Unfortunately, there is no standard for anything resembling reliable UDP > - that would be ideal. > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Wed Jul 24 15:50:37 2002 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 ESMTP id PAA29836 for ; Wed, 24 Jul 2002 15:50:36 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxz23674 for ; Wed, 24 Jul 2002 19:51:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyxz22454; Wed, 24 Jul 2002 19:51:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyxz13415 for mpls-outgoing; Wed, 24 Jul 2002 19:50:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyxz13384 for ; Wed, 24 Jul 2002 19:50: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 QQmyxz23347 for ; Wed, 24 Jul 2002 19:49:55 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyxz21638 for ; Wed, 24 Jul 2002 19:49:54 GMT Received: from mail.timetra.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.timetra.com [63.104.212.2]) id QQmyxz21633 for ; Wed, 24 Jul 2002 19:49:54 GMT Received: from vkompella ([192.168.1.253]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 12:49:53 -0700 From: "Vach Kompella" To: "Loa Andersson" , "MPLS wg" Cc: "Scott Bradner" , "George Swallow" Subject: RE: comments on the MPLS OAM discussion Date: Wed, 24 Jul 2002 12:49:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: <3D367CD4.3040309@utfors.se> Importance: Normal X-OriginalArrivalTime: 24 Jul 2002 19:49:53.0113 (UTC) FILETIME=[47460490:01C2334B] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit I'm all in favor of the OAM label, but I share the concern that "giving away" a label to the ITU isn't the best use of the small reserved label space. I would like to see an MPLS OAM label defined. But the application of the label should not be restricted to the Y.1711 proposal. E.g., HVPLS OAM proposes to use an OAM label. We'd like to be able to use the MPLS OAM label without having to exchange OAM FECs as proposed in that draft. If we allow the use of a single label for all OAM applications that want to use it, we now have the next issue of how do we demux to the different apps that want to use this label? -Vach > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Loa > Andersson > Sent: Thursday, July 18, 2002 1:31 AM > To: MPLS wg > Cc: Scott Bradner; George Swallow > Subject: comments on the MPLS OAM discussion > > > All, > > at the meeting of the MPLS wg today at the 54th IETF in Yokohama the > MPLS OAM and the liasion from ITU-T SG13/Q3 were revisted. There were > a very clear consensus in the room supporting the the request in > "Use of a reserved label value defined in RFC 3032 for MPLS OAM > functions" to assign a label > value out of the reserved mpls label value space to support MPLS OAM. > > There were some concerns raised on the "economy of the reserved label > space", i.e. are we using this label space most effectively by accepting > the request from ITU-T SG13/Q3. It is the intention of the IESG to > address the question of moving the > to informational on Thursday next, this is to open up the mpls mailing > list for comments on this topic to support the IESG in their decission. > Ideally the IESG should be able to take the decission on Thursday, > but if we have an active discussion on the list the decission will > be taken when the discussion vonverges. > > /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 Jul 24 16:20:06 2002 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 ESMTP id QAA01059 for ; Wed, 24 Jul 2002 16:20:04 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyyb16822 for ; Wed, 24 Jul 2002 20:21:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyyb14674; Wed, 24 Jul 2002 20:19:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyyb08048 for mpls-outgoing; Wed, 24 Jul 2002 20:19:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmyyb08043 for ; Wed, 24 Jul 2002 20:19: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 QQmyyb25646 for ; Wed, 24 Jul 2002 20:18:49 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyyb14131 for ; Wed, 24 Jul 2002 20:18:48 GMT Received: from zcars04e.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmyyb14127 for ; Wed, 24 Jul 2002 20:18:48 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6OKISg26363; Wed, 24 Jul 2002 16:18:28 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 16:18:28 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04B87E6A@zcard031.ca.nortel.com> From: "David Allan" To: Vach Kompella , Loa Andersson , MPLS wg Cc: Scott Bradner , George Swallow Subject: RE: comments on the MPLS OAM discussion Date: Wed, 24 Jul 2002 16:18:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2334F.43DD74D8" 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_01C2334F.43DD74D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Vach: Isn't defining OAM messaging for every application of MPLS getting into = a bit of a combinatorial problem? I also got the impression from the presentation in Yokahoma that the = HVPLS OAM was more of a discussion of possibilities, and that MAC layer OAM = for HVPLS also had desirable properties (I cannot remember what the = non-MPLS PW possibilities were which presumably would require a different = mechanism...). IMHO there is not sufficient well elucidated demand for a label for = HVPLS (or anything else) to impact the meeting consensus on the ITU's = request. BTW The discussion in Yokahoma was based around a concern that the ITU = would not repeatedly keep coming back for labels and would make good use of = the the one requested. There was also discussion on hoping that proposed = use of the label was accompanied by informational drafts etc. such that the = MPLS community had the opportunity to comment on how OAM and label use = evolved. I think other folks wanting a "piece" of the label only came up briefly = and was secondary to the original concern.... cheers Dave =20 > -----Original Message----- > From: Vach Kompella [mailto:vkompella@timetra.com] > Sent: Wednesday, July 24, 2002 3:50 PM > To: Loa Andersson; MPLS wg > Cc: Scott Bradner; George Swallow > Subject: RE: comments on the MPLS OAM discussion >=20 >=20 > I'm all in favor of the OAM label, but I share the concern=20 > that "giving away" a > label to the ITU isn't the best use of the small reserved=20 > label space. I would > like to see an MPLS OAM label defined. But the application=20 > of the label should > not be restricted to the Y.1711 proposal. E.g., HVPLS OAM=20 > proposes to use an > OAM label. We'd like to be able to use the MPLS OAM label=20 > without having to > exchange OAM FECs as proposed in that draft. >=20 > If we allow the use of a single label for all OAM=20 > applications that want to use > it, we now have the next issue of how do we demux to the=20 > different apps that > want to use this label? >=20 > -Vach >=20 > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Loa > > Andersson > > Sent: Thursday, July 18, 2002 1:31 AM > > To: MPLS wg > > Cc: Scott Bradner; George Swallow > > Subject: comments on the MPLS OAM discussion > > > > > > All, > > > > at the meeting of the MPLS wg today at the 54th IETF in Yokohama = the > > MPLS OAM and the liasion from ITU-T SG13/Q3 were revisted.=20 > There were > > a very clear consensus in the room supporting the the request in > > "Use of a reserved label value defined in RFC 3032 for MPLS OAM > > functions" to assign a label > > value out of the reserved mpls label value space to support=20 > MPLS OAM. > > > > There were some concerns raised on the "economy of the=20 > reserved label > > space", i.e. are we using this label space most effectively=20 > by accepting > > the request from ITU-T SG13/Q3. It is the intention of the IESG to > > address the question of moving the=20 > > > to informational on Thursday next, this is to open up the=20 > mpls mailing > > list for comments on this topic to support the IESG in=20 > their decission. > > Ideally the IESG should be able to take the decission on Thursday, > > but if we have an active discussion on the list the decission will > > be taken when the discussion vonverges. > > > > /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 >=20 ------_=_NextPart_001_01C2334F.43DD74D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: comments on the MPLS OAM discussion

Vach:

Isn't defining OAM messaging for every application of = MPLS getting into a bit of a combinatorial problem?

I also got the impression from the presentation in = Yokahoma that the HVPLS OAM was more of a discussion of possibilities, = and that MAC layer OAM for HVPLS also had desirable properties (I = cannot remember what the non-MPLS PW possibilities were which = presumably would require a different mechanism...). IMHO there is not = sufficient well elucidated demand for a label for HVPLS (or anything = else) to impact the meeting consensus on the ITU's request.

BTW The discussion in Yokahoma was based around a = concern that the ITU would not repeatedly keep coming back for labels = and would make good use of the the one requested. There was also = discussion on hoping that proposed use of the label was accompanied by = informational drafts etc. such that the MPLS community had the = opportunity to comment on how OAM and label use evolved. I think other = folks wanting a "piece" of the label only came up briefly and = was secondary to the original concern....

cheers
Dave
 
> -----Original Message-----
> From: Vach Kompella [mailto:vkompella@timetra.com]<= /FONT>
> Sent: Wednesday, July 24, 2002 3:50 PM
> To: Loa Andersson; MPLS wg
> Cc: Scott Bradner; George Swallow
> Subject: RE: comments on the MPLS OAM = discussion
>
>
> I'm all in favor of the OAM label, but I share = the concern
> that "giving away" a
> label to the ITU isn't the best use of the = small reserved
> label space.  I would
> like to see an MPLS OAM label defined.  = But the application
> of the label should
> not be restricted to the Y.1711 proposal.  = E.g., HVPLS OAM
> proposes to use an
> OAM label.  We'd like to be able to use = the MPLS OAM label
> without having to
> exchange OAM FECs as proposed in that = draft.
>
> If we allow the use of a single label for all = OAM
> applications that want to use
> it, we now have the next issue of how do we = demux to the
> different apps that
> want to use this label?
>
> -Vach
>
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of Loa
> > Andersson
> > Sent: Thursday, July 18, 2002 1:31 = AM
> > To: MPLS wg
> > Cc: Scott Bradner; George Swallow
> > Subject: comments on the MPLS OAM = discussion
> >
> >
> > All,
> >
> > at the meeting of the MPLS wg today at the = 54th IETF in Yokohama the
> > MPLS OAM and the liasion from ITU-T = SG13/Q3 were revisted.
> There were
> > a very clear consensus in the room = supporting the the request in
> > "Use of a reserved label value = defined in RFC 3032 for MPLS OAM
> > functions" = <draft-ohta-mpls-label-value-01.txt> to assign a label
> > value out of the reserved mpls label value = space to support
> MPLS OAM.
> >
> > There were some concerns raised on the = "economy of the
> reserved label
> > space", i.e. are we using this label = space most effectively
> by accepting
> > the request from ITU-T SG13/Q3. It is the = intention of the IESG to
> > address the question of moving the
> = <draft-ohta-mpls-label-value-01.txt>
> > to informational on Thursday next, this is = to open up the
> mpls mailing
> > list for comments on this topic to support = the IESG in
> their decission.
> > Ideally the IESG should be able to take = the decission on Thursday,
> > but if we have an active discussion on the = list the decission will
> > be taken when the discussion = vonverges.
> >
> > /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           &nb= sp; www.utfors.se
> >
> >
>
>

------_=_NextPart_001_01C2334F.43DD74D8-- From owner-mpls@UU.NET Wed Jul 24 17:18:40 2002 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 ESMTP id RAA02921 for ; Wed, 24 Jul 2002 17:18:40 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyyf27478 for ; Wed, 24 Jul 2002 21:19:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyyf25969; Wed, 24 Jul 2002 21:19:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyyf07479 for mpls-outgoing; Wed, 24 Jul 2002 21:18:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyyf07474 for ; Wed, 24 Jul 2002 21:18: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 QQmyyf21282 for ; Wed, 24 Jul 2002 21:18:27 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyyf15673 for ; Wed, 24 Jul 2002 21:18:27 GMT Received: from smtp6.mindspring.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQmyyf15669 for ; Wed, 24 Jul 2002 21:18:27 GMT Received: from user-uinjnfq.dsl.mindspring.com ([165.121.221.250] helo=METANOIA) by smtp6.mindspring.com with smtp (Exim 3.33 #1) id 17XTWW-0004et-00; Wed, 24 Jul 2002 17:18:20 -0400 Reply-To: From: "Vishal Sharma" To: "Atul Gupta" , Subject: RE: Notification process Date: Wed, 24 Jul 2002 17:19:27 -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 In-Reply-To: <20020724065837.11747.qmail@web20905.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Atul, It would not be very efficient to use the Notification message of GMPLS to remove Path/Resv states in MPLS (or GMPLS). The primary purpose of the Notification message is to get error information to the point/node responsible for taking an action (such as a restoration action) in response to that error/fault. The removal of the states (even when using GMPLS) is still handled by normal RSVP processes, which remove state systematically (hop-by-hop) [and free up resources] from all of the intermediate nodes on a LSP. To do the same with a Notification message, you'd probably have to send a series of Notification messages (since it is a targeted message) one each to every intermediate node on the LSP, instructing them to remove state! -Vishal > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Atul > Gupta > Sent: Wednesday, July 24, 2002 2:59 AM > To: mpls@UU.NET > Subject: Notification process > > > Hi, > In GMPLS we use Notification Message to avoid the > large propagation delays of the error messages. Can we > use same message in MPLS so that existing Path/Resv > States can be removed quikly and resources are also > preserved. > Atul > Samsung > > ===== > Atul Gupta > Samsung Software > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > From owner-mpls@UU.NET Wed Jul 24 17:25:21 2002 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 ESMTP id RAA03077 for ; Wed, 24 Jul 2002 17:25:21 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyyf04751 for ; Wed, 24 Jul 2002 21:26:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyyf03465; Wed, 24 Jul 2002 21:25:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyyf07669 for mpls-outgoing; Wed, 24 Jul 2002 21:25:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyyf07664 for ; Wed, 24 Jul 2002 21:25: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 QQmyyf09833 for ; Wed, 24 Jul 2002 21:24:34 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyyf06287 for ; Wed, 24 Jul 2002 21:24:33 GMT Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmyyf06282 for ; Wed, 24 Jul 2002 21:24:33 GMT Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 24 Jul 2002 22:24:36 +0100 Message-ID: To: dallan@nortelnetworks.com, vkompella@timetra.com, loa.andersson@utfors.se, mpls@UU.NET Cc: sob@harvard.edu, swallow@cisco.com Subject: RE: comments on the MPLS OAM discussion Date: Wed, 24 Jul 2002 22:24:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23358.7CCA8160" 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_01C23358.7CCA8160 Content-Type: text/plain; charset="ISO-8859-1" Dave....Your 1st observation below misses a key point: One of the main requirements of the MPLS OAM work (requirements being defined in Y.1710) is that solutions must be client or server layer (read technology if you like) agnostic. So whether the LSP is carrying IP, ATM, ethernet or anything else it is the LSP itself that is fault-managed. This is a desirable goal for what I think are obvious reasons. When an OAM pkt is sent the LSP label depth increases by 1 over normal traffic depth. So exactly the same 'normal traffic' label stack appears before an OAM pkt. Given the semantics of the payload are supposed to be conveyed from seeing the normal forwarding label then one knows the application to which this OAM pkt applies. Further, you should not be asking MPLS OAM to proxy for any missing ethernet OAM. MPLS OAM looks after LSPs irrespective of the client as I noted above. If ethernet requires OAM then ethernet should provide it.....in fact I am puzzled why no one has suggested defining a new ethertype for ethernet OAM (or maybe they have?), since at least ethernet does have such a field and this seems an obvious solution here. regards, Neil -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: 24 July 2002 21:18 To: Vach Kompella; Loa Andersson; MPLS wg Cc: Scott Bradner; George Swallow Subject: RE: comments on the MPLS OAM discussion Vach: Isn't defining OAM messaging for every application of MPLS getting into a bit of a combinatorial problem? I also got the impression from the presentation in Yokahoma that the HVPLS OAM was more of a discussion of possibilities, and that MAC layer OAM for HVPLS also had desirable properties (I cannot remember what the non-MPLS PW possibilities were which presumably would require a different mechanism...). IMHO there is not sufficient well elucidated demand for a label for HVPLS (or anything else) to impact the meeting consensus on the ITU's request. BTW The discussion in Yokahoma was based around a concern that the ITU would not repeatedly keep coming back for labels and would make good use of the the one requested. There was also discussion on hoping that proposed use of the label was accompanied by informational drafts etc. such that the MPLS community had the opportunity to comment on how OAM and label use evolved. I think other folks wanting a "piece" of the label only came up briefly and was secondary to the original concern.... cheers Dave > -----Original Message----- > From: Vach Kompella [ mailto:vkompella@timetra.com ] > Sent: Wednesday, July 24, 2002 3:50 PM > To: Loa Andersson; MPLS wg > Cc: Scott Bradner; George Swallow > Subject: RE: comments on the MPLS OAM discussion > > > I'm all in favor of the OAM label, but I share the concern > that "giving away" a > label to the ITU isn't the best use of the small reserved > label space. I would > like to see an MPLS OAM label defined. But the application > of the label should > not be restricted to the Y.1711 proposal. E.g., HVPLS OAM > proposes to use an > OAM label. We'd like to be able to use the MPLS OAM label > without having to > exchange OAM FECs as proposed in that draft. > > If we allow the use of a single label for all OAM > applications that want to use > it, we now have the next issue of how do we demux to the > different apps that > want to use this label? > > -Vach > > > -----Original Message----- > > From: owner-mpls@UU.NET [ mailto:owner-mpls@UU.NET ]On Behalf Of Loa > > Andersson > > Sent: Thursday, July 18, 2002 1:31 AM > > To: MPLS wg > > Cc: Scott Bradner; George Swallow > > Subject: comments on the MPLS OAM discussion > > > > > > All, > > > > at the meeting of the MPLS wg today at the 54th IETF in Yokohama the > > MPLS OAM and the liasion from ITU-T SG13/Q3 were revisted. > There were > > a very clear consensus in the room supporting the the request in > > "Use of a reserved label value defined in RFC 3032 for MPLS OAM > > functions" to assign a label > > value out of the reserved mpls label value space to support > MPLS OAM. > > > > There were some concerns raised on the "economy of the > reserved label > > space", i.e. are we using this label space most effectively > by accepting > > the request from ITU-T SG13/Q3. It is the intention of the IESG to > > address the question of moving the > > > to informational on Thursday next, this is to open up the > mpls mailing > > list for comments on this topic to support the IESG in > their decission. > > Ideally the IESG should be able to take the decission on Thursday, > > but if we have an active discussion on the list the decission will > > be taken when the discussion vonverges. > > > > /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 > > > > > > ------_=_NextPart_001_01C23358.7CCA8160 Content-Type: text/html; charset="ISO-8859-1" RE: comments on the MPLS OAM discussion
Dave....Your 1st observation below misses a key point:  One of the main requirements of the MPLS OAM work (requirements being defined in Y.1710) is that solutions must be client or server layer (read technology if you like) agnostic.  So whether the LSP is carrying IP, ATM, ethernet or anything else it is the LSP itself that is fault-managed.  This is a desirable goal for what I think are obvious reasons. 
 
When an OAM pkt is sent the LSP label depth increases by 1 over normal traffic depth.  So exactly the same 'normal traffic' label stack appears before an OAM pkt.  Given the semantics of the payload are supposed to be conveyed from seeing the normal forwarding label then one knows the application to which this OAM pkt applies.
 
Further, you should not be asking MPLS OAM to proxy for any missing ethernet OAM.  MPLS OAM looks after LSPs irrespective of the client as I noted above.  If ethernet requires OAM then ethernet should provide it.....in fact I am puzzled why no one has suggested defining a new ethertype for ethernet OAM (or maybe they have?), since at least ethernet does have such a field and this seems an obvious solution here.
 
regards, Neil
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: 24 July 2002 21:18
To: Vach Kompella; Loa Andersson; MPLS wg
Cc: Scott Bradner; George Swallow
Subject: RE: comments on the MPLS OAM discussion

Vach:

Isn't defining OAM messaging for every application of MPLS getting into a bit of a combinatorial problem?

I also got the impression from the presentation in Yokahoma that the HVPLS OAM was more of a discussion of possibilities, and that MAC layer OAM for HVPLS also had desirable properties (I cannot remember what the non-MPLS PW possibilities were which presumably would require a different mechanism...). IMHO there is not sufficient well elucidated demand for a label for HVPLS (or anything else) to impact the meeting consensus on the ITU's request.

BTW The discussion in Yokahoma was based around a concern that the ITU would not repeatedly keep coming back for labels and would make good use of the the one requested. There was also discussion on hoping that proposed use of the label was accompanied by informational drafts etc. such that the MPLS community had the opportunity to comment on how OAM and label use evolved. I think other folks wanting a "piece" of the label only came up briefly and was secondary to the original concern....

cheers
Dave
 
> -----Original Message-----
> From: Vach Kompella [mailto:vkompella@timetra.com]
> Sent: Wednesday, July 24, 2002 3:50 PM
> To: Loa Andersson; MPLS wg
> Cc: Scott Bradner; George Swallow
> Subject: RE: comments on the MPLS OAM discussion
>
>
> I'm all in favor of the OAM label, but I share the concern
> that "giving away" a
> label to the ITU isn't the best use of the small reserved
> label space.  I would
> like to see an MPLS OAM label defined.  But the application
> of the label should
> not be restricted to the Y.1711 proposal.  E.g., HVPLS OAM
> proposes to use an
> OAM label.  We'd like to be able to use the MPLS OAM label
> without having to
> exchange OAM FECs as proposed in that draft.
>
> If we allow the use of a single label for all OAM
> applications that want to use
> it, we now have the next issue of how do we demux to the
> different apps that
> want to use this label?
>
> -Vach
>
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Loa
> > Andersson
> > Sent: Thursday, July 18, 2002 1:31 AM
> > To: MPLS wg
> > Cc: Scott Bradner; George Swallow
> > Subject: comments on the MPLS OAM discussion
> >
> >
> > All,
> >
> > at the meeting of the MPLS wg today at the 54th IETF in Yokohama the
> > MPLS OAM and the liasion from ITU-T SG13/Q3 were revisted.
> There were
> > a very clear consensus in the room supporting the the request in
> > "Use of a reserved label value defined in RFC 3032 for MPLS OAM
> > functions" <draft-ohta-mpls-label-value-01.txt> to assign a label
> > value out of the reserved mpls label value space to support
> MPLS OAM.
> >
> > There were some concerns raised on the "economy of the
> reserved label
> > space", i.e. are we using this label space most effectively
> by accepting
> > the request from ITU-T SG13/Q3. It is the intention of the IESG to
> > address the question of moving the
> <draft-ohta-mpls-label-value-01.txt>
> > to informational on Thursday next, this is to open up the
> mpls mailing
> > list for comments on this topic to support the IESG in
> their decission.
> > Ideally the IESG should be able to take the decission on Thursday,
> > but if we have an active discussion on the list the decission will
> > be taken when the discussion vonverges.
> >
> > /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
> >
> >
>
>

------_=_NextPart_001_01C23358.7CCA8160-- From owner-mpls@UU.NET Thu Jul 25 02:11:36 2002 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 ESMTP id CAA24116 for ; Thu, 25 Jul 2002 02:11:36 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyzo26373 for ; Thu, 25 Jul 2002 06:12:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyzo25269; Thu, 25 Jul 2002 06:12:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyzo02644 for mpls-outgoing; Thu, 25 Jul 2002 06:11:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyzo02638 for ; Thu, 25 Jul 2002 06:11: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 QQmyzo14519 for ; Thu, 25 Jul 2002 06:11:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyzo05865 for ; Thu, 25 Jul 2002 06:11:07 GMT Received: from web20909.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20909.mail.yahoo.com [216.136.226.231]) id QQmyzo05861 for ; Thu, 25 Jul 2002 06:11:07 GMT Message-ID: <20020725061106.6726.qmail@web20909.mail.yahoo.com> Received: from [203.200.20.226] by web20909.mail.yahoo.com via HTTP; Wed, 24 Jul 2002 23:11:06 PDT Date: Wed, 24 Jul 2002 23:11:06 -0700 (PDT) From: Atul Gupta Subject: RE: Notification process To: v.sharma@ieee.org, mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Vishal, Well sending the Notifications to all upstream nodes may not help much(If the Idea is not only to remove the State) because the new PATH request has to come from Ingress/Initiator. What if the Notify Message send to the Ingress/Initiator starts sending the PathTear downstream and the failure detection point start tearing the Path State upstream. The two together will remove the existing PATH and help establishing the new PATH again quickly. Although we can use GMPLS over PSC, but the Idea above is only to modify MPLS for fast convergence, for big LSP. --- Vishal Sharma wrote: > Atul, > > It would not be very efficient to use the > Notification message > of GMPLS to remove Path/Resv states in MPLS (or > GMPLS). > The primary purpose of the Notification message is > to get error > information to the point/node responsible for taking > an action > (such as a restoration action) in response to that > error/fault. > > The removal of the states (even when using GMPLS) > is still handled by normal RSVP processes, > which remove state systematically (hop-by-hop) [and > free up resources] > from all of the intermediate nodes on a LSP. > > To do the same with a Notification message, you'd > probably have to > send a series of Notification messages (since it is > a targeted message) > one each to every intermediate node on the LSP, > instructing them to > remove state! > > -Vishal > > > -----Original Message----- > > From: owner-mpls@UU.NET > [mailto:owner-mpls@UU.NET]On Behalf Of Atul > > Gupta > > Sent: Wednesday, July 24, 2002 2:59 AM > > To: mpls@UU.NET > > Subject: Notification process > > > > > > Hi, > > In GMPLS we use Notification Message to avoid the > > large propagation delays of the error messages. > Can we > > use same message in MPLS so that existing > Path/Resv > > States can be removed quikly and resources are > also > > preserved. > > Atul > > Samsung > > > > ===== > > Atul Gupta > > Samsung Software > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Health - Feel better, live better > > http://health.yahoo.com > > > ===== Atul Gupta Samsung Software __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-mpls@UU.NET Thu Jul 25 02:13:09 2002 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 ESMTP id CAA24166 for ; Thu, 25 Jul 2002 02:13:09 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyzo07980 for ; Thu, 25 Jul 2002 06:14:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyzo06464; Thu, 25 Jul 2002 06:13:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyzo02661 for mpls-outgoing; Thu, 25 Jul 2002 06:12:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyzo02654 for ; Thu, 25 Jul 2002 06:12: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 QQmyzo29567 for ; Thu, 25 Jul 2002 06:11:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyzo24780 for ; Thu, 25 Jul 2002 06:11:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmyzo24768 for ; Thu, 25 Jul 2002 06:11:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA01791 for ; Thu, 25 Jul 2002 02:11:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA13819 for mpls@uu.net; Thu, 25 Jul 2002 02:11:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyzo01787 for ; Thu, 25 Jul 2002 06:09: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 QQmyzo24561 for ; Thu, 25 Jul 2002 06:09:28 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyzo01106 for ; Thu, 25 Jul 2002 06:09:28 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmyzo01101 for ; Thu, 25 Jul 2002 06:09:27 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 11:46:06 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06500093@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: David Charlap Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Thu, 25 Jul 2002 11:41:21 +0530 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 David, I accept your argument. However, it finally comes down to saying that RSVP-TE is not having more overhead than CR-LDP. Its taken a lot of add-ons and workarounds to RSVP to bring to this level. Thats why the question of complexity, implementation and maintenance issues related to software life cycle reduction were raised. Developing a new transport for signalling would be much beneficial than doing it separately for each signalling protocol. Regards, Vijay -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Wednesday, July 24, 2002 8:15 PM To: IETF MPLS List Subject: Re: initiating a discussion on mpls singaling protocols Vijayanand C - CTD, Chennai. wrote: > TCP being a relaible transport protocol is meant to do just that. It can and > has been optimised repeatedly for this purpose. The presence of TCP is > almost default in all the stacks. So, there is no need to duplicate a part > of its functionality in another protocol and try to optimise it repeatedly > in a new thread. Trying to build a semi reliable transport layer inside > RSVP-TE with all its paraphenelia to make it harder is another form of > duplication so to speak. Also, refreshing a number of LSPs even through > summaries is avoided by a single keep alive in CR LDP. Thanks for changing the subject here. You were talking about protocol complexity, not implementation stability. Of course a new protocol implementation will be less stable than something 20 years old. Does this mean we should avoid developing anything new ever again? As for the rest, TCP is not an appropriate transport for signaling protocols in the first place. RSVP-TE, LDP and CR-LDP all use a message-passing mechanism. They are not designed around streaming data. Use of a streaming protocol means that the protocol has to deal with the issue of detecting message boundaries and half-received messages. Unfortunately, there is no standard for anything resembling reliable UDP - that would be ideal. The message-ID part of RSVP refresh reduction is designed to fill this void. Packets can't be half-received, and message boundaries are preserved. Retransmission is on a per-message basis instead of for the entire flow, so one dropped message doesn't cause all subsequent messages to back up waiting for the retransmission. It also recognizes the fact that not all messages need to be delivered reliably, and allows RSVP to not use the mechanism for those messages that don't result in state changes. With regard to refreshing, you don't seem to appreciate what the refresh reduction extension buys. There is no need to generate summary refreshes every 30 seconds. As I have said before, when refresh reduction and hellos are both in place, there is no need for frequent refreshes. Under this circumstance, you can set the refresh interval to something on the order of hours, or even days without any ill effect. How is this have any more overhead than what CR-LDP does. -- David From owner-mpls@UU.NET Thu Jul 25 02:36:16 2002 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 ESMTP id CAA24483 for ; Thu, 25 Jul 2002 02:36:16 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyzq15297 for ; Thu, 25 Jul 2002 06:37:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyzq13907; Thu, 25 Jul 2002 06:36:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyzq04537 for mpls-outgoing; Thu, 25 Jul 2002 06:36:26 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmyzq04495 for ; Thu, 25 Jul 2002 06:36: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 QQmyzq12068 for ; Thu, 25 Jul 2002 06:36:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyzq22392 for ; Thu, 25 Jul 2002 06:36:09 GMT Received: from mx2.melange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lmta02.melange.net [212.59.199.93]) id QQmyzq22386 for ; Thu, 25 Jul 2002 06:36:08 GMT Received: from page.melange.net (smss02-correo.arrakis.isp [192.168.197.194]) by mx2.melange.net (---) with ESMTP id g6P6ajU11149; Thu, 25 Jul 2002 08:36:46 +0200 From: fraanro To: ccie@k.st Cc: mpls@UU.NET Message-ID: <4e8be4b65d.4b65d4e8be@page.melange.net> Date: Thu, 25 Jul 2002 06:36:45 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: Re: MPLS L2VPN Multiple Packet (Broadcast/Multicast/UnkUnicast) Problem X-Accept-Language: es 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 At this moment the existing implementations are based on replication in the headend as you say. It is highly important to do that replication in hardware, and ASICs usually will have limitations in the number of replications they are able to do at the same time. Now the point is, considering that scenario what can be considered appropiate for a L2 VPN, 50 sites? 100? 200? ... Obviously because of this, the Hierchical VPLS are being introduced in order to support a higher number of sites on a L2 VPN. On the other hand I am not sure if an scenario with such a big number of sites is appropriate for a L2 VPN and maybe it would be better a L3 VPN (well, maybe a online gaming L2 VPN where each site is an individual user may make sense). Javier. ----- Mensaje Original ----- Remitente: Gary Blankenship Fecha: Lunes, Julio 22, 2002 8:07 am Asunto: MPLS L2VPN Multiple Packet (Broadcast/Multicast/UnkUnicast) Problem > MPLS WG, > > I was wondering what the current direction of the MPLS WG is for > solving the duplicate copy over single link problem for L2VPN. > > Problem definition: In a multipoint environment a full mesh of > LSP's is required (classic N(N-1)/2). If the packet is duplicated > at the head end it results in multiple copies of the same packet > traveling over the same wire (bad thing). > > Questions: > > What is the current thinking for solving this problem? Draft > Yasukawa (RSVP Multicast LSPs)? Hierarchical LSPs? Can someone > please give me a status summary on work to resolve this? Comments > from anyone on the Lasserre-VKompella draft? Any ideas leading > the pack? > > Thanks, > > Gary > > _____________________________________________________________ > Powered by a short email address ... http://www.k.st > > _____________________________________________________________ > Promote your group and strengthen ties to your members with > email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag > > From owner-mpls@UU.NET Thu Jul 25 04:19:19 2002 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 ESMTP id EAA26182 for ; Thu, 25 Jul 2002 04:19:18 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyzx09210 for ; Thu, 25 Jul 2002 08:20:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmyzx07653; Thu, 25 Jul 2002 08:19:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmyzx26339 for mpls-outgoing; Thu, 25 Jul 2002 08:19:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmyzx26334 for ; Thu, 25 Jul 2002 08:19:15 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 QQmyzx08870 for ; Thu, 25 Jul 2002 08:18:51 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmyzx19191 for ; Thu, 25 Jul 2002 08:18:50 GMT Received: from mail1.hd.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hdfdns01.hd.intel.com [192.52.58.10]) id QQmyzx19187 for ; Thu, 25 Jul 2002 08:18:50 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by mail1.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6P8Inm18486 for ; Thu, 25 Jul 2002 08:18:49 GMT Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002072501175627226 ; Thu, 25 Jul 2002 01:17:57 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 10:15:08 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0329C607@alpha.igk.intel.com> From: "Bisewski, Radoslaw" To: "'Giles Heron'" , "Jothilingam, Vasudevan \"\"(Vasu)" Cc: IETF MPLS List Subject: RE: initiating a discussion on mpls singaling protocols Date: Thu, 25 Jul 2002 10:15:08 +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 But CR-LDP is an extension to the LDP protocol. While RSVP-TE has nothing in common with LDP. After "eliminating" CR-LDP you will still have two MPLS signalling protocols MPLS LDP and RSVP-TE. Radek > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Wednesday, July 24, 2002 9:49 PM > To: Jothilingam, Vasudevan ""(Vasu) > Cc: IETF MPLS List > Subject: RE: initiating a discussion on mpls singaling protocols > > > On Wed, 2002-07-24 at 18:22, Jothilingam, Vasudevan (Vasu) wrote: > [snip] > > I would like to say, yeah RSVP-TE is the way adn CR-LDP could be > > informational RFC. > > Being said that, there is lots of work going of L2 > Transportation over MPLS, > > using LDP. > > LDP != CR-LSP > > Giles > > > Well, even though I am not for that approach of using > RSVP-TE and LDP ( two > > big protocols ??) > > for L2 transport, we need to see where that goes.. > > > > Thanks > > Vasu > > > > > > > > > > Vasu Jothilingam > > Lucent Technologies > > 1 Robbins Rd > > Westford, MA-01886 > > PH: (978)-952-7533 > > FAX: (978)-952-7977 > > > > > > -----Original Message----- > > From: Ong, Lyndon [mailto:LyOng@ciena.com] > > Sent: Wednesday, July 24, 2002 2:00 PM > > To: 'David Charlap'; IETF MPLS List > > Subject: RE: initiating a discussion on mpls singaling protocols > > > > > > Hi David, > > > > Actually, SCTP is an alternative that supports message > > passing and boundary preservation, plus other features > > for reliability and detection of signaling path failure. > > It was intended to relieve the application from having to > > do continual verification of the signaling path and support > > of a backup path. However, it was being defined at about > > the same time as MPLS, so it was never considered as an > > alternative for transport of MPLS signaling. > > > > A reliable UDP was one of the alternatives considered when doing > > SCTP, but it still leaves the application to do testing > > of the signaling path and message rerouting if that fails, > > and does not have congestion control built in. > > > > Cheers, > > > > Lyndon > > > > -----Original Message----- > > From: David Charlap [mailto:david.charlap@marconi.com] > > Sent: Wednesday, July 24, 2002 7:45 AM > > To: IETF MPLS List > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > As for the rest, TCP is not an appropriate transport for signaling > > protocols in the first place. RSVP-TE, LDP and CR-LDP all use a > > message-passing mechanism. They are not designed around > streaming data. > > Use of a streaming protocol means that the protocol has > to deal with > > the issue of detecting message boundaries and half-received > messages. > > > > Unfortunately, there is no standard for anything resembling > reliable UDP > > - that would be ideal. > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Thu Jul 25 05:10:14 2002 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 ESMTP id FAA26830 for ; Thu, 25 Jul 2002 05:10:14 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzaa23673 for ; Thu, 25 Jul 2002 09:11:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzaa22676; Thu, 25 Jul 2002 09:10:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzaa21280 for mpls-outgoing; Thu, 25 Jul 2002 09:10:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzaa21226 for ; Thu, 25 Jul 2002 09:09:51 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 QQmzaa26859 for ; Thu, 25 Jul 2002 09:09:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzaa21597 for ; Thu, 25 Jul 2002 09:09:04 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 QQmzaa21585 for ; Thu, 25 Jul 2002 09:09:03 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA01182; Thu, 25 Jul 2002 11:08:43 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA19441; Thu, 25 Jul 2002 11:09:01 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 11:08:57 +0200 Message-ID: From: Hummel Heinrich To: "'Bisewski, Radoslaw'" , "'Giles Heron'" , "Jothilingam, Vasudevan \"\"(Vasu)" Cc: IETF MPLS List Subject: AW: initiating a discussion on mpls singaling protocols Date: Thu, 25 Jul 2002 11:08: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 FAA26830 What kind of LSPs are we currently able to establish ? Which of the following LSPs can be established by CR-LDP, RSVP-TE, LDP : 1) p2p LSP 2) p2mp LSP 3) mp2p LSP 4) mp2mp LSP 5) p2p H-LSP 6) mp2p H-LSP 7) p2mp H-LSP 8) mp2mp H-LSP Which of the three protocols seems to be suitable for extensions where we don't have a solution yet? (BTW: In Orlando in 1998 I remember a VPN BOF, which at that time failed to proceed to a WG, because of an argument, saying "we cannot do such high level applications before we haven't even solved MPLS Multicast:-( Heinrich -----Ursprüngliche Nachricht----- Von: Bisewski, Radoslaw [mailto:Radoslaw.Bisewski@intel.com] Gesendet: Donnerstag, 25. Juli 2002 10:15 An: 'Giles Heron'; Jothilingam, Vasudevan ""(Vasu) Cc: IETF MPLS List Betreff: RE: initiating a discussion on mpls singaling protocols But CR-LDP is an extension to the LDP protocol. While RSVP-TE has nothing in common with LDP. After "eliminating" CR-LDP you will still have two MPLS signalling protocols MPLS LDP and RSVP-TE. Radek > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Wednesday, July 24, 2002 9:49 PM > To: Jothilingam, Vasudevan ""(Vasu) > Cc: IETF MPLS List > Subject: RE: initiating a discussion on mpls singaling protocols > > > On Wed, 2002-07-24 at 18:22, Jothilingam, Vasudevan (Vasu) wrote: > [snip] > > I would like to say, yeah RSVP-TE is the way adn CR-LDP could be > > informational RFC. > > Being said that, there is lots of work going of L2 > Transportation over MPLS, > > using LDP. > > LDP != CR-LSP > > Giles > > > Well, even though I am not for that approach of using > RSVP-TE and LDP ( two > > big protocols ??) > > for L2 transport, we need to see where that goes.. > > > > Thanks > > Vasu > > > > > > > > > > Vasu Jothilingam > > Lucent Technologies > > 1 Robbins Rd > > Westford, MA-01886 > > PH: (978)-952-7533 > > FAX: (978)-952-7977 > > > > > > -----Original Message----- > > From: Ong, Lyndon [mailto:LyOng@ciena.com] > > Sent: Wednesday, July 24, 2002 2:00 PM > > To: 'David Charlap'; IETF MPLS List > > Subject: RE: initiating a discussion on mpls singaling protocols > > > > > > Hi David, > > > > Actually, SCTP is an alternative that supports message > > passing and boundary preservation, plus other features > > for reliability and detection of signaling path failure. > > It was intended to relieve the application from having to > > do continual verification of the signaling path and support > > of a backup path. However, it was being defined at about > > the same time as MPLS, so it was never considered as an > > alternative for transport of MPLS signaling. > > > > A reliable UDP was one of the alternatives considered when doing > > SCTP, but it still leaves the application to do testing > > of the signaling path and message rerouting if that fails, > > and does not have congestion control built in. > > > > Cheers, > > > > Lyndon > > > > -----Original Message----- > > From: David Charlap [mailto:david.charlap@marconi.com] > > Sent: Wednesday, July 24, 2002 7:45 AM > > To: IETF MPLS List > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > As for the rest, TCP is not an appropriate transport for signaling > > protocols in the first place. RSVP-TE, LDP and CR-LDP all use a > > message-passing mechanism. They are not designed around > streaming data. > > Use of a streaming protocol means that the protocol has > to deal with > > the issue of detecting message boundaries and half-received > messages. > > > > Unfortunately, there is no standard for anything resembling > reliable UDP > > - that would be ideal. > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Thu Jul 25 07:34:22 2002 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 ESMTP id HAA29006 for ; Thu, 25 Jul 2002 07:34:22 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzak23036 for ; Thu, 25 Jul 2002 11:35:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzak21432; Thu, 25 Jul 2002 11:34:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzak16307 for mpls-outgoing; Thu, 25 Jul 2002 11:34:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzak16302 for ; Thu, 25 Jul 2002 11:34: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 QQmzak21032 for ; Thu, 25 Jul 2002 11:32:27 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzak23790 for ; Thu, 25 Jul 2002 11:32:27 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmzak23786 for ; Thu, 25 Jul 2002 11:32:26 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17Xgm6-0002aO-00; Thu, 25 Jul 2002 12:27:18 +0100 Subject: RE: initiating a discussion on mpls singaling protocols From: Giles Heron To: "Bisewski, Radoslaw" Cc: "Jothilingam, Vasudevan ""\"\"(Vasu)" , IETF MPLS List In-Reply-To: <413FBB0BA5AED1119122000083234B1A0329C607@alpha.igk.intel.com> References: <413FBB0BA5AED1119122000083234B1A0329C607@alpha.igk.intel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Jul 2002 12:27:09 +0000 Message-Id: <1027600029.1449.153.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2002-07-25 at 08:15, Bisewski, Radoslaw wrote: > But CR-LDP is an extension to the LDP protocol. While RSVP-TE has nothing in > common with LDP. After "eliminating" CR-LDP you will still have two MPLS > signalling protocols MPLS LDP and RSVP-TE. Agreed - however this doesn't negate my point that LDP != CR-LDP (i.e. moving CR-LDP to informational or historic would in no way impact LDP). In a perfect world we would probably only have LDP (for merging LSPs and for L2 FEC advertisement) and CR-LDP (for TE). However it is rather too late to shut this particular stable door. Neither LDP or RSVP-TE is about to disappear - however annoying it might be that certain vendors appeared to foist RSVP-TE onto us (I wasn't there at the time so I can't comment on this). Having CR-LDP as well (even if it is based on LDP) seems to me to increase complexity, rather than reduce it... Giles > > Radek > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: Wednesday, July 24, 2002 9:49 PM > > To: Jothilingam, Vasudevan ""(Vasu) > > Cc: IETF MPLS List > > Subject: RE: initiating a discussion on mpls singaling protocols > > > > > > On Wed, 2002-07-24 at 18:22, Jothilingam, Vasudevan (Vasu) wrote: > > [snip] > > > I would like to say, yeah RSVP-TE is the way adn CR-LDP could be > > > informational RFC. > > > Being said that, there is lots of work going of L2 > > Transportation over MPLS, > > > using LDP. > > > > LDP != CR-LSP > > > > Giles > > > > > Well, even though I am not for that approach of using > > RSVP-TE and LDP ( two > > > big protocols ??) > > > for L2 transport, we need to see where that goes.. > > > > > > Thanks > > > Vasu > > > > > > > > > > > > > > > Vasu Jothilingam > > > Lucent Technologies > > > 1 Robbins Rd > > > Westford, MA-01886 > > > PH: (978)-952-7533 > > > FAX: (978)-952-7977 > > > > > > > > > -----Original Message----- > > > From: Ong, Lyndon [mailto:LyOng@ciena.com] > > > Sent: Wednesday, July 24, 2002 2:00 PM > > > To: 'David Charlap'; IETF MPLS List > > > Subject: RE: initiating a discussion on mpls singaling protocols > > > > > > > > > Hi David, > > > > > > Actually, SCTP is an alternative that supports message > > > passing and boundary preservation, plus other features > > > for reliability and detection of signaling path failure. > > > It was intended to relieve the application from having to > > > do continual verification of the signaling path and support > > > of a backup path. However, it was being defined at about > > > the same time as MPLS, so it was never considered as an > > > alternative for transport of MPLS signaling. > > > > > > A reliable UDP was one of the alternatives considered when doing > > > SCTP, but it still leaves the application to do testing > > > of the signaling path and message rerouting if that fails, > > > and does not have congestion control built in. > > > > > > Cheers, > > > > > > Lyndon > > > > > > -----Original Message----- > > > From: David Charlap [mailto:david.charlap@marconi.com] > > > Sent: Wednesday, July 24, 2002 7:45 AM > > > To: IETF MPLS List > > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > > > As for the rest, TCP is not an appropriate transport for signaling > > > protocols in the first place. RSVP-TE, LDP and CR-LDP all use a > > > message-passing mechanism. They are not designed around > > streaming data. > > > Use of a streaming protocol means that the protocol has > > to deal with > > > the issue of detecting message boundaries and half-received > > messages. > > > > > > Unfortunately, there is no standard for anything resembling > > reliable UDP > > > - that would be ideal. > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Thu Jul 25 08:11:45 2002 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 ESMTP id IAA00333 for ; Thu, 25 Jul 2002 08:11:45 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzam17324 for ; Thu, 25 Jul 2002 12:12:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzam14840; Thu, 25 Jul 2002 12:11:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzam11253 for mpls-outgoing; Thu, 25 Jul 2002 12:11:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzam11142 for ; Thu, 25 Jul 2002 12:10:56 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 QQmzam23056 for ; Thu, 25 Jul 2002 12:10:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzam14244 for ; Thu, 25 Jul 2002 12:10:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzam14213 for ; Thu, 25 Jul 2002 12:10:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA13631 for ; Thu, 25 Jul 2002 08:10:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20581 for mpls@uu.net; Thu, 25 Jul 2002 08:10:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzam10333 for ; Thu, 25 Jul 2002 12:08: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 QQmzam19946 for ; Thu, 25 Jul 2002 12:08:45 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzam13572 for ; Thu, 25 Jul 2002 12:08:45 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmzam13568 for ; Thu, 25 Jul 2002 12:08:44 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00041; Thu, 25 Jul 2002 08:07:38 -0400 (EDT) Message-Id: <200207251207.IAA00041@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-crldp-unnum-07.txt Date: Thu, 25 Jul 2002 08:07:38 -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 : Signalling Unnumbered Links in CR-LDP Author(s) : K. Kompella, Y. Rekhter, A. Kullberg Filename : draft-ietf-mpls-crldp-unnum-07.txt Pages : 7 Date : 24-Jul-02 Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) doesn't provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-crldp-unnum-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-crldp-unnum-07.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-crldp-unnum-07.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: <20020724143031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-crldp-unnum-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724143031.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jul 25 08:14:03 2002 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 ESMTP id IAA00388 for ; Thu, 25 Jul 2002 08:14:03 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzan22528 for ; Thu, 25 Jul 2002 12:15:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzam14429; Thu, 25 Jul 2002 12:11:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzam11195 for mpls-outgoing; Thu, 25 Jul 2002 12:11:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzam11141 for ; Thu, 25 Jul 2002 12:10: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 QQmzam23058 for ; Thu, 25 Jul 2002 12:10:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzam14256 for ; Thu, 25 Jul 2002 12:10:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzam14220 for ; Thu, 25 Jul 2002 12:10:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA13633 for ; Thu, 25 Jul 2002 08:10:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20590 for mpls@uu.net; Thu, 25 Jul 2002 08:10:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzam10422 for ; Thu, 25 Jul 2002 12:09: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 QQmzam20159 for ; Thu, 25 Jul 2002 12:08:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzam13614 for ; Thu, 25 Jul 2002 12:08:49 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmzam13610 for ; Thu, 25 Jul 2002 12:08: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 IAA00057; Thu, 25 Jul 2002 08:07:43 -0400 (EDT) Message-Id: <200207251207.IAA00057@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-unnum-07.txt Date: Thu, 25 Jul 2002 08:07:43 -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 : Signalling Unnumbered Links in RSVP-TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-rsvp-unnum-07.txt Pages : 8 Date : 24-Jul-02 Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) doesn't provide support for unnumbered links. This document defines procedures and extensions to Extensions to RSVP for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-unnum-07.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-unnum-07.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: <20020724143041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-unnum-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724143041.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jul 25 08:15:55 2002 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 ESMTP id IAA00422 for ; Thu, 25 Jul 2002 08:15:55 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzan24487 for ; Thu, 25 Jul 2002 12:17:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzam16675; Thu, 25 Jul 2002 12:13:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzam11369 for mpls-outgoing; Thu, 25 Jul 2002 12:13:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzam11348 for ; Thu, 25 Jul 2002 12:11: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 QQmzam28257 for ; Thu, 25 Jul 2002 12:11:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzam14862 for ; Thu, 25 Jul 2002 12:11:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzam14856 for ; Thu, 25 Jul 2002 12:11:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA13681 for ; Thu, 25 Jul 2002 08:11:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20695 for mpls@uu.net; Thu, 25 Jul 2002 08:11:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzam10479 for ; Thu, 25 Jul 2002 12:09: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 QQmzam05023 for ; Thu, 25 Jul 2002 12:08:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzam13544 for ; Thu, 25 Jul 2002 12:08:39 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmzam13536 for ; Thu, 25 Jul 2002 12:08:39 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00025; Thu, 25 Jul 2002 08:07:33 -0400 (EDT) Message-Id: <200207251207.IAA00025@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-bundle-04.txt Date: Thu, 25 Jul 2002 08:07:33 -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 : Link Bundling in MPLS Traffic Engineering Author(s) : K. Kompella, Y. Rekhter, L. Berger Filename : draft-ietf-mpls-bundle-04.txt Pages : 9 Date : 24-Jul-02 For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct which is described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-bundle-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-bundle-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020724143022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bundle-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bundle-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724143022.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jul 25 10:21:12 2002 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 ESMTP id KAA05518 for ; Thu, 25 Jul 2002 10:21:11 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzav04618 for ; Thu, 25 Jul 2002 14:22:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzav03785; Thu, 25 Jul 2002 14:21:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzav07487 for mpls-outgoing; Thu, 25 Jul 2002 14:20:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzav07474 for ; Thu, 25 Jul 2002 14:20: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 QQmzav29847 for ; Thu, 25 Jul 2002 14:19:44 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzav23269 for ; Thu, 25 Jul 2002 14:19:43 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 QQmzav23265 for ; Thu, 25 Jul 2002 14:19: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 KAA05107 for ; Thu, 25 Jul 2002 10:19:42 -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 KAA02470 for ; Thu, 25 Jul 2002 10:19:42 -0400 (EDT) Message-ID: <3D40091F.70505@marconi.com> Date: Thu, 25 Jul 2002 10:20:15 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols References: <55E277B99171E041ABF5F4B1C6DDCA06500093@haritha.hclt.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vijayanand C - CTD, Chennai. wrote: > > I accept your argument. However, it finally comes down to saying that > RSVP-TE is not having more overhead than CR-LDP. Its taken a lot of add-ons > and workarounds to RSVP to bring to this level. Thats why the question of > complexity, implementation and maintenance issues related to software life > cycle reduction were raised. The fact that extensions are needed to make it scale doesn't make the protocol somehow worthless. You don't say BGP is trash because version 1 can't scale to the current size of the internet, do you? -- David From owner-mpls@UU.NET Thu Jul 25 10:41:42 2002 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 ESMTP id KAA06358 for ; Thu, 25 Jul 2002 10:41:41 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzaw07754 for ; Thu, 25 Jul 2002 14:42:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzaw07235; Thu, 25 Jul 2002 14:42:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzaw08838 for mpls-outgoing; Thu, 25 Jul 2002 14:42:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzaw08824 for ; Thu, 25 Jul 2002 14:42:06 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 QQmzaw12710 for ; Thu, 25 Jul 2002 14:41:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzaw21331 for ; Thu, 25 Jul 2002 14:41:39 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 QQmzaw21325 for ; Thu, 25 Jul 2002 14:41:39 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 KAA07327 for ; Thu, 25 Jul 2002 10:41: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 KAA08117 for ; Thu, 25 Jul 2002 10:41:35 -0400 (EDT) Message-ID: <3D400E3F.7080702@marconi.com> Date: Thu, 25 Jul 2002 10:42:07 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: initiating a discussion on mpls singaling protocols References: <413FBB0BA5AED1119122000083234B1A0329C607@alpha.igk.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bisewski, Radoslaw wrote: > But CR-LDP is an extension to the LDP protocol. While RSVP-TE has nothing in > common with LDP. After "eliminating" CR-LDP you will still have two MPLS > signalling protocols MPLS LDP and RSVP-TE. So? These two serve very different purposes and are not redundant. LDP automatically generates LSPs based on the routing table. RSVP-TE generates traffic-engineered LSPs based on requests from an ingress router. -- David From owner-mpls@UU.NET Thu Jul 25 11:06:34 2002 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 ESMTP id LAA07270 for ; Thu, 25 Jul 2002 11:06:34 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzay18226 for ; Thu, 25 Jul 2002 15:07:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzay17036; Thu, 25 Jul 2002 15:06:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzay01908 for mpls-outgoing; Thu, 25 Jul 2002 15:06:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzay01899 for ; Thu, 25 Jul 2002 15:06: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 QQmzay20840 for ; Thu, 25 Jul 2002 15:06:22 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzay27476 for ; Thu, 25 Jul 2002 15:06:22 GMT Received: from mail1.hd.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hdfdns01.hd.intel.com [192.52.58.10]) id QQmzay27467 for ; Thu, 25 Jul 2002 15:06:21 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by mail1.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g6PF6Lh03208 for ; Thu, 25 Jul 2002 15:06:21 GMT Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002072508053109198 ; Thu, 25 Jul 2002 08:05:31 -0700 Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 17:02:43 +0200 Message-ID: <413FBB0BA5AED1119122000083234B1A0329C612@alpha.igk.intel.com> From: "Bisewski, Radoslaw" To: IETF MPLS List Cc: "'David Charlap'" Subject: RE: initiating a discussion on mpls singaling protocols Date: Thu, 25 Jul 2002 17:02:38 +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 CR-LDP is functionaly equivalent to RSVP-TE. However the advantage of the CR-LDP over the RSVP-TE is that CR-LDP is an extension to the existing LDP protocol. LDP with CR-LDP extensions gives you one protocol implementation, which handles both automatic generation of LSP based on routing table and TE. On the other side ( LDP and RSVP-TE) you will have two different protocols serving two different purposes. I'm not sure if the second approach (LDP and RSVP-TE) is the optimal one. Radek > -----Original Message----- > From: David Charlap [mailto:david.charlap@marconi.com] > Sent: Thursday, July 25, 2002 4:42 PM > To: IETF MPLS List > Subject: Re: initiating a discussion on mpls singaling protocols > > > Bisewski, Radoslaw wrote: > > But CR-LDP is an extension to the LDP protocol. While > RSVP-TE has nothing in > > common with LDP. After "eliminating" CR-LDP you will still > have two MPLS > > signalling protocols MPLS LDP and RSVP-TE. > > So? These two serve very different purposes and are not redundant. > > LDP automatically generates LSPs based on the routing table. > > RSVP-TE generates traffic-engineered LSPs based on requests from an > ingress router. > > -- David > From owner-mpls@UU.NET Thu Jul 25 11:17:44 2002 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 ESMTP id LAA07803 for ; Thu, 25 Jul 2002 11:17:43 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzam18304; Thu, 25 Jul 2002 12:13:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzam11281 for mpls-outgoing; Thu, 25 Jul 2002 12:11:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzam11144 for ; Thu, 25 Jul 2002 12:10:56 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 QQmzam23036 for ; Thu, 25 Jul 2002 12:10:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzam14223 for ; Thu, 25 Jul 2002 12:10:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzam14195 for ; Thu, 25 Jul 2002 12:10:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA13630 for ; Thu, 25 Jul 2002 08:10:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20580 for mpls@uu.net; Thu, 25 Jul 2002 08:10:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzam10335 for ; Thu, 25 Jul 2002 12:08: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 QQmzam13935 for ; Thu, 25 Jul 2002 12:08:35 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzam13531 for ; Thu, 25 Jul 2002 12:08:34 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmzam13527 for ; Thu, 25 Jul 2002 12:08:34 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00009; Thu, 25 Jul 2002 08:07:28 -0400 (EDT) Message-Id: <200207251207.IAA00009@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-restart-03.txt Date: Thu, 25 Jul 2002 08:07:28 -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 : Graceful Restart Mechanism for LDP Author(s) : M. Leelanivas, Y. Rekhter, R. Aggarwal Filename : draft-ietf-mpls-ldp-restart-03.txt Pages : 11 Date : 24-Jul-02 This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switch Router's (LSR's) control plane restart, and specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter need to implement only a subset of the mechanism described in this document). The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related state to be preserved across the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-restart-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-restart-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-ldp-restart-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: <20020724143011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-restart-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-restart-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724143011.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jul 25 11:22:51 2002 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 ESMTP id LAA08110 for ; Thu, 25 Jul 2002 11:22:51 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzaz04452 for ; Thu, 25 Jul 2002 15:23:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzaz02522; Thu, 25 Jul 2002 15:22:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzaz04522 for mpls-outgoing; Thu, 25 Jul 2002 15:22:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzaz04517 for ; Thu, 25 Jul 2002 15:22: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 QQmzaz06372 for ; Thu, 25 Jul 2002 15:21:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzaz07136 for ; Thu, 25 Jul 2002 15:21:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzaz07110 for ; Thu, 25 Jul 2002 15:21:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA26329 for ; Thu, 25 Jul 2002 11:21:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA12358 for mpls@uu.net; Thu, 25 Jul 2002 11:21:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzaz04402 for ; Thu, 25 Jul 2002 15:19: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 QQmzaz13353 for ; Thu, 25 Jul 2002 15:18:17 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzaz29368 for ; Thu, 25 Jul 2002 15:18:17 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 QQmzaz29362 for ; Thu, 25 Jul 2002 15:18:16 GMT Received: (qmail 6176 invoked by uid 104); 25 Jul 2002 15:18:15 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4214. . Clean. Processed in 1.307374 secs); 25 Jul 2002 15:18:15 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 25 Jul 2002 15:18:14 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6PFIDc07555; Thu, 25 Jul 2002 08:18:13 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 08:18:14 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03767@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'David Charlap'" , IETF MPLS List Subject: RE: initiating a discussion on mpls singaling protocols Date: Thu, 25 Jul 2002 08:04:33 -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 I think a question to ask is, which one requires less software to implement: (LDP + CR-LDP) or (LDP + RSVP-TE)? -Shahram > -----Original Message----- > From: David Charlap [mailto:david.charlap@marconi.com] > Sent: Thursday, July 25, 2002 10:42 AM > To: IETF MPLS List > Subject: Re: initiating a discussion on mpls singaling protocols > > > Bisewski, Radoslaw wrote: > > But CR-LDP is an extension to the LDP protocol. While > RSVP-TE has nothing in > > common with LDP. After "eliminating" CR-LDP you will still > have two MPLS > > signalling protocols MPLS LDP and RSVP-TE. > > So? These two serve very different purposes and are not redundant. > > LDP automatically generates LSPs based on the routing table. > > RSVP-TE generates traffic-engineered LSPs based on requests from an > ingress router. > > -- David > > From owner-mpls@UU.NET Thu Jul 25 11:24:17 2002 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 ESMTP id LAA08152 for ; Thu, 25 Jul 2002 11:24:17 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzaz12187 for ; Thu, 25 Jul 2002 15:25:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzaz10580; Thu, 25 Jul 2002 15:24:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzaz04671 for mpls-outgoing; Thu, 25 Jul 2002 15:24:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzaz04616 for ; Thu, 25 Jul 2002 15:23: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 QQmzaz26204 for ; Thu, 25 Jul 2002 15:23:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzaz17703 for ; Thu, 25 Jul 2002 15:23:50 GMT Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQmzaz17697 for ; Thu, 25 Jul 2002 15:23:50 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA22418 for ; Thu, 25 Jul 2002 11:18:26 -0400 (EDT) Subject: RFC3209 Section 4.1.2 To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Thu, 25 Jul 2002 11:18:24 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 07/25/2002 11:18:27 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, In RFC3209 Section 4.21.2 non-support of the label object. 4.1.2. Non-support of the Label Object Under normal circumstances, a node should never receive a LABEL object in a Resv message unless it had included a LABEL_REQUEST object in the corresponding Path message. However, an RSVP router that does not recognize the LABEL object sends a ResvErr with the error code "Unknown object class" toward the receiver. This causes the reservation to fail. For example, A -------LSR--------B If the A sent out a Path msg without the LRO, LSR will forward this path msg to B, then if B sent a Resv msg with a Label object, will the LSR send the Resverr msg with the error code "Unknown object class" toward B? I do think so unless LSR is non-support the LABEL object. Please let me know if it is correct. Thanks in an advance. Julia From owner-mpls@UU.NET Thu Jul 25 11:41:51 2002 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 ESMTP id LAA09113 for ; Thu, 25 Jul 2002 11:41:51 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzba02486 for ; Thu, 25 Jul 2002 15:42:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzba01049; Thu, 25 Jul 2002 15:42:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzba06176 for mpls-outgoing; Thu, 25 Jul 2002 15:41:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzba06169 for ; Thu, 25 Jul 2002 15:41:32 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 QQmzba29877 for ; Thu, 25 Jul 2002 15:41:01 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzba19516 for ; Thu, 25 Jul 2002 15:41:01 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 QQmzba19506 for ; Thu, 25 Jul 2002 15:41: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 LAA13097 for ; Thu, 25 Jul 2002 11:40:59 -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 LAA22870 for ; Thu, 25 Jul 2002 11:40:57 -0400 (EDT) Message-ID: <3D401C2A.2010805@marconi.com> Date: Thu, 25 Jul 2002 11:41:30 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RFC3209 Section 4.1.2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > In RFC3209 Section 4.21.2 non-support of the label object. > > 4.1.2. Non-support of the Label Object > > Under normal circumstances, a node should never receive a LABEL > object in a Resv message unless it had included a LABEL_REQUEST > object in the corresponding Path message. However, an RSVP router > that does not recognize the LABEL object sends a ResvErr with the > error code "Unknown object class" toward the receiver. This causes > the reservation to fail. > > For example, > > A -------LSR--------B > > If the A sent out a Path msg without the LRO, LSR will forward this path > msg to B, then if B sent a Resv msg with a Label object, will the LSR send > the Resverr msg with the error code "Unknown object class" toward B? If A didn't send a LABEL_REQUEST, and B sent back a LABEL anyway, then B is broken. No LSP can possibly come up, because A wasn't trying to establish one in the first place. It is absolutely correct for A to generate a ResvErr. > I do think so unless LSR is non-support the LABEL object. If A generated a Path without a LABEL_REQUEST, then either it is not running RSVP-TE (meaning the LABEL object definitely isn't supported), or it is a hybrid router, running both classical RSVP and RSVP-TE at once. If it is such a hybrid, then the decision of what to do with an unexpected LABEL object is not specified. Personally, I think the ResvErr should still be generated, since that's what a non-TE router would do for the exact same session. -- David From owner-mpls@UU.NET Thu Jul 25 11:55:52 2002 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 ESMTP id LAA09665 for ; Thu, 25 Jul 2002 11:55:52 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbb10751 for ; Thu, 25 Jul 2002 15:56:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzbb06174; Thu, 25 Jul 2002 15:55:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzbb07141 for mpls-outgoing; Thu, 25 Jul 2002 15:55:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzbb07128 for ; Thu, 25 Jul 2002 15:55: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 QQmzbb16482 for ; Thu, 25 Jul 2002 15:54:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbb14309 for ; Thu, 25 Jul 2002 15:54:44 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmzbb14303 for ; Thu, 25 Jul 2002 15:54:44 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1TPX>; Thu, 25 Jul 2002 11:54:44 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B02267197@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: mpls@UU.NET Subject: Possible Conclusion to the Signaling debate? Date: Thu, 25 Jul 2002 11:54:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C233F3.97DC6C70" 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_01C233F3.97DC6C70 Content-Type: text/plain Unsurprisingly, the debate rages on. I suspect that we might be able to achieve consensus to making the following change to the MPLS WG charter: Change - 2. Advance the Proposed Standards developed by the MPLS WG to Draft Standard. This includes the LDP, CR-LDP, and RSVP-TE signaling specifications as well as the encapsulations. To - 2. Advance the Proposed Standards developed by the MPLS WG to Draft Standard. This includes the LDP and RSVP-TE signaling specifications as well as the encapsulations. Ongoing work related to CR-LDP will be targeted for Informational status. It seems highly unlikely that we will get consensus to do much more than this at this point. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 ------_=_NextPart_001_01C233F3.97DC6C70 Content-Type: text/html

Unsurprisingly, the debate rages on.

 

I suspect that we might be able to achieve consensus to making the

following change to the MPLS WG charter:

 

Change -

2. Advance the Proposed Standards developed by the MPLS WG

to Draft Standard. This includes the LDP, CR-LDP, and RSVP-TE

signaling specifications as well as the encapsulations.

 

To -

2. Advance the Proposed Standards developed by the MPLS WG

to Draft Standard. This includes the LDP and RSVP-TE

signaling specifications as well as the encapsulations. Ongoing work

related to CR-LDP will be targeted for Informational status.

 

It seems highly unlikely that we will get consensus to do much more

than this at this point.

 

 

Eric W. Gray

Systems Architect

Celox Networks, Inc.

egray@celoxnetworks.com

508 305 7214

 

------_=_NextPart_001_01C233F3.97DC6C70-- From owner-mpls@UU.NET Thu Jul 25 12:24:36 2002 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 ESMTP id MAA11009 for ; Thu, 25 Jul 2002 12:24:35 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbd06749 for ; Thu, 25 Jul 2002 16:25:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzbd02945; Thu, 25 Jul 2002 16:23:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzbd01720 for mpls-outgoing; Thu, 25 Jul 2002 16:23:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzbd01713 for ; Thu, 25 Jul 2002 16:23: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 QQmzbd13559 for ; Thu, 25 Jul 2002 16:22:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbd29224 for ; Thu, 25 Jul 2002 16:22:52 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmzbd29220 for ; Thu, 25 Jul 2002 16:22:51 GMT Received: from utfors.se ([195.58.105.96]) by blooper.utfors.se (Utfors AB) with ESMTP id g6PGMW5F026253; Thu, 25 Jul 2002 18:22:33 +0200 (MEST) Message-ID: <3D4025C8.5030901@utfors.se> Date: Thu, 25 Jul 2002 18:22:32 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Shahram Davari , MPLS wg Subject: Re: initiating a discussion on mpls singaling protocols References: <4B6D09F3B826D411A67300D0B706EFDEB03767@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Sharam, if we have 2 years (well 18 month, and will be a lot more before er see any cr-ldp deployment) experience of running rsvp-te + ldp, the SIZE of the software will be a ery minor problem ;) /Loa Shahram Davari wrote: > I think a question to ask is, which one requires less software to implement: > > (LDP + CR-LDP) or (LDP + RSVP-TE)? > > -Shahram > > >>-----Original Message----- >>From: David Charlap [mailto:david.charlap@marconi.com] >>Sent: Thursday, July 25, 2002 10:42 AM >>To: IETF MPLS List >>Subject: Re: initiating a discussion on mpls singaling protocols >> >> >>Bisewski, Radoslaw wrote: >> >>>But CR-LDP is an extension to the LDP protocol. While >>> >>RSVP-TE has nothing in >> >>>common with LDP. After "eliminating" CR-LDP you will still >>> >>have two MPLS >> >>>signalling protocols MPLS LDP and RSVP-TE. >>> >>So? These two serve very different purposes and are not redundant. >> >>LDP automatically generates LSPs based on the routing table. >> >>RSVP-TE generates traffic-engineered LSPs based on requests from an >>ingress router. >> >>-- David >> >> >> > -- 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 Jul 25 12:25:04 2002 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 ESMTP id MAA11044 for ; Thu, 25 Jul 2002 12:25:04 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbd07760 for ; Thu, 25 Jul 2002 16:26:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzbd04036; Thu, 25 Jul 2002 16:24:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzbd01741 for mpls-outgoing; Thu, 25 Jul 2002 16:23:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzbd01722 for ; Thu, 25 Jul 2002 16:23: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 QQmzbd14371 for ; Thu, 25 Jul 2002 16:21:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbd27789 for ; Thu, 25 Jul 2002 16:21:08 GMT Received: from mail1.paramanet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.paramanet.com [65.211.83.162]) id QQmzbd27773 for ; Thu, 25 Jul 2002 16:21:08 GMT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: initiating a discussion on mpls singaling protocols X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 25 Jul 2002 12:21:06 -0400 Message-ID: <9791A828507D5A418741095C3FD0DDE35EB740@indus> Thread-Topic: initiating a discussion on mpls singaling protocols Thread-Index: AcIz7YcbvXtQWyJ8Rj6uTbOMO9+gHAACXONA From: "Cheenu Srinivasan" To: "Bisewski, Radoslaw" , "IETF MPLS List" Cc: "David Charlap" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11044 > CR-LDP is functionaly equivalent to RSVP-TE. However the > advantage of the > CR-LDP over the RSVP-TE is that CR-LDP is an extension to the > existing LDP > protocol. > LDP with CR-LDP extensions gives you one protocol > implementation, which > handles both automatic generation of LSP based on routing > table and TE. On > the other side ( LDP and RSVP-TE) you will have two different > protocols > serving two different purposes. I'm not sure if the second > approach (LDP and > RSVP-TE) is the optimal one. Given that the choice in front of us is (1) LDP + RSVP-TE + CRLDP, or (2) LDP + RSVP-TE, this is a moot point. No one is discussing just LDP + CRLDP as a possibility. > > Radek > > > -----Original Message----- > > From: David Charlap [mailto:david.charlap@marconi.com] > > Sent: Thursday, July 25, 2002 4:42 PM > > To: IETF MPLS List > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > > > Bisewski, Radoslaw wrote: > > > But CR-LDP is an extension to the LDP protocol. While > > RSVP-TE has nothing in > > > common with LDP. After "eliminating" CR-LDP you will still > > have two MPLS > > > signalling protocols MPLS LDP and RSVP-TE. > > > > So? These two serve very different purposes and are not redundant. > > > > LDP automatically generates LSPs based on the routing table. > > > > RSVP-TE generates traffic-engineered LSPs based on requests from an > > ingress router. > > > > -- David > > > From owner-mpls@UU.NET Thu Jul 25 13:22:08 2002 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 ESMTP id NAA13374 for ; Thu, 25 Jul 2002 13:22:07 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbh18392 for ; Thu, 25 Jul 2002 17:23:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzbh16397; Thu, 25 Jul 2002 17:21:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzbh28759 for mpls-outgoing; Thu, 25 Jul 2002 17:21:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzbh28745 for ; Thu, 25 Jul 2002 17:21:16 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 QQmzbh22462 for ; Thu, 25 Jul 2002 17:21:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbh05000 for ; Thu, 25 Jul 2002 17:21:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzbh04992 for ; Thu, 25 Jul 2002 17:21:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA05569 for ; Thu, 25 Jul 2002 13:21:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA27406 for mpls@uu.net; Thu, 25 Jul 2002 13:21:05 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzbh28567 for ; Thu, 25 Jul 2002 17:19: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 QQmzbh16406 for ; Thu, 25 Jul 2002 17:18:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbh14032 for ; Thu, 25 Jul 2002 17:18:14 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 QQmzbh14013 for ; Thu, 25 Jul 2002 17:18:13 GMT Received: (qmail 28314 invoked by uid 104); 25 Jul 2002 17:18:12 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4214. . Clean. Processed in 2.463618 secs); 25 Jul 2002 17:18:12 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 25 Jul 2002 17:18:09 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6PHI8c02198 for ; Thu, 25 Jul 2002 10:18:08 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 10:18:09 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0376B@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: MPLS wg Subject: RE: initiating a discussion on mpls singaling protocols Date: Thu, 25 Jul 2002 10:18:07 -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 FYI, Following is an excerpt from an article published in the July 2002 IEEE communication magazine called "A proposal for an Alternative Standards Setting process": "... in the absense of a sound basis for the judgement and decision, the adoption of a particular technology by just one firm may encourage others to follow suit. If this happens, chances are that an inferior technology will be adopted, which may suit the initial adaptor but does not necessarily meet other entities' demands. They in turn, will then make their choices solely based on the initial adaptor's policy decision. Little if any experiment with alternative technologies or systems will occur, which will rapidly be discarded. The DOS operationg system was a case in point: one strong player, IBM, chose this system, which did not really represent the state of the art even at that time, and almost all others followed the suit. Obviously IBM gained significant profits from this developement- as did even more so, Microsoft..." -Shahram From owner-mpls@UU.NET Thu Jul 25 13:52:07 2002 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 ESMTP id NAA14605 for ; Thu, 25 Jul 2002 13:52:06 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbj11496 for ; Thu, 25 Jul 2002 17:53:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzbj09971; Thu, 25 Jul 2002 17:52:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzbj00879 for mpls-outgoing; Thu, 25 Jul 2002 17:52:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzbj00870 for ; Thu, 25 Jul 2002 17:52: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 QQmzbj20344 for ; Thu, 25 Jul 2002 17:48:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbj07495 for ; Thu, 25 Jul 2002 17:48:31 GMT 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 QQmzbj07483 for ; Thu, 25 Jul 2002 17:48:30 GMT Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6OItWL16763 for ; Wed, 24 Jul 2002 14:55:32 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 14:55:32 -0400 Message-ID: From: "Jothilingam, Vasudevan (Vasu)" To: Giles Heron , "Jothilingam, Vasudevan (Vasu)" Cc: IETF MPLS List Subject: RE: initiating a discussion on mpls singaling protocols Date: Wed, 24 Jul 2002 14:55:31 -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 Giles I understand that, I just wanted make sure.. So are we suggesting that Just have LDP. Well, I am not sure what will that buy us without TE. Vasu Jothilingam Lucent Technologies 1 Robbins Rd Westford, MA-01886 PH: (978)-952-7533 FAX: (978)-952-7977 -----Original Message----- From: Giles Heron [mailto:giles@packetexchange.net] Sent: Wednesday, July 24, 2002 3:49 PM To: Jothilingam, Vasudevan ""(Vasu) Cc: IETF MPLS List Subject: RE: initiating a discussion on mpls singaling protocols On Wed, 2002-07-24 at 18:22, Jothilingam, Vasudevan (Vasu) wrote: [snip] > I would like to say, yeah RSVP-TE is the way adn CR-LDP could be > informational RFC. > Being said that, there is lots of work going of L2 Transportation over MPLS, > using LDP. LDP != CR-LSP Giles > Well, even though I am not for that approach of using RSVP-TE and LDP ( two > big protocols ??) > for L2 transport, we need to see where that goes.. > > Thanks > Vasu > > > > > Vasu Jothilingam > Lucent Technologies > 1 Robbins Rd > Westford, MA-01886 > PH: (978)-952-7533 > FAX: (978)-952-7977 > > > -----Original Message----- > From: Ong, Lyndon [mailto:LyOng@ciena.com] > Sent: Wednesday, July 24, 2002 2:00 PM > To: 'David Charlap'; IETF MPLS List > Subject: RE: initiating a discussion on mpls singaling protocols > > > Hi David, > > Actually, SCTP is an alternative that supports message > passing and boundary preservation, plus other features > for reliability and detection of signaling path failure. > It was intended to relieve the application from having to > do continual verification of the signaling path and support > of a backup path. However, it was being defined at about > the same time as MPLS, so it was never considered as an > alternative for transport of MPLS signaling. > > A reliable UDP was one of the alternatives considered when doing > SCTP, but it still leaves the application to do testing > of the signaling path and message rerouting if that fails, > and does not have congestion control built in. > > Cheers, > > Lyndon > > -----Original Message----- > From: David Charlap [mailto:david.charlap@marconi.com] > Sent: Wednesday, July 24, 2002 7:45 AM > To: IETF MPLS List > Subject: Re: initiating a discussion on mpls singaling protocols > > As for the rest, TCP is not an appropriate transport for signaling > protocols in the first place. RSVP-TE, LDP and CR-LDP all use a > message-passing mechanism. They are not designed around streaming data. > Use of a streaming protocol means that the protocol has to deal with > the issue of detecting message boundaries and half-received messages. > > Unfortunately, there is no standard for anything resembling reliable UDP > - that would be ideal. > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Thu Jul 25 15:56:40 2002 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 ESMTP id PAA18999 for ; Thu, 25 Jul 2002 15:56:40 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbr08526 for ; Thu, 25 Jul 2002 19:57:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzbr07563; Thu, 25 Jul 2002 19:57:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzbr24314 for mpls-outgoing; Thu, 25 Jul 2002 19:56:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzbr24300 for ; Thu, 25 Jul 2002 19:56: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 QQmzbr00693 for ; Thu, 25 Jul 2002 19:56:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzbr07055 for ; Thu, 25 Jul 2002 19:56:12 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmzbr07049 for ; Thu, 25 Jul 2002 19:56:12 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6PJtx128121; Thu, 25 Jul 2002 15:55:59 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 15:55:58 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04B8858F@zcard031.ca.nortel.com> From: "David Allan" To: "Gray, Eric" , mpls@UU.NET Subject: RE: Possible Conclusion to the Signaling debate? Date: Thu, 25 Jul 2002 15:55:48 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Eric: As this more or less is all that has been suggested to date, I'm not sure how this qualifies as some minimal compromise that folks can agree to??? Modifying the November 01 milestone (intent to get stuff to draft standard) to only reference LDP, RSVP-TE and encapsulation IMHO would appear to be an achievable consensus. later Dave -----Original Message----- From: Gray, Eric [mailto:egray@celoxnetworks.com] Sent: Thursday, July 25, 2002 11:55 AM To: mpls@UU.NET Subject: Possible Conclusion to the Signaling debate? Unsurprisingly, the debate rages on. I suspect that we might be able to achieve consensus to making the following change to the MPLS WG charter: Change - 2. Advance the Proposed Standards developed by the MPLS WG to Draft Standard. This includes the LDP, CR-LDP, and RSVP-TE signaling specifications as well as the encapsulations. To - 2. Advance the Proposed Standards developed by the MPLS WG to Draft Standard. This includes the LDP and RSVP-TE signaling specifications as well as the encapsulations. Ongoing work related to CR-LDP will be targeted for Informational status. It seems highly unlikely that we will get consensus to do much more than this at this point. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 From owner-mpls@UU.NET Thu Jul 25 19:45:19 2002 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 ESMTP id TAA24946 for ; Thu, 25 Jul 2002 19:45:19 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzch13114 for ; Thu, 25 Jul 2002 23:46:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzch11597; Thu, 25 Jul 2002 23:45:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzch19307 for mpls-outgoing; Thu, 25 Jul 2002 23:45:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzch19302 for ; Thu, 25 Jul 2002 23:45: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 QQmzcg23976 for ; Thu, 25 Jul 2002 23:44:21 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzcg06969 for ; Thu, 25 Jul 2002 23:44:21 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmzcg06963 for ; Thu, 25 Jul 2002 23:44:20 GMT Received: from [213.208.123.104] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17XsHJ-0004qy-00; Fri, 26 Jul 2002 00:44:17 +0100 Subject: RE: initiating a discussion on mpls singaling protocols From: Giles Heron To: "Jothilingam, Vasudevan ""(Vasu)" Cc: IETF MPLS List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 26 Jul 2002 00:44:06 +0000 Message-Id: <1027644248.2234.3.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2002-07-24 at 18:55, Jothilingam, Vasudevan (Vasu) wrote: > Giles > > I understand that, I just wanted make sure.. > So are we suggesting that Just have LDP. Well, I am not sure what will that > buy us > without TE. No - I am suggesting that we need LDP, and that we also need a TE mechanism. Given that RSVP-TE is so widely deployed I think the opportunity for CR-LDP has passed. BTW - LDP actually buys us plenty without TE (only IMO of course - I don't want anyone to restart that "we need to kill LDP because it isn't compatible with MPLS OAM" thread!) However some SPs have TE requirements, so we need TE as well. Giles > Vasu Jothilingam > Lucent Technologies > 1 Robbins Rd > Westford, MA-01886 > PH: (978)-952-7533 > FAX: (978)-952-7977 > > > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Wednesday, July 24, 2002 3:49 PM > To: Jothilingam, Vasudevan ""(Vasu) > Cc: IETF MPLS List > Subject: RE: initiating a discussion on mpls singaling protocols > > > On Wed, 2002-07-24 at 18:22, Jothilingam, Vasudevan (Vasu) wrote: > [snip] > > I would like to say, yeah RSVP-TE is the way adn CR-LDP could be > > informational RFC. > > Being said that, there is lots of work going of L2 Transportation over > MPLS, > > using LDP. > > LDP != CR-LSP > > Giles > > > Well, even though I am not for that approach of using RSVP-TE and LDP ( > two > > big protocols ??) > > for L2 transport, we need to see where that goes.. > > > > Thanks > > Vasu > > > > > > > > > > Vasu Jothilingam > > Lucent Technologies > > 1 Robbins Rd > > Westford, MA-01886 > > PH: (978)-952-7533 > > FAX: (978)-952-7977 > > > > > > -----Original Message----- > > From: Ong, Lyndon [mailto:LyOng@ciena.com] > > Sent: Wednesday, July 24, 2002 2:00 PM > > To: 'David Charlap'; IETF MPLS List > > Subject: RE: initiating a discussion on mpls singaling protocols > > > > > > Hi David, > > > > Actually, SCTP is an alternative that supports message > > passing and boundary preservation, plus other features > > for reliability and detection of signaling path failure. > > It was intended to relieve the application from having to > > do continual verification of the signaling path and support > > of a backup path. However, it was being defined at about > > the same time as MPLS, so it was never considered as an > > alternative for transport of MPLS signaling. > > > > A reliable UDP was one of the alternatives considered when doing > > SCTP, but it still leaves the application to do testing > > of the signaling path and message rerouting if that fails, > > and does not have congestion control built in. > > > > Cheers, > > > > Lyndon > > > > -----Original Message----- > > From: David Charlap [mailto:david.charlap@marconi.com] > > Sent: Wednesday, July 24, 2002 7:45 AM > > To: IETF MPLS List > > Subject: Re: initiating a discussion on mpls singaling protocols > > > > As for the rest, TCP is not an appropriate transport for signaling > > protocols in the first place. RSVP-TE, LDP and CR-LDP all use a > > message-passing mechanism. They are not designed around streaming data. > > Use of a streaming protocol means that the protocol has to deal with > > the issue of detecting message boundaries and half-received messages. > > > > Unfortunately, there is no standard for anything resembling reliable UDP > > - that would be ideal. > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Fri Jul 26 00:13:24 2002 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 ESMTP id AAA29293 for ; Fri, 26 Jul 2002 00:13:24 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzcy17853 for ; Fri, 26 Jul 2002 04:14:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzcy16854; Fri, 26 Jul 2002 04:13:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzcy29429 for mpls-outgoing; Fri, 26 Jul 2002 04:13:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzcy29424 for ; Fri, 26 Jul 2002 04:13: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 QQmzcy04815 for ; Fri, 26 Jul 2002 04:13:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzcy21851 for ; Fri, 26 Jul 2002 04:13:26 GMT Received: from web20908.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20908.mail.yahoo.com [216.136.226.230]) id QQmzcy21847 for ; Fri, 26 Jul 2002 04:13:26 GMT Message-ID: <20020726041325.30327.qmail@web20908.mail.yahoo.com> Received: from [203.200.20.226] by web20908.mail.yahoo.com via HTTP; Thu, 25 Jul 2002 21:13:25 PDT Date: Thu, 25 Jul 2002 21:13:25 -0700 (PDT) From: Atul Gupta To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can any one please tell me the site where I can find the details on Nested GMPLS Signaling flow. Thanks. Atul ===== Atul Gupta Samsung Software __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-mpls@UU.NET Fri Jul 26 02:28:32 2002 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 ESMTP id CAA09876 for ; Fri, 26 Jul 2002 02:28:32 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzdh15874 for ; Fri, 26 Jul 2002 06:29:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzdh14664; Fri, 26 Jul 2002 06:28:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzdh23125 for mpls-outgoing; Fri, 26 Jul 2002 06:28:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzdh23120 for ; Fri, 26 Jul 2002 06:28: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 QQmzdh18356 for ; Fri, 26 Jul 2002 06:27:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzdh13504 for ; Fri, 26 Jul 2002 06:27:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzdh13494 for ; Fri, 26 Jul 2002 06:27:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA23061 for ; Fri, 26 Jul 2002 02:27:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA16800 for mpls@uu.net; Fri, 26 Jul 2002 02:27:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzdh22911 for ; Fri, 26 Jul 2002 06:25: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 QQmzdh12951 for ; Fri, 26 Jul 2002 06:25:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzdh12612 for ; Fri, 26 Jul 2002 06:25:23 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmzdh12596 for ; Fri, 26 Jul 2002 06:25:22 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 12:02:02 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06500C6A@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: David Charlap Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 26 Jul 2002 11:57:19 +0530 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 I am just saying is that adding so much complexity and code to RSVP has only made it to have 'not more overhead' than CR LDP. Regards, Vijay -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Thursday, July 25, 2002 7:50 PM To: mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols Vijayanand C - CTD, Chennai. wrote: > > I accept your argument. However, it finally comes down to saying that > RSVP-TE is not having more overhead than CR-LDP. Its taken a lot of add-ons > and workarounds to RSVP to bring to this level. Thats why the question of > complexity, implementation and maintenance issues related to software life > cycle reduction were raised. The fact that extensions are needed to make it scale doesn't make the protocol somehow worthless. You don't say BGP is trash because version 1 can't scale to the current size of the internet, do you? -- David From owner-mpls@UU.NET Fri Jul 26 05:30:45 2002 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 ESMTP id FAA12544 for ; Fri, 26 Jul 2002 05:30:45 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzdu13133 for ; Fri, 26 Jul 2002 09:31:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzdu12258; Fri, 26 Jul 2002 09:31:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzdu12541 for mpls-outgoing; Fri, 26 Jul 2002 09:31:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzdu12500 for ; Fri, 26 Jul 2002 09:31: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 QQmzdu02651 for ; Fri, 26 Jul 2002 09:30:37 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzdu27272 for ; Fri, 26 Jul 2002 09:30:37 GMT Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmzdu27261 for ; Fri, 26 Jul 2002 09:30:36 GMT Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 10:30:48 +0100 Message-ID: To: giles@packetexchange.net Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 26 Jul 2002 10:30:05 +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 Giles....my apologies, but I have to correct you here as I feel you are misrepresenting an important issue....please see below. regards, Neil > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: 26 July 2002 01:44 > To: Jothilingam, Vasudevan " "(Vasu) > Cc: IETF MPLS List > Subject: RE: initiating a discussion on mpls singaling protocols > > > On Wed, 2002-07-24 at 18:55, Jothilingam, Vasudevan (Vasu) wrote: > > Giles > > > > I understand that, I just wanted make sure.. > > So are we suggesting that Just have LDP. Well, I am not > sure what will that > > buy us > > without TE. > > No - I am suggesting that we need LDP, and that we also need a TE > mechanism. Given that RSVP-TE is so widely deployed I think the > opportunity for CR-LDP has passed. NH=> There is general LDP and targeted LDP....the former creates mp2p entities, but I believe your requirement is for the latter which creates p2p entities (though I assume you could use RSVP-TE for this too, so its not clear to me that LDP is a 'must' in your case.....but please correct me if this is not the case). > > BTW - LDP actually buys us plenty without TE (only IMO of course - I > don't want anyone to restart that "we need to kill LDP > because it isn't > compatible with MPLS OAM" thread!) However some SPs have TE > requirements, so we need TE as well. NH=> This is a misleading slant. The difficulty of fault-management of general LDP is simply 1 problem it raises......it is not the only one. The discussion/thread you are referring to was based on the question 'what networking problem does LDP solve that cannot be better solved by IPinIP (if an any-any mode is required) or p2p LSPs (if hard SLAs are required that are easily measureable/manageable)?'. However, I agree we don't want to open this up again. From owner-mpls@UU.NET Fri Jul 26 06:11:56 2002 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 ESMTP id GAA13119 for ; Fri, 26 Jul 2002 06:11:56 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzdw19991 for ; Fri, 26 Jul 2002 10:12:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzdw19255; Fri, 26 Jul 2002 10:12:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzdw07495 for mpls-outgoing; Fri, 26 Jul 2002 10:12:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzdw07443 for ; Fri, 26 Jul 2002 10:11:50 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 QQmzdw02818 for ; Fri, 26 Jul 2002 10:11:14 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzdw06640 for ; Fri, 26 Jul 2002 10:11:13 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmzdw06629 for ; Fri, 26 Jul 2002 10:11:13 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17Y23z-00064F-00; Fri, 26 Jul 2002 11:11:11 +0100 Subject: RE: initiating a discussion on mpls singaling protocols From: Giles Heron To: neil.2.harrison@bt.com Cc: mpls@UU.NET In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 26 Jul 2002 11:11:01 +0000 Message-Id: <1027681862.1501.24.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-07-26 at 09:30, neil.2.harrison@bt.com wrote: > Giles....my apologies, but I have to correct you here as I feel you are > misrepresenting an important issue....please see below. no misrepresentation intended. No correction required ;-) > regards, Neil > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: 26 July 2002 01:44 > > To: Jothilingam, Vasudevan " "(Vasu) > > Cc: IETF MPLS List > > Subject: RE: initiating a discussion on mpls singaling protocols > > > > > > On Wed, 2002-07-24 at 18:55, Jothilingam, Vasudevan (Vasu) wrote: > > > Giles > > > > > > I understand that, I just wanted make sure.. > > > So are we suggesting that Just have LDP. Well, I am not > > sure what will that > > > buy us > > > without TE. > > > > No - I am suggesting that we need LDP, and that we also need a TE > > mechanism. Given that RSVP-TE is so widely deployed I think the > > opportunity for CR-LDP has passed. > NH=> There is general LDP and targeted LDP....the former creates mp2p > entities, but I believe your requirement is for the latter which creates p2p > entities (though I assume you could use RSVP-TE for this too, so its not > clear to me that LDP is a 'must' in your case.....but please correct me if > this is not the case). [snipped to end] I want *both* mp2p LDP and targetted LDP. I want the former because it: 1) minimises the number of labels required in the core - O(N) rather than O(N squared). 2) enables auto-generation of full mesh connectivity (each PE advertises a single label for itself which reaches all other Ps and PEs). 3) is a good last resort even when RSVP-TE is being used (because of the above) I want the latter for L2 over MPLS. Sure the L2 stuff could be done with RSVP-TE (someone specified this in a draft at one stage I think?) but LDP seems a to me a much more natural way to advertise labels over a single hop than RSVP-TE. Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Fri Jul 26 07:40:23 2002 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 ESMTP id HAA14950 for ; Fri, 26 Jul 2002 07:40:23 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzec21628 for ; Fri, 26 Jul 2002 11:41:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzec19944; Fri, 26 Jul 2002 11:40:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzec05766 for mpls-outgoing; Fri, 26 Jul 2002 11:40:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzec05757 for ; Fri, 26 Jul 2002 11:39:57 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 QQmzec17226 for ; Fri, 26 Jul 2002 11:39:50 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzec23307 for ; Fri, 26 Jul 2002 11:39:49 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQmzec23303 for ; Fri, 26 Jul 2002 11:39:49 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA04647; Fri, 26 Jul 2002 13:39:14 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA16376; Fri, 26 Jul 2002 13:39:32 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2656.59) id ; Fri, 26 Jul 2002 13:39:28 +0200 Message-ID: From: Hummel Heinrich To: "'Bisewski, Radoslaw'" , "'Giles Heron'" , "'Jothilingam, Vasudevan \"\"(Vasu)'" Cc: "'IETF MPLS List'" Subject: AW: initiating a discussion on mpls singaling protocols Date: Fri, 26 Jul 2002 13:39:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Let me try to give an answer myself w.r.t my previously asked question by this following Table of current accomplishments: CR-LDP, RSVP-TE, LDP ------------------------------------------------------ 1) p2p LSP yes yes N/A 2) p2mp LSP no no no (or N/A?) 3) mp2p LSP no no yes 4) mp2mp LSP no no no (or N/A?) 5) p2p H-LSP no no N/A 6) mp2p H-LSP no no N/A 7) p2mp H-LSP no no no (or N/A?) 8) mp2mp H-LSP no no no (or N/A?) I think we should take this table into consideration which may effect the ongoing CR-LDP versus RSVP-TE discussion in one way or the other: We may say: There are too many NO's as to make a pro/con CR-LDP decision already now. And also: For economical reasons, let's turn only one NO into a YES p e r l i n e - by future work. Heinrich From owner-mpls@UU.NET Fri Jul 26 08:08:33 2002 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 ESMTP id IAA15556 for ; Fri, 26 Jul 2002 08:08:33 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzee09058 for ; Fri, 26 Jul 2002 12:09:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzee07385; Fri, 26 Jul 2002 12:08:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzee24835 for mpls-outgoing; Fri, 26 Jul 2002 12:08:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzee24746 for ; Fri, 26 Jul 2002 12:08: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 QQmzee12701 for ; Fri, 26 Jul 2002 12:07:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzee02081 for ; Fri, 26 Jul 2002 12:07:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzee02073 for ; Fri, 26 Jul 2002 12:07:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA03558 for ; Fri, 26 Jul 2002 08:07:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20959 for mpls@uu.net; Fri, 26 Jul 2002 08:07:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzee22591 for ; Fri, 26 Jul 2002 12:06: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 QQmzee13958 for ; Fri, 26 Jul 2002 12:05:43 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzee21301 for ; Fri, 26 Jul 2002 12:05:43 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmzee21297 for ; Fri, 26 Jul 2002 12:05:42 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 17:42:20 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA0651FAA2@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: David Charlap Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 26 Jul 2002 17:37:39 +0530 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 To add one more point here- by making extensions to RSVP it may have come to a state where it does nt have 'more overhead' than CR LDP. But should everyone bother to add so much of stuff to RSVP and then use it than using CR LDP. At present RSVP-TE may be leading in deployment due to kick start given by leaders and hence this may not be the right criteria to judge it, as Shahram also pointed out.The question is which protocol would benefit everyone in the long run in terms of performance,feature-extensibility(as Heinrich points out),scalability and other implementation/maintenance issues related to software life cycle reduction. Regards, Vijay -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Thursday, July 25, 2002 7:50 PM To: mpls@UU.NET Subject: Re: initiating a discussion on mpls singaling protocols Vijayanand C - CTD, Chennai. wrote: > > I accept your argument. However, it finally comes down to saying that > RSVP-TE is not having more overhead than CR-LDP. Its taken a lot of add-ons > and workarounds to RSVP to bring to this level. Thats why the question of > complexity, implementation and maintenance issues related to software life > cycle reduction were raised. The fact that extensions are needed to make it scale doesn't make the protocol somehow worthless. You don't say BGP is trash because version 1 can't scale to the current size of the internet, do you? -- David From owner-mpls@UU.NET Fri Jul 26 08:37:07 2002 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 ESMTP id IAA16810 for ; Fri, 26 Jul 2002 08:37:07 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzeg13874 for ; Fri, 26 Jul 2002 12:38:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzeg12787; Fri, 26 Jul 2002 12:37:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzeg02290 for mpls-outgoing; Fri, 26 Jul 2002 12:37:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzeg02285 for ; Fri, 26 Jul 2002 12:37:04 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 QQmzeg19732 for ; Fri, 26 Jul 2002 12:36:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzeg07450 for ; Fri, 26 Jul 2002 12:36:11 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmzeg07432 for ; Fri, 26 Jul 2002 12:36:10 GMT Received: from utfors.se ([195.58.105.124]) by blooper.utfors.se (Utfors AB) with ESMTP id g6QCZo5F007602; Fri, 26 Jul 2002 14:35:50 +0200 (MEST) Message-ID: <3D414226.7000500@utfors.se> Date: Fri, 26 Jul 2002 14:35:50 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: MPLS wg CC: George Swallow , Scott Bradner Subject: reformulated question on signaling protocols Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, after Avris mail and some other questions if there has been other examples of moving rfc from standards tracks to informational we have looked into the process. We've found that moving cr-ldp to informational is not covered by any process that is described for the IETF, also that we might cause serious problems or at least extra work for other organizations that have normative references to cr-ldp. Our suggestion is that cr-ldp will remain proposed standard, and that we reformulate the question from the mpls wg meeting as follows: "Should the mpls wg focus its efforts on a a signaling protocol for te applications on rsvp-te, and hence the wg effort with cr-ldp be discontinued? This would not involve any change in document status for cr-ldp, nor would it hinder continued individual contributions in the cr-ldp space. It would involve a change in the mpls wg charter to reflect this." Eric Gray has suggested such changes to the charter, please comment on the suggested changes. We would also like to say that we regard this as very important and will allocate time before we will try to call consensus, this is even more important since lots of people has been traveling back home from Japan and will have a mail back log to go through. Parts of Europe is on vacation and also needs time to come back to work and state with their opinions. We've placed a overview of how I see that people have stated their opinions so far at: http://62.119.0.68/~loa/tally.htm please let us know if we misunderstood. It is our assumption that people that supported moving to "informational" will support the current proposal also (that might not necessary be true - but we trust you'll will let us know. Also, if yo want me to correct/change/add your opinion let us know. /Loa and George -- 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 Jul 26 09:25:47 2002 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 ESMTP id JAA19036 for ; Fri, 26 Jul 2002 09:25:47 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzej10000 for ; Fri, 26 Jul 2002 13:26:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzej08898; Fri, 26 Jul 2002 13:26:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzej28713 for mpls-outgoing; Fri, 26 Jul 2002 13:25:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzej28706 for ; Fri, 26 Jul 2002 13:25:51 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 QQmzej26144 for ; Fri, 26 Jul 2002 13:24:58 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzej28677 for ; Fri, 26 Jul 2002 13:24:58 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmzej28673 for ; Fri, 26 Jul 2002 13:24:57 GMT Received: from utfors.se ([195.58.105.124]) by blooper.utfors.se (Utfors AB) with ESMTP id g6QDOs5F008088; Fri, 26 Jul 2002 15:24:54 +0200 (MEST) Message-ID: <3D414DA6.4080505@utfors.se> Date: Fri, 26 Jul 2002 15:24:54 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Hummel Heinrich , MPLS wg Subject: Re: AW: initiating a discussion on mpls singaling protocols References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Heinrich, this seems to show that cr-ldp and rsvp-te addresses one problem space and ldp another. Though I it is possible to create mp2p lsps with rsvp-te, just use the same spec and lsp's will merge. But, and more important, since there is no big difference and only one protocol is deployed, would that support the position on focusing on one protocol? /Loa Hummel Heinrich wrote: > Let me try to give an answer myself w.r.t my previously asked question by this following > > Table of current accomplishments: > > > CR-LDP, RSVP-TE, LDP > ------------------------------------------------------ > 1) p2p LSP yes yes N/A > 2) p2mp LSP no no no (or N/A?) > 3) mp2p LSP no no yes > 4) mp2mp LSP no no no (or N/A?) > 5) p2p H-LSP no no N/A > 6) mp2p H-LSP no no N/A > 7) p2mp H-LSP no no no (or N/A?) > 8) mp2mp H-LSP no no no (or N/A?) > > > I think we should take this table into consideration which may effect the ongoing CR-LDP versus RSVP-TE discussion > in one way or the other: > > We may say: There are too many NO's as to make a pro/con CR-LDP decision already now. > > And also: For economical reasons, let's turn only one NO into a YES p e r l i n e - by future work. > > Heinrich > -- 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 Jul 26 11:18:36 2002 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 ESMTP id LAA24820 for ; Fri, 26 Jul 2002 11:18:36 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzer00299 for ; Fri, 26 Jul 2002 15:19:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzer28437; Fri, 26 Jul 2002 15:18:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzer24512 for mpls-outgoing; Fri, 26 Jul 2002 15:18:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzer24507 for ; Fri, 26 Jul 2002 15:18: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 QQmzer05880 for ; Fri, 26 Jul 2002 15:17:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzer13667 for ; Fri, 26 Jul 2002 15:17:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzer13663 for ; Fri, 26 Jul 2002 15:17:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA14747 for ; Fri, 26 Jul 2002 11:17:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA10991 for mpls@uu.net; Fri, 26 Jul 2002 11:17:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzer23975 for ; Fri, 26 Jul 2002 15:15:39 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 QQmzer01477 for ; Fri, 26 Jul 2002 15:15:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzer26318 for ; Fri, 26 Jul 2002 15:15:03 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 QQmzer26292 for ; Fri, 26 Jul 2002 15:15:02 GMT Received: (qmail 8938 invoked by uid 104); 26 Jul 2002 15:15:02 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4214. . Clean. Processed in 0.488994 secs); 26 Jul 2002 15:15:02 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 26 Jul 2002 15:15:01 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6QFEtc29266; Fri, 26 Jul 2002 08:14:55 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 08:14:55 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03779@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Giles Heron'" , neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 26 Jul 2002 08:14:55 -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 Giles, > > I want *both* mp2p LDP and targetted LDP. > > I want the former because it: > > 1) minimises the number of labels required in the core - O(N) rather > than O(N squared). > I think Heinrich Hummel demonstrated in the Japan (as predicted by Dave Allan) that mp2p (LDP) results only ~15% less states than N^2 mesh. -Shahram From owner-mpls@UU.NET Fri Jul 26 11:45:03 2002 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 ESMTP id LAA26093 for ; Fri, 26 Jul 2002 11:45:03 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzet29518 for ; Fri, 26 Jul 2002 15:46:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzet28616; Fri, 26 Jul 2002 15:45:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzet25872 for mpls-outgoing; Fri, 26 Jul 2002 15:45:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzet25859 for ; Fri, 26 Jul 2002 15:45:07 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 QQmzes04573 for ; Fri, 26 Jul 2002 15:44:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzes14261 for ; Fri, 26 Jul 2002 15:44:09 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmzes14256 for ; Fri, 26 Jul 2002 15:44:09 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 17Y7G4-0007Fe-00; Fri, 26 Jul 2002 16:44:00 +0100 Subject: RE: initiating a discussion on mpls singaling protocols From: Giles Heron To: Shahram Davari Cc: neil.2.harrison@bt.com, mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03779@nt-exch-yow.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDEB03779@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 26 Jul 2002 16:43:49 +0000 Message-Id: <1027701829.1500.172.camel@gizpad> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-07-26 at 15:14, Shahram Davari wrote: > Giles, > > > > > I want *both* mp2p LDP and targetted LDP. > > > > I want the former because it: > > > > 1) minimises the number of labels required in the core - O(N) rather > > than O(N squared). > > > > I think Heinrich Hummel demonstrated in the Japan (as predicted by Dave Allan) > that mp2p (LDP) results only ~15% less states than N^2 mesh. I didn't see Henrich's demonstration :( From what I remember he relies on an assumption of per interface label state to achieve this (i.e. consider label L received on interface X and forwarded to interface Z to be a different state to label L received on interface Y and forwarded to interface Z). This assumption is correct for some MPLS P devices - but not AFAIK for those which are deployed most commonly. And of course the results will vary depending on the ratio of P to PE devices and the on the network topology... Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Fri Jul 26 11:55:37 2002 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 ESMTP id LAA26733 for ; Fri, 26 Jul 2002 11:55:36 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzet26591 for ; Fri, 26 Jul 2002 15:56:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzet25195; Fri, 26 Jul 2002 15:56:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzet26255 for mpls-outgoing; Fri, 26 Jul 2002 15:55:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzet26244 for ; Fri, 26 Jul 2002 15:55:26 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 QQmzet02482 for ; Fri, 26 Jul 2002 15:53:58 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzet22970 for ; Fri, 26 Jul 2002 15:53:57 GMT Received: from zcars04e.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmzet22965 for ; Fri, 26 Jul 2002 15:53:57 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6QFrNd27075; Fri, 26 Jul 2002 11:53:23 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 11:53:23 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04B8894E@zcard031.ca.nortel.com> From: "David Allan" To: Shahram Davari , "'Giles Heron'" , neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Fri, 26 Jul 2002 11:53:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C234BC.91A1F3E2" 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_01C234BC.91A1F3E2 Content-Type: text/plain; charset="iso-8859-1" Shahram: Wasn't 15% although the relationship was linear and not exponential, and where the argument got heated was comparing the LSH count vs. overall state. Unstated was if you used per-platform space the amount of state at the downstream LSRs of each LSH diminished significantly (although still more or less a linear relationship and probably forced use of liberal label retention so you didn't need to remember the list of folks who cared about your label, in other words your state issues got pushed upstream). Not that I want to start THAT discussion again..... ;-) cheers Dave > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Friday, July 26, 2002 11:15 AM > To: 'Giles Heron'; neil.2.harrison@bt.com > Cc: mpls@UU.NET > Subject: RE: initiating a discussion on mpls singaling protocols > > > Giles, > > > > > I want *both* mp2p LDP and targetted LDP. > > > > I want the former because it: > > > > 1) minimises the number of labels required in the core - O(N) rather > > than O(N squared). > > > > I think Heinrich Hummel demonstrated in the Japan (as > predicted by Dave Allan) > that mp2p (LDP) results only ~15% less states than N^2 mesh. > > -Shahram > > ------_=_NextPart_001_01C234BC.91A1F3E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: initiating a discussion on mpls singaling protocols

Shahram:

Wasn't 15% although the relationship was linear and = not exponential, and where the argument got heated was comparing the = LSH count vs. overall state. Unstated was if you used per-platform = space the amount of state at the downstream LSRs of each LSH diminished = significantly (although still more or less a linear relationship and = probably forced use of liberal label retention so you didn't need to = remember the list of folks who cared about your label, in other words = your state issues got pushed upstream).

Not that I want to start THAT discussion again..... = ;-)

cheers
Dave

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-= sierra.com]
> Sent: Friday, July 26, 2002 11:15 AM
> To: 'Giles Heron'; = neil.2.harrison@bt.com
> Cc: mpls@UU.NET
> Subject: RE: initiating a discussion on mpls = singaling protocols
>
>
> Giles,
>
> >
> > I want *both* mp2p LDP and targetted = LDP.
> >
> > I want the former because it:
> >
> > 1) minimises the number of labels required = in the core - O(N) rather
> > than O(N squared).
> >
>
> I think Heinrich Hummel demonstrated in the = Japan (as
> predicted by Dave Allan)
> that mp2p (LDP) results only ~15% less states = than N^2 mesh.
>
> -Shahram
>
>

------_=_NextPart_001_01C234BC.91A1F3E2-- From owner-mpls@UU.NET Fri Jul 26 12:33:05 2002 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 ESMTP id MAA28630 for ; Fri, 26 Jul 2002 12:33:04 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzew01243 for ; Fri, 26 Jul 2002 16:33:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzew29790; Fri, 26 Jul 2002 16:33:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzew21396 for mpls-outgoing; Fri, 26 Jul 2002 16:32:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzew21386 for ; Fri, 26 Jul 2002 16:32:50 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 QQmzew24412 for ; Fri, 26 Jul 2002 16:32:35 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 QQmzer02312 for ; Fri, 26 Jul 2002 15:20:38 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA18364; Fri, 26 Jul 2002 17:19:49 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA13439; Fri, 26 Jul 2002 17:20:08 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 17:20:02 +0200 Message-ID: From: Hummel Heinrich To: "'Loa Andersson'" , MPLS wg Subject: AW: AW: initiating a discussion on mpls singaling protocols Date: Fri, 26 Jul 2002 17:20:04 +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 MAA28630 As I see it: 1) p2p LSP: in DoD. Is done by RSVP-TE and CR-LDP. With and without Explicit Routing. 2) mp2p LSP: Is done by LDP using DU. But without QoS-/Policy-/Bandwidth- sensitiveness; Could be done by explicitly-routed /hop-by-hop routed merging LSPs, starting from the egress. Is not provided by CR-LDP. Is it provided by RSVP-TE (I doubt)? 3) p2mp LSP (for Multicast): from source towards receivers, upon leaf initiated join requests. Not even started. 4) mp2mp LSP (e.g for VPLS): Is not provided at all. Note: If n=2, it means the bi-directional LSP. Is not provided at all. Could be done by explictly routed /hop-by-hop routed LSPs starting from whichever edge node towards all the other edge nodes. None of the following is done: H-1) p2p H-LSP: see draft-hummel-mpls-hierarchical-lsp-01.txt H-2) mp2p H-LSP: see expired draft-hummel-ppvpn-tunnel-sequencing-00.txt H-3) p2mp H-LSP: for VPN multicast on top of the partial mesh LSPs,no blind traffic to non-interested receiver sites H-4) mp2mp H-LSP: for VPN multicast on top of the partial mesh LSPs, blind traffic is accepted I think any protocol can be extended to provide all of it. Syntax is just syntax. The question is: Is this or that extension against the basic philosphy of the particular protocol ? Does it make sense to come up with an explicit release procedure for let's say mp2mp H-LSP within RSVP-TE, if for some religious belief a similar procedure is out of discusion for p2p LSP ? Another thing is: The MPLS Forum's UNI PVC is clearly based on CR-LDP, and has been developped with the help of companies which are now against CR-LDP. Funny but true. I also believe that it is much much much better to work with just one protocol. However, if some extension is reasonable and valuable, it should not be rejected because of reasons, which were used to fight other protocols in former times. A word about LDP: IMO it may have some value as a routing=advertisement protocol. But for setting up LSPs??? I only see one single merge LSP per egress (there is no LSP-ID as to cater for more). However it makes a lot of sense to explicitly establish merging LSPs starting from the egress. Heinrich -----Ursprüngliche Nachricht----- Von: Loa Andersson [mailto:loa.andersson@utfors.se] Gesendet: Freitag, 26. Juli 2002 15:25 An: Hummel Heinrich; MPLS wg Betreff: Re: AW: initiating a discussion on mpls singaling protocols Heinrich, this seems to show that cr-ldp and rsvp-te addresses one problem space and ldp another. Though I it is possible to create mp2p lsps with rsvp-te, just use the same spec and lsp's will merge. But, and more important, since there is no big difference and only one protocol is deployed, would that support the position on focusing on one protocol? /Loa Hummel Heinrich wrote: > Let me try to give an answer myself w.r.t my previously asked question by this following > > Table of current accomplishments: > > > CR-LDP, RSVP-TE, LDP > ------------------------------------------------------ > 1) p2p LSP yes yes N/A > 2) p2mp LSP no no no (or N/A?) > 3) mp2p LSP no no yes > 4) mp2mp LSP no no no (or N/A?) > 5) p2p H-LSP no no N/A > 6) mp2p H-LSP no no N/A > 7) p2mp H-LSP no no no (or N/A?) > 8) mp2mp H-LSP no no no (or N/A?) > > > I think we should take this table into consideration which may effect the ongoing CR-LDP versus RSVP-TE discussion > in one way or the other: > > We may say: There are too many NO's as to make a pro/con CR-LDP decision already now. > > And also: For economical reasons, let's turn only one NO into a YES p e r l i n e - by future work. > > Heinrich > -- 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 Jul 26 13:25:16 2002 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 ESMTP id NAA01032 for ; Fri, 26 Jul 2002 13:25:16 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzez05904 for ; Fri, 26 Jul 2002 17:26:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzez04390; Fri, 26 Jul 2002 17:25:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzez17834 for mpls-outgoing; Fri, 26 Jul 2002 17:25:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzez17829 for ; Fri, 26 Jul 2002 17:25:12 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 QQmzez16521 for ; Fri, 26 Jul 2002 17:24:58 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzez03946 for ; Fri, 26 Jul 2002 17:24:58 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 QQmzez03942 for ; Fri, 26 Jul 2002 17:24:57 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 NAA17079 for ; Fri, 26 Jul 2002 13:24:55 -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 NAA26567 for ; Fri, 26 Jul 2002 13:24:56 -0400 (EDT) Message-ID: <3D41860D.6070506@marconi.com> Date: Fri, 26 Jul 2002 13:25:33 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: MPLS wg Subject: Re: AW: AW: initiating a discussion on mpls singaling protocols References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hummel Heinrich wrote: > As I see it: > > 1) p2p LSP: in DoD. Is done by RSVP-TE and CR-LDP. With and without Explicit Routing. > > 2) mp2p LSP: Is done by LDP using DU. But without QoS-/Policy-/Bandwidth- sensitiveness; > Could be done by explicitly-routed /hop-by-hop routed merging LSPs, starting from the egress. > Is not provided by CR-LDP. Is it provided by RSVP-TE (I doubt)? RSVP-TE does not support this. Being a TE protocol, each LSP originates from exactly one ingress node. It should be theoretically possible for multile LSPs to merge (share an outgoing label) if their QoS and explicit routes are identical for the remainder of the path to the egress, but this is more of an optimization than a feature that can be explicitly requested. I would hesitate to call the result of this a mp2p LSP. > 3) p2mp LSP (for Multicast): from source towards receivers, upon leaf initiated join requests. Not even started. RSVP-TE, as specified right now, can handle this. RFC 3209 does not specify a multicast version of the ERO (explicit route object), but I think the rest of the RFC can work fine for multicast, if the tunnel endpoint address is a multicast group address. A multicast ERO object has been defined in Saisho Yasukawa's draft, if you consider that a requirement for p2mp LSPs. I don't think there any implementations at this time, however. I don't know which (if any) vendors are currently working on this. > 4) mp2mp LSP (e.g for VPLS): Is not provided at all. Note: If n=2, it means the bi-directional LSP. Is not provided at all. > Could be done by explictly routed /hop-by-hop routed LSPs starting from whichever > edge node towards all the other edge nodes. I don't know of any work in this area. I think (but don't know enough to be sure) that LDP could theoretically work here, by using multicast group addresses as FECs. But I don't know the protocol well enough to know if there are other issues that might make it impossible. RSVP-TE, as currently defined, can't do this. Same reasons as mp2p (see above.) -- David From owner-mpls@UU.NET Fri Jul 26 14:04:11 2002 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 ESMTP id OAA02541 for ; Fri, 26 Jul 2002 14:04:11 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfc11492 for ; Fri, 26 Jul 2002 18:05:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzfc09832; Fri, 26 Jul 2002 18:04:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzfc02000 for mpls-outgoing; Fri, 26 Jul 2002 18:04:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzfc01854 for ; Fri, 26 Jul 2002 18:03: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 QQmzfc03731 for ; Fri, 26 Jul 2002 18:03:40 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfc09569 for ; Fri, 26 Jul 2002 18:03:39 GMT Received: from mailrelay.laurelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailrelay.laurelnetworks.com [63.94.127.11]) id QQmzfc09565 for ; Fri, 26 Jul 2002 18:03:39 GMT Received: from sherlock.laurelnetworks.com (sherlock.laurelnetworks.com [10.0.0.20]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id OAA05006; Fri, 26 Jul 2002 14:03:39 -0400 Received: by sherlock.laurelnetworks.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Jul 2002 14:03:39 -0400 Message-ID: <48E9CC6471FFD411B1AB00B0D079A42FE010BF@sherlock.laurelnetworks.com> From: Ganesh Murugesan To: "'mpls@UU.NET'" Cc: "'lberger@movaz.com'" , Ganesh Murugesan , "'swallow@cisco.com'" Subject: Question of RRO behavior Date: Fri, 26 Jul 2002 14:03:38 -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, Section 4.4.3 of RFC 3209 quotes that When the destination node of an RSVP session receives a Path message with an RRO, this indicates that the sender node needs route recording. The destination node initiates the RRO process by adding an RRO to Resv messages. The processing mirrors that of the Path messages. The only difference is that the RRO in a Resv message records the path information in the reverse direction. Since there is no MUST or SHOULD used to describe the behaviour of the destination on receiving a PATH message with an RRO, what is the expected behavior on the node receiving the RESV message from the destination if the destination decided not to place a RRO object in the RESV message. Should the Phop node drop the RESV message or forward the RESV message without an RRO, or add a RRO to the outgoing RESV message or send a ResvErr downstream (with what error code/value)? thanx ganesh From owner-mpls@UU.NET Fri Jul 26 14:57:53 2002 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 ESMTP id OAA04322 for ; Fri, 26 Jul 2002 14:57:53 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzff06646 for ; Fri, 26 Jul 2002 18:58:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzff04918; Fri, 26 Jul 2002 18:57:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzff20924 for mpls-outgoing; Fri, 26 Jul 2002 18:57:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzff20919 for ; Fri, 26 Jul 2002 18:57:34 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 QQmzff07517 for ; Fri, 26 Jul 2002 18:56:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzff27892 for ; Fri, 26 Jul 2002 18:56:47 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzff27888 for ; Fri, 26 Jul 2002 18:56:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01282 for ; Fri, 26 Jul 2002 14:56:46 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05509 for mpls@uu.net; Fri, 26 Jul 2002 14:56:46 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzff20484 for ; Fri, 26 Jul 2002 18:51:11 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 QQmzff16265 for ; Fri, 26 Jul 2002 18:51:02 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzff07036 for ; Fri, 26 Jul 2002 18:51:01 GMT Received: from caduceus.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr02.intel.com [192.55.52.25]) id QQmzff07027 for ; Fri, 26 Jul 2002 18:51:01 GMT Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24 00:39:04 root Exp $) with ESMTP id g6QImah15545 for ; Fri, 26 Jul 2002 18:48:36 GMT Received: from FMSMSX018.fm.intel.com (fmsmsx018.fm.intel.com [132.233.42.197]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with ESMTP id g6QImFi00833 for ; Fri, 26 Jul 2002 18:48:15 GMT Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3WZHRH6V>; Fri, 26 Jul 2002 11:50:59 -0700 Message-ID: From: "Feng, Mark" To: "'mpls@UU.NET'" Subject: RE: Question of RRO behavior Date: Fri, 26 Jul 2002 11:50:51 -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 IMO, the phop should accept the message. Keep in mind that, RRO is not mandatory. - Mark > -----Original Message----- > From: Ganesh Murugesan [mailto:ganesh@laurelnetworks.com] > Sent: Friday, July 26, 2002 11:04 AM > To: 'mpls@UU.NET' > Cc: 'lberger@movaz.com'; Ganesh Murugesan; 'swallow@cisco.com' > Subject: Question of RRO behavior > > > Hi, > > Section 4.4.3 of RFC 3209 quotes that > > When the destination node of an RSVP session receives a > Path message > with an RRO, this indicates that the sender node needs route > recording. The destination node initiates the RRO process > by adding > an RRO to Resv messages. The processing mirrors that of the Path > messages. The only difference is that the RRO in a Resv message > records the path information in the reverse direction. > > > Since there is no MUST or SHOULD used to describe the behaviour of > the destination on receiving a PATH message with an RRO, what is the > expected > behavior on the node receiving the RESV message from the destination > if the destination decided not to place a RRO object in the > RESV message. > > Should the Phop node drop the RESV message or forward the RESV message > without an RRO, or add a RRO to the outgoing RESV message or send a > ResvErr downstream (with what error code/value)? > > thanx > ganesh > From owner-mpls@UU.NET Fri Jul 26 15:12:33 2002 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 ESMTP id PAA04780 for ; Fri, 26 Jul 2002 15:12:32 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfg08669 for ; Fri, 26 Jul 2002 19:13:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzfg07489; Fri, 26 Jul 2002 19:13:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzfg14461 for mpls-outgoing; Fri, 26 Jul 2002 19:12:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzfg14456 for ; Fri, 26 Jul 2002 19:12: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 QQmzfg02357 for ; Fri, 26 Jul 2002 19:10:55 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfg06384 for ; Fri, 26 Jul 2002 19:10:55 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 QQmzfg06374 for ; Fri, 26 Jul 2002 19:10: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 PAA23798 for ; Fri, 26 Jul 2002 15:10:52 -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 PAA17833 for ; Fri, 26 Jul 2002 15:10:54 -0400 (EDT) Message-ID: <3D419EE3.70207@marconi.com> Date: Fri, 26 Jul 2002 15:11:31 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@UU.NET'" Subject: Re: Question of RRO behavior References: <48E9CC6471FFD411B1AB00B0D079A42FE010BF@sherlock.laurelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ganesh Murugesan wrote: > > Section 4.4.3 of RFC 3209 quotes that > > When the destination node of an RSVP session receives a Path message > with an RRO, this indicates that the sender node needs route > recording. The destination node initiates the RRO process by adding > an RRO to Resv messages. The processing mirrors that of the Path > messages. The only difference is that the RRO in a Resv message > records the path information in the reverse direction. > > > Since there is no MUST or SHOULD used to describe the behaviour of > the destination on receiving a PATH message with an RRO, what is the > expected > behavior on the node receiving the RESV message from the destination > if the destination decided not to place a RRO object in the RESV message. > > Should the Phop node drop the RESV message or forward the RESV message > without an RRO, or add a RRO to the outgoing RESV message or send a > ResvErr downstream (with what error code/value)? I would have it process the Resv message normally, and not add an RRO to it. You don't want to reject the Resv, because you don't want non-support of RRO to break LSP setup itself. You also don't want to add an RRO where none existed because the ingress node, upon reading that RRO, might think the LSP has ended on the Phop node instead of on the egress node, and it might take inappropriate action as a result. -- David From owner-mpls@UU.NET Fri Jul 26 15:32:16 2002 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 ESMTP id PAA05454 for ; Fri, 26 Jul 2002 15:32:15 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfi02890 for ; Fri, 26 Jul 2002 19:33:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzfi01774; Fri, 26 Jul 2002 19:32:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzfi16095 for mpls-outgoing; Fri, 26 Jul 2002 19:32:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzfi16090 for ; Fri, 26 Jul 2002 19:32: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 QQmzfi19684 for ; Fri, 26 Jul 2002 19:31:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfi23360 for ; Fri, 26 Jul 2002 19:31:42 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmzfi23354 for ; Fri, 26 Jul 2002 19:31:42 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1WZV>; Fri, 26 Jul 2002 15:31:42 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022671A3@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'David Charlap'" , "'mpls@UU.NET'" Subject: RE: Question of RRO behavior Date: Fri, 26 Jul 2002 15:31:41 -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 David, Can you give an example of an appropriate action that might be driven by RRO, even supposing it has been correctly constructed? My impression is that the RRO is intended to be used for information only and is not intended to incur some activity in response... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Friday, July 26, 2002 3:12 PM To: 'mpls@UU.NET' Subject: Re: Question of RRO behavior Ganesh Murugesan wrote: > > Section 4.4.3 of RFC 3209 quotes that > > When the destination node of an RSVP session receives a Path message > with an RRO, this indicates that the sender node needs route > recording. The destination node initiates the RRO process by adding > an RRO to Resv messages. The processing mirrors that of the Path > messages. The only difference is that the RRO in a Resv message > records the path information in the reverse direction. > > > Since there is no MUST or SHOULD used to describe the behaviour of > the destination on receiving a PATH message with an RRO, what is the > expected > behavior on the node receiving the RESV message from the destination > if the destination decided not to place a RRO object in the RESV message. > > Should the Phop node drop the RESV message or forward the RESV message > without an RRO, or add a RRO to the outgoing RESV message or send a > ResvErr downstream (with what error code/value)? I would have it process the Resv message normally, and not add an RRO to it. You don't want to reject the Resv, because you don't want non-support of RRO to break LSP setup itself. You also don't want to add an RRO where none existed because the ingress node, upon reading that RRO, might think the LSP has ended on the Phop node instead of on the egress node, and it might take inappropriate action as a result. -- David From owner-mpls@UU.NET Fri Jul 26 15:37:44 2002 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 ESMTP id PAA05628 for ; Fri, 26 Jul 2002 15:37:44 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfi28187 for ; Fri, 26 Jul 2002 19:38:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzfi26882; Fri, 26 Jul 2002 19:38:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzfi16340 for mpls-outgoing; Fri, 26 Jul 2002 19:37:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzfi16335 for ; Fri, 26 Jul 2002 19:37:36 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 QQmzfi09086 for ; Fri, 26 Jul 2002 19:37:28 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfi29139 for ; Fri, 26 Jul 2002 19:37:28 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 QQmzfi29127 for ; Fri, 26 Jul 2002 19:37:28 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 PAA25521 for ; Fri, 26 Jul 2002 15:37:25 -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 PAA23117 for ; Fri, 26 Jul 2002 15:37:27 -0400 (EDT) Message-ID: <3D41A51C.7080208@marconi.com> Date: Fri, 26 Jul 2002 15:38:04 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@UU.NET'" Subject: Re: Question of RRO behavior References: <1117F7D44159934FB116E36F4ABF221B022671A3@celox-ma1-ems1.celoxnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gray, Eric wrote: > > Can you give an example of an appropriate action > that might be driven by RRO, even supposing it has been > correctly constructed? My impression is that the RRO > is intended to be used for information only and is not > intended to incur some activity in response... It may be used to verify that the LSP is actually following the route specified by an ERO. It may also be used as a part of route pinning - generate a Path without ERO, or with a loose ERO, and then compose a strict ERO from the RRO in order to pin the route in place. -- David From owner-mpls@UU.NET Fri Jul 26 16:28:28 2002 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 ESMTP id QAA07469 for ; Fri, 26 Jul 2002 16:28:28 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfl10342 for ; Fri, 26 Jul 2002 20:29:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzfl08799; Fri, 26 Jul 2002 20:28:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzfl12446 for mpls-outgoing; Fri, 26 Jul 2002 20:28:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzfl12441 for ; Fri, 26 Jul 2002 20:28:25 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 QQmzfl18566 for ; Fri, 26 Jul 2002 20:26:40 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfl28890 for ; Fri, 26 Jul 2002 20:26:39 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmzfl28884 for ; Fri, 26 Jul 2002 20:26:39 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1W93>; Fri, 26 Jul 2002 16:26:39 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022671A4@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'David Charlap'" , "'mpls@UU.NET'" Subject: RE: Question of RRO behavior Date: Fri, 26 Jul 2002 16:26:39 -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 David, Okay, thanks for the refresh on pinning. :-) It might be a bad idea for the ingress to infer from an RRO that an LSP did not follow the path given in the ERO. This is not being 'liberal in what you receive' since the specification doesn't say that the address used in the RRO MUST be the same one that was provided in the ERO for the same Path message (it does give guidelines as to what address SHOULD be used, and it RECOMMENDS consistent use from Path message to Path message but, it if it also says that the address MUST be the same as the one contained in the ERO, I didn't see it). I think the least that an LSR should do, if it is actually checking to see if it is expecting an RRO when it does not get one, is record this event at least once so that the operator might be able to discover that an inconsistency exists. I suspect that most LSRs are not doing this check, so the absence of an RRO in a Resv message will mean that it will not include an RRO in a Path message sent upstream - automagically. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Friday, July 26, 2002 3:38 PM To: 'mpls@UU.NET' Subject: Re: Question of RRO behavior Gray, Eric wrote: > > Can you give an example of an appropriate action > that might be driven by RRO, even supposing it has been > correctly constructed? My impression is that the RRO > is intended to be used for information only and is not > intended to incur some activity in response... It may be used to verify that the LSP is actually following the route specified by an ERO. It may also be used as a part of route pinning - generate a Path without ERO, or with a loose ERO, and then compose a strict ERO from the RRO in order to pin the route in place. -- David From owner-mpls@UU.NET Fri Jul 26 16:34:27 2002 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 ESMTP id QAA07733 for ; Fri, 26 Jul 2002 16:34:26 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfm04787 for ; Fri, 26 Jul 2002 20:35:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzfm03091; Fri, 26 Jul 2002 20:34:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzfm12777 for mpls-outgoing; Fri, 26 Jul 2002 20:34:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzfm12770 for ; Fri, 26 Jul 2002 20:34:23 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 QQmzfm12684 for ; Fri, 26 Jul 2002 20:34:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzfm02589 for ; Fri, 26 Jul 2002 20:34:04 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmzfm02577 for ; Fri, 26 Jul 2002 20:34:04 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K1W02>; Fri, 26 Jul 2002 16:34:04 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022671A5@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'David Charlap'" , "'mpls@UU.NET'" Subject: RE: Question of RRO behavior Date: Fri, 26 Jul 2002 16:34:03 -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 ... Path message sent upstream - automagically. ^^^^ Should be Resv... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Friday, July 26, 2002 3:38 PM To: 'mpls@UU.NET' Subject: Re: Question of RRO behavior Gray, Eric wrote: > > Can you give an example of an appropriate action > that might be driven by RRO, even supposing it has been > correctly constructed? My impression is that the RRO > is intended to be used for information only and is not > intended to incur some activity in response... It may be used to verify that the LSP is actually following the route specified by an ERO. It may also be used as a part of route pinning - generate a Path without ERO, or with a loose ERO, and then compose a strict ERO from the RRO in order to pin the route in place. -- David From owner-mpls@UU.NET Fri Jul 26 17:33:17 2002 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 ESMTP id RAA09882 for ; Fri, 26 Jul 2002 17:33:17 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzet00912; Fri, 26 Jul 2002 15:58:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzet26339 for mpls-outgoing; Fri, 26 Jul 2002 15:57:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzet26311 for ; Fri, 26 Jul 2002 15:57: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 QQmzet26109 for ; Fri, 26 Jul 2002 15:57:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzet19565 for ; Fri, 26 Jul 2002 15:57:07 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmzet19555 for ; Fri, 26 Jul 2002 15:57:06 GMT Received: from utfors.se ([195.58.105.124]) by blooper.utfors.se (Utfors AB) with ESMTP id g6QFv35F009302; Fri, 26 Jul 2002 17:57:03 +0200 (MEST) Message-ID: <3D41714F.5020806@utfors.se> Date: Fri, 26 Jul 2002 17:57:03 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Hummel Heinrich CC: MPLS wg Subject: Re: AW: AW: initiating a discussion on mpls singaling protocols References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Heinrich, see inline Hummel Heinrich wrote: > As I see it: > > 1) p2p LSP: in DoD. Is done by RSVP-TE and CR-LDP. With and without Explicit Routing. > > 2) mp2p LSP: Is done by LDP using DU. But without QoS-/Policy-/Bandwidth- sensitiveness; > Could be done by explicitly-routed /hop-by-hop routed merging LSPs, starting from the egress. > Is not provided by CR-LDP. Is it provided by RSVP-TE (I doubt)? If you have a the same spec's this is a request to merge, in fact you have to make sure that you don't have the same spec's if you don't want to merge. Maybe one of the rsvp-te authors could correct me if i'm wrong. in some scenarios life would be easier if i were ;) > > 3) p2mp LSP (for Multicast): from source towards receivers, upon leaf initiated join requests. Not even started. there were a multicast proposal in yokohama, we said that it was premature to have an opinion on that, since the multicast fw were just through the iesg review and that we need a discussion on how much of this we want to do. there is alos early work on mpls multicast based on ldp (not cr-ldp) /Loa > > > 4) mp2mp LSP (e.g for VPLS): Is not provided at all. Note: If n=2, it means the bi-directional LSP. Is not provided at all. > Could be done by explictly routed /hop-by-hop routed LSPs starting from whichever > edge node towards all the other edge nodes. > > None of the following is done: > H-1) p2p H-LSP: see draft-hummel-mpls-hierarchical-lsp-01.txt > H-2) mp2p H-LSP: see expired draft-hummel-ppvpn-tunnel-sequencing-00.txt > H-3) p2mp H-LSP: for VPN multicast on top of the partial mesh LSPs,no blind traffic to non-interested receiver sites > H-4) mp2mp H-LSP: for VPN multicast on top of the partial mesh LSPs, blind traffic is accepted > > I think any protocol can be extended to provide all of it. Syntax is just syntax. > > The question is: > Is this or that extension against the basic philosphy of the particular protocol ? > Does it make sense to come up with an explicit release procedure for let's say mp2mp H-LSP within RSVP-TE, if > for some religious belief a similar procedure is out of discusion for p2p LSP ? > > Another thing is: The MPLS Forum's UNI PVC is clearly based on CR-LDP, and has been developped with the help of companies which are now against CR-LDP. Funny but true. > > I also believe that it is much much much better to work with just one protocol. However, if some > extension is reasonable and valuable, it should not be rejected because of reasons, which were used to > fight other protocols in former times. > > A word about LDP: > IMO it may have some value as a routing=advertisement protocol. But for setting up LSPs??? I only see one single > merge LSP per egress (there is no LSP-ID as to cater for more). However it makes a lot of sense to explicitly establish merging LSPs starting from the egress. > > > Heinrich > > > > > -----Ursprüngliche Nachricht----- > Von: Loa Andersson [mailto:loa.andersson@utfors.se] > Gesendet: Freitag, 26. Juli 2002 15:25 > An: Hummel Heinrich; MPLS wg > Betreff: Re: AW: initiating a discussion on mpls singaling protocols > > > Heinrich, > > this seems to show that cr-ldp and rsvp-te addresses one problem > space and ldp another. Though I it is possible to create mp2p > lsps with rsvp-te, just use the same spec and lsp's will merge. > > But, and more important, since there is no big difference and only > one protocol is deployed, would that support the position on focusing > on one protocol? > > /Loa > > Hummel Heinrich wrote: > > >>Let me try to give an answer myself w.r.t my previously asked question by this following >> >>Table of current accomplishments: >> >> >> CR-LDP, RSVP-TE, LDP >>------------------------------------------------------ >>1) p2p LSP yes yes N/A >>2) p2mp LSP no no no (or N/A?) >>3) mp2p LSP no no yes >>4) mp2mp LSP no no no (or N/A?) >>5) p2p H-LSP no no N/A >>6) mp2p H-LSP no no N/A >>7) p2mp H-LSP no no no (or N/A?) >>8) mp2mp H-LSP no no no (or N/A?) >> >> >>I think we should take this table into consideration which may effect the ongoing CR-LDP versus RSVP-TE discussion >>in one way or the other: >> >>We may say: There are too many NO's as to make a pro/con CR-LDP decision already now. >> >>And also: For economical reasons, let's turn only one NO into a YES p e r l i n e - by future work. >> >>Heinrich >> >> > > -- 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 Sat Jul 27 16:10:21 2002 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 ESMTP id QAA07001 for ; Sat, 27 Jul 2002 16:10:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzjc04330 for ; Sat, 27 Jul 2002 20:11:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzjc03248; Sat, 27 Jul 2002 20:10:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzjc28409 for mpls-outgoing; Sat, 27 Jul 2002 20:10:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzjc28267 for ; Sat, 27 Jul 2002 20:09:57 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 QQmzjc14325 for ; Sat, 27 Jul 2002 20:08:22 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzjc02251 for ; Sat, 27 Jul 2002 20:08:21 GMT Received: from smtp6.mindspring.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQmzjc02245 for ; Sat, 27 Jul 2002 20:08:21 GMT Received: from user-11fab7h.dsl.mindspring.com ([66.245.44.241] helo=METANOIA) by smtp6.mindspring.com with smtp (Exim 3.33 #1) id 17YXrP-0007Bl-00; Sat, 27 Jul 2002 16:08:19 -0400 Reply-To: From: "Vishal Sharma" To: "Shahram Davari" , "'mpls@uu.net'" Cc: "Fiffi Hellstrand" Subject: RE: draft-ietf-mpls-recovery-frmwrk-04.txt Date: Sat, 27 Jul 2002 16:09:53 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03721@nt-exch-yow.pmc-sierra.bc.ca> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Shahram, The latest version of the MPLS Recovery framework has been submitted to the IETF drafts directory: draft-ietf-mpls-recovery-frmwrk-06.txt, and should be available next week. It addresses the concern you raised below, by rewording the description in (now) Section 4.6, and allowing for notification to proceed in either direction. This was done by introducing a point of repair (POR) LSR, which could be a PSL or a PML, depending on the recovery scheme deployed. I believe this will satisfactorily address your concern. We'd like to thank Dave Allan for suggesting the alternative wording, and the POR definition. Thanks Dave! -Vishal & Fiffi (and co-authors) > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram > Davari > Sent: Thursday, June 27, 2002 4:28 PM > To: 'mpls@uu.net' > Subject: RE: draft-ietf-mpls-recovery-frmwrk-04.txt > > > Hi, > > Why is that in section 3.6. (Fault Notification), the only > notification method mentioned is sending FIS upstream, > hop-by-hop. Although this is possible but a simpler and more > conventional method is to send the FIS to the PML and let the PML > inform the PSL. Is this type of notification excluded? If so why, > and if not could the authors please add it to the text. > > > Thanks, > Shahram > From owner-mpls@UU.NET Mon Jul 29 04:07:47 2002 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 ESMTP id EAA20642 for ; Mon, 29 Jul 2002 04:07:46 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzoq19336 for ; Mon, 29 Jul 2002 08:08:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzoq12592; Mon, 29 Jul 2002 08:05:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzoq14340 for mpls-outgoing; Mon, 29 Jul 2002 08:04:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzoq14075 for ; Mon, 29 Jul 2002 08: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 QQmzoq11159 for ; Mon, 29 Jul 2002 08:03:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzoq14764 for ; Mon, 29 Jul 2002 08:03:53 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 QQmzoq14760 for ; Mon, 29 Jul 2002 08:03:53 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA11409; Mon, 29 Jul 2002 10:03:24 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA10434; Mon, 29 Jul 2002 10:03:41 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 10:03:32 +0200 Message-ID: From: Hummel Heinrich To: "'Loa Andersson'" Cc: MPLS wg Subject: AW: AW: AW: initiating a discussion on mpls singaling protocols Date: Mon, 29 Jul 2002 10:03:31 +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 Loa, Quite some time ago (in Oslo)I presented a solution how to provide explicit routing information w.r.t. a tree route and I would be pleased to revive this work if it is oked. By chance, it was using CR-LDP syntax and not RSVP-TE syntax, but this can be changed.BTW: I neither like the message names PATH/RESERVE nor LABEL_REQUEST/LABEL_MAPPING but rather LSP_SETUP/LSP_SETUP_ACK.But this is my humble opinion only. It started with a simple algorithm which inversed the Dijkstra tree representation (where each node points to another node one hop closer to the root) to a sequence of "("- TLVs, ")"-TLVs and ER-TLVs, where the bracket-TLVs shaped the tree and where the ER-TLVs represented non-branching sections within the tree. The over-all "TREE ROUTE TLV" might also contain new Node-Info-TLVs,which, properly positioned, would carry specific information (like FEC) to the right individual nodes on the tree.And finally,by pairs of (new) Nodes-Info-Begin-TLV and Nodes-Info-End-TLV specific information could be sent to clusters of nodes within the tree, e.g. how much bandwidth shall be reserved by each node for the respective links of some non-branching section of a merging LSP. I also showed how each node must handle the received "TREE ROUTE TLV", as to recognize what information it has to evaluate by itself, and which part of the received TLV has to be forwarded along which child-link. The handling of this TREE ROUTE TLV, would be beneficial to mp2p- LSPs, mp2mp- LSPs and p2mp-LSPs, be they elementary LSPs or Hierarchical LSPs. In all these cases, the message would start at some root node and progress towards multiple leaf nodes. It is just this simple, and to hell with discussion "what is hereby DoD versus DU" :-) Needless to say: If the initial Dijkstra tree had been sensitive to QoS/Bandwidth-availability/Policy, then the inverse representation,i.e. the TREE ROUTE TLV representation would be as well. Loa, if you ok so, I can sketch the algorithm for inversing the Dijkstra tree representation already in the next email and also submit a revived draft. Heinrich ------------------ see inline Hummel Heinrich wrote: > As I see it: > > 1) p2p LSP: in DoD. Is done by RSVP-TE and CR-LDP. With and without Explicit Routing. > > 2) mp2p LSP: Is done by LDP using DU. But without QoS-/Policy-/Bandwidth- sensitiveness; > Could be done by explicitly-routed /hop-by-hop routed merging LSPs, starting from the egress. > Is not provided by CR-LDP. Is it provided by RSVP-TE (I doubt)? If you have a the same spec's this is a request to merge, in fact you have to make sure that you don't have the same spec's if you don't want to merge. Maybe one of the rsvp-te authors could correct me if i'm wrong. in some scenarios life would be easier if i were ;) > > 3) p2mp LSP (for Multicast): from source towards receivers, upon leaf initiated join requests. Not even started. there were a multicast proposal in yokohama, we said that it was premature to have an opinion on that, since the multicast fw were just through the iesg review and that we need a discussion on how much of this we want to do. there is alos early work on mpls multicast based on ldp (not cr-ldp) /Loa > > > 4) mp2mp LSP (e.g for VPLS): Is not provided at all. Note: If n=2, it means the bi-directional LSP. Is not provided at all. > Could be done by explictly routed /hop-by-hop routed LSPs starting from whichever > edge node towards all the other edge nodes. > > None of the following is done: > H-1) p2p H-LSP: see draft-hummel-mpls-hierarchical-lsp-01.txt > H-2) mp2p H-LSP: see expired draft-hummel-ppvpn-tunnel-sequencing-00.txt > H-3) p2mp H-LSP: for VPN multicast on top of the partial mesh LSPs,no blind traffic to non-interested receiver sites > H-4) mp2mp H-LSP: for VPN multicast on top of the partial mesh LSPs, blind traffic is accepted > > I think any protocol can be extended to provide all of it. Syntax is just syntax. > > The question is: > Is this or that extension against the basic philosphy of the particular protocol ? > Does it make sense to come up with an explicit release procedure for let's say mp2mp H-LSP within RSVP-TE, if > for some religious belief a similar procedure is out of discusion for p2p LSP ? > > Another thing is: The MPLS Forum's UNI PVC is clearly based on CR-LDP, and has been developped with the help of companies which are now against CR-LDP. Funny but true. > > I also believe that it is much much much better to work with just one protocol. However, if some > extension is reasonable and valuable, it should not be rejected because of reasons, which were used to > fight other protocols in former times. > > A word about LDP: > IMO it may have some value as a routing=advertisement protocol. But for setting up LSPs??? I only see one single > merge LSP per egress (there is no LSP-ID as to cater for more). However it makes a lot of sense to explicitly establish merging LSPs starting from the egress. > > > Heinrich > > > > > -----Ursprüngliche Nachricht----- > Von: Loa Andersson [mailto:loa.andersson@utfors.se] > Gesendet: Freitag, 26. Juli 2002 15:25 > An: Hummel Heinrich; MPLS wg > Betreff: Re: AW: initiating a discussion on mpls singaling protocols > > > Heinrich, > > this seems to show that cr-ldp and rsvp-te addresses one problem > space and ldp another. Though I it is possible to create mp2p > lsps with rsvp-te, just use the same spec and lsp's will merge. > > But, and more important, since there is no big difference and only > one protocol is deployed, would that support the position on focusing > on one protocol? > > /Loa > > Hummel Heinrich wrote: > > >>Let me try to give an answer myself w.r.t my previously asked question by this following >> >>Table of current accomplishments: >> >> >> CR-LDP, RSVP-TE, LDP >>------------------------------------------------------ >>1) p2p LSP yes yes N/A >>2) p2mp LSP no no no (or N/A?) >>3) mp2p LSP no no yes >>4) mp2mp LSP no no no (or N/A?) >>5) p2p H-LSP no no N/A >>6) mp2p H-LSP no no N/A >>7) p2mp H-LSP no no no (or N/A?) >>8) mp2mp H-LSP no no no (or N/A?) >> >> >>I think we should take this table into consideration which may effect the ongoing CR-LDP versus RSVP-TE discussion >>in one way or the other: >> >>We may say: There are too many NO's as to make a pro/con CR-LDP decision already now. >> >>And also: For economical reasons, let's turn only one NO into a YES p e r l i n e - by future work. >> >>Heinrich >> >> > > -- 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 Jul 29 10:07:22 2002 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 ESMTP id KAA00490 for ; Mon, 29 Jul 2002 10:07:22 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpo14814 for ; Mon, 29 Jul 2002 14:08:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzpo13212; Mon, 29 Jul 2002 14:07:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzpo02023 for mpls-outgoing; Mon, 29 Jul 2002 14:07:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzpo02014 for ; Mon, 29 Jul 2002 14:07:00 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 QQmzpo11783 for ; Mon, 29 Jul 2002 14:06:30 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpo02138 for ; Mon, 29 Jul 2002 14:06:29 GMT Received: from emerson.torrentnet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: emerson.torrentnet.com [198.78.51.110]) id QQmzpo02134 for ; Mon, 29 Jul 2002 14:06:29 GMT Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g6TE6PZ36639; Mon, 29 Jul 2002 10:06:25 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g6TE6ON81904; Mon, 29 Jul 2002 10:06:24 -0400 (EDT) Received: from oldmonk (oldmonk.torrentnet.com [4.18.161.44]) by castillo.torrentnet.com (8.9.3/8.9.3) with SMTP id KAA05774; Mon, 29 Jul 2002 10:06:23 -0400 (EDT) From: "Sumit Garg" To: "'Hummel Heinrich'" , "'Loa Andersson'" Cc: "'MPLS wg'" Subject: RE: AW: AW: initiating a discussion on mpls singaling protocols Date: Mon, 29 Jul 2002 10:06:22 -0400 Message-ID: <000201c23709$1f0a5780$2ca11204@torrentnet.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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Does this all mean that you are carrying the ER-Hop/ Bandwidth etc from the egress (root) towards the ingress (head)? Applications? /Sumit From owner-mpls@UU.NET Mon Jul 29 10:36:44 2002 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 ESMTP id KAA01593 for ; Mon, 29 Jul 2002 10:36:43 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpq04952 for ; Mon, 29 Jul 2002 14:37:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzpq03232; Mon, 29 Jul 2002 14:36:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzpq04889 for mpls-outgoing; Mon, 29 Jul 2002 14:36:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzpq04757 for ; Mon, 29 Jul 2002 14:36: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 QQmzpq07410 for ; Mon, 29 Jul 2002 14:35:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpq17040 for ; Mon, 29 Jul 2002 14:35:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzpq17035 for ; Mon, 29 Jul 2002 14:35:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA14830 for ; Mon, 29 Jul 2002 10:35:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA14208 for mpls@uu.net; Mon, 29 Jul 2002 10:35:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzpq04714 for ; Mon, 29 Jul 2002 14:33: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 QQmzpq20916 for ; Mon, 29 Jul 2002 14:32:47 GMT From: sven.van_den_bosch@alcatel.be Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpq05950 for ; Mon, 29 Jul 2002 14:32:47 GMT Received: from mail.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQmzpq05945 for ; Mon, 29 Jul 2002 14:32:46 GMT Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g6TESIr17990 for ; Mon, 29 Jul 2002 16:28:18 +0200 Subject: additional sub-TLV for FA-LSP To: mpls@UU.NET Cc: Dimitri.Papadimitriou@alcatel.be X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 29 Jul 2002 16:32:37 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/29/2002 16:32:45 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, During the MPLS meeting there was some discussion on our proposal (see draft-vandenbosch-mpls-fa-considerations-01.txt) to add an additional sub-TLV (subTLV 10) to the resource class specification in draft-katz-yeung-ospf-traffic-06.txt. This subTLV could exist only in combination with subTLV9 in which case subTLV9 would denote resource classes to be used in an INCLUDE statement and subTLV10 in an EXCLUDE statement (example given in the draft). During the discussion it was made clear that the solution would cover most, but not all cases. Some analysis is provided below: - Elementary resource class specifications: . INCLUDE ANY: can be converted to OR-list of INCLUDEs . INCLUDE ALL: addressed for FA by sub-TLV 9 . EXCLUDE ANY: seems pointless, OR-list of EXCLUDEs . EXCLUDE ALL: addressed for FA by new sub-TLV 10 - How to handle combinations: any AND/OR list of the previous . INCLUDE(X) AND INCLUDE(Y) == INCLUDE(X,Y) . INCLUDE(X) OR INCLUDE(Y) == ? . EXCLUDE(X) AND EXCLUDE(Y) == EXCLUDE(X,Y) . EXCLUDE(X) OR EXCLUDE(Y) == EXCLUDE(X,Y) . INCLUDE(X) AND EXCLUDE(Y) == INCLUDE(X) if X,Y non-overlapping . INCLUDE(X) OR EXCLUDE(Y) == EXCLUDE(Y), If X,Y non-overlapping Note that a provider will be able to know whether or not it is safe to use this (by not specifying INC OR INC) and that the solution has mnore general applicability (e.g. for bundled links). There was some support for this during the meeting. If this is felt to be useful, we would like to request this modification in the appropriate WGs (OSPF,ISIS) with support from the MPLS community. Best regards, Sven. From owner-mpls@UU.NET Mon Jul 29 11:12:33 2002 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 ESMTP id LAA03310 for ; Mon, 29 Jul 2002 11:12:33 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzps05290 for ; Mon, 29 Jul 2002 15:13:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzps02898; Mon, 29 Jul 2002 15:12:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzps29670 for mpls-outgoing; Mon, 29 Jul 2002 15:11:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzps29665 for ; Mon, 29 Jul 2002 15:11:38 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 QQmzps21616 for ; Mon, 29 Jul 2002 15:09:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzps00778 for ; Mon, 29 Jul 2002 15:09:31 GMT Received: from gorilla.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQmzps00744 for ; Mon, 29 Jul 2002 15:09:30 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA29958; Mon, 29 Jul 2002 17:09:22 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA06011; Mon, 29 Jul 2002 17:09:19 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 17:09:11 +0200 Message-ID: From: Hummel Heinrich To: "'Sumit Garg'" , "'Loa Andersson'" Cc: "'MPLS wg'" Subject: AW: AW: AW: initiating a discussion on mpls singaling protocols Date: Mon, 29 Jul 2002 17:09:11 +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 Does this all mean that you are carrying the ER-Hop/ Bandwidth etc from the egress (root) towards the ingress (head)? Applications? Bandwidth reservation for all sections of the mp2p merge tree: It is assumed that the root (egress) knows how much bandwidth is required for the sake of each leaf(ingress). In compliance with the merging branches, the root may compute the accumulated bandwidth demand for each non-branching tree section. By proper placement of a Nodes-Info-Begin-TLV (which contains the accumulated bandwidth size and also a unique "sequence number") and of a Nodes-Info-End-TLV (which contains the respective "sequence number" as well), each node at the begin, in the middle, and at the end of the particular non-branching tree section will be alerted to make the appropriate bandwidth reservation. Consider some non-branching tree section somewhere in the middle of the tree. The respective TLV-pair will be forwarded from the root to the nearest node of this section. That nearest node will recognize which child link is of concern, and will be alerted to make the right bandwidth reservation. The Nodes-Info-Begin-TLV would not be removed before it becomes placed next to the respective Nodes-Info-End-TLV. I.e. it may alert all the nodes of this section. Thereafter, both TLVs will drop out. /Sumit From owner-mpls@UU.NET Mon Jul 29 11:22:46 2002 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 ESMTP id LAA03746 for ; Mon, 29 Jul 2002 11:22:45 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpt18185 for ; Mon, 29 Jul 2002 15:23:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzpt16600; Mon, 29 Jul 2002 15:22:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzpt01113 for mpls-outgoing; Mon, 29 Jul 2002 15:22:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzpt01104 for ; Mon, 29 Jul 2002 15:22:17 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 QQmzpt11619 for ; Mon, 29 Jul 2002 15:22:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpt16204 for ; Mon, 29 Jul 2002 15:22:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzpt16192 for ; Mon, 29 Jul 2002 15:22:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA18742 for ; Mon, 29 Jul 2002 11:22:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA19558 for mpls@uu.net; Mon, 29 Jul 2002 11:22:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzpt00854 for ; Mon, 29 Jul 2002 15:17:40 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 QQmzpt08069 for ; Mon, 29 Jul 2002 15:17:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpt12199 for ; Mon, 29 Jul 2002 15:17:30 GMT Received: from vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.131]) id QQmzpt12188 for ; Mon, 29 Jul 2002 15:17:30 GMT Received: from AMALIS.vivacenetworks.com ([10.120.0.2] unverified) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 29 Jul 2002 08:16:43 -0700 Message-Id: <5.1.0.14.2.20020729110932.02bbea90@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Jul 2002 11:14:48 -0400 To: mpls@UU.NET From: "Andrew G. Malis" Subject: Vendor ID (OUI) encoding in LDP section 3.6.1.1 Cc: Jim Harford , David Sinicrope Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Jul 2002 15:16:43.0584 (UTC) FILETIME=[F26B1C00:01C23712] Sender: owner-mpls@UU.NET Precedence: bulk RFC 3036 section 3.6.1.1 defines a 32-bit field called the "Vendor ID", which contains a 24-bit IEEE 802 OUI, however the exact encoding of the Vendor ID is not discussed. Is there anyone that does not agree that the OUI should be right-justified (in bits 8-31) in the field, with bits 0-7 set to zero? We may wish to clarify that when LDP becomes a Draft Standard. Thanks, Andy From owner-mpls@UU.NET Mon Jul 29 12:04:18 2002 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 ESMTP id MAA05546 for ; Mon, 29 Jul 2002 12:04:18 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpw18287 for ; Mon, 29 Jul 2002 16:05:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzpw16543; Mon, 29 Jul 2002 16:04:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzpw17744 for mpls-outgoing; Mon, 29 Jul 2002 16:04:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzpw17737 for ; Mon, 29 Jul 2002 16:04:04 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 QQmzpw21216 for ; Mon, 29 Jul 2002 16:03:51 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpw01681 for ; Mon, 29 Jul 2002 16:03:51 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 QQmzpw01676 for ; Mon, 29 Jul 2002 16:03:50 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA20498; Mon, 29 Jul 2002 18:03:29 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA25966; Mon, 29 Jul 2002 18:03:46 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 18:03:38 +0200 Message-ID: From: Hummel Heinrich To: "'Shahram Davari'" , "'Giles Heron'" , neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: AW: initiating a discussion on mpls singaling protocols Date: Mon, 29 Jul 2002 18:03: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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA05546 NO, the savings are much more. They are about 85 % reduction, so that 15 % remains.( I will not talk down these savings) However, 0.15 * O(n**2) will still be far too much, if n is big enough. Note that method (4) as of draft-hummel-mpls-n-square-investigations-00.txt also uses merging H-LSPs as to reduce the costs at the PEs, e.g. down to 0.15 * O(n**2). But I also pointed out that even this is not good enough, if n = 7500 for example. For VPNs of such size, we should even form groups of sites (e.g. all sites within one city form a group) and may have: a) a partial mesh of elementary LSPs (which form a tree, a ring, a ring of trees, a tree of rings,or a chessboard grit) b) a full mesh of hierarchical LSPs between the groups of sites c) a full mesh of hierarchical LSPs between the sites of each group of sites In order to accomplish effective full mesh connectivity, it may be appropriate to advertise all these LSPs (their ingress and their egress, as well as their starting labels, etc.) - roughly spoken. Of course it will take more labor, more conceptual thinking. E.g. so that the VC-label handling is integrated rather than an "abuse" :-) Heinrich -----Ursprüngliche Nachricht----- Von: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Gesendet: Freitag, 26. Juli 2002 17:15 An: 'Giles Heron'; neil.2.harrison@bt.com Cc: mpls@UU.NET Betreff: RE: initiating a discussion on mpls singaling protocols Giles, > > I want *both* mp2p LDP and targetted LDP. > > I want the former because it: > > 1) minimises the number of labels required in the core - O(N) rather > than O(N squared). > I think Heinrich Hummel demonstrated in the Japan (as predicted by Dave Allan) that mp2p (LDP) results only ~15% less states than N^2 mesh. -Shahram From owner-mpls@UU.NET Mon Jul 29 12:17:05 2002 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 ESMTP id MAA06084 for ; Mon, 29 Jul 2002 12:17:05 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpx13071 for ; Mon, 29 Jul 2002 16:18:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzpx11810; Mon, 29 Jul 2002 16:17:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzpx00850 for mpls-outgoing; Mon, 29 Jul 2002 16:17:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzpx00845 for ; Mon, 29 Jul 2002 16:17: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 QQmzpx22577 for ; Mon, 29 Jul 2002 16:16:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpx08807 for ; Mon, 29 Jul 2002 16:16:58 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQmzpx08799 for ; Mon, 29 Jul 2002 16:16:58 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA02828; Mon, 29 Jul 2002 18:16:54 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA28364; Mon, 29 Jul 2002 18:16:56 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 18:16:47 +0200 Message-ID: From: Hummel Heinrich To: "'Shahram Davari'" , "'Giles Heron'" , neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: AW: initiating a discussion on mpls singaling protocols Date: Mon, 29 Jul 2002 18:16:40 +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 MAA06084 Note, my mentioning of " the groups of sites" is just an initial thought. But if you have attended the elementary classes of the PNNI-school, you will be confident that this goal can be achieved:-) Heinrich -----Ursprüngliche Nachricht----- Von: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Gesendet: Montag, 29. Juli 2002 18:06 An: 'Hummel Heinrich'; 'Giles Heron'; neil.2.harrison@bt.com Cc: mpls@UU.NET Betreff: RE: initiating a discussion on mpls singaling protocols Ok, my mistake. -Shahram > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: Monday, July 29, 2002 12:04 PM > To: Shahram Davari; 'Giles Heron'; neil.2.harrison@bt.com > Cc: mpls@UU.NET > Subject: AW: initiating a discussion on mpls singaling protocols > > > NO, the savings are much more. They are about 85 % reduction, > so that 15 % remains.( I will not talk down these savings) > However, 0.15 * O(n**2) will still be far too much, if n is > big enough. > > Note that method (4) as of > draft-hummel-mpls-n-square-investigations-00.txt also uses > merging H-LSPs as to reduce the > costs at the PEs, e.g. down to 0.15 * O(n**2). > > But I also pointed out that even this is not good enough, if > n = 7500 for example. For VPNs of such size, we should even > form groups of sites (e.g. all sites within one city form a group) > and may have: > a) a partial mesh of elementary LSPs (which form a tree, a > ring, a ring of trees, a tree of rings,or a chessboard grit) > b) a full mesh of hierarchical LSPs between the groups of sites > c) a full mesh of hierarchical LSPs between the sites of each > group of sites > > In order to accomplish effective full mesh connectivity, it > may be appropriate to advertise all these LSPs (their ingress > and their egress, as well as their starting labels, etc.) - > roughly spoken. > > Of course it will take more labor, more conceptual thinking. > E.g. so that the VC-label handling is integrated rather than > an "abuse" :-) > > > Heinrich > > > > -----Ursprüngliche Nachricht----- > Von: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Gesendet: Freitag, 26. Juli 2002 17:15 > An: 'Giles Heron'; neil.2.harrison@bt.com > Cc: mpls@UU.NET > Betreff: RE: initiating a discussion on mpls singaling protocols > > > Giles, > > > > > I want *both* mp2p LDP and targetted LDP. > > > > I want the former because it: > > > > 1) minimises the number of labels required in the core - O(N) rather > > than O(N squared). > > > > I think Heinrich Hummel demonstrated in the Japan (as > predicted by Dave Allan) > that mp2p (LDP) results only ~15% less states than N^2 mesh. > > -Shahram > From owner-mpls@UU.NET Mon Jul 29 12:44:18 2002 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 ESMTP id MAA06990 for ; Mon, 29 Jul 2002 12:44:18 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpz08260 for ; Mon, 29 Jul 2002 16:45:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzpy06724; Mon, 29 Jul 2002 16:44:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzpy05326 for mpls-outgoing; Mon, 29 Jul 2002 16:44:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzpy05288 for ; Mon, 29 Jul 2002 16:44: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 QQmzpy17090 for ; Mon, 29 Jul 2002 16:42:22 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpy23782 for ; Mon, 29 Jul 2002 16:42:22 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmzpy23772 for ; Mon, 29 Jul 2002 16:42:21 GMT Received: from utfors.se ([195.58.105.112]) by blooper.utfors.se (Utfors AB) with ESMTP id g6TGfu5F008384; Mon, 29 Jul 2002 18:41:56 +0200 (MEST) Message-ID: <3D457053.2010006@utfors.se> Date: Mon, 29 Jul 2002 18:41:55 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Hummel Heinrich CC: "'Shahram Davari'" , "'Giles Heron'" , neil.2.harrison@bt.com, mpls@UU.NET Subject: singaling hierarchical LSP's (WAS (part of): initiating a discussion on mpls singaling protocols) References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, it seems like this discussion, though related, now has deviated enough from what was originally intended with this thread, could you please change the subject line Hummel Heinrich wrote: > Note, my mentioning of " the groups of sites" is just an initial thought. But if you have attended the > elementary classes of the PNNI-school, you will be confident that this goal can be achieved:-) > Heinrich > > -----Ursprüngliche Nachricht----- > Von: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Gesendet: Montag, 29. Juli 2002 18:06 > An: 'Hummel Heinrich'; 'Giles Heron'; neil.2.harrison@bt.com > Cc: mpls@UU.NET > Betreff: RE: initiating a discussion on mpls singaling protocols > > > Ok, my mistake. > > -Shahram > > >>-----Original Message----- >>From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] >>Sent: Monday, July 29, 2002 12:04 PM >>To: Shahram Davari; 'Giles Heron'; neil.2.harrison@bt.com >>Cc: mpls@UU.NET >>Subject: AW: initiating a discussion on mpls singaling protocols >> >> >>NO, the savings are much more. They are about 85 % reduction, >>so that 15 % remains.( I will not talk down these savings) >>However, 0.15 * O(n**2) will still be far too much, if n is >>big enough. >> >>Note that method (4) as of >>draft-hummel-mpls-n-square-investigations-00.txt also uses >>merging H-LSPs as to reduce the >>costs at the PEs, e.g. down to 0.15 * O(n**2). >> >>But I also pointed out that even this is not good enough, if >>n = 7500 for example. For VPNs of such size, we should even >>form groups of sites (e.g. all sites within one city form a group) >>and may have: >>a) a partial mesh of elementary LSPs (which form a tree, a >>ring, a ring of trees, a tree of rings,or a chessboard grit) >>b) a full mesh of hierarchical LSPs between the groups of sites >>c) a full mesh of hierarchical LSPs between the sites of each >>group of sites >> >>In order to accomplish effective full mesh connectivity, it >>may be appropriate to advertise all these LSPs (their ingress >>and their egress, as well as their starting labels, etc.) - >>roughly spoken. >> >>Of course it will take more labor, more conceptual thinking. >>E.g. so that the VC-label handling is integrated rather than >>an "abuse" :-) >> >> >>Heinrich >> >> >> >>-----Ursprüngliche Nachricht----- >>Von: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>Gesendet: Freitag, 26. Juli 2002 17:15 >>An: 'Giles Heron'; neil.2.harrison@bt.com >>Cc: mpls@UU.NET >>Betreff: RE: initiating a discussion on mpls singaling protocols >> >> >>Giles, >> >> >>>I want *both* mp2p LDP and targetted LDP. >>> >>>I want the former because it: >>> >>>1) minimises the number of labels required in the core - O(N) rather >>>than O(N squared). >>> >>> >>I think Heinrich Hummel demonstrated in the Japan (as >>predicted by Dave Allan) >>that mp2p (LDP) results only ~15% less states than N^2 mesh. >> >>-Shahram >> > -- 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 Jul 29 13:14:59 2002 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 ESMTP id NAA07946 for ; Mon, 29 Jul 2002 13:14:59 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqb17114 for ; Mon, 29 Jul 2002 17:16:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzqb15729; Mon, 29 Jul 2002 17:15:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzqa29648 for mpls-outgoing; Mon, 29 Jul 2002 17:14:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzqa29643 for ; Mon, 29 Jul 2002 17:14:54 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 QQmzqa25189 for ; Mon, 29 Jul 2002 17:13:28 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqa13064 for ; Mon, 29 Jul 2002 17:13:27 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQmzqa13051 for ; Mon, 29 Jul 2002 17:13:26 GMT Received: from utfors.se ([195.58.105.112]) by blooper.utfors.se (Utfors AB) with ESMTP id g6THDO5F008601; Mon, 29 Jul 2002 19:13:24 +0200 (MEST) Message-ID: <3D4577B4.2010802@utfors.se> Date: Mon, 29 Jul 2002 19:13:24 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Hummel Heinrich CC: MPLS wg Subject: Re: singaling hierarchical LSP's (WAS (part of): initiating a discussion on mpls singaling protocols) References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Heinrich, the answer to this is simple - reviving work is up to you. Re-issue the drafts and take the discussion to the list. If there are sufficent interest from the working group it will be progressed as a wg doc. However, I would like to ask three things - do not rename the message, all those suggestions were discussed -97 and we chose the current names - whether the names are good or not is not a fruitul discussion - rename them will cause confusion - wether we decide to focus on rsvp-te only or not, it is my take that this has to be designed for rsvp-te (also) to have any chance to fly - since we have the signaling protocol disucssion hold the revising of the draft until you know the design environment. /Loa Hummel Heinrich wrote: > Loa, > Quite some time ago (in Oslo)I presented a solution how to provide explicit routing information w.r.t. a tree route > and I would be pleased to revive this work if it is oked. > > By chance, it was using CR-LDP syntax and not RSVP-TE syntax, but this can be changed.BTW: I neither like the message > names PATH/RESERVE nor LABEL_REQUEST/LABEL_MAPPING but rather LSP_SETUP/LSP_SETUP_ACK.But this is my humble opinion only. > > It started with a simple algorithm which inversed the Dijkstra tree representation (where each node points to another > node one hop closer to the root) to a sequence of "("- TLVs, ")"-TLVs and ER-TLVs, where the bracket-TLVs shaped the tree and where the ER-TLVs represented non-branching sections within the tree. > > The over-all "TREE ROUTE TLV" might also contain new Node-Info-TLVs,which, properly positioned, would carry specific information (like FEC) to the right individual nodes on the tree.And finally,by pairs of (new) Nodes-Info-Begin-TLV and Nodes-Info-End-TLV specific information could be sent to clusters of nodes within the tree, e.g. how much bandwidth shall be reserved by each node for the respective links of some non-branching section of a merging LSP. > > I also showed how each node must handle the received "TREE ROUTE TLV", as to recognize what information it has to > evaluate by itself, and which part of the received TLV has to be forwarded along which child-link. > > The handling of this TREE ROUTE TLV, would be beneficial to > mp2p- LSPs, mp2mp- LSPs and p2mp-LSPs, be they elementary LSPs or Hierarchical LSPs. > > In all these cases, the message would start at some root node and progress towards multiple leaf nodes. > It is just this simple, and to hell with discussion "what is hereby DoD versus DU" :-) > > Needless to say: If the initial Dijkstra tree had been sensitive to QoS/Bandwidth-availability/Policy, then the inverse > representation,i.e. the TREE ROUTE TLV representation would be as well. > > Loa, if you ok so, I can sketch the algorithm for inversing the Dijkstra tree representation already in the next email > and also submit a revived draft. > > Heinrich > > ------------------ > > > see inline > > Hummel Heinrich wrote: > > >>As I see it: >> >>1) p2p LSP: in DoD. Is done by RSVP-TE and CR-LDP. With and without Explicit Routing. >> >>2) mp2p LSP: Is done by LDP using DU. But without QoS-/Policy-/Bandwidth- sensitiveness; >> Could be done by explicitly-routed /hop-by-hop routed merging LSPs, starting from the egress. >> Is not provided by CR-LDP. Is it provided by RSVP-TE (I doubt)? >> > > > If you have a the same spec's this is a request to merge, in fact you > have to make sure that you don't have the same spec's if you don't > want to merge. Maybe one of the rsvp-te authors could correct me if > i'm wrong. in some scenarios life would be easier if i were ;) > > > >> >>3) p2mp LSP (for Multicast): from source towards receivers, upon leaf initiated join requests. Not even started. >> > > > there were a multicast proposal in yokohama, we said that it was > premature to have an opinion on that, since the multicast fw were > just through the iesg review and that we need a discussion on how > much of this we want to do. > there is alos early work on mpls multicast based on ldp (not cr-ldp) > > /Loa > > > >> >> >>4) mp2mp LSP (e.g for VPLS): Is not provided at all. Note: If n=2, it means the bi-directional LSP. Is not provided at all. >> Could be done by explictly routed /hop-by-hop routed LSPs starting from whichever >> edge node towards all the other edge nodes. >> >>None of the following is done: >>H-1) p2p H-LSP: see draft-hummel-mpls-hierarchical-lsp-01.txt >>H-2) mp2p H-LSP: see expired draft-hummel-ppvpn-tunnel-sequencing-00.txt >>H-3) p2mp H-LSP: for VPN multicast on top of the partial mesh LSPs,no blind traffic to non-interested receiver sites >>H-4) mp2mp H-LSP: for VPN multicast on top of the partial mesh LSPs, blind traffic is accepted >> >>I think any protocol can be extended to provide all of it. Syntax is just syntax. >> >>The question is: >>Is this or that extension against the basic philosphy of the particular protocol ? >>Does it make sense to come up with an explicit release procedure for let's say mp2mp H-LSP within RSVP-TE, if >>for some religious belief a similar procedure is out of discusion for p2p LSP ? >> >>Another thing is: The MPLS Forum's UNI PVC is clearly based on CR-LDP, and has been developped with the help of companies which are now against CR-LDP. Funny but true. >> >>I also believe that it is much much much better to work with just one protocol. However, if some >>extension is reasonable and valuable, it should not be rejected because of reasons, which were used to >>fight other protocols in former times. >> >>A word about LDP: >>IMO it may have some value as a routing=advertisement protocol. But for setting up LSPs??? I only see one single >>merge LSP per egress (there is no LSP-ID as to cater for more). However it makes a lot of sense to explicitly establish merging LSPs starting from the egress. >> >> >>Heinrich >> >> >> >> >>-----Ursprüngliche Nachricht----- >>Von: Loa Andersson [mailto:loa.andersson@utfors.se] >>Gesendet: Freitag, 26. Juli 2002 15:25 >>An: Hummel Heinrich; MPLS wg >>Betreff: Re: AW: initiating a discussion on mpls singaling protocols >> >> >>Heinrich, >> >>this seems to show that cr-ldp and rsvp-te addresses one problem >>space and ldp another. Though I it is possible to create mp2p >>lsps with rsvp-te, just use the same spec and lsp's will merge. >> >>But, and more important, since there is no big difference and only >>one protocol is deployed, would that support the position on focusing >>on one protocol? >> >>/Loa >> >>Hummel Heinrich wrote: >> >> >> >>>Let me try to give an answer myself w.r.t my previously asked question by this following >>> >>>Table of current accomplishments: >>> >>> >>> CR-LDP, RSVP-TE, LDP >>>------------------------------------------------------ >>>1) p2p LSP yes yes N/A >>>2) p2mp LSP no no no (or N/A?) >>>3) mp2p LSP no no yes >>>4) mp2mp LSP no no no (or N/A?) >>>5) p2p H-LSP no no N/A >>>6) mp2p H-LSP no no N/A >>>7) p2mp H-LSP no no no (or N/A?) >>>8) mp2mp H-LSP no no no (or N/A?) >>> >>> >>>I think we should take this table into consideration which may effect the ongoing CR-LDP versus RSVP-TE discussion >>>in one way or the other: >>> >>>We may say: There are too many NO's as to make a pro/con CR-LDP decision already now. >>> >>>And also: For economical reasons, let's turn only one NO into a YES p e r l i n e - by future work. >>> >>>Heinrich >>> >>> >>> >> > > -- 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 Jul 29 13:28:35 2002 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 ESMTP id NAA08347 for ; Mon, 29 Jul 2002 13:28:35 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqb23167 for ; Mon, 29 Jul 2002 17:29:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzqb20800; Mon, 29 Jul 2002 17:28:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzqb00560 for mpls-outgoing; Mon, 29 Jul 2002 17:28:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzqb00555 for ; Mon, 29 Jul 2002 17:28:00 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 QQmzqb20708 for ; Mon, 29 Jul 2002 17:27:48 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqb29903 for ; Mon, 29 Jul 2002 17:27:48 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzqb29898 for ; Mon, 29 Jul 2002 17:27:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA24222 for ; Mon, 29 Jul 2002 13:27:47 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA22241 for mpls@uu.net; Mon, 29 Jul 2002 11:42:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzpu03189 for ; Mon, 29 Jul 2002 15:39:51 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 QQmzpu11659 for ; Mon, 29 Jul 2002 15:39:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpu20114 for ; Mon, 29 Jul 2002 15:39:31 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 QQmzpu20099 for ; Mon, 29 Jul 2002 15:39:30 GMT Received: (qmail 16701 invoked by uid 104); 29 Jul 2002 15:39:24 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4214. . Clean. Processed in 1.169553 secs); 29 Jul 2002 15:39:24 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 29 Jul 2002 15:39:23 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6TFdNw26556; Mon, 29 Jul 2002 08:39:23 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 08:39:23 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03780@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Andrew G. Malis'" , mpls@UU.NET Cc: Jim Harford , David Sinicrope Subject: RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1 Date: Mon, 29 Jul 2002 08:39:19 -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 Andy, IS=a there any reason that this kind of OUI does not exist in RSVP-TE? Yours, -Shahram > -----Original Message----- > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > Sent: Monday, July 29, 2002 11:15 AM > To: mpls@UU.NET > Cc: Jim Harford; David Sinicrope > Subject: Vendor ID (OUI) encoding in LDP section 3.6.1.1 > > > RFC 3036 section 3.6.1.1 defines a 32-bit field called the > "Vendor ID", > which contains a 24-bit IEEE 802 OUI, however the exact > encoding of the > Vendor ID is not discussed. Is there anyone that does not > agree that the > OUI should be right-justified (in bits 8-31) in the field, > with bits 0-7 > set to zero? We may wish to clarify that when LDP becomes a > Draft Standard. > > Thanks, > Andy > From owner-mpls@UU.NET Mon Jul 29 14:11:13 2002 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 ESMTP id OAA09440 for ; Mon, 29 Jul 2002 14:11:13 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqe28728 for ; Mon, 29 Jul 2002 18:12:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzqe26422; Mon, 29 Jul 2002 18:10:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzqe24796 for mpls-outgoing; Mon, 29 Jul 2002 18:10:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzqe24750 for ; Mon, 29 Jul 2002 18:10:09 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 QQmzqe23929 for ; Mon, 29 Jul 2002 18:09:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqe25468 for ; Mon, 29 Jul 2002 18:09:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzqe25460 for ; Mon, 29 Jul 2002 18:09:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA28948 for ; Mon, 29 Jul 2002 14:09:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA07673 for mpls@uu.net; Mon, 29 Jul 2002 14:09:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzpw23971 for ; Mon, 29 Jul 2002 16:06:39 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 QQmzpw26505 for ; Mon, 29 Jul 2002 16:05:46 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpw02625 for ; Mon, 29 Jul 2002 16:05:46 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 QQmzpw02617 for ; Mon, 29 Jul 2002 16:05:45 GMT Received: (qmail 10708 invoked by uid 104); 29 Jul 2002 16:05:44 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4214. . Clean. Processed in 0.469888 secs); 29 Jul 2002 16:05:44 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 29 Jul 2002 16:05:43 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6TG5hw18061; Mon, 29 Jul 2002 09:05:43 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 09:05:44 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03783@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Hummel Heinrich'" , "'Giles Heron'" , neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: RE: initiating a discussion on mpls singaling protocols Date: Mon, 29 Jul 2002 09:05:42 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA09440 Ok, my mistake. -Shahram > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: Monday, July 29, 2002 12:04 PM > To: Shahram Davari; 'Giles Heron'; neil.2.harrison@bt.com > Cc: mpls@UU.NET > Subject: AW: initiating a discussion on mpls singaling protocols > > > NO, the savings are much more. They are about 85 % reduction, > so that 15 % remains.( I will not talk down these savings) > However, 0.15 * O(n**2) will still be far too much, if n is > big enough. > > Note that method (4) as of > draft-hummel-mpls-n-square-investigations-00.txt also uses > merging H-LSPs as to reduce the > costs at the PEs, e.g. down to 0.15 * O(n**2). > > But I also pointed out that even this is not good enough, if > n = 7500 for example. For VPNs of such size, we should even > form groups of sites (e.g. all sites within one city form a group) > and may have: > a) a partial mesh of elementary LSPs (which form a tree, a > ring, a ring of trees, a tree of rings,or a chessboard grit) > b) a full mesh of hierarchical LSPs between the groups of sites > c) a full mesh of hierarchical LSPs between the sites of each > group of sites > > In order to accomplish effective full mesh connectivity, it > may be appropriate to advertise all these LSPs (their ingress > and their egress, as well as their starting labels, etc.) - > roughly spoken. > > Of course it will take more labor, more conceptual thinking. > E.g. so that the VC-label handling is integrated rather than > an "abuse" :-) > > > Heinrich > > > > -----Ursprüngliche Nachricht----- > Von: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Gesendet: Freitag, 26. Juli 2002 17:15 > An: 'Giles Heron'; neil.2.harrison@bt.com > Cc: mpls@UU.NET > Betreff: RE: initiating a discussion on mpls singaling protocols > > > Giles, > > > > > I want *both* mp2p LDP and targetted LDP. > > > > I want the former because it: > > > > 1) minimises the number of labels required in the core - O(N) rather > > than O(N squared). > > > > I think Heinrich Hummel demonstrated in the Japan (as > predicted by Dave Allan) > that mp2p (LDP) results only ~15% less states than N^2 mesh. > > -Shahram > From owner-mpls@UU.NET Mon Jul 29 17:01:32 2002 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 ESMTP id RAA14831 for ; Mon, 29 Jul 2002 17:01:32 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqq18013 for ; Mon, 29 Jul 2002 21:02:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzqq16518; Mon, 29 Jul 2002 21:01:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzqq29535 for mpls-outgoing; Mon, 29 Jul 2002 21:01:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzqq28240 for ; Mon, 29 Jul 2002 21:01:24 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 QQmzqq13466 for ; Mon, 29 Jul 2002 21:01:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqq04209 for ; Mon, 29 Jul 2002 21:01:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzqq04197 for ; Mon, 29 Jul 2002 21:01:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA15392 for ; Mon, 29 Jul 2002 17:01:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA27214 for mpls@uu.net; Mon, 29 Jul 2002 17:01:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzqq25345 for ; Mon, 29 Jul 2002 21:00:34 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 QQmzqp23261 for ; Mon, 29 Jul 2002 20:59:34 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqp16827 for ; Mon, 29 Jul 2002 20:59:33 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 QQmzqp16818 for ; Mon, 29 Jul 2002 20:59:33 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14637; Mon, 29 Jul 2002 16:58:26 -0400 (EDT) Message-Id: <200207292058.QAA14637@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: MTU Signalling Extensions for LDP to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 29 Jul 2002 16:58:26 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider MTU Signalling Extensions for LDP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 12, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mtu-extensions-00.txt From owner-mpls@UU.NET Mon Jul 29 17:35:30 2002 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 ESMTP id RAA16049 for ; Mon, 29 Jul 2002 17:35:29 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqs08866 for ; Mon, 29 Jul 2002 21:36:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzqs08071; Mon, 29 Jul 2002 21:36:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzqs17738 for mpls-outgoing; Mon, 29 Jul 2002 21:35:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzqs17730 for ; Mon, 29 Jul 2002 21:35: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 QQmzqs23651 for ; Mon, 29 Jul 2002 21:34:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzqs27894 for ; Mon, 29 Jul 2002 21:34:29 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 QQmzqs27890 for ; Mon, 29 Jul 2002 21:34:28 GMT Received: from MDUFFY ([10.1.3.119]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P5WPQ85X; Mon, 29 Jul 2002 17:34:23 -0400 Message-Id: <3.0.5.32.20020729172949.007ba100@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 Jul 2002 17:29:49 -0400 To: iesg@ietf.org From: Mark Duffy Subject: Re: Last Call: MTU Signalling Extensions for LDP to Proposed Standard Cc: mpls@UU.NET In-Reply-To: <200207292058.QAA14637@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I reported a number of problems with the Example section (section 3) of draft-ietf-mpls-ldp-mtu-extensions-00.txt on 23 July. I didn't realize at the time that the draft was almost ready for Last Call; perhaps it had already been submitted even. So, apologies for the lateness of my comments. All the same I believe that the procedures in section 2 of the document are difficult to understand, and that a correct example is therefore very important. One of the authors agreed with my comments and I understood that the draft was to be updated. A copy of the comments is below. Thanks, Mark Duffy >X-Sender: mduffy@email.quarrytech.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) >Date: Tue, 23 Jul 2002 11:07:26 -0400 >To: ben@layer8.net,kireeti@juniper.net,mpls@UU.net >From: Mark Duffy >Subject: issues in draft-ietf-mpls-ldp-mtu-extensions-00 > >Hi, > >In draft-ietf-mpls-ldp-mtu-extensions-00 I believe there are several >problems with the example in section 3. > >At the very end of the example it states: > > At t[2]: > > 1) Rx receives a Mapping for F from Ry with an MTU of 9216. Rx > compares 9212 (9216 - 4) to 4466, and sends a Mapping message for F > with an MTU of 4466 to Ri. > > 2) Ri has not received Mappings for F. > > At t[3]: > > 1) Ri receives a Mapping for F from Rx with an MTU of 4462. Ri > compares 4466 to 9216, and sets the MTU for P1 to 4462 (4466 minus > the overhead of 1 label pushed onto the stack). > > >The last step looks to me like it has several errors. >At t[2] item 1 Rx sends a mapping with mtu of 4466 to Ri. Therefore at >t[3] step 1 Ri should receive a mapping from Rx with an mtu of 4466. Also >in this same step Ri should subtract 4 bytes from both the MTU it learned >from Rx, as well as its local interface MTU, in making the calculation (to >account for the label pushed at Ri). > >So it looks to me like the correct text for t[3] is: > > 1) Ri receives a Mapping for F from Rx with an MTU of *4466*. Ri > compares *4462* to *9212*, and sets the MTU for P1 to 4462 (4466 minus > the overhead of 1 label pushed onto the stack). > >--------------------- > >Also, the example doesn't seem to correctly account for the encapsulation >of LSP P1 inside LSP P2 from Rx to Re. It discusses mappings for FEC F to >LSP P1 distributed to Ry, however Ry may be unaware of FEC F, since LSP P1 >is encapsulated in P2 at this point. > >I think the way to fix this would be to: > Let FEC G represent traffic mapped to LSP P2. > Change t[0] and t[1] items #1 to discuss G rather than F. > Change t[0] and t[1] items #2 to include G. > Chnage t[2] item #1 to receive mapping for G from Ry, send mapping for F >to Ri. > Adding another column to the table at the right of the figure would help >as well, giving the "MTU with P1 and P2 overhead". > > >Apologies if I am misunderstanding this, or if this has already been >pointed out. > >--Mark > From owner-mpls@UU.NET Mon Jul 29 21:22:33 2002 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 ESMTP id VAA20939 for ; Mon, 29 Jul 2002 21:22:33 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzrh24940 for ; Tue, 30 Jul 2002 01:23:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzrh23238; Tue, 30 Jul 2002 01:22:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzrh03284 for mpls-outgoing; Tue, 30 Jul 2002 01:22:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzrh03279 for ; Tue, 30 Jul 2002 01:22: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 QQmzrh12707 for ; Tue, 30 Jul 2002 01:20:59 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzrh21993 for ; Tue, 30 Jul 2002 01:20:59 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzrh20307 for ; Tue, 30 Jul 2002 01:20:19 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA29256 for ; Mon, 29 Jul 2002 21:20:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id VAA23340 for mpls@uu.net; Mon, 29 Jul 2002 21:20:05 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzpz06566 for ; Mon, 29 Jul 2002 16:53:50 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 QQmzpz13608 for ; Mon, 29 Jul 2002 16:52:59 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzpz28295 for ; Mon, 29 Jul 2002 16:52:58 GMT Received: from vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.131]) id QQmzpz28276 for ; Mon, 29 Jul 2002 16:52:58 GMT Received: from AMALIS.vivacenetworks.com ([10.120.0.2] unverified) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 29 Jul 2002 09:52:24 -0700 Message-Id: <5.1.0.14.2.20020729124939.02c19900@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Jul 2002 12:52:16 -0400 To: Shahram Davari From: "Andrew G. Malis" Subject: RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1 Cc: "'Andrew G. Malis'" , mpls@UU.NET, Jim Harford , David Sinicrope In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03780@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Jul 2002 16:52:24.0798 (UTC) FILETIME=[5072D7E0:01C23720] Sender: owner-mpls@UU.NET Precedence: bulk Shahram, For RSVP-TE (and classical RSVP) private extensions are typically handled by asking IANA for a new Class Number allocation in the range 224-255. Cheers, Andy ------ At 7/29/2002 08:39 AM -0700, Shahram Davari wrote: >Andy, > >IS=a there any reason that this kind of OUI does not exist in RSVP-TE? > >Yours, >-Shahram > > > -----Original Message----- > > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > > Sent: Monday, July 29, 2002 11:15 AM > > To: mpls@UU.NET > > Cc: Jim Harford; David Sinicrope > > Subject: Vendor ID (OUI) encoding in LDP section 3.6.1.1 > > > > > > RFC 3036 section 3.6.1.1 defines a 32-bit field called the > > "Vendor ID", > > which contains a 24-bit IEEE 802 OUI, however the exact > > encoding of the > > Vendor ID is not discussed. Is there anyone that does not > > agree that the > > OUI should be right-justified (in bits 8-31) in the field, > > with bits 0-7 > > set to zero? We may wish to clarify that when LDP becomes a > > Draft Standard. > > > > Thanks, > > Andy > > From owner-mpls@UU.NET Mon Jul 29 23:03:38 2002 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 ESMTP id XAA24048 for ; Mon, 29 Jul 2002 23:03:37 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzro15264 for ; Tue, 30 Jul 2002 03:04:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzro13347; Tue, 30 Jul 2002 03:03:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzro15044 for mpls-outgoing; Tue, 30 Jul 2002 03:03:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzro15035 for ; Tue, 30 Jul 2002 03:03: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 QQmzro23803 for ; Tue, 30 Jul 2002 03:02:37 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzro12791 for ; Tue, 30 Jul 2002 03:02:37 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f68.law4.hotmail.com [216.33.149.68]) id QQmzro12783 for ; Tue, 30 Jul 2002 03:02:37 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Jul 2002 20:02:36 -0700 Received: from 66.7.144.1 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 30 Jul 2002 03:02:36 GMT X-Originating-IP: [66.7.144.1] From: "Tissa Senevirathne" To: pwe3@ietf.org, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: Secure MPLS Date: Tue, 30 Jul 2002 03:02:36 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Jul 2002 03:02:36.0733 (UTC) FILETIME=[8EDCC6D0:01C23775] Sender: owner-mpls@UU.NET Precedence: bulk At Yokhoma during PWe3 session, it was indicated that hackers are waiting for the day that L2 VPN get exposed in the WAN. In light of that I thought to restart the discussion on Secure MPLS. The link below is Secure MPLS ID. This ID present how MPLS payloads can be encrypted in a similar manner like IPsec when upper layers does not have security capabilities. Or on links between PE to PE that are exposed to public networks. http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt For those who are lot in to Security the DOI (Domain of Interpretation) for Secure MPLS can be found in http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-01.txt Could you provide comments and feedback. Thanks Tissa _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Tue Jul 30 07:57:01 2002 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 ESMTP id HAA13562 for ; Tue, 30 Jul 2002 07:57:01 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzsx29834 for ; Tue, 30 Jul 2002 11:58:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzsx28760; Tue, 30 Jul 2002 11:57:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzsx01510 for mpls-outgoing; Tue, 30 Jul 2002 11:57:20 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzsx01505 for ; Tue, 30 Jul 2002 11:57: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 QQmzsx18328 for ; Tue, 30 Jul 2002 11:57:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzsx04170 for ; Tue, 30 Jul 2002 11:57:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzsx04163 for ; Tue, 30 Jul 2002 11:57:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26846 for ; Tue, 30 Jul 2002 07:57:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA25641 for mpls@uu.net; Tue, 30 Jul 2002 07:57:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzsx01490 for ; Tue, 30 Jul 2002 11:56: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 QQmzsx16735 for ; Tue, 30 Jul 2002 11:56:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzsx28036 for ; Tue, 30 Jul 2002 11:56:17 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQmzsx27999 for ; Tue, 30 Jul 2002 11:56:13 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13440; Tue, 30 Jul 2002 07:55:04 -0400 (EDT) Message-Id: <200207301155.HAA13440@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-recovery-frmwrk-06.txt Date: Tue, 30 Jul 2002 07:55:04 -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 : Framework for MPLS-based Recovery Author(s) : V. Sharma, F. Hellstrand Filename : draft-ietf-mpls-recovery-frmwrk-06.txt Pages : 31 Date : 29-Jul-02 Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switched routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling, support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-recovery-frmwrk-06.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-recovery-frmwrk-06.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: <20020729151316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-recovery-frmwrk-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020729151316.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jul 30 10:23:39 2002 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 ESMTP id KAA20015 for ; Tue, 30 Jul 2002 10:23:39 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzth28628 for ; Tue, 30 Jul 2002 14:24:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzth27498; Tue, 30 Jul 2002 14:24:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzth20472 for mpls-outgoing; Tue, 30 Jul 2002 14:23:47 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzth20456 for ; Tue, 30 Jul 2002 14:23: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 QQmzth29486 for ; Tue, 30 Jul 2002 14:23:01 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzth15637 for ; Tue, 30 Jul 2002 14:23: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 QQmzth15631 for ; Tue, 30 Jul 2002 14:23: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 KAA18800 for ; Tue, 30 Jul 2002 10:22:59 -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 KAA03093 for ; Tue, 30 Jul 2002 10:22:58 -0400 (EDT) Message-ID: <3D46A139.3020906@marconi.com> Date: Tue, 30 Jul 2002 10:22:49 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Vendor ID (OUI) encoding in LDP section 3.6.1.1 References: <5.1.0.14.2.20020729124939.02c19900@po1.vivacenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Andrew G. Malis wrote: > > For RSVP-TE (and classical RSVP) private extensions are typically > handled by asking IANA for a new Class Number allocation in the range > 224-255. IANA is the organization that selects standard numbers. But a private extension, that is not an RFC, does not normally get an IANA allocation. Even drafts that are well on their way to becoming RFCs don't usually get numbers assigned until it actually becomes an RFC. As for the range, IANA may assign from anywhere, not just 224-255. There are three ranges of object classes that dictate how a router that doesn't support the object should respond to it. The range chosen depends on the required behavior: 1-127 - non-supporting routers will not process the message at all, but will return PathErr or ResvErr. 128-191 - non-supporting routers will drop the object but process the rest of the message. 192-255 - non-supporting routers will forward the object without processing it. There is absolutely nothing special about the range 224-255. And there is no region reserved for vendor-proprietary class numbers, so it is always possible for a non-standard class to conflict with another class (let alone with another vendor's non-standard class.) This is a problem with RSVP, but there's no real solution as long as the class ID remains an 8-bit value. (And the kind of radical change needed to make it wider would probably be unwelcome, given the number of existing implementations.) -- David From owner-mpls@UU.NET Tue Jul 30 10:44:07 2002 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 ESMTP id KAA21550 for ; Tue, 30 Jul 2002 10:44:07 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztj19976 for ; Tue, 30 Jul 2002 14:45:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzti18494; Tue, 30 Jul 2002 14:44:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzti22470 for mpls-outgoing; Tue, 30 Jul 2002 14:43:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzti22465 for ; Tue, 30 Jul 2002 14:43:38 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 QQmzti18947 for ; Tue, 30 Jul 2002 14:43:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzti26488 for ; Tue, 30 Jul 2002 14:43:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzti26480 for ; Tue, 30 Jul 2002 14:43:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA07565 for ; Tue, 30 Jul 2002 10:43:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA12692 for mpls@uu.net; Tue, 30 Jul 2002 10:43:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzti22445 for ; Tue, 30 Jul 2002 14:42: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 QQmzti13319 for ; Tue, 30 Jul 2002 14:42:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzti26236 for ; Tue, 30 Jul 2002 14:42:31 GMT Received: from vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.131]) id QQmzti26230 for ; Tue, 30 Jul 2002 14:42:31 GMT Received: from AMALIS.vivacenetworks.com ([10.122.19.102]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Jul 2002 07:42:06 -0700 Message-Id: <5.1.0.14.2.20020730103807.073203a8@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 10:41:57 -0400 To: David Charlap From: "Andrew G. Malis" Subject: Re: Vendor ID (OUI) encoding in LDP section 3.6.1.1 Cc: IETF MPLS List In-Reply-To: <3D46A139.3020906@marconi.com> References: <5.1.0.14.2.20020729124939.02c19900@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Jul 2002 14:42:06.0945 (UTC) FILETIME=[470EE510:01C237D7] Sender: owner-mpls@UU.NET Precedence: bulk David, According to http://www.iana.org/assignments/rsvp-parameters, the range 224-255 is available for FCFS allocation. It doesn't specify any other particular allocation requirements. Cheers, Andy -------- At 7/30/2002 10:22 AM -0400, David Charlap wrote: >Andrew G. Malis wrote: >>For RSVP-TE (and classical RSVP) private extensions are typically handled >>by asking IANA for a new Class Number allocation in the range 224-255. > >IANA is the organization that selects standard numbers. But a private >extension, that is not an RFC, does not normally get an IANA >allocation. Even drafts that are well on their way to becoming RFCs don't >usually get numbers assigned until it actually becomes an RFC. > >As for the range, IANA may assign from anywhere, not just 224-255. > >There are three ranges of object classes that dictate how a router that >doesn't support the object should respond to it. The range chosen depends >on the required behavior: > >1-127 - non-supporting routers will not process the message at all, but >will return PathErr or ResvErr. > >128-191 - non-supporting routers will drop the object but process the rest >of the message. > >192-255 - non-supporting routers will forward the object without >processing it. > >There is absolutely nothing special about the range 224-255. And there is >no region reserved for vendor-proprietary class numbers, so it is always >possible for a non-standard class to conflict with another class (let >alone with another vendor's non-standard class.) > >This is a problem with RSVP, but there's no real solution as long as the >class ID remains an 8-bit value. (And the kind of radical change needed >to make it wider would probably be unwelcome, given the number of existing >implementations.) > >-- David From owner-mpls@UU.NET Tue Jul 30 11:12:22 2002 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 ESMTP id LAA22889 for ; Tue, 30 Jul 2002 11:12:22 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztk12120 for ; Tue, 30 Jul 2002 15:13:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmztk10391; Tue, 30 Jul 2002 15:12:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmztk17083 for mpls-outgoing; Tue, 30 Jul 2002 15:12:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmztk17077 for ; Tue, 30 Jul 2002 15:12: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 QQmztk20423 for ; Tue, 30 Jul 2002 15:10:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztk09270 for ; Tue, 30 Jul 2002 15:10: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 QQmztk09263 for ; Tue, 30 Jul 2002 15:10: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 LAA23589 for ; Tue, 30 Jul 2002 11:10: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 LAA16015 for ; Tue, 30 Jul 2002 11:10:29 -0400 (EDT) Message-ID: <3D46AC5C.3000107@marconi.com> Date: Tue, 30 Jul 2002 11:10:20 -0400 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020719 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Vendor ID (OUI) encoding in LDP section 3.6.1.1 References: <5.1.0.14.2.20020729124939.02c19900@po1.vivacenetworks.com> <5.1.0.14.2.20020730103807.073203a8@po1.vivacenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I know about the comment in IANA's file, and I have no idea what they're actually talking about. They _DO_ make allocations from elsewhere. The DIFFSERV object (class 65) was not assigned until RFC 3270 went on-line in May. And the DCLASS object (225 - in that region) is not proprietary - it's defined by RFC 2996. -- David Andrew G. Malis wrote: > > According to http://www.iana.org/assignments/rsvp-parameters, the range > 224-255 is available for FCFS allocation. It doesn't specify any other > particular allocation requirements. > > Cheers, > Andy > > -------- > > At 7/30/2002 10:22 AM -0400, David Charlap wrote: > >> Andrew G. Malis wrote: >> >>> For RSVP-TE (and classical RSVP) private extensions are typically >>> handled by asking IANA for a new Class Number allocation in the range >>> 224-255. >> >> >> IANA is the organization that selects standard numbers. But a private >> extension, that is not an RFC, does not normally get an IANA >> allocation. Even drafts that are well on their way to becoming RFCs >> don't usually get numbers assigned until it actually becomes an RFC. >> >> As for the range, IANA may assign from anywhere, not just 224-255. >> >> There are three ranges of object classes that dictate how a router >> that doesn't support the object should respond to it. The range >> chosen depends on the required behavior: >> >> 1-127 - non-supporting routers will not process the message at all, >> but will return PathErr or ResvErr. >> >> 128-191 - non-supporting routers will drop the object but process the >> rest of the message. >> >> 192-255 - non-supporting routers will forward the object without >> processing it. >> >> There is absolutely nothing special about the range 224-255. And >> there is no region reserved for vendor-proprietary class numbers, so >> it is always possible for a non-standard class to conflict with >> another class (let alone with another vendor's non-standard class.) >> >> This is a problem with RSVP, but there's no real solution as long as >> the class ID remains an 8-bit value. (And the kind of radical change >> needed to make it wider would probably be unwelcome, given the number >> of existing implementations.) >> >> -- David > > From owner-mpls@UU.NET Tue Jul 30 11:24:17 2002 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 ESMTP id LAA23417 for ; Tue, 30 Jul 2002 11:24:17 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztl23004 for ; Tue, 30 Jul 2002 15:25:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmztl22028; Tue, 30 Jul 2002 15:24:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQmztl18399 for mpls-outgoing; Tue, 30 Jul 2002 15:24:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmztl18394 for ; Tue, 30 Jul 2002 15:24: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 QQmztl12041 for ; Tue, 30 Jul 2002 15:22:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztl14154 for ; Tue, 30 Jul 2002 15:22:42 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQmztl14147 for ; Tue, 30 Jul 2002 15:22:42 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <3T6K18H8>; Tue, 30 Jul 2002 11:22:42 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B022671BD@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'David Charlap'" , IETF MPLS List Subject: RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1 Date: Tue, 30 Jul 2002 11:22:41 -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 David, First come, first served doesn't necessarily equate to proprietary. Also, vendor specific objects are very likely to fall in the range 192-255 because of the likely desired behavior (forward without processing if unknown). Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Tuesday, July 30, 2002 11:10 AM To: IETF MPLS List Subject: Re: Vendor ID (OUI) encoding in LDP section 3.6.1.1 I know about the comment in IANA's file, and I have no idea what they're actually talking about. They _DO_ make allocations from elsewhere. The DIFFSERV object (class 65) was not assigned until RFC 3270 went on-line in May. And the DCLASS object (225 - in that region) is not proprietary - it's defined by RFC 2996. -- David Andrew G. Malis wrote: > > According to http://www.iana.org/assignments/rsvp-parameters, the range > 224-255 is available for FCFS allocation. It doesn't specify any other > particular allocation requirements. > > Cheers, > Andy > > -------- > > At 7/30/2002 10:22 AM -0400, David Charlap wrote: > >> Andrew G. Malis wrote: >> >>> For RSVP-TE (and classical RSVP) private extensions are typically >>> handled by asking IANA for a new Class Number allocation in the range >>> 224-255. >> >> >> IANA is the organization that selects standard numbers. But a private >> extension, that is not an RFC, does not normally get an IANA >> allocation. Even drafts that are well on their way to becoming RFCs >> don't usually get numbers assigned until it actually becomes an RFC. >> >> As for the range, IANA may assign from anywhere, not just 224-255. >> >> There are three ranges of object classes that dictate how a router >> that doesn't support the object should respond to it. The range >> chosen depends on the required behavior: >> >> 1-127 - non-supporting routers will not process the message at all, >> but will return PathErr or ResvErr. >> >> 128-191 - non-supporting routers will drop the object but process the >> rest of the message. >> >> 192-255 - non-supporting routers will forward the object without >> processing it. >> >> There is absolutely nothing special about the range 224-255. And >> there is no region reserved for vendor-proprietary class numbers, so >> it is always possible for a non-standard class to conflict with >> another class (let alone with another vendor's non-standard class.) >> >> This is a problem with RSVP, but there's no real solution as long as >> the class ID remains an 8-bit value. (And the kind of radical change >> needed to make it wider would probably be unwelcome, given the number >> of existing implementations.) >> >> -- David > > From owner-mpls@UU.NET Tue Jul 30 11:34:52 2002 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 ESMTP id LAA23876 for ; Tue, 30 Jul 2002 11:34:52 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztm28322 for ; Tue, 30 Jul 2002 15:35:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmztm26727; Tue, 30 Jul 2002 15:34:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmztm19035 for mpls-outgoing; Tue, 30 Jul 2002 15:34:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmztm19024 for ; Tue, 30 Jul 2002 15:34: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 QQmztm12180 for ; Tue, 30 Jul 2002 15:34:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztm05119 for ; Tue, 30 Jul 2002 15:34:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmztm05100 for ; Tue, 30 Jul 2002 15:34:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12184 for ; Tue, 30 Jul 2002 11:34:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA18940 for mpls@uu.net; Tue, 30 Jul 2002 11:34:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmztm18995 for ; Tue, 30 Jul 2002 15:33:14 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 QQmztm28180 for ; Tue, 30 Jul 2002 15:32:20 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztm03140 for ; Tue, 30 Jul 2002 15:32:20 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmztm03125 for ; Tue, 30 Jul 2002 15:32:19 GMT Received: (qmail 9761 invoked by uid 104); 30 Jul 2002 15:32:18 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4214. . Clean. Processed in 0.483475 secs); 30 Jul 2002 15:32:18 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 30 Jul 2002 15:32:18 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g6UFWHw23172; Tue, 30 Jul 2002 08:32:17 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jul 2002 08:32:18 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03796@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'David Charlap'" , IETF MPLS List Subject: RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1 Date: Tue, 30 Jul 2002 08:32:16 -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 David, I think Andy is right. PacketCable has been able to get the number 226 without any RFC. Yours, -Shahram > -----Original Message----- > From: David Charlap [mailto:david.charlap@marconi.com] > Sent: Tuesday, July 30, 2002 11:10 AM > To: IETF MPLS List > Subject: Re: Vendor ID (OUI) encoding in LDP section 3.6.1.1 > > > I know about the comment in IANA's file, and I have no idea > what they're > actually talking about. > > They _DO_ make allocations from elsewhere. The DIFFSERV > object (class > 65) was not assigned until RFC 3270 went on-line in May. > > And the DCLASS object (225 - in that region) is not > proprietary - it's > defined by RFC 2996. > > -- David > > > Andrew G. Malis wrote: > > > > According to > http://www.iana.org/assignments/rsvp-parameters, the range > > 224-255 is available for FCFS allocation. It doesn't > specify any other > > particular allocation requirements. > > > > Cheers, > > Andy > > > > -------- > > > > At 7/30/2002 10:22 AM -0400, David Charlap wrote: > > > >> Andrew G. Malis wrote: > >> > >>> For RSVP-TE (and classical RSVP) private extensions are typically > >>> handled by asking IANA for a new Class Number allocation > in the range > >>> 224-255. > >> > >> > >> IANA is the organization that selects standard numbers. > But a private > >> extension, that is not an RFC, does not normally get an IANA > >> allocation. Even drafts that are well on their way to > becoming RFCs > >> don't usually get numbers assigned until it actually > becomes an RFC. > >> > >> As for the range, IANA may assign from anywhere, not just 224-255. > >> > >> There are three ranges of object classes that dictate how a router > >> that doesn't support the object should respond to it. The range > >> chosen depends on the required behavior: > >> > >> 1-127 - non-supporting routers will not process the > message at all, > >> but will return PathErr or ResvErr. > >> > >> 128-191 - non-supporting routers will drop the object but > process the > >> rest of the message. > >> > >> 192-255 - non-supporting routers will forward the object without > >> processing it. > >> > >> There is absolutely nothing special about the range 224-255. And > >> there is no region reserved for vendor-proprietary class > numbers, so > >> it is always possible for a non-standard class to conflict with > >> another class (let alone with another vendor's non-standard class.) > >> > >> This is a problem with RSVP, but there's no real solution > as long as > >> the class ID remains an 8-bit value. (And the kind of > radical change > >> needed to make it wider would probably be unwelcome, given > the number > >> of existing implementations.) > >> > >> -- David > > > > > > From owner-mpls@UU.NET Tue Jul 30 12:20:03 2002 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 ESMTP id MAA26632 for ; Tue, 30 Jul 2002 12:20:03 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztp29452 for ; Tue, 30 Jul 2002 16:21:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmztp21726; Tue, 30 Jul 2002 16:17:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmztp14737 for mpls-outgoing; Tue, 30 Jul 2002 16:17:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmztp14732 for ; Tue, 30 Jul 2002 16:17: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 QQmztp14158 for ; Tue, 30 Jul 2002 16:17:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztp17350 for ; Tue, 30 Jul 2002 16:17:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmztp17343 for ; Tue, 30 Jul 2002 16:17:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA15582 for ; Tue, 30 Jul 2002 12:17:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA24572 for mpls@uu.net; Tue, 30 Jul 2002 12:17:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzto14210 for ; Tue, 30 Jul 2002 16:13: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 QQmzto06411 for ; Tue, 30 Jul 2002 16:12:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzto14418 for ; Tue, 30 Jul 2002 16:12:13 GMT Received: from parsmtp2.rd.francetelecom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parsmtp2.rd.francetelecom.com [194.167.105.14]) id QQmzto14412 for ; Tue, 30 Jul 2002 16:12:12 GMT Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Jul 2002 18:12:11 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C237E3.DC61BFEE" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: MPLS2002 conference program Date: Tue, 30 Jul 2002 18:12:11 +0200 Message-ID: <8C19E3FBB6467846AFF97E366D34CB6029A51D@LANMHS20.rd.francetelecom.fr> Thread-Topic: MPLS2002 conference program Thread-Index: AcI34+gl1JqO9qOTEda1XACQJ5TFXw== From: "CARUGI Marco FTRD/DAC/LAN" To: "Ppvpn" , "Ccamp" , "Mpls" , "Pwe3" , , X-OriginalArrivalTime: 30 Jul 2002 16:12:11.0907 (UTC) FILETIME=[DCAAA530:01C237E3] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C237E3.DC61BFEE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all. On behalf of the Technical Program Committee, I wish to inform you that = the program of the MPLS2002 conference in Washington D.C. (October = 27-29) is available at http://www.mpls2002.com The Technical Program Committee has tried to assembly a program based on = original content and unpublished work to continue the tradition initiated by this conference in 1998 of covering = cutting edge topics.=20 Regards, Marco Carugi (MPLS2002 Technical Program co-chair) ------_=_NextPart_001_01C237E3.DC61BFEE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MPLS2002 conference program

Hi all.

On behalf of the Technical Program = Committee, I wish to inform you that the program of the MPLS2002 = conference in Washington D.C. (October 27-29) is available at  http://www.mpls2002.com

The Technical Program Committee has = tried to assembly a program based on original content and unpublished = work to
continue the tradition initiated by = this conference in 1998 of covering cutting edge topics.

Regards, Marco Carugi  (MPLS2002 = Technical Program co-chair)

------_=_NextPart_001_01C237E3.DC61BFEE-- From owner-mpls@UU.NET Tue Jul 30 12:49:25 2002 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 ESMTP id MAA27968 for ; Tue, 30 Jul 2002 12:49:25 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztr09071 for ; Tue, 30 Jul 2002 16:50:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmztr07909; Tue, 30 Jul 2002 16:49:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmztr17351 for mpls-outgoing; Tue, 30 Jul 2002 16:49:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmztr17340 for ; Tue, 30 Jul 2002 16:49:26 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 QQmztr20359 for ; Tue, 30 Jul 2002 16:49:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztr07412 for ; Tue, 30 Jul 2002 16:49:23 GMT Received: from djswamp.layer8.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: soggy131.drizzle.com [216.162.199.131]) id QQmztr07397 for ; Tue, 30 Jul 2002 16:49:22 GMT Received: (qmail 98457 invoked by uid 1000); 30 Jul 2002 16:49:16 -0000 Date: Tue, 30 Jul 2002 09:49:16 -0700 From: Ben Black To: Tissa Senevirathne Cc: pwe3@ietf.org, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: Re: Secure MPLS Message-ID: <20020730164916.GB63357@layer8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.99i Sender: owner-mpls@UU.NET Precedence: bulk Could you elaborate further on the requirements for a secure MPLS mechanism? Eager hackers seems a bit vague. Ben On Tue, Jul 30, 2002 at 03:02:36AM +0000, Tissa Senevirathne wrote: > > > > At Yokhoma during PWe3 session, it was indicated that hackers are waiting > for the day that L2 VPN get exposed in the WAN. > > In light of that I thought to restart the discussion on Secure MPLS. > > The link below is Secure MPLS ID. This ID present how MPLS payloads can be > encrypted in a similar manner like IPsec when upper layers does not have > security capabilities. Or on links between PE to PE that are exposed to > public networks. > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt > > For those who are lot in to Security the DOI (Domain of Interpretation) for > Secure MPLS can be found in > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-01.txt > > Could you provide comments and feedback. > > Thanks > > Tissa > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Tue Jul 30 13:38:00 2002 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 ESMTP id NAA01357 for ; Tue, 30 Jul 2002 13:37:59 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztu19595 for ; Tue, 30 Jul 2002 17:39:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmztu18014; Tue, 30 Jul 2002 17:38:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmztu13348 for mpls-outgoing; Tue, 30 Jul 2002 17:38:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmztu13343 for ; Tue, 30 Jul 2002 17:37:57 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 QQmztu16743 for ; Tue, 30 Jul 2002 17:37:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztu13789 for ; Tue, 30 Jul 2002 17:37:52 GMT Received: from mozzer.routingloop.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mozzer.routingloop.com [65.215.164.222]) id QQmztu13785 for ; Tue, 30 Jul 2002 17:37:51 GMT Received: from mozzer.routingloop.com (localhost [127.0.0.1]) by mozzer.routingloop.com (8.12.1/9.1.1) with ESMTP id g6UHR3AT009657; Tue, 30 Jul 2002 10:27:03 -0700 (PDT) (envelope-from alan@mozzer.routingloop.com) Received: (from alan@localhost) by mozzer.routingloop.com (8.12.1/8.12.1/Submit) id g6UHR3Wg009656; Tue, 30 Jul 2002 10:27:03 -0700 (PDT) (envelope-from alan) Date: Tue, 30 Jul 2002 10:27:02 -0700 From: Alan Hannan To: Tissa Senevirathne , pwe3@ietf.org, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: Re: Secure MPLS Message-ID: <20020730102702.A9638@routingloop.com> References: <20020730164916.GB63357@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020730164916.GB63357@layer8.net>; from ben@layer8.net on Tue, Jul 30, 2002 at 09:49:16AM -0700 Sender: owner-mpls@UU.NET Precedence: bulk I suggest that folks review the work done on Secure Frame Relay. -a Thus spake Ben Black (ben@layer8.net) on or about Tue, Jul 30, 2002 at 09:49:16AM -0700: > Could you elaborate further on the requirements for a secure MPLS > mechanism? Eager hackers seems a bit vague. > > > Ben > > On Tue, Jul 30, 2002 at 03:02:36AM +0000, Tissa Senevirathne wrote: > > > > > > > > At Yokhoma during PWe3 session, it was indicated that hackers are waiting > > for the day that L2 VPN get exposed in the WAN. > > > > In light of that I thought to restart the discussion on Secure MPLS. > > > > The link below is Secure MPLS ID. This ID present how MPLS payloads can be > > encrypted in a similar manner like IPsec when upper layers does not have > > security capabilities. Or on links between PE to PE that are exposed to > > public networks. > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt > > > > For those who are lot in to Security the DOI (Domain of Interpretation) for > > Secure MPLS can be found in > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-01.txt > > > > Could you provide comments and feedback. > > > > Thanks > > > > Tissa > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Tue Jul 30 14:09:50 2002 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 ESMTP id OAA02560 for ; Tue, 30 Jul 2002 14:09:49 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztw29211 for ; Tue, 30 Jul 2002 18:10:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmztw27660; Tue, 30 Jul 2002 18:10:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmztw07359 for mpls-outgoing; Tue, 30 Jul 2002 18:09:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmztw07349 for ; Tue, 30 Jul 2002 18:09:48 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 QQmztw03378 for ; Tue, 30 Jul 2002 18:09:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmztw14842 for ; Tue, 30 Jul 2002 18:09:39 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f68.law4.hotmail.com [216.33.149.68]) id QQmztw14837 for ; Tue, 30 Jul 2002 18:09:39 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Jul 2002 11:09:38 -0700 Received: from 63.251.106.30 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 30 Jul 2002 18:09:38 GMT X-Originating-IP: [63.251.106.30] From: "Tissa Senevirathne" To: alan@routingloop.com, pwe3@ietf.org, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: Re: [PWE3] Re: Secure MPLS Date: Tue, 30 Jul 2002 18:09:38 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Jul 2002 18:09:38.0620 (UTC) FILETIME=[44D5B7C0:01C237F4] Sender: owner-mpls@UU.NET Precedence: bulk Alan Can you give us pointers to secure Frame relay that we can use and compare.. >From: Alan Hannan >To: Tissa Senevirathne , pwe3@ietf.org, mpls@UU.NET, > ppvpn@ppvpn.francetelecom.com >Subject: [PWE3] Re: Secure MPLS >Date: Tue, 30 Jul 2002 10:27:02 -0700 > > > I suggest that folks review the work done on Secure Frame Relay. > > -a > >Thus spake Ben Black (ben@layer8.net) > on or about Tue, Jul 30, 2002 at 09:49:16AM -0700: > > Could you elaborate further on the requirements for a secure MPLS > > mechanism? Eager hackers seems a bit vague. > > > > > > Ben > > > > On Tue, Jul 30, 2002 at 03:02:36AM +0000, Tissa Senevirathne wrote: > > > > > > > > > > > > At Yokhoma during PWe3 session, it was indicated that hackers are >waiting > > > for the day that L2 VPN get exposed in the WAN. > > > > > > In light of that I thought to restart the discussion on Secure MPLS. > > > > > > The link below is Secure MPLS ID. This ID present how MPLS payloads >can be > > > encrypted in a similar manner like IPsec when upper layers does not >have > > > security capabilities. Or on links between PE to PE that are exposed >to > > > public networks. > > > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt > > > > > > For those who are lot in to Security the DOI (Domain of >Interpretation) for > > > Secure MPLS can be found in > > > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-01.txt > > > > > > Could you provide comments and feedback. > > > > > > Thanks > > > > > > Tissa > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Tue Jul 30 14:34:17 2002 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 ESMTP id OAA03747 for ; Tue, 30 Jul 2002 14:34:17 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzty04456 for ; Tue, 30 Jul 2002 18:35:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzty03084; Tue, 30 Jul 2002 18:34:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzty09845 for mpls-outgoing; Tue, 30 Jul 2002 18:34:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzty09834 for ; Tue, 30 Jul 2002 18:34:09 GMT Received: from imr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzty05203 for ; Tue, 30 Jul 2002 18:33:56 GMT Received: from pmismtp06.wcomnet.com by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pmismtp06.wcomnet.com [166.38.62.54]) id QQmzty05188 for ; Tue, 30 Jul 2002 18:33:56 GMT Received: from CONVERSION-DAEMON.pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) id <0H0200501RHOUH@pmismtp06.wcomnet.com> for mpls@uu.net; Tue, 30 Jul 2002 18:33:56 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H0200601RKK2N@pmismtp06.wcomnet.com> for mpls@uu.net; Tue, 30 Jul 2002 18:33:56 +0000 (GMT) Received: from rbonica ([166.60.14.44]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H02004LXRKJO0@pmismtp06.wcomnet.com>; Tue, 30 Jul 2002 18:33:55 +0000 (GMT) Date: Tue, 30 Jul 2002 14:22:32 -0400 From: Ron Bonica Subject: RE: Secure MPLS In-reply-to: To: Tissa Senevirathne , mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tissa, Given that the upper layers are capable of encryption using mechanisms like IPSEC, why would a service provider want to encrypt the contents of an MPLS LSP? Wouldn't you want to push the encryption function higher in the protocol stack and closer to the network edges? Ron > -----Original Message----- > From: ppvpn-owner@ppvpn.francetelecom.com > [mailto:ppvpn-owner@ppvpn.francetelecom.com]On Behalf Of Tissa > Senevirathne > Sent: Monday, July 29, 2002 11:03 PM > To: pwe3@ietf.org; mpls@uu.net; ppvpn@ppvpn.francetelecom.com > Subject: Secure MPLS > > > > > > At Yokhoma during PWe3 session, it was indicated that hackers are waiting > for the day that L2 VPN get exposed in the WAN. > > In light of that I thought to restart the discussion on Secure MPLS. > > The link below is Secure MPLS ID. This ID present how MPLS > payloads can be > encrypted in a similar manner like IPsec when upper layers does not have > security capabilities. Or on links between PE to PE that are exposed to > public networks. > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt > > For those who are lot in to Security the DOI (Domain of > Interpretation) for > Secure MPLS can be found in > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-01.txt > > Could you provide comments and feedback. > > Thanks > > Tissa > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > From owner-mpls@UU.NET Tue Jul 30 15:43:22 2002 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 ESMTP id PAA06450 for ; Tue, 30 Jul 2002 15:43:22 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzuc22115 for ; Tue, 30 Jul 2002 19:44:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzuc20850; Tue, 30 Jul 2002 19:43:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzuc07211 for mpls-outgoing; Tue, 30 Jul 2002 19:43:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzuc07206 for ; Tue, 30 Jul 2002 19:43: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 QQmzuc20836 for ; Tue, 30 Jul 2002 19:43:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzuc03855 for ; Tue, 30 Jul 2002 19:43:17 GMT Received: from mclaren.timewarp.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mclaren.timewarp.co.uk [217.149.108.13]) id QQmzuc03846 for ; Tue, 30 Jul 2002 19:43:16 GMT Received: from [217.149.105.23] (helo=BIGBOY) by mclaren.timewarp.co.uk with smtp (Exim 3.22 #3) id 17ZctU-0003pR-00; Tue, 30 Jul 2002 20:42:56 +0100 Message-ID: <009901c23801$767e32e0$2201a8c0@BIGBOY> From: "h.hopkins" To: "Tissa Senevirathne" , , , , References: Subject: Re: [PWE3] Re: Secure MPLS Date: Tue, 30 Jul 2002 20:44:02 +0100 Organization: Accent on Networks Ltd. 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanner: exiscan *17ZctU-0003pR-00*vS71ccIk2r6* http://duncanthrax.net/exiscan/ Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The Frame Relay Forum has published an Implementation Agreement on Privacy at http://www.frforum.com/5000/5000index.html See FRF.17 it may be relevant. Harman H Hopkins Director, Accent on Networks 26 Princes Road Felixstowe, Suffolk IP11 7QZ UK e-mail: h.hopkins@accent-on-networks.co.uk ----- Original Message ----- From: "Tissa Senevirathne" To: ; ; ; Sent: 30 July 2002 19:09 Subject: Re: [PWE3] Re: Secure MPLS > Alan > > Can you give us pointers to secure Frame relay that we can use and > compare.. > > > >From: Alan Hannan > >To: Tissa Senevirathne , pwe3@ietf.org, mpls@UU.NET, > > ppvpn@ppvpn.francetelecom.com > >Subject: [PWE3] Re: Secure MPLS > >Date: Tue, 30 Jul 2002 10:27:02 -0700 > > > > > > I suggest that folks review the work done on Secure Frame Relay. > > > > -a > > > >Thus spake Ben Black (ben@layer8.net) > > on or about Tue, Jul 30, 2002 at 09:49:16AM -0700: > > > Could you elaborate further on the requirements for a secure MPLS > > > mechanism? Eager hackers seems a bit vague. > > > > > > > > > Ben > > > > > > On Tue, Jul 30, 2002 at 03:02:36AM +0000, Tissa Senevirathne wrote: > > > > > > > > > > > > > > > > At Yokhoma during PWe3 session, it was indicated that hackers are > >waiting > > > > for the day that L2 VPN get exposed in the WAN. > > > > > > > > In light of that I thought to restart the discussion on Secure MPLS. > > > > > > > > The link below is Secure MPLS ID. This ID present how MPLS payloads > >can be > > > > encrypted in a similar manner like IPsec when upper layers does not > >have > > > > security capabilities. Or on links between PE to PE that are exposed > >to > > > > public networks. > > > > > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt > > > > > > > > For those who are lot in to Security the DOI (Domain of > >Interpretation) for > > > > Secure MPLS can be found in > > > > > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-01.txt > > > > > > > > Could you provide comments and feedback. > > > > > > > > Thanks > > > > > > > > Tissa > > > > > > > > _________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > From owner-mpls@UU.NET Tue Jul 30 16:34:01 2002 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 ESMTP id QAA07884 for ; Tue, 30 Jul 2002 16:34:01 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzug27148 for ; Tue, 30 Jul 2002 20:35:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzug26162; Tue, 30 Jul 2002 20:34:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzug03386 for mpls-outgoing; Tue, 30 Jul 2002 20:34:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzug03379 for ; Tue, 30 Jul 2002 20:34:00 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 QQmzug00470 for ; Tue, 30 Jul 2002 20:33:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzug25400 for ; Tue, 30 Jul 2002 20:33:32 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQmzug25388 for ; Tue, 30 Jul 2002 20:33:31 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g6UKXVm31638; Tue, 30 Jul 2002 13:33:31 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g6UKXUZ16675; Tue, 30 Jul 2002 13:33:31 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 30 Jul 2002 13:33:30 -0700 (PDT) From: Kireeti Kompella To: Scott Bradner cc: Subject: RE: initiating a discussion on mpls singalong protocols In-Reply-To: <200207240002.g6O02CX11150@newdev.harvard.edu> Message-ID: <20020730100505.P12840-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 23 Jul 2002, Scott Bradner wrote: > the question has been asked about reclassifying a already published > RFC from Proposed Standard to Informational (i.e. de-standardization) Here's my take on this (lemme see, which hat should I wear?) On the one hand, what Eric calls "responsible protocol development" has meant more drafts and more work for all (including this thread). On the other hand, I'm not sure the IETF should get into the business of choosing among protocols. However, somebody has to. In this case, the market did. Rephrasing Scott's original question: should the IETF recognize this? if so, how? A simple answer is: move RSVP-TE to Draft Standard. Let CR-LDP langui^H^H^H^H^H^H, um, remain as PS. It's probably time to start thinking about advancing RFC 3209, anyway. RFC 2026 says: "A specification ... for which *sufficient successful* operational experience has been obtained, may be elevated to the "Draft Standard" level." (My emphasis.) > specific questions: > A/ should IETF working group charters be modified to remove a requirement > to work on CR-LPD technologies? Yes. More important, I would say that a goal in the form "Advance to Draft Standard" is dangerous. One might say, "Consider advancing to DS" ... (see MPLS WG charter). > B/ if there is CR-LDP work already in progress, what should happen to it? Target the work as Experimental. > C/ if a working group requests publication of RFCs about CR-LPD > technology on the standards track what should we do? Publish as Experimental. > D/ if someone requests independent publication of RFCs about CR-LPD > technology on the standards track (as permitted by RFC 2026) what > should we do? Publish as Experimental. Kireeti. From owner-mpls@UU.NET Tue Jul 30 16:34:20 2002 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 ESMTP id QAA07899 for ; Tue, 30 Jul 2002 16:34:19 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzug26690 for ; Tue, 30 Jul 2002 20:35:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzug25016; Tue, 30 Jul 2002 20:34:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzug03391 for mpls-outgoing; Tue, 30 Jul 2002 20:34:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzug03381 for ; Tue, 30 Jul 2002 20:34: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 QQmzug13603 for ; Tue, 30 Jul 2002 20:31:54 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzug04263 for ; Tue, 30 Jul 2002 20:31:54 GMT Received: from djswamp.layer8.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: soggy131.drizzle.com [216.162.199.131]) id QQmzug04254 for ; Tue, 30 Jul 2002 20:31:53 GMT Received: (qmail 99442 invoked by uid 1000); 30 Jul 2002 20:31:47 -0000 Date: Tue, 30 Jul 2002 13:31:47 -0700 From: Ben Black To: "h.hopkins" Cc: Tissa Senevirathne , alan@routingloop.com, pwe3@ietf.org, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: Re: [PWE3] Re: Secure MPLS Message-ID: <20020730203147.GD99290@layer8.net> References: <009901c23801$767e32e0$2201a8c0@BIGBOY> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009901c23801$767e32e0$2201a8c0@BIGBOY> User-Agent: Mutt/1.3.99i Sender: owner-mpls@UU.NET Precedence: bulk Would any vendor who actually implemented this please chime in? Ben On Tue, Jul 30, 2002 at 08:44:02PM +0100, h.hopkins wrote: > The Frame Relay Forum has published an Implementation Agreement on Privacy > at > http://www.frforum.com/5000/5000index.html See FRF.17 it may be relevant. > > Harman H Hopkins > Director, Accent on Networks > 26 Princes Road > Felixstowe, Suffolk > IP11 7QZ > UK > > e-mail: h.hopkins@accent-on-networks.co.uk > > ----- Original Message ----- > From: "Tissa Senevirathne" > To: ; ; ; > > Sent: 30 July 2002 19:09 > Subject: Re: [PWE3] Re: Secure MPLS > > > > Alan > > > > Can you give us pointers to secure Frame relay that we can use and > > compare.. > > > > > > >From: Alan Hannan > > >To: Tissa Senevirathne , pwe3@ietf.org, > mpls@UU.NET, > > > ppvpn@ppvpn.francetelecom.com > > >Subject: [PWE3] Re: Secure MPLS > > >Date: Tue, 30 Jul 2002 10:27:02 -0700 > > > > > > > > > I suggest that folks review the work done on Secure Frame Relay. > > > > > > -a > > > > > >Thus spake Ben Black (ben@layer8.net) > > > on or about Tue, Jul 30, 2002 at 09:49:16AM -0700: > > > > Could you elaborate further on the requirements for a secure MPLS > > > > mechanism? Eager hackers seems a bit vague. > > > > > > > > > > > > Ben > > > > > > > > On Tue, Jul 30, 2002 at 03:02:36AM +0000, Tissa Senevirathne wrote: > > > > > > > > > > > > > > > > > > > > At Yokhoma during PWe3 session, it was indicated that hackers are > > >waiting > > > > > for the day that L2 VPN get exposed in the WAN. > > > > > > > > > > In light of that I thought to restart the discussion on Secure MPLS. > > > > > > > > > > The link below is Secure MPLS ID. This ID present how MPLS payloads > > >can be > > > > > encrypted in a similar manner like IPsec when upper layers does not > > >have > > > > > security capabilities. Or on links between PE to PE that are exposed > > >to > > > > > public networks. > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt > > > > > > > > > > For those who are lot in to Security the DOI (Domain of > > >Interpretation) for > > > > > Secure MPLS can be found in > > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-01.txt > > > > > > > > > > Could you provide comments and feedback. > > > > > > > > > > Thanks > > > > > > > > > > Tissa > > > > > > > > > > _________________________________________________________________ > > > > > MSN Photos is the easiest way to share and print your photos: > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > From owner-mpls@UU.NET Tue Jul 30 16:56:03 2002 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 ESMTP id QAA08663 for ; Tue, 30 Jul 2002 16:56:03 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzuh18505 for ; Tue, 30 Jul 2002 20:57:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzuh17149; Tue, 30 Jul 2002 20:56:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzuh05189 for mpls-outgoing; Tue, 30 Jul 2002 20:55:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzuh05158 for ; Tue, 30 Jul 2002 20:55: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 QQmzuh08107 for ; Tue, 30 Jul 2002 20:55:34 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzuh16404 for ; Tue, 30 Jul 2002 20:55:34 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f133.law4.hotmail.com [216.33.149.133]) id QQmzuh16392 for ; Tue, 30 Jul 2002 20:55:33 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Jul 2002 13:55:32 -0700 Received: from 66.7.144.1 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 30 Jul 2002 20:55:32 GMT X-Originating-IP: [66.7.144.1] From: "Tissa Senevirathne" To: Ronald.P.Bonica@wcom.com, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: RE: Secure MPLS Date: Tue, 30 Jul 2002 20:55:32 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Jul 2002 20:55:32.0990 (UTC) FILETIME=[721A09E0:01C2380B] Sender: owner-mpls@UU.NET Precedence: bulk Hi Ron It depends based on what purpose the MPLS tunnel is used. if you take the case of VPLS, it is a LAN network with multi points of LSP. So there is no easy way you could provide an upper layer encryption. However if you are using Encryption at the MPLS level the encryption is an attribute between two adjacent PE. As an example instead of providing a costly VPLS service that requires encryption on all tunnels, one may choose to encrypt the tunnels across some untrusted domains, On the other hand can this be provided as a value added service to the customer ? >From: Ron Bonica >To: Tissa Senevirathne , mpls@uu.net >Subject: RE: Secure MPLS >Date: Tue, 30 Jul 2002 14:22:32 -0400 > >Tissa, > >Given that the upper layers are capable of encryption using mechanisms like >IPSEC, why would a service provider want to encrypt the contents of an MPLS >LSP? > >Wouldn't you want to push the encryption function higher in the protocol >stack and closer to the network edges? > > Ron > > > > -----Original Message----- > > From: ppvpn-owner@ppvpn.francetelecom.com > > [mailto:ppvpn-owner@ppvpn.francetelecom.com]On Behalf Of Tissa > > Senevirathne > > Sent: Monday, July 29, 2002 11:03 PM > > To: pwe3@ietf.org; mpls@uu.net; ppvpn@ppvpn.francetelecom.com > > Subject: Secure MPLS > > > > > > > > > > > > At Yokhoma during PWe3 session, it was indicated that hackers are >waiting > > for the day that L2 VPN get exposed in the WAN. > > > > In light of that I thought to restart the discussion on Secure MPLS. > > > > The link below is Secure MPLS ID. This ID present how MPLS > > payloads can be > > encrypted in a similar manner like IPsec when upper layers does not have > > security capabilities. Or on links between PE to PE that are exposed to > > public networks. > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt > > > > For those who are lot in to Security the DOI (Domain of > > Interpretation) for > > Secure MPLS can be found in > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-01.txt > > > > Could you provide comments and feedback. > > > > Thanks > > > > Tissa > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-mpls@UU.NET Tue Jul 30 17:43:41 2002 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 ESMTP id RAA10165 for ; Tue, 30 Jul 2002 17:43:41 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzuk09407 for ; Tue, 30 Jul 2002 21:44:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzuk07996; Tue, 30 Jul 2002 21:44:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzuk00923 for mpls-outgoing; Tue, 30 Jul 2002 21:43:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzuk00918 for ; Tue, 30 Jul 2002 21:43:30 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 QQmzuk25614 for ; Tue, 30 Jul 2002 21:43:17 GMT From: neil.2.harrison@bt.com Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmzuh21264 for ; Tue, 30 Jul 2002 20:58:16 GMT Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 30 Jul 2002 21:58:19 +0100 Message-ID: To: Shahram_Davari@pmc-sierra.com, david.charlap@marconi.com, mpls@UU.NET Subject: RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1 Date: Tue, 30 Jul 2002 21:58:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk My view on this is that any body who purports to be a 'standards organisation' should not sanction vendor (or other, eg SP) protocol codepoints. regards, Neil > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: 30 July 2002 16:32 > To: 'David Charlap'; IETF MPLS List > Subject: RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1 > > > David, > > I think Andy is right. PacketCable has been able to get the number 226 > without any RFC. > > Yours, > -Shahram > > > -----Original Message----- > > From: David Charlap [mailto:david.charlap@marconi.com] > > Sent: Tuesday, July 30, 2002 11:10 AM > > To: IETF MPLS List > > Subject: Re: Vendor ID (OUI) encoding in LDP section 3.6.1.1 > > > > > > I know about the comment in IANA's file, and I have no idea > > what they're > > actually talking about. > > > > They _DO_ make allocations from elsewhere. The DIFFSERV > > object (class > > 65) was not assigned until RFC 3270 went on-line in May. > > > > And the DCLASS object (225 - in that region) is not > > proprietary - it's > > defined by RFC 2996. > > > > -- David > > > > > > Andrew G. Malis wrote: > > > > > > According to > > http://www.iana.org/assignments/rsvp-parameters, the range > > > 224-255 is available for FCFS allocation. It doesn't > > specify any other > > > particular allocation requirements. > > > > > > Cheers, > > > Andy > > > > > > -------- > > > > > > At 7/30/2002 10:22 AM -0400, David Charlap wrote: > > > > > >> Andrew G. Malis wrote: > > >> > > >>> For RSVP-TE (and classical RSVP) private extensions are > typically > > >>> handled by asking IANA for a new Class Number allocation > > in the range > > >>> 224-255. > > >> > > >> > > >> IANA is the organization that selects standard numbers. > > But a private > > >> extension, that is not an RFC, does not normally get an IANA > > >> allocation. Even drafts that are well on their way to > > becoming RFCs > > >> don't usually get numbers assigned until it actually > > becomes an RFC. > > >> > > >> As for the range, IANA may assign from anywhere, not > just 224-255. > > >> > > >> There are three ranges of object classes that dictate > how a router > > >> that doesn't support the object should respond to it. The range > > >> chosen depends on the required behavior: > > >> > > >> 1-127 - non-supporting routers will not process the > > message at all, > > >> but will return PathErr or ResvErr. > > >> > > >> 128-191 - non-supporting routers will drop the object but > > process the > > >> rest of the message. > > >> > > >> 192-255 - non-supporting routers will forward the object without > > >> processing it. > > >> > > >> There is absolutely nothing special about the range > 224-255. And > > >> there is no region reserved for vendor-proprietary class > > numbers, so > > >> it is always possible for a non-standard class to conflict with > > >> another class (let alone with another vendor's > non-standard class.) > > >> > > >> This is a problem with RSVP, but there's no real solution > > as long as > > >> the class ID remains an 8-bit value. (And the kind of > > radical change > > >> needed to make it wider would probably be unwelcome, given > > the number > > >> of existing implementations.) > > >> > > >> -- David > > > > > > > > > > > From owner-mpls@UU.NET Tue Jul 30 18:16:47 2002 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 ESMTP id SAA11177 for ; Tue, 30 Jul 2002 18:16:47 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzun03006 for ; Tue, 30 Jul 2002 22:17:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzun01332; Tue, 30 Jul 2002 22:17:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzun25924 for mpls-outgoing; Tue, 30 Jul 2002 22:16:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzun25919 for ; Tue, 30 Jul 2002 22:16: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 QQmzun00463 for ; Tue, 30 Jul 2002 22:16:29 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzun04984 for ; Tue, 30 Jul 2002 22:16:29 GMT Received: from djswamp.layer8.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: soggy131.drizzle.com [216.162.199.131]) id QQmzun04978 for ; Tue, 30 Jul 2002 22:16:28 GMT Received: (qmail 132 invoked by uid 1000); 30 Jul 2002 22:16:19 -0000 Date: Tue, 30 Jul 2002 15:16:19 -0700 From: Ben Black To: Tissa Senevirathne Cc: Ronald.P.Bonica@wcom.com, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: Re: Secure MPLS Message-ID: <20020730221619.GB99844@layer8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.99i Sender: owner-mpls@UU.NET Precedence: bulk Tissa, Are you implying that there are realistic weaknesses in both FR and ATM networks that you are repairing by integrating encryption into L2? If so, please elaborate upon these weaknesses and the viable threats posed. If not, then, given that MPLS really inherits much of the FR and ATM feature set relevant to traffic isolation and circuit access, I ask again what requirements are being met by Secure MPLS? Ben On Tue, Jul 30, 2002 at 08:55:32PM +0000, Tissa Senevirathne wrote: > Hi Ron > > It depends based on what purpose the MPLS tunnel is used. if you take the > case of VPLS, it is a LAN network with multi points of LSP. So there is no > easy way you could provide an upper layer encryption. > > However if you are using Encryption at the MPLS level the encryption is an > attribute between two adjacent PE. > > As an example instead of providing a costly VPLS service that requires > encryption on all tunnels, one may choose to encrypt the tunnels across > some untrusted domains, > > On the other hand can this be provided as a value added service to the > customer ? > > >From: Ron Bonica > >To: Tissa Senevirathne , mpls@uu.net > >Subject: RE: Secure MPLS > >Date: Tue, 30 Jul 2002 14:22:32 -0400 > > > >Tissa, > > > >Given that the upper layers are capable of encryption using mechanisms like > >IPSEC, why would a service provider want to encrypt the contents of an MPLS > >LSP? > > > >Wouldn't you want to push the encryption function higher in the protocol > >stack and closer to the network edges? > > > > Ron > > > > > >> -----Original Message----- > >> From: ppvpn-owner@ppvpn.francetelecom.com > >> [mailto:ppvpn-owner@ppvpn.francetelecom.com]On Behalf Of Tissa > >> Senevirathne > >> Sent: Monday, July 29, 2002 11:03 PM > >> To: pwe3@ietf.org; mpls@uu.net; ppvpn@ppvpn.francetelecom.com > >> Subject: Secure MPLS > >> > >> > >> > >> > >> > >> At Yokhoma during PWe3 session, it was indicated that hackers are > >waiting > >> for the day that L2 VPN get exposed in the WAN. > >> > >> In light of that I thought to restart the discussion on Secure MPLS. > >> > >> The link below is Secure MPLS ID. This ID present how MPLS > >> payloads can be > >> encrypted in a similar manner like IPsec when upper layers does not have > >> security capabilities. Or on links between PE to PE that are exposed to > >> public networks. > >> > >> http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt > >> > >> For those who are lot in to Security the DOI (Domain of > >> Interpretation) for > >> Secure MPLS can be found in > >> > >> http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-01.txt > >> > >> Could you provide comments and feedback. > >> > >> Thanks > >> > >> Tissa > >> > >> _________________________________________________________________ > >> MSN Photos is the easiest way to share and print your photos: > >> http://photos.msn.com/support/worldwide.aspx > >> > >> > > > > > _________________________________________________________________ > Join the world?s largest e-mail service with MSN Hotmail. > http://www.hotmail.com From owner-mpls@UU.NET Tue Jul 30 21:20:42 2002 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 ESMTP id VAA15074 for ; Tue, 30 Jul 2002 21:20:42 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzuz25442 for ; Wed, 31 Jul 2002 01:21:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzuz23635; Wed, 31 Jul 2002 01:21:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzuz16067 for mpls-outgoing; Wed, 31 Jul 2002 01:20:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzuz16036 for ; Wed, 31 Jul 2002 01:20:34 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 QQmzuz24252 for ; Wed, 31 Jul 2002 01:20:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzuz21652 for ; Wed, 31 Jul 2002 01:20:17 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f5.law4.hotmail.com [216.33.149.5]) id QQmzuz21640 for ; Wed, 31 Jul 2002 01:20:17 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Jul 2002 18:20:16 -0700 Received: from 66.7.144.1 by lw4fd.law4.hotmail.msn.com with HTTP; Wed, 31 Jul 2002 01:20:16 GMT X-Originating-IP: [66.7.144.1] From: "Tissa Senevirathne" To: h.hopkins@accent-on-networks.co.uk, pwe3@ietf.org, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com Subject: Re: [PWE3] Re: Secure MPLS Date: Wed, 31 Jul 2002 01:20:16 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Jul 2002 01:20:16.0437 (UTC) FILETIME=[6D5FB650:01C23830] Sender: owner-mpls@UU.NET Precedence: bulk FRF.17 is very helpful. After reading the document here is the summary I gathered. FRF.17 is the privacy agreement for Frame Relay and published presented in Jan 2000. The document provide both Authentication and Encryption. I am inclined to believe , availability of this document as a FRF ID indicates Frame Relay forum may have had a good motivation to consider the encryption and authentication. Drilling further into the Payload format I found that encapsulation of security header etc.. is quite similar to the work presented in secure MPLS. Both of these (FRF.17 and Secure MPLS) use work from IPSec. The advantage is one could leverage the existing crypto engines to implement the solutions at hardware level. >From: "h.hopkins" >To: "Tissa Senevirathne" >,,,, >Subject: Re: [PWE3] Re: Secure MPLS >Date: Tue, 30 Jul 2002 20:44:02 +0100 > >The Frame Relay Forum has published an Implementation Agreement on Privacy >at >http://www.frforum.com/5000/5000index.html See FRF.17 it may be relevant. > >Harman H Hopkins >Director, Accent on Networks >26 Princes Road >Felixstowe, Suffolk >IP11 7QZ >UK > >e-mail: h.hopkins@accent-on-networks.co.uk > >----- Original Message ----- >From: "Tissa Senevirathne" >To: ; ; ; > >Sent: 30 July 2002 19:09 >Subject: Re: [PWE3] Re: Secure MPLS > > > > Alan > > > > Can you give us pointers to secure Frame relay that we can use and > > compare.. > > > > > > >From: Alan Hannan > > >To: Tissa Senevirathne , pwe3@ietf.org, >mpls@UU.NET, > > > ppvpn@ppvpn.francetelecom.com > > >Subject: [PWE3] Re: Secure MPLS > > >Date: Tue, 30 Jul 2002 10:27:02 -0700 > > > > > > > > > I suggest that folks review the work done on Secure Frame Relay. > > > > > > -a > > > > > >Thus spake Ben Black (ben@layer8.net) > > > on or about Tue, Jul 30, 2002 at 09:49:16AM -0700: > > > > Could you elaborate further on the requirements for a secure MPLS > > > > mechanism? Eager hackers seems a bit vague. > > > > > > > > > > > > Ben > > > > > > > > On Tue, Jul 30, 2002 at 03:02:36AM +0000, Tissa Senevirathne wrote: > > > > > > > > > > > > > > > > > > > > At Yokhoma during PWe3 session, it was indicated that hackers are > > >waiting > > > > > for the day that L2 VPN get exposed in the WAN. > > > > > > > > > > In light of that I thought to restart the discussion on Secure >MPLS. > > > > > > > > > > The link below is Secure MPLS ID. This ID present how MPLS >payloads > > >can be > > > > > encrypted in a similar manner like IPsec when upper layers does >not > > >have > > > > > security capabilities. Or on links between PE to PE that are >exposed > > >to > > > > > public networks. > > > > > > > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt > > > > > > > > > > For those who are lot in to Security the DOI (Domain of > > >Interpretation) for > > > > > Secure MPLS can be found in > > > > > > > > > > >http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-01.txt > > > > > > > > > > Could you provide comments and feedback. > > > > > > > > > > Thanks > > > > > > > > > > Tissa > > > > > > > > > > _________________________________________________________________ > > > > > MSN Photos is the easiest way to share and print your photos: > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Tue Jul 30 22:28:18 2002 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 ESMTP id WAA16935 for ; Tue, 30 Jul 2002 22:28:18 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzvd19667 for ; Wed, 31 Jul 2002 02:29:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzvd18371; Wed, 31 Jul 2002 02:28:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzvd13347 for mpls-outgoing; Wed, 31 Jul 2002 02:28:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzvd13342 for ; Wed, 31 Jul 2002 02:28: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 QQmzvd16642 for ; Wed, 31 Jul 2002 02:28:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzvd24445 for ; Wed, 31 Jul 2002 02:28:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzvd24432 for ; Wed, 31 Jul 2002 02:28:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA25437 for ; Tue, 30 Jul 2002 22:28:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA28118 for mpls@uu.net; Tue, 30 Jul 2002 22:28:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzvd13314 for ; Wed, 31 Jul 2002 02:26:49 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 QQmzvd06235 for ; Wed, 31 Jul 2002 02:26:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzvd28526 for ; Wed, 31 Jul 2002 02:26:07 GMT Received: from vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.131]) id QQmzvd28516 for ; Wed, 31 Jul 2002 02:26:07 GMT Received: from AMALIS.vivacenetworks.com ([10.122.19.102]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Jul 2002 19:26:00 -0700 Message-Id: <5.1.0.14.2.20020730222123.07666a88@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 22:25:55 -0400 To: neil.2.harrison@bt.com From: "Andrew G. Malis" Subject: RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1 Cc: Shahram_Davari@pmc-sierra.com, david.charlap@marconi.com, mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Jul 2002 02:26:00.0954 (UTC) FILETIME=[9C7D3DA0:01C23839] Sender: owner-mpls@UU.NET Precedence: bulk Neil, >My view on this is that any body who purports to be a 'standards >organisation' should not sanction vendor (or other, eg SP) protocol >codepoints. See Q.2931 (02/95 revision is the one I'm looking at) section 4.5.8 and X.36 (04/95) Annex D for some examples of ITU-T usage of the IEEE OUI for vendor extensions and private protocol identification. Cheers, Andy From owner-mpls@UU.NET Wed Jul 31 07:41:24 2002 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 ESMTP id HAA21935 for ; Wed, 31 Jul 2002 07:41:24 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzwo06806 for ; Wed, 31 Jul 2002 11:42:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzwo29879; Wed, 31 Jul 2002 11:39:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzwo13986 for mpls-outgoing; Wed, 31 Jul 2002 11:39:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzwo13981 for ; Wed, 31 Jul 2002 11:39: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 QQmzwo12350 for ; Wed, 31 Jul 2002 11:39:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzwo29464 for ; Wed, 31 Jul 2002 11:39:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzwo29451 for ; Wed, 31 Jul 2002 11:39:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA18512 for ; Wed, 31 Jul 2002 07:39:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA22031 for mpls@uu.net; Wed, 31 Jul 2002 07:39:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzwo13960 for ; Wed, 31 Jul 2002 11:37:48 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 QQmzwo12647 for ; Wed, 31 Jul 2002 11:37:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzwo27339 for ; Wed, 31 Jul 2002 11:37:17 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 QQmzwo27329 for ; Wed, 31 Jul 2002 11:37:16 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21536; Wed, 31 Jul 2002 07:36:08 -0400 (EDT) Message-Id: <200207311136.HAA21536@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-ft-04.txt Date: Wed, 31 Jul 2002 07:36:07 -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 : Fault Tolerance for the Label Distribution Protocol (LDP) Author(s) : A. Farrel, P. Brittain Filename : draft-ietf-mpls-ldp-ft-04.txt Pages : 54 Date : 30-Jul-02 MPLS systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including LDP, CR-LDP, the switching hardware and TCP, are implementation specific. This document identifies issues in the CR-LDP specification [2] and the LDP specification [4] that make it difficult to implement an FT LSR using the current LDP and CR-LDP protocols, and proposes enhancements to the LDP specification to ease such FT LSR implementations. The extensions described here are equally applicable to CR-LDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ft-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-ft-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-ft-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020730114502.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-ft-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-ft-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020730114502.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 31 11:38:21 2002 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 ESMTP id LAA02695 for ; Wed, 31 Jul 2002 11:38:21 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzxe04304 for ; Wed, 31 Jul 2002 15:39:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzxe02674; Wed, 31 Jul 2002 15:38:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzxe01569 for mpls-outgoing; Wed, 31 Jul 2002 15:38:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzxe01564 for ; Wed, 31 Jul 2002 15:38:08 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 QQmzxe03751 for ; Wed, 31 Jul 2002 15:38:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzxe01061 for ; Wed, 31 Jul 2002 15:38:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzxe01036 for ; Wed, 31 Jul 2002 15:38:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA06063 for ; Wed, 31 Jul 2002 11:38:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA16117 for mpls@uu.net; Wed, 31 Jul 2002 11:38:01 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzxe01547 for ; Wed, 31 Jul 2002 15:37:27 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 QQmzxe00211 for ; Wed, 31 Jul 2002 15:36:57 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzxe28949 for ; Wed, 31 Jul 2002 15:36:56 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 QQmzxe28928 for ; Wed, 31 Jul 2002 15:36:56 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02495; Wed, 31 Jul 2002 11:35:46 -0400 (EDT) Message-Id: <200207311535.LAA02495@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: LSP Hierarchy with Generalized MPLS TE to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 31 Jul 2002 11:35:45 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o LSP Hierarchy with Generalized MPLS TE o Signalling Unnumbered Links in RSVP-TE o Signalling Unnumbered Links in CR-LDP o Link Bundling in MPLS Traffic Engineering The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 13, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-07.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-07.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-crldp-unnum-07.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-04.txt From owner-mpls@UU.NET Wed Jul 31 16:14:34 2002 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 ESMTP id QAA16310 for ; Wed, 31 Jul 2002 16:14:33 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzxx13554 for ; Wed, 31 Jul 2002 20:15:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzxw12076; Wed, 31 Jul 2002 20:14:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzxw13735 for mpls-outgoing; Wed, 31 Jul 2002 20:14:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmzxw13728 for ; Wed, 31 Jul 2002 20: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 QQmzxw29477 for ; Wed, 31 Jul 2002 20:13:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzxw11169 for ; Wed, 31 Jul 2002 20:13:11 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzxw11141 for ; Wed, 31 Jul 2002 20:13:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA28301 for ; Wed, 31 Jul 2002 16:13:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA14768 for mpls@uu.net; Wed, 31 Jul 2002 16:13:07 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmzxq21738 for ; Wed, 31 Jul 2002 18:40:47 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 QQmzxq09140 for ; Wed, 31 Jul 2002 18:39:50 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzxq03305 for ; Wed, 31 Jul 2002 18:39:50 GMT Received: from vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.131]) id QQmzxq03282 for ; Wed, 31 Jul 2002 18:39:46 GMT Received: from AMALIS.vivacenetworks.com ([10.120.0.2] RDNS failed) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 31 Jul 2002 11:39:24 -0700 Message-Id: <5.1.0.14.2.20020731142420.053bc340@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 31 Jul 2002 14:39:18 -0400 To: Ron Bonica From: "Andrew G. Malis" Subject: RE: Secure MPLS Cc: Tissa Senevirathne , mpls@UU.NET In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Jul 2002 18:39:25.0124 (UTC) FILETIME=[98165840:01C238C1] Sender: owner-mpls@UU.NET Precedence: bulk I agree with Ron. From the end user point of view, some problems with service provider encryption are that the tail circuits from the customer premise to the service provider are unprotected (which the obvious place to place a covert wiretap); the encryption keys are the property of the service provider, not the end user; and the keys could be subject to government escrow or seizure depending on where you are in the world. This is certainly the case in the US (see http://www.fcc.gov/calea/ ). Cheers, Andy ------ At 7/30/2002 02:22 PM -0400, Ron Bonica wrote: >Tissa, > >Given that the upper layers are capable of encryption using mechanisms like >IPSEC, why would a service provider want to encrypt the contents of an MPLS >LSP? > >Wouldn't you want to push the encryption function higher in the protocol >stack and closer to the network edges? > > Ron From owner-mpls@UU.NET Wed Jul 31 16:53:23 2002 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 ESMTP id QAA17958 for ; Wed, 31 Jul 2002 16:53:23 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzxz20136 for ; Wed, 31 Jul 2002 20:54:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzxz15889; Wed, 31 Jul 2002 20:52:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzxz17005 for mpls-outgoing; Wed, 31 Jul 2002 20:51:50 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzxz16998 for ; Wed, 31 Jul 2002 20:51:34 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 QQmzxz16142 for ; Wed, 31 Jul 2002 20:50:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzxz02682 for ; Wed, 31 Jul 2002 20:50:14 GMT Received: from mm02snlnto.sandia.gov by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mm02snlnto.sandia.gov [132.175.109.21]) id QQmzxz02650 for ; Wed, 31 Jul 2002 20:50:14 GMT Received: from 132.175.109.4 by mm02snlnto.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 31 Jul 2002 14:46:49 -0600 X-Server-Uuid: 95b8ca9b-fe4b-44f7-8977-a6cb2d3025ff Received: from es08snlnt.sandia.gov (es08snlnt.sandia.gov [134.253.130.11]) by mailgate2.sandia.gov (8.12.5/8.12.5) with ESMTP id g6VKo5Gc016921; Wed, 31 Jul 2002 14:50:05 -0600 (MDT) Received: by es08snlnt.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Wed, 31 Jul 2002 14:50:04 -0600 Message-ID: <9A4B2157EFDBE546BECD68C62AC3B1C805DA26E7@es05snlnt> From: "Black, Stephen" To: "'Andrew G. Malis'" , "Ron Bonica" cc: "Tissa Senevirathne" , "'mpls@UU.NET'" Subject: RE: Secure MPLS Date: Wed, 31 Jul 2002 14:50:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Filter-Version: 1.8 (sass2426) X-WSS-ID: 11569333388696-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit To a point I agree with Ron also... but there are other considerations to look at... Such as government/corporate clients who need to have an ISP guarantee that their links are secure (i.e. a link between FBI and CIA, or a link from Intel in CA to Intel in NY). There are also military networks that might want to implement a secure form of MPLS. Granted this is a very small piece of the pie but it should be worth putting some effort into. As a client I'd rather have a combination of layers that incorporates security rather than a higher layer where the lower layers can be compromised without my knowledge. Just running IPSEC and a firewall is like putting all your eggs in one basket. Let the politicians worry about the escrow and seizure. Steve -----Original Message----- From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] Sent: Wednesday, July 31, 2002 12:39 PM To: Ron Bonica Cc: Tissa Senevirathne; mpls@UU.NET Subject: RE: Secure MPLS I agree with Ron. From the end user point of view, some problems with service provider encryption are that the tail circuits from the customer premise to the service provider are unprotected (which the obvious place to place a covert wiretap); the encryption keys are the property of the service provider, not the end user; and the keys could be subject to government escrow or seizure depending on where you are in the world. This is certainly the case in the US (see http://www.fcc.gov/calea/ ). Cheers, Andy ------ At 7/30/2002 02:22 PM -0400, Ron Bonica wrote: >Tissa, > >Given that the upper layers are capable of encryption using mechanisms like >IPSEC, why would a service provider want to encrypt the contents of an MPLS >LSP? > >Wouldn't you want to push the encryption function higher in the protocol >stack and closer to the network edges? > > Ron From owner-mpls@UU.NET Wed Jul 31 17:15:03 2002 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 ESMTP id RAA18400 for ; Wed, 31 Jul 2002 17:15:02 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzyb06452 for ; Wed, 31 Jul 2002 21:16:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzya04281; Wed, 31 Jul 2002 21:14:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzya11041 for mpls-outgoing; Wed, 31 Jul 2002 21:14:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzya11036 for ; Wed, 31 Jul 2002 21:14: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 QQmzya28444 for ; Wed, 31 Jul 2002 21:14:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzya18533 for ; Wed, 31 Jul 2002 21:14:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzya18525 for ; Wed, 31 Jul 2002 21:14:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA03197 for ; Wed, 31 Jul 2002 17:14:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA21703 for mpls@uu.net; Wed, 31 Jul 2002 17:14:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzya10988 for ; Wed, 31 Jul 2002 21:13: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 QQmzya28225 for ; Wed, 31 Jul 2002 21:12:40 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzya26704 for ; Wed, 31 Jul 2002 21:12:39 GMT Received: from netreference.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netreference.com [209.246.37.190]) id QQmzya26692 for ; Wed, 31 Jul 2002 21:12:39 GMT Received: from ILAZAR.mplsrc.com (209.246.37.179) by netreference.com with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 31 Jul 2002 17:14:31 -0400 Message-Id: <5.1.0.14.2.20020731171123.00b1c850@localhost> X-Sender: news/mplsrc.com@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 31 Jul 2002 17:13:23 -0400 To: mplsrc_news@mplsrc.com From: MPLS RC News Subject: MPLScon Fall 2002 Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk We're pleased to announce that the conference program for MPLScon 2002 is now available at http://www.mplscon.com/attend/conf_at_a_glance.html MPLScon Fall 2002 will take place on October 7-10 in Denver, CO. Keynote speakers include Luca Martini, Dr. Yakov Rekhter and Dr. Bruce Davie. From owner-mpls@UU.NET Wed Jul 31 18:05:49 2002 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 ESMTP id SAA19869 for ; Wed, 31 Jul 2002 18:05:49 -0400 (EDT) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzye02233 for ; Wed, 31 Jul 2002 22:06:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzye00427; Wed, 31 Jul 2002 22:05:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzye01152 for mpls-outgoing; Wed, 31 Jul 2002 22:05:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzye29531 for ; Wed, 31 Jul 2002 22:05: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 QQmzye25917 for ; Wed, 31 Jul 2002 22:05:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzye21995 for ; Wed, 31 Jul 2002 22:05:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmzye21990 for ; Wed, 31 Jul 2002 22:05:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA06519 for ; Wed, 31 Jul 2002 18:05:01 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA27318 for mpls@uu.net; Wed, 31 Jul 2002 18:05:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmzye26854 for ; Wed, 31 Jul 2002 22:03: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 QQmzye19574 for ; Wed, 31 Jul 2002 22:02:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzye20836 for ; Wed, 31 Jul 2002 22:02:10 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 QQmzye20829 for ; Wed, 31 Jul 2002 22:02:09 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19802; Wed, 31 Jul 2002 18:00:59 -0400 (EDT) Message-Id: <200207312200.SAA19802@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Rescinding Last Call for "Signalling Unnumbered Links in CR-LDP" Reply-to: iesg@ietf.org Date: Wed, 31 Jul 2002 18:00:59 -0400 Sender: owner-mpls@UU.NET Precedence: bulk The Internet Draft "Signalling Unnumbered Links in CR-LDP" was mistakenly included in the list of MPLS TE last calls. This Internet Draft is not currently under consideration by the IESG. Sorry for any confusion. From owner-mpls@UU.NET Wed Jul 31 22:44:20 2002 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 ESMTP id WAA25107 for ; Wed, 31 Jul 2002 22:44:19 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzyx06045 for ; Thu, 1 Aug 2002 02:45:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmzyw04827; Thu, 1 Aug 2002 02:44:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQmzyw19649 for mpls-outgoing; Thu, 1 Aug 2002 02:44:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmzyw19611 for ; Thu, 1 Aug 2002 02:44: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 QQmzyw09294 for ; Thu, 1 Aug 2002 02:44:00 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQmzyw01050 for ; Thu, 1 Aug 2002 02:43:59 GMT Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmzyw01037 for ; Thu, 1 Aug 2002 02:43:59 GMT Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 1 Aug 2002 03:44:07 +0100 Message-ID: To: Andy.Malis@vivacenetworks.com Cc: mpls@UU.NET Subject: RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1 Date: Thu, 1 Aug 2002 03:43:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Andy, > >My view on this is that any body who purports to be a 'standards > >organisation' should not sanction vendor (or other, eg SP) protocol > >codepoints. > > See Q.2931 (02/95 revision is the one I'm looking at) section > 4.5.8 and > X.36 (04/95) Annex D for some examples of ITU-T usage of the > IEEE OUI for > vendor extensions and private protocol identification. NH=> And therefore the conclusion is?.........you seem to be saying something like 'if X commits a crime it now gives everyone the right and also go and commit the same crime'. I don't care which stds body does this....it simply is not right in principle IMO. regards, Neil