From owner-mpls@UU.NET Mon Jan 3 08:44:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00414 for ; Mon, 3 Jan 2000 08:44:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwkc04860; Mon, 3 Jan 2000 13:44:03 GMT Received: by mail-control.mail.uu.net id QQhwkc28985 for mpls-outgoing; Mon, 3 Jan 2000 13:43:35 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwkc28980 for ; Mon, 3 Jan 2000 13:43:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwkc05956 for ; Mon, 3 Jan 2000 08:43:24 -0500 (EST) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQhwkc04345 for ; Mon, 3 Jan 2000 13:43:23 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00373; Mon, 3 Jan 2000 08:43:22 -0500 (EST) Message-Id: <200001031343.IAA00373@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-wang-mpls-loop-probe-00.txt Date: Mon, 03 Jan 2000 08:43:22 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A probe method in MPLS loop avoidance Author(s) : W. Yahong Filename : draft-wang-mpls-loop-probe-00.txt Pages : 5 Date : 30-Dec-99 This paper introduces a very simple mechanism, based on 'probe' message, which can be used for loop avoidance in the case that a LSP is changed. This probe mechanism is based on the idea that in the situation of one LSR has a new next hop and changes the LSP to new next hop, if this change leads to a loop, the only reason for the loop formation is that the LSR changes its next hop. So that we use a very simple length-fixed probe message, no state is needed to keep in the tandem LSRs, and the message primitives are very limited and simple. Also this method is flexible and robust. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wang-mpls-loop-probe-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wang-mpls-loop-probe-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-wang-mpls-loop-probe-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: <19991230081259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wang-mpls-loop-probe-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-wang-mpls-loop-probe-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991230081259.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jan 4 01:18:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15094 for ; Tue, 4 Jan 2000 01:18:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwmr02156; Tue, 4 Jan 2000 06:17:54 GMT Received: by mail-control.mail.uu.net id QQhwmr24378 for mpls-outgoing; Tue, 4 Jan 2000 06:17:17 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhwmr24368 for ; Tue, 4 Jan 2000 06:17:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwmr25264 for ; Tue, 4 Jan 2000 01:17:02 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQhwmr01584 for ; Tue, 4 Jan 2000 06:17:01 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jan 2000 06:16:38 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FDF0@monk.datcon.co.uk> From: Adrian Farrel To: "Ash, Gerald R (Jerry), ALARC" , "'mpls@UU.NET'" Subject: RE: I-D ACTION:draft-ietf-mpls-crlsp-modify-00.txt Date: Tue, 4 Jan 2000 06:16:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jerry, hi. We've already discussed my major points with this draft, and they've also recently been raised on the list. Here are a few additional points, typos and editorial thoughts. I hope they are of use. Happy New Year, Adrian In sections 1 and 3 the text still refers to the _action indicator flag_ as an extension to CR-LDP. It is, of course, now part of the spec and the _modify_ value is defined. I suggest that the text be changed to read something like... The LSP modification feature can be supported by CD-LDP by use of the _modify_ value for the _action indicator flag_ in the LSPID TLV. In section 2 you define the convention Lid: but in the text you use L-id: In section 2 you might move FTN to below NHLFE. In section 3 you twice refer to the action indication flag (should read indicator). 4.1, para 2. For "in the messages" read "in the message". 4.1 para 2. Insert "its" to read "R1 now still has an entry in its FTN". 4.1 para 3. I think it would be useful to clarify at this point that bandwidth is never decreased while processing a modify Label Request. I suggest that the last part of the paragraph should read something like... (I have also made a suggested change to the order of the words in the penultimate sentence for clarity.) bandwidth required and derives the new service class. Compared with the already reserved bandwidth for L-id1, Ri now reserves only any increase in the bandwidth requirements. A reduction in bandwidth requirements is only actioned when the old label is released. This prevents Ri from doing bandwidth double booking. If a new service class is requested, Ri also prepares to receive the traffic on L1 in just the same way as handling it for a Label Request Message, perhaps using a different type of queue. Ri assigns a new label for the Label Request Message. 4.1 para 4. Insert "its" to read "R1 can now activate the new entry in its FTN". 4.1 para 5, penultimate line. Should "R1" read "Ri"? 4.1 para 5, last line. Insert "s" to read "another set of labels". 4.1 para 5 (or 6 depending on the page break!) The reference to using modify to reroute an LSP is fine but perhaps a bit thin. In particular, the previous description of the behavior for assigning and releasing labels does not apply itself well to the case where the LSPID only has one entry on parts of the path where the path has diverged. I suggest that an additional subsection describing reroute should be added. I'd be happy to draft some text if you like. 4.2 Missing blank line between the paragraphs. 4.3 It is, perhaps, stating the obvious, but I think this section would benefit from a direct statement such as... In the event of a modification failure, all modifications to the LSP including the holding priority must be restored to their original values. 5.0 should be numbered simply 5. 5.0 para 1, last sentence. For "priority" read "priorities". 5.0 para 2 and 3. Many small typos. Updated version below. The network operator wants to control the resource on the links of LSRs, so each LSR keeps the usage status of its links and based on the usage history, each link is assigned a current threshold priority Pi. Which means that the link has no bandwidth available for a Label Request with a setup priority lower than Pi. When an LSP's bandwidth needs to be modified, the operator uses a policy based algorithm to assign a priority for its modification request, say Mp for LSP L2. Then the ingress LSR sends Label Request message with (Setup Priority = Mp). The rule is then only if there is enough bandwidth on the link and, the Setup priority in the Label Request Message is higher in priority (Mp numerically smaller) than Pi of the link, the Label Request Message will be accepted by the LSR. Otherwise, the Label Request message will be rejected with a Notification message indicating that there aren't enough resources. It should also be noted that when OSPF (or IS-IS) floods the link available bandwidth information, the available bandwidth associated with priority lower than Pi (numerical value bigger) should be indicated as _0_. This procedure based on a priority threshold Pi is implementation specific and value added. It offers networks flexibility to prioritize and control its resources. The calculation of Mp is network dependent, based on the operator's own algorithm. For example, the operator may assign a higher Mp to L2 if L2 belongs to a customer with _Key_ priority. The operator may also collect the actual usage of each LSP and assign a high Mp to L2 if in the past week, L2 has exceeded its reserved bandwidth by 2 times on average, and the customer of L2 agrees to increase its bandwidth for a better guaranteed service. Some operators may try to increase the bandwidth of L2 on its existing path unsuccessfully as there isn't enough bandwidth there. Then the operator is willing to change the path of L2 in order to increase its bandwidth, but with a lower priority Mp this time as L2 is now routed on its secondary path, which should yield priority to the LSPs that are on its primary paths here. Section 7. Should this section include a comment about security with respect to modifications made to LSPs by malign agents? -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Tue Jan 4 05:02:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26888 for ; Tue, 4 Jan 2000 05:02:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwng17449; Tue, 4 Jan 2000 10:02:26 GMT Received: by mail-control.mail.uu.net id QQhwng01409 for mpls-outgoing; Tue, 4 Jan 2000 10:01:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhwng01340 for ; Tue, 4 Jan 2000 10:01:30 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwng09751 for ; Tue, 4 Jan 2000 05:01:28 -0500 (EST) Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQhwng19343 for ; Tue, 4 Jan 2000 10:01:26 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id B94E9352; Tue, 4 Jan 2000 11:01:21 +0100 (MET) Received: from flefauch-8kcdt.cisco.com (localhost [127.0.0.1]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA12848; Tue, 4 Jan 2000 11:01:16 +0100 (MET) Message-Id: <200001041001.LAA12848@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 04 Jan 2000 10:52:49 +0100 To: "Thomas Wolfram" From: Francois Le Faucheur Subject: Re: Current status of IPv6 support? Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Thomas, At 17:47 21/12/1999 +0100, Thomas Wolfram wrote: > >But other drafts seem to make few provisions for IPv6 if at >all (ldp, icmp, diff-ext). We will add a statement in the next rev of the diff-ext I-D that it is applicable to both IPv4 and IPv6. >And what about the extended RSVP? It supports IPv6 prefixes >but tunnel sender and end point addresses as well as Extended >Tunnel IDs are defined using IPv4 addresses. So IPv6 could be >transmiited over a ER-LSP but the LERs/LSRs themselves would >still have to run IPv4, right? > as per : "The LABEL_REQUEST object indicates that a label binding for this path is requested and also provides an indication of the network layer protocol that is to be carried over this path. The reason for this is that the network layer protocol sent down an LSP cannot be assumed to be IPv4 and cannot be deduced from the L2 header, which simply identifies the higher layer protocol as MPLS." and : "Label Request without Label Range class = 19, C_Type = 1 (need to get an official class num from the IANA) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L3PID an identifier of the layer 3 protocol using this path. Standard Ethertype values are used. So, I'd say it is possible to set up LSP Tunnels via the currently defined RSVP extensions to transport IPv6. Francois > >Thanks in advance, >-- > NOTE : New Mobile Number +33 6 89 10 81 59 _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Phone Office: +33 4 92 96 75 64 Phone Home Office: +33 4 92 94 00 78 Mobile : +33 6 89 10 81 59 Vmail: +33 1 69 18 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Tue Jan 4 11:55:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02245 for ; Tue, 4 Jan 2000 11:55:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwoh06643; Tue, 4 Jan 2000 16:54:22 GMT Received: by mail-control.mail.uu.net id QQhwoh27824 for mpls-outgoing; Tue, 4 Jan 2000 16:53:59 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhwoh27818 for ; Tue, 4 Jan 2000 16:53:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwoh09351 for ; Tue, 4 Jan 2000 11:53:51 -0500 (EST) From: frost@eecs.ukans.edu Received: from lighthouse-el0.sprintcorp.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: lighthouse.sprintcorp.com [144.230.241.2]) id QQhwoh06179 for ; Tue, 4 Jan 2000 16:53:51 GMT Received: from dns.sprintcorp.com by lighthouse-el0.sprintcorp.com via smtpd (for wodc7-1.corprelay.mail.uu.net [192.48.96.68]) with SMTP; 4 Jan 2000 16:53:46 UT Received: from frost-pc (frost-pc.sprintcorp.com [144.230.8.10]) by dns.sprintcorp.com (8.9.1/8.8.0) with SMTP id JAA17591 for ; Tue, 4 Jan 2000 09:32:39 -0600 Message-Id: <3.0.6.32.20000104093504.00a3a390@pop.ittc.ukans.edu> X-Sender: frost@pop.ittc.ukans.edu X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 04 Jan 2000 09:35:04 -0600 To: mpls@UU.NET Subject: Reordering and MPLS? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Is there a requirement to preserve packet order in MPLS? That is, are MPLS enabled network elements (individual routers or a collection of routers in a single location) required to forward IP packet in the order they are received? Thanks ====================================================================== Dr. Victor S. Frost Sabbatical contact information: Sprint Dan F. Servey Distinguished Professor Phone: 913 534 5334 Electrical Engineering Fax: 913 534 2526 and Computer Science victor.frost@mail.sprint.com Information and Telecommunication 9300 Metcalf Technology Center Overland Park, Kansas 66212 University of Kansas 2291 Irving Hill Dr. Lawrence, Kansas 66044-7541 Phone: (785) 864-4833 FAX:(785) 864-7789 e-mail: frost@eecs.ukans.edu http://www.ittc.ukans.edu/ From owner-mpls@UU.NET Tue Jan 4 12:05:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02444 for ; Tue, 4 Jan 2000 12:05:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwoi12347; Tue, 4 Jan 2000 17:03:38 GMT Received: by mail-control.mail.uu.net id QQhwoi00956 for mpls-outgoing; Tue, 4 Jan 2000 17:03:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhwoi00861 for ; Tue, 4 Jan 2000 17:03:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwoi10213 for ; Tue, 4 Jan 2000 12:03:01 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQhwoi10562 for ; Tue, 4 Jan 2000 17:03:00 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA21398; Tue, 4 Jan 2000 09:02:53 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jan 2000 09:02:53 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE413514EE@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'frost@eecs.ukans.edu'" , mpls@UU.NET Subject: RE: Reordering and MPLS? Date: Tue, 4 Jan 2000 09:00:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, No. Preserving the order of packets is not an MPLS requirement. In fact in some cases such as E-LSP setup (explained in draft-ietf-mpls-diff-ext-02, in which one LSP can carry multiple COS traffics), packets will be reordered based on their COS. Shahram Davari Systems Engineer, Product Research PMC-Sierra Inc. 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 > -----Original Message----- > From: frost@eecs.ukans.edu [mailto:frost@eecs.ukans.edu] > Sent: Tuesday, January 04, 2000 10:35 AM > To: mpls@UU.NET > Subject: Reordering and MPLS? > > > > Is there a requirement to preserve packet order in MPLS? > That is, are MPLS > enabled network elements (individual routers or a collection > of routers in > a single location) required to forward IP packet in the order they are > received? > > Thanks > ====================================================================== > Dr. Victor S. Frost Sabbatical contact information: > Sprint > Dan F. Servey Distinguished Professor Phone: 913 534 5334 > Electrical Engineering Fax: 913 534 2526 > and Computer Science victor.frost@mail.sprint.com > Information and Telecommunication 9300 Metcalf > Technology Center Overland Park, Kansas 66212 > University of Kansas > 2291 Irving Hill Dr. > Lawrence, Kansas 66044-7541 > Phone: (785) 864-4833 FAX:(785) 864-7789 > e-mail: frost@eecs.ukans.edu http://www.ittc.ukans.edu/ > From owner-mpls@UU.NET Tue Jan 4 12:16:45 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02657 for ; Tue, 4 Jan 2000 12:16:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwoi19053; Tue, 4 Jan 2000 17:14:44 GMT Received: by mail-control.mail.uu.net id QQhwoi07178 for mpls-outgoing; Tue, 4 Jan 2000 17:14:07 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhwoi07168 for ; Tue, 4 Jan 2000 17:14:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwoi29275 for ; Tue, 4 Jan 2000 12:14:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhwoi17194 for ; Tue, 4 Jan 2000 17:14:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Jan 4 12:13:16 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.40.142]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA15070; Tue, 4 Jan 2000 12:13:09 -0500 (EST) Message-ID: <38722B3C.A01A42F3@lucent.com> Date: Tue, 04 Jan 2000 12:17:48 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: frost@eecs.ukans.edu CC: mpls@UU.NET Subject: Re: Reordering and MPLS? References: <3.0.6.32.20000104093504.00a3a390@pop.ittc.ukans.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dr. Frost You wrote: > > Is there a requirement to preserve packet order in MPLS? That is, are MPLS > enabled network elements (individual routers or a collection of routers in > a single location) required to forward IP packet in the order they are > received? This is not a requirement of either network elements or the network as a whole. It is probably a reasonable expectation of network elements and may be a reasonable expectation of the network as a whole if implementations observe - or allow observation of - certain rules. For example, if we assume that implementations (network elements) do not themselves change the order of packet delivery (either naturally as a consequence of queuing behavior within the implementation, or as an enabled option), then we can get ordered behavior out of the network as a whole if we are able to ensure (again, as a result of natural or enabled network element behavior) that all the packets associated with a specific stream are forwarded from one network element to another in exactly the same way and at all times. Jeremy Lawrence pointed out earlier that normal routing changes will affect the behavior of the network as a whole in being able to guarantee this behavior. It is possible to get around this using some combination of explicit routing and route pinning. Of course, it is essential that packets which must be delivered in order follow the same LSP and that this LSP either follows exactly one path, or includes mechanisms to preserve ordered delivery on potential multiple paths. And, of course, what you mean by ordered delivery may depend on whether or not you mean to include variance in queuing treatment for different levels of service. If you intend that packets receiving different levels of service are to be considered separate streams from an ordering perspective, then the above applies. > > Thanks > ====================================================================== > Dr. Victor S. Frost Sabbatical contact information: > Sprint > Dan F. Servey Distinguished Professor Phone: 913 534 5334 > Electrical Engineering Fax: 913 534 2526 > and Computer Science victor.frost@mail.sprint.com > Information and Telecommunication 9300 Metcalf > Technology Center Overland Park, Kansas 66212 > University of Kansas > 2291 Irving Hill Dr. > Lawrence, Kansas 66044-7541 > Phone: (785) 864-4833 FAX:(785) 864-7789 > e-mail: frost@eecs.ukans.edu http://www.ittc.ukans.edu/ From owner-mpls@UU.NET Tue Jan 4 13:03:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03417 for ; Tue, 4 Jan 2000 13:03:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwom19261; Tue, 4 Jan 2000 18:02:48 GMT Received: by mail-control.mail.uu.net id QQhwom12375 for mpls-outgoing; Tue, 4 Jan 2000 18:02:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhwom12229 for ; Tue, 4 Jan 2000 18:01:54 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwom13432 for ; Tue, 4 Jan 2000 13:01:37 -0500 (EST) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQhwom18217 for ; Tue, 4 Jan 2000 18:01:05 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA26091 for ; Tue, 4 Jan 2000 13:01:03 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA00770 for ; Tue, 4 Jan 2000 13:01:03 -0500 (EST) Message-Id: <200001041801.NAA00770@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: WG last call status Date: Tue, 04 Jan 2000 13:01:03 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk The last call on BGP labels, draft-ietf-mpls-bgp4-mpls-03.txt, closed 12/23/99, 5 pm est. A new draft reflecting the last call comments will be issued within a week. The last call on MPLS ICMP, draft-ietf-mpls-icmp-01.txt, closed 12/20/99, 5 pm est. There were no comments to the list. The draft will be forwarded to the IESG for action. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Jan 4 14:14:05 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04385 for ; Tue, 4 Jan 2000 14:14:04 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwoq04632; Tue, 4 Jan 2000 19:12:54 GMT Received: by mail-control.mail.uu.net id QQhwoq01079 for mpls-outgoing; Tue, 4 Jan 2000 19:12:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhwoq01066 for ; Tue, 4 Jan 2000 19:12:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwoq23159 for ; Tue, 4 Jan 2000 14:12:09 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQhwoq04026 for ; Tue, 4 Jan 2000 19:12:09 GMT Received: from mjork-pc (mjork-pc.avici.com [10.1.2.168]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id OAA01595 for ; Tue, 4 Jan 2000 14:12:07 -0500 (EST) Message-Id: <4.1.20000104135406.00a9f2f0@mailhost.avici.com> X-Sender: mjork@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 04 Jan 2000 14:12:08 -0500 To: mpls@UU.NET From: Markus Jork Subject: bug in draft-ietf-mpls-rsvp-lsp-tunnel-04 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Section 3 of the draft states that an EXPLICIT_ROUTE object is only applicable to RSVP Path messages. But it also needs to go into PathTear messages so that they can be routed correctly. And the ResvConf message also needs the EXPLICIT_ROUTE object (if anybody cares about ResvConf in the MPLS TE context). I tried to research the status of this draft. The MPLS WG meeting minutes say it's in IETF last call. Did I just miss the announcement on the IETF list or hasn't the last call been announced yet? Markus From owner-mpls@UU.NET Tue Jan 4 15:19:53 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05631 for ; Tue, 4 Jan 2000 15:19:52 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwov15237; Tue, 4 Jan 2000 20:18:35 GMT Received: by mail-control.mail.uu.net id QQhwov13319 for mpls-outgoing; Tue, 4 Jan 2000 20:18:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhwov13297 for ; Tue, 4 Jan 2000 20:17:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwov27680 for ; Tue, 4 Jan 2000 15:17:52 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQhwov14469 for ; Tue, 4 Jan 2000 20:17:50 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id PAA14393; Tue, 4 Jan 2000 15:17:37 -0500 Date: Tue, 4 Jan 2000 15:17:37 -0500 From: "J. Noel Chiappa" Message-Id: <200001042017.PAA14393@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: Reordering and MPLS? Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Eric Gray >> Is there a requirement to preserve packet order in MPLS? > It is probably a reasonable expectation of network elements and may be a > reasonable expectation of the network as a whole ... if we assume that > implementations .. do not themselves change the order of packet delivery > .. then we can get ordered behavior out of the network as a whole What you say is of course theoretically correct. However, as I expect everyone already understands, it would be extremely unwise to try and guarantee this "in-order" property of the network as a whole, to the point where implementations in endnodes rely on it. It would be equally unwise for endnodes to rely on this guarantee, even if the network tried to make it. The reasoning is simple. One one hand, it only takes one bug, in a complex mass of mechanism distributed across many independent components, to break this property. On the other hand, the cost (in performance, and complexity) of building endnodes which do not rely on this property is minimal. Given the importance of robustness (i.e. fault tolerance), including it in this area, when the cost is so minimal, is really the only choice. To expand on the cost a bit, ideas like header-prediction mean that one does not pay the overhead of dealing with out-of-order packets on every normal packet. Checks for out-of-order packets, and waiting queued out-of-order packets, can be performed only if the incoming packet is not the "next expected packet". Also, out-of-order packets are handled in much the same way as the latter packets in a burst, if an early one is dropped - so most of the mechanism to handle them has to be there anyway. If the point of the question was not literally "required", but rather "the network should try hard to keep packets in order", that's a different point, to which the answer is clearly "yes". Out-of-order packets will likely have a performance impact. However, exactly how hard the network should try is a complex subject. For exmple, it may enable great simplification in the network, and network elements, if intermediate elements are allowed to run a low-probability risk of reordering a packet (e.g. in the routing case you cite). Noel From owner-mpls@UU.NET Tue Jan 4 15:23:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05674 for ; Tue, 4 Jan 2000 15:23:12 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwov14665; Tue, 4 Jan 2000 20:18:01 GMT Received: by mail-control.mail.uu.net id QQhwov13275 for mpls-outgoing; Tue, 4 Jan 2000 20:17:37 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwov13263 for ; Tue, 4 Jan 2000 20:17:28 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwov29339 for ; Tue, 4 Jan 2000 15:17:24 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQhwov11919 for ; Tue, 4 Jan 2000 20:17:24 GMT Received: from mjork-pc (mjork-pc.avici.com [10.1.2.168]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id PAA05497 for ; Tue, 4 Jan 2000 15:17:12 -0500 (EST) Message-Id: <4.1.20000104150839.00aa7660@mailhost.avici.com> X-Sender: mjork@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 04 Jan 2000 15:17:12 -0500 To: mpls@UU.NET From: Markus Jork Subject: Re: bug in draft-ietf-mpls-rsvp-lsp-tunnel-04 In-Reply-To: <4.1.20000104135406.00a9f2f0@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk I wrote: >Section 3 of the draft states that an EXPLICIT_ROUTE object >is only applicable to RSVP Path messages. >But it also needs to go into PathTear messages so that they >can be routed correctly. And the ResvConf message also >needs the EXPLICIT_ROUTE object (if anybody cares about >ResvConf in the MPLS TE context). I might have been too quick calling this a bug. Thinking about it some more, one can figure out where to forward the PathTear by looking at the existing path state it refers to and take the explicit route from there. Was this the intention of the spec? Markus From owner-mpls@UU.NET Tue Jan 4 17:56:31 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08609 for ; Tue, 4 Jan 2000 17:56:31 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwpf28733; Tue, 4 Jan 2000 22:54:47 GMT Received: by mail-control.mail.uu.net id QQhwpf10409 for mpls-outgoing; Tue, 4 Jan 2000 22:54:11 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhwpf10404 for ; Tue, 4 Jan 2000 22:54:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwpf16813 for ; Tue, 4 Jan 2000 17:54:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhwpf24526 for ; Tue, 4 Jan 2000 22:54:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Jan 4 17:53:52 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.41.228]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA22964; Tue, 4 Jan 2000 17:53:45 -0500 (EST) Message-ID: <38727B10.19A5F0C3@lucent.com> Date: Tue, 04 Jan 2000 17:58:24 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "J. Noel Chiappa" CC: mpls@UU.NET Subject: Re: Reordering and MPLS? References: <200001042017.PAA14393@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Noel. Please see below. You wrote: > > > From: Eric Gray > > >> Is there a requirement to preserve packet order in MPLS? > > > It is probably a reasonable expectation of network elements and may be a > > reasonable expectation of the network as a whole ... if we assume that > > implementations .. do not themselves change the order of packet delivery > > .. then we can get ordered behavior out of the network as a whole > > What you say is of course theoretically correct. Interesting that the hacked up version above - while it reads like a sentence - is just as clearly incorrect. I'm glad I didn't say it... :-) > > However, as I expect everyone already understands, it would be extremely > unwise to try and guarantee this "in-order" property of the network as a > whole, to the point where implementations in endnodes rely on it. It would be > equally unwise for endnodes to rely on this guarantee, even if the network > tried to make it. It is clearly expensive to guarantee in order delivery for all packets transmitted across a network. But it is easily justified for specific uses of the network. For example, if I want to transport data using an LSP from one end node to another that needs to be delivered in order - just because I'm ornery and simply want to skip the step of adding an IP header - there should be no reason why I should not be able to do this. There are technologies today that allow this. > > The reasoning is simple. One one hand, it only takes one bug, in a complex > mass of mechanism distributed across many independent components, to break > this property. On the other hand, the cost (in performance, and complexity) of > building endnodes which do not rely on this property is minimal. Given the > importance of robustness (i.e. fault tolerance), including it in this area, > when the cost is so minimal, is really the only choice. Interestingly enough, there are some companies who've had it as a long term goal to produce equipment that is not so buggy. > > To expand on the cost a bit, ideas like header-prediction mean that one does > not pay the overhead of dealing with out-of-order packets on every normal > packet. Checks for out-of-order packets, and waiting queued out-of-order > packets, can be performed only if the incoming packet is not the "next > expected packet". Also, out-of-order packets are handled in much the same way > as the latter packets in a burst, if an early one is dropped - so most of the > mechanism to handle them has to be there anyway. > > If the point of the question was not literally "required", but rather "the > network should try hard to keep packets in order", that's a different point, > to which the answer is clearly "yes". Out-of-order packets will likely have a > performance impact. However, exactly how hard the network should try is a > complex subject. > > For exmple, it may enable great simplification in the network, and network > elements, if intermediate elements are allowed to run a low-probability risk > of reordering a packet (e.g. in the routing case you cite). Actually, even the low probability risk should be eliminated if a specific network application is using an LSP that was setup using an explicit route and/or route pinning. The only reason why "should be" rather than "will be" is because it is always possible that there are companies out there that have not had it as a long term goal to produce equipment that is not so buggy. :-) For an application of LSPs that requires in order delivery, it should take a network event that results in lost connectivity to cause the LSP to fail. This is appropriate, since - for at least one application of this sort - out of order delivery is exactly the same thing as lost connectivity. > > Noel From owner-mpls@UU.NET Tue Jan 4 17:59:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08711 for ; Tue, 4 Jan 2000 17:59:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwpf01016; Tue, 4 Jan 2000 22:58:48 GMT Received: by mail-control.mail.uu.net id QQhwpf10640 for mpls-outgoing; Tue, 4 Jan 2000 22:58:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwpf10635 for ; Tue, 4 Jan 2000 22:58:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwpf17071 for ; Tue, 4 Jan 2000 17:58:02 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhwpf00417 for ; Tue, 4 Jan 2000 22:58:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Tue Jan 4 17:56:42 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.41.228]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA23034; Tue, 4 Jan 2000 17:56:35 -0500 (EST) Message-ID: <38727BBB.52A32E99@lucent.com> Date: Tue, 04 Jan 2000 18:01:15 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Multi-Protocol Label Switching WG Subject: [Fwd: WG last call status] Content-Type: multipart/mixed; boundary="------------D430679F67F102257FE4990A" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------D430679F67F102257FE4990A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry to forward this to the list. I sent it to George and it bounced... --------------D430679F67F102257FE4990A Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from ihrh2.emsr.lucent.com by mvjok.mv.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA02772; Tue, 4 Jan 2000 14:22:19 -0500 Received: by ihrh2.emsr.lucent.com (SMI-8.6/EMS-1.5 Solaris/emsr) id NAA22089; Tue, 4 Jan 2000 13:22:16 -0600 Received: by ihrh2.emsr.lucent.com (SMI-8.6/EMS-1.5 Solaris/emsr) id NAA21720; Tue, 4 Jan 2000 13:21:50 -0600 Received: from zubin.dnrc.bell-labs.com by ihrh2.emsr.lucent.com (SMI-8.6/EMS-1.5 Solaris/emsr) id NAA20837; Tue, 4 Jan 2000 13:21:42 -0600 Received: from lucent.com (ewgray.lra.lucent.com [135.255.41.228]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA18409; Tue, 4 Jan 2000 14:21:12 -0500 (EST) Message-ID: <3872493F.AAF93690@lucent.com> Date: Tue, 04 Jan 2000 14:25:51 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow Subject: Re: WG last call status References: <200001041801.NAA00770@lir.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George, I assume that last call is also closed for the draft on LDP state machines. I will be working with the others to re-spin this based on the one comment we did receive. It should take less than a week, but I do not know for sure I will be able to contact all three of them for input before the end of this week. You wrote: > > The last call on BGP labels, draft-ietf-mpls-bgp4-mpls-03.txt, > closed 12/23/99, 5 pm est. A new draft reflecting the last call > comments will be issued within a week. > > The last call on MPLS ICMP, draft-ietf-mpls-icmp-01.txt, > closed 12/20/99, 5 pm est. There were no comments to the list. The > draft will be forwarded to the IESG for action. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 --------------D430679F67F102257FE4990A-- From owner-mpls@UU.NET Tue Jan 4 18:16:49 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09013 for ; Tue, 4 Jan 2000 18:16:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwph06497; Tue, 4 Jan 2000 23:15:40 GMT Received: by mail-control.mail.uu.net id QQhwph19340 for mpls-outgoing; Tue, 4 Jan 2000 23:15:05 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhwpg19239 for ; Tue, 4 Jan 2000 23:14:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwpg18430 for ; Tue, 4 Jan 2000 18:14:44 -0500 (EST) Received: from goliath.dacor.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.dacor.net [205.133.75.2]) id QQhwpg09564 for ; Tue, 4 Jan 2000 23:14:44 GMT Received: from veda-home.com (adsl-77.dacor.net [205.133.74.77]) by goliath.dacor.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CKAG6WSW; Tue, 4 Jan 2000 18:14:47 -0500 Message-ID: <3872802E.69345A7D@veda-home.com> Date: Tue, 04 Jan 2000 18:20:15 -0500 From: Telecom Tom Organization: The Veda Home Company X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m) X-Accept-Language: en-US, es, de, fr MIME-Version: 1.0 To: mpls@UU.NET, vompls@lists.integralaccess.com Subject: prime time MPLS/fiber Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Wed 08 Dec 1999 raszuk@cisco.com wrote: > > As far as I know MPLS is currently mostly used for > > Traffic Engineering. > That might in fact be the case in US, but anywhere else > for example Europe or Asia the primary mpls deployments > are for the purpose of mpls-vpns and hierarchical routing > applications. Speaking of applications of MPLS: If a municipality was considering an Integrated Community Network based on MPLS (preferably without the complications of ATM), are there examples one could refer the decision makers to? One of the more important questions is, How much does it cost to take MPLS/fiber to the home? Another way of putting this, Is MPLS/fiber ready for prime time? -- ------------------------------------------------ Tom Nelson Scott tom.scott@veda-home.com The Veda Home Company Bowling Green, Ohio USA "In IP We Trust" "E Pluribus Unix" ------------------------------------------------ From owner-mpls@UU.NET Tue Jan 4 22:47:00 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14577 for ; Tue, 4 Jan 2000 22:46:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwpz02214; Wed, 5 Jan 2000 03:46:12 GMT Received: by mail-control.mail.uu.net id QQhwpz09073 for mpls-outgoing; Wed, 5 Jan 2000 03:45:47 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwpz09063 for ; Wed, 5 Jan 2000 03:45:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwpz26704 for ; Tue, 4 Jan 2000 22:45:37 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhwpz01779 for ; Wed, 5 Jan 2000 03:45:37 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id TAA11669 for ; Tue, 4 Jan 2000 19:45:34 -0800 (PST) Message-Id: <4.2.2.20000105142201.00a7cb40@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Jan 2000 14:45:26 +1100 To: mpls@UU.NET From: Jeremy Lawrence Subject: Re: Reordering and MPLS? In-Reply-To: <200001042017.PAA14393@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Reordering has come up a couple of times recently, and I'm wondering why. As Noel has eloquently explained, a well-designed network attempts wherever feasible to deliver similar packets (e.g. packets of the source, destination, and diffserv class) in order, and a well-designed end-system can tolerate occasional mis-ordering. Unless I'm missing something, this all seems quite sensible. Is it just that a note to this effect needs to be added to a document somewhere? (I'm not sure where: these are fundamentals of packet network & equipment design independent of MPLS or IP.) Or is it that people are considering applications of MPLS in circumstances where it seems desirable that packet ordering be guaranteed at the network layer? If so, then it seems important to discuss the applications themselves. Jeremy Lawrence From owner-mpls@UU.NET Tue Jan 4 23:03:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14773 for ; Tue, 4 Jan 2000 23:03:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwqa06929; Wed, 5 Jan 2000 04:03:00 GMT Received: by mail-control.mail.uu.net id QQhwqa10899 for mpls-outgoing; Wed, 5 Jan 2000 04:02:21 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwqa10879 for ; Wed, 5 Jan 2000 04:02:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwqa27468 for ; Tue, 4 Jan 2000 23:02:04 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhwqa09732 for ; Wed, 5 Jan 2000 04:02:04 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id UAA14013; Tue, 4 Jan 2000 20:01:58 -0800 (PST) Message-Id: <4.2.2.20000105144624.00a96700@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Jan 2000 15:01:49 +1100 To: Telecom Tom From: Jeremy Lawrence Subject: Re: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <3872802E.69345A7D@veda-home.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Tom, At 18:20 01/04/2000 -0500, Telecom Tom wrote: >On Wed 08 Dec 1999 raszuk@cisco.com wrote: > > > As far as I know MPLS is currently mostly used for > > > Traffic Engineering. > > > That might in fact be the case in US, but anywhere else > > for example Europe or Asia the primary mpls deployments > > are for the purpose of mpls-vpns and hierarchical routing > > applications. > >Speaking of applications of MPLS: If a municipality was considering an >Integrated Community Network based on MPLS (preferably without the >complications of ATM), are there examples one could refer the decision >makers to? One of the more important questions is, How much does it >cost to take MPLS/fiber to the home? Another way of putting this, Is >MPLS/fiber ready for prime time? Most MPLS networks use MPLS/fiber somehow (e.g. MPLS/PPP/fiber or MPLS/ATM/fiber) between the core LSRs, but I don't think that is really your question. A more relevant question is whether it makes sense to take MPLS to the home. I don't think so. MPLS is a technology for carrying IP in network cores, giving: - traffic engineering capability - VPN capability - excellent IP and ATM integration At the edge (between the home and the first SP router), I don't think MPLS makes sense. MPLS may well make sense in the network core, for the reasons just discussed, but the access just needs to be IP-over-anything. IP/x/fiber, where x is an appropriate data link layer (PPP, fast ethernet, gigabit ethernet, etc.), could certainly be used. Hope this helps, Jeremy Lawrence From owner-mpls@UU.NET Tue Jan 4 23:33:33 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15485 for ; Tue, 4 Jan 2000 23:33:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwqc23759; Wed, 5 Jan 2000 04:32:04 GMT Received: by mail-control.mail.uu.net id QQhwqc19642 for mpls-outgoing; Wed, 5 Jan 2000 04:31:28 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhwqc19636 for ; Wed, 5 Jan 2000 04:31:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwqc09076 for ; Tue, 4 Jan 2000 23:31:23 -0500 (EST) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQhwqc20813 for ; Wed, 5 Jan 2000 04:31:22 GMT Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA14660 for ; Tue, 4 Jan 2000 20:31:22 -0800 (PST) Received: by monterey.pluris.com with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Jan 2000 20:31:22 -0800 Message-ID: <6342F12F9359D311990B009027A1B9B603E7B6@monterey.pluris.com> From: Bora Akyol To: mpls@UU.NET Subject: RE: Reordering and MPLS? Date: Tue, 4 Jan 2000 20:31:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk Reordering of IP packets inside MPLS packets will clearly cause most TCP applications to attempt early transmits for sessions thereby reducing goodput of the network. At least in our box, we are making every effort possible such that we don't reorder packets MPLS or IP belonging to the same flow. I believe that as long as TCP is not changed to handle this, all MPLS/IP router vendors have a responsibility to guarantee ordered arrival packets belonging to the same flow in order to preserve the Internet. Diffserv has gone to a lot of trouble assuring this for AF classes (as in dictating how queueing should be done). I expect that all MPLS equipment out there will do their best to keep packets in order. Yes I know it is a pain to do this at higher speeds but oh well. I would suggest that we add this to the MPLS architecture document. Bora Akyol Pluris (http://www.pluris.com) -----Original Message----- From: Jeremy Lawrence [mailto:jlawrenc@cisco.com] Sent: Tuesday, January 04, 2000 7:45 PM To: mpls@UU.NET Subject: Re: Reordering and MPLS? Reordering has come up a couple of times recently, and I'm wondering why. As Noel has eloquently explained, a well-designed network attempts wherever feasible to deliver similar packets (e.g. packets of the source, destination, and diffserv class) in order, and a well-designed end-system can tolerate occasional mis-ordering. Unless I'm missing something, this all seems quite sensible. Is it just that a note to this effect needs to be added to a document somewhere? (I'm not sure where: these are fundamentals of packet network & equipment design independent of MPLS or IP.) Or is it that people are considering applications of MPLS in circumstances where it seems desirable that packet ordering be guaranteed at the network layer? If so, then it seems important to discuss the applications themselves. Jeremy Lawrence From owner-mpls@UU.NET Wed Jan 5 04:07:05 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29581 for ; Wed, 5 Jan 2000 04:07:05 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwqu29982; Wed, 5 Jan 2000 09:05:32 GMT Received: by mail-control.mail.uu.net id QQhwqu11178 for mpls-outgoing; Wed, 5 Jan 2000 09:04:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhwqu10946 for ; Wed, 5 Jan 2000 09:04:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwqu22728 for ; Wed, 5 Jan 2000 04:04:34 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQhwqu29346 for ; Wed, 5 Jan 2000 09:04:33 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 09:04:29 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FDF6@monk.datcon.co.uk> From: Adrian Farrel To: Markus Jork , mpls@UU.NET Subject: RE: bug in draft-ietf-mpls-rsvp-lsp-tunnel-04 Date: Wed, 5 Jan 2000 09:04:27 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Happy New Year Markus, >>Section 3 of the draft states that an EXPLICIT_ROUTE object >>is only applicable to RSVP Path messages. >>But it also needs to go into PathTear messages so that they >>can be routed correctly. And the ResvConf message also >>needs the EXPLICIT_ROUTE object (if anybody cares about >>ResvConf in the MPLS TE context). > >I might have been too quick calling this a bug. Thinking about >it some more, one can figure out where to forward the PathTear >by looking at the existing path state it refers to and take >the explicit route from there. Was this the intention of the spec? You're right. The ER is already known by each RSVP LSR along the path and so does not need to be part of the PathTear or ResvConf. Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Jan 5 07:29:29 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02585 for ; Wed, 5 Jan 2000 07:29:29 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwrh04479; Wed, 5 Jan 2000 12:28:37 GMT Received: by mail-control.mail.uu.net id QQhwrh20182 for mpls-outgoing; Wed, 5 Jan 2000 12:28:14 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwrh20177 for ; Wed, 5 Jan 2000 12:28:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwrh22384 for ; Wed, 5 Jan 2000 07:28:04 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQhwrh04154 for ; Wed, 5 Jan 2000 12:28:03 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 12:27:58 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FE0D@monk.datcon.co.uk> From: Adrian Farrel To: cheenu@tachion.com, arunv@lucent.com, mpls@UU.NET Cc: vijay@torrentnet.com, swallow@cisco.com Subject: MPLS TE MIB Date: Wed, 5 Jan 2000 12:27:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have some issues with the current draft of the TE MIB, but before I raise them I want to check that the MIB is alive and well. The current version, draft-ietf-mpls-te-mib-01.txt, is marked as expiring in December 1999. Can anyone tell me what the plans are for further progress? TIA Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Jan 5 07:49:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03260 for ; Wed, 5 Jan 2000 07:49:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwrj15048; Wed, 5 Jan 2000 12:48:11 GMT Received: by mail-control.mail.uu.net id QQhwrj21756 for mpls-outgoing; Wed, 5 Jan 2000 12:47:47 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwrj21748 for ; Wed, 5 Jan 2000 12:47:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwrj23353 for ; Wed, 5 Jan 2000 07:47:34 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQhwrj13571 for ; Wed, 5 Jan 2000 12:47:33 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA04402; Wed, 5 Jan 2000 07:47:23 -0500 (EST) Message-Id: <4.2.0.58.20000105074624.00ae1b10@pentagon.cisco.com> X-Sender: tnadeau@pentagon.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jan 2000 07:47:18 -0500 To: Adrian Farrel , cheenu@tachion.com, arunv@lucent.com, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: MPLS TE MIB Cc: vijay@torrentnet.com, swallow@cisco.com In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E13FE0D@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Yes, the TE MIB is alive and well. I am currently working on the final edits for the next revision with Cheenu. The new revision should be out in a few weeks. --Tom >I have some issues with the current draft of the TE MIB, but before I raise >them I want to check that the MIB is alive and well. The current version, >draft-ietf-mpls-te-mib-01.txt, is marked as expiring in December 1999. > >Can anyone tell me what the plans are for further progress? > >TIA >Adrian >-- >Adrian Farrel mailto:af@datcon.co.uk >ATM, MPLS and Telecoms Development Group >Data Connection Ltd., Chester, UK >http://www.datcon.co.uk/ >Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Jan 5 08:21:11 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03942 for ; Wed, 5 Jan 2000 08:21:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwrl00104; Wed, 5 Jan 2000 13:20:17 GMT Received: by mail-control.mail.uu.net id QQhwrl01853 for mpls-outgoing; Wed, 5 Jan 2000 13:19:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwrl01837 for ; Wed, 5 Jan 2000 13:19:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwrl02326 for ; Wed, 5 Jan 2000 08:19:19 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQhwrl29483 for ; Wed, 5 Jan 2000 13:19:18 GMT Received: from tnadeau-pc02 ([161.44.204.102]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA05104; Wed, 5 Jan 2000 08:19:11 -0500 (EST) Message-Id: <4.2.0.58.20000105081824.00ae2220@pentagon.cisco.com> X-Sender: tnadeau@pentagon.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jan 2000 08:19:08 -0500 To: Adrian Farrel , cheenu@tachion.com, arunv@lucent.com, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: MPLS TE MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, I hit the return key a little prematurely last time. :P I also wanted to say that if you had any comments or issues, to please mail them to us ASAP. --Tom From owner-mpls@UU.NET Wed Jan 5 08:45:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04504 for ; Wed, 5 Jan 2000 08:45:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwrl05057; Wed, 5 Jan 2000 13:29:28 GMT Received: by mail-control.mail.uu.net id QQhwrl02562 for mpls-outgoing; Wed, 5 Jan 2000 13:28:59 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwrl02552 for ; Wed, 5 Jan 2000 13:28:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwrl02947 for ; Wed, 5 Jan 2000 08:28:36 -0500 (EST) Received: from morris.canarie.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: server.canarie.ca [209.217.86.48]) id QQhwrl04483 for ; Wed, 5 Jan 2000 13:28:36 GMT Received: from micky (pc2.canet2.net [205.189.33.104]) by morris.canarie.ca (8.9.3+Sun/8.9.3) with SMTP id IAA06721; Wed, 5 Jan 2000 08:28:34 -0500 (EST) Reply-To: From: "Bill St. Arnaud" To: "Telecom Tom" , , Subject: RE: prime time MPLS/fiber Date: Wed, 5 Jan 2000 08:27:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <3872802E.69345A7D@veda-home.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom: We are doing some active development in this area with Fiber to the Home with MPLS. You may want to check out our web site and see some of the papers presented at our November workshop on this subject at www.canarie.ca. As well you might want to check CA*net 3 news archives at www.canet3.net Bill Bill St. Arnaud Senior Director Network Projects CANARIE bill.st.arnaud@canarie.ca +1 613 785-0426 > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Telecom > Tom > Sent: January 4, 2000 6:20 PM > To: mpls@UU.NET; vompls@lists.integralaccess.com > Subject: prime time MPLS/fiber > > > On Wed 08 Dec 1999 raszuk@cisco.com wrote: > > > As far as I know MPLS is currently mostly used for > > > Traffic Engineering. > > > That might in fact be the case in US, but anywhere else > > for example Europe or Asia the primary mpls deployments > > are for the purpose of mpls-vpns and hierarchical routing > > applications. > > Speaking of applications of MPLS: If a municipality was considering an > Integrated Community Network based on MPLS (preferably without the > complications of ATM), are there examples one could refer the decision > makers to? One of the more important questions is, How much does it > cost to take MPLS/fiber to the home? Another way of putting this, Is > MPLS/fiber ready for prime time? > > -- > ------------------------------------------------ > Tom Nelson Scott tom.scott@veda-home.com > The Veda Home Company Bowling Green, Ohio USA > "In IP We Trust" "E Pluribus Unix" > ------------------------------------------------ > From owner-mpls@UU.NET Wed Jan 5 10:02:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06766 for ; Wed, 5 Jan 2000 10:02:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwrs25983; Wed, 5 Jan 2000 15:00:45 GMT Received: by mail-control.mail.uu.net id QQhwrs16913 for mpls-outgoing; Wed, 5 Jan 2000 15:00:00 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwrr16902 for ; Wed, 5 Jan 2000 14:59:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwrr03621 for ; Wed, 5 Jan 2000 09:59:36 -0500 (EST) Received: from almso1.proxy.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: almso1.att.com [192.128.167.69]) id QQhwrr25005 for ; Wed, 5 Jan 2000 14:59:35 GMT Received: from mo3980r1.ems.att.com ([135.38.12.14]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAA26364; Wed, 5 Jan 2000 09:59:34 -0500 (EST) Received: from njb140bh1.ems.att.com by mo3980r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA29016; Wed, 5 Jan 2000 09:56:00 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2448.0) id ; Wed, 5 Jan 2000 09:59:34 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA01BBD545@njc240po03.ho.att.com> From: "Ash, Gerald R (Jerry), ALARC" To: "'Adrian Farrel'" Cc: "Ash, Gerald R (Jerry), ALARC" , "'mpls@UU.NET'" Subject: RE: I-D ACTION:draft-ietf-mpls-crlsp-modify-00.txt Date: Wed, 5 Jan 2000 09:59:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Adrian, Many thanks for your careful reading and helpful comments. We agree with essentially all your suggested changes (see responses below). Happy New Year! Jerry Ash ------------------------------------------------------------ Gerald R. (Jerry) Ash AT&T Labs Manager, Standards Strategy Room MT E3-3C37 200 Laurel Avenue Middletown, NJ 07748 USA Telephone 732-420-4578 Fax 732-368-6687 Email gash@att.com ------------------------------------------------------------ -----Original Message----- From: Adrian Farrel [SMTP:AF@datcon.co.uk] Sent: Tuesday, January 04, 2000 1:17 AM To: Ash, Gerald R (Jerry), ALARC; 'mpls@UU.NET' Subject: RE: I-D ACTION:draft-ietf-mpls-crlsp-modify-00.txt Jerry, hi. We've already discussed my major points with this draft, and they've also recently been raised on the list. Here are a few additional points, typos and editorial thoughts. I hope they are of use. Happy New Year, Adrian In sections 1 and 3 the text still refers to the _action indicator flag_ as an extension to CR-LDP. It is, of course, now part of the spec and the _modify_ value is defined. I suggest that the text be changed to read something like... The LSP modification feature can be supported by CD-LDP by use of the _modify_ value for the _action indicator flag_ in the LSPID TLV. OK In section 2 you define the convention Lid: but in the text you use L-id: Will change Section 2 to L-id In section 2 you might move FTN to below NHLFE. OK In section 3 you twice refer to the action indication flag (should read indicator). OK 4.1, para 2. For "in the messages" read "in the message". OK 4.1 para 2. Insert "its" to read "R1 now still has an entry in its FTN". OK 4.1 para 3. I think it would be useful to clarify at this point that bandwidth is never decreased while processing a modify Label Request. I suggest that the last part of the paragraph should read something like... (I have also made a suggested change to the order of the words in the penultimate sentence for clarity.) bandwidth required and derives the new service class. Compared with the already reserved bandwidth for L-id1, Ri now reserves only any increase in the bandwidth requirements. A reduction in bandwidth requirements is only actioned when the old label is released. This prevents Ri from doing bandwidth double booking. If a new service class is requested, Ri also prepares to receive the traffic on L1 in just the same way as handling it for a Label Request Message, perhaps using a different type of queue. Ri assigns a new label for the Label Request Message. OK 4.1 para 4. Insert "its" to read "R1 can now activate the new entry in its FTN". OK 4.1 para 5, penultimate line. Should "R1" read "Ri"? yes 4.1 para 5, last line. Insert "s" to read "another set of labels". OK 4.1 para 5 (or 6 depending on the page break!) The reference to using modify to reroute an LSP is fine but perhaps a bit thin. In particular, the previous description of the behavior for assigning and releasing labels does not apply itself well to the case where the LSPID only has one entry on parts of the path where the path has diverged. I suggest that an additional subsection describing reroute should be added. I'd be happy to draft some text if you like. OK, also happy to get suggested text. 4.2 Missing blank line between the paragraphs. OK 4.3 It is, perhaps, stating the obvious, but I think this section would benefit from a direct statement such as... In the event of a modification failure, all modifications to the LSP including the holding priority must be restored to their original values. OK, will insert at end of Section 4.3 5.0 should be numbered simply 5. OK 5.0 para 1, last sentence. For "priority" read "priorities". OK 5.0 para 2 and 3. Many small typos. Updated version below. The network operator wants to control the resource on the links of LSRs, so each LSR keeps the usage status of its links and based on the usage history, each link is assigned a current threshold priority Pi. Which means that the link has no bandwidth available for a Label Request with a setup priority lower than Pi. When an LSP's bandwidth needs to be modified, the operator uses a policy based algorithm to assign a priority for its modification request, say Mp for LSP L2. Then the ingress LSR sends Label Request message with (Setup Priority = Mp). The rule is then only if there is enough bandwidth on the link and, the Setup priority in the Label Request Message is higher in priority (Mp numerically smaller) than Pi of the link, the Label Request Message will be accepted by the LSR. Otherwise, the Label Request message will be rejected with a Notification message indicating that there aren't enough resources. It should also be noted that when OSPF (or IS-IS) floods the link available bandwidth information, the available bandwidth associated with priority lower than Pi (numerical value bigger) should be indicated as _0_. This procedure based on a priority threshold Pi is implementation specific and value added. It offers networks flexibility to prioritize and control its resources. The calculation of Mp is network dependent, based on the operator's own algorithm. For example, the operator may assign a higher Mp to L2 if L2 belongs to a customer with _Key_ priority. The operator may also collect the actual usage of each LSP and assign a high Mp to L2 if in the past week, L2 has exceeded its reserved bandwidth by 2 times on average, and the customer of L2 agrees to increase its bandwidth for a better guaranteed service. Some operators may try to increase the bandwidth of L2 on its existing path unsuccessfully as there isn't enough bandwidth there. Then the operator is willing to change the path of L2 in order to increase its bandwidth, but with a lower priority Mp this time as L2 is now routed on its secondary path, which should yield priority to the LSPs that are on its primary paths here. The text at http://www.ietf.org/internet-drafts/draft-ietf-mpls-crlsp-modify-00.txt was already updated to remove many of the typos. Here is further updated text based on your suggested changes: The network operator wants to control the resource on the links of the LSRs, so each LSR keeps the usage status of its links. Based on the usage history, each link is assigned a current threshold priority Pi, which means that the link has no bandwidth available for a Label Request with a setup priority lower than Pi. When an LSP's bandwidth needs to be modified, the operator uses a policy-based algorithm to assign a priority for its modification request, say Mp for LSP L2. The ingress LSR then sends a Label Request message with Setup Priority = Mp. If there is sufficient bandwidth on the link for the modification, and the Setup priority in the Label Request Message is higher in priority (Mp numerically smaller) than the Pi threshold of the link, the Label Request Message will be accepted by the LSR. Otherwise, the Label Request message will be rejected with a Notification message which indicates that there are insufficient resources. It should also be noted that when OSPF (or IS-IS) floods the available-link-bandwidth information, the available bandwidth associated with a priority lower than Pi (numerical value bigger) should be interpreted as _0_. This example based on a priority threshold Pi is implementation specific, and illustrates the flexibility of the modification procedure to prioritize and control network resources. The calculation of Mp can be network and service dependent, and is based on the operator's routing policy. For example, the operator may assign a higher priority (lower Mp value) to L2 bandwidth modification if L2 belongs to a customer or service with _Key_ priority. The operator may also collect the actual usage of each LSP and assign a lower priority (higher Mp) to L2 bandwidth-increase modification if, for example, in the past week L2 has exceeded its reserved bandwidth by 2 times on the average. In addition, an operator may try to increase the bandwidth of L2 on its existing path unsuccessfully if there is insufficient bandwidth available on L2. In that case, the operator is willing to increase the bandwidth of another LSP, L3, with the same ingress/egress LSRs as L2, in order to increase the overall ingress/egress bandwidth allocation. However, in this case the L3 bandwidth modification is performed with a lower priority (higher Mp value) since L3 is routed on a secondary path, which results in the higher bandwidth allocation priority being given to the LSPs that are on their primary paths [2]. Please let us know of any more suggested changes to the above text. Section 7. Should this section include a comment about security with respect to modifications made to LSPs by malign agents? OK, how about adding the following sentence in Section 7: Protection against LSP modification by malign agents has to be controlled by the MPLS domain. -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 Thanks again, Regards, Jerry From owner-mpls@UU.NET Wed Jan 5 10:10:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07007 for ; Wed, 5 Jan 2000 10:10:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwrs00856; Wed, 5 Jan 2000 15:08:19 GMT Received: by mail-control.mail.uu.net id QQhwrs21590 for mpls-outgoing; Wed, 5 Jan 2000 15:07:54 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhwrs21578 for ; Wed, 5 Jan 2000 15:07:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwrs14580 for ; Wed, 5 Jan 2000 10:07:49 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQhwrs00354 for ; Wed, 5 Jan 2000 15:07:48 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 15:07:43 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FE15@monk.datcon.co.uk> From: Adrian Farrel To: "Thomas D. Nadeau" , cheenu@tachion.com, mpls@UU.NET Subject: RE: MPLS TE MIB Date: Wed, 5 Jan 2000 15:07:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Good news, Tom! Here are some thoughts on the current draft. Regards, Adrian 1. Control of Notifications. It would be nice to be able to control the notifications so that they do not flood the Management Application. Can I suggest adding to mplsTeObjects as follows. mplsTunnelUpNotificationEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Allows the generation of notifications in when the mplsTunnelOperStatus object of a configured tunnel moves from the down state to any state other than notPresent." DEFVAL { true } ::= { mplsTeObjects 4 } mplsTunnelDownNotificationEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Allows the generation of notifications in when the mplsTunnelOperStatus object of a configured tunnel moves into the down state from any state other than notPresent." DEFVAL { true } ::= { mplsTeObjects 5 } 2. Cannot Read the Actual Route Used Although this feature does not (currently) exist for CR-LDP the RRO is present and useful in Labels RSVP. It offers the potential to examine the actual route in use which might be particularly nice in some TE applications and where a loose explicit route has been used. The TE MIB does not offer the possibility of examining the RRO. Should we add it? 3. Bit Rates etc. In a previous thread, Andy Baker (ab@datcon.co.uk) wrote... > In the MPLS Traffic Engineering MIBs, bit rates > and burst sizes in the mplsTspecTable and mplsTunnelTable are inherited > from the Integrated Services MIB where they are defined as SNMP INTEGERs > with a valid range of 0 - 0x7FFFFFFF. > > However, the underlying traffic parameter quantities for both CR-LDP and > RSVP are IEEE 32-bit floating point numbers. (For example, see section > 4.3 of draft-ietf-mpls-crldp-03.txt.) > > This means that the data rates which it is possible to reserve on an LSP > are limited to 2Gbit/s, while as the underlying protocols will support > data rates up around 10^39 bytes/second (note the differing units too). > > To be able to configure and manage an LSP using SNMP, it seems to me that > we need to modify the object type for the bit rates and burst sizes to be > a 64 bit quantity, which at least will allow data rates up to about 10^18. draft-kzm-hcdata-types-02.txt suggests an approach using 64 bits, but perhaps we should bite the bullet and use/define full floating point support (I haven't checked whether MIB-II SMI has floating point support). 4. Support for draft-ietf-mpls-diff-ext-02.txt When defining an MPLS Tunnel to support Diff-Serv according to this spec (and in particular L-LSPs) it will be necessary to supply the information to be encoded in the new objects/TLVs (e.g. RSVP DIFFSERV_PSC Object). To avoid having extensions to the MIB at a later date, it would be as well to add this to the current MIB (in such a way that implementations that do not support draft-ietf-mpls-diff-ext-02.txt will not be handicapped). Can I suggest the following ASN.1. You might want to run it past Francois Le Faucher. mplsTunnelDiffServLspType OBJECT-TYPE SYNTAX INTEGER { no-diff-serv(1) -- Diff-Serv not supported e-lsp(2) -- EXP-Inferred-PSC LSP exp-e-lsp(3) -- EXP-Inferred-PSC LSP set up -- explicitly using the method -- used for L-LSPs. l-lsp(4) -- Label-Inferred-PSC LSP } MAX-ACCESS read-create STATUS current DESCRIPTION "Determines the support for diff-Serv provided by this LSP Tunnel. If this field is set to no-diff-serv, then mplsTunnelDiffServPscNum and mplsTunnelDiffServPsc have no meaning." REFERENCE "MPLS Support of Differentiated Services, Le Faucheur, et. al, draft-ietf-mpls-diff-ext-02.txt, October 1999." DEFVAL { 1 } ::= { mplsTunnelEntry xx } mplsTunnelDiffServPscNum OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the number of PSC values included in mplsTunnelDiffServPsc. This object has no meaning if mplsTunnelDiffServLspType is set to no-diff-serv." REFERENCE "MPLS Support of Differentiated Services, Le Faucheur, et. al, draft-ietf-mpls-diff-ext-02.txt, October 1999." DEFVAL { 1 } ::= { mplsTunnelEntry xx } mplsTunnelDiffServPsc OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the PSC value to use for this LSP. This object has no meaning if mplsTunnelDiffServLspType is set to no-diff-serv. If mplsTunnelDiffServLspType indicates exp-e-lsp, this object must only represent a single Ordered Aggregate." REFERENCE "MPLS Support of Differentiated Services, Le Faucheur, et. al, draft-ietf-mpls-diff-ext-02.txt, October 1999." ::= { mplsTunnelEntry xx } mplsTunnelDiffServExpELsp OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the number PSC value to use for this LSP. This object has no meaning if mplsTunnelDiffServLspType is set to no-diff-serv." REFERENCE "MPLS Support of Differentiated Services, Le Faucheur, et. al, draft-ietf-mpls-diff-ext-02.txt, October 1999." DEFVAL { false } ::= { mplsTunnelEntry xx } -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Wednesday, January 05, 2000 12:47 PM >To: Adrian Farrel; cheenu@tachion.com; arunv@lucent.com; mpls@UU.NET >Cc: vijay@torrentnet.com; swallow@cisco.com >Subject: Re: MPLS TE MIB > > > > Yes, the TE MIB is alive and well. I am currently working >on the final edits for the next revision with Cheenu. The new revision >should be out in a few weeks. > > --Tom > > >>I have some issues with the current draft of the TE MIB, but >before I raise >>them I want to check that the MIB is alive and well. The >current version, >>draft-ietf-mpls-te-mib-01.txt, is marked as expiring in December 1999. >> >>Can anyone tell me what the plans are for further progress? >> >>TIA >>Adrian >>-- >>Adrian Farrel mailto:af@datcon.co.uk >>ATM, MPLS and Telecoms Development Group >>Data Connection Ltd., Chester, UK >>http://www.datcon.co.uk/ >>Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > From owner-mpls@UU.NET Wed Jan 5 10:36:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08108 for ; Wed, 5 Jan 2000 10:36:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwru16877; Wed, 5 Jan 2000 15:34:10 GMT Received: by mail-control.mail.uu.net id QQhwru27478 for mpls-outgoing; Wed, 5 Jan 2000 15:33:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhwru27465 for ; Wed, 5 Jan 2000 15:33:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwru17370 for ; Wed, 5 Jan 2000 10:33:06 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQhwru16644 for ; Wed, 5 Jan 2000 15:33:05 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 15:33:00 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FE18@monk.datcon.co.uk> From: Adrian Farrel To: "Ash, Gerald R (Jerry), ALARC" Cc: "'mpls@UU.NET'" Subject: RE: I-D ACTION:draft-ietf-mpls-crlsp-modify-00.txt Date: Wed, 5 Jan 2000 15:32:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jerry, >Many thanks for your careful reading and helpful comments. No problem. >>4.1 para 5 (or 6 depending on the page break!) The reference to >>using modify to reroute an LSP is fine but perhaps a bit thin. >>In particular, the previous description of the behavior for >>assigning and releasing labels does not apply itself well to the >>case where the LSPID only has one entry on parts of the path >>where the path has diverged. I suggest that an additional >>subsection describing reroute should be added. I'd be happy to >>draft some text if you like. > OK, also happy to get suggested text. Fine. I'll try to get to it soon (but not, this week I think). >>5.0 para 2 and 3. Many small typos. Updated version below. >Here is further updated text based on your suggested changes: [SNIP] >Please let us know of any more suggested changes to >the above text. Looks good to me. >>Section 7. Should this section include a comment about security >with respect to modifications made to LSPs by malign agents? >OK, how about adding the following sentence in Section 7: > >Protection against LSP modification by malign agents has to be >controlled by the MPLS domain. Yes that probably covers it at least as well as the main CR-LDP draft ;-) Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Jan 5 11:24:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09604 for ; Wed, 5 Jan 2000 11:24:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwrx23744; Wed, 5 Jan 2000 16:21:39 GMT Received: by mail-control.mail.uu.net id QQhwrx08816 for mpls-outgoing; Wed, 5 Jan 2000 16:20:55 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwrx08807 for ; Wed, 5 Jan 2000 16:20:49 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwrx21506 for ; Wed, 5 Jan 2000 11:20:46 -0500 (EST) Received: from castillo.torrentnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: castillo.torrentnet.com [4.18.161.34]) id QQhwrx22906 for ; Wed, 5 Jan 2000 16:20:45 GMT Received: from torrentnet.com (hooch.torrentnet.com [4.18.161.66]) by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id LAA04197 for ; Wed, 5 Jan 2000 11:20:45 -0500 (EST) Message-ID: <38736F57.A9864EAC@torrentnet.com> Date: Wed, 05 Jan 2000 11:20:39 -0500 From: Vijay Srinivasan X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 2.2.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: LDP state machine draft last call closed Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The last call for draft-ietf-mpls-ldp-state-02.txt has closed. The authors will be working to issue a new draft reflecting the last call comments, hopefully within one week. - Vijay From owner-mpls@UU.NET Wed Jan 5 11:32:51 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09911 for ; Wed, 5 Jan 2000 11:32:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwry00519; Wed, 5 Jan 2000 16:31:24 GMT Received: by mail-control.mail.uu.net id QQhwry09827 for mpls-outgoing; Wed, 5 Jan 2000 16:30:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhwry09815 for ; Wed, 5 Jan 2000 16:30:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwry22831 for ; Wed, 5 Jan 2000 11:30:38 -0500 (EST) Received: from p-voyageur.issy.cnet.fr by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: p-voyageur.issy.cnet.fr [139.100.0.39]) id QQhwry29595 for ; Wed, 5 Jan 2000 16:30:32 GMT Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Wed, 5 Jan 2000 17:31:25 +0100 Message-ID: From: RABARISON Dina CNET/DTD/LAN To: mpls@UU.NET Subject: about drafts Date: Wed, 5 Jan 2000 17:30:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi and happy year, I''ve just joined the mailing list. Could someone tell me how to considere differents drafts concerning MPLS ? As most of them will expire during this year, is it better to wait for them to become RFCs or can we consider that information they have got is valid ? best regards, Dina RABARISON From owner-mpls@UU.NET Wed Jan 5 13:10:12 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12334 for ; Wed, 5 Jan 2000 13:10:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwse01269; Wed, 5 Jan 2000 18:04:45 GMT Received: by mail-control.mail.uu.net id QQhwse26233 for mpls-outgoing; Wed, 5 Jan 2000 18:04:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhwse26215 for ; Wed, 5 Jan 2000 18:04:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwse07742 for ; Wed, 5 Jan 2000 13:04:02 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhwse00710 for ; Wed, 5 Jan 2000 18:04:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jan 5 13:02:36 EST 2000 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.19.134]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA08886; Wed, 5 Jan 2000 13:02:29 -0500 (EST) Message-ID: <387387B0.FD78D0E6@dnrc.bell-labs.com> Date: Wed, 05 Jan 2000 10:04:32 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeremy Lawrence CC: mpls@UU.NET, vompls@lists.integralaccess.com Subject: Re: prime time MPLS/fiber References: <4.2.2.20000105144624.00a96700@farley.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeremy Lawrence wrote: [..] > At the edge (between the home and the first SP router), I don't > think MPLS makes sense. MPLS may well make sense in the network > core, for the reasons just discussed, but the access just needs > to be IP-over-anything. IP/x/fiber, where x is an appropriate > data link layer (PPP, fast ethernet, gigabit ethernet, etc.), > could certainly be used. In principle MPLS might be useful in the access networks for the same reasons ATM is sometimes used in access networks - a 'connection' abstraction allows things like multiple provider selection over single physical links. Each LSP can be a virtual access link. cheers, gja From owner-mpls@UU.NET Wed Jan 5 13:19:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12532 for ; Wed, 5 Jan 2000 13:19:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwse08689; Wed, 5 Jan 2000 18:14:47 GMT Received: by mail-control.mail.uu.net id QQhwse01939 for mpls-outgoing; Wed, 5 Jan 2000 18:14:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhwse01905 for ; Wed, 5 Jan 2000 18:14:03 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwse08680 for ; Wed, 5 Jan 2000 13:13:49 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQhwse06560 for ; Wed, 5 Jan 2000 18:13:48 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA07012; Wed, 5 Jan 2000 10:08:52 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 10:08:52 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Grenville Armitage'" , Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Date: Wed, 5 Jan 2000 10:06:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, MPLS at the access can also reduce the classification burden of the edge routers and make it distributed. -Shahram > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: Wednesday, January 05, 2000 1:05 PM > To: Jeremy Lawrence > Cc: mpls@UU.NET; vompls@lists.integralaccess.com > Subject: Re: prime time MPLS/fiber > > > > > Jeremy Lawrence wrote: > [..] > > > At the edge (between the home and the first SP router), I don't > > think MPLS makes sense. MPLS may well make sense in the network > > core, for the reasons just discussed, but the access just needs > > to be IP-over-anything. IP/x/fiber, where x is an appropriate > > data link layer (PPP, fast ethernet, gigabit ethernet, etc.), > > could certainly be used. > > In principle MPLS might be useful in the access networks for the > same reasons ATM is sometimes used in access networks - a 'connection' > abstraction allows things like multiple provider selection over > single physical links. Each LSP can be a virtual access link. > > cheers, > gja > From owner-mpls@UU.NET Wed Jan 5 13:19:53 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12547 for ; Wed, 5 Jan 2000 13:19:52 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwse06973; Wed, 5 Jan 2000 18:14:15 GMT Received: by mail-control.mail.uu.net id QQhwse01845 for mpls-outgoing; Wed, 5 Jan 2000 18:13:29 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwse01826 for ; Wed, 5 Jan 2000 18:13:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwse27733 for ; Wed, 5 Jan 2000 13:13:11 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQhwse06126 for ; Wed, 5 Jan 2000 18:13:06 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id NAA17878; Wed, 5 Jan 2000 13:13:05 -0500 Date: Wed, 5 Jan 2000 13:13:05 -0500 From: "J. Noel Chiappa" Message-Id: <200001051813.NAA17878@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: RE: Reordering and MPLS? Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Bora Akyol > all MPLS/IP router vendors have a responsibility to guarantee ordered > arrival packets belonging to the same flow There's a big difference between "guarantee to never do " and "do very, very rarely". From this next comment I gather you meant the second, though? > I expect that all MPLS equipment out there will do their best to keep > packets in order. This is entirely reasonable. > I would suggest that we add this to the MPLS architecture document. Sure, as long as it's "do their best", not "guarantee". Of course, if you leave out a specific numberic target, then you run the risk of some smart-aleck saying "oh, our box does reorder one packet in ten, but we are doing our best". However, as pointed out on the IETF list in another thread, the IETF doesn't get into saying whether implementations meet a spec anyway, so even if the spec did say "don't reorder more than .001% of packets", it wouldn't do that much good. (And the argument about what number to put in could and possibly would go on forever! :-) Noel From owner-mpls@UU.NET Wed Jan 5 13:33:24 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12858 for ; Wed, 5 Jan 2000 13:33:23 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwsg18080; Wed, 5 Jan 2000 18:30:51 GMT Received: by mail-control.mail.uu.net id QQhwsg03342 for mpls-outgoing; Wed, 5 Jan 2000 18:30:14 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwsg03334 for ; Wed, 5 Jan 2000 18:30:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwsg29237 for ; Wed, 5 Jan 2000 13:30:02 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhwsg15735 for ; Wed, 5 Jan 2000 18:30:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jan 5 13:28:59 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.41.219]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA09548; Wed, 5 Jan 2000 13:28:52 -0500 (EST) Message-ID: <38738E78.E37EA934@lucent.com> Date: Wed, 05 Jan 2000 13:33:28 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "J. Noel Chiappa" CC: mpls@UU.NET Subject: Re: Reordering and MPLS? References: <200001051813.NAA17878@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Noel, Then the wording to be added would be something like: "For packets transported on a single LSP, and receiving the same level of service, in-order delivery SHOULD be preserved." Correct? You wrote: > > > From: Bora Akyol > > > all MPLS/IP router vendors have a responsibility to guarantee ordered > > arrival packets belonging to the same flow > > There's a big difference between "guarantee to never do " and "do > very, very rarely". From this next comment I gather you meant the second, > though? > > > I expect that all MPLS equipment out there will do their best to keep > > packets in order. > > This is entirely reasonable. > > > I would suggest that we add this to the MPLS architecture document. > > Sure, as long as it's "do their best", not "guarantee". > > Of course, if you leave out a specific numberic target, then you run the risk > of some smart-aleck saying "oh, our box does reorder one packet in ten, but > we are doing our best". However, as pointed out on the IETF list in another > thread, the IETF doesn't get into saying whether implementations meet a spec > anyway, so even if the spec did say "don't reorder more than .001% of > packets", it wouldn't do that much good. (And the argument about what number > to put in could and possibly would go on forever! :-) > > Noel From owner-mpls@UU.NET Wed Jan 5 14:35:10 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14290 for ; Wed, 5 Jan 2000 14:35:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwsk24733; Wed, 5 Jan 2000 19:32:54 GMT Received: by mail-control.mail.uu.net id QQhwsk15256 for mpls-outgoing; Wed, 5 Jan 2000 19:32:19 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhwsk15218 for ; Wed, 5 Jan 2000 19:32:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwsk16023 for ; Wed, 5 Jan 2000 14:31:54 -0500 (EST) Received: from metconnect.ixc-comm.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ixcfw1.ixc-comm.com [38.244.111.5]) id QQhwsk23942 for ; Wed, 5 Jan 2000 19:31:54 GMT Received: by metconnect.ixc-comm.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 13:28:18 -0600 Message-ID: From: "Johnson, Robert (Broadwing)" To: "'Shahram Davari'" , "'Grenville Armitage'" , Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Date: Wed, 5 Jan 2000 13:31:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Agreed. Moving classification and other MPLS-based services (VPN et al) to the customer premise would reduce the burden on the network edge and enhance the ability to offer new services. However, connecting this thread to the "Reordering and MPLS?" thread, isn't some kind of ordered delivery guarantee required to create true connection-oriented CPE-based services? Robert -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, January 05, 2000 12:07 PM To: 'Grenville Armitage'; Jeremy Lawrence Cc: mpls@UU.NET; vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Hi, MPLS at the access can also reduce the classification burden of the edge routers and make it distributed. -Shahram > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: Wednesday, January 05, 2000 1:05 PM > To: Jeremy Lawrence > Cc: mpls@UU.NET; vompls@lists.integralaccess.com > Subject: Re: prime time MPLS/fiber > > > > > Jeremy Lawrence wrote: > [..] > > > At the edge (between the home and the first SP router), I don't > > think MPLS makes sense. MPLS may well make sense in the network > > core, for the reasons just discussed, but the access just needs > > to be IP-over-anything. IP/x/fiber, where x is an appropriate > > data link layer (PPP, fast ethernet, gigabit ethernet, etc.), > > could certainly be used. > > In principle MPLS might be useful in the access networks for the > same reasons ATM is sometimes used in access networks - a 'connection' > abstraction allows things like multiple provider selection over > single physical links. Each LSP can be a virtual access link. > > cheers, > gja > From owner-mpls@UU.NET Wed Jan 5 17:11:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16899 for ; Wed, 5 Jan 2000 17:11:30 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwsu23376; Wed, 5 Jan 2000 22:09:40 GMT Received: by mail-control.mail.uu.net id QQhwsu16841 for mpls-outgoing; Wed, 5 Jan 2000 22:09:02 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwsu16691 for ; Wed, 5 Jan 2000 22:08:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwsu17440 for ; Wed, 5 Jan 2000 17:08:39 -0500 (EST) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQhwsu25998 for ; Wed, 5 Jan 2000 22:08:39 GMT Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA00099; Wed, 5 Jan 2000 14:08:37 -0800 (PST) Received: by monterey.pluris.com with Internet Mail Service (5.5.2448.0) id ; Wed, 5 Jan 2000 14:08:37 -0800 Message-ID: <6342F12F9359D311990B009027A1B9B603E7B8@monterey.pluris.com> From: Bora Akyol To: "'J. Noel Chiappa'" , mpls@UU.NET Subject: RE: Reordering and MPLS? Date: Wed, 5 Jan 2000 14:08:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk No I meant the first. In order delivery should be **guaranteed**. Otherwise, out of order delivery causes problems at the TCP level and reduces your network goodput. This is especially true with fast retransmit. Bora Akyol -----Original Message----- From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] Sent: Wednesday, January 05, 2000 10:13 AM To: mpls@UU.NET Cc: jnc@ginger.lcs.mit.edu Subject: RE: Reordering and MPLS? > From: Bora Akyol > all MPLS/IP router vendors have a responsibility to guarantee ordered > arrival packets belonging to the same flow There's a big difference between "guarantee to never do " and "do very, very rarely". From this next comment I gather you meant the second, though? > I expect that all MPLS equipment out there will do their best to keep > packets in order. This is entirely reasonable. > I would suggest that we add this to the MPLS architecture document. Sure, as long as it's "do their best", not "guarantee". Of course, if you leave out a specific numberic target, then you run the risk of some smart-aleck saying "oh, our box does reorder one packet in ten, but we are doing our best". However, as pointed out on the IETF list in another thread, the IETF doesn't get into saying whether implementations meet a spec anyway, so even if the spec did say "don't reorder more than .001% of packets", it wouldn't do that much good. (And the argument about what number to put in could and possibly would go on forever! :-) Noel From owner-mpls@UU.NET Wed Jan 5 18:19:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17809 for ; Wed, 5 Jan 2000 18:19:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwsz04471; Wed, 5 Jan 2000 23:18:08 GMT Received: by mail-control.mail.uu.net id QQhwsz03077 for mpls-outgoing; Wed, 5 Jan 2000 23:17:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwsz03068 for ; Wed, 5 Jan 2000 23:17:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwsz01299 for ; Wed, 5 Jan 2000 18:17:07 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhwsz29764 for ; Wed, 5 Jan 2000 23:17:06 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA13146; Wed, 5 Jan 2000 15:16:31 -0800 (PST) Message-Id: <4.2.2.20000106094859.00a84cf0@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Jan 2000 10:16:23 +1100 To: Shahram Davari From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Shahram, At 10:06 01/05/2000 -0800, Shahram Davari wrote: >Hi, > >MPLS at the access can also reduce the classification burden of the edge >routers and make it distributed. Agreed in principle, though the security of management of that could be a problem. If a malicious person gained access to an edge LSR, it's easy to imagine ways in which they could make the network unstable, or otherwise cause trouble (e.g. by readvertising large numbers of routes into the network core). If the CPE are edge LSRs, then the scope for that sort of thing is very high. I have been involved in network designs where edge LSRs are customer located equipment, but that involved a requirement that the edge LSRs were placed only in a physically secure environment, e.g. a telco-controlled distribution room in a building. Regards, Jeremy Lawrence > > -----Original Message----- > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > Sent: Wednesday, January 05, 2000 1:05 PM > > To: Jeremy Lawrence > > Cc: mpls@UU.NET; vompls@lists.integralaccess.com > > Subject: Re: prime time MPLS/fiber > > > > > > > > > > Jeremy Lawrence wrote: > > [..] > > > > > At the edge (between the home and the first SP router), I don't > > > think MPLS makes sense. MPLS may well make sense in the network > > > core, for the reasons just discussed, but the access just needs > > > to be IP-over-anything. IP/x/fiber, where x is an appropriate > > > data link layer (PPP, fast ethernet, gigabit ethernet, etc.), > > > could certainly be used. > > > > In principle MPLS might be useful in the access networks for the > > same reasons ATM is sometimes used in access networks - a 'connection' > > abstraction allows things like multiple provider selection over > > single physical links. Each LSP can be a virtual access link. > > > > cheers, > > gja > > From owner-mpls@UU.NET Wed Jan 5 18:28:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17896 for ; Wed, 5 Jan 2000 18:28:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwsz04962; Wed, 5 Jan 2000 23:26:58 GMT Received: by mail-control.mail.uu.net id QQhwsz03754 for mpls-outgoing; Wed, 5 Jan 2000 23:26:37 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhwsz03749 for ; Wed, 5 Jan 2000 23:26:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwsz01812 for ; Wed, 5 Jan 2000 18:26:24 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhwsz04507 for ; Wed, 5 Jan 2000 23:26:24 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA16769; Wed, 5 Jan 2000 15:26:19 -0800 (PST) Message-Id: <4.2.2.20000106101827.00a8cbc0@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Jan 2000 10:26:10 +1100 To: "Johnson, Robert (Broadwing)" From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Robert, At 13:31 01/05/2000 -0600, Johnson, Robert (Broadwing) wrote: [...] >However, connecting this thread to the >"Reordering and MPLS?" thread, isn't some kind of ordered delivery guarantee >required to create true connection-oriented CPE-based services? If the services are suitable for connection over a packet network, then it can be strongly argued (as Noel has done recently) that the services must be able to deal gracefully with occasional packet mis-ordering. Are there services proposed for connection over MPLS which do not meet this requirement? Regards, Jeremy Lawrence From owner-mpls@UU.NET Wed Jan 5 18:29:43 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17918 for ; Wed, 5 Jan 2000 18:29:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwsz10178; Wed, 5 Jan 2000 23:28:41 GMT Received: by mail-control.mail.uu.net id QQhwsz03804 for mpls-outgoing; Wed, 5 Jan 2000 23:28:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwsz03799 for ; Wed, 5 Jan 2000 23:28:15 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwsz01895 for ; Wed, 5 Jan 2000 18:28:11 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQhwsz09767 for ; Wed, 5 Jan 2000 23:28:11 GMT Received: from gwaters-pc (gwaters-pc.avici.com [10.1.1.169]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id SAA18846; Wed, 5 Jan 2000 18:28:08 -0500 (EST) Message-Id: <4.1.20000105170220.00b245d0@mailhost.avici.com> X-Sender: gwaters@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 05 Jan 2000 18:27:06 -0500 To: ewgray@lucent.com, jnc@ginger.lcs.mit.edu From: Greg Waters Subject: Re: Reordering and MPLS? Cc: mpls@UU.NET In-Reply-To: <38738E78.E37EA934@lucent.com> References: <200001051813.NAA17878@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 01:33 PM 1/5/00 -0500, you wrote: >Noel, > Then the wording to be added would be something like: > "For packets transported on a single LSP, and receiving > the same level of service, in-order delivery SHOULD be > preserved." >Correct? No, LSRs are obliged to limit reordering of IP traffic in the same manner as IP routers, until someone presents a reason to reduce reordering in LSRs relative to high-end IP routers. This was discussed long ago (early 1999) on the MPLS list, and I agree with the original discussion (which I don't keep handy; sorry). The reason is that very fast LSRs engage in traffic engineering methods that include load-balancing, analogous to equal-cost multi-path routing in very fast IP routers. What is important for IPv4 and IPv6 is to "almost always" deliver packets in order within a 6-tuple IPv4 or IPv6 flow (DiffServ class, IP source, IP dest, protocol, source port, dest port). For simplicity, core-network switches need not exploit (protocol, source port, dest port) variation for extra load balancing. The most useful invariants of an "IP forwarding flow" are (DiffServ class, IP source, IP dest). Thanks to DWDM, load balancing a 100-Gbit/sec trunk LSP across dozens of lambdas is an operationally important feature in the near future. Fortunately for this discussion, high-end routers have always done some of that to IPv4 due to ECMP, so letting LSRs reorder within a fat LSP (for a given class) is equally reasonable. When an LSP is not configured to carry pure IPv4 (and/or IPv6) traffic, or other traffic with widely-known flow identifiers, then that LSP should not suffer reordering within a DiffServ class. Therefore, non-IP LSPs will typically be confined to one lambda of capacity. "Almost always" means that reordering is to be expected during re-routing, until otherwise stated. Changing an LSP's route at high frequency is an unsociable act, absent a mechanism to keep each flow's packets in order. What MPLS specs could say is that reordering in an LSP should be limited in the same manner as for the network protocol(s) carried within the LSP, as appropriate. Hypothetically, if a fat LSP carried IPv6/FrameRelay/MPLS, the reordering expectations of IPv6 and/or FrameRelay might apply to the LSP. MPLS specs could stipulate that a mode of LSP mid-point "should" be supported which from a forwarding perspective has unidentifiable flows. If supported, that mode of LSP should keep all packets in order for a given Exp-coded service class. --gw From owner-mpls@UU.NET Wed Jan 5 18:32:52 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18089 for ; Wed, 5 Jan 2000 18:32:52 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwta12064; Wed, 5 Jan 2000 23:31:34 GMT Received: by mail-control.mail.uu.net id QQhwta04025 for mpls-outgoing; Wed, 5 Jan 2000 23:31:10 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhwta03951 for ; Wed, 5 Jan 2000 23:31:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwta23553 for ; Wed, 5 Jan 2000 18:30:49 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhwta07011 for ; Wed, 5 Jan 2000 23:30:49 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA18223; Wed, 5 Jan 2000 15:30:42 -0800 (PST) Message-Id: <4.2.2.20000106102747.00a95940@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Jan 2000 10:30:34 +1100 To: RABARISON Dina CNET/DTD/LAN From: Jeremy Lawrence Subject: Re: about drafts Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Dina, At 17:30 01/05/2000 +0100, RABARISON Dina CNET/DTD/LAN wrote: > Hi and happy year, > > I''ve just joined the mailing list. > Could someone tell me how to considere differents drafts concerning >MPLS ? As most of them will expire during this year, > is it better to wait for them to become RFCs or can we consider that >information they have got is valid Many of them will become RFCs. The attached message from the IESG explains the current state of several of them, and it appears that Working Group Last Calls will soon be complete on at least three more. Regards, Jeremy Lawrence >To: IETF-Announce:; >Cc: mpls@UU.NET >From: The IESG >SUBJECT: Last Call: LDP Specification to Proposed Standard >Reply-to: iesg@ietf.org >Date: Thu, 04 Nov 1999 15:52:33 -0500 >Sender: owner-mpls@UU.NET > > >The IESG has received a request from the Multiprotocol Label Switching >Working Group to consider publication of the following as Proposed >Standards: > >o LDP Specification > >o LDP Applicability > >o Extensions to RSVP for LSP Tunnels > >o Applicability Statement for Extensions to RSVP for LSP-Tunnels > >o Constraint-Based LSP Setup using LDP > >o Applicability Statement for CR-LDP > > > >The IESG will also consider publication of A Framework for MPLS > as an Informational RFC. > >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 November 25, 1999. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-06.txt >http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-applic-00.txt >http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-04.txt >http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-tunnel-applicability-00.txt >http://www.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-03.txt >http://www.ietf.org/internet-drafts/draft-ietf-mpls-crldp-applic-00.txt >http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-05.txt From owner-mpls@UU.NET Wed Jan 5 19:19:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18609 for ; Wed, 5 Jan 2000 19:18:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwtd06258; Thu, 6 Jan 2000 00:16:08 GMT Received: by mail-control.mail.uu.net id QQhwtd14540 for mpls-outgoing; Thu, 6 Jan 2000 00:15:11 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhwtd14526 for ; Thu, 6 Jan 2000 00:15:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwtd11449 for ; Wed, 5 Jan 2000 19:15:05 -0500 (EST) Received: from etri.re.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.etri.re.kr [129.254.113.113]) id QQhwtd05575 for ; Thu, 6 Jan 2000 00:15:04 GMT Received: from LocalHost (extkang.etri.re.kr [129.254.197.52]) by etri.re.kr (8.9.3/8.9.3) with SMTP id JAA20809 for ; Thu, 6 Jan 2000 09:13:38 +0900 (KST) Message-ID: <007b01bf57e3$f0f95cd0$34c5fe81@etri.re.kr> From: "Sun-Moo Svenna Kang" To: Subject: Linux based MPLS on ATM interface Date: Thu, 6 Jan 2000 10:18:28 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01BF582F.60099090" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0078_01BF582F.60099090 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksDQogDQpJIGFtIHdvbmRlcmluZyB3aGV0aGVyIHNvbWUgcGFydGllcyBhcmUgd29ya2luZyBv biB0aGUgbGludXggYmFzZWQgDQpNUExTIG9uIEFUTSBpbnRlcmZhY2UuDQoNClBsZWFzZSBiZSBh IHBhdGhmaW5kZXIgZm9yIG1lLg0KDQpUaGFua3MuDQoNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpTdW4tTW9vIFN2 ZW5uYSBLYW5nLCBQaEQuDQpQcmluY2lwYWwgTWVtYmVyIG9mIFJlc2VhcmNoIFN0YWZmLFRlYW0g TGVhZGVyLCANCk1QTFMgUy9XIFRlYW0sRVRSSShFbGVjdHJvbmljcyBUZWxlY29tbXVuaWNhdGlv bnMgUmVzZWFyY2ggSW5zdGl0dXRlKSwgDQpQLk8uQm94IDEwNiwgWXVzb25nLCBUYWVqb24gMzA1 LTYwMCwgVGhlIFJlcHVibGljIG9mIEtvcmVhDQpUZWwpICs4Mi00Mi04NjAtNTI5OSwgRmF4KSAr ODItNDItODYwLTU0NDAsIE1vYmlsZSkgKzgyLTE2LTQwNy02MjcyDQpXZWIpIGh0dHA6Ly9tcGxz MC5ldHJpLnJlLmtyL35ldHhrYW5nDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K ------=_NextPart_000_0078_01BF582F.60099090 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjIzMTQuMTAwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48 Rk9OVCBzaXplPTI+SGksPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBhbSB3b25kZXJpbmcgd2hldGhlciBzb21l IHBhcnRpZXMgYXJlIHdvcmtpbmcgb24gdGhlIGxpbnV4IA0KYmFzZWQgPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+TVBMUyBvbiBBVE0gaW50ZXJmYWNlLjwvRk9OVD48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5QbGVhc2UgYmUgYSBwYXRoZmluZGVy IGZvciBtZS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+VGhhbmtzLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCANCnNpemU9Mj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxCUj5TdW4tTW9vIA0KU3Zlbm5hIEthbmcs IFBoRC48QlI+UHJpbmNpcGFsIE1lbWJlciBvZiBSZXNlYXJjaCBTdGFmZixUZWFtIExlYWRlciwg PEJSPk1QTFMgDQpTL1cgVGVhbSxFVFJJKEVsZWN0cm9uaWNzIFRlbGVjb21tdW5pY2F0aW9ucyBS ZXNlYXJjaCBJbnN0aXR1dGUpLCA8QlI+UC5PLkJveCANCjEwNiwgWXVzb25nLCBUYWVqb24gMzA1 LTYwMCwgVGhlIFJlcHVibGljIG9mIEtvcmVhPEJSPlRlbCkgKzgyLTQyLTg2MC01Mjk5LCBGYXgp IA0KKzgyLTQyLTg2MC01NDQwLCBNb2JpbGUpICs4Mi0xNi00MDctNjI3MjxCUj5XZWIpIDxBIA0K aHJlZj0iaHR0cDovL21wbHMwLmV0cmkucmUua3IvfmV0eGthbmciPmh0dHA6Ly9tcGxzMC5ldHJp LnJlLmtyL35ldHhrYW5nPC9BPjxCUj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvRk9OVD48L0RJVj48L0JPRFk+PC9I VE1MPg0K ------=_NextPart_000_0078_01BF582F.60099090-- From owner-mpls@UU.NET Wed Jan 5 19:45:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18898 for ; Wed, 5 Jan 2000 19:45:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwte15340; Thu, 6 Jan 2000 00:44:06 GMT Received: by mail-control.mail.uu.net id QQhwte16753 for mpls-outgoing; Thu, 6 Jan 2000 00:43:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhwte16707 for ; Thu, 6 Jan 2000 00:43:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwte13021 for ; Wed, 5 Jan 2000 19:43:17 -0500 (EST) Received: from metconnect.ixc-comm.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ixcfw1.ixc-comm.com [38.244.111.5]) id QQhwte19563 for ; Thu, 6 Jan 2000 00:43:17 GMT Received: by metconnect.ixc-comm.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 18:39:41 -0600 Message-ID: From: "Johnson, Robert (Broadwing)" To: "'Jeremy Lawrence'" Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Date: Wed, 5 Jan 2000 18:43:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jeremy, >If the services are suitable for connection over a packet network, >then it can be strongly argued (as Noel has done recently) that the >services must be able to deal gracefully with occasional packet >mis-ordering. Are there services proposed for connection over MPLS >which do not meet this requirement? I apologize for not clarifying, but I was implying the inclusion of those services that are not suitable for use over a pure, connectionless packet network. There has been some discussion of using MPLS to provide connection-oriented services, some of which are not designed to survive the rigors of a connectionless packet network. If MPLS were to be utilized as a transport protocol for customer access, it would need to be capable of supporting these types of services. In other words, it needs to guarantee ordered packet delivery or it should be not be used for these services. Robert From owner-mpls@UU.NET Wed Jan 5 21:05:09 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19449 for ; Wed, 5 Jan 2000 21:04:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwtk28246; Thu, 6 Jan 2000 02:03:52 GMT Received: by mail-control.mail.uu.net id QQhwtk03470 for mpls-outgoing; Thu, 6 Jan 2000 02:03:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhwtk03390 for ; Thu, 6 Jan 2000 02:03:02 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwtk16704 for ; Wed, 5 Jan 2000 21:02:47 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQhwtk22659 for ; Thu, 6 Jan 2000 02:02:47 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id VAA19460; Wed, 5 Jan 2000 21:02:46 -0500 Date: Wed, 5 Jan 2000 21:02:46 -0500 From: "J. Noel Chiappa" Message-Id: <200001060202.VAA19460@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: RE: Reordering and MPLS? Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Bora Akyol >>> all MPLS/IP router vendors have a responsibility to guarantee ordered >>> arrival packets belonging to the same flow >> There's a big difference between "guarantee to never do " and "do >> very, very rarely". > No I meant the first. In order delivery should be **guaranteed**. > Otherwise, out of order delivery causes problems at the TCP level and > reduces your network goodput. This is especially true with fast > retransmit. Well, you do concede that an endnode has to be able to handle segments arriving out of order, right? (This is because it's basically impossible to tell whether you're seeing a retransmitted packet, or a delayed packet: e.g. host A sends packets 1, 2 and 3; packet 2 gets lost; host A retransmits 2; so host B sees packets 1, 3, 2 arrive.) So, given that, it's purely a "maximizing throughput" argument you're making, right? However, a reordering will not cause more of a hit to throughput than a lost packet, right? (Extensive analysis of end-end behaviour in both circumstances to determine the exact performance impact omitted, since the weak ordering above will do for my argument. Also omitted is speculation about how to changes to fast retransmit to filter out "out-of-order" incidents.) So, if the rate at which the network reorders packets is much smaller than the rate at which it drops packets (which I expect to be true), how does completely getting rid of all reordering buy you a noticeable increase in throughput? And why expend all the effort to absolutely, utterly guarantee that there is no reordering - when it doesn't buy you anything noticeable? Again, I have no problem with a mandate that MPLS boxes try hard to never reorder packets. But I find a *guarantee* of absolutely no reordering i) of great expense (in terms of complexity, mechanism, etc), and ii) of no real worth. Noel From owner-mpls@UU.NET Wed Jan 5 21:19:10 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19542 for ; Wed, 5 Jan 2000 21:19:03 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwtl29961; Thu, 6 Jan 2000 02:18:14 GMT Received: by mail-control.mail.uu.net id QQhwtl10336 for mpls-outgoing; Thu, 6 Jan 2000 02:17:36 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwtl10323 for ; Thu, 6 Jan 2000 02:17:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwtl11421 for ; Wed, 5 Jan 2000 21:17:24 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQhwtl29392 for ; Thu, 6 Jan 2000 02:17:23 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id VAA19516; Wed, 5 Jan 2000 21:17:22 -0500 Date: Wed, 5 Jan 2000 21:17:22 -0500 From: "J. Noel Chiappa" Message-Id: <200001060217.VAA19516@ginger.lcs.mit.edu> To: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: "Johnson, Robert (Broadwing)" > I was implying the inclusion of those services that are not suitable > for use over a pure, connectionless packet network. There has been some > discussion of using MPLS to provide connection-oriented services, some > of which are not designed to survive the rigors of a connectionless > packet network. ... it needs to guarantee ordered packet delivery or it > should be not be used for these services. How do these services deal with lost packets? (C.f. my point to Bora Akyol about how the effects of lost packets and reordered packets can look almost identical, at the receiver.) Or are you saying that these services won't work in networks which can lose packets? If so, are you now proposing that MPLS guaranteee to never drop packets? And if these services can somehow deal with lost packets (e.g. by simply ignoring them, the way packet voice does), why can't they just discard out-of-order packets - if a service can handle lost packets, it can handle discarded packets, right? Noel From owner-mpls@UU.NET Wed Jan 5 21:30:53 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19578 for ; Wed, 5 Jan 2000 21:30:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwtl05378; Thu, 6 Jan 2000 02:29:36 GMT Received: by mail-control.mail.uu.net id QQhwtl11535 for mpls-outgoing; Thu, 6 Jan 2000 02:29:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwtl11527 for ; Thu, 6 Jan 2000 02:28:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwtl11990 for ; Wed, 5 Jan 2000 21:28:50 -0500 (EST) Received: from relay1.pair.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: relay1.pair.com [209.68.1.20]) id QQhwtl10195 for ; Thu, 6 Jan 2000 02:28:49 GMT Received: (qmail 26608 invoked from network); 6 Jan 2000 02:28:33 -0000 Received: from flure.pair.com (HELO ragnarok) (209.68.1.159) by relay1.pair.com with SMTP; 6 Jan 2000 02:28:33 -0000 X-pair-Authenticated: 209.68.1.159 From: "Thomas Wolfram" To: "Francois Le Faucheur" Cc: Subject: RE: Current status of IPv6 support? Date: Thu, 6 Jan 2000 03:29:35 +0100 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: <200001041001.LAA12848@europe.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA19578 Francois, > Thomas, > > At 17:47 21/12/1999 +0100, Thomas Wolfram wrote: ... > >But other drafts seem to make few provisions for IPv6 if at > >all (ldp, icmp, diff-ext). > > We will add a statement in the next rev of the diff-ext I-D that it is > applicable to both IPv4 and IPv6. that would be fine. I think it would be quite useful if all MPLS drafts would contain such a applicability statement concerning the level of IPv6 support. I.e. 'IPv4 only', 'IPv4 + some IPv6' (like tunnels) or full IPv* support (which would mean that all variants: 'IPv4 only' OR 'IPv4 + some IPv6' OR native 'IPv6 only' are possible with the draft spec). > >And what about the extended RSVP? It supports IPv6 prefixes > >but tunnel sender and end point addresses as well as Extended > >Tunnel IDs are defined using IPv4 addresses. So IPv6 could be > >transmiited over a ER-LSP but the LERs/LSRs themselves would > >still have to run IPv4, right? > > > > as per : > "The LABEL_REQUEST object > indicates that a label binding for this path is requested and also ... > and : > "Label Request without Label Range ... > So, I'd say it is possible to set up LSP Tunnels via the currently defined > RSVP extensions to transport IPv6. Well ok, this confirms what I assumed after reading the draft. But I rather wanted to point out that I see actually no reason not to add the more or less minor(?) extensions needed for complete native IPv6 support right now. As far as I can see it - and perhaps I miss some implications - adding basic but complete IPv6 support (i.e. find perhaps ways to map the IPv6 flow label etc. later) right now would not be such a big deal for most of the drafts, wouldn't it? I know all the arguments about IPv6 not needed in the cores right now (if at all), no business case yet etc.etc. and I don't want get into this here. But given that there were made already quite a number of provisions for IPv6 in the drafts why not complete it for native IPv6? As a starting point I've appended here a old message from April 1999 from David Mankins concerning IPv6 support in the TE-RSVP draft (which suggests to add a C-type LSP_TUNNEL_IPv6 to support IPv6 tunnel sender and egress addresses). Hope this is not obsolete for some reason? And I guess chapter 2.1, 2.2 would need a little bit tuning for IPv6 as well. But if I don't miss something these would be rather minor changes in the draft - or not? regards, Thomas Wolfram -----snip----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] on behalf of david mankins > Sent: Monday, April 12, 1999 6:09 PM > To: mpls@UU.NET > Subject: LSP_TUNNEL_IPv6 c-types are missing from draft-ietf-mpls-rsvp-tunnel-02 > > > > Bora Akyol mentioned this before the latest draft of the document came > out, but The document should specify the C-type LSP_TUNNEL_IPv6 (for > all the classes that have C-type LSP_TUNNEL_IPv4) before it becomes a > standard. > > In particular, > > Class = SESSION, C-Type = LSP_TUNNEL_IPv4 (7) > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 tunnel end point address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Must be zero | Tunnel ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Extended Tunnel ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > should probably have an ipv6 equivalent: > > Class = SESSION, C-Type = LSP_TUNNEL_IPv6 (?) > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel end point address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Must be zero | Tunnel ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Extended Tunnel ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Extended Tunnel ID (cont'd) > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Extended Tunnel ID (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Extended Tunnel ID (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > and: > > > Class = SENDER_TEMPLATE, C-Type = LSP_TUNNEL_IPv4 (7) > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 tunnel sender address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Must be zero | LSP ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > should have a corresponding: > > Class = SENDER_TEMPLATE, C-Type = LSP_TUNNEL_IPv6 (?) > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Must be zero | LSP ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > and, > > Class = FILTER SPECIFICATION, C-Type = LSP_TUNNEL_IPv4 (7) > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 tunnel sender address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Must be zero | LSP ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > should have a corresponding > > Class = FILTER SPECIFICATION, C-Type = LSP_TUNNEL_IPv6 (7) > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 tunnel sender address (cont'd) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Must be zero | LSP ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > - david mankins (dm@bbn.com, dm@world.std.com, phone(US): 617-873-2873) > -----snip----- From owner-mpls@UU.NET Wed Jan 5 21:56:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20701 for ; Wed, 5 Jan 2000 21:56:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwtn18229; Thu, 6 Jan 2000 02:55:20 GMT Received: by mail-control.mail.uu.net id QQhwtn13845 for mpls-outgoing; Thu, 6 Jan 2000 02:54:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhwtn13840 for ; Thu, 6 Jan 2000 02:54:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwtn13242 for ; Wed, 5 Jan 2000 21:54:34 -0500 (EST) Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQhwtn17740 for ; Thu, 6 Jan 2000 02:54:33 GMT Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id SAA09980; Wed, 5 Jan 2000 18:54:31 -0800 (PST) Received: by monterey.pluris.com with Internet Mail Service (5.5.2448.0) id ; Wed, 5 Jan 2000 18:54:32 -0800 Message-ID: <6342F12F9359D311990B009027A1B9B603E7BB@monterey.pluris.com> From: Bora Akyol To: "'J. Noel Chiappa'" , mpls@UU.NET Subject: RE: Reordering and MPLS? Date: Wed, 5 Jan 2000 18:54:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk OK, I see your point. I would reword it to say that packet ordering should be preserved under normal operating conditions. When packets are getting rerouted in the network or even within a box due to a failure, then we will see reordering. I also agree that reordering such that fast retransmit within TCP is not triggered, we should be OK. So if this translates to "very rarely" than I agree. On the other hand, I would like to say that striping packets through a switch without any respect to packet order is NOT acceptable as long as applications are not changed to handle this. Thanks Bora -----Original Message----- From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] Sent: Wednesday, January 05, 2000 6:03 PM To: mpls@UU.NET Cc: jnc@ginger.lcs.mit.edu Subject: RE: Reordering and MPLS? > From: Bora Akyol >>> all MPLS/IP router vendors have a responsibility to guarantee ordered >>> arrival packets belonging to the same flow >> There's a big difference between "guarantee to never do " and "do >> very, very rarely". > No I meant the first. In order delivery should be **guaranteed**. > Otherwise, out of order delivery causes problems at the TCP level and > reduces your network goodput. This is especially true with fast > retransmit. Well, you do concede that an endnode has to be able to handle segments arriving out of order, right? (This is because it's basically impossible to tell whether you're seeing a retransmitted packet, or a delayed packet: e.g. host A sends packets 1, 2 and 3; packet 2 gets lost; host A retransmits 2; so host B sees packets 1, 3, 2 arrive.) So, given that, it's purely a "maximizing throughput" argument you're making, right? However, a reordering will not cause more of a hit to throughput than a lost packet, right? (Extensive analysis of end-end behaviour in both circumstances to determine the exact performance impact omitted, since the weak ordering above will do for my argument. Also omitted is speculation about how to changes to fast retransmit to filter out "out-of-order" incidents.) So, if the rate at which the network reorders packets is much smaller than the rate at which it drops packets (which I expect to be true), how does completely getting rid of all reordering buy you a noticeable increase in throughput? And why expend all the effort to absolutely, utterly guarantee that there is no reordering - when it doesn't buy you anything noticeable? Again, I have no problem with a mandate that MPLS boxes try hard to never reorder packets. But I find a *guarantee* of absolutely no reordering i) of great expense (in terms of complexity, mechanism, etc), and ii) of no real worth. Noel From owner-mpls@UU.NET Wed Jan 5 22:28:15 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20886 for ; Wed, 5 Jan 2000 22:28:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwtp03391; Thu, 6 Jan 2000 03:26:42 GMT Received: by mail-control.mail.uu.net id QQhwtp23477 for mpls-outgoing; Thu, 6 Jan 2000 03:26:06 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhwtp23466 for ; Thu, 6 Jan 2000 03:25:52 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwtp06627 for ; Wed, 5 Jan 2000 22:25:46 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhwtp07188 for ; Thu, 6 Jan 2000 03:25:45 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp139-254.cisco.com [144.254.139.254]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id TAA16292; Wed, 5 Jan 2000 19:25:41 -0800 (PST) Message-Id: <4.2.2.20000106123923.00ab0380@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Jan 2000 14:25:26 +1100 To: "Johnson, Robert (Broadwing)" From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Robert, >I apologize for not clarifying, but I was implying the inclusion of those >services that are not suitable for use over a pure, connectionless packet >network. There has been some discussion of using MPLS to provide >connection-oriented services, some of which are not designed to survive the >rigors of a connectionless packet network. If MPLS were to be utilized as a >transport protocol for customer access, it would need to be capable of >supporting these types of services. In other words, it needs to guarantee >ordered packet delivery or it should be not be used for these services. What services? Unless I've missed something, no-one has stated a problem for which it was argued that the best solution is modifying MPLS to ensure in-order packet delivery. If the problem is "carrying voice over MPLS", then guaranteed in-order delivery clearly isn't required. A suitable transport in a voice codec can simply discard out-of-sequence packets, and any vaguely adequate codec can gracefully deal with an occasional dropped packet. If the problem is "using my equipment with an extremely poor/old voice codec over an MPLS network", then the best solution seems to be: - Update the equipment to use an adequate codec (packetized 64kb/s PCM with an appropriate transport could be adequate, for example) - In the meantime, use ATM circuit emulation. All ATM-LSRs which I know about can simultaneously support circuit emulation services over PVCs, on the same links and switches that constitute the MPLS network backbone. If the problem is something else, then what is it? Regards, Jeremy Lawrence From owner-mpls@UU.NET Wed Jan 5 23:15:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22215 for ; Wed, 5 Jan 2000 23:15:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwts00205; Thu, 6 Jan 2000 04:14:45 GMT Received: by mail-control.mail.uu.net id QQhwts02299 for mpls-outgoing; Thu, 6 Jan 2000 04:14:10 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhwts02154 for ; Thu, 6 Jan 2000 04:13:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwts08730 for ; Wed, 5 Jan 2000 23:13:44 -0500 (EST) Received: from Level3.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sushi.eng.Level3.net [209.245.26.225]) id QQhwts29563 for ; Thu, 6 Jan 2000 04:13:43 GMT Received: from boyle.jimp.l3.com (localhost [127.0.0.1]) by Level3.net (8.9.3/8.9.3) with SMTP id EAA14282; Thu, 6 Jan 2000 04:13:34 GMT Message-Id: <4.1.20000105211428.0506ccc0@localhost> X-Sender: jboyle@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 05 Jan 2000 21:17:01 -0700 To: Greg Waters , Luca Martini From: Jim Boyle Subject: Re: Comments on draft-martini-l2circuit-trans-mpls-00.txt Cc: mpls@UU.NET In-Reply-To: <4.1.19991222174917.00ab63c0@mailhost.avici.com> References: <386151D3.C479627F@level3.net> <4.2.2.19991221112659.0456bf00@alpo.casc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 06:29 PM 12/22/99 -0500, Greg Waters wrote: >At 10:33 PM 12/22/99 +0000, Luca Martini wrote: >>> 2. There was no discussion of the requirements this particular draft was >>> trying to meet, or any comparison of the pluses and minuses of this draft >>> to any of the other L2 tunneling mechanisms in use, such as GRE. >> >>This method is meant to allow a service provider to offer frame-relay , >>or ATM AAL5 transport services across an MPLS backbone. > >Should your draft discuss tunneling raw ATM cells (sometimes called >"AAL0") over MPLS? In that case, OAM F5 cells flow naturally through >the tunnel, and the tunnel end-points can more easily complete the >ATM VCC service emulation (generate alarms or propagate F5 loopback). >In addition, tunneling raw ATM cells allows ATM VPC service emulation. >Putting multiple raw ATM cells into each MPLS packet might be >desirable for efficiency. Or as a thought (yes a late one :) - OAM F5 cells could be processed locally and tied into the state of an LSP. Similarly w/ andy's question on FR endtoend pvc management, LMI could manage either end of a PVC and tie into the state of the LSP. From owner-mpls@UU.NET Thu Jan 6 03:00:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05886 for ; Thu, 6 Jan 2000 03:00:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwuh09041; Thu, 6 Jan 2000 07:58:52 GMT Received: by mail-control.mail.uu.net id QQhwuh10270 for mpls-outgoing; Thu, 6 Jan 2000 07:58:13 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhwuh10265 for ; Thu, 6 Jan 2000 07:58:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwuh04318 for ; Thu, 6 Jan 2000 02:58:04 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQhwuh08463 for ; Thu, 6 Jan 2000 07:58:03 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id JAA21066; Thu, 6 Jan 2000 09:57:54 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14452.19202.677373.991264@lohi.eng.telia.fi> Date: Thu, 6 Jan 2000 09:57:54 +0200 (EET) To: Jeremy Lawrence Cc: Shahram Davari , mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber In-Reply-To: <4.2.2.20000106094859.00a84cf0@farley.cisco.com> References: <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeremy Lawrence writes: > I have been involved in network designs where edge LSRs are customer > located equipment, but that involved a requirement that the edge > LSRs were placed only in a physically secure environment, e.g. > a telco-controlled distribution room in a building. why is that? you can use soft permanent lsps (once we have got them defined) between the cpe lsr and the operator lsr. you could also use real signaled lsps and install an access list in the operator lsr that controls what kind of destination addresses can be used. -- juha From owner-mpls@UU.NET Thu Jan 6 06:28:04 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06888 for ; Thu, 6 Jan 2000 06:28:03 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwuv17295; Thu, 6 Jan 2000 11:25:43 GMT Received: by mail-control.mail.uu.net id QQhwuv23684 for mpls-outgoing; Thu, 6 Jan 2000 11:25:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhwuv23676 for ; Thu, 6 Jan 2000 11:25:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwuv13356 for ; Thu, 6 Jan 2000 06:25:04 -0500 (EST) Received: from fsnt.future.futusoft.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQhwuv12231 for ; Thu, 6 Jan 2000 11:25:00 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 06 Jan 2000 17:02:03 +0530 Received: from kishoretm.future.futsoft.com ([172.16.1.13]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA06977; Thu, 6 Jan 2000 16:45:29 +0530 Received: by localhost with Microsoft MAPI; Thu, 6 Jan 2000 16:55:48 +0530 Message-Id: <01BF5866.E15648A0.kishoretm@future.futsoft.com> From: T M Kishore Reply-To: "kishoretm@future.futsoft.com" To: "'loa.andersson@nortelnetworks.com'" , "'pdoolan@ennovatenetworks.com'" , "'nkf@us.ibm.com'" , "'rhthomas@cisco.com'" , "Eric Gray [ewgray@lucent.com] (E-mail)" Cc: "'mpls@uu.net'" Subject: Receive Label Abort Request Date: Thu, 6 Jan 2000 16:55:46 +0530 Organization: Future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-mpls@UU.NET Precedence: bulk Hello, There is contradiction between the draft-ietf-mpls-ldp-06 and draft-ietf-mpls-ldp-state-02 . According draft-ldp-06, if Downsream LSR receives Label Abort Request from Upstream LSR after Downstream LSR sending Label Mapping Message to Upstream LSR, Downstream LSR should ignore the Label Abort Request Message . Draft-ldp-state-02 specifies the free the upstream Label and send LDP Release Message to Downstream LSR and delete the control Block. The draft-ietf-mpls-ldp-06 says " When an LSR receives a label abort request message from a peer, it checks whether it has already responded to the label request in question. If it has, it silently ignores the message. If it has not, it sends the peer a Label Request Aborted Notification. In addition, if it has a label request outstanding for the LSP in question to a downstream peer, it sends a Label Abort Request to the downstream peer to abort the LSP. " Algorithm: LAbR.1 Does the message match a previously received label request message from MsgSource? (See Note 1.) If not, goto LAbR.12. LAbR.2 Has LSR responded to the previously received label request? If so, goto LAbR.12. LAbR.12 DONE. " But draft-ietf-mpls-ldp-state-02 says as follows : State: ESTABLISHED Event: LDP Upstream Abort New State: IDLE Actions: Disconnect the upstream label from the downstream label. Free the upstream label. Send event "Internal Destroy" if the LSR was in the middle of switching over to the better next hop. Propagate an LDP-RELEASE message downstream and delete the LSP_Control_Block. Please clarify it. Thanks, Kishore T M Kishore, Senior Software Engineer, Future Software Pvt Ltd, 480 - 481, Anna Salai, Nandanam, Chennai - 600 035 India. Phone : +91-44-4330550 Ext.412 From owner-mpls@UU.NET Thu Jan 6 06:42:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07189 for ; Thu, 6 Jan 2000 06:42:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwuw24587; Thu, 6 Jan 2000 11:41:35 GMT Received: by mail-control.mail.uu.net id QQhwuw24713 for mpls-outgoing; Thu, 6 Jan 2000 11:40:53 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwuw24707 for ; Thu, 6 Jan 2000 11:40:49 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwuw06220 for ; Thu, 6 Jan 2000 06:40:42 -0500 (EST) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQhwuw19124 for ; Thu, 6 Jan 2000 11:40:40 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07114; Thu, 6 Jan 2000 06:40:41 -0500 (EST) Message-Id: <200001061140.GAA07114@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-bgp4-mpls-04.txt Date: Thu, 06 Jan 2000 06:40:41 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Carrying Label Information in BGP-4 Author(s) : Y. Rekhter, E. Rosen Filename : draft-ietf-mpls-bgp4-mpls-04.txt Pages : 7 Date : 05-Jan-00 When BGP is used to distribute a particular route, it can be also be used to distribute an MPLS label which is mapped to that route [MPLS-ARCH]. This document specifies the way in which this is done. The label mapping information for a particular route is piggybacked in the same BGP Update message that is used to distribute the route itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp4-mpls-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-bgp4-mpls-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-bgp4-mpls-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: <20000105142948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bgp4-mpls-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bgp4-mpls-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000105142948.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jan 6 07:09:22 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07717 for ; Thu, 6 Jan 2000 07:09:22 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwuy07319; Thu, 6 Jan 2000 12:08:24 GMT Received: by mail-control.mail.uu.net id QQhwuy29652 for mpls-outgoing; Thu, 6 Jan 2000 12:07:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhwuy29609 for ; Thu, 6 Jan 2000 12:07:52 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwuy15130 for ; Thu, 6 Jan 2000 07:07:52 -0500 (EST) Received: from kickme.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kickme.cisco.com [198.92.30.42]) id QQhwuy06904 for ; Thu, 6 Jan 2000 12:07:51 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id EAA03891; Thu, 6 Jan 2000 04:01:34 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id HAA09308; Thu, 6 Jan 2000 07:07:45 -0500 (EST) Message-Id: <200001061207.HAA09308@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: "kishoretm@future.futsoft.com" cc: "'loa.andersson@nortelnetworks.com'" , "'pdoolan@ennovatenetworks.com'" , "'nkf@us.ibm.com'" , "Eric Gray [ewgray@lucent.com] (E-mail)" , "'mpls@uu.net'" Subject: Re: Receive Label Abort Request In-reply-to: Your message of "Thu, 06 Jan 2000 16:55:46 +0530." <01BF5866.E15648A0.kishoretm@future.futsoft.com> Date: Thu, 06 Jan 2000 07:07:44 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Kishore, Plase note that LDP is specified by draft-ietf-mpls-ldp-06.txt. Bob > Hello, > There is contradiction between the draft-ietf-mpls-ldp-06 and > draft-ietf-mpls-ldp-state-02 . > According draft-ldp-06, if Downsream LSR receives Label Abort Request > from Upstream LSR after Downstream LSR sending Label Mapping Message to > Upstream LSR, Downstream LSR should ignore the Label Abort Request Message > . Draft-ldp-state-02 specifies the free the upstream Label and send LDP > Release Message to Downstream LSR and delete the control Block. > > The draft-ietf-mpls-ldp-06 says > > " When an LSR receives a label abort request message from a peer, it > checks whether it has already responded to the label request in > question. If it has, it silently ignores the message. If it has > not, it sends the peer a Label Request Aborted Notification. In > addition, if it has a label request outstanding for the LSP in > question to a downstream peer, it sends a Label Abort Request to > the downstream peer to abort the LSP. " > > Algorithm: > > LAbR.1 Does the message match a previously received label request > message from MsgSource? (See Note 1.) > If not, goto LAbR.12. > > LAbR.2 Has LSR responded to the previously received label request? > If so, goto LAbR.12. > > LAbR.12 DONE. " > > But draft-ietf-mpls-ldp-state-02 says as follows : > > State: ESTABLISHED > > Event: LDP Upstream Abort > > New State: IDLE > > Actions: > > Disconnect the upstream label from the downstream label. > > Free the upstream label. > > Send event "Internal Destroy" if the LSR was in the middle of > switching over to the better next hop. > > Propagate an LDP-RELEASE message downstream and delete the > LSP_Control_Block. > > Please clarify it. > Thanks, > Kishore > > T M Kishore, > Senior Software Engineer, > Future Software Pvt Ltd, > 480 - 481, Anna Salai, Nandanam, > Chennai - 600 035 > India. > Phone : +91-44-4330550 Ext.412 From owner-mpls@UU.NET Thu Jan 6 07:43:38 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08718 for ; Thu, 6 Jan 2000 07:43:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwva21770; Thu, 6 Jan 2000 12:41:54 GMT Received: by mail-control.mail.uu.net id QQhwva06794 for mpls-outgoing; Thu, 6 Jan 2000 12:41:17 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhwva06789 for ; Thu, 6 Jan 2000 12:41:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwva18175 for ; Thu, 6 Jan 2000 07:40:59 -0500 (EST) Received: from blaze.hcltech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [204.160.253.201]) id QQhwva26903 for ; Thu, 6 Jan 2000 12:40:52 GMT Received: from srikrishna-pc.lab ([192.168.201.29]) by blaze.hcltech.com (8.9.3/8.8.7) with SMTP id SAA25172; Thu, 6 Jan 2000 18:06:49 +0530 Date: Thu, 6 Jan 2000 18:06:49 +0530 Message-Id: <200001061236.SAA25172@blaze.hcltech.com> X-Sender: krish@192.168.201.1 X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "kishoretm@future.futsoft.com" From: Srikrishnan Venkataraman Subject: Re: Receive Label Abort Request Cc: mpls@UU.NET, ewgray@lucent.com, rhthomas@cisco.com, nkf@us.ibm.com, loa.andersson@nortelnetworks.com Sender: owner-mpls@UU.NET Precedence: bulk there are 2 cases: viz. 1. lsr not responded to the Label Request message in which case you send label Abort Notification message to the upstream. After this you need to check the downstream lsp state , whether it is in Response_Awaited state. If so Propagate Label Abort message to the Next Hop. Delete the upstream lsp block. 2. If downstream lsp state = Established (Not Sure this case can happen because once the lsr gets Label Mapping message from the Fec Next Hop and the upstream Lsp state is Response_Awaited (for Ordered Control mode) it sends a Label Mapping message to the upstream peer and this code shall execute as one single thread.............) assuming this scenario occurs and there are No upstream lsp (for Merge capable) it will behave as if It has Received a Label Release event from the Upstream peer and will propage the Label Release message to the Next Hop(if Label Release propagation has been configured). But Propagating Label Release makes sense because for that Lsp the concerned lsr is a Transit lsr. It would be logical to tear Down the Lsp. Any Comments>>>> At 04:55 PM 1/6/00 +0530, you wrote: >Hello, > There is contradiction between the draft-ietf-mpls-ldp-06 and > draft-ietf-mpls-ldp-state-02 . > According draft-ldp-06, if Downsream LSR receives Label Abort Request >from Upstream LSR after Downstream LSR sending Label Mapping Message to >Upstream LSR, Downstream LSR should ignore the Label Abort Request Message >. Draft-ldp-state-02 specifies the free the upstream Label and send LDP >Release Message to Downstream LSR and delete the control Block. > > The draft-ietf-mpls-ldp-06 says > > " When an LSR receives a label abort request message from a peer, it > checks whether it has already responded to the label request in > question. If it has, it silently ignores the message. If it has > not, it sends the peer a Label Request Aborted Notification. In > addition, if it has a label request outstanding for the LSP in > question to a downstream peer, it sends a Label Abort Request to > the downstream peer to abort the LSP. " > > Algorithm: > > LAbR.1 Does the message match a previously received label request > message from MsgSource? (See Note 1.) > If not, goto LAbR.12. > > LAbR.2 Has LSR responded to the previously received label request? > If so, goto LAbR.12. > > LAbR.12 DONE. " > > But draft-ietf-mpls-ldp-state-02 says as follows : > >State: ESTABLISHED > > Event: LDP Upstream Abort > > New State: IDLE > > Actions: > > Disconnect the upstream label from the downstream label. > > Free the upstream label. > > Send event "Internal Destroy" if the LSR was in the middle of > switching over to the better next hop. > > Propagate an LDP-RELEASE message downstream and delete the > LSP_Control_Block. > >Please clarify it. >Thanks, >Kishore > >T M Kishore, >Senior Software Engineer, >Future Software Pvt Ltd, >480 - 481, Anna Salai, Nandanam, >Chennai - 600 035 >India. >Phone : +91-44-4330550 Ext.412 > > > From owner-mpls@UU.NET Thu Jan 6 09:14:19 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12257 for ; Thu, 6 Jan 2000 09:14:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwvg14538; Thu, 6 Jan 2000 14:12:58 GMT Received: by mail-control.mail.uu.net id QQhwvg26226 for mpls-outgoing; Thu, 6 Jan 2000 14:12:20 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhwvg26174 for ; Thu, 6 Jan 2000 14:12:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwvg16746 for ; Thu, 6 Jan 2000 09:12:03 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhwvg08861 for ; Thu, 6 Jan 2000 14:12:03 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jan 6 09:11:41 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.42.36]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA26289; Thu, 6 Jan 2000 09:10:26 -0500 (EST) Message-ID: <3874A368.7988C824@lucent.com> Date: Thu, 06 Jan 2000 09:15:04 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Srikrishnan Venkataraman CC: "kishoretm@future.futsoft.com" , mpls@UU.NET, rhthomas@cisco.com, nkf@us.ibm.com, loa.andersson@nortelnetworks.com Subject: Re: Receive Label Abort Request References: <200001061236.SAA25172@blaze.hcltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Srikrishnan and Kishore, Thanks for pointing this out. As Bob Thomas said already, the LDP specification specifies correct behavior. The section in question in the LDP state draft is incorrect for the reason that Srikrishnan mentions below - i.e. the Established State means I have sent (or at least queued for sending) a Label Mapping upstream. While I do not necessarily agree that an implementation must send the Label Mapping message upstream necessarily on the same thread as the one on which it received a Label Mapping from downstream, it is valid to assume that this is done in the simplistic state machine described in the draft. (Implementations that use a multi-threaded approach in this instance, may have a more complex state-machine which is none-the-less compatible with that which the draft defines). Although the last call has closed, we will work out a corrected wording that is consistent with the LDP specification for this bug in the draft. Thanks again, Eric Gray You wrote: > > there are 2 cases: > viz. > 1. lsr not responded to the Label Request message in which case you send > label Abort Notification message to the upstream. > After this you need to check the downstream lsp state , whether it is in > Response_Awaited state. If so Propagate Label Abort message to the Next Hop. > Delete the upstream lsp block. > > 2. If downstream lsp state = Established (Not Sure this case can happen because > once the lsr gets Label Mapping message from the Fec Next Hop and the > upstream Lsp state is Response_Awaited (for Ordered Control mode) > it sends a Label Mapping message to the upstream peer and this code shall > execute as one single thread.............) > assuming this scenario occurs and there are No upstream lsp (for Merge > capable) > it will behave as if It has Received a Label Release event from the > Upstream peer > and will propage the Label Release message to the Next Hop(if Label > Release propagation > has been configured). But Propagating Label Release makes sense because > for that Lsp > the concerned lsr is a Transit lsr. It would be logical to tear Down the Lsp. > > Any Comments>>>> > > > > At 04:55 PM 1/6/00 +0530, you wrote: > >Hello, > > There is contradiction between the draft-ietf-mpls-ldp-06 and > > draft-ietf-mpls-ldp-state-02 . > > According draft-ldp-06, if Downsream LSR receives Label Abort Request > >from Upstream LSR after Downstream LSR sending Label Mapping Message to > >Upstream LSR, Downstream LSR should ignore the Label Abort Request Message > >. Draft-ldp-state-02 specifies the free the upstream Label and send LDP > >Release Message to Downstream LSR and delete the control Block. > > > > The draft-ietf-mpls-ldp-06 says > > > > " When an LSR receives a label abort request message from a peer, it > > checks whether it has already responded to the label request in > > question. If it has, it silently ignores the message. If it has > > not, it sends the peer a Label Request Aborted Notification. In > > addition, if it has a label request outstanding for the LSP in > > question to a downstream peer, it sends a Label Abort Request to > > the downstream peer to abort the LSP. " > > > > Algorithm: > > > > LAbR.1 Does the message match a previously received label request > > message from MsgSource? (See Note 1.) > > If not, goto LAbR.12. > > > > LAbR.2 Has LSR responded to the previously received label request? > > If so, goto LAbR.12. > > > > LAbR.12 DONE. " > > > > But draft-ietf-mpls-ldp-state-02 says as follows : > > > >State: ESTABLISHED > > > > Event: LDP Upstream Abort > > > > New State: IDLE > > > > Actions: > > > > Disconnect the upstream label from the downstream label. > > > > Free the upstream label. > > > > Send event "Internal Destroy" if the LSR was in the middle of > > switching over to the better next hop. > > > > Propagate an LDP-RELEASE message downstream and delete the > > LSP_Control_Block. > > > >Please clarify it. > >Thanks, > >Kishore > > > >T M Kishore, > >Senior Software Engineer, > >Future Software Pvt Ltd, > >480 - 481, Anna Salai, Nandanam, > >Chennai - 600 035 > >India. > >Phone : +91-44-4330550 Ext.412 > > > > > > From owner-mpls@UU.NET Thu Jan 6 19:13:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25653 for ; Thu, 6 Jan 2000 19:13:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwwu28362; Fri, 7 Jan 2000 00:12:16 GMT Received: by mail-control.mail.uu.net id QQhwwu04229 for mpls-outgoing; Fri, 7 Jan 2000 00:11:07 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwwu04065 for ; Fri, 7 Jan 2000 00:10:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwwu04714 for ; Thu, 6 Jan 2000 19:10:50 -0500 (EST) Received: from hitiij.hitachi.co.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hitiij.hitachi.co.jp [133.145.224.3]) id QQhwwu27383 for ; Fri, 7 Jan 2000 00:10:48 GMT Received: from newton.ebina.hitachi.co.jp by hitiij.hitachi.co.jp (8.9.3/3.7W-hitiij) id JAA15628; Fri, 7 Jan 2000 09:10:43 +0900 (JST) Received: from gpc.ebina.hitachi.co.jp (root@gpc.ebina.hitachi.co.jp [158.214.169.213]) by newton.ebina.hitachi.co.jp (8.9.0/3.7W-EBINA) with ESMTP id JAA18044 for ; Fri, 7 Jan 2000 09:10:42 +0900 (JST) Received: from m-nakaya.ebina.hitachi.co.jp ([172.16.109.207]) by gpc.ebina.hitachi.co.jp (8.9.1/3.7W-EBINA-local) with SMTP id JAA18264 for ; Fri, 7 Jan 2000 09:10:40 +0900 (JST) Message-Id: <200001070007.AA00139@m-nakaya.ebina.hitachi.co.jp> From: Nakayama Masaki Date: Fri, 07 Jan 2000 09:07:22 +0900 To: mpls@UU.NET Subject: test mail MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.11 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk It's a test mail. Please ignore it. --------------------- Nakayama Masaki Hitachi System Development Laboratory m-nakaya@sdl.hitachi.co.jp From owner-mpls@UU.NET Thu Jan 6 19:55:55 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26044 for ; Thu, 6 Jan 2000 19:55:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwwx26796; Fri, 7 Jan 2000 00:53:15 GMT Received: by mail-control.mail.uu.net id QQhwwx08405 for mpls-outgoing; Fri, 7 Jan 2000 00:52:47 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhwwx08398 for ; Fri, 7 Jan 2000 00:52:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwwx22240 for ; Thu, 6 Jan 2000 19:52:33 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhwwx26309 for ; Fri, 7 Jan 2000 00:52:32 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA04202; Thu, 6 Jan 2000 16:51:56 -0800 (PST) Message-Id: <4.2.2.20000107112802.00a893e0@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 07 Jan 2000 11:51:47 +1100 To: Juha Heinanen From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <14452.19202.677373.991264@lohi.eng.telia.fi> References: <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Juha, At 09:57 01/06/2000 +0200, Juha Heinanen wrote: >Jeremy Lawrence writes: > > > I have been involved in network designs where edge LSRs are customer > > located equipment, but that involved a requirement that the edge > > LSRs were placed only in a physically secure environment, e.g. > > a telco-controlled distribution room in a building. > >why is that? you can use soft permanent lsps (once we have got >them defined) between the cpe lsr and the operator lsr. you could also >use real signaled lsps and install an access list in the operator lsr >that controls what kind of destination addresses can be used. First, a clarification: the customer located edge LSR I mentioned was an operator LSR, dealing with CPE from several different customers. But on to the real issue, which is when/if it makes sense to turn on MPLS on CPE... Looking first at performance: using MPLS on CPE would seem to be of performance benefit if the operator LSR was going to be able to label-switch the packets without pushing extra labels, and without looking into the IP headers of the packet. One requirement for this would be for the routes as seen by the customer LSR to have the same granularity of (a subset of) the operator's IGP routes. (In other words, it is highly unlikely that the CPE could simply point "default" at the operator router, which breaks a common operational requirement.) In the unlikely event that this condition could be met, then the operator LSR could then be, say, an ATM-LSR, with the "router-like" edge functions offloaded to the CPE LSR. In the more likely case that the routing granularity is different for some reason, then the operator LSR would need to look into the IP packets from the CPE LSR, and have to act as an edge LSR. (Also, if TE or VPNs were used, the operator LSR might well have to push and pop labels, which might also implies "edge LSR" function and overhead.) So, from a performance perspective, there would be little point having the CPE router act as an edge LSR, as the extra work required in the operator LSR for the CPE LSR to send unlabelled IP packets would be marginal. Having both the CPE router and the operator router act as edge LSRs would make sense, though, if the goal was to use MPLS for protection switching between the CPE LSR and the operator LSR. (Which, I think, was one of your points?) Regards, Jeremy Lawrence From owner-mpls@UU.NET Fri Jan 7 01:51:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04131 for ; Fri, 7 Jan 2000 01:51:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwxv07898; Fri, 7 Jan 2000 06:48:19 GMT Received: by mail-control.mail.uu.net id QQhwxv16413 for mpls-outgoing; Fri, 7 Jan 2000 06:47:46 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhwxv16406 for ; Fri, 7 Jan 2000 06:47:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhwxv23938 for ; Fri, 7 Jan 2000 01:47:34 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQhwxv17556 for ; Fri, 7 Jan 2000 06:47:33 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id IAA24075; Fri, 7 Jan 2000 08:47:27 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14453.35839.381205.551578@lohi.eng.telia.fi> Date: Fri, 7 Jan 2000 08:47:27 +0200 (EET) To: Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber In-Reply-To: <4.2.2.20000107112802.00a893e0@farley.cisco.com> References: <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000107112802.00a893e0@farley.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jeremy, i didn't understand anything you said about granularity of igp routes, default route, etc. i don't need any of that in order to use mpls in the cpe router. my model would be exactly the same as in case of using atm in a cpe router (adsl or something else). the cpe router simply sets up lsps to ip addresses of other cpe routers or isp routers, or receives lsp setups from them or defines permanent lsps that match operator defined soft permanent lsps. if the cpe router is not multihomed, there is no need to run any routing protocol between it and the operator lsr. the cpe router can learn the ip addresses of the target routers for the lsp setups by any offline means. -- juha From owner-mpls@UU.NET Fri Jan 7 08:58:09 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17644 for ; Fri, 7 Jan 2000 08:58:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwyx10946; Fri, 7 Jan 2000 13:55:34 GMT Received: by mail-control.mail.uu.net id QQhwyx07470 for mpls-outgoing; Fri, 7 Jan 2000 13:54:50 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhwyx07459 for ; Fri, 7 Jan 2000 13:54:32 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwyx17966 for ; Fri, 7 Jan 2000 08:54:27 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQhwyx10306 for ; Fri, 7 Jan 2000 13:54:25 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jan 2000 13:54:13 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FE42@monk.datcon.co.uk> From: Adrian Farrel To: "Thomas D. Nadeau" Cc: mpls@UU.NET Subject: Re: MPLS TE MIB Date: Fri, 7 Jan 2000 13:54:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tom, A further thought... The CR-LDP ER-Hop TLV can be of type LSPID to allow an LSP to be "tunneled" down another LSP for the next hop. This is not currently reflected in the MIB. I think you need to modify as follows. MplsTunnelHopEntry ::= SEQUENCE { mplsTunnelHopIndex Integer32, mplsTunnelHopAddrType INTEGER, mplsTunnelHopIpv4Addr IpAddress, mplsTunnelHopIpv4PrefixLen INTEGER, mplsTunnelHopIpv6Addr Ipv6Address, mplsTunnelHopIpv6PrefixLen INTEGER, mplsTunnelHopAsNumber INTEGER, mplsTunnelHopLspId INTEGER, mplsTunnelHopStrictOrLoose INTEGER, mplsTunnelHopRowStatus RowStatus } mplsTunnelHopAddrType OBJECT-TYPE SYNTAX INTEGER { ipV4(1), ipV6(2), asNumber(3), lspId(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "Address type of this hop." DEFVAL { ipV4 } ::= { mplsTunnelHopEntry 2 } mplsTunnelHopLspId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(6)) MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsTunnelHopAddrType is lspId(4), the LSPID over which to route this hop. This is encoded as two bytes of Local LSPID followed by four bytes of Ingress LSR Router ID. This object is not significant otherwise and should return a value of 0." ::= { mplsTunnelHopEntry 8 } What do you think? Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Fri Jan 7 14:51:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26053 for ; Fri, 7 Jan 2000 14:51:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwzv01705; Fri, 7 Jan 2000 19:45:07 GMT Received: by mail-control.mail.uu.net id QQhwzu20748 for mpls-outgoing; Fri, 7 Jan 2000 19:44:31 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwzu20729 for ; Fri, 7 Jan 2000 19:44:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwzu23503 for ; Fri, 7 Jan 2000 14:43:54 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhwzu13857 for ; Fri, 7 Jan 2000 19:43:53 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Fri, 7 Jan 2000 14:43:48 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A19C5EB@email.quarrytech.com> From: "Ballou, Ken" To: mpls@UU.NET Subject: Confusion about terminology in draft-ietf-mpls-atm-02.txt Date: Fri, 7 Jan 2000 14:43:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I have been struggling mightily with the terminology and definitions in "MPLS using LDP and ATM VC Switching." First, I notice the draft is dated April, 1999, and expired October, 1999. What is the current status of this document? (I'll call that "Question 0." :-) Question 1: In section 3, the following definition is given for an ATM-LSR: An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards cells between these interfaces using labels carried in the VCI or VPI/VCI field. Since the definition of "LC-ATM interface" specifies explicitly that the "top label is inferred either from the contents of the VCI field or the combined contents of the VPI and VCI fields," would it be correct to state that the clause "which forwards cells ..." in the definition of an ATM-LSR is redundant? That is, simply containing at least one LC-ATM interface makes an LSR be an ATM-LSR? (I'm not trying to be uselessly pedantic here. This is one cause of my confusion later.) Question 2: A frame-based LSR is defined as "a LSR which forwards complete frames between its interfaces." My interpretation of "forwards complete frames" is that once the first bit of the layer 3 PDU (along with any layer 2 encapsulation) appears on the physical link, there are no intervening bits until the entire frame is sent. (So, for example, ethernet forwards complete frames, but ATM-LSRs do not [since cells for other VPI/VCIs can be freely intermixed with cells for the current frame].) Does the definition of frame-based LSR require that complete frames appear on both the ingress and the egress interface? (That's how I interpret it.) Or does it mean that there is a complete frame on _at least one_ interface? I could word this question another way. Here's a router with three interfaces: gigabit +--------+ ATM OC-12 ethernet | +------------- ------------+ | | +------------- +--------+ ATM OC-12 Assume that the two ATM OC-12 interfaces are LC-ATM interfaces. Does this router then meet the definition of "frame-based LSR"? I assume the LC-ATM interfaces do not forward complete frames, since cells can be interleaved. But if the definition of "frame-based LSR" requires finding a pair of interfaces which forward complete interfaces, this can't be a frame-based LSR. (I'm hung up on this because I'm trying to understand whether this device can be an "Edge LSR.") Question 3: The Edge Set of an ATM-LSR domain is defined as "the set of frame-based LSRs which are connected to members of the domain by LC-ATM interfaces." Since at ATM-LSR domain is defined as "a set of ATM-LSRs which are mutually interconnected by LC-ATM interfaces," I conclude that the "Edge LSRs," which are the members of the Edge Set, are also members of the ATM-LSR domain. However, in the last sentence of the first paragraph of section 8, I read: "these 'Edge LSRs' are not themselves ATM-LSRs". This appears to contradict the definitions of section 3. Thanks in advance for any enlightenment. - Ken From owner-mpls@UU.NET Fri Jan 7 15:42:42 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26911 for ; Fri, 7 Jan 2000 15:42:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhwzy14926; Fri, 7 Jan 2000 20:36:51 GMT Received: by mail-control.mail.uu.net id QQhwzy01893 for mpls-outgoing; Fri, 7 Jan 2000 20:36:13 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhwzy01852 for ; Fri, 7 Jan 2000 20:36:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhwzy28190 for ; Fri, 7 Jan 2000 15:36:03 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhwzy14321 for ; Fri, 7 Jan 2000 20:36:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Jan 7 15:35:01 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.40.238]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA06091; Fri, 7 Jan 2000 15:34:53 -0500 (EST) Message-ID: <38764F03.91BF2FAC@lucent.com> Date: Fri, 07 Jan 2000 15:39:31 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Ballou, Ken" CC: mpls@UU.NET Subject: Re: Confusion about terminology in draft-ietf-mpls-atm-02.txt References: <496A8683261CD211BF6C0008C733261A19C5EB@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Ballou, Ken" wrote: > > I have been struggling mightily with the terminology and definitions in > "MPLS using LDP and ATM VC Switching." First, I notice the draft is dated > April, 1999, and expired October, 1999. What is the current status of this > document? (I'll call that "Question 0." :-) It's in the process of becoming an RFC. Whether it is currently in the RFC editor's hands I don't know. Once it gets to this state, there is no need to 'refresh' it in order to keep it from expiring. > > Question 1: > > In section 3, the following definition is given for an ATM-LSR: > > An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards > cells between these interfaces using labels carried in the VCI or > VPI/VCI field. > > Since the definition of "LC-ATM interface" specifies explicitly that the > "top label is inferred either from the contents of the VCI field or the > combined contents of the VPI and VCI fields," would it be correct to state > that the clause "which forwards cells ..." in the definition of an ATM-LSR > is redundant? That is, simply containing at least one LC-ATM interface > makes an LSR be an ATM-LSR? (I'm not trying to be uselessly pedantic here. > This is one cause of my confusion later.) In the english language, redundancy is often a good thing. > > Question 2: > > A frame-based LSR is defined as "a LSR which forwards complete frames > between its interfaces." My interpretation of "forwards complete frames" is > that once the first bit of the layer 3 PDU (along with any layer 2 > encapsulation) appears on the physical link, there are no intervening bits > until the entire frame is sent. (So, for example, ethernet forwards > complete frames, but ATM-LSRs do not [since cells for other VPI/VCIs can be > freely intermixed with cells for the current frame].) > > Does the definition of frame-based LSR require that complete frames appear > on both the ingress and the egress interface? (That's how I interpret it.) > Or does it mean that there is a complete frame on _at least one_ interface? In forwarding a complete frame from an input interface to an output interface, the frame would appear first on one, and then on the other - wouldn't it? > > I could word this question another way. Here's a router with three > interfaces: > > gigabit +--------+ ATM OC-12 > ethernet | +------------- > ------------+ | > | +------------- > +--------+ ATM OC-12 > > Assume that the two ATM OC-12 interfaces are LC-ATM interfaces. Does this > router then meet the definition of "frame-based LSR"? I assume the LC-ATM > interfaces do not forward complete frames, since cells can be interleaved. > But if the definition of "frame-based LSR" requires finding a pair of > interfaces which forward complete interfaces, this can't be a frame-based > LSR. (I'm hung up on this because I'm trying to understand whether this > device can be an "Edge LSR.") Ah. My feeling is that an LSR is necessarily a frame based LSR if it receives whole frames (as in this case) since they will be translated into AAL5 PDUs before being pushed down to the ATM layer and broken into cells. It also follows that the LSR is frame based in the reverse direction because the ATM cells would be re-assembled into an AAL-5 PDU in order to be transmitted as whole frames via an ethernet interface. > > Question 3: > > The Edge Set of an ATM-LSR domain is defined as "the set of frame-based LSRs > which are connected to members of the domain by LC-ATM interfaces." Since > at ATM-LSR domain is defined as "a set of ATM-LSRs which are mutually > interconnected by LC-ATM interfaces," I conclude that the "Edge LSRs," which > are the members of the Edge Set, are also members of the ATM-LSR domain. > However, in the last sentence of the first paragraph of section 8, I read: > "these 'Edge LSRs' are not themselves ATM-LSRs". This appears to contradict > the definitions of section 3. Well, not so much so if you assume that the definition of frame based is actually as I've explained it above. There is the fuzziness that surrounds an LSR that has multiple LC-ATM interfaces and at least one interface that is not an ATM interface. In this case, forwarding between LC-ATM interfaces will not be frame-based while forwarding between any interface and a non-ATM interface will be. I would think of this as a hybrid LSR. > > Thanks in advance for any enlightenment. > > - Ken From owner-mpls@UU.NET Fri Jan 7 18:50:41 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29203 for ; Fri, 7 Jan 2000 18:50:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxal29271; Fri, 7 Jan 2000 23:47:53 GMT Received: by mail-control.mail.uu.net id QQhxal08698 for mpls-outgoing; Fri, 7 Jan 2000 23:47:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxal08687 for ; Fri, 7 Jan 2000 23:47:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxal15247 for ; Fri, 7 Jan 2000 18:46:53 -0500 (EST) Received: from smtprich.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprich.nortel.com [192.135.215.8]) id QQhxal28610 for ; Fri, 7 Jan 2000 23:46:52 GMT Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprich.nortel.com; Fri, 7 Jan 2000 17:46:45 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jan 2000 17:46:09 -0600 Message-ID: From: "Badarinath Devalla" To: "'mpls@uu.net'" Cc: "Badarinath Devalla" Subject: Carrying Private Lines over an MPLS network Date: Fri, 7 Jan 2000 17:46:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5969.5F245D00" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5969.5F245D00 Content-Type: text/plain Howdy ! What is the migration path for carriers using cross-connects to carry private line services (unidentified private line) when their network evolves to an MPLS-based network ? In other words, if a carrier deploys an MPLS backbone (let us say, no CSRs but routers acting as LSRs), how are the private lines (say DS1 and above rates) served ? On a related note, I was looking for drafts on MPLS VPN work and found a message from Dec 98 (MPLS list archive: http://cell.onecall.net/mhonarc/mpls/1998-Dec/msg00017.html) on draft-rosen-vpn-mpls-00.txt - are there any updates to this draft ? (Looking for tunnelling info over an MPLS network) Thanks in advance badari ----- Badari Devalla IP & ATM Network Planning Business & Network Consulting, Richardson bdevalla@nortelnetworks.com Tel: (972) 685 5174 (W), (972) 414 6453 (H) ------_=_NextPart_001_01BF5969.5F245D00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Carrying Private Lines over an MPLS network

Howdy !
What is the migration path for = carriers using cross-connects to carry private line services = (unidentified private line) when their network evolves to an MPLS-based = network ?

In other words, if a carrier deploys = an MPLS backbone (let us say, no CSRs but routers acting as LSRs), how = are the private lines (say DS1 and above rates) served ?

On a related note, I was looking for = drafts on MPLS VPN work and found a message from Dec 98 (MPLS list = archive: http://cell.onecall.net/mhonarc/mpls/1998-Dec/msg00017= .html) on = draft-rosen-vpn-mpls-00.txt - are there any updates to this draft ? = (Looking for tunnelling info over an MPLS network)

Thanks in advance
badari

-----

Badari = Devalla

IP & ATM Network = Planning

Business & Network = Consulting, Richardson

bdevalla@nortelnetworks.com

Tel: (972) 685 5174 = (W), (972) 414 6453 (H)

------_=_NextPart_001_01BF5969.5F245D00-- From owner-mpls@UU.NET Sat Jan 8 01:43:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06575 for ; Sat, 8 Jan 2000 01:43:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxbm15144; Sat, 8 Jan 2000 06:41:17 GMT Received: by mail-control.mail.uu.net id QQhxbm27016 for mpls-outgoing; Sat, 8 Jan 2000 06:40:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxbm27005 for ; Sat, 8 Jan 2000 06:40:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxbm18686 for ; Sat, 8 Jan 2000 01:40:17 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxbm14458 for ; Sat, 8 Jan 2000 06:40:16 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id WAA00102; Fri, 7 Jan 2000 22:40:08 -0800 (PST) Message-Id: <4.2.2.20000108171944.00a94170@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 08 Jan 2000 17:39:58 +1100 To: "Ballou, Ken" From: Jeremy Lawrence Subject: Re: Confusion about terminology in draft-ietf-mpls-atm-02.txt Cc: mpls@UU.NET, ewgray@lucent.com In-Reply-To: <38764F03.91BF2FAC@lucent.com> References: <496A8683261CD211BF6C0008C733261A19C5EB@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Some comments... At 15:39 01/07/2000 -0500, Eric Gray wrote: >"Ballou, Ken" wrote: [...] > > Question 1: > > > > In section 3, the following definition is given for an ATM-LSR: > > > > An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards > > cells between these interfaces using labels carried in the VCI or > > VPI/VCI field. > > > > Since the definition of "LC-ATM interface" specifies explicitly that the > > "top label is inferred either from the contents of the VCI field or the > > combined contents of the VPI and VCI fields," would it be correct to state > > that the clause "which forwards cells ..." in the definition of an ATM-LSR > > is redundant? That is, simply containing at least one LC-ATM interface > > makes an LSR be an ATM-LSR? (I'm not trying to be uselessly pedantic here. > > This is one cause of my confusion later.) > >In the english language, redundancy is often a good thing. It's not redundant. A frame-based LSR can have one or more LC-ATM interfaces. An ATM-LSR, in addition, forwards cells. This often implies that it has limited ability do deal with frame-based operations like pushing and popping labels, and LDP has some features to deal with this (e.g. an assumption that ATM-LSRs cannot do penultimate hop popping). > > > > Question 2: > > > > A frame-based LSR is defined as "a LSR which forwards complete frames > > between its interfaces." My interpretation of "forwards complete frames" is > > that once the first bit of the layer 3 PDU (along with any layer 2 > > encapsulation) appears on the physical link, there are no intervening bits > > until the entire frame is sent. (So, for example, ethernet forwards > > complete frames, but ATM-LSRs do not [since cells for other VPI/VCIs can be > > freely intermixed with cells for the current frame].) > > > > Does the definition of frame-based LSR require that complete frames appear > > on both the ingress and the egress interface? (That's how I interpret it.) > > Or does it mean that there is a complete frame on _at least one_ interface? No, a frame-based LSR can have one or more LC-ATM interfaces. > > I could word this question another way. Here's a router with three > > interfaces: > > > > gigabit +--------+ ATM OC-12 > > ethernet | +------------- > > ------------+ | > > | +------------- > > +--------+ ATM OC-12 > > > > Assume that the two ATM OC-12 interfaces are LC-ATM interfaces. Does this > > router then meet the definition of "frame-based LSR"? Assuming it could deal with whole frames and frame-based operations like pushing and popping several labels, then it would be a frame-based LSR. > > Question 3: > > > > The Edge Set of an ATM-LSR domain is defined as "the set of frame-based LSRs > > which are connected to members of the domain by LC-ATM interfaces." Since > > at ATM-LSR domain is defined as "a set of ATM-LSRs which are mutually > > interconnected by LC-ATM interfaces," I conclude that the "Edge LSRs," which > > are the members of the Edge Set, are also members of the ATM-LSR domain. Edge LSRs cannot be members of the ATM-LSR domain as they are not ATM-LSRs. Hope this helps, Jeremy From owner-mpls@UU.NET Sat Jan 8 02:12:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15074 for ; Sat, 8 Jan 2000 02:12:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxbo29318; Sat, 8 Jan 2000 07:11:16 GMT Received: by mail-control.mail.uu.net id QQhxbo06241 for mpls-outgoing; Sat, 8 Jan 2000 07:10:42 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxbo06236 for ; Sat, 8 Jan 2000 07:10:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxbo03816 for ; Sat, 8 Jan 2000 02:10:34 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxbo28833 for ; Sat, 8 Jan 2000 07:10:34 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id XAA02844; Fri, 7 Jan 2000 23:09:58 -0800 (PST) Message-Id: <4.2.2.20000108174032.00a931d0@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 08 Jan 2000 18:09:48 +1100 To: Juha Heinanen From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <14453.35839.381205.551578@lohi.eng.telia.fi> References: <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000107112802.00a893e0@farley.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Juha, At 08:47 01/07/2000 +0200, Juha Heinanen wrote: >i didn't understand anything you said about granularity of igp routes, >default route, etc. i don't need any of that in order to use mpls in >the cpe router. my model would be exactly the same as in case of using >atm in a cpe router (adsl or something else). > >the cpe router simply sets up lsps to ip addresses of other cpe routers >or isp routers, or receives lsp setups from them or defines permanent >lsps that match operator defined soft permanent lsps. if the cpe router >is not multihomed, there is no need to run any routing protocol between >it and the operator lsr. the cpe router can learn the ip addresses of >the target routers for the lsp setups by any offline means. Yes, MPLS can be run on the CPE. I'm addressing a somewhat different issue, which is whether any benefit is derived by running MPLS on the CPE. Unless the CPE knows routing information with the same granularity as the operator LSR, there is little or no performance benefit to the operator LSR if the CPE is an LSR. If the granularities are different, then the operator LSR must look at the IP address in the packets from the CPE, in order to re-label then with a label corresponding to the correct address-prefix. In general, the CPE may know routing information with a different granularity to the operator LSR (e.g. it would often know exactly two routes: one customer network, and a default route through the operator LSR). Let's look an example. 20.0.0.0/8---CPE-----Operator LSR x y Let's look a the case where the Operator LSR is an ATM-LSR. The operator LSR might have thousands of entries in its forwarding table, e.g. 0.0.0.0/0 10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.1.1/32 10.2.0.0/16 20.0.0.0/8 ... On the other hand the CPE probably has a table like 0.0.0.0/0 y 20.0.0.0/8 x Now assume that the CPE wants to send a packet to 10.1.1.2. It would label it to be sent to 0.0.0.0/0. There is no way that the operator LSR could forward this correctly. So there is no point running a network in this configuration, unless the CPE knows the same thousands of routes as the operator LSR, which would imply the running of a routing protocol to the CPE. This may well be unacceptable. If the Operator LSR is a frame-based LSR, then it would advertise thousands of labels to the CPE. Assuming that the CPE has enough memory to deal with all the labels (it's expected to deal with thousands of labels even though it has only two routes), then it could label the packet so that it can be forwarded correctly by the operator LSR. However the operator LSR can probably deal with unlabelled IP packets with similar performance to labelled packets (this is true for all the frame-based LSRs with which I'm familiar). So, in general, there is little performance benefit to running MPLS on the CPE. There may be other benefits. Regards, Jeremy From owner-mpls@UU.NET Sat Jan 8 02:33:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16283 for ; Sat, 8 Jan 2000 02:33:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxbq08334; Sat, 8 Jan 2000 07:30:57 GMT Received: by mail-control.mail.uu.net id QQhxbq07591 for mpls-outgoing; Sat, 8 Jan 2000 07:30:23 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhxbq07585 for ; Sat, 8 Jan 2000 07:30:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxbq04613 for ; Sat, 8 Jan 2000 02:30:03 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQhxbq07721 for ; Sat, 8 Jan 2000 07:30:02 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id JAA27850; Sat, 8 Jan 2000 09:29:56 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14454.59252.645730.305366@lohi.eng.telia.fi> Date: Sat, 8 Jan 2000 09:29:56 +0200 (EET) To: Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber In-Reply-To: <4.2.2.20000108174032.00a931d0@farley.cisco.com> References: <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000108174032.00a931d0@farley.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit yes, looks like we are not talking about the same thing at all. in my model, the operator lsr would not announce any labels to the cpe lsr. all labels that the cpe lsr would know of are those that it had got back as responses to its own label request messages and it would send label request messages only for those destinations that it is interested in sending packets to, e.g., an isp lsr and an lsr of another site of the same company. -- juha From owner-mpls@UU.NET Sat Jan 8 07:05:28 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17898 for ; Sat, 8 Jan 2000 07:05:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxci12520; Sat, 8 Jan 2000 12:04:43 GMT Received: by mail-control.mail.uu.net id QQhxci26195 for mpls-outgoing; Sat, 8 Jan 2000 12:04:05 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxci26140 for ; Sat, 8 Jan 2000 12:03:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxci17831 for ; Sat, 8 Jan 2000 07:03:50 -0500 (EST) Received: from relay1.pair.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: relay1.pair.com [209.68.1.20]) id QQhxci11928 for ; Sat, 8 Jan 2000 12:03:49 GMT Received: (qmail 23799 invoked from network); 8 Jan 2000 12:03:31 -0000 Received: from flure.pair.com (HELO ragnarok) (209.68.1.159) by relay1.pair.com with SMTP; 8 Jan 2000 12:03:31 -0000 X-pair-Authenticated: 209.68.1.159 From: "Thomas Wolfram" To: , Subject: RE: prime time MPLS/fiber Date: Sat, 8 Jan 2000 13:05:03 +0100 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: <4.2.2.20000108174032.00a931d0@farley.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA17898 > Juha, > > At 08:47 01/07/2000 +0200, Juha Heinanen wrote: > >i didn't understand anything you said about granularity of igp routes, > >default route, etc. i don't need any of that in order to use mpls in > >the cpe router. my model would be exactly the same as in case of using > >atm in a cpe router (adsl or something else). > > > >the cpe router simply sets up lsps to ip addresses of other cpe routers > >or isp routers, or receives lsp setups from them or defines permanent > >lsps that match operator defined soft permanent lsps. if the cpe router > >is not multihomed, there is no need to run any routing protocol between > >it and the operator lsr. the cpe router can learn the ip addresses of > >the target routers for the lsp setups by any offline means. > > Yes, MPLS can be run on the CPE. I'm addressing a somewhat different > issue, which is whether any benefit is derived by running MPLS on > the CPE. > > Unless the CPE knows routing information with the same granularity > as the operator LSR, there is little or no performance benefit > to the operator LSR if the CPE is an LSR. If the granularities > are different, then the operator LSR must look at the IP address > in the packets from the CPE, in order to re-label then with a > label corresponding to the correct address-prefix. > > In general, the CPE may know routing information with a different > granularity to the operator LSR (e.g. it would often know exactly > two routes: one customer network, and a default route through > the operator LSR). > > Let's look an example. > > 20.0.0.0/8---CPE-----Operator LSR > x y > > Let's look a the case where the Operator LSR is an ATM-LSR. > The operator LSR might have thousands of entries in its > forwarding table, e.g. > 0.0.0.0/0 > 10.0.0.0/8 > 10.1.0.0/16 > 10.1.1.0/24 > 10.1.1.1/32 > 10.2.0.0/16 > 20.0.0.0/8 > ... > > On the other hand the CPE probably has a table like > 0.0.0.0/0 y > 20.0.0.0/8 x > > Now assume that the CPE wants to send a packet to 10.1.1.2. > It would label it to be sent to 0.0.0.0/0. There is no > way that the operator LSR could forward this correctly. So there > is no point running a network in this configuration, unless > the CPE knows the same thousands of routes as the operator LSR, > which would imply the running of a routing protocol to the CPE. > This may well be unacceptable. > > If the Operator LSR is a frame-based LSR, then it would advertise > thousands of labels to the CPE. Assuming that the CPE has enough > memory to deal with all the labels (it's expected to deal > with thousands of labels even though it has only two routes), > then it could label the packet so that it can be forwarded > correctly by the operator LSR. > > However the operator LSR can probably deal with unlabelled IP > packets with similar performance to labelled packets (this is > true for all the frame-based LSRs with which I'm familiar). > > So, in general, there is little performance benefit to running > MPLS on the CPE. There may be other benefits. I think that depends. In the scenario you're describing it probably wouldn't make a lot of sense. But I think if you would want to use framed MPLS to replace cell ATM in an xDSL access network extending MPLS to the CPE could make sense. There the CPE isn't connected directly to the operator LSR having all the internet routes anyway. Perhaps several hundred CPEs are connected to DSLAMs and you have perhaps the LERs of several ISPs connected to the PoP. You could also have other service gateways connected to the PoP. All these ISP LERs route into the internet, i.e. to the same set of destinations. You wouldn't use MPLS on the local loop to pre-label the packets for transport through the core network but through the access network. By using different labels the customer could even choose to send different traffic to the same destination via different ISPs though he has only one physical xDSL link. I.e. I think you could use MPLS for the same purpose ATM is used in the access networks today. From owner-mpls@UU.NET Sat Jan 8 14:02:30 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20428 for ; Sat, 8 Jan 2000 14:02:29 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxdk01531; Sat, 8 Jan 2000 19:01:40 GMT Received: by mail-control.mail.uu.net id QQhxdk15830 for mpls-outgoing; Sat, 8 Jan 2000 19:01:13 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhxdk15783 for ; Sat, 8 Jan 2000 19:01:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxdk11146 for ; Sat, 8 Jan 2000 14:01:05 -0500 (EST) Received: from element.integralaccess.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: server2.integralaccess.com [38.155.16.225]) id QQhxdk15444 for ; Sat, 8 Jan 2000 19:01:04 GMT Received: from akankkunen (192.168.1.229) by element.integralaccess.com (LSMTP Lite for Windows NT v1.1a) with SMTP id <0.BFA744E0@element.integralaccess.com>; Sat, 8 Jan 2000 14:00:41 -0500 From: "Antti Kankkunen" To: "Badarinath Devalla" , "'mpls@uu.net'" , Subject: RE: Carrying Private Lines over an MPLS network Date: Sat, 8 Jan 2000 14:01:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01BF59E0.E99389D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BF59E0.E99389D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Carrying Private Lines over an MPLS networkBadari, private lines are the biggest (from revenue point of view) data service today and it is clear that they are not going away any time soon. If an operator wants to build a single infrastructure for all services, this infrastructure needs to able to support private lines. We have started some effort around defining the ways to carry voice services over MPLS infrastructure. As part of this work we are planning to work on circuit emulation over MPLS. Even though the motivation is carrying voice, the mechanisms can be used for general private lines as well. We are in the process of creating an Internet Draft that will define the architectural reference model for VoMPLS, identify the applications of VoMPLS, list the specific requirements for each application and list the requirements this sets on various call control protocols. We are attempting to reuse existing VoIP call control and minimize any impact on it. We would like to present this ID in the next IETF meeting and get consensus on commencing work on VoMPLS standardization. Also a suitable working group for this activity will need to be identified. If you are interested in following this work, we invite you to joint the mailing list “vompls@lists.integralaccess.com”. To subscribe: vompls-request@lists.integralaccess.com In body: subscribe (unsubscribe) Archive: http://sonic.sparklist.com/scripts/lyris.pl?enter=vompls Best regards, Antti K. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Badarinath Devalla Sent: Friday, January 07, 2000 6:46 PM To: 'mpls@uu.net' Cc: Badarinath Devalla Subject: Carrying Private Lines over an MPLS network Howdy ! What is the migration path for carriers using cross-connects to carry private line services (unidentified private line) when their network evolves to an MPLS-based network ? In other words, if a carrier deploys an MPLS backbone (let us say, no CSRs but routers acting as LSRs), how are the private lines (say DS1 and above rates) served ? On a related note, I was looking for drafts on MPLS VPN work and found a message from Dec 98 (MPLS list archive: http://cell.onecall.net/mhonarc/mpls/1998-Dec/msg00017.html) on draft-rosen-vpn-mpls-00.txt - are there any updates to this draft ? (Looking for tunnelling info over an MPLS network) Thanks in advance badari ----- Badari Devalla IP & ATM Network Planning Business & Network Consulting, Richardson bdevalla@nortelnetworks.com Tel: (972) 685 5174 (W), (972) 414 6453 (H) ------=_NextPart_000_0004_01BF59E0.E99389D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Carrying Private Lines over an MPLS network
Badari,
 
private lines are the biggest (from revenue = point of=20 view) data service today and it is clear that they are not going = away any=20 time soon. If an operator wants to build a single infrastructure for all = services, this infrastructure needs to able to support private=20 lines.
 
We have started some effort around = defining=20 the ways to carry voice services over MPLS infrastructure. As part of = this work=20 we are planning to work on circuit emulation over MPLS. Even though the=20 motivation is carrying voice, the mechanisms can be used for general = private=20 lines as well.

We are in the = process of=20 creating an Internet Draft that will=20 define the architectural reference model for VoMPLS, identify the = applications of VoMPLS, list the specific requirements for each = application and=20 list the requirements this sets on = various=20 call control protocols. We are attempting to reuse existing VoIP call = control=20 and minimize any impact on it.

We would like to present this ID in the next IETF meeting and get = consensus=20 on commencing work on VoMPLS standardization. Also a suitable working = group for=20 this activity will need to be identified.

If you are interested in following this = work, we invite you to joint the mailing list=20 “vompls@lists.integralaccess.com”.

To subscribe: vompls-request@li= sts.integralaccess.com
In body: subscribe = (unsubscribe)
Archive:=20 http://sonic.sparklist.com/scripts/lyris.pl?enter=3Dvompls
 
Best regards,
 
Antti K.
 
 -----Original=20 Message-----
From: owner-mpls@UU.NET = [mailto:owner-mpls@UU.NET]On=20 Behalf Of Badarinath Devalla
Sent: Friday, January 07, = 2000 6:46=20 PM
To: 'mpls@uu.net'
Cc: Badarinath=20 Devalla
Subject: Carrying Private Lines over an MPLS=20 network

Howdy !
What is=20 the migration path for carriers using cross-connects to carry private = line=20 services (unidentified private line) when their network evolves to an=20 MPLS-based network ?

In other words, if a carrier deploys an = MPLS=20 backbone (let us say, no CSRs but routers acting as LSRs), how are the = private=20 lines (say DS1 and above rates) served ?

On a related note, I was looking for = drafts on MPLS=20 VPN work and found a message from Dec 98 (MPLS list archive:=20 http://cell.onecall.net/mhonarc/mpls/1998-Dec/msg00017.ht= ml) on draft-rosen-vpn-mpls-00.txt - are there any = updates to=20 this draft ? (Looking for tunnelling info over an MPLS = network)

Thanks in advance
badari

-----

Badari = Devalla

IP & ATM Network=20 Planning

Business & Network = Consulting,=20 Richardson

bdevalla@nortelnetworks.com

Tel: (972) 685 5174 (W), = (972) 414=20 6453 (H)

------=_NextPart_000_0004_01BF59E0.E99389D0-- From owner-mpls@UU.NET Sat Jan 8 14:27:18 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20524 for ; Sat, 8 Jan 2000 14:27:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxdl14373; Sat, 8 Jan 2000 19:26:50 GMT Received: by mail-control.mail.uu.net id QQhxdl23724 for mpls-outgoing; Sat, 8 Jan 2000 19:26:27 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxdl23716 for ; Sat, 8 Jan 2000 19:26:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxdl13993 for ; Sat, 8 Jan 2000 14:26:00 -0500 (EST) Received: from ns1.arch.bellsouth.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.arch.bellsouth.net [205.152.173.2]) id QQhxdl28478 for ; Sat, 8 Jan 2000 19:25:59 GMT Received: (from ck@localhost) by ns1.arch.bellsouth.net (8.9.1a/goaway) id OAA12502; Sat, 8 Jan 2000 14:24:48 -0500 (EST) Date: Sat, 8 Jan 2000 14:24:48 -0500 From: Christian Kuhtz To: Antti Kankkunen Cc: Badarinath Devalla , "'mpls@uu.net'" , vompls@lists.integralaccess.com Subject: Re: Carrying Private Lines over an MPLS network Message-ID: <20000108142448.B11030@ns1.arch.bellsouth.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Antti Kankkunen on Sat, Jan 08, 2000 at 02:01:51PM -0500 Sender: owner-mpls@UU.NET Precedence: bulk If I may add my $.02, On Sat, Jan 08, 2000 at 02:01:51PM -0500, Antti Kankkunen wrote: > Carrying Private Lines over an MPLS networkBadari, > > private lines are the biggest (from revenue point of view) data service > today and it is clear that they are not going away any time soon. If an > operator wants to build a single infrastructure for all services, this > infrastructure needs to able to support private lines. It's also one of the most closely watched areas of telecommunications. Watched by the regulatory bodies. So, while it is most definitely feasible to throw private line on MPLS or any other transport (raw IP for that matter), another crucial piece besides delivering the SLA you *MUST* deliver, the other piece is reporting, provisioning & troubleshooting. Unless you got all those piece rock solid or you can at the very least pass a straight face test, nobody with, say, FCC reporting duty, will even dare to touch it. If you talk to people doing ATM circuit emulation, you might find quite a few people who will say that private line emulation is everything but easy. While it is certainly technically feasible, it still makes a lot of people very nervous (and, yes, I'm one of the people chuckling about it -- in no way I'm advocating soldered copper wire from a to b, I'd love to see all these things on IP. It opens a whole new world of integration, which is why we had discussions about this internally and with vendors almost 2 yrs ago). The real question, if I understand what you're going for, though, is.. What's the point of doing call control natively over MPLS, though? How will you interact with a SoftSwitch? I think this is almost beyond the scope of the IETF mpls WG, though. Cheers, Chris -- Christian Kuhtz Architecture, BellSouth.net -wk, -hm Atlanta, GA "Speaking for myself only." From owner-mpls@UU.NET Sat Jan 8 14:57:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20629 for ; Sat, 8 Jan 2000 14:57:03 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxdn29643; Sat, 8 Jan 2000 19:56:23 GMT Received: by mail-control.mail.uu.net id QQhxdn25350 for mpls-outgoing; Sat, 8 Jan 2000 19:55:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxdn25344 for ; Sat, 8 Jan 2000 19:55:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxdn15570 for ; Sat, 8 Jan 2000 14:55:38 -0500 (EST) Received: from element.integralaccess.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: server2.integralaccess.com [38.155.16.225]) id QQhxdn12952 for ; Sat, 8 Jan 2000 19:55:38 GMT Received: from akankkunen (192.168.1.229) by element.integralaccess.com (LSMTP Lite for Windows NT v1.1a) with SMTP id <0.5EE53E70@element.integralaccess.com>; Sat, 8 Jan 2000 14:55:14 -0500 From: "Antti Kankkunen" To: "Christian Kuhtz" Cc: "Badarinath Devalla" , "'mpls@uu.net'" , Subject: RE: Carrying Private Lines over an MPLS network Date: Sat, 8 Jan 2000 14:56:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20000108142448.B11030@ns1.arch.bellsouth.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Christian Kuhtz [mailto:ck@arch.bellsouth.net] > The real question, if I understand what you're going for, though, > is.. What's > the point of doing call control natively over MPLS, though? How will you > interact with a SoftSwitch? > This work is still in early stages, but at the moment at least my thinking is that call control will most of the time be carried over IP, which then may or may not be carried over MPLS. I would not be surprised if the interaction with SoftSwitch will have some similarities to the way ATM elements are interacting with Softswitch in current specifications. Best regards, Antti K. From owner-mpls@UU.NET Sat Jan 8 16:43:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02613 for ; Sat, 8 Jan 2000 16:43:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxdu06454; Sat, 8 Jan 2000 21:42:25 GMT Received: by mail-control.mail.uu.net id QQhxdu16880 for mpls-outgoing; Sat, 8 Jan 2000 21:41:58 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhxdu16871 for ; Sat, 8 Jan 2000 21:41:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxdu19946; Sat, 8 Jan 2000 16:41:41 -0500 (EST) From: money3@aichi.com Received: from chila by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: chila.pquim.unam.mx [132.248.56.14]) id QQhxdu05910; Sat, 8 Jan 2000 21:41:40 GMT Received: from 132.248.56.14 by chila via SMTP (940816.SGI.8.6.9/940406.SGI) id NAA11295; Sat, 8 Jan 2000 13:54:06 -0800 Received: from mailhost.executiv.com[alt.executiv.com[208.8.76.65]] by executiv101.com (8.8.5/8.6.5) with SMTP id GAA02454 for ; Sat, 08 Jan 2000 16:31:44 -0600 (EST) To: ezmoney6@aichi.com Message-ID: <200249362.EBY100599@executiv101.com> Date: Sat, 08 Jan 00 16:31:44 EST Subject: Re: FREE ~ MAKE AT LEAST $5000 EVERY WEEK ~ GUARANTEED! Reply-To: ezmoney6@aichi.com X-UIDL: 3447bri9h78989nnjhyrd9mkh098muht5 Comments: Authenticated sender is Sender: owner-mpls@UU.NET Precedence: bulk LEARN HOW YOU CAN MAKE AT LEAST $5000 EVERY WEEK ~ GUARANTEED! ABSOLUTELY NO SELLING ~ NOT MLM ~ NO PRODUCTS TO PURCHASE ~ NO RISK! If You're Serious About Making BIG Money, Get this Important FREE Information NOW, and start earning Your Fortune TODAY! For all of the details, just send a blank email, with "Free Secrets" in the subject box, to: nowork4u1113@bigfoot.com THIS IS YOUR CHANCE ~ TAKE IT NOW!! You are on our in-house safe list. If you would like to be removed, please just hit reply, and put Remove in the subject box, and you will be removed Immediately! Thank you. From owner-mpls@UU.NET Sat Jan 8 23:17:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10280 for ; Sat, 8 Jan 2000 23:17:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxev29070; Sun, 9 Jan 2000 04:16:29 GMT Received: by mail-control.mail.uu.net id QQhxev04033 for mpls-outgoing; Sun, 9 Jan 2000 04:15:55 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxev04025 for ; Sun, 9 Jan 2000 04:15:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxev22830 for ; Sat, 8 Jan 2000 23:15:44 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQhxev10585 for ; Sun, 9 Jan 2000 04:15:44 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id XAA04617; Sat, 8 Jan 2000 23:15:42 -0500 Date: Sat, 8 Jan 2000 23:15:42 -0500 From: "J. Noel Chiappa" Message-Id: <200001090415.XAA04617@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: RE: Reordering and MPLS? Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Bora Akyol > I would reword it to say that packet ordering should be preserved under > normal operating conditions. That sounds fine, but be careful of IETF standards terminology - if a document says 'SHOULD' that may still allow someone to try and build a switch that reorders every third packet. ("SHOULD: This word .. mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.) It needs to say something like "MUST only reorder packets rarely", or something (and no, I don't think it's appropriate to be any more specific than "rarely"). > I would like to say that striping packets through a switch without any > respect to packet order is NOT acceptable Sure, that sounds reasonable. Switches should not make a practise of reordering packets (except as explicitly called for by resource allocation mechanisms, and in those cases it will be between flows). Noel From owner-mpls@UU.NET Sat Jan 8 23:37:18 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10727 for ; Sat, 8 Jan 2000 23:37:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxew20374; Sun, 9 Jan 2000 04:36:28 GMT Received: by mail-control.mail.uu.net id QQhxew05353 for mpls-outgoing; Sun, 9 Jan 2000 04:35:59 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxew05346 for ; Sun, 9 Jan 2000 04:35:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxew09258 for ; Sat, 8 Jan 2000 23:35:46 -0500 (EST) Received: from ns1.arch.bellsouth.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.arch.bellsouth.net [205.152.173.2]) id QQhxew07786 for ; Sun, 9 Jan 2000 04:35:46 GMT Received: (from ck@localhost) by ns1.arch.bellsouth.net (8.9.1a/goaway) id XAA19846; Sat, 8 Jan 2000 23:35:35 -0500 (EST) Date: Sat, 8 Jan 2000 23:35:35 -0500 From: Christian Kuhtz To: "J. Noel Chiappa" Cc: mpls@UU.NET Subject: Re: Reordering and MPLS? Message-ID: <20000108233535.D14042@ns1.arch.bellsouth.net> References: <200001090415.XAA04617@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <200001090415.XAA04617@ginger.lcs.mit.edu>; from J. Noel Chiappa on Sat, Jan 08, 2000 at 11:15:42PM -0500 Sender: owner-mpls@UU.NET Precedence: bulk On Sat, Jan 08, 2000 at 11:15:42PM -0500, J. Noel Chiappa wrote: > > I would like to say that striping packets through a switch without any > > respect to packet order is NOT acceptable > > Sure, that sounds reasonable. Switches should not make a practise of > reordering packets (except as explicitly called for by resource allocation > mechanisms, and in those cases it will be between flows). And a flow is what exactly? Which very large scale flow based traffic engineering technique has been proven to scale with very large #s of flows? "between flows" to me implies some amount of automagic detection of flows. It sounds like you guys are suggesting that traffic engineering by means of WFQ, Priority Queue w/ WFQ, CBWFQ, etc are the exception and not the norm, or at the very least very rare.. Note: classification and scheduling are disjoint events. While it is perhaps _in theory_ desirable to not have reordering, reality is that you should never assume that it doesn't happen. In fact, certain TE mechanism will cause reordering beyond an applications control. Cheers, Chris -- Christian Kuhtz Architecture, BellSouth.net -wk, -hm Atlanta, GA "Speaking for myself only." From owner-mpls@UU.NET Sat Jan 8 23:48:38 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10836 for ; Sat, 8 Jan 2000 23:48:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxex25883; Sun, 9 Jan 2000 04:47:57 GMT Received: by mail-control.mail.uu.net id QQhxex06185 for mpls-outgoing; Sun, 9 Jan 2000 04:47:35 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxex06179 for ; Sun, 9 Jan 2000 04:47:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxex09102 for ; Sat, 8 Jan 2000 23:47:23 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQhxex25498 for ; Sun, 9 Jan 2000 04:47:23 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id XAA04981; Sat, 8 Jan 2000 23:47:22 -0500 Date: Sat, 8 Jan 2000 23:47:22 -0500 From: "J. Noel Chiappa" Message-Id: <200001090447.XAA04981@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: Reordering and MPLS? Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Christian Kuhtz >> Switches should not make a practise of reordering packets (except as >> explicitly called for by resource allocation mechanisms, and in those >> cases it will be between flows). > And a flow is what exactly? ... "between flows" to me implies some > amount of automagic detection of flows. I wasn't intending to mean anything specific by "flow", just "a stream of packets that the resource allocation treats as a group". So for "flows" in the above sentence, substitute "packets in different resource allocation groupings", or whatever similar phrase will keep you happy. Noel From owner-mpls@UU.NET Sun Jan 9 00:16:16 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10971 for ; Sun, 9 Jan 2000 00:16:16 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxey24823; Sun, 9 Jan 2000 05:11:56 GMT Received: by mail-control.mail.uu.net id QQhxey14961 for mpls-outgoing; Sun, 9 Jan 2000 05:11:35 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxey14956 for ; Sun, 9 Jan 2000 05:11:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxey10326 for ; Sun, 9 Jan 2000 00:11:31 -0500 (EST) Received: from ns1.arch.bellsouth.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.arch.bellsouth.net [205.152.173.2]) id QQhxey24368 for ; Sun, 9 Jan 2000 05:11:31 GMT Received: (from ck@localhost) by ns1.arch.bellsouth.net (8.9.1a/goaway) id AAA20451 for mpls@uu.net; Sun, 9 Jan 2000 00:11:31 -0500 (EST) Date: Sun, 9 Jan 2000 00:11:31 -0500 From: Christian Kuhtz To: mpls@UU.NET Subject: Re: Reordering and MPLS? Message-ID: <20000109001131.C20037@ns1.arch.bellsouth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Sender: owner-mpls@UU.NET Precedence: bulk On Sat, Jan 08, 2000 at 11:47:22PM -0500, J. Noel Chiappa wrote: > I wasn't intending to mean anything specific by "flow", just "a stream of > packets that the resource allocation treats as a group". So for "flows" in the > above sentence, substitute "packets in different resource allocation > groupings", or whatever similar phrase will keep you happy. Regardless of the semantics, only traffic shaping (buffering) inside a class will prevent you from reordering. If you do as much as WFQ in a class, you get reordering.. Cheers, Chris -- Christian Kuhtz Architecture, BellSouth.net -wk, -hm Atlanta, GA "Speaking for myself only." From owner-mpls@UU.NET Sun Jan 9 00:22:17 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10991 for ; Sun, 9 Jan 2000 00:22:16 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxez11172; Sun, 9 Jan 2000 05:21:17 GMT Received: by mail-control.mail.uu.net id QQhxez15738 for mpls-outgoing; Sun, 9 Jan 2000 05:20:56 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxez15725 for ; Sun, 9 Jan 2000 05:20:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxez10685 for ; Sun, 9 Jan 2000 00:20:39 -0500 (EST) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQhxez28715 for ; Sun, 9 Jan 2000 05:20:39 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id VAA17468; Sat, 8 Jan 2000 21:20:34 -0800 (PST) Message-ID: <38781A9B.7E2AF3FB@pluris.com> Date: Sat, 08 Jan 2000 21:20:27 -0800 From: Bora Akyol Organization: Pluris X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Christian Kuhtz CC: mpls@UU.NET Subject: Re: Reordering and MPLS? References: <20000109001131.C20037@ns1.arch.bellsouth.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Christian As long as you are doing WFQ between classes and the packets of the same flow belong to the same class or they use AF with different DPs, then there is no chance of reordering. And we don't care about the ordering of different flows. There are also good references for how to preserve ordering in draft-ietf-ospf-omp-xx.txt (submit latest number in place of xx). Please also review the Diffserv WG documents on this topic. Bora Akyol Pluris, http://www.pluris.com Christian Kuhtz wrote: > On Sat, Jan 08, 2000 at 11:47:22PM -0500, J. Noel Chiappa wrote: > > I wasn't intending to mean anything specific by "flow", just "a stream of > > packets that the resource allocation treats as a group". So for "flows" in the > > above sentence, substitute "packets in different resource allocation > > groupings", or whatever similar phrase will keep you happy. > > Regardless of the semantics, only traffic shaping (buffering) inside a class > will prevent you from reordering. If you do as much as WFQ in a class, you get > reordering.. > > Cheers, > Chris > > -- > Christian Kuhtz Architecture, BellSouth.net > -wk, -hm Atlanta, GA > "Speaking for myself only." From owner-mpls@UU.NET Sun Jan 9 13:39:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09622 for ; Sun, 9 Jan 2000 13:39:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxha16132; Sun, 9 Jan 2000 18:38:14 GMT Received: by mail-control.mail.uu.net id QQhxha13268 for mpls-outgoing; Sun, 9 Jan 2000 18:37:47 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxha13262 for ; Sun, 9 Jan 2000 18:37:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxha14950 for ; Sun, 9 Jan 2000 13:37:45 -0500 (EST) Received: from shultz.argon.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: shultz.argon.com [208.234.161.2]) id QQhxha00679 for ; Sun, 9 Jan 2000 18:37:45 GMT Received: from fjk (foxtrot.tunnel.argon.com [10.254.0.12]) by shultz.argon.com (8.9.3/8.9.3) with SMTP id NAA19184; Sun, 9 Jan 2000 13:37:15 -0500 (EST) Message-Id: <3.0.5.32.20000109134550.007d35c0@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 09 Jan 2000 13:45:50 -0500 To: "J. Noel Chiappa" , mpls@UU.NET From: Frank Kastenholz Subject: RE: Reordering and MPLS? Cc: jnc@ginger.lcs.mit.edu In-Reply-To: <200001090415.XAA04617@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 11:15 PM 1/8/00 -0500, J. Noel Chiappa wrote: >It needs to say something like "MUST only reorder packets rarely", or >something (and no, I don't think it's appropriate to be any more specific >than "rarely"). If it's not quantifiable, it's not a standard/specification, it's an implementation guideline. From owner-mpls@UU.NET Sun Jan 9 13:52:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09676 for ; Sun, 9 Jan 2000 13:52:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxhb07650; Sun, 9 Jan 2000 18:51:42 GMT Received: by mail-control.mail.uu.net id QQhxhb14160 for mpls-outgoing; Sun, 9 Jan 2000 18:51:20 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxhb14136 for ; Sun, 9 Jan 2000 18:51:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxhb14999 for ; Sun, 9 Jan 2000 13:51:05 -0500 (EST) Received: from pop03.globecomm.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pop03.iname.net [165.251.8.221]) id QQhxhb07170 for ; Sun, 9 Jan 2000 18:51:05 GMT Received: from wiztech (vdp018.ath03.cas.hol.gr [195.97.3.19]) by pop03.globecomm.net (8.9.3/8.9.3) with SMTP id NAA19815 for ; Sun, 9 Jan 2000 13:51:02 -0500 (EST) Reply-To: From: "Constantine Protopapas" To: Subject: MPLS and ATM Date: Sun, 9 Jan 2000 20:50:47 +0200 Message-ID: <000001bf5ad2$73620960$130361c3@hol.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit How does exactly MPLS fits in a network with ATM core? On network that has an ATM core, ATM takes care of switching and prioritising, so instead of using MPLS-enabled routers (that need quite a lot of processing power), MPOA-enabled ATM switches can be used. Constantine Protopapas Systems/Network Engineer Applied Science 62 Karpenisioti Str. GR 115 24 N. Filothei Athens GREECE tel: ++30-1-6998225 fax ++30-1-6998983 mobile: ++30-97-7598043 e-mail: applied@otenet.gr (office) wiztech@hol.gr (home) From owner-mpls@UU.NET Sun Jan 9 17:49:35 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10728 for ; Sun, 9 Jan 2000 17:49:35 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxhr28340; Sun, 9 Jan 2000 22:48:44 GMT Received: by mail-control.mail.uu.net id QQhxhr28709 for mpls-outgoing; Sun, 9 Jan 2000 22:48:24 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxhr28695 for ; Sun, 9 Jan 2000 22:48:18 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxhr04396; Sun, 9 Jan 2000 17:48:15 -0500 (EST) From: jeffallen@sourcenet.org Received: from sourcenet.org by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: host-209-214-98-110.sav.bellsouth.net [209.214.98.110]) id QQhxhr27946; Sun, 9 Jan 2000 22:48:12 GMT Subject: Good Luck in the New Millenium Date: Sun, 9 Jan 2000 17:53:56 Message-Id: <553.561879.328734@sourcenet.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk To be removed from this mailing list immediately press reply and enter REMOVE on the subject line. Would you like to be able to buy Computers and Software at wholesale? At below what the stores Pay? Reply with "MORE INFO" in the subject field If you are a reseller and would like information on paying what the distributors pay then Reply with Reseller in the subject field. If you have computer products you need to sell then email your details From owner-mpls@UU.NET Sun Jan 9 18:09:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10881 for ; Sun, 9 Jan 2000 18:09:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxhs07940; Sun, 9 Jan 2000 23:08:15 GMT Received: by mail-control.mail.uu.net id QQhxhs05866 for mpls-outgoing; Sun, 9 Jan 2000 23:07:50 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxhs05833 for ; Sun, 9 Jan 2000 23:07:49 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxhs05326 for ; Sun, 9 Jan 2000 18:07:48 -0500 (EST) Received: from mailhost.auckland.ac.nz by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.auckland.ac.nz [130.216.1.4]) id QQhxhs22329 for ; Sun, 9 Jan 2000 23:07:46 GMT Received: from staffdata.auckland.ac.nz (staffdata.business.auckland.ac.nz [130.216.97.241]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id MAA08254 for ; Mon, 10 Jan 2000 12:07:44 +1300 (NZDT) Received: by staffdata.business.auckland.ac.nz with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 12:07:24 +1300 Message-ID: From: "Surujpal, Sunil" To: mpls@UU.NET Subject: Questions Date: Mon, 10 Jan 2000 12:07:24 +1300 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, I am writing a research essay on MPLS, in particular on the signalling protocols that are being considered for use such as RSVP and LDP. I have several questions that I am would like help with. 1. In the Internet Draft draft-ietf-mpls-arch-06.txt, it says that the MPLS architecture does not assume that there is only one label distribution protocol and that several protocols are being standardized such as BGP, RSVP and new protocols being created for i.e. LDP. The majority of the material that I have looked at only discuss RSVP and to some extent LDP as the two protocols that are now being considered for this purpose. Are these two the only protocols that are being considered for standardization by the IETF and if so, why was BGP discarded? If not, can someone please direct me to material on BGP and how it is being extended to provide label distribution. 2. Can someone also please direct me to material that discusses the pros and con of the protocols that are being considered for use as the label distribution protocol for MPLS. Your help is very much appreciated. Sunil Surujpal __________________________________________________ Sunil Surujpal Course Coordinator Department of Management Science and Information Systems School of Economics and Business University of Auckland Private Bag 92019 Auckland New Zealand Phone: 64 9 3737599 x8537 Fax: 64 9 3737430 From owner-mpls@UU.NET Sun Jan 9 20:18:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11507 for ; Sun, 9 Jan 2000 20:18:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxib22895; Mon, 10 Jan 2000 01:17:37 GMT Received: by mail-control.mail.uu.net id QQhxib00729 for mpls-outgoing; Mon, 10 Jan 2000 01:17:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxib00721 for ; Mon, 10 Jan 2000 01:17:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxib01948 for ; Sun, 9 Jan 2000 20:17:01 -0500 (EST) Received: from www.netlabs.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: www.netlabs.net [216.116.128.3]) id QQhxib22460 for ; Mon, 10 Jan 2000 01:17:01 GMT Received: from blhoreckpc (arni.netlabs.net [216.116.143.247]) by www.netlabs.net (8.9.3/8.9.3) with SMTP id UAA29035; Sun, 9 Jan 2000 20:16:46 -0500 (EST) Message-ID: <108101bf5b08$b6389250$0200a8c0@blhoreckpc> From: "Arni Raghu" To: "Surujpal, Sunil" , References: Subject: Re: Questions Date: Sun, 9 Jan 2000 20:19:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, http://www.nortel-bay.com/products/announcements/mpls/source/collateral/whit epaper.html hth. Arni ----- Original Message ----- From: Surujpal, Sunil To: Sent: Sunday, January 09, 2000 6:07 PM Subject: Questions > > Hi, > > I am writing a research essay on MPLS, in particular on the signalling > protocols that are being considered for use such as RSVP and LDP. I have > several questions that I am would like help with. > 1. In the Internet Draft draft-ietf-mpls-arch-06.txt, it says that the > MPLS architecture does not assume that there is only one label distribution > protocol and that several protocols are being standardized such as BGP, RSVP > and new protocols being created for i.e. LDP. The majority of the material > that I have looked at only discuss RSVP and to some extent LDP as the two > protocols that are now being considered for this purpose. Are these two the > only protocols that are being considered for standardization by the IETF and > if so, why was BGP discarded? If not, can someone please direct me to > material on BGP and how it is being extended to provide label distribution. > 2. Can someone also please direct me to material that discusses the > pros and con of the protocols that are being considered for use as the label > distribution protocol for MPLS. > > Your help is very much appreciated. > Sunil Surujpal > > > __________________________________________________ > Sunil Surujpal > Course Coordinator > Department of Management Science and Information Systems > School of Economics and Business > University of Auckland > Private Bag 92019 > Auckland > New Zealand > Phone: 64 9 3737599 x8537 > Fax: 64 9 3737430 > > From owner-mpls@UU.NET Sun Jan 9 20:49:12 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11626 for ; Sun, 9 Jan 2000 20:49:12 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxid24859; Mon, 10 Jan 2000 01:47:39 GMT Received: by mail-control.mail.uu.net id QQhxid03384 for mpls-outgoing; Mon, 10 Jan 2000 01:47:11 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxid03378 for ; Mon, 10 Jan 2000 01:47:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxid04812 for ; Sun, 9 Jan 2000 20:46:58 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxid24371 for ; Mon, 10 Jan 2000 01:46:58 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp139-254.cisco.com [144.254.139.254]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id RAA16917; Sun, 9 Jan 2000 17:46:07 -0800 (PST) Message-Id: <4.2.2.20000110124119.00a88400@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 10 Jan 2000 12:45:26 +1100 To: "Surujpal, Sunil" From: Jeremy Lawrence Subject: Re: Questions Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Sunil, >1. In the Internet Draft draft-ietf-mpls-arch-06.txt, it says that the >MPLS architecture does not assume that there is only one label distribution >protocol and that several protocols are being standardized such as BGP, RSVP >and new protocols being created for i.e. LDP. The majority of the material >that I have looked at only discuss RSVP and to some extent LDP as the two >protocols that are now being considered for this purpose. Are these two the >only protocols that are being considered for standardization by the IETF and >if so, why was BGP discarded? If not, can someone please direct me to >material on BGP and how it is being extended to provide label distribution. The BGP stuff is very much alive and has recently gone to Working Group Last Call (the final Working Group stage before forwarding it to the IESG for consideration as a Proposed Standard). The current draft is http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp4-mpls-04.txt Jeremy Lawrence From owner-mpls@UU.NET Sun Jan 9 21:19:17 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11764 for ; Sun, 9 Jan 2000 21:19:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxif09811; Mon, 10 Jan 2000 02:18:06 GMT Received: by mail-control.mail.uu.net id QQhxif13486 for mpls-outgoing; Mon, 10 Jan 2000 02:17:46 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxif13481 for ; Mon, 10 Jan 2000 02:17:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxif14191 for ; Sun, 9 Jan 2000 21:17:27 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxif09359 for ; Mon, 10 Jan 2000 02:17:27 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp139-254.cisco.com [144.254.139.254]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id SAA19278; Sun, 9 Jan 2000 18:17:18 -0800 (PST) Message-Id: <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 10 Jan 2000 13:17:08 +1100 To: Juha Heinanen From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <14454.59252.645730.305366@lohi.eng.telia.fi> References: <4.2.2.20000108174032.00a931d0@farley.cisco.com> <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000108174032.00a931d0@farley.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Juha, At 09:29 01/08/2000 +0200, Juha Heinanen wrote: >yes, looks like we are not talking about the same thing at all. in my >model, the operator lsr would not announce any labels to the cpe lsr. >all labels that the cpe lsr would know of are those that it had got back >as responses to its own label request messages and it would send label >request messages only for those destinations that it is interested in >sending packets to, e.g., an isp lsr and an lsr of another site of the >same company. What are the semantics of the label request message? If it is a normal LDP message saying "give me a label for address prefix a.b.c.d/x", then there is a problem for which the only obvious solution is for the operator LSR to respond by announcing many labels in general, perhaps labels for all the addresses it knows. (On the other hand, if the semantics are different, there may be no such problem.) Regards, Jeremy Lawrence From owner-mpls@UU.NET Sun Jan 9 21:43:45 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12174 for ; Sun, 9 Jan 2000 21:43:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxig06119; Mon, 10 Jan 2000 02:42:19 GMT Received: by mail-control.mail.uu.net id QQhxig15373 for mpls-outgoing; Mon, 10 Jan 2000 02:41:53 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxig15368 for ; Mon, 10 Jan 2000 02:41:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxig07530 for ; Sun, 9 Jan 2000 21:41:42 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxig21815 for ; Mon, 10 Jan 2000 02:41:42 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp139-254.cisco.com [144.254.139.254]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id SAA21162; Sun, 9 Jan 2000 18:41:38 -0800 (PST) Message-Id: <4.2.2.20000110131728.00a7e720@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 10 Jan 2000 13:41:28 +1100 To: From: Jeremy Lawrence Subject: Re: MPLS and ATM Cc: In-Reply-To: <000001bf5ad2$73620960$130361c3@hol.gr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Constantine, At 20:50 01/09/2000 +0200, Constantine Protopapas wrote: >How does exactly MPLS fits in a network with ATM core? >On network that has an ATM core, ATM takes care of switching and >prioritising, so instead of using MPLS-enabled routers (that need quite a >lot of processing power), MPOA-enabled ATM switches can be used. There are, broadly, two modes of relationship between MPLS and ATM: In ATM MPLS, IP routing (OSPF, IS-IS, etc.) and MPLS act as a connection control system for a (typically) AALx-compliant ATM fabric. ATM is still taking care of switching and prioritizing, but IP routing and MPLS are routing and signalling the ATM connections. (IP routing and MPLS may do this either instead of, or in parallel with, an (S)PVC/SVC routing system like PNNI.) An ATM switch with an IP routing/MPLS control system is referred to as an ATM Label Switch Router (ATM-LSR). MPLS can also be tunneled through non-MPLS capable ATM switches, either using (S)PVCs (which act much like any other point-to-point link between MPLS-capable routers), or (S)PVPs. If (S)PVPs are used, then they form ATM virtual trunks which can be used to link ATM edge LSRs (ATM MPLS-capable routers) and/or ATM-LSRs. MPOA and MPLS are different solutions which are not closely related to each other. MPOA is intended largely for LAN/MAN applications, i.e. linking hosts to each other, and linking hosts to routers. MPLS, on the other hand, is designed for applications involving the use of many routers, typically in WANs. Hope this helps, Jeremy Lawrence From owner-mpls@UU.NET Mon Jan 10 02:05:57 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26005 for ; Mon, 10 Jan 2000 02:05:57 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxiy06356; Mon, 10 Jan 2000 07:03:34 GMT Received: by mail-control.mail.uu.net id QQhxiy05379 for mpls-outgoing; Mon, 10 Jan 2000 07:02:51 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxiy05317 for ; Mon, 10 Jan 2000 07:02:47 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxiy00671 for ; Mon, 10 Jan 2000 02:02:45 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQhxiy18732 for ; Mon, 10 Jan 2000 07:02:44 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id JAA06695; Mon, 10 Jan 2000 09:02:35 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14457.33803.150184.540713@lohi.eng.telia.fi> Date: Mon, 10 Jan 2000 09:02:35 +0200 (EET) To: Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber In-Reply-To: <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> References: <4.2.2.20000108174032.00a931d0@farley.cisco.com> <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeremy Lawrence writes: > What are the semantics of the label request message? If it is > a normal LDP message saying "give me a label for address > prefix a.b.c.d/x", then there is a problem for which the only > obvious solution is for the operator LSR to respond by announcing > many labels in general, perhaps labels for all the addresses it > knows. yes, the cpe router asks for a label for a single address a.b.c.d/32 which is the address the the peer router (e.g. isp or corporate) to which it wants to setup an lsp and gets back a single label. the operator lsp never advertises any labels to the cpe router that the cpe router has not been asked for. -- juha From owner-mpls@UU.NET Mon Jan 10 03:18:00 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27729 for ; Mon, 10 Jan 2000 03:18:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxjd00418; Mon, 10 Jan 2000 08:16:35 GMT Received: by mail-control.mail.uu.net id QQhxjd18629 for mpls-outgoing; Mon, 10 Jan 2000 08:15:56 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxjd18548 for ; Mon, 10 Jan 2000 08:15:48 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxjd07111 for ; Mon, 10 Jan 2000 03:15:27 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxjd29752 for ; Mon, 10 Jan 2000 08:15:27 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id AAA12843; Mon, 10 Jan 2000 00:14:51 -0800 (PST) Message-Id: <4.2.2.20000110190615.00a8c3b0@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 10 Jan 2000 19:14:41 +1100 To: Juha Heinanen From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <14457.33803.150184.540713@lohi.eng.telia.fi> References: <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> <4.2.2.20000108174032.00a931d0@farley.cisco.com> <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Juha, At 09:02 01/10/2000 +0200, Juha Heinanen wrote: >Jeremy Lawrence writes: > > > What are the semantics of the label request message? If it is > > a normal LDP message saying "give me a label for address > > prefix a.b.c.d/x", then there is a problem for which the only > > obvious solution is for the operator LSR to respond by announcing > > many labels in general, perhaps labels for all the addresses it > > knows. > >yes, the cpe router asks for a label for a single address a.b.c.d/32 >which is the address the the peer router (e.g. isp or corporate) to >which it wants to setup an lsp and gets back a single label. the >operator lsp never advertises any labels to the cpe router that the cpe >router has not been asked for. That will work if and only if the operator LSR knows a route for a.b.c.d/32 specifically, and not just a less specific route like a.b.0.0/16. Otherwise, there are problems, and the current LDP spec prohibits issuing a binding. One clarification: in the other case you mentioned, which was where the CPE is getting access to/through a specific ISP, are you assuming that it also needs a label for a /32 only? Regards, Jeremy Lawrence From owner-mpls@UU.NET Mon Jan 10 03:36:45 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27846 for ; Mon, 10 Jan 2000 03:36:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxje26372; Mon, 10 Jan 2000 08:35:18 GMT Received: by mail-control.mail.uu.net id QQhxje22640 for mpls-outgoing; Mon, 10 Jan 2000 08:34:45 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxje22623 for ; Mon, 10 Jan 2000 08:34:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxje08057 for ; Mon, 10 Jan 2000 03:34:26 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQhxje08621 for ; Mon, 10 Jan 2000 08:34:24 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id KAA06977; Mon, 10 Jan 2000 10:34:17 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14457.39304.958783.611329@lohi.eng.telia.fi> Date: Mon, 10 Jan 2000 10:34:16 +0200 (EET) To: Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber In-Reply-To: <4.2.2.20000110190615.00a8c3b0@farley.cisco.com> References: <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> <4.2.2.20000108174032.00a931d0@farley.cisco.com> <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000110190615.00a8c3b0@farley.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeremy Lawrence writes: > That will work if and only if the operator LSR knows a route for > a.b.c.d/32 specifically, and not just a less specific route like > a.b.0.0/16. Otherwise, there are problems, and the current LDP spec > prohibits issuing a binding. i sent a message about this a month ago, but there was no discussion. the question was, how should an lsr advertise its interfaces (or cpe lsrs behind those interfaces). one obvious (but not good) solution is to advertise a host route for each interface separately. a better solution would be to advertise a single prefix, for example a /28 one, if the lsr has a maximum of 16 interfaces, where the interface would then be selected locally using the last 4 bits of the prefix. i'm not an ldp expert, but if you say that only the host route solution would be consistent with the current ldp spec, then there is something seriously wrong with the spec. > One clarification: in the other case you mentioned, which was where > the CPE is getting access to/through a specific ISP, are you assuming > that it also needs a label for a /32 only? yes, juha From owner-mpls@UU.NET Mon Jan 10 07:19:15 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29887 for ; Mon, 10 Jan 2000 07:19:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxjt27928; Mon, 10 Jan 2000 12:17:47 GMT Received: by mail-control.mail.uu.net id QQhxjt06255 for mpls-outgoing; Mon, 10 Jan 2000 12:17:07 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxjt06200 for ; Mon, 10 Jan 2000 12:17:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxjt18791 for ; Mon, 10 Jan 2000 07:16:55 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxjt27340 for ; Mon, 10 Jan 2000 12:16:55 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id EAA23531; Mon, 10 Jan 2000 04:16:19 -0800 (PST) Message-Id: <4.2.2.20000110222653.00a91b20@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 10 Jan 2000 23:15:43 +1100 To: Juha Heinanen From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <14457.39304.958783.611329@lohi.eng.telia.fi> References: <4.2.2.20000110190615.00a8c3b0@farley.cisco.com> <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> <4.2.2.20000108174032.00a931d0@farley.cisco.com> <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000110190615.00a8c3b0@farley.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Juha, At 10:34 01/10/2000 +0200, Juha Heinanen wrote: >Jeremy Lawrence writes: > > > That will work if and only if the operator LSR knows a route for > > a.b.c.d/32 specifically, and not just a less specific route like > > a.b.0.0/16. Otherwise, there are problems, and the current LDP spec > > prohibits issuing a binding. > >i sent a message about this a month ago, but there was no discussion. >the question was, how should an lsr advertise its interfaces (or cpe >lsrs behind those interfaces). one obvious (but not good) solution is >to advertise a host route for each interface separately. a better >solution would be to advertise a single prefix, for example a /28 one, >if the lsr has a maximum of 16 interfaces, where the interface would >then be selected locally using the last 4 bits of the prefix. > >i'm not an ldp expert, but if you say that only the host route solution >would be consistent with the current ldp spec, then there is something >seriously wrong with the spec. That's not necessarily the case. It could be argued that to change the LDP spec on this issue would be to change the MPLS architecture. The current situation was a generally agreed solution to a messy problem. In short, things get extremely complicated when two adjacent LSRs don't run a routing protocol between each other, and hence have different granularities of routing knowledge (My previous example of routing tables was getting at some of the issues; there are others.) There was no consensus on a number of issues related to this, but consensus was reached to assume that adjacent LSRs either do run a routing protocol between each other, or otherwise have exactly corresponding routing knowledge for the addresses of interest. This resulted in two restrictions in the LDP spec: - For Label Request Message processing, which occurs in Downstream on demand mode: "Unless its routing table includes an entry that exactly matches the requested Prefix or Host Address, the LSR must respond with a No Route Notification message." [draft-ietf-mpls-ldp-06.txt, 3.5.8.1] - For Label mapping Message processing: "An LSR receiving a Label Mapping message from a downstream LSR for a Prefix or Host Address FEC Element should not use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element. [draft-ietf-mpls-ldp-06.txt, 3.5.7.1] It is might possible to change LDP to remove this assumption, but this would involve a lot of work and debate, on both LDP itself, and on the architectural issues. LDP is currently designed to work in close conjunction with a routing protocol. Regards, Jeremy Lawrence From owner-mpls@UU.NET Mon Jan 10 07:28:34 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00163 for ; Mon, 10 Jan 2000 07:28:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxjt19704; Mon, 10 Jan 2000 12:27:25 GMT Received: by mail-control.mail.uu.net id QQhxjt07675 for mpls-outgoing; Mon, 10 Jan 2000 12:26:49 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxjt07666 for ; Mon, 10 Jan 2000 12:26:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxjt19341 for ; Mon, 10 Jan 2000 07:26:25 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQhxjt02612 for ; Mon, 10 Jan 2000 12:26:24 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id OAA07928; Mon, 10 Jan 2000 14:26:15 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14457.53223.113348.696513@lohi.eng.telia.fi> Date: Mon, 10 Jan 2000 14:26:15 +0200 (EET) To: Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber In-Reply-To: <4.2.2.20000110222653.00a91b20@farley.cisco.com> References: <4.2.2.20000110190615.00a8c3b0@farley.cisco.com> <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> <4.2.2.20000108174032.00a931d0@farley.cisco.com> <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000110222653.00a91b20@farley.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeremy Lawrence writes: > It is might possible to change LDP to remove this assumption, but > this would involve a lot of work and debate, on both LDP itself, > and on the architectural issues. LDP is currently designed to > work in close conjunction with a routing protocol. ok, in that case an lsr that wishes to terminate label requests to itself, needs to advertise its ip address(es) as /32 routes. i assume that an actual routing protocol is not needed, but that the advertisement can be staticly configured. regarding the architectural issues, if a network is only interested to run ldp in downstream on demand/ordered control mode, then it is not clear to me what the architectural and prototol problems would be that would prevent an lsr from forwarding a label request based on longest match. -- juha From owner-mpls@UU.NET Mon Jan 10 09:35:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04661 for ; Mon, 10 Jan 2000 09:35:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxkc25466; Mon, 10 Jan 2000 14:32:12 GMT Received: by mail-control.mail.uu.net id QQhxkc01862 for mpls-outgoing; Mon, 10 Jan 2000 14:31:37 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxkc01847 for ; Mon, 10 Jan 2000 14:31:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxkc20366 for ; Mon, 10 Jan 2000 09:31:17 -0500 (EST) Received: from hq_nt1.netreference.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.netreference.com [206.181.70.90]) id QQhxkc09316 for ; Mon, 10 Jan 2000 14:31:17 GMT Received: by mail.netreference.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 09:35:37 -0500 Message-ID: <511FDE2316C5D211890E00A0C997507524E2CB@mail.netreference.com> From: Irwin Lazar To: "'mpls@uu.net'" Subject: New MPLS related web site Date: Mon, 10 Jan 2000 09:35:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello, I'm in the process of building an MPLS related web site at http://www.mplsforum.com/ The site will provide information related to the design, deployment and management of MPLS networks. If anyone is interested in helping put together an MPLS FAQ please contact me at ilazar@cais.com . Thanks, Irwin From owner-mpls@UU.NET Mon Jan 10 09:37:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04701 for ; Mon, 10 Jan 2000 09:37:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxkc11139; Mon, 10 Jan 2000 14:34:13 GMT Received: by mail-control.mail.uu.net id QQhxkc02067 for mpls-outgoing; Mon, 10 Jan 2000 14:33:37 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxkc02054 for ; Mon, 10 Jan 2000 14:33:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxkc20536 for ; Mon, 10 Jan 2000 09:33:19 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQhxkc10459 for ; Mon, 10 Jan 2000 14:33:18 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Mon, 10 Jan 2000 08:31:01 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 08:30:51 -0600 Message-ID: <6DDA62170439D31185750000F80826AC01214750@zmerd004.ca.nortel.com> From: "David Allan" To: Juha Heinanen , Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Date: Mon, 10 Jan 2000 08:30:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5B77.4A8B0E6A" 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_01BF5B77.4A8B0E6A Content-Type: text/plain Juha, Jeremy: It strikes me that a default route has utility whereby the the provider router has to perform classification on best effort upstream traffic. Otherwise the number of "downstream on demand" label requests would just about double the amount of traffic. Where I would see MPLS to the prem having utility would be for specific QoS or CoS LSPs to be dynamically set up where the default path and latency (due to extra classification step) would not be adequate. At least for multimedia, pushing classification into the customer gear for voice and other "lots of little packet" services would have advantages. It strikes me that it does not scale to the general traffic case. So I don't want to ask for /32s, I want a /0 best effort, and then ask for /32s or whatever when I need somthing extra or somthing non-IP in the payload. Cheers Dave > -----Original Message----- > From: Juha Heinanen [SMTP:jh@lohi.eng.telia.fi] > Sent: Monday, January 10, 2000 7:26 AM > To: Jeremy Lawrence > Cc: mpls@UU.NET; vompls@lists.integralaccess.com > Subject: RE: prime time MPLS/fiber > > Jeremy Lawrence writes: > > > It is might possible to change LDP to remove this assumption, but > > this would involve a lot of work and debate, on both LDP itself, > > and on the architectural issues. LDP is currently designed to > > work in close conjunction with a routing protocol. > > ok, in that case an lsr that wishes to terminate label requests to > itself, needs to advertise its ip address(es) as /32 routes. i assume > that an actual routing protocol is not needed, but that the advertisement > can be staticly configured. > > regarding the architectural issues, if a network is only interested to > run ldp in downstream on demand/ordered control mode, then it is not > clear to me what the architectural and prototol problems would be that > would prevent an lsr from forwarding a label request based on longest > match. > > -- juha ------_=_NextPart_001_01BF5B77.4A8B0E6A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: prime time MPLS/fiber

Juha, Jeremy:

It strikes me that a = default route has utility whereby the the provider router has to = perform classification on best effort upstream traffic. Otherwise the = number of "downstream on demand" label requests would just = about double the amount of traffic. Where I would see MPLS to the prem = having utility would be for specific QoS or CoS LSPs to be dynamically = set up where the default path and latency (due to extra classification = step) would not be adequate. At least for multimedia, pushing = classification into the customer gear for voice and other "lots of = little packet" services would have advantages. It strikes me that = it does not scale to the general traffic case.

So I don't want to = ask for /32s, I want a /0 best effort, and then ask for /32s or = whatever when I need somthing extra or somthing non-IP in the = payload.

Cheers
Dave

    -----Original Message-----
    From:   Juha Heinanen = [SMTP:jh@lohi.eng.telia.fi]
    Sent:   Monday, January 10, 2000 7:26 AM
    To:     Jeremy Lawrence
    Cc:     mpls@UU.NET; vompls@lists.integralaccess.com
    Subject:       = RE: prime time MPLS/fiber

    Jeremy Lawrence writes:

     > It is might possible to = change LDP to remove this assumption, but
     > this would involve a lot = of work and debate, on both LDP itself,
     > and on the architectural = issues. LDP is currently designed to
     > work in close conjunction = with a routing protocol.

    ok, in that case an lsr that wishes to = terminate label requests to
    itself, needs to advertise its ip = address(es) as /32 routes.  i assume
    that an actual routing protocol is = not needed, but that the advertisement
    can be staticly configured.

    regarding the architectural issues, if = a network is only interested to
    run ldp in downstream on = demand/ordered control mode, then it is not
    clear to me what the architectural = and prototol problems would be that
    would prevent an lsr from forwarding = a label request based on longest
    match.

    -- juha

------_=_NextPart_001_01BF5B77.4A8B0E6A-- From owner-mpls@UU.NET Mon Jan 10 09:48:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04993 for ; Mon, 10 Jan 2000 09:48:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxkd18832; Mon, 10 Jan 2000 14:46:19 GMT Received: by mail-control.mail.uu.net id QQhxkd02870 for mpls-outgoing; Mon, 10 Jan 2000 14:45:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxkd02864 for ; Mon, 10 Jan 2000 14:45:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxkd29308 for ; Mon, 10 Jan 2000 09:45:56 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQhxkd04051 for ; Mon, 10 Jan 2000 14:45:55 GMT Received: by smtp2.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 14:45:47 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FE74@monk.datcon.co.uk> From: Adrian Farrel To: "Surujpal, Sunil" , mpls@UU.NET Subject: RE: Questions Date: Mon, 10 Jan 2000 14:45:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Sunil, Good timing! Data Connection plans to publish a White Paper early next week entitled "MPLS Traffic Engineering - A Choice of Signaling Protocols". This is essentially a comparison of CR-LDP and RSVP. Look out for it on our web site at http://www.datcon.co.uk/ Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Surujpal, Sunil [mailto:s.surujpal@auckland.ac.nz] >Sent: Sunday, January 09, 2000 11:07 PM >To: mpls@UU.NET >Subject: Questions > >I am writing a research essay on MPLS, in particular on the >signalling protocols that are being considered for use such >as RSVP and LDP. I have several questions that I am would >like help with. [SNIP] >2. Can someone also please direct me to material that >discusses the pros and con of the protocols that are being >considered for use as the label distribution protocol for >MPLS. From owner-mpls@UU.NET Mon Jan 10 10:32:41 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06115 for ; Mon, 10 Jan 2000 10:32:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxkf14638; Mon, 10 Jan 2000 15:29:41 GMT Received: by mail-control.mail.uu.net id QQhxkf13581 for mpls-outgoing; Mon, 10 Jan 2000 15:29:19 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxkf13576 for ; Mon, 10 Jan 2000 15:29:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxkf24237 for ; Mon, 10 Jan 2000 10:29:11 -0500 (EST) Received: from metconnect.ixc-comm.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ixcfw1.ixc-comm.com [38.244.111.5]) id QQhxkf14124 for ; Mon, 10 Jan 2000 15:29:11 GMT Received: by metconnect.ixc-comm.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 09:25:34 -0600 Message-ID: From: "Johnson, Robert (Broadwing)" To: "'Jeremy Lawrence'" Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Date: Mon, 10 Jan 2000 09:29:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jeremy, I would refer you to the short discussion thread on Private Line over MPLS. I am also looking into Voice over MPLS. Both of these applications require additional services which MPLS does not provide today (i.e. guaranteed ordered packet delivery). Therefore, I suppose that we are talking about additional adaptation layers to provide the facilities necessary to deliver these services over an MPLS infrastructure. Without going into detail, I think that you can see the problems that might occur if this isn't made abundantly clear up-front. Robert Johnson -----Original Message----- From: Jeremy Lawrence [mailto:jlawrenc@cisco.com] Sent: Wednesday, January 05, 2000 9:25 PM To: Johnson, Robert (Broadwing) Cc: mpls@UU.NET; vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Robert, >I apologize for not clarifying, but I was implying the inclusion of those >services that are not suitable for use over a pure, connectionless packet >network. There has been some discussion of using MPLS to provide >connection-oriented services, some of which are not designed to survive the >rigors of a connectionless packet network. If MPLS were to be utilized as a >transport protocol for customer access, it would need to be capable of >supporting these types of services. In other words, it needs to guarantee >ordered packet delivery or it should be not be used for these services. What services? Unless I've missed something, no-one has stated a problem for which it was argued that the best solution is modifying MPLS to ensure in-order packet delivery. If the problem is "carrying voice over MPLS", then guaranteed in-order delivery clearly isn't required. A suitable transport in a voice codec can simply discard out-of-sequence packets, and any vaguely adequate codec can gracefully deal with an occasional dropped packet. If the problem is "using my equipment with an extremely poor/old voice codec over an MPLS network", then the best solution seems to be: - Update the equipment to use an adequate codec (packetized 64kb/s PCM with an appropriate transport could be adequate, for example) - In the meantime, use ATM circuit emulation. All ATM-LSRs which I know about can simultaneously support circuit emulation services over PVCs, on the same links and switches that constitute the MPLS network backbone. If the problem is something else, then what is it? Regards, Jeremy Lawrence From owner-mpls@UU.NET Mon Jan 10 11:26:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07036 for ; Mon, 10 Jan 2000 11:26:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxkj20704; Mon, 10 Jan 2000 16:26:02 GMT Received: by mail-control.mail.uu.net id QQhxkj26819 for mpls-outgoing; Mon, 10 Jan 2000 16:25:40 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxkj26813 for ; Mon, 10 Jan 2000 16:25:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxkj10730 for ; Mon, 10 Jan 2000 11:25:30 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQhxkj07563 for ; Mon, 10 Jan 2000 16:25:29 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 16:25:20 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E10E1BB@monk.datcon.co.uk> From: Andy Baker To: "MPLS Mailing List (E-mail)" Subject: Uni-directional Labels with Labels-RSVP over ATM Date: Mon, 10 Jan 2000 16:25:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk ATM hardware only typically only supports uni-directional labels, such that when a label (A) is allocated for an upstream connection over a link, and connected through to a second label (B) received over a downstream link, establishing a data path from upstream through to the downstream link, then the reverse direction is also set up. This means that a bi-directional signalling protocol such as RSVP MUST not allow the upstream machine to then assign the use of label A for a different LSP downstream. Typically this may be solved in several ways: 1. careful configuration of the range of labels which each box may allocate labels from 2. dynamic determination or negotiation of the range of labels a box may use (e.g. boxes using LDP compare their identifiers, and the box with the lesser id only allocates even labels, that with the larger, odd labels 3. luck - try a label and if refused, try another one I have not seen any attempt to address this for Labels - RSVP. What are people's thoughts? Andy -- Andy Baker mailto:ab@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Mon Jan 10 12:44:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09047 for ; Mon, 10 Jan 2000 12:44:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxko10782; Mon, 10 Jan 2000 17:44:04 GMT Received: by mail-control.mail.uu.net id QQhxko10800 for mpls-outgoing; Mon, 10 Jan 2000 17:43:41 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxko10785 for ; Mon, 10 Jan 2000 17:43:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxko19865 for ; Mon, 10 Jan 2000 12:43:30 -0500 (EST) Received: from kickme.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kickme.cisco.com [198.92.30.42]) id QQhxko26369 for ; Mon, 10 Jan 2000 17:43:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA24738; Mon, 10 Jan 2000 09:36:50 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA09073; Mon, 10 Jan 2000 12:43:19 -0500 (EST) Message-Id: <200001101743.MAA09073@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: "Ballou, Ken" cc: mpls@UU.NET Subject: Re: Confusion about terminology in draft-ietf-mpls-atm-02.txt In-reply-to: Your message of Fri, 07 Jan 2000 14:43:48 -0500. <496A8683261CD211BF6C0008C733261A19C5EB@email.quarrytech.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.5 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Jan 2000 12:43:18 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Let me try to clarify. Ken> Question 1: Ken> In section 3, the following definition is given for an ATM-LSR: An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards cells between these interfaces using labels carried in the VCI or VPI/VCI field. Ken> Since the definition of "LC-ATM interface" specifies explicitly that Ken> the "top label is inferred either from the contents of the VCI field or Ken> the combined contents of the VPI and VCI fields," would it be correct Ken> to state that the clause "which forwards cells ..." in the definition Ken> of an ATM-LSR is redundant? That is, simply containing at least one Ken> LC-ATM interface makes an LSR be an ATM-LSR? (I'm not trying to be Ken> uselessly pedantic here. This is one cause of my confusion later.) An LSR which receives cells on an LC-ATM interface might do one of two things: 1. For each cell it receives, it forwards that cell out another LC-ATM interface, replacing the VPI/VCI field. 2. It reassembles a set of cells into a full frame, then decides how to forward that frame, perhaps based (wholly or partially) on the incoming VPI/VCI value which the cells carried. If it does 1, it is functioning as an ATM-LSR. If it does 2, it is functioning as a frame-based LSR. Note that 2 is compatible with the outgoing interface being an LC-ATM interface as well. In this case, the frame gets reassembled when it arrives, and then gets segmented before it is transimtted. Ken> Question 2: Ken> A frame-based LSR is defined as "a LSR which forwards complete frames Ken> between its interfaces." My interpretation of "forwards complete Ken> frames" is The intended interpretation is that the entire frame is present before it is transmitted. Whether the frame is interspersed with others on the outgoing interface doesn't matter. Ken> Does the definition of frame-based LSR require that complete frames Ken> appear on both the ingress and the egress interface? (That's how I Ken> interpret it.) Or does it mean that there is a complete frame on _at Ken> least one_ interface? Neither. A host which is connected to two ATM switches could be a frame-based LSR, if each of the ATM switches is functioning as an ATM-LSR. Ken> I could word this question another way. Here's a router with three Ken> interfaces: Ken> gigabit +--------+ ATM OC-12 Ken> ethernet | +------------- Ken> ------------+ | Ken> | +------------- Ken> +--------+ ATM OC-12 Ken> Assume that the two ATM OC-12 interfaces are LC-ATM interfaces. Does Ken> this router then meet the definition of "frame-based LSR"? If this router is not an ATM switch, but an ATM endsystem, then it is a frame-based LSR. This is probably the case you are thinking of. In this case, the router can certainly be an Edge LSR. If this router is an ATM switch with a gigabit ethernet interface (perhaps a somewhat unusual configuration), then it might well be that it functions as a frame-based LSR when forwarding between the ethernet and the ATM interfaces, but as an ATM-LSR when forwarding between the two ATM interfaces. Ken> Question 3: Ken> The Edge Set of an ATM-LSR domain is defined as "the set of frame-based Ken> LSRs which are connected to members of the domain by LC-ATM Ken> interfaces." Since at ATM-LSR domain is defined as "a set of ATM-LSRs Ken> which are mutually interconnected by LC-ATM interfaces," I conclude Ken> that the "Edge LSRs," which are the members of the Edge Set, are also Ken> members of the ATM-LSR domain. Since an LSR can have an LC-ATM interface without being an ATM-LSR, your conclusion is a non-sequitur. From owner-mpls@UU.NET Mon Jan 10 13:36:10 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10122 for ; Mon, 10 Jan 2000 13:36:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxks20378; Mon, 10 Jan 2000 18:36:07 GMT Received: by mail-control.mail.uu.net id QQhxks22153 for mpls-outgoing; Mon, 10 Jan 2000 18:35:41 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxks22145 for ; Mon, 10 Jan 2000 18:35:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxks28173 for ; Mon, 10 Jan 2000 13:35:26 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhxks19768 for ; Mon, 10 Jan 2000 18:35:24 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Mon, 10 Jan 2000 13:34:58 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CD86@email.quarrytech.com> From: "Ballou, Ken" To: erosen@cisco.com, jlawrence@cisco.com Cc: mpls@UU.NET Subject: RE: Confusion about terminology in draft-ietf-mpls-atm-02.txt Date: Mon, 10 Jan 2000 13:34:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk OK, I think I understand. (Thanks also to Jeremy Lawrence for his clarification.) Might I suggest that the definition of "ATM-LSR" needs to be more restrictive? As I read the definition, it does not preclude reassembling the incoming cells into a complete frame and then deciding how to forward the frame (scenario 2 Eric describes). Perhaps changing the wording to "forwards cells between these interfaces without first reassembling the frame using only labels carried ..." would make the definition clearer? I believe this is the distinction between scenarios 1 and 2. I think this also makes clear that an edge LSR is not a member of an ATM-LSR domain, since it is spelled out that just having an LC-ATM interface does not automatically imply being an ATM-LSR. - Ken -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Monday, January 10, 2000 12:43 PM To: Ballou, Ken Cc: mpls@UU.NET Subject: Re: Confusion about terminology in draft-ietf-mpls-atm-02.txt Let me try to clarify. Ken> Question 1: Ken> In section 3, the following definition is given for an ATM-LSR: An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards cells between these interfaces using labels carried in the VCI or VPI/VCI field. Ken> Since the definition of "LC-ATM interface" specifies explicitly that Ken> the "top label is inferred either from the contents of the VCI field or Ken> the combined contents of the VPI and VCI fields," would it be correct Ken> to state that the clause "which forwards cells ..." in the definition Ken> of an ATM-LSR is redundant? That is, simply containing at least one Ken> LC-ATM interface makes an LSR be an ATM-LSR? (I'm not trying to be Ken> uselessly pedantic here. This is one cause of my confusion later.) An LSR which receives cells on an LC-ATM interface might do one of two things: 1. For each cell it receives, it forwards that cell out another LC-ATM interface, replacing the VPI/VCI field. 2. It reassembles a set of cells into a full frame, then decides how to forward that frame, perhaps based (wholly or partially) on the incoming VPI/VCI value which the cells carried. If it does 1, it is functioning as an ATM-LSR. If it does 2, it is functioning as a frame-based LSR. Note that 2 is compatible with the outgoing interface being an LC-ATM interface as well. In this case, the frame gets reassembled when it arrives, and then gets segmented before it is transimtted. Ken> Question 2: Ken> A frame-based LSR is defined as "a LSR which forwards complete frames Ken> between its interfaces." My interpretation of "forwards complete Ken> frames" is The intended interpretation is that the entire frame is present before it is transmitted. Whether the frame is interspersed with others on the outgoing interface doesn't matter. Ken> Does the definition of frame-based LSR require that complete frames Ken> appear on both the ingress and the egress interface? (That's how I Ken> interpret it.) Or does it mean that there is a complete frame on _at Ken> least one_ interface? Neither. A host which is connected to two ATM switches could be a frame-based LSR, if each of the ATM switches is functioning as an ATM-LSR. Ken> I could word this question another way. Here's a router with three Ken> interfaces: Ken> gigabit +--------+ ATM OC-12 Ken> ethernet | +------------- Ken> ------------+ | Ken> | +------------- Ken> +--------+ ATM OC-12 Ken> Assume that the two ATM OC-12 interfaces are LC-ATM interfaces. Does Ken> this router then meet the definition of "frame-based LSR"? If this router is not an ATM switch, but an ATM endsystem, then it is a frame-based LSR. This is probably the case you are thinking of. In this case, the router can certainly be an Edge LSR. If this router is an ATM switch with a gigabit ethernet interface (perhaps a somewhat unusual configuration), then it might well be that it functions as a frame-based LSR when forwarding between the ethernet and the ATM interfaces, but as an ATM-LSR when forwarding between the two ATM interfaces. Ken> Question 3: Ken> The Edge Set of an ATM-LSR domain is defined as "the set of frame-based Ken> LSRs which are connected to members of the domain by LC-ATM Ken> interfaces." Since at ATM-LSR domain is defined as "a set of ATM-LSRs Ken> which are mutually interconnected by LC-ATM interfaces," I conclude Ken> that the "Edge LSRs," which are the members of the Edge Set, are also Ken> members of the ATM-LSR domain. Since an LSR can have an LC-ATM interface without being an ATM-LSR, your conclusion is a non-sequitur. From owner-mpls@UU.NET Mon Jan 10 13:45:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10281 for ; Mon, 10 Jan 2000 13:44:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxks14154; Mon, 10 Jan 2000 18:44:54 GMT Received: by mail-control.mail.uu.net id QQhxks22650 for mpls-outgoing; Mon, 10 Jan 2000 18:44:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxks22645 for ; Mon, 10 Jan 2000 18:44:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxks18173 for ; Mon, 10 Jan 2000 13:44:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhxks13423 for ; Mon, 10 Jan 2000 18:44:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Jan 10 13:43:04 EST 2000 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.20.90]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA16970; Mon, 10 Jan 2000 13:42:57 -0500 (EST) Message-ID: <387A28B0.2E06BA5D@dnrc.bell-labs.com> Date: Mon, 10 Jan 2000 10:45:04 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Ballou, Ken" CC: mpls@UU.NET Subject: Re: Confusion about terminology in draft-ietf-mpls-atm-02.txt References: <496A8683261CD211BF6C0008C733261A48CD86@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Ballou, Ken" wrote: [..] > Might I suggest that the definition of "ATM-LSR" needs to be more > restrictive? As I read the definition, it does not preclude reassembling > the incoming cells into a complete frame and then deciding how to forward > the frame (scenario 2 Eric describes). Perhaps changing the wording to > "forwards cells between these interfaces without first reassembling the > frame using only labels carried ..." would make the definition clearer? I > believe this is the distinction between scenarios 1 and 2. I dont see the need for any more wordage. The ATM-LSR definition talks about forwarding cells, and Eric's scenario 2 refers to forwarding frames. Remember, the definition is based on what the LSR does internally, not the format in which the blobs of MPLS data arrive and leave over external interfaces. cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research Silicon Valley From owner-mpls@UU.NET Mon Jan 10 13:52:56 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10398 for ; Mon, 10 Jan 2000 13:52:56 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxkt02221; Mon, 10 Jan 2000 18:52:55 GMT Received: by mail-control.mail.uu.net id QQhxkt23393 for mpls-outgoing; Mon, 10 Jan 2000 18:52:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxkt23342 for ; Mon, 10 Jan 2000 18:52:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxkt19399 for ; Mon, 10 Jan 2000 13:52:00 -0500 (EST) Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQhxkt19681 for ; Mon, 10 Jan 2000 18:52:00 GMT Received: (from news@localhost) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) id NAA21785; Mon, 10 Jan 2000 13:51:55 -0500 X-Authentication-Warning: rolls.laurelnetworks.com: news set sender to using -f Received: from news.laurelnetworks.com (by news@localhost) with news2mail (1.0/laurel.bww) id test/34 for test@laurelnetworks.com laurel@laurelnetworks.com hardware@laurelnetworks.com software@laurelnetworks.com mpls@laurelnetworks.com; Mon, 10 Jan 2000 13:51:55 -0500 From: Bradley White X-Newsgroups: test Subject: via news Date: 10 Jan 2000 13:51:54 -0500 Organization: Laurel Networks, Inc. Message-ID: <85d9oa$tea$1@beetle.laurelnetworks.com> To: test@laurelnetworks.com.laurel@laurelnetworks.com.hardware@laurelnetworks.com.software@laurelnetworks.com.mpls@laurelnetworks.com Sender: owner-mpls@UU.NET Precedence: bulk via news From owner-mpls@UU.NET Mon Jan 10 13:58:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10446 for ; Mon, 10 Jan 2000 13:58:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxkt09611; Mon, 10 Jan 2000 18:58:15 GMT Received: by mail-control.mail.uu.net id QQhxkt23716 for mpls-outgoing; Mon, 10 Jan 2000 18:57:41 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhxkt23710 for ; Mon, 10 Jan 2000 18:57:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxkt21292 for ; Mon, 10 Jan 2000 13:57:35 -0500 (EST) Received: from tokyo.ccrle.nec.de by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQhxkt08946 for ; Mon, 10 Jan 2000 18:57:34 GMT Received: from prak (Prak.heidelberg.ccrle.nec.de [192.168.102.92]) by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with SMTP id TAA28092 for ; Mon, 10 Jan 2000 19:57:56 +0100 (CET) Message-ID: <002201bf5b9b$9c55a420$5c66a8c0@prak.heidelberg.ccrle.nec.de> From: "hjs" To: "MPLS Mailing List" Subject: Deadline extended to January 24th Date: Mon, 10 Jan 2000 19:50:48 +0100 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit My sincere apology if you receive multiple copies of this CFP. Please feel free to pass the CFP to anyone who might be interested. Kind regards, Heinrich Stuettgen Call For Papers ---------------------------------------------------------------------- 2nd Call For Papers Extended Submission Deadline - Jan.24th, 2000 Conference on High Performance Switching & Routing Joint IEEE ATM Workshop 2000 and 3rd International Conference on ATM (ICATM'2000) June 26-29, 2000 Crowne Plaza Hotel, Heidelberg, Germany Sponsored by the IEEE Communication Society Supported by: VDE, EC Information Society Technologies, EURESCOM GmbH, Alcatel SEL AG, Cisco Systems GmbH, Deutsche Telekom AG, Ericsson Eurolab Deutschland GmbH, IBM Deutschland GmbH, Lucent Technologies GmnH, NEC Europe Ltd., Siemens AG For a nicely formatted version of this Call for Papers as well as for any other information related to this event please check the conference website under URL: http://atm2000.ccrle.nec.de Conference Scope A wide variety of ATM products have been developed for local and wide-area, private and public networks. First-generation ATM public services have been deployed on a global basis and efforts are underway to implement full-service, large-scale ATM networks. Wired (xDSL, HFC) and wireless (W-ATM) access networks enabling end-to-end ATM services are becoming available. Integration between ATM and IP evolves rapidly. Researchers and practitioners are studying issues like network design, network performance and traffic engineering, network reliability and survivability, charging and tariffing, quality of service and multicast support. At the same time next generation switching and routing technologies including IP over SONET/SDH or IP over WDM are being developed, converging cell and packet switching architectures. Driving applications for integrated networks become visible, namely Virtual Private Networks (VPN), Voice over Packet (VOP) and group communication services like conferencing and video on demand (VOD). They create new requirements on network architecture and management. The purpose of the conference is to share ideas, experiences, and information among researchers, developers, and service providers in the field of data, voice and multimedia communications using ATM and other high-speed switching and routing technologies, including Gigabit/Terabit switch/routers for optical networks. Original papers are hereby solicited on such topics as (but not limited to): 1. ATM Networks 1.1. ATM/WDM Networks 1.2. Broadband Access Networks (xDSL,HFC,PON) 1.3. Wireless / Mobile ATM 1.4. Satellite-Based ATM 1.5. ATM and UMTS/IMT2000 1.6. Interworking 2. ATM Switching 2.1. ATM Switch Architectures 2.2. Large-Scale Switch Implementations and Performance 2.3. Broadcasting/Multicasting 3. Signaling and Control 3.1. Broadband Signaling 3.2. Large-scale Call Processing Architectures. 3.3. PNNI, I-PNNI 3.4. QoS Routing 3.5. Signaling Interworking (ATM, PSTN, VoIP,...) 4. Traffic Engineering 4.1. ATM Traffic Modeling 4.2. Cell and Packet Level Scheduling 4.3. UBR,VBR, ABR, CBR Performance 4.4. Traffic Engineering 4.5. Network Design and Dimensioning 4.6. Network Optimization 5. ATM/IP Integration 5.1. IP/ATM Integration: MPLS, MPOA, ... 5.2. IP Multicasting over ATM 5.3. IPv6 over ATM 5.4. TCP over ATM 5.5. IP over ATM vs. native IP 6. Integrated Services, Multimedia 6.1. Native ATM Applications and Interfaces 6.2. QoS and CoS 6.3. IntServ and Diffserv 6.4. Video Coding and Transmission 6.5. VToA, VoP, VoIP 6.6. Multimedia Traffic Characteristics 7. Management and Control 7.1. Software Architectures for Switch/Router Control 7.2. Traffic Management Functions (UPC,CAC,...) 7.3. Tariffing, Charging and Accounting 7.4. Virtual Private Networks, VLANs,... 7.5. Network/VPN Security 7.6. Survivability, Fault Tolerance, Self-Healing,... 7.7. Network and Service Management 7.8. Service Provisioning 8. Gigabit/Terabit Routers 8.1. High-Speed Packet Switching and Routing 8.2. Switching & Routing for WDM 8.3. IP over SONET/SDH and IP over WDM 8.4. MPLS over WDM 8.5. Multicast Routing 9. Real User Networks 9.1. Operational Experience 9.2. User Experiences 9.3. Business Aspects 9.4. Network Evolution 10. Alternative Technologies 10.1. DTM 10.2. Photonic Switching 10.3. others Instructions for Authors: Send an electronic version of your submission to the address below. Submissions should be extended abstracts (2000 - 3000 words) summarizing original work. All the manuscripts must be written in English. The first page of each paper should contain the title of the paper, the authors' name(s), affiliation, address, telephone and fax numbers, e-mail of the author responsible for correspondence, a list of four keywords and categories from the above list as well as a summary of up to 100 words of the main achievements in your contribution. Electronic submissions are strongly encouraged. Acceptable formats are PDF, Postscript Level 2, RTF, FrameMaker Vs.5, Word 97. Please use A4 paper format when formatting your submission! Authors of accepted papers will later be required to submit an IEEE copyright form, please assure that you have all necessary authorizations in place. Typing instructions for accepted full papers can be downloaded from http://www.vde-verlag.de. All submitted papers should be sent electronically to the following address: Dr. Heinrich J. Stüttgen, General Chair IEEE ATM Workshop 2000 & ICATM 2000 Computer and Communcation Research Laboratories NEC Europe Ltd. Adenauerplatz 6 D-69115 Heidelberg, Germany Phone: +49 6221 905 11-0 Fax: +49 6221 905 11-55 E-mail: ATM2000@ccrle.nec.de Important Dates: Submission of extended abstract due: extended to: January 24th, 2000 (Ext.Abstracts of 5 pages or 2500 words) Authors notified: March 15th, 2000 Final camera ready papers due: April 17th, 2000 (Final papers of max. 5000 Words or 10 Pages) Tutorials: On Monday, June 26th, 2000 the workshop will begin with four half day tutorials focusing on emerging technologies in the areas of MPLS, IP over WDM, Gigabit Routing, IP/ATM in UMTS/IMT2000, Soft-Switch Architecture and related subjects. Workshop Committees General Chair (IEEE ATM Workshop) Heinrich J. Stuettgen, C&C Research Laboratories NEC Europe Ltd., Heidelberg, German General Co-Chair (ICATM) Pascal Lorenz, University Haute Alsace, Colmar, France Technical Co-Chairs Jonathan Turner, Washington University, St.Louis, USA Naoaki Yamanaka, NTT Network System Laboratories, Tokyo, Japan From owner-mpls@UU.NET Mon Jan 10 14:42:55 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11141 for ; Mon, 10 Jan 2000 14:42:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxkw25920; Mon, 10 Jan 2000 19:42:36 GMT Received: by mail-control.mail.uu.net id QQhxkw04868 for mpls-outgoing; Mon, 10 Jan 2000 19:42:03 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxkw04861 for ; Mon, 10 Jan 2000 19:41:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxkw25827 for ; Mon, 10 Jan 2000 14:41:49 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhxkw25127 for ; Mon, 10 Jan 2000 19:41:46 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Mon, 10 Jan 2000 14:41:38 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CD8A@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Subject: MPLS termination action sub-object in ERO for RSVP Date: Mon, 10 Jan 2000 14:41:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk hi, I'm a little confused about the use of the LSP termination sub-object in the explicit route object and the allocation of multi-level labels using RSVP. 1. Who decides to allocate a higher level label ? a. the egress point ? - this will help it identify the ultimate destination assuming the LSP is part of a tunnel. b. An intermediate node that performed a merge - this will allow the various flows to be uniquely identified using the second level label ? in this case how will the upper label be negotiated with the next hop ? c. Any other contenders ? 2. How is the "LSP Termination" object is used ? Since it can only appear as part of an ERO, and hence only from the ingress - what is the expected treatment by the receiving node - the one identified in the ERO ? Is it expected that the receiving node realize it has to assign more than the top label ? is it some kind of "penultimate-hop-pop" mechanism ? Thanx, Andi. From owner-mpls@UU.NET Mon Jan 10 18:04:41 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14837 for ; Mon, 10 Jan 2000 18:04:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxlk10259; Mon, 10 Jan 2000 23:04:18 GMT Received: by mail-control.mail.uu.net id QQhxlk17199 for mpls-outgoing; Mon, 10 Jan 2000 23:03:58 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxlk17177 for ; Mon, 10 Jan 2000 23:03:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxlk29241 for ; Mon, 10 Jan 2000 18:03:51 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxlk09833 for ; Mon, 10 Jan 2000 23:03:50 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA14062; Mon, 10 Jan 2000 15:03:15 -0800 (PST) Message-Id: <4.2.2.20000111091834.00a9ca20@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 11 Jan 2000 10:02:51 +1100 To: Juha Heinanen From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <14457.53223.113348.696513@lohi.eng.telia.fi> References: <4.2.2.20000110222653.00a91b20@farley.cisco.com> <4.2.2.20000110190615.00a8c3b0@farley.cisco.com> <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> <4.2.2.20000108174032.00a931d0@farley.cisco.com> <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000110222653.00a91b20@farley.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Juha, At 14:26 01/10/2000 +0200, Juha Heinanen wrote: >Jeremy Lawrence writes: > > > It is might possible to change LDP to remove this assumption, but > > this would involve a lot of work and debate, on both LDP itself, > > and on the architectural issues. LDP is currently designed to > > work in close conjunction with a routing protocol. > >ok, in that case an lsr that wishes to terminate label requests to >itself, needs to advertise its ip address(es) as /32 routes. i assume >that an actual routing protocol is not needed, but that the advertisement >can be staticly configured. > >regarding the architectural issues, if a network is only interested to >run ldp in downstream on demand/ordered control mode, then it is not >clear to me what the architectural and prototol problems would be that >would prevent an lsr from forwarding a label request based on longest >match. Assume that the CPE uses LDP to ask for a label for a.b.c.d/32, and the operator LSR knows a route only for a.b.0.0/16, and LDP is modified to allow it to respond. There are many issues with this that are not addressed in the LDP spec: - Does the operator LSR respond with a binding for a. a.b.c.d/32, or b. a.b.0.0/16? - If (b), then either: i. The CPE must not assume that it can use the binding for any address in a.b.0.0/16. It must ask again for each address, in case the operator LSR knows a more specific route for some of the addresses. ii. If the operator LSR knows more specific routes in a.b.0.0/16, (e.g. a.b.e.0/24) it must return bindings for those routes at the same time that it returns the binding for a.b.0.0/16. - In (a) or (b.i), then if the CPE asks for bindings for other addresses for which a.b.0.0/16 is the best match, then the operator LSR should return the same label value. (Or should it?) - What are the procedures if the route for a.b.0.0/16 goes away? (Observe that there might be other valid routes to a.b.c.d, e.g. a.0.0.0/8, or 0.0.0.0/0. What should the operator LSR automatically do?) - What are the procedures if a new route in a.b.0.0/16 is learnt, e.g. a.b.f.0/24? The last two points suggest that with either (a) or (b.i), the operator LSR must remember the requested prefixes for all binding requests, even though it will respond with a duplicate label to many of them. This is so it can make the correct changes to the labels if the routing information ever changes. Now assume that the CPE can ask for addresses other than /32s. This will work ok with (b.ii), but it's not obvious how to make this work with (a) or (b.i), except to make them work like (b.ii) in this case. Note that with (b.ii), if the CPE ever asks for a binding for 0.0.0.0/0, then the LDP peering will then (effectively) start to run in downstream mode. Curtis has just pointed out that the problem can be dealt with by using an explicitly routed LSP rather than LDP. That seems more sensible than modifying LDP to deal with all this mess. Regards, Jeremy Lawrence From owner-mpls@UU.NET Mon Jan 10 18:23:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14957 for ; Mon, 10 Jan 2000 18:23:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxll21525; Mon, 10 Jan 2000 23:23:40 GMT Received: by mail-control.mail.uu.net id QQhxll23412 for mpls-outgoing; Mon, 10 Jan 2000 23:23:18 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhxll23403 for ; Mon, 10 Jan 2000 23:23:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxll17665 for ; Mon, 10 Jan 2000 18:23:07 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxll20926 for ; Mon, 10 Jan 2000 23:23:06 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA19668; Mon, 10 Jan 2000 15:18:34 -0800 (PST) Message-Id: <4.2.2.20000111100346.00a9de90@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 11 Jan 2000 10:18:03 +1100 To: "David Allan" From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <6DDA62170439D31185750000F80826AC01214750@zmerd004.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk David, At 08:30 01/10/2000 -0600, David Allan wrote: [...] >So I don't want to ask for /32s, I want a /0 best effort, and then ask for /32s or whatever when I need somthing extra or somthing non-IP in the payload. By the argument in previous emails, if: 1. the CPE asks for a label for 0.0.0.0/0, and 2. there is no routing protocol or similar means of ensuring consistent routing information between the CPE and operator LSR, and 3. the operator LSR knows more specific routes in addition to 0.0.0.0/0 then label forwarding would run correctly if and only if the operator LSR returned labels for all routes it knows, in response to the request for a binding for 0.0.0.0/0. Otherwise, the CPE will always pretend that the longest prefix match for an address a.b.c.d is 0.0.0.0/0, when often there will be a better match, say a.b.0.0/16. This would mean that the operator LSR often would not correctly forward traffic from the CPE. (LDP as it stands is the wrong tool for this job, as it assumes the reverse of point #2.) Regards, Jeremy Lawrence From owner-mpls@UU.NET Mon Jan 10 18:29:10 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15020 for ; Mon, 10 Jan 2000 18:29:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxll13736; Mon, 10 Jan 2000 23:29:10 GMT Received: by mail-control.mail.uu.net id QQhxll23874 for mpls-outgoing; Mon, 10 Jan 2000 23:28:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxll23869 for ; Mon, 10 Jan 2000 23:28:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxll00992 for ; Mon, 10 Jan 2000 18:28:38 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxll24256 for ; Mon, 10 Jan 2000 23:28:37 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA23252; Mon, 10 Jan 2000 15:28:32 -0800 (PST) Message-Id: <4.2.2.20000111081911.00a50ee0@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 11 Jan 2000 10:27:54 +1100 To: "Johnson, Robert (Broadwing)" From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Robert, At 09:29 01/10/2000 -0600, Johnson, Robert (Broadwing) wrote: >Jeremy, > >I would refer you to the short discussion thread on Private Line over MPLS. >I am also looking into Voice over MPLS. Both of these applications require >additional services which MPLS does not provide today (i.e. guaranteed >ordered packet delivery). That's certainly not true for carrying voice over MPLS. Per the discussions last week, virtually any packet voice system can deal with small amounts of packet misordering (by discarding the out-of-order packets). >Therefore, I suppose that we are talking about >additional adaptation layers to provide the facilities necessary to deliver >these services over an MPLS infrastructure. Without going into detail, I >think that you can see the problems that might occur if this isn't made >abundantly clear up-front. Private Lines are another issue, and yes, there would need to be some mechanism to ensure packet ordering. However I wonder if we're looking at the right problem here. What, exactly, is the problem you are trying to solve? (I suspect that it may be "carrying private lines and MPLS on the same equipment", which is subtly different to "carrying private lines over MPLS".) Regards, Jeremy Lawrence From owner-mpls@UU.NET Mon Jan 10 19:55:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15771 for ; Mon, 10 Jan 2000 19:55:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxlr27773; Tue, 11 Jan 2000 00:55:21 GMT Received: by mail-control.mail.uu.net id QQhxlr07171 for mpls-outgoing; Tue, 11 Jan 2000 00:54:59 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxlr07163 for ; Tue, 11 Jan 2000 00:54:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxlr23613 for ; Mon, 10 Jan 2000 19:54:38 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQhxlr09272 for ; Tue, 11 Jan 2000 00:54:37 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id TAA10756; Mon, 10 Jan 2000 19:54:34 -0500 Date: Mon, 10 Jan 2000 19:54:34 -0500 From: "J. Noel Chiappa" Message-Id: <200001110054.TAA10756@ginger.lcs.mit.edu> To: Robert.Johnson@broadwing.com, mpls@UU.NET Subject: RE: prime time MPLS/fiber Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: "Johnson, Robert (Broadwing)" > Both of these applications require additional services which MPLS does > not provide today (i.e. guaranteed ordered packet delivery). I'm still curious to see what your answer is to a question I put previously (although perhaps somehow my mail to the MPLS list didn't get to you): How do these services deal with lost packets? ... Or are you saying that these services won't work in networks which can lose packets? If so, are you now proposing that MPLS guaranteee to never drop packets? And if these services can somehow deal with lost packets (e.g. by simply ignoring them, the way packet voice does), why can't they just discard out-of-order packets - if a service can handle lost packets, it can handle discarded packets, right? Do I take it from your phrase above ("guaranteed ordered packet delivery") that you do in fact propose that MPLS networks guarantee to never lose packets? > I suppose that we are talking about additional adaptation layers to > provide the facilities necessary to deliver these services over an MPLS > infrastructure. So, if I correctly understand you, you're now proposing that we provide this reliable, ordered service by means of an AL above MPLS. In that case, my query is whether you propose that this AL be something provided in the end-nodes, or by the switches in the middle - i.e., fundamentally, whether a packet lost in the network is replicated from a preceding switch, or whether the ultimate originator has to resend the packet. Noel From owner-mpls@UU.NET Tue Jan 11 00:00:51 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19406 for ; Tue, 11 Jan 2000 00:00:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxmi11588; Tue, 11 Jan 2000 05:00:35 GMT Received: by mail-control.mail.uu.net id QQhxmi27968 for mpls-outgoing; Tue, 11 Jan 2000 05:00:09 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxmi27818 for ; Tue, 11 Jan 2000 05:00:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxmh07487 for ; Mon, 10 Jan 2000 23:59:57 -0500 (EST) Received: from metconnect.ixc-comm.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ixcfw1.ixc-comm.com [38.244.111.5]) id QQhxmh28798 for ; Tue, 11 Jan 2000 04:59:57 GMT Received: by metconnect.ixc-comm.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 22:56:20 -0600 Message-ID: From: "Johnson, Robert (Broadwing)" To: "'Jeremy Lawrence'" Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Date: Mon, 10 Jan 2000 22:59:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk >>I would refer you to the short discussion thread on Private Line over MPLS. >>I am also looking into Voice over MPLS. Both of these applications require >>additional services which MPLS does not provide today (i.e. guaranteed >>ordered packet delivery). >That's certainly not true for carrying voice over MPLS. Per the >discussions last week, virtually any packet voice system can deal >with small amounts of packet misordering (by discarding the >out-of-order packets). I suppose that depends on the definition of VoMPLS. If VoMPLS were simply VoIP within MPLS, it should still be referred to as VoIP. However, if the IP layer is removed and the RTP/UDP layers are retained, then they would act as the adaptation layer for voice services over the MPLS transport layer. However, I am not currently up-to-date on the activities in the VoMPLS area, so I apologize if my comments are out-of-order. >>Therefore, I suppose that we are talking about >>additional adaptation layers to provide the facilities necessary to deliver >>these services over an MPLS infrastructure. Without going into detail, I >>think that you can see the problems that might occur if this isn't made >>abundantly clear up-front. >Private Lines are another issue, and yes, there would need to be >some mechanism to ensure packet ordering. However I wonder if we're >looking at the right problem here. What, exactly, is the problem you >are trying to solve? (I suspect that it may be "carrying private lines >and MPLS on the same equipment", which is subtly different to >"carrying private lines over MPLS".) Agreed. Private line and MPLS traffic carried over the same switch is quite different from using MPLS as the transport protocol to carry the private line traffic. However, as I understand it, there are those with the intention of using MPLS in the same manner that ATM is used in carrier networks today to provide CES. However, MPLS does not provide all of the facilities to support CES that ATM does. In short, I do not think that MPLS is anymore of a convergence layer than other proposed convergence layers that have gone before it. It will require modifications to support some of the services that are being delivered today over networks using ATM or physical leased facilities. Robert Johnson From owner-mpls@UU.NET Tue Jan 11 00:05:42 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19475 for ; Tue, 11 Jan 2000 00:05:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxmi14295; Tue, 11 Jan 2000 05:05:33 GMT Received: by mail-control.mail.uu.net id QQhxmi03263 for mpls-outgoing; Tue, 11 Jan 2000 05:05:09 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxmi03157 for ; Tue, 11 Jan 2000 05:05:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxmi07790 for ; Tue, 11 Jan 2000 00:05:03 -0500 (EST) Received: from samar.sasi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sasi.com [164.164.56.2]) id QQhxmi13876 for ; Tue, 11 Jan 2000 05:04:59 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id KAA21063 for ; Tue, 11 Jan 2000 10:36:24 +0530 (IST) Received: from pcd133.sasi.com ([10.0.16.133]) by samar.sasi.com; Tue, 11 Jan 2000 10:36:23 +0000 (IST) Received: from localhost (vasan@localhost) by pcd133.sasi.com (8.9.1/8.9.1) with ESMTP id KAA04578 for ; Tue, 11 Jan 2000 10:37:27 +0530 Date: Tue, 11 Jan 2000 10:37:26 +0530 (IST) From: Srinivasan Rangarajan To: mpls@UU.NET Subject: MPLS Implementation In Linux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am currently going through James R. Leu's mpls implementation in linux. I have downloaded the linux-2.3.3.tar.gz. But I am unable to find "linux/mpls.h" which is included in one of the files in ldpd directory. where I can find that file?. Also I am not able to find the definitions of types "fec_type" and "label_type",etc. Where can I get this?. Regards, R. Srinivasan From owner-mpls@UU.NET Tue Jan 11 00:11:10 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19496 for ; Tue, 11 Jan 2000 00:11:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxmi04491; Tue, 11 Jan 2000 05:10:55 GMT Received: by mail-control.mail.uu.net id QQhxmi05944 for mpls-outgoing; Tue, 11 Jan 2000 05:10:29 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhxmi05939 for ; Tue, 11 Jan 2000 05:10:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxmi08045 for ; Tue, 11 Jan 2000 00:10:12 -0500 (EST) Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQhxmi03909 for ; Tue, 11 Jan 2000 05:10:09 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 11 Jan 2000 10:47:47 +0530 Received: from david.future.futsoft.com ([172.16.1.119]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA30289 for ; Tue, 11 Jan 2000 10:30:26 +0530 Message-Id: <009101bf5bf1$814cc040$770110ac@future.futsoft.com> From: "dailei" To: Subject: How to process hello msg if received from different logical network? Date: Tue, 11 Jan 2000 10:35:38 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello All: I have a doubt of LDP running on broadcast network. -------------------------- | | | A B C A:10.0.1.0/24 B:10.0.1.0/24, 10.0.2.0/24 C:10.0.2.0/24 Consider the LSR A,B,C are in the same broadcast network, but in different logic sub networks. When LSR C receives a hello message from LSR A, how to process it? Is it necessary to create a new adjacency and session? I think this new session is useless because it is impossible that LSR A becomes the next hop of LSR C. Regards, Dai Lei dailei@bigfoot.com From owner-mpls@UU.NET Tue Jan 11 00:34:47 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19730 for ; Tue, 11 Jan 2000 00:34:47 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxmk01855; Tue, 11 Jan 2000 05:34:36 GMT Received: by mail-control.mail.uu.net id QQhxmk07551 for mpls-outgoing; Tue, 11 Jan 2000 05:34:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxmk07545 for ; Tue, 11 Jan 2000 05:34:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxmk08205 for ; Tue, 11 Jan 2000 00:33:49 -0500 (EST) Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQhxmk15597 for ; Tue, 11 Jan 2000 05:33:46 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 11 Jan 2000 11:10:38 +0530 Received: from david.future.futsoft.com ([172.16.1.119]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA30862 for ; Tue, 11 Jan 2000 10:53:18 +0530 Message-Id: <001f01bf5bf4$b2ceac20$770110ac@future.futsoft.com> From: "dailei" To: "mpls" Subject: How to process hello msg if received from different logical network? Date: Tue, 11 Jan 2000 10:58:31 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello All: I have a doubt of LDP running on broadcast network. -------------------------- | | | A B C A:10.0.1.0/24 B:10.0.1.0/24, 10.0.2.0/24 C:10.0.2.0/24 Consider the LSR A,B,C are in the same broadcast network, but in different logic sub networks. When LSR C receives a hello message from LSR A, how to process it? Is it necessary to create a new adjacency and session? I think this new session is useless because it is impossible that LSR A becomes the next hop of LSR C. Regards, Dai Lei From owner-mpls@UU.NET Tue Jan 11 01:05:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20019 for ; Tue, 11 Jan 2000 01:05:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxmm20905; Tue, 11 Jan 2000 06:05:35 GMT Received: by mail-control.mail.uu.net id QQhxmm14752 for mpls-outgoing; Tue, 11 Jan 2000 06:05:10 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxmm14620 for ; Tue, 11 Jan 2000 06:05:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxmm09494 for ; Tue, 11 Jan 2000 01:05:02 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxmm00499 for ; Tue, 11 Jan 2000 06:05:02 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id WAA17449; Mon, 10 Jan 2000 22:04:57 -0800 (PST) Message-Id: <4.2.2.20000111165406.00a87d50@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 11 Jan 2000 17:04:46 +1100 To: "Johnson, Robert (Broadwing)" From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Robert, >Agreed. Private line and MPLS traffic carried over the same switch is quite >different from using MPLS as the transport protocol to carry the private >line traffic. However, as I understand it, there are those with the >intention of using MPLS in the same manner that ATM is used in carrier >networks today to provide CES. However, MPLS does not provide all of the >facilities to support CES that ATM does. This begs the question "why add them?". MPLS was invented to do some things well that nothing else did well, but CES wasn't one of those things. ATM does CES well. If it is easy to modify MPLS to do CES well, it might be justifiable to modify it. Otherwise, why not just use ATM to do CES? Jeremy From owner-mpls@UU.NET Tue Jan 11 01:21:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21156 for ; Tue, 11 Jan 2000 01:21:31 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxmn09936; Tue, 11 Jan 2000 06:21:16 GMT Received: by mail-control.mail.uu.net id QQhxmn18096 for mpls-outgoing; Tue, 11 Jan 2000 06:20:49 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxmn18085 for ; Tue, 11 Jan 2000 06:20:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxmn11340; Tue, 11 Jan 2000 01:20:28 -0500 (EST) From: netserv5@crescotek.com Received: from ibernet4.ibernet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [195.76.100.6]) id QQhxmn09141; Tue, 11 Jan 2000 06:20:27 GMT Message-Id: Received: from LocalHost ([208.26.26.3]) by ibernet4.ibernet.com (Netscape Mail Server v2.02) with SMTP id AAA27136; Tue, 11 Jan 2000 07:20:40 +0000 Subject: Re: That Info (374ie78) Date: Tue, 11 Jan 2000 01:09:45 To: X-See-Also: 0A79B1D15 MessageID: X-Mailer: Internet Mail Service [6.2.1187.81] (Win95; I) Content-Type: text/plain X-Accept-Language: en X-In-Response-To: 0A216BA9C Sender: owner-mpls@UU.NET Precedence: bulk I NEED HELP!!! OVERWHELMED with Leads! Will Help You Get Started! Earn $5000.00 to $10,000.00 per month…PART TIME! Fantastic Support! No Selling. NOT MLM. 1-800-886-2334 24 hour 2 minute message, if busy…call back in 2 minutes $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$ +++++++++++++++++++++++++++++++++++++++++++++++++++ For Removal Please reply with Remove in the subject or call toll free 877-202-0942 and you will be permanently removed from future mailings. +++++++++++++++++++++++++++++++++++++++++++++++++++ From owner-mpls@UU.NET Tue Jan 11 03:42:15 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02607 for ; Tue, 11 Jan 2000 03:42:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxmw12791; Tue, 11 Jan 2000 08:42:03 GMT Received: by mail-control.mail.uu.net id QQhxmw11730 for mpls-outgoing; Tue, 11 Jan 2000 08:41:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxmw11721 for ; Tue, 11 Jan 2000 08:41:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxmw17323 for ; Tue, 11 Jan 2000 03:41:36 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQhxmw12175 for ; Tue, 11 Jan 2000 08:41:36 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id KAA10945; Tue, 11 Jan 2000 10:41:25 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14458.60597.806988.344161@lohi.eng.telia.fi> Date: Tue, 11 Jan 2000 10:41:25 +0200 (EET) To: Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber In-Reply-To: <4.2.2.20000111091834.00a9ca20@farley.cisco.com> References: <4.2.2.20000110222653.00a91b20@farley.cisco.com> <4.2.2.20000110190615.00a8c3b0@farley.cisco.com> <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> <4.2.2.20000108174032.00a931d0@farley.cisco.com> <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000111091834.00a9ca20@farley.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeremy Lawrence writes: > - Does the operator LSR respond with a binding for > a. a.b.c.d/32, or > b. a.b.0.0/16? it should respond with (a) since that is what the user asked for. > - In (a) or (b.i), then if the CPE asks for bindings for other > addresses for which a.b.0.0/16 is the best match, then the operator > LSR should return the same label value. (Or should it?) it should return a new label for the other destination. > - What are the procedures if the route for a.b.0.0/16 goes away? > (Observe that there might be other valid routes to a.b.c.d, > e.g. a.0.0.0/8, or 0.0.0.0/0. What should the operator LSR > automatically do?) nothing as long the lsp stays up. > - What are the procedures if a new route in a.b.0.0/16 is learnt, > e.g. a.b.f.0/24? again, new routes only affect new lsps, not the ones that already exist as long as they stay up. an operator can of course have a policy to reroute also existing lsps if the new routes are "much" better than the old ones and tell when that can happen. > The last two points suggest that with either (a) or (b.i), the > operator LSR must remember the requested prefixes for all binding > requests, even though it will respond with a duplicate label to > many of them. This is so it can make the correct changes to the > labels if the routing information ever changes. i don't see how the labels could be duplicate for different destinations. > Now assume that the CPE can ask for addresses other than /32s. > This will work ok with (b.ii), but it's not obvious how to > make this work with (a) or (b.i), except to make them work > like (b.ii) in this case. in the application that i have been talking about, the cpe lsr would not ASK labels for addresses other than /32, but the lsrs would ADVERTISE addresses with prefixes other than /32. > Curtis has just pointed out that the problem can be dealt with > by using an explicitly routed LSP rather than LDP. That seems > more sensible than modifying LDP to deal with all this mess. it doesn't sound realistic to me that the cpe lsr would know or care about any explicit routes. -- juha From owner-mpls@UU.NET Tue Jan 11 05:32:43 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03149 for ; Tue, 11 Jan 2000 05:32:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxne08412; Tue, 11 Jan 2000 10:32:25 GMT Received: by mail-control.mail.uu.net id QQhxne03854 for mpls-outgoing; Tue, 11 Jan 2000 10:32:04 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxne03847 for ; Tue, 11 Jan 2000 10:32:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxne21846 for ; Tue, 11 Jan 2000 05:31:52 -0500 (EST) From: bie.jiuling@mail.zhongxing.com Received: from mail.zhongxing.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) id QQhxnd05075 for ; Tue, 11 Jan 2000 10:27:20 GMT Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 48256863.003950F7 ; Tue, 11 Jan 2000 18:26:02 +0800 X-Lotus-FromDomain: ZTE_LTD To: Srinivasan Rangarajan cc: mpls@UU.NET Message-ID: <48256863.0025CDC8.00@mail.zhongxing.com> Date: Tue, 11 Jan 2000 14:57:03 +0800 Subject: RE:MPLS Implementation In Linux Sender: owner-mpls@UU.NET Precedence: bulk There's a patch file 'kernel/mpls-2.3.3.diff' in the package. Using patch utility against your kernel source with this file, you can get those .h files. The types are all in generated 'mpls.h'. Regards Seado Hi, I am currently going through James R. Leu's mpls implementation in linux. I have downloaded the linux-2.3.3.tar.gz. But I am unable to find "linux/mpls.h" which is included in one of the files in ldpd directory. where I can find that file?. Also I am not able to find the definitions of types "fec_type" and "label_type",etc. Where can I get this?. Regards, R. Srinivasan From owner-mpls@UU.NET Tue Jan 11 07:17:12 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04708 for ; Tue, 11 Jan 2000 07:17:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxnl18740; Tue, 11 Jan 2000 12:17:02 GMT Received: by mail-control.mail.uu.net id QQhxnl24760 for mpls-outgoing; Tue, 11 Jan 2000 12:16:26 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxnl24741 for ; Tue, 11 Jan 2000 12:16:24 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxnl28886 for ; Tue, 11 Jan 2000 07:16:05 -0500 (EST) Received: from smtp1.cluster.oleane.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.cluster.oleane.net [195.25.12.16]) id QQhxnl12372 for ; Tue, 11 Jan 2000 12:16:04 GMT Received: from oleane (dyn-1-1-205.Vin.dialup.oleane.fr [195.25.4.205]) by smtp1.cluster.oleane.net with SMTP id NAA46002; Tue, 11 Jan 2000 13:15:58 +0100 (CET) Message-ID: <001b01bf5c2d$41e873e0$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: Cellular Internet, Call for Paper Date: Tue, 11 Jan 2000 13:13:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01BF5C35.A2B8B7E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0018_01BF5C35.A2B8B7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cellular Internet: The Micro-Mobility Approach The micro-mobility concept is the most recent and promising approach = proposed to add mobility to the Internet and packet data services to = third generation cellular systems. =20 A CFP is available at:=20 http://www.upperside.fr/baipcn.htm ------=_NextPart_000_0018_01BF5C35.A2B8B7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cellular Internet: The = Micro-Mobility=20 Approach

The micro-mobility concept is the most recent and = promising=20 approach proposed to add mobility to the Internet and packet data = services to=20 third generation cellular systems.
 
A CFP is available at:
http://www.upperside.fr/baipc= n.htm
------=_NextPart_000_0018_01BF5C35.A2B8B7E0-- From owner-mpls@UU.NET Tue Jan 11 08:17:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07422 for ; Tue, 11 Jan 2000 08:17:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxnp27245; Tue, 11 Jan 2000 13:17:30 GMT Received: by mail-control.mail.uu.net id QQhxnp08069 for mpls-outgoing; Tue, 11 Jan 2000 13:16:54 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxnp08047 for ; Tue, 11 Jan 2000 13:16:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxnp29901 for ; Tue, 11 Jan 2000 08:16:48 -0500 (EST) Received: from metconnect.ixc-comm.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ixcfw1.ixc-comm.com [38.244.111.5]) id QQhxnp26235 for ; Tue, 11 Jan 2000 13:16:48 GMT Received: by metconnect.ixc-comm.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jan 2000 07:13:11 -0600 Message-ID: From: "Johnson, Robert (Broadwing)" To: "'Jeremy Lawrence'" Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Date: Tue, 11 Jan 2000 07:16:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jeremy, >This begs the question "why add them?". MPLS was invented to do some >things well that nothing else did well, but CES wasn't one of those >things. ATM does CES well. If it is easy to modify MPLS to do CES >well, it might be justifiable to modify it. Otherwise, why not just >use ATM to do CES? That has been my argument to those who suggest that MPLS will completely eliminate the applications for ATM in short order. However, by not clarifying that MPLS will not support all applications that ATM supports, perhaps we are inviting such discussion. Robert Johnson From owner-mpls@UU.NET Tue Jan 11 11:15:18 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13981 for ; Tue, 11 Jan 2000 11:15:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxoa00146; Tue, 11 Jan 2000 16:14:51 GMT Received: by mail-control.mail.uu.net id QQhxoa13733 for mpls-outgoing; Tue, 11 Jan 2000 16:14:16 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxoa13670 for ; Tue, 11 Jan 2000 16:14:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxoa16806 for ; Tue, 11 Jan 2000 11:14:08 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhxoa29499 for ; Tue, 11 Jan 2000 16:14:06 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Jan 11 11:12:31 EST 2000 Received: from lucent.com (vasanthipc [135.180.130.137]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA20451; Tue, 11 Jan 2000 11:12:29 -0500 (EST) Message-ID: <387B5635.2D63161E@lucent.com> Date: Tue, 11 Jan 2000 11:11:33 -0500 From: Vasanthi Thirumalai Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: dailei CC: mpls Subject: Re: How to process hello msg if received from different logical network? References: <001f01bf5bf4$b2ceac20$770110ac@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dailei, On getting a hello, check whether you need to respond to it by looking at the peer address and respond only when that is in the same subnet. -Vasanthi dailei wrote: > > Hello All: > I have a doubt of LDP running on broadcast network. > > -------------------------- > | | | > A B C > > A:10.0.1.0/24 > B:10.0.1.0/24, 10.0.2.0/24 > C:10.0.2.0/24 > > Consider the LSR A,B,C are in the same broadcast network, but in different > logic sub networks. When LSR C receives a hello message from LSR A, how to > process it? Is it necessary to create a new adjacency and session? I think > this new session is useless because it is impossible that LSR A becomes the > next hop of LSR C. > > Regards, > Dai Lei -- ------------------------------------------------ Vasanthi Thirumalai Phone: 732-949-3787 Lucent Technologies Room : 2J-643 101 Crawfords Corner Holmdel, NJ-07733 ------------------------------------------------ From owner-mpls@UU.NET Tue Jan 11 12:03:59 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15658 for ; Tue, 11 Jan 2000 12:03:57 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxoe25384; Tue, 11 Jan 2000 17:02:35 GMT Received: by mail-control.mail.uu.net id QQhxoe21542 for mpls-outgoing; Tue, 11 Jan 2000 17:02:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxoe21528 for ; Tue, 11 Jan 2000 17:01:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxoe21571 for ; Tue, 11 Jan 2000 12:01:53 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQhxoe24661 for ; Tue, 11 Jan 2000 17:01:53 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Tue, 11 Jan 2000 12:01:03 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CL0AYDNJ; Tue, 11 Jan 2000 11:59:17 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CJ8MR716; Tue, 11 Jan 2000 11:59:18 -0500 Message-ID: <387B6166.1D138DC4@americasm01.nt.com> Date: Tue, 11 Jan 2000 11:59:18 -0500 From: "Peter Ashwood-Smith" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: MPLS Implementation In Linux References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit vasan@sasi.com wrote: > > Hi, > I am currently going through James R. Leu's mpls implementation > in linux. I have downloaded the linux-2.3.3.tar.gz. But I am > unable to find "linux/mpls.h" which is included in one of the > files in ldpd directory. where I can find that file?. > > Also I am not able to find the definitions of types "fec_type" > and "label_type",etc. Where can I get this?. > > Regards, > R. Srinivasan I'm not 100% certain but I suspect that is the same header file from the Nortel PDU's which you can get from www.NortelNetworks/mpls. Cheers, Peter Ashwood-Smith From owner-mpls@UU.NET Tue Jan 11 12:57:36 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16970 for ; Tue, 11 Jan 2000 12:57:35 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxoh12688; Tue, 11 Jan 2000 17:56:16 GMT Received: by mail-control.mail.uu.net id QQhxoh03736 for mpls-outgoing; Tue, 11 Jan 2000 17:55:40 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxoh03719 for ; Tue, 11 Jan 2000 17:55:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxoh13186 for ; Tue, 11 Jan 2000 12:55:23 -0500 (EST) Received: from smtprich.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprich.nortel.com [192.135.215.8]) id QQhxoh14500 for ; Tue, 11 Jan 2000 17:55:23 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Tue, 11 Jan 2000 11:55:29 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 11:54:48 -0600 Message-ID: <6DDA62170439D31185750000F80826AC0126E825@zmerd004.ca.nortel.com> From: "David Allan" To: Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber Date: Tue, 11 Jan 2000 11:54:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5C5C.F21CAB58" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5C5C.F21CAB58 Content-Type: text/plain Jeremy: > By the argument in previous emails, if: > 1. the CPE asks for a label for 0.0.0.0/0, and > 2. there is no routing protocol or similar means of ensuring > consistent routing information between the CPE and operator LSR, and > 3. the operator LSR knows more specific routes in addition to 0.0.0.0/0 > > then label forwarding would run correctly if and only if the operator > LSR returned labels for all routes it knows, in response to the > request for a binding for 0.0.0.0/0. > Otherwise, the CPE will always pretend that the longest prefix match for an address a.b.c.d is 0.0.0.0/0, when often there will be a better match, say a.b.0.0/16. This would mean that the operator LSR often would not correctly forward traffic from the CPE. (LDP as it stands is the wrong tool for this job, as it assumes the reverse of point #2.) I understand what you are saying, my suggestion is that MPLS transport be extended to the CPE but classification be distributed between the CPE and the operator LSR, hence traffic on 0.0.0.0/0 best effort cannot be directly forwarded without re-classification by a box with more authoritative knowledge of the routes. There may well be a better match known to the operator LSR, but I think the correct statement is that the operator LSR will not optimally forward traffic. It is capable of correctly forwarding it. This to me is a trade off as for short flows either: i) all this information needs to be a priori distributed to the CPE which adds to CPE complexity, OR ii) the CPE needs to request an explicit binding, which to me seems to defeat the point, adding additional transactions to simplify relatively few forwarding steps, OR iii) the CPE just forwards the packet to the provider LSR. For long flows, or those with specific characteristics, then requesting a specific binding to push classification to the edge and perform proper MPLS layer forwarding at the provider LSR makes sense. It addresses all my concerns. cheers Dave ------_=_NextPart_001_01BF5C5C.F21CAB58 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: prime time MPLS/fiber

Jeremy:

        <snip>

    By the argument in previous emails, = if:
    1. the CPE asks for a label for = 0.0.0.0/0, and
    2. there is no routing protocol or = similar means of ensuring
        consistent routing = information between the CPE and operator LSR, and
    3. the operator LSR knows more = specific routes in addition to 0.0.0.0/0

    then label forwarding would run = correctly if and only if the operator
    LSR returned labels for all routes it = knows, in response to the
    request for a binding for = 0.0.0.0/0.

    Otherwise, the CPE will always pretend = that the longest prefix match
    for an address a.b.c.d is 0.0.0.0/0, = when often there will
    be a better match, say a.b.0.0/16. = This would mean that the operator
    LSR often would not correctly forward = traffic from the CPE.

    (LDP as it stands is the wrong tool = for this job, as it assumes
    the reverse of point #2.)

I understand what = you are saying, my suggestion is that MPLS transport be extended to the = CPE but classification be distributed between the CPE and the operator = LSR, hence traffic on 0.0.0.0/0 best effort cannot be directly = forwarded without re-classification by a box with more authoritative = knowledge of the routes. There may well be a better match known to the = operator LSR, but I think the correct statement is that the operator = LSR will not optimally forward traffic. It is capable of correctly = forwarding it. This to me is a trade off as for short flows = either:

i)  all this = information needs to be a priori distributed to the CPE which adds to = CPE complexity, OR
ii) the CPE needs = to request an explicit binding,  which to me seems to defeat the = point, adding additional transactions to simplify relatively few = forwarding steps, OR

iii) the CPE just = forwards the packet to the provider LSR.

For long flows, or = those with specific characteristics, then requesting a specific binding = to push classification to the edge and perform proper MPLS layer = forwarding at the provider LSR makes sense. It addresses all my = concerns.

cheers
Dave

------_=_NextPart_001_01BF5C5C.F21CAB58-- From owner-mpls@UU.NET Tue Jan 11 14:16:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19002 for ; Tue, 11 Jan 2000 14:16:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxom02885; Tue, 11 Jan 2000 19:12:25 GMT Received: by mail-control.mail.uu.net id QQhxom25674 for mpls-outgoing; Tue, 11 Jan 2000 19:11:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxom25584 for ; Tue, 11 Jan 2000 19:11:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxom03893 for ; Tue, 11 Jan 2000 14:11:23 -0500 (EST) Received: from web3305.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web3305.mail.yahoo.com [204.71.201.147]) id QQhxom15811 for ; Tue, 11 Jan 2000 19:11:22 GMT Message-ID: <20000111191121.5261.qmail@web3305.mail.yahoo.com> Received: from [204.71.42.211] by web3305.mail.yahoo.com; Tue, 11 Jan 2000 11:11:21 PST Date: Tue, 11 Jan 2000 11:11:21 -0800 (PST) From: m lu Subject: source code for mpls? To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi: I just join the group and try to learn mpls. Is there any source code availabe on the net, like gated? TIA -mll __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-mpls@UU.NET Tue Jan 11 14:24:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19137 for ; Tue, 11 Jan 2000 14:24:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxon10015; Tue, 11 Jan 2000 19:23:17 GMT Received: by mail-control.mail.uu.net id QQhxon27762 for mpls-outgoing; Tue, 11 Jan 2000 19:22:47 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxon27742 for ; Tue, 11 Jan 2000 19:22:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxon21584 for ; Tue, 11 Jan 2000 14:22:28 -0500 (EST) Received: from baynet.baynetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20]) id QQhxon09148 for ; Tue, 11 Jan 2000 19:22:27 GMT Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id LAA08238; Tue, 11 Jan 2000 11:21:05 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id OAA15022; Tue, 11 Jan 2000 14:17:44 -0500 (EST) Received: from bubba.engeast (bubba [192.168.136.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id OAA16926; Tue, 11 Jan 2000 14:22:23 -0500 for Received: by bubba.engeast (SMI-8.6/SMI-SVR4) id OAA17154; Tue, 11 Jan 2000 14:22:24 -0500 Date: Tue, 11 Jan 2000 14:22:24 -0500 From: dwilder@baynetworks.com (David Wilder) Message-Id: <200001111922.OAA17154@bubba.engeast> To: m1lu@yahoo.com, mpls@UU.NET Subject: Re: source code for mpls? Sender: owner-mpls@UU.NET Precedence: bulk Hi, Try looking at: www.nortelnetworks.com/mpls This will give you a look at Nortel's CR-LDP source code Dave **************************************************************** Hi: I just join the group and try to learn mpls. Is there any source code availabe on the net, like gated? TIA -mll From owner-mpls@UU.NET Tue Jan 11 15:01:05 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19901 for ; Tue, 11 Jan 2000 15:01:04 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxop09436; Tue, 11 Jan 2000 19:58:13 GMT Received: by mail-control.mail.uu.net id QQhxop01451 for mpls-outgoing; Tue, 11 Jan 2000 19:57:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxop01446 for ; Tue, 11 Jan 2000 19:57:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxop08466 for ; Tue, 11 Jan 2000 14:57:38 -0500 (EST) Received: from web3307.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web3307.mail.yahoo.com [204.71.201.231]) id QQhxop08745 for ; Tue, 11 Jan 2000 19:57:37 GMT Message-ID: <20000111195736.15771.qmail@web3307.mail.yahoo.com> Received: from [204.71.42.211] by web3307.mail.yahoo.com; Tue, 11 Jan 2000 11:57:36 PST Date: Tue, 11 Jan 2000 11:57:36 -0800 (PST) From: m lu Subject: Re: source code for mpls? To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Thanks. i am very gratefull for this. one more question: does anyone build this on freebsd, or solaris? TIA -mll --- David Wilder wrote: > Hi, > > Try looking at: www.nortelnetworks.com/mpls > This will give you a look at Nortel's CR-LDP source > code > > Dave > > **************************************************************** > > Hi: > > I just join the group and try to learn mpls. Is > there > any source code availabe on the net, like gated? > > TIA > > -mll > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-mpls@UU.NET Tue Jan 11 15:56:38 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21011 for ; Tue, 11 Jan 2000 15:56:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxot06304; Tue, 11 Jan 2000 20:55:44 GMT Received: by mail-control.mail.uu.net id QQhxot13340 for mpls-outgoing; Tue, 11 Jan 2000 20:55:04 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxot13328 for ; Tue, 11 Jan 2000 20:54:48 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxot03327 for ; Tue, 11 Jan 2000 15:54:42 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprtp1.ntcom.nortel.net [137.118.22.14]) id QQhxot05175 for ; Tue, 11 Jan 2000 20:54:42 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Tue, 11 Jan 2000 15:53:01 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CL0AZ1KX; Tue, 11 Jan 2000 15:52:57 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CJ8MR8NL; Tue, 11 Jan 2000 15:52:58 -0500 Message-ID: <387B982A.723BE3BC@americasm01.nt.com> Date: Tue, 11 Jan 2000 15:52:58 -0500 From: "Peter Ashwood-Smith" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: source code for mpls? References: <20000111195736.15771.qmail@web3307.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Just to be clear, the code on: www.nortelnetworks.com/mpls Is for the LDP and CR-LDP pdu encoding and decoding only. There are LINUX implementations of LDP/CR-LDP that use these PDUs that are available elsewhere. Cheers, Peter Ashwood-Smith > > Thanks. i am very gratefull for this. > > one more question: does anyone build this on freebsd, > or solaris? > > TIA > > -mll > > --- David Wilder wrote: > > Hi, > > > > Try looking at: www.nortelnetworks.com/mpls > > This will give you a look at Nortel's CR-LDP source > > code > > > > Dave > > > > > **************************************************************** > > > > Hi: > > > > I just join the group and try to learn mpls. Is > > there > > any source code availabe on the net, like gated? > > > > TIA > > > > -mll > > > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com From owner-mpls@UU.NET Tue Jan 11 16:03:34 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21163 for ; Tue, 11 Jan 2000 16:03:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxou11954; Tue, 11 Jan 2000 21:01:26 GMT Received: by mail-control.mail.uu.net id QQhxou14323 for mpls-outgoing; Tue, 11 Jan 2000 21:00:55 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxou14245 for ; Tue, 11 Jan 2000 21:00:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxou03989 for ; Tue, 11 Jan 2000 16:00:37 -0500 (EST) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQhxou00087 for ; Tue, 11 Jan 2000 21:00:37 GMT Received: from lightning.pluris.com (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA07543; Tue, 11 Jan 2000 13:00:36 -0800 (PST) Received: (from akyol@localhost) by lightning.pluris.com (8.9.3/8.8.7) id NAA01056; Tue, 11 Jan 2000 13:00:36 -0800 To: "Peter Ashwood-Smith" Cc: mpls@UU.NET Subject: Re: source code for mpls? References: <20000111195736.15771.qmail@web3307.mail.yahoo.com> <387B982A.723BE3BC@americasm01.nt.com> From: Bora Akyol Date: 11 Jan 2000 13:00:36 -0800 In-Reply-To: "Peter Ashwood-Smith"'s message of "Tue, 11 Jan 2000 15:52:58 -0500" Message-ID: <4p66x0fhmz.fsf@lightning.pluris.com> Lines: 59 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Sender: owner-mpls@UU.NET Precedence: bulk I am glad that you clarified this. Since the PDU decoding and encoding is really one of the easier components of developing an MPLS stack. Bora Akyol Pluris "Peter Ashwood-Smith" writes: > Just to be clear, the code on: > > www.nortelnetworks.com/mpls > > Is for the LDP and CR-LDP pdu encoding and decoding > only. > > There are LINUX implementations of LDP/CR-LDP that > use these PDUs that are available elsewhere. > > Cheers, > > Peter Ashwood-Smith > > > > > Thanks. i am very gratefull for this. > > > > one more question: does anyone build this on freebsd, > > or solaris? > > > > TIA > > > > -mll > > > > --- David Wilder wrote: > > > Hi, > > > > > > Try looking at: www.nortelnetworks.com/mpls > > > This will give you a look at Nortel's CR-LDP source > > > code > > > > > > Dave > > > > > > > > **************************************************************** > > > > > > Hi: > > > > > > I just join the group and try to learn mpls. Is > > > there > > > any source code availabe on the net, like gated? > > > > > > TIA > > > > > > -mll > > > > > __________________________________________________ > > Do You Yahoo!? > > Talk to your friends online with Yahoo! Messenger. > > http://im.yahoo.com From owner-mpls@UU.NET Tue Jan 11 17:09:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22117 for ; Tue, 11 Jan 2000 17:09:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxoy19124; Tue, 11 Jan 2000 22:04:56 GMT Received: by mail-control.mail.uu.net id QQhxoy28564 for mpls-outgoing; Tue, 11 Jan 2000 22:04:15 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxoy28412 for ; Tue, 11 Jan 2000 22:04:01 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxoy24280 for ; Tue, 11 Jan 2000 17:03:51 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhxoy25810 for ; Tue, 11 Jan 2000 22:03:51 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Tue, 11 Jan 2000 17:03:50 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CD95@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Subject: LSP tunnels - support for hierarchies Date: Tue, 11 Jan 2000 17:03:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, There's an RSVP WG draft: draft-ietf-rsvp-tunnel-04.txt, that deals with issues of running RSVP over ip-in-ip tunnels. Some of the problems seem to be relevant to MPLS as well. Can some one clarify the support for setting-up hierarchial LSP's using RSVP ? Other than the not so clear (to me) MPLS Label Switched Path Termination operation subobject - is there some support for this ? Thanx. From owner-mpls@UU.NET Tue Jan 11 17:20:17 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22542 for ; Tue, 11 Jan 2000 17:20:17 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxoz04426; Tue, 11 Jan 2000 22:18:47 GMT Received: by mail-control.mail.uu.net id QQhxoz05159 for mpls-outgoing; Tue, 11 Jan 2000 22:17:59 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxoz05131 for ; Tue, 11 Jan 2000 22:17:51 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxoz12128 for ; Tue, 11 Jan 2000 17:17:47 -0500 (EST) Received: from element.integralaccess.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: server2.integralaccess.com [38.155.16.225]) id QQhxoz03762 for ; Tue, 11 Jan 2000 22:17:47 GMT Received: from akankkunen (192.168.1.229) by element.integralaccess.com (LSMTP Lite for Windows NT v1.1a) with SMTP id <0.B8984400@element.integralaccess.com>; Tue, 11 Jan 2000 17:17:21 -0500 From: "Antti Kankkunen" To: "Thomas Wolfram" Cc: , , Subject: MPLS based DSLAMs Date: Tue, 11 Jan 2000 17:18:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thomas and others, a related comment below. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas > Wolfram > Sent: Saturday, January 08, 2000 7:05 AM > To: mpls@UU.NET; vompls@lists.integralaccess.com > Subject: RE: prime time MPLS/fiber > > But I think if you would want to use framed MPLS to replace > cell ATM in an xDSL access network extending MPLS to the CPE > could make sense. There the CPE isn't connected directly to the > operator LSR having all the internet routes anyway. Perhaps > several hundred CPEs are connected to DSLAMs and you have > perhaps the LERs of several ISPs connected to the PoP. You > could also have other service gateways connected to the > PoP. All these ISP LERs route into the internet, i.e. to the > same set of destinations. You wouldn't use MPLS on the local > loop to pre-label the packets for transport through the core > network but through the access network. By using different labels > the customer could even choose to send different traffic to > the same destination via different ISPs though he has only > one physical xDSL link. > I.e. I think you could use MPLS for the same purpose ATM is > used in the access networks today. > There is already some effort in progress to address the kinds of applications you describe above. In their Paris meeting early February, the DSL Forum will hold a BOF session on MPLS and its relevance to the DSL/DSLAM architectures being addressed in the DSL Forum set of recommendations. Please see http://www.adsl.com/adsl_forum.html (Click on Meetings & Events / Meeting Information) You need to be a DSL Forum member to attend the BOF session. The session is held on the evening of either 2/9 or 2/10. Below please find a quote from an e-mail from Greg Wetzel of Covad describing the BOF session. ===Beginning of quote from Greg Wetzel== The technical committee chair, Gavin Young, agreed just last week to hold a BoF on MPLS at the technical committee meeting in Paris. It will be chaired by Martin Jackson, a member of the DSL Forum board of directors. The BoF will be either Wed or Thu evening from 5:30-7:30pm. An agenda will be forthcoming shortly, but will include a 45 min MPLS tutorial from David Allan, Nortel, chair of the Architecture Working Group, and an hour on the discussion of how MPLS fits into the DSL Forum set of recommendations. ===End of quote==================== Best regards, Antti K. From owner-mpls@UU.NET Tue Jan 11 18:23:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23146 for ; Tue, 11 Jan 2000 18:23:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxpd29661; Tue, 11 Jan 2000 23:22:10 GMT Received: by mail-control.mail.uu.net id QQhxpd17829 for mpls-outgoing; Tue, 11 Jan 2000 23:21:40 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxpd17819 for ; Tue, 11 Jan 2000 23:21:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxpd00379 for ; Tue, 11 Jan 2000 18:21:33 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxpd10102 for ; Tue, 11 Jan 2000 23:21:32 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA22285; Tue, 11 Jan 2000 15:20:57 -0800 (PST) Message-Id: <4.2.2.20000112101305.00a936e0@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Jan 2000 10:20:44 +1100 To: Juha Heinanen From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <14458.60597.806988.344161@lohi.eng.telia.fi> References: <4.2.2.20000111091834.00a9ca20@farley.cisco.com> <4.2.2.20000110222653.00a91b20@farley.cisco.com> <4.2.2.20000110190615.00a8c3b0@farley.cisco.com> <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> <4.2.2.20000108174032.00a931d0@farley.cisco.com> <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000111091834.00a9ca20@farley.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Juha, I agree with some of your responses about LDP procedures, and disagree with others. However I think the key point is this: At 10:41 01/11/2000 +0200, Juha Heinanen wrote: >Jeremy Lawrence writes: [...] > > Curtis has just pointed out that the problem can be dealt with > > by using an explicitly routed LSP rather than LDP. That seems > > more sensible than modifying LDP to deal with all this mess. > >it doesn't sound realistic to me that the cpe lsr would know or care >about any explicit routes. It isn't, but the mechanisms for explicit routing do exactly what is required here. A loose source routed LSP from the CPE to a.b.c.d/32 (so "loose" that no intermediate hops are specified at all) does exactly what is required, without requiring any modification to LDP, and without requiring any information at the CPE other than the address a.b.c.d/32. Regards, Jeremy Lawrence From owner-mpls@UU.NET Tue Jan 11 18:46:34 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23329 for ; Tue, 11 Jan 2000 18:46:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxpe27840; Tue, 11 Jan 2000 23:44:54 GMT Received: by mail-control.mail.uu.net id QQhxpe19219 for mpls-outgoing; Tue, 11 Jan 2000 23:44:00 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxpe19213 for ; Tue, 11 Jan 2000 23:43:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxpe19867 for ; Tue, 11 Jan 2000 18:43:43 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhxpe26856 for ; Tue, 11 Jan 2000 23:43:43 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA26199; Tue, 11 Jan 2000 15:31:07 -0800 (PST) Message-Id: <4.2.2.20000112102210.00a88370@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Jan 2000 10:30:55 +1100 To: "David Allan" From: Jeremy Lawrence Subject: RE: prime time MPLS/fiber Cc: mpls@UU.NET, vompls@lists.integralaccess.com In-Reply-To: <6DDA62170439D31185750000F80826AC0126E825@zmerd004.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk David, At 11:54 01/11/2000 -0600, David Allan wrote: [...] >I understand what you are saying, my suggestion is that MPLS transport be extended to the CPE but classification be distributed between the CPE and the operator LSR, hence traffic on 0.0.0.0/0 best effort cannot be directly forwarded without re-classification by a box with more authoritative knowledge of the routes. Well, you could deal with this by the method that Juha suggests, which is to forward the traffic on an LSP established to w.x.y.z/32, which is the (say) loopback address of the operator LSR, instead of 0.0.0.0/0? That way, the operator LSR would examine the IP packets that come out the LSP, and forward them appropriately. (It may be better, though, to simply forward unlabelled IP packets to the operator LSR.) Regards, Jeremy Lawrence From owner-mpls@UU.NET Tue Jan 11 22:48:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26741 for ; Tue, 11 Jan 2000 22:48:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxpv18662; Wed, 12 Jan 2000 03:48:18 GMT Received: by mail-control.mail.uu.net id QQhxpv06643 for mpls-outgoing; Wed, 12 Jan 2000 03:47:43 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxpv06632 for ; Wed, 12 Jan 2000 03:47:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxpv10572 for ; Tue, 11 Jan 2000 22:47:16 -0500 (EST) Received: from metconnect.ixc-comm.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ixcfw1.ixc-comm.com [38.244.111.5]) id QQhxpv18086 for ; Wed, 12 Jan 2000 03:47:16 GMT Received: by metconnect.ixc-comm.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jan 2000 20:56:29 -0600 Message-ID: From: "Johnson, Robert (Broadwing)" To: "'J. Noel Chiappa'" , mpls@UU.NET Subject: RE: prime time MPLS/fiber Date: Tue, 11 Jan 2000 21:00:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Noel, I apologize for not answering your question sooner and, fundamentally, I agree with your argument. A core LSR should not be responsible for operating an adaptation layer to support services that cannot deal with the loss or reordering of packets. However, I disagree with the focus of your argument, which is on packet-based services. If a service is not packet-based, but is being packetized to ride an MPLS network, then adaptation layers must be defined to provide those facilities. Either that, or the idea that non-packet-based services can be adapted to an MPLS network should be dismissed out-of-hand. I am compliant with either approach. Robert Johnson From owner-mpls@UU.NET Wed Jan 12 01:37:09 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00585 for ; Wed, 12 Jan 2000 01:37:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxqg22588; Wed, 12 Jan 2000 06:36:38 GMT Received: by mail-control.mail.uu.net id QQhxqg09757 for mpls-outgoing; Wed, 12 Jan 2000 06:36:06 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxqg09703 for ; Wed, 12 Jan 2000 06:35:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxqg21789 for ; Wed, 12 Jan 2000 01:35:51 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQhxqg24771 for ; Wed, 12 Jan 2000 06:35:50 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id IAA14172; Wed, 12 Jan 2000 08:35:39 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14460.8379.395865.292765@lohi.eng.telia.fi> Date: Wed, 12 Jan 2000 08:35:39 +0200 (EET) To: Jeremy Lawrence Cc: mpls@UU.NET, vompls@lists.integralaccess.com Subject: RE: prime time MPLS/fiber In-Reply-To: <4.2.2.20000112101305.00a936e0@farley.cisco.com> References: <4.2.2.20000111091834.00a9ca20@farley.cisco.com> <4.2.2.20000110222653.00a91b20@farley.cisco.com> <4.2.2.20000110190615.00a8c3b0@farley.cisco.com> <4.2.2.20000110130922.00a7f6d0@farley.cisco.com> <4.2.2.20000108174032.00a931d0@farley.cisco.com> <4.2.2.20000107112802.00a893e0@farley.cisco.com> <4.2.2.20000106094859.00a84cf0@farley.cisco.com> <336ECDAFDF7DD311B9E30090277AEE413514FA@nt-exchange-bby.pmc -sierra.bc.ca> <4.2.2.20000112101305.00a936e0@farley.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeremy Lawrence writes: > It isn't, but the mechanisms for explicit routing do exactly what > is required here. A loose source routed LSP from the CPE to a.b.c.d/32 > (so "loose" that no intermediate hops are specified at all) does > exactly what is required, without requiring any modification to LDP, > and without requiring any information at the CPE other than the > address a.b.c.d/32. this is fine with me. -- juha From owner-mpls@UU.NET Wed Jan 12 06:41:57 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12220 for ; Wed, 12 Jan 2000 06:41:56 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxra07817; Wed, 12 Jan 2000 11:41:02 GMT Received: by mail-control.mail.uu.net id QQhxra06275 for mpls-outgoing; Wed, 12 Jan 2000 11:40:28 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxra06268 for ; Wed, 12 Jan 2000 11:40:24 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxra14813 for ; Wed, 12 Jan 2000 06:40:15 -0500 (EST) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQhxra07256 for ; Wed, 12 Jan 2000 11:40:14 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12107; Wed, 12 Jan 2000 06:40:13 -0500 (EST) Message-Id: <200001121140.GAA12107@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-git-uus-04.txt Date: Wed, 12 Jan 2000 06:40:13 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol Author(s) : M. Suzuki Filename : draft-ietf-mpls-git-uus-04.txt Pages : 25 Date : 11-Jan-00 The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS- sensitive session transfers over ATM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-git-uus-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-git-uus-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-git-uus-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: <20000111095825.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-git-uus-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-git-uus-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000111095825.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 12 10:42:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17945 for ; Wed, 12 Jan 2000 10:42:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxrp23047; Wed, 12 Jan 2000 15:19:28 GMT Received: by mail-control.mail.uu.net id QQhxrp22923 for mpls-outgoing; Wed, 12 Jan 2000 15:18:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxrp22885 for ; Wed, 12 Jan 2000 15:18:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxrp29957 for ; Wed, 12 Jan 2000 10:18:36 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhxrp24439 for ; Wed, 12 Jan 2000 15:18:36 GMT Received: from jsullivan.quarrytech.com (JSULLIVAN [10.1.1.202]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10) id Z9CT2SFD; Wed, 12 Jan 2000 10:18:34 -0500 Message-Id: <3.0.32.20000112101242.00718e68@qtech1> X-Sender: jims@qtech1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 Jan 2000 10:12:42 -0500 To: mpls@UU.NET From: Jim Sullivan Subject: using MPLS for protection switching Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk In several threads people have mentioned using MPLS for protection switching. Can someone tell me what this is ? Is there a specification that describes it ? Thanks Jim From owner-mpls@UU.NET Wed Jan 12 10:44:20 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17970 for ; Wed, 12 Jan 2000 10:44:20 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxrq10008; Wed, 12 Jan 2000 15:41:34 GMT Received: by mail-control.mail.uu.net id QQhxrq25582 for mpls-outgoing; Wed, 12 Jan 2000 15:40:55 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache01.uu.net [153.39.49.42]) id QQhxrq25569 for ; Wed, 12 Jan 2000 15:40:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxrq06325 for ; Wed, 12 Jan 2000 10:40:28 -0500 (EST) Received: from phoenix.ficon-tech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: phoenix.ficon-tech.com [209.125.90.2]) id QQhxrq09166 for ; Wed, 12 Jan 2000 15:40:26 GMT Received: from ficon-tech.com (192.168.137.202) by phoenix.ficon-tech.com (Worldmail 1.3.167); 12 Jan 2000 10:48:44 -0500 Message-ID: <387CA064.E1D866ED@ficon-tech.com> Date: Wed, 12 Jan 2000 10:40:20 -0500 From: Rohit Chhapolia Organization: Ficon Technology X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: MPLS WG Subject: RSVP: Wrong label in RESV message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit A question on rsvp-tunnels: When a node receives RESV message from downstream node containing label value which is either not of the same type as requested or does not fall in the range requested (possible if downstream LSR has some implementation problem), what action should it take? If it should send Resv Err message to signify this error, there should be an error code assigned for it. Rohit -- Rohit Chhapolia Ficon Technology, Inc. mailto:rohit@ficon-tech.com http://www.ficon-tech.com From owner-mpls@UU.NET Wed Jan 12 11:06:17 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18322 for ; Wed, 12 Jan 2000 11:06:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxrs26009; Wed, 12 Jan 2000 16:04:36 GMT Received: by mail-control.mail.uu.net id QQhxrs29226 for mpls-outgoing; Wed, 12 Jan 2000 16:04:02 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxrs29194 for ; Wed, 12 Jan 2000 16:03:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxrs08883 for ; Wed, 12 Jan 2000 11:03:55 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQhxrs25291 for ; Wed, 12 Jan 2000 16:03:54 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Wed, 12 Jan 2000 10:03:27 -0600 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CL0A65FG; Wed, 12 Jan 2000 11:03:26 -0500 Received: from americasm01.nt.com (pkpky01p.ca.nortel.com [47.125.48.162]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CY2DKWWK; Wed, 12 Jan 2000 11:03:24 -0500 Message-ID: <387CA545.A010B336@americasm01.nt.com> Date: Wed, 12 Jan 2000 11:01:10 -0500 From: "Stephen Shew" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Sullivan CC: mpls@UU.NET Subject: Re: using MPLS for protection switching References: <3.0.32.20000112101242.00718e68@qtech1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit There are a number of I-Ds that discuss aspects of protection using MPLS. These include: Broadly speaking, there are two types of protection mechanisms: protecting an LSP at a time, or protecting a link over which multiple LSPs are being carried. Jim Sullivan wrote: > In several threads people have mentioned using MPLS for > protection switching. Can someone tell me what this is ? > Is there a specification that describes it ? > Thanks Jim -- Stephen Shew Voice: 613-763-2462 Fax: 613-765-3165 Nortel - Carrier Packet Solutions email: sdshew@nortelnetworks.com P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 From owner-mpls@UU.NET Wed Jan 12 11:11:53 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18430 for ; Wed, 12 Jan 2000 11:11:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxrs28434; Wed, 12 Jan 2000 16:09:39 GMT Received: by mail-control.mail.uu.net id QQhxrs01607 for mpls-outgoing; Wed, 12 Jan 2000 16:09:02 GMT Received: from gen1.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen1.ffx.ops.us.uu.net [153.39.49.41]) id QQhxrs01542 for ; Wed, 12 Jan 2000 16:08:54 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxrs09422 for ; Wed, 12 Jan 2000 11:07:48 -0500 (EST) Received: from palrel3.hp.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: palrel3.hp.com [156.153.255.226]) id QQhxrs26858 for ; Wed, 12 Jan 2000 16:07:47 GMT Received: from hpqt0791.sqf.hp.com (hpqt0791.sqf.hp.com [15.144.189.176]) by palrel3.hp.com (Postfix) with ESMTP id 44A0814E for ; Wed, 12 Jan 2000 08:07:46 -0800 (PST) Received: from sqf.hp.com (niallb@localhost [127.0.0.1]) by hpqt0791.sqf.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.3 TIS 5.0) id QAA22019 for ; Wed, 12 Jan 2000 16:06:48 GMT Message-ID: <387CA698.D046C57E@sqf.hp.com> Date: Wed, 12 Jan 2000 16:06:48 +0000 From: Niall Brown Reply-To: Niall_Brown@agilent.com Organization: Agilent Tecnologies X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/785) X-Accept-Language: en-GB,gd,fi MIME-Version: 1.0 To: mpls@UU.NET Subject: remove Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From owner-mpls@UU.NET Wed Jan 12 11:35:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19120 for ; Wed, 12 Jan 2000 11:34:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxru13740; Wed, 12 Jan 2000 16:32:01 GMT Received: by mail-control.mail.uu.net id QQhxru08591 for mpls-outgoing; Wed, 12 Jan 2000 16:31:27 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxru08555 for ; Wed, 12 Jan 2000 16:31:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxru12367 for ; Wed, 12 Jan 2000 11:31:10 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQhxru12927 for ; Wed, 12 Jan 2000 16:31:09 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Wed, 12 Jan 2000 10:30:44 -0600 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C3GKB12H; Wed, 12 Jan 2000 11:30:41 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CJ8MR0GV; Wed, 12 Jan 2000 11:30:41 -0500 Message-ID: <387CAC31.8AD41E4F@americasm01.nt.com> Date: Wed, 12 Jan 2000 11:30:41 -0500 From: "Peter Ashwood-Smith" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: using MPLS for protection switching References: <3.0.32.20000112101242.00718e68@qtech1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jim Sullivan wrote: > > In several threads people have mentioned using MPLS for > protection switching. Can someone tell me what this is ? > Is there a specification that describes it ? > Thanks Jim The basic concept is to use another MPLS tunnel to backup either 1 or many other MPLS tunnels. This can be done with a hot standby that either maps one to one or one to many with the backed up tunnels. If one implements a backup so that it protects a single or small number of hops of a longer LSP, you have something similar to protection switching. In essense MPLS gives you the possibility to implement a whole range of backup strategies from local segment 1:n backup (similar to protection switching) all the way up to 1:1 end to end backup. There have been a couple of drafts proposing mechanisms to do this and a draft that proposes a framework for these mechanisms. Cheers, Peter Ashwood-Smith From owner-mpls@UU.NET Wed Jan 12 14:04:22 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22038 for ; Wed, 12 Jan 2000 14:04:19 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxse26884; Wed, 12 Jan 2000 19:00:07 GMT Received: by mail-control.mail.uu.net id QQhxsd08483 for mpls-outgoing; Wed, 12 Jan 2000 18:59:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxsd08468 for ; Wed, 12 Jan 2000 18:59:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxsd22289 for ; Wed, 12 Jan 2000 13:59:09 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhxsd00164 for ; Wed, 12 Jan 2000 18:59:04 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Wed, 12 Jan 2000 13:59:02 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CD9B@email.quarrytech.com> From: "Abes, Andi" To: "Abes, Andi" , MPLS mailing list Subject: Explicit route operations in RSVP Date: Wed, 12 Jan 2000 13:59:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi again, I guess the original question was kind of cryptic.... The draft-ietf-mpls-rsvp-lsp-tunnel-04 draft contains an operation sub-object in the Explict route. This is part of the Path message traveling from the Sender (ingress) of the "to be setup" tunnel towards the Reciver (egress). Section 4.3.4.1. 3) says: " If the subobject is an operation subobject, the node pops the subobject from the EXPLICIT ROUTE object , records the subobject, and continues processing with step 2, above. " This leaves me with the following questions: What are the processing rules for this sub-object ? In what scenario will this option be used ? TIA, Andi -----Original Message----- From: Abes, Andi [mailto:aabes@quarrytech.com] Sent: Monday, January 10, 2000 2:42 PM To: MPLS mailing list Subject: MPLS termination action sub-object in ERO for RSVP hi, I'm a little confused about the use of the LSP termination sub-object in the explicit route object and the allocation of multi-level labels using RSVP. 1. Who decides to allocate a higher level label ? a. the egress point ? - this will help it identify the ultimate destination assuming the LSP is part of a tunnel. b. An intermediate node that performed a merge - this will allow the various flows to be uniquely identified using the second level label ? in this case how will the upper label be negotiated with the next hop ? c. Any other contenders ? 2. How is the "LSP Termination" object is used ? Since it can only appear as part of an ERO, and hence only from the ingress - what is the expected treatment by the receiving node - the one identified in the ERO ? Is it expected that the receiving node realize it has to assign more than the top label ? is it some kind of "penultimate-hop-pop" mechanism ? Thanx, Andi. From owner-mpls@UU.NET Wed Jan 12 17:18:17 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25764 for ; Wed, 12 Jan 2000 17:18:16 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxsq11125; Wed, 12 Jan 2000 22:14:52 GMT Received: by mail-control.mail.uu.net id QQhxsq25389 for mpls-outgoing; Wed, 12 Jan 2000 22:14:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxsq25309 for ; Wed, 12 Jan 2000 22:13:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxsq16544 for ; Wed, 12 Jan 2000 17:13:47 -0500 (EST) Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQhxsq10320 for ; Wed, 12 Jan 2000 22:13:47 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jan 2000 17:12:47 -0500 Message-ID: From: "Kullberg, Alan" To: "'mpls@uu.net'" Subject: LDP MIB update? Date: Wed, 12 Jan 2000 17:12:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk When is the next revision of the LDP MIB draft expected to be released? Thanks, Alan From owner-mpls@UU.NET Wed Jan 12 18:50:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26961 for ; Wed, 12 Jan 2000 18:50:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxsx04898; Wed, 12 Jan 2000 23:46:56 GMT Received: by mail-control.mail.uu.net id QQhxsx10966 for mpls-outgoing; Wed, 12 Jan 2000 23:46:19 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxsx10946 for ; Wed, 12 Jan 2000 23:46:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxsx26137 for ; Wed, 12 Jan 2000 18:46:04 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQhxsx06460 for ; Wed, 12 Jan 2000 23:46:04 GMT Received: by BRIXCORP2 with Internet Mail Service (5.5.1960.3) id ; Wed, 12 Jan 2000 18:44:06 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB0CE20E@BRIXCORP2> From: Joan Cucchiara To: "'Kullberg, Alan'" , "'mpls@uu.net'" Subject: RE: LDP MIB update? Date: Wed, 12 Jan 2000 18:44:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Alan, Should be by the end of this month. -Joan > -----Original Message----- > From: Kullberg, Alan [mailto:akullber@hjinc.com] > Sent: Wednesday, January 12, 2000 5:13 PM > To: 'mpls@uu.net' > Subject: LDP MIB update? > > > When is the next revision of the LDP MIB draft expected to be > released? > > Thanks, > > Alan > From owner-mpls@UU.NET Wed Jan 12 20:50:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27700 for ; Wed, 12 Jan 2000 20:50:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxtf27150; Thu, 13 Jan 2000 01:47:55 GMT Received: by mail-control.mail.uu.net id QQhxtf04407 for mpls-outgoing; Thu, 13 Jan 2000 01:47:19 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxtf04398 for ; Thu, 13 Jan 2000 01:47:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxtf06008 for ; Wed, 12 Jan 2000 20:47:04 -0500 (EST) Received: from infer.nal.ecl.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: infer.nal.ecl.net [163.138.70.32]) id QQhxtf20168 for ; Thu, 13 Jan 2000 01:46:59 GMT Received: by infer.nal.ecl.net (8.9.3/eclnet*nal.mx4) with TCP; Thu, 13 Jan 2000 10:46:57 +0900 (JST) Message-Id: <200001130146.KAA21629@infer.nal.ecl.net> To: mpls@UU.NET Subject: Re: I-D ACTION:draft-ietf-mpls-git-uus-04.txt Date: Thu, 13 Jan 2000 10:46:57 +0900 From: Muneyoshi Suzuki Sender: owner-mpls@UU.NET Precedence: bulk Dear, I submitted draft-ietf-mpls-git-uus-03.txt which is the replacement of draft-ietf-mpls-git-uus-03.txt. There is no technical changes but based on the IESG review, ST2+ related identifiers are moved to the appendix. Thanks, M.Suzuki > --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 : The Assignment of the Information Field and Protocol > Identifier in the Q.2941 Generic Identifier and Q.295 > 7 > User-to-user Signaling for the Internet Protocol > Author(s) : M. Suzuki > Filename : draft-ietf-mpls-git-uus-04.txt > Pages : 25 > Date : 11-Jan-00 > From owner-mpls@UU.NET Thu Jan 13 07:50:44 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16965 for ; Thu, 13 Jan 2000 07:50:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxux07434; Thu, 13 Jan 2000 12:49:35 GMT Received: by mail-control.mail.uu.net id QQhxux10536 for mpls-outgoing; Thu, 13 Jan 2000 12:49:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxux10522 for ; Thu, 13 Jan 2000 12:48:50 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxux15660 for ; Thu, 13 Jan 2000 07:48:40 -0500 (EST) Received: from smtp2.cluster.oleane.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.cluster.oleane.net [195.25.12.17]) id QQhxux04409 for ; Thu, 13 Jan 2000 12:48:39 GMT Received: from oleane (dyn-1-1-028.Vin.dialup.oleane.fr [195.25.4.28]) by smtp2.cluster.oleane.net with SMTP id NAA35249; Thu, 13 Jan 2000 13:48:12 +0100 (CET) Message-ID: <001001bf5dc4$19ddc240$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS Forum Date: Thu, 13 Jan 2000 13:45:31 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01BF5DCC.758AB780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BF5DCC.758AB780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The MPLS Forum will stand in Paris next 7-10 March. Reports from real deployments, standard progress issues, technical propositions, debate: building the next IP architecture. Get details at: www.upperside.fr/mplsforum.htm ------=_NextPart_000_000D_01BF5DCC.758AB780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The MPLS = Forum will stand=20 in Paris next 7-10 March. Reports from real
deployments, standard = progress=20 issues, technical propositions, debate:
building the next IP=20 architecture.
Get details at:
www.upperside.fr/mplsforum= .htm
 
 
------=_NextPart_000_000D_01BF5DCC.758AB780-- From owner-mpls@UU.NET Thu Jan 13 14:06:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23961 for ; Thu, 13 Jan 2000 14:06:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxvw23881; Thu, 13 Jan 2000 19:03:18 GMT Received: by mail-control.mail.uu.net id QQhxvw29655 for mpls-outgoing; Thu, 13 Jan 2000 19:02:41 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxvw29487 for ; Thu, 13 Jan 2000 19:02:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxvw01300 for ; Thu, 13 Jan 2000 14:02:24 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQhxvw19701 for ; Thu, 13 Jan 2000 19:02:24 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id OAA18675; Thu, 13 Jan 2000 14:02:22 -0500 Date: Thu, 13 Jan 2000 14:02:22 -0500 From: "J. Noel Chiappa" Message-Id: <200001131902.OAA18675@ginger.lcs.mit.edu> To: Robert.Johnson@broadwing.com, mpls@UU.NET Subject: RE: prime time MPLS/fiber Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: "Johnson, Robert (Broadwing)" > A core LSR should not be responsible for operating an adaptation layer > to support services that cannot deal with the loss or reordering of > packets. Concur. Too much extra complexity to be worth it. > I disagree with the focus of your argument, which is on packet-based > services. If a service is not packet-based, but is being packetized to > ride an MPLS network, then adaptation layers must be defined to provide > those facilities. I don't necessarily disagree with that. (One can think of TCP as an adaption layer that synthesizes a reliable stream facility out of an unreliable packet service.) The two places I might branch out are: - Whether, if one needs a reliable service, it makes sense to define a separate MPLS-only facility to do that. If you need reliability, and it's going to be basically end-end (even if it's provided by an access box, and not the actual end user), you're going to need sequence numbers, time-outs, retransmits, etc - and if you've got all that, why not just use TCP, or some similar internetwork service? (Long analysis of pros and cons of MPLS-specific, versus IP-based approachs elided - not enough energy to type it all in.) - The problem with doing reliability on a basically end-end basis is it might conflict with timing requirements. E.g. if you have a real-time application, in which timely delivery of data is important, you might not be able to stand an end-end roundtrip to pick up missing data. And using a long playback buffer to hide such delay variance might run afoul of overall delay budgets. It's at that point that doing reliability in the switches in the middle (i.e. a packet lost in the network is replicated from a preceding switch) starts to look better. However, there are sometimes ways around this, e.g. depending on what %-age of overall traffic this application is, and how critical it is that you really, really get the data. For example, (and this is really simplistic) I might send all data three times, using a sliding window: e.g. packet 1 contains data blocks D, E, F; packet 2 contains E, F, G; packet 3 contains F, G, H. A much smaller playback buffer will allow you to smooth out the data stream over any missing packets, and it takes 3 losses in a row to lose a data block completely. If this traffic is a small %-age of the overall traffic, such a scheme is probably more cost-effective overall than requiring per-switch packet reliability (by local replication). Depending on the exact details of the application, other schemes (different in detail, but similar in spirit) might work for them. > Either that, or the idea that non-packet-based services can be adapted > to an MPLS network should be dismissed out-of-hand. I think that's excessive. As I indicated, TCP is not (to the user) a "packet based service". However, the exact requirements of such services need to be quantified before it can be ascertained whether it can be supported on an MPLS fabric. I would argue, though, that anything you can support on basic MPLS should be supportable on IP+QoS, and in fact it would be preferable to do the latter. (Why limit the scope of such a new service to MPLS fabric, when it could *potentially* operate over the whole Internet, if transmission fabric with the right data-carrying attributes are available?) Noel From owner-mpls@UU.NET Thu Jan 13 17:38:15 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26003 for ; Thu, 13 Jan 2000 17:38:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxwj09789; Thu, 13 Jan 2000 22:21:27 GMT Received: by mail-control.mail.uu.net id QQhxwj14527 for mpls-outgoing; Thu, 13 Jan 2000 22:21:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxwj14439 for ; Thu, 13 Jan 2000 22:20:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxwj02222 for ; Thu, 13 Jan 2000 17:20:37 -0500 (EST) Received: from smtp.adtech-inc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.adtech-inc.com [192.216.50.164]) id QQhxwj09126 for ; Thu, 13 Jan 2000 22:20:36 GMT Received: from wormhole ([192.168.1.1]) by smtp.adtech-inc.com (8.9.3/8.9.3) with SMTP id MAA14899 for ; Thu, 13 Jan 2000 12:21:40 -1000 Received: by MGMGRAND with Internet Mail Service (5.5.2650.21) id ; Thu, 13 Jan 2000 12:20:33 -1000 Message-ID: From: "Nava.Zvaig" To: mpls@UU.NET Subject: independent vs ordered Date: Thu, 13 Jan 2000 12:20:33 -1000 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 Where, or how, are independent and ordered label distribution contol modes defined? Thanks, Nava From owner-mpls@UU.NET Thu Jan 13 17:51:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26068 for ; Thu, 13 Jan 2000 17:51:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxwl12452; Thu, 13 Jan 2000 22:49:29 GMT Received: by mail-control.mail.uu.net id QQhxwl17418 for mpls-outgoing; Thu, 13 Jan 2000 22:49:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxwl17413 for ; Thu, 13 Jan 2000 22:49:01 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxwl08442 for ; Thu, 13 Jan 2000 17:48:52 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQhxwl11904 for ; Thu, 13 Jan 2000 22:48:51 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 13 Jan 2000 22:48:47 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FEDE@monk.datcon.co.uk> From: Adrian Farrel To: "Nava.Zvaig" , mpls@UU.NET Subject: RE: independent vs ordered Date: Thu, 13 Jan 2000 22:33:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Nava, Look at section 4.12 of "A Framework for Multiprotocol Label Switching" Also 3.19 of "Multiprotocol Label Switching Architecture" Cheers, Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Nava.Zvaig [mailto:NZvaig@adtech-inc.com] >Sent: Thursday, January 13, 2000 10:21 PM >To: mpls@UU.NET >Subject: independent vs ordered > > > >Where, or how, are independent and ordered label distribution >contol modes >defined? > >Thanks, >Nava > From owner-mpls@UU.NET Thu Jan 13 19:22:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26656 for ; Thu, 13 Jan 2000 19:22:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxwr06766; Fri, 14 Jan 2000 00:18:16 GMT Received: by mail-control.mail.uu.net id QQhxwr08067 for mpls-outgoing; Fri, 14 Jan 2000 00:17:38 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxwr08039 for ; Fri, 14 Jan 2000 00:17:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxwr17495 for ; Thu, 13 Jan 2000 19:17:15 -0500 (EST) Received: from smtp.adtech-inc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.adtech-inc.com [192.216.50.164]) id QQhxwr05960 for ; Fri, 14 Jan 2000 00:17:15 GMT Received: from wormhole ([192.168.1.1]) by smtp.adtech-inc.com (8.9.3/8.9.3) with SMTP id OAA15902; Thu, 13 Jan 2000 14:18:16 -1000 Received: by MGMGRAND with Internet Mail Service (5.5.2650.21) id ; Thu, 13 Jan 2000 14:17:09 -1000 Message-ID: From: "Nava.Zvaig" To: Adrian Farrel , mpls@UU.NET Subject: RE: independent vs ordered Date: Thu, 13 Jan 2000 14:16:59 -1000 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 How is an LSR defined to be independent or ordered? Is there a standard way or is it proprietary for each router? -----Original Message----- From: Adrian Farrel [mailto:AF@datcon.co.uk] Sent: Thursday, January 13, 2000 12:34 PM To: Nava.Zvaig; mpls@UU.NET Subject: RE: independent vs ordered Nava, Look at section 4.12 of "A Framework for Multiprotocol Label Switching" Also 3.19 of "Multiprotocol Label Switching Architecture" Cheers, Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Nava.Zvaig [mailto:NZvaig@adtech-inc.com] >Sent: Thursday, January 13, 2000 10:21 PM >To: mpls@UU.NET >Subject: independent vs ordered > > > >Where, or how, are independent and ordered label distribution >contol modes >defined? > >Thanks, >Nava > From owner-mpls@UU.NET Thu Jan 13 19:46:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26784 for ; Thu, 13 Jan 2000 19:46:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxws23984; Fri, 14 Jan 2000 00:44:39 GMT Received: by mail-control.mail.uu.net id QQhxws10239 for mpls-outgoing; Fri, 14 Jan 2000 00:44:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxws10231 for ; Fri, 14 Jan 2000 00:43:52 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxws19531 for ; Thu, 13 Jan 2000 19:43:37 -0500 (EST) Received: from panther.cs.ucla.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: Panther.CS.UCLA.EDU [131.179.128.25]) id QQhxws10296 for ; Fri, 14 Jan 2000 00:43:22 GMT Received: from localhost (dubrovsk@localhost) by panther.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id QAA05907 for ; Thu, 13 Jan 2000 16:43:13 -0800 (PST) Date: Thu, 13 Jan 2000 16:43:13 -0800 (PST) From: Alex Dubrovsky To: mpls@UU.NET Subject: Using MPLS in LAN environment Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I had a few questions regarding taking advantage of MPLS functionality from a LAN server: 1) Does it make sense to run MPLS from a LAN environment? 2) Let's assume I have a server which sits behind the MPLS capable ingress router, is it possible for that particular server to run LDP and request Label Mappings from the ingress router, then connect to an MPLS capable LDP peer in the core of the network and request specific label mappings and then finally to stack 2 labels on top of each other accrdingly and thus create "Loose" LSP which would follow through the 2 routers my server exchanged label information with? Also would I be able to initiate CR-LDP from that server? 3) Do ingress MPLS routers have functionality where they would understand sourcerouted IP packets (LSRR for instance) and will setup label bindings accordingly? Any help would be appreciated Thanks, -Alex From owner-mpls@UU.NET Thu Jan 13 22:23:00 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28548 for ; Thu, 13 Jan 2000 22:23:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxxd10704; Fri, 14 Jan 2000 03:21:06 GMT Received: by mail-control.mail.uu.net id QQhxxd13344 for mpls-outgoing; Fri, 14 Jan 2000 03:20:27 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxxd13308 for ; Fri, 14 Jan 2000 03:20:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxxd05380 for ; Thu, 13 Jan 2000 22:20:08 -0500 (EST) Received: from mailhost.auckland.ac.nz by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.auckland.ac.nz [130.216.1.4]) id QQhxxd09868 for ; Fri, 14 Jan 2000 03:20:06 GMT Received: from staffdata.auckland.ac.nz (staffdata.business.auckland.ac.nz [130.216.97.241]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id QAA17354 for ; Fri, 14 Jan 2000 16:20:00 +1300 (NZDT) Received: by staffdata.business.auckland.ac.nz with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 16:19:20 +1300 Message-ID: From: "Surujpal, Sunil" To: "'mpls@UU.net'" Subject: LDP/CR-LDP and RSVP implementations Date: Fri, 14 Jan 2000 16:19:19 +1300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi All I was wondering if someone could refer me to implementations of LDP/CR-LDP or RSVP that i could get material on. Thanks Sunil From owner-mpls@UU.NET Thu Jan 13 23:18:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29784 for ; Thu, 13 Jan 2000 23:18:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxxg04083; Fri, 14 Jan 2000 04:05:24 GMT Received: by mail-control.mail.uu.net id QQhxxg17589 for mpls-outgoing; Fri, 14 Jan 2000 04:04:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhxxg17534 for ; Fri, 14 Jan 2000 04:04:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxxg08331 for ; Thu, 13 Jan 2000 23:04:34 -0500 (EST) Received: from www.netlabs.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: www.netlabs.net [216.116.128.3]) id QQhxxg13895 for ; Fri, 14 Jan 2000 04:04:34 GMT Received: from blhoreckpc (arni.netlabs.net [216.116.143.247]) by www.netlabs.net (8.9.3/8.9.3) with SMTP id XAA18797; Thu, 13 Jan 2000 23:04:22 -0500 (EST) Message-ID: <00e501bf5e44$dc111f80$0200a8c0@blhoreckpc> From: "Arni Raghu" To: "Surujpal, Sunil" , "'mpls@UU.net'" References: Subject: Re: LDP/CR-LDP and RSVP implementations Date: Thu, 13 Jan 2000 23:07:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ftp://nero.doit.wisc.edu/pub/mpls/ for the ldp version..no idea about the rsvp extensions version..It was on Jim's todo list though.. There is a freebsd version also... http://www.antd.nist.gov/itg/nistswitch/ I think this one only uses the rsvp extensions...though I never tried it hth, A ----- Original Message ----- From: Surujpal, Sunil To: 'mpls@UU.net' Sent: Thursday, January 13, 2000 10:19 PM Subject: LDP/CR-LDP and RSVP implementations > > Hi All > > I was wondering if someone could refer me to implementations of LDP/CR-LDP > or RSVP that i could get material on. > > Thanks > Sunil > From owner-mpls@UU.NET Fri Jan 14 00:27:28 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00566 for ; Fri, 14 Jan 2000 00:27:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxxl29006; Fri, 14 Jan 2000 05:25:52 GMT Received: by mail-control.mail.uu.net id QQhxxl06689 for mpls-outgoing; Fri, 14 Jan 2000 05:25:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxxl06684 for ; Fri, 14 Jan 2000 05:25:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxxl15517 for ; Fri, 14 Jan 2000 00:24:58 -0500 (EST) Received: from samar.sasi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sasi.com [164.164.56.2]) id QQhxxl15086 for ; Fri, 14 Jan 2000 05:24:54 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id KAA14682 for ; Fri, 14 Jan 2000 10:56:13 +0530 (IST) Received: from hpd14.sasi.com ([10.0.16.14]) by samar.sasi.com; Fri, 14 Jan 2000 10:56:13 +0000 (IST) Received: from localhost (gbnaidu@localhost) by hpd14.sasi.com (8.9.1/8.9.1) with ESMTP id LAA04080 for ; Fri, 14 Jan 2000 11:04:36 +0530 (IST) Date: Fri, 14 Jan 2000 11:04:36 +0530 (IST) From: "G.B.Naidu" To: mpls@UU.NET Subject: MPLS on FreeBSD... In-Reply-To: <00e501bf5e44$dc111f80$0200a8c0@blhoreckpc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi I am wondering whether is there a FreeBSD implementation of MPLS? I have gone to the address mentioned below - but that looks like s/w of a switch. regards --GB > > There is a freebsd version also... > > http://www.antd.nist.gov/itg/nistswitch/ > > I think this one only uses the rsvp extensions...though I never tried it > > hth, > A > > ----- Original Message ----- > From: Surujpal, Sunil > To: 'mpls@UU.net' > Sent: Thursday, January 13, 2000 10:19 PM > Subject: LDP/CR-LDP and RSVP implementations > > > > > > Hi All > > > > I was wondering if someone could refer me to implementations of LDP/CR-LDP > > or RSVP that i could get material on. > > > > Thanks > > Sunil > > > From owner-mpls@UU.NET Fri Jan 14 01:24:36 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02203 for ; Fri, 14 Jan 2000 01:24:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxxp27123; Fri, 14 Jan 2000 06:23:15 GMT Received: by mail-control.mail.uu.net id QQhxxp17221 for mpls-outgoing; Fri, 14 Jan 2000 06:22:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxxp17209 for ; Fri, 14 Jan 2000 06:22:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxxp17771 for ; Fri, 14 Jan 2000 01:22:30 -0500 (EST) Received: from www.netlabs.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: www.netlabs.net [216.116.128.3]) id QQhxxp26574 for ; Fri, 14 Jan 2000 06:22:29 GMT Received: from blhoreckpc (arni.netlabs.net [216.116.143.247]) by www.netlabs.net (8.9.3/8.9.3) with SMTP id BAA01235; Fri, 14 Jan 2000 01:22:06 -0500 (EST) Message-ID: <016101bf5e58$16f60c60$0200a8c0@blhoreckpc> From: "Arni Raghu" To: "G.B.Naidu" , References: Subject: Re: MPLS on FreeBSD... Date: Fri, 14 Jan 2000 01:25:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Have a cup of coffee, take a 10 minute break and read the the same page again.. A ----- Original Message ----- From: G.B.Naidu To: Sent: Friday, January 14, 2000 12:34 AM Subject: MPLS on FreeBSD... > Hi > > I am wondering whether is there a FreeBSD implementation of MPLS? > > I have gone to the address mentioned below - but that looks like s/w of a > switch. > > regards > --GB > > > > > There is a freebsd version also... > > > > http://www.antd.nist.gov/itg/nistswitch/ > > > > I think this one only uses the rsvp extensions...though I never tried it > > > > hth, > > A > > > > ----- Original Message ----- > > From: Surujpal, Sunil > > To: 'mpls@UU.net' > > Sent: Thursday, January 13, 2000 10:19 PM > > Subject: LDP/CR-LDP and RSVP implementations > > > > > > > > > > Hi All > > > > > > I was wondering if someone could refer me to implementations of LDP/CR-LDP > > > or RSVP that i could get material on. > > > > > > Thanks > > > Sunil > > > > > > > From owner-mpls@UU.NET Fri Jan 14 03:05:44 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13454 for ; Fri, 14 Jan 2000 03:05:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxxq28611; Fri, 14 Jan 2000 06:37:53 GMT Received: by mail-control.mail.uu.net id QQhxxq18574 for mpls-outgoing; Fri, 14 Jan 2000 06:37:21 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxxq18564 for ; Fri, 14 Jan 2000 06:37:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxxq18649 for ; Fri, 14 Jan 2000 01:37:05 -0500 (EST) Received: from samar.sasi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sasi.com [164.164.56.2]) id QQhxxq03925 for ; Fri, 14 Jan 2000 06:37:02 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id MAA17050; Fri, 14 Jan 2000 12:08:23 +0530 (IST) Received: from hpd14.sasi.com ([10.0.16.14]) by samar.sasi.com; Fri, 14 Jan 2000 12:08:23 +0000 (IST) Received: from localhost (gbnaidu@localhost) by hpd14.sasi.com (8.9.1/8.9.1) with ESMTP id MAA04231; Fri, 14 Jan 2000 12:16:46 +0530 (IST) Date: Fri, 14 Jan 2000 12:16:46 +0530 (IST) From: "G.B.Naidu" To: Arni Raghu cc: mpls@UU.NET Subject: Re: MPLS on FreeBSD... In-Reply-To: <016101bf5e58$16f60c60$0200a8c0@blhoreckpc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Thanks buddy. A appreciate your timely help. -- GB On Fri, 14 Jan 2000, Arni Raghu wrote: > Have a cup of coffee, take a 10 minute break and read the the same page > again.. > > A > > ----- Original Message ----- > From: G.B.Naidu > To: > Sent: Friday, January 14, 2000 12:34 AM > Subject: MPLS on FreeBSD... > > > > Hi > > > > I am wondering whether is there a FreeBSD implementation of MPLS? > > > > I have gone to the address mentioned below - but that looks like s/w of a > > switch. > > > > regards > > --GB > > > > > > > > There is a freebsd version also... > > > > > > http://www.antd.nist.gov/itg/nistswitch/ > > > > > > I think this one only uses the rsvp extensions...though I never tried it > > > > > > hth, > > > A > > > > > > ----- Original Message ----- > > > From: Surujpal, Sunil > > > To: 'mpls@UU.net' > > > Sent: Thursday, January 13, 2000 10:19 PM > > > Subject: LDP/CR-LDP and RSVP implementations > > > > > > > > > > > > > > Hi All > > > > > > > > I was wondering if someone could refer me to implementations of > LDP/CR-LDP > > > > or RSVP that i could get material on. > > > > > > > > Thanks > > > > Sunil > > > > > > > > > > > > From owner-mpls@UU.NET Fri Jan 14 06:09:09 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14336 for ; Fri, 14 Jan 2000 06:09:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxyi07703; Fri, 14 Jan 2000 11:08:30 GMT Received: by mail-control.mail.uu.net id QQhxyi08022 for mpls-outgoing; Fri, 14 Jan 2000 11:07:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxyi07992 for ; Fri, 14 Jan 2000 11:07:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxyi06919 for ; Fri, 14 Jan 2000 06:07:40 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQhxyi10729 for ; Fri, 14 Jan 2000 11:07:40 GMT Received: by smtp2.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 11:07:32 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FEE6@monk.datcon.co.uk> From: Adrian Farrel To: "Nava.Zvaig" , mpls@UU.NET, Joan Cucchiara Subject: RE: independent vs ordered Date: Fri, 14 Jan 2000 11:07:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Nava, Sorry. I see what you meant by your original question. Yes, Control mode appears to be missing from the LDP MIB. I think it should be in the LdpPeerTable next to mplsLdpPeerLabelDistributionMethod Joan, would you like to comment? While we're on (or near) the subject, does anyone know why mplsLdpEntityLabelDistributionMethod is in the LdpEntityTable as well? It would seem that an LDP entity needs to know what method of label distribution to use, but that this could vary per session (i.e. per peer). In addition, according to draft-ietf-mpls-ldp-06, ... However, for any given LDP session, each LSR must be aware of the label distribution method used by its peer in order to avoid situations where one peer using Downstream Unsolicited label distribution assumes its peer is also. which suggests that this information should be added to the LdpPeerTable, too. Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >From: Nava.Zvaig [mailto:NZvaig@adtech-inc.com] > >How is an LSR defined to be independent or ordered? Is there >a standard way or is it proprietary for each router? > >>From: Adrian Farrel [mailto:AF@datcon.co.uk] >> >>Look at section 4.12 of "A Framework for Multiprotocol Label Switching" >> >> >>Also 3.19 of "Multiprotocol Label Switching Architecture" >> >> >>>From: Nava.Zvaig [mailto:NZvaig@adtech-inc.com] >>> >>>Where, or how, are independent and ordered label distribution >>>contol modes >>>defined? From owner-mpls@UU.NET Fri Jan 14 08:58:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16754 for ; Fri, 14 Jan 2000 08:58:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxyt01082; Fri, 14 Jan 2000 13:56:52 GMT Received: by mail-control.mail.uu.net id QQhxyt09748 for mpls-outgoing; Fri, 14 Jan 2000 13:56:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxyt09743 for ; Fri, 14 Jan 2000 13:56:21 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxyt20287 for ; Fri, 14 Jan 2000 08:56:01 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhxyt00240 for ; Fri, 14 Jan 2000 13:56:00 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jan 14 08:54:11 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.43.130]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id IAA09155; Fri, 14 Jan 2000 08:54:01 -0500 (EST) Message-ID: <387F2B8D.D2B87C37@lucent.com> Date: Fri, 14 Jan 2000 08:58:37 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Farrel CC: "Nava.Zvaig" , mpls@UU.NET, Joan Cucchiara Subject: Re: independent vs ordered References: <6DEA508A9A0ED31192E80000F6CC176E13FEE6@monk.datcon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Adrian, This turf feels familiar. The control modes "ordered" and "independent" are implementation choices. It's good to have the terms so that we can have intelligible discussions about some types of control operations and how they work. However, real world implementations are likely to implement one mode for some operations and the other for other operations and some hybrid of the two for still more operations. Examples: o Ordered Control - satisfying CR-LDP Label Requests. o Independent Control - allocating new labels as a result of a route change. o Hybrid - use Independent Control for initial labels and Ordered Control for additional labels in an MPLS network consisting entirely of non-merge capable LSRs. Another instance of hybrid operation is exemplified by the following: - - - LSR-n --- LSR-p --- LSR-q --- (LS)R-t If initially LDP is not enabled for (LS)R-t, then LSR-q is the LSP egress for traffic going through (LS)R-t. If LDP is now turned on at (LS)R-t, LSR-q will detect that its next hop for traffic going through (LS)R-t is an LSR and it is no longer the egress for LSPs toward (LS)R-t. What does LSR-q do for the short period of time that will transpire between detecting that (LS)R-t is an LSR and getting all the Labels it requires in order to complete the existing LSPs toward (LS)R-t? If LSR-q immediately tears down all such LSPs, then it is using Ordered Control in the strictest sense. One might want to do this, if one is concerned about looping data traffic, for instance. However, this would be extremely disruptive and anti-social behavior in many cases. If LSR-q sends new Label Mapping messages for all such LSPs to reflect that the hop-count is now unknown, it is possibly just as disruptive since upstream LSRs may elect not to use the LSP until the hop count is known (another way to avoid looping data). If LSR-q elects to do this, however, it is not strictly using ordered control. If LSR-q simply continues to forward packets (as it was doing) to (LS)R-t as IP packets until it receives new Label Mappings (and forwards the new hop count upstream) there will be minimal disruption. However, in this case, LSR-q is clearly not using Ordered Control mode. What - you might ask - is my point? One - given any specific implementation - it is not at all guaranteed what control mode means in every case. Therefore, if a vendor elects to make control mode an option, they must provide the management hooks and description of behavior that fits their implementation. Trying to generalize this looks like a rat-hole. Two - with the exception of cases where the control mode is explicitly defined (i.e. - CR-LDP) - behavior of MPLS systems is not dependent on having a consistent control mode. Control modes of individual LSRs do not normally affect how other LSRs behave in an MPLS network. Thus, there is no general requirement to be able to configure control mode in LSRs. Three - largely because of one and two above - there is no general requirement for any implementation to support any particular control mode. If vendor A builds LSRs that only use ordered control and vendor B builds LSRs that only use independent control, having management hooks in place to read/set the control mode is useless. In short, IMHO, having standard MIB variables for control mode is meaningless, unnecessary and ineffectual. :-) Does this make sense? You wrote: > > Nava, > > Sorry. I see what you meant by your original question. > > Yes, Control mode appears to be missing from the LDP MIB. > I think it should be in the LdpPeerTable next to > mplsLdpPeerLabelDistributionMethod > > Joan, would you like to comment? > > While we're on (or near) the subject, does anyone know why > mplsLdpEntityLabelDistributionMethod is in the LdpEntityTable as well? It > would seem that an LDP entity needs to know what method of label > distribution to use, but that this could vary per session (i.e. per peer). > In addition, according to draft-ietf-mpls-ldp-06, ... > > However, for any given LDP session, each > LSR must be aware of the label distribution method used by its peer > in order to avoid situations where one peer using Downstream > Unsolicited label distribution assumes its peer is also. > > which suggests that this information should be added to the LdpPeerTable, > too. > > Regards, > Adrian > -- > Adrian Farrel mailto:af@datcon.co.uk > ATM, MPLS and Telecoms Development Group > Data Connection Ltd., Chester, UK > http://www.datcon.co.uk/ > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 > > >From: Nava.Zvaig [mailto:NZvaig@adtech-inc.com] > > > >How is an LSR defined to be independent or ordered? Is there > >a standard way or is it proprietary for each router? > > > >>From: Adrian Farrel [mailto:AF@datcon.co.uk] > >> > >>Look at section 4.12 of "A Framework for Multiprotocol Label Switching" > >> > >> > >>Also 3.19 of "Multiprotocol Label Switching Architecture" > >> > >> > >>>From: Nava.Zvaig [mailto:NZvaig@adtech-inc.com] > >>> > >>>Where, or how, are independent and ordered label distribution > >>>contol modes > >>>defined? From owner-mpls@UU.NET Fri Jan 14 11:12:01 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19097 for ; Fri, 14 Jan 2000 11:12:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxyy14911; Fri, 14 Jan 2000 15:14:03 GMT Received: by mail-control.mail.uu.net id QQhxyy26734 for mpls-outgoing; Fri, 14 Jan 2000 15:13:25 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxyy26669 for ; Fri, 14 Jan 2000 15:13:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxyy05749 for ; Fri, 14 Jan 2000 10:13:07 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQhxyy03556 for ; Fri, 14 Jan 2000 15:13:07 GMT Received: by smtp2.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 15:12:58 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FEF2@monk.datcon.co.uk> From: Adrian Farrel To: ewgray@lucent.com Cc: "Nava.Zvaig" , mpls@UU.NET, Joan Cucchiara Subject: RE: independent vs ordered Date: Fri, 14 Jan 2000 15:06:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Thanks Eric, A good reply (and you didn't laugh at me for my crass mistake about what an entry in the LdpEntityTable represents - it is, of course, an instance of the protocol, not an instance of the code that implements the protocol). Your point that an implementation must make it clear what it actually means by the assertion that it supports ordered or independent control on a particular session is well made. Typically, this will expand to an upfront statement or a bunch of configuration options. You're right, trying to generalize this for the LDP MIBs would be a mess. Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Fri Jan 14 11:46:49 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19775 for ; Fri, 14 Jan 2000 11:46:47 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxze04995; Fri, 14 Jan 2000 16:43:11 GMT Received: by mail-control.mail.uu.net id QQhxze13152 for mpls-outgoing; Fri, 14 Jan 2000 16:42:33 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxze13145 for ; Fri, 14 Jan 2000 16:42:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhxze19752 for ; Fri, 14 Jan 2000 11:42:23 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhxze04341 for ; Fri, 14 Jan 2000 16:42:23 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Fri, 14 Jan 2000 11:42:17 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CDAC@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Subject: Can the "Terminate LSP" object be removed from RSVP-tunnels ? Date: Fri, 14 Jan 2000 11:42:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, from mails I got in response to questions I submitted to the list, it seems that there's a general agreement (at least amongst those who responded) - No one can come up with a usefull scenario for this option. So can it be removed ? Andi. From owner-mpls@UU.NET Fri Jan 14 13:30:02 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21008 for ; Fri, 14 Jan 2000 13:30:02 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxzl17147; Fri, 14 Jan 2000 18:27:01 GMT Received: by mail-control.mail.uu.net id QQhxzl04756 for mpls-outgoing; Fri, 14 Jan 2000 18:26:19 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxzl04724 for ; Fri, 14 Jan 2000 18:26:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxzl01608 for ; Fri, 14 Jan 2000 13:26:02 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhxzl16476 for ; Fri, 14 Jan 2000 18:26:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Jan 14 13:24:06 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.43.130]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA14738; Fri, 14 Jan 2000 13:23:57 -0500 (EST) Message-ID: <387F6ACE.7BBCD8F5@lucent.com> Date: Fri, 14 Jan 2000 13:28:30 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Farrel CC: "Nava.Zvaig" , mpls@UU.NET, Joan Cucchiara Subject: Re: independent vs ordered References: <6DEA508A9A0ED31192E80000F6CC176E13FEF2@monk.datcon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Adrian, Thanks for you reply. I hope that you realize that your question was a reasonable one and that my answer was not intended to discourage other questions like it. You wrote: > > Thanks Eric, > > A good reply (and you didn't laugh at me for my crass > mistake about what an entry in the LdpEntityTable > represents - it is, of course, an instance of the > protocol, not an instance of the code that > implements the protocol). > > Your point that an implementation must make it clear > what it actually means by the assertion that it supports > ordered or independent control on a particular session > is well made. > > Typically, this will expand to an upfront statement or > a bunch of configuration options. You're right, trying > to generalize this for the LDP MIBs would be a mess. > > Regards, > Adrian > -- > Adrian Farrel mailto:af@datcon.co.uk > ATM, MPLS and Telecoms Development Group > Data Connection Ltd., Chester, UK > http://www.datcon.co.uk/ > Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Fri Jan 14 14:54:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21720 for ; Fri, 14 Jan 2000 14:54:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxzq02674; Fri, 14 Jan 2000 19:44:48 GMT Received: by mail-control.mail.uu.net id QQhxzq17942 for mpls-outgoing; Fri, 14 Jan 2000 19:44:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhxzq17937 for ; Fri, 14 Jan 2000 19:44:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxzq08843 for ; Fri, 14 Jan 2000 14:44:03 -0500 (EST) Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQhxzq05997 for ; Fri, 14 Jan 2000 19:44:02 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA00535; Fri, 14 Jan 2000 11:43:57 -0800 (PST) Message-Id: <200001141943.LAA00535@omega.cisco.com> To: "Abes, Andi" cc: MPLS mailing list Subject: Re: Explicit route operations in RSVP In-reply-to: Your message of "Wed, 12 Jan 2000 13:59:01 EST." <496A8683261CD211BF6C0008C733261A48CD9B@email.quarrytech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <529.947879036.1@cisco.com> Date: Fri, 14 Jan 2000 11:43:57 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Andi, > I guess the original question was kind of cryptic.... > > The draft-ietf-mpls-rsvp-lsp-tunnel-04 draft contains > an operation sub-object in the Explict route. > > This is part of the Path message traveling from the > Sender (ingress) of the "to be setup" tunnel > towards the Reciver (egress). > > > Section 4.3.4.1. 3) says: > " If the subobject > is an operation subobject, the node pops the subobject from the > EXPLICIT ROUTE object , records the subobject, and continues > processing with step 2, above. " > > This leaves me with the following questions: > > What are the processing rules for this sub-object ? > > In what scenario will this option be used ? When setting up an LSP within another LSP. Here is an example where this sub-object could be useful. Consider the following topology: A---B----C----D----E-----F Assume that A sends a Path message with ERO = (B, E, F). When this message arrives at B, B wants to route it along C and D. One way to do this is just to expand the ERO to (B, C, D, E, F). For this you don't need the label termination sub-object. An alternative is for B to expand this ERO to (B, C, D, lto, E, F) (where "lto" is the label termination sub-object). When D gets a label L1 from E (this label will be carried in the Resv message from E to D), D would use it as the outgoing label for the LSP. D then allocates its own label, L2, for that LSP. In the Label Object that D sends to C (in the Resv message) D will put not just L2, but . When C receives this Resv message, C allocates its own label, L3, and sends in the Label Object to B. B at this point allocates its own label, L4, and sends *just* L4 in the Label Object to A (as it was B who inserted lto in the first place). When A sends a packet over the LSP, A puts L4 on the packet. B replaces A4 with L2 and pushes L3 onto the stack. C pops the stack and sends the packet with just L2 to D. D replaces L2 with L1.... I don't think that the current text reflects what I described above... Yakov. From owner-mpls@UU.NET Fri Jan 14 15:26:54 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21982 for ; Fri, 14 Jan 2000 15:26:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxzt24994; Fri, 14 Jan 2000 20:15:49 GMT Received: by mail-control.mail.uu.net id QQhxzs24252 for mpls-outgoing; Fri, 14 Jan 2000 20:14:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhxzs24158 for ; Fri, 14 Jan 2000 20:14:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxzs14847 for ; Fri, 14 Jan 2000 15:14:33 -0500 (EST) Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQhxzs24973 for ; Fri, 14 Jan 2000 20:14:33 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 15:13:32 -0500 Message-ID: From: "Agranoff, Saul" To: MPLS mailing list Subject: RE: Explicit route operations in RSVP Date: Fri, 14 Jan 2000 15:13:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > When setting up an LSP within another LSP. > > Here is an example where this sub-object could be useful. > Consider the following topology: > > A---B----C----D----E-----F > > Assume that A sends a Path message with ERO = (B, E, F). When this > message arrives at B, B wants to route it along C and D. One way to do > this is just to expand the ERO to (B, C, D, E, F). For this you don't > need the label termination sub-object. > > An alternative is for B to expand this ERO to (B, C, D, lto, E, F) > (where "lto" is the label termination sub-object). When D gets a label > L1 from E (this label will be carried in the Resv message > from E to D), > D would use it as the outgoing label for the LSP. D then > allocates its > own label, L2, for that LSP. In the Label Object that D > sends to C (in > the Resv message) D will put not just L2, but L2>. When > C receives this Resv message, C allocates its own label, L3, and sends > in the Label Object to B. B at this point allocates its own > label, L4, and sends *just* L4 in the Label Object to A (as it was > B who inserted lto in the first place). > > When A sends a packet over the LSP, A puts L4 on the packet. B > replaces A4 with L2 and pushes L3 onto the stack. C pops the > stack and sends the packet with just L2 to D. D replaces L2 with > L1.... > > I don't think that the current text reflects what I described above... > > Yakov. > Thanks Yakov, I was wondering about this issue myself. It almost makes sense now. But since there is an alternative, why would an LSR ('B' in your example) choose to force an extra layer in the label stack? It doesn't seem to buy anything unless the LSP being used for tunnelling can be shared among multiple upper-layer LSPs. We still need some better guidelines in the draft if this option is to be understood. Saul Agranoff Harris & Jeffries, Inc. From owner-mpls@UU.NET Fri Jan 14 15:45:38 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22191 for ; Fri, 14 Jan 2000 15:45:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhxzk08772; Fri, 14 Jan 2000 18:12:50 GMT Received: by mail-control.mail.uu.net id QQhxzk00187 for mpls-outgoing; Fri, 14 Jan 2000 18:12:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhxzk00179 for ; Fri, 14 Jan 2000 18:12:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhxzk00077 for ; Fri, 14 Jan 2000 13:12:10 -0500 (EST) Received: from rambo.globespan.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: p1.globespan.net [209.191.59.250]) id QQhxzk08237 for ; Fri, 14 Jan 2000 18:12:10 GMT Received: from globespan.net (phoenix.ficon-tech.com [209.125.90.2]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Y72N3JQW; Fri, 14 Jan 2000 13:10:49 -0500 Message-ID: <387F66F1.B6160AB3@globespan.net> Date: Fri, 14 Jan 2000 13:12:01 -0500 From: Rohit Chhapolia Organization: Globespan, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Abes, Andi" CC: MPLS mailing list Subject: Re: Can the "Terminate LSP" object be removed from RSVP-tunnels ? References: <496A8683261CD211BF6C0008C733261A48CDAC@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Andi on this aspect. Either there should be some usage for this object or it should be removed, otherwise it just adds more confusion to the rsvp-tunnel draft. Rohit "Abes, Andi" wrote: > > Hi, > from mails I got in response to questions I submitted to the list, > it seems that there's a general agreement (at least amongst those > who responded) - > No one can come up with a usefull scenario for this option. > > So can it be removed ? > > Andi. -- Rohit Chhapolia Globespan, Inc. mailto:rohit@globespan.net http://www.globespan.net From owner-mpls@UU.NET Sat Jan 15 10:04:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12979 for ; Sat, 15 Jan 2000 10:04:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhycq13012; Sat, 15 Jan 2000 15:03:17 GMT Received: by mail-control.mail.uu.net id QQhycq13657 for mpls-outgoing; Sat, 15 Jan 2000 15:02:43 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhycq13637 for ; Sat, 15 Jan 2000 15:02:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhycq18424 for ; Sat, 15 Jan 2000 10:02:36 -0500 (EST) Received: from uqam.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: anis.telecom.uqam.ca [132.208.250.6]) id QQhycq12498 for ; Sat, 15 Jan 2000 15:02:35 GMT Received: from rhim (laroussi@labunix.labunix.uqam.ca [132.208.132.195]) by uqam.ca (8.9.2/8.9.2) with SMTP id KAA19173 for ; Sat, 15 Jan 2000 10:02:31 -0500 (EST) Message-ID: <002901bf5f61$4d6cb6e0$0f02000a@rhim.uqam.ca> From: "H. LAROUSSI" To: Subject: remove Date: Sat, 15 Jan 2000 10:03:27 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01BF5F3F.C4C841E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0026_01BF5F3F.C4C841E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0026_01BF5F3F.C4C841E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0026_01BF5F3F.C4C841E0-- From owner-mpls@UU.NET Sat Jan 15 13:09:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13860 for ; Sat, 15 Jan 2000 13:09:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhydc14999; Sat, 15 Jan 2000 18:09:01 GMT Received: by mail-control.mail.uu.net id QQhydc19704 for mpls-outgoing; Sat, 15 Jan 2000 18:08:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhydc19460 for ; Sat, 15 Jan 2000 18:08:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhydc00948 for ; Sat, 15 Jan 2000 13:07:59 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhydc01190 for ; Sat, 15 Jan 2000 18:07:59 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Sat, 15 Jan 2000 13:07:51 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CDB7@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Subject: RE: Explicit route operations in RSVP Date: Sat, 15 Jan 2000 13:07:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk See below.. > -----Original Message----- > From: Agranoff, Saul [mailto:saula@hjinc.com] > Sent: Friday, January 14, 2000 3:14 PM > To: MPLS mailing list > Subject: RE: Explicit route operations in RSVP > > > > When setting up an LSP within another LSP. > > > > Here is an example where this sub-object could be useful. > > Consider the following topology: > > > > A---B----C----D----E-----F > > > > Assume that A sends a Path message with ERO = (B, E, F). When this > > message arrives at B, B wants to route it along C and D. > One way to do > > this is just to expand the ERO to (B, C, D, E, F). For this > you don't > > need the label termination sub-object. > > > > An alternative is for B to expand this ERO to (B, C, D, lto, E, F) > > (where "lto" is the label termination sub-object). When D > gets a label > > L1 from E (this label will be carried in the Resv message > > from E to D), > > D would use it as the outgoing label for the LSP. D then > > allocates its > > own label, L2, for that LSP. In the Label Object that D > > sends to C (in > > the Resv message) D will put not just L2, but > L2>. When > > C receives this Resv message, C allocates its own label, > L3, and sends > > in the Label Object to B. B at this point allocates its own > > label, L4, and sends *just* L4 in the Label Object to A (as it was > > B who inserted lto in the first place). > > > > When A sends a packet over the LSP, A puts L4 on the packet. B > > replaces A4 with L2 and pushes L3 onto the stack. C pops the > > stack and sends the packet with just L2 to D. D replaces L2 with > > L1.... > > > > I don't think that the current text reflects what I > described above... > > > > Yakov. > > > > Thanks Yakov, > > I was wondering about this issue myself. It almost makes sense now. > > But since there is an alternative, why would an LSR ('B' in > your example) choose to force an extra layer in the label stack? > > It doesn't seem to buy anything unless the LSP being used for > tunnelling can be shared among multiple upper-layer LSPs. My understanding is that: In order for LSP's signaled by RSVP to be shared, they have to be in the same session. The session is defined by the egress point and the tunnel id (assume no exteneded ID). So, the "tunnel" B-C needs to be assigned a Tunnel ID, that can some how be learned by other potential users. There are no provisions for "advertising" this tunnel ID, hence it can not be share. I definitaly stand by Saul's statement, that if the LSP tunnel can not be share, it's useless. Andi. > > We still need some > better guidelines in the draft if this option is to be understood. > > Saul Agranoff > Harris & Jeffries, Inc. > From owner-mpls@UU.NET Mon Jan 17 00:43:22 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16081 for ; Mon, 17 Jan 2000 00:43:22 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyio05702; Mon, 17 Jan 2000 05:42:50 GMT Received: by mail-control.mail.uu.net id QQhyio28970 for mpls-outgoing; Mon, 17 Jan 2000 05:42:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyio28965 for ; Mon, 17 Jan 2000 05:42:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyio00567 for ; Mon, 17 Jan 2000 00:42:03 -0500 (EST) From: chetan@samsung.co.kr Received: from omail30.unitel.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omail30.unitel.co.kr [203.241.135.155]) id QQhyio05842 for ; Mon, 17 Jan 2000 05:42:01 GMT Received: from localhost (root@localhost) by gp_man.sdsosc.co.kr (8.8.8H1/8.8.8) with ESMTP id OAA05396; Mon, 17 Jan 2000 14:41:39 +0900 (KST) X-OpenMail-Hops: 3 Date: Mon, 17 Jan 2000 13:41:06 +0800 Message-Id: Subject: MPLS TE MIB MIME-Version: 1.0 TO: mpls@UU.NET, arunv@lucent.com, cheenu@tachion.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Mon, 17 Jan 2000 13:30:33 +0800" ;Modification-Date="Mon, 17 Jan 2000 13:41:01 +0800" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi, This is with reference to "draft-ietf-mpls-te-mib-01.txt" Is it necessary to have both "mplsTunnelLocalCookie" and "mplsTunnelRemoteCookie" as part of "mplsTunnelEntry"? Can't this be replaced by just one mib variable say, "mplsTunnelCookie"? cheers, chetan From owner-mpls@UU.NET Mon Jan 17 04:56:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29106 for ; Mon, 17 Jan 2000 04:56:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyjf27852; Mon, 17 Jan 2000 09:55:51 GMT Received: by mail-control.mail.uu.net id QQhyjf11298 for mpls-outgoing; Mon, 17 Jan 2000 09:55:19 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyjf11291 for ; Mon, 17 Jan 2000 09:55:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyjf18456 for ; Mon, 17 Jan 2000 04:55:01 -0500 (EST) Received: from samar.sasi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sasi.com [164.164.56.2]) id QQhyjf06185 for ; Mon, 17 Jan 2000 09:54:54 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id PAA04053 for ; Mon, 17 Jan 2000 15:26:11 +0530 (IST) Received: from hpd14.sasi.com ([10.0.16.14]) by samar.sasi.com; Mon, 17 Jan 2000 15:26:09 +0000 (IST) Received: from localhost (gbnaidu@localhost) by hpd14.sasi.com (8.9.1/8.9.1) with ESMTP id PAA01719 for ; Mon, 17 Jan 2000 15:34:29 +0530 (IST) Date: Mon, 17 Jan 2000 15:34:29 +0530 (IST) From: "G.B.Naidu" To: mpls@UU.NET Subject: interface index in MPLS implementation... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi How is the interface is identified in MPLS implementation? Is it through interface name or interface index? We are trying to have index number in forwarding tables. I would like to know how do I find out the interface index of the interface on which the packet came in(Incoming packet)? Thank you -- GB From owner-mpls@UU.NET Mon Jan 17 10:17:16 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02446 for ; Mon, 17 Jan 2000 10:17:16 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyka13074; Mon, 17 Jan 2000 15:14:53 GMT Received: by mail-control.mail.uu.net id QQhyka13812 for mpls-outgoing; Mon, 17 Jan 2000 15:14:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhyka13796 for ; Mon, 17 Jan 2000 15:14:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyka09924 for ; Mon, 17 Jan 2000 10:13:54 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQhyka12345 for ; Mon, 17 Jan 2000 15:13:52 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 14:57:16 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E13FF19@monk.datcon.co.uk> From: Adrian Farrel To: "Surujpal, Sunil" , mpls@UU.NET Subject: RE: Questions Date: Mon, 17 Jan 2000 14:57:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Sunil, You and several others asked when the White Paper on this subject would be available. The answer is now. See http://www.datcon.co.uk/download/crldprsvp.pdf or follow the links from our front page http://www.datcon.co.uk Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Surujpal, Sunil [mailto:s.surujpal@auckland.ac.nz] >Sent: Sunday, January 09, 2000 11:07 PM >To: mpls@UU.NET >Subject: Questions > > > >Hi, > >I am writing a research essay on MPLS, in particular on the signalling >protocols that are being considered for use such as RSVP and >LDP. I have >several questions that I am would like help with. >1. In the Internet Draft draft-ietf-mpls-arch-06.txt, it >says that the >MPLS architecture does not assume that there is only one label >distribution >protocol and that several protocols are being standardized >such as BGP, RSVP >and new protocols being created for i.e. LDP. The majority of >the material >that I have looked at only discuss RSVP and to some extent LDP >as the two >protocols that are now being considered for this purpose. Are >these two the >only protocols that are being considered for standardization >by the IETF and >if so, why was BGP discarded? If not, can someone please direct me to >material on BGP and how it is being extended to provide label >distribution. >2. Can someone also please direct me to material that discusses the >pros and con of the protocols that are being considered for >use as the label >distribution protocol for MPLS. > >Your help is very much appreciated. >Sunil Surujpal > > >__________________________________________________ >Sunil Surujpal >Course Coordinator >Department of Management Science and Information Systems >School of Economics and Business >University of Auckland >Private Bag 92019 >Auckland >New Zealand >Phone: 64 9 3737599 x8537 >Fax: 64 9 3737430 > From owner-mpls@UU.NET Mon Jan 17 10:31:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02777 for ; Mon, 17 Jan 2000 10:31:31 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhykb27883; Mon, 17 Jan 2000 15:28:33 GMT Received: by mail-control.mail.uu.net id QQhykb14668 for mpls-outgoing; Mon, 17 Jan 2000 15:28:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhykb14661 for ; Mon, 17 Jan 2000 15:27:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhykb11044 for ; Mon, 17 Jan 2000 10:27:44 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQhykb27268 for ; Mon, 17 Jan 2000 15:27:39 GMT Received: by smtp2.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 15:27:13 -0000 Message-ID: <37701240971DD31193970000F6CCB9F7B9AB7D@duke.datcon.co.uk> From: Piers Finlayson To: "'Joan Cucchiara'" Cc: "'mpls@uu.net'" Subject: RE: LDP MIB update? Date: Mon, 17 Jan 2000 15:24:21 -0000 Deferred-Delivery: Mon, 17 Jan 2000 15:27:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Joan, I think there may be a problem with the mplsLdpSessionPeerAddressTable in the LDP MIB. The mplsLdpSessionPeerAddressTable extends the mplsLdpSessionTable in the same way as the mplsLdpFrameRelaySessionTable and the mplsLdpAtmSessionTable. They all use the same indexes as the mplsLdpSessionTable, but the Protocol Session Table indexes are extended to include mplsLdpSessionAtmLabelRangeLowerBoundVpi and mplsLdpSessionAtmLabelRangeLowerBoundVpi in the ATM case mplsLdpFrSessionMinDlci in the Frame Relay case. These additional indexes allow multiple rows to exist in the Protocol Session Tables for a single entry in the mplsLdpSessionTable. this is important because there may be several label ranges for a single session. I think there may also be multiple peer next hop addresses per session. This means that the two fields mplsLdpSessionPeerNextHopAddressType mplsLdpSessionPeerNextHopAddress should be added to the index so that rows in this table can also be accessed. If you make this change, the ASN.1 for mplsLdpSessionPeerAddressEntry will become ... mplsLdpSessionPeerAddressEntry OBJECT-TYPE SYNTAX MplsLdpSessionPeerAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on session's for a single next hop address which was advertised in an Address Message from the LDP peer. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpPeerIndex, mplsLdpSessionIndex mplsLdpSessionPeerNextHopAddressType mplsLdpSessionPeerNextHopAddress } ::= { mplsLdpSessionPeerAddressTable 1 } MplsLdpSessionPeerAddressEntry ::= SEQUENCE { mplsLdpSessionPeerNextHopAddressType AddressFamilyNumbers, mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr } The individual fields also have to become "not-accessible" ... However, in your email of 3 December 1999 you describe new indexing for the mplsLdpSessionTable. I assume, therefore that mplsLdpSessionPeerAddressEntry becomes ... mplsLdpSessionPeerAddressEntry OBJECT-TYPE SYNTAX MplsLdpSessionPeerAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on session's for a single next hop address which was advertised in an Address Message from the LDP peer. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpSessionPeerNextHopAddressType, mplsLdpSessionPeerNextHopAddress } ::= { mplsLdpSessionPeerAddressTable 1 } MplsLdpSessionPeerAddressEntry ::= SEQUENCE { mplsLdpSessionPeerNextHopAddressType AddressFamilyNumbers, mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr } ... Is this correct? Thanks, Piers --------------------------------------------------------- Piers Finlayson ATM, MPLS and Telecoms Group Data Connection Ltd. Tel: +44 20 8366 1177 Fax: +44 20 8363 4478 Email: pdf@datcon.co.uk Web: http://www.datcon.co.uk --------------------------------------------------------- From owner-mpls@UU.NET Mon Jan 17 11:48:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03735 for ; Mon, 17 Jan 2000 11:48:48 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhykh14354; Mon, 17 Jan 2000 16:46:54 GMT Received: by mail-control.mail.uu.net id QQhykh26355 for mpls-outgoing; Mon, 17 Jan 2000 16:46:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhykh26346 for ; Mon, 17 Jan 2000 16:46:12 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhykh18699; Mon, 17 Jan 2000 11:46:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhykh13643; Mon, 17 Jan 2000 16:46:02 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Jan 17 11:45:40 EST 2000 Received: from research.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA06873; Mon, 17 Jan 2000 11:45:37 -0500 (EST) Message-ID: <388346D7.8321A1D5@research.bell-labs.com> Date: Mon, 17 Jan 2000 11:44:07 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: RSVP , mpls , diffserv , te-wg CC: Henning Schulzrinne , Ellen Hahne Subject: A new draft on inter-domain level resource management Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, all, We have just submitted a draft, "BGRP: A Framework for Scalable Resource Reservation". It describes a new scalable signaling protocol that can setup reservation trunks/MPLS LSP's over multiple internet domains. I think that people on the above mailing lists may want to take a look at it. You may find the draft in http://www.cs.columbia.edu/~pingpan/papers/draft-pan-bgrp-framework-00.txt Some more information is in http://www.cs.columbia.edu/~pingpan/projects/bgrp.html Here are some of the highlights: - Why not RSVP? In RSVP, PATH messages are required to pin-down reservation routes prior to the actual reservation. Thus with PATH/RESV, each route has to maintain both source and destination information. This would cause the N**2 problem, where N is total number of end users. In our proposal, we suggest to have senders probing the network, but the routers don't have to store the probing information. The routers only have to remember the reservation destination (that is, sink-tree model). This would reduce the problem to O(N). - Useful to MPLS and TE Each link may not have too many end-host real-time reservations all at once. But to apply traffic engineering, the ISP's may want to setup a fully connected LSP network. With RSVP/LDP, N**2 would be a problem. We proposed a different way for setting up the LSP's for inter-domain. - DiffServ IMHO, DiffServ is good for data aggregation so that the routers don't have to maintain micro-flow information as in IntServ. But DiffServ is NOT a control mechanism. Our proposal can be used to setup DiffServ trunks across the network. - Routing interface We interface with BGP for reservation routes. If we look at the network today, BGP with route aggregation provides nice sink-trees to all destination networks. Our objective is to set up reservations along the BGP routes. So please take a look at our draft. We have collected a lot of traffic traces with the help from NLANR people. From the trace, we observed some very interesting behaviors with source/destination data. Also we have talked (formally and informally) to many developers and operation people to make sure our scheme would work. Thanks to them all. This is a new area of work on inter-domain resource management, which I believe it would be useful in the near future. We would like to hear from all of you to make sure we didn't think in the wrong direction. Thank you all in advance! -- Ping, Ellen, Henning From owner-mpls@UU.NET Mon Jan 17 12:07:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04141 for ; Mon, 17 Jan 2000 12:07:12 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyki25166; Mon, 17 Jan 2000 17:03:35 GMT Received: by mail-control.mail.uu.net id QQhyki29891 for mpls-outgoing; Mon, 17 Jan 2000 17:03:02 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyki29814 for ; Mon, 17 Jan 2000 17:02:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyki21572 for ; Mon, 17 Jan 2000 12:02:46 -0500 (EST) Received: from us-cam-mail.cignal.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.243.204.4]) id QQhyki21342 for ; Mon, 17 Jan 2000 17:02:46 GMT Received: by us-cam-mail.cignal.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 12:02:47 -0500 Message-ID: <0592CB9598B8D311823300902785C69904ADC2@us-cam-mail.cignal.com> From: Mark Land To: "'mpls@uu.net'" Subject: Who has hardware? Date: Mon, 17 Jan 2000 12:02:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Are their any manufacturers of a deployable CR-LDP MPLS solution? Mark S. Land From owner-mpls@UU.NET Mon Jan 17 13:36:52 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05315 for ; Mon, 17 Jan 2000 13:36:52 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyko14837; Mon, 17 Jan 2000 18:34:13 GMT Received: by mail-control.mail.uu.net id QQhyko17086 for mpls-outgoing; Mon, 17 Jan 2000 18:33:51 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyko17081 for ; Mon, 17 Jan 2000 18:33:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyko01419 for ; Mon, 17 Jan 2000 13:33:36 -0500 (EST) Received: from pop02.iname.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pop02.iname.net [165.251.20.34]) id QQhyko14395 for ; Mon, 17 Jan 2000 18:33:35 GMT Received: from wiztech (vdp138.ath03.cas.hol.gr [195.97.3.139]) by pop02.iname.net (8.9.3/8.9.3) with SMTP id NAA26580; Mon, 17 Jan 2000 13:33:33 -0500 (EST) Reply-To: From: "Constantine Protopapas" To: "Mark Land" , "'mpls@uu.net'" Subject: RE: Who has hardware? Date: Mon, 17 Jan 2000 20:33:15 +0200 Message-ID: <000201bf6119$54a2df20$8b0361c3@hol.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <0592CB9598B8D311823300902785C69904ADC2@us-cam-mail.cignal.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mark, Try Newbridge Networks' 670 Routing Switch Platform. Constantine Protopapas Systems/Network Engineer Applied Science 62 Karpenisioti Str. GR 115 24 N. Filothei Athens GREECE tel: ++30-1-6998225 fax ++30-1-6998983 mobile: ++30-97-7598043 e-mail: applied@otenet.gr (office) wiztech@hol.gr (home) > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mark Land > Sent: Monday, January 17, 2000 7:03 PM > To: 'mpls@uu.net' > Subject: Who has hardware? > > > Are their any manufacturers of a deployable CR-LDP MPLS solution? > > Mark S. Land > From owner-mpls@UU.NET Mon Jan 17 13:40:02 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05346 for ; Mon, 17 Jan 2000 13:40:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyko16214; Mon, 17 Jan 2000 18:36:34 GMT Received: by mail-control.mail.uu.net id QQhyko17230 for mpls-outgoing; Mon, 17 Jan 2000 18:36:11 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyko17169 for ; Mon, 17 Jan 2000 18:36:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyko01563 for ; Mon, 17 Jan 2000 13:35:56 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQhyko15767 for ; Mon, 17 Jan 2000 18:35:55 GMT Received: by BRIXCORP2 with Internet Mail Service (5.5.1960.3) id ; Mon, 17 Jan 2000 13:33:55 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB0CE238@BRIXCORP2> From: Joan Cucchiara To: "'Piers Finlayson'" , Joan Cucchiara Cc: "'mpls@uu.net'" Subject: RE: LDP MIB update? Date: Mon, 17 Jan 2000 13:33:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Piers, I do think you are correct and those NextHop objects should be included in the index. And yes, we have removed the SessionIndex from the MIB, so your table appears to be correct. Thanks, Joan > -----Original Message----- > From: Piers Finlayson [mailto:pdf@datcon.co.uk] > Sent: Monday, January 17, 2000 10:24 AM > To: 'Joan Cucchiara' > Cc: 'mpls@uu.net' > Subject: RE: LDP MIB update? > > > Joan, > > I think there may be a problem with the > mplsLdpSessionPeerAddressTable in > the LDP MIB. > > The mplsLdpSessionPeerAddressTable extends the > mplsLdpSessionTable in the > same way as the mplsLdpFrameRelaySessionTable and the > mplsLdpAtmSessionTable. They all use the same indexes as the > mplsLdpSessionTable, but the Protocol Session Table indexes > are extended to > include > > mplsLdpSessionAtmLabelRangeLowerBoundVpi and > mplsLdpSessionAtmLabelRangeLowerBoundVpi in the ATM case > > mplsLdpFrSessionMinDlci in the Frame Relay case. > > These additional indexes allow multiple rows to exist in the Protocol > Session Tables for a single entry in the mplsLdpSessionTable. this is > important because there may be several label ranges for a > single session. > > I think there may also be multiple peer next hop addresses > per session. > This means that the two fields > > mplsLdpSessionPeerNextHopAddressType > mplsLdpSessionPeerNextHopAddress > > should be added to the index so that rows in this table can also be > accessed. > > > If you make this change, the ASN.1 for > mplsLdpSessionPeerAddressEntry will > become > > ... > > mplsLdpSessionPeerAddressEntry OBJECT-TYPE > SYNTAX MplsLdpSessionPeerAddressEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents information on > session's for a single next hop address which was > advertised in an Address Message from the LDP peer. > The information contained in a row is read-only." > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpPeerIndex, > mplsLdpSessionIndex > mplsLdpSessionPeerNextHopAddressType > mplsLdpSessionPeerNextHopAddress > } > ::= { mplsLdpSessionPeerAddressTable 1 } > > MplsLdpSessionPeerAddressEntry ::= SEQUENCE { > mplsLdpSessionPeerNextHopAddressType > AddressFamilyNumbers, > mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr > } > > The individual fields also have to become "not-accessible" > > ... > > However, in your email of 3 December 1999 you describe new > indexing for the > mplsLdpSessionTable. I assume, therefore that > mplsLdpSessionPeerAddressEntry becomes > > ... > > mplsLdpSessionPeerAddressEntry OBJECT-TYPE > SYNTAX MplsLdpSessionPeerAddressEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents information on > session's for a single next hop address which was > advertised in an Address Message from the LDP peer. > The information contained in a row is read-only." > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpSessionPeerNextHopAddressType, > mplsLdpSessionPeerNextHopAddress > } > ::= { mplsLdpSessionPeerAddressTable 1 } > > MplsLdpSessionPeerAddressEntry ::= SEQUENCE { > mplsLdpSessionPeerNextHopAddressType > AddressFamilyNumbers, > mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr > } > > ... > > > Is this correct? > > Thanks, > Piers > > --------------------------------------------------------- > Piers Finlayson > > ATM, MPLS and Telecoms Group > Data Connection Ltd. > > Tel: +44 20 8366 1177 Fax: +44 20 8363 4478 > Email: pdf@datcon.co.uk Web: http://www.datcon.co.uk > --------------------------------------------------------- > From owner-mpls@UU.NET Mon Jan 17 14:53:47 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07648 for ; Mon, 17 Jan 2000 14:53:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhykt25170; Mon, 17 Jan 2000 19:51:08 GMT Received: by mail-control.mail.uu.net id QQhykt28339 for mpls-outgoing; Mon, 17 Jan 2000 19:50:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhykt28334 for ; Mon, 17 Jan 2000 19:50:36 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhykt08058 for ; Mon, 17 Jan 2000 14:50:29 -0500 (EST) Received: from gateway.metrored.com.ar by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gateway.metrored.com.ar [200.47.48.198]) id QQhykt24629 for ; Mon, 17 Jan 2000 19:50:27 GMT Received: by GATEWAY with Internet Mail Service (5.5.2448.0) id ; Mon, 17 Jan 2000 16:50:57 -0300 Message-ID: From: =?iso-8859-1?Q?=22Bugallo=2C_Hern=E1n=22?= To: "'mpls@UU.NET'" Subject: Books or courses Date: Mon, 17 Jan 2000 16:50:53 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA07648 Hello all! I would like to understand the technology more easily, and learn how it is applied in MPLS. Would have you, some type of training or course, which wanted to share comigo? I am thankful to all. Hernán Bugallo. Tecnologia & Networking. MetroRED Telecomunicaciones Paseo Colon 505-5š Piso (Buenos Aires)-ARGENTINA. C.P.:(1063). Tel: +(5411) +4344-7700 +(7829) From owner-mpls@UU.NET Mon Jan 17 15:22:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08183 for ; Mon, 17 Jan 2000 15:22:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhykv09852; Mon, 17 Jan 2000 20:20:08 GMT Received: by mail-control.mail.uu.net id QQhykv07772 for mpls-outgoing; Mon, 17 Jan 2000 20:19:43 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhykv07767 for ; Mon, 17 Jan 2000 20:19:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhykv10379 for ; Mon, 17 Jan 2000 15:19:30 -0500 (EST) Received: from ucayali.unired.net.pe by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ucayali.unired.net.pe [206.138.105.38]) id QQhykv09399 for ; Mon, 17 Jan 2000 20:19:27 GMT Received: from telefonica.com.pe ([200.37.84.135]) by ucayali.unired.net.pe (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id e0HAIVT20341; Mon, 17 Jan 2000 15:18:31 +0500 (GMT) Message-ID: <38837939.D0A02C23@telefonica.com.pe> Date: Mon, 17 Jan 2000 15:19:06 -0500 From: Jesus Rodriguez Stuart Reply-To: jrstuart@telefonica.com.pe Organization: Telefonica del Peru X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bugallo@ucayali.unired.net.pe, =?iso-8859-1?Q?Hern=E1n?= CC: "'mpls@UU.NET'" Subject: Re: Books or courses References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Opinion: The best book are the drafts , auto-learning , this is a personal opinion. I dont know any especialized MPLS book , but, I think that you have to read MPLS I-D, BGP RFCs. Jesus Rodriguez Stuart Network Solutions Telefonica del Peru Comunicaciones de Empresa jrstuart@telefonica.com.pe +51-1- 210-4835 Fax : +51-1-422-0591 "Bugallo, Hernán" wrote: > Hello all! > I would like to understand the technology more easily, and learn how it is > applied in MPLS. > Would have you, some type of training or course, which wanted to share > comigo? > I am thankful to all. > > Hernán Bugallo. > Tecnologia & Networking. > MetroRED Telecomunicaciones > Paseo Colon 505-5š Piso (Buenos Aires)-ARGENTINA. > C.P.:(1063). Tel: +(5411) +4344-7700 +(7829) -- From owner-mpls@UU.NET Mon Jan 17 15:49:17 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08658 for ; Mon, 17 Jan 2000 15:49:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhykw15791; Mon, 17 Jan 2000 20:30:21 GMT Received: by mail-control.mail.uu.net id QQhykv08210 for mpls-outgoing; Mon, 17 Jan 2000 20:29:56 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhykv08205 for ; Mon, 17 Jan 2000 20:29:52 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhykv07144 for ; Mon, 17 Jan 2000 15:29:51 -0500 (EST) Received: from hq_nt1.netreference.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.netreference.com [206.181.70.90]) id QQhykv19991 for ; Mon, 17 Jan 2000 20:29:51 GMT Received: by mail.netreference.com with Internet Mail Service (5.5.2448.0) id ; Mon, 17 Jan 2000 15:34:26 -0500 Message-ID: <511FDE2316C5D211890E00A0C997507524E353@mail.netreference.com> From: Irwin Lazar To: "'jrstuart@telefonica.com.pe'" , Bugallo@ucayali.unired.net.pe, =?iso-8859-1?Q?Hern=E1n?= Cc: "'mpls@UU.NET'" Subject: RE: Books or courses Date: Mon, 17 Jan 2000 15:34:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF612A.3E928780" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF612A.3E928780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are a couple of books worth looking at: Switching in Ip Networks : Ip Switching, Tag Switching, and Related Technologies (The Morgan Kaufmann Series in Networking) By Bruce S. Davie, Paul Doolan, Yakov Rekhter=20 IP Switching : Protocols and Architecture, By Christopher Y. Metz Also see: http://www.itprc.com/routing.htm for links to several on-line = MPLS resources. Irwin > -----Original Message----- > From: Jesus Rodriguez Stuart [mailto:jrstuart@telefonica.com.pe] > Sent: Monday, January 17, 2000 3:19 PM > To: Bugallo@ucayali.unired.net.pe; Hern=E1n > Cc: 'mpls@UU.NET' > Subject: Re: Books or courses >=20 >=20 > Opinion: > The best book are the drafts , auto-learning , this is a=20 > personal opinion. I > dont know any especialized MPLS book , but, I think that you=20 > have to read MPLS > I-D, BGP RFCs. >=20 > Jesus Rodriguez Stuart >=20 > Network Solutions > Telefonica del Peru > Comunicaciones de Empresa > jrstuart@telefonica.com.pe >=20 > +51-1- 210-4835 > Fax : +51-1-422-0591 >=20 >=20 >=20 > "Bugallo, Hern=E1n" wrote: >=20 > > Hello all! > > I would like to understand the technology more easily, and=20 > learn how it is > > applied in MPLS. > > Would have you, some type of training or course, which=20 > wanted to share > > comigo? > > I am thankful to all. > > > > Hern=E1n Bugallo. > > Tecnologia & Networking. > > MetroRED Telecomunicaciones > > Paseo Colon 505-5=BA Piso (Buenos Aires)-ARGENTINA. > > C.P.:(1063). Tel: +(5411) +4344-7700 +(7829) >=20 > -- >=20 >=20 >=20 ------_=_NextPart_000_01BF612A.3E928780 Content-Type: application/octet-stream; name="Irwin Lazar (E-mail).vcf" Content-Disposition: attachment; filename="Irwin Lazar (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Lazar;Irwin FN:Irwin Lazar (E-mail) ORG:The Burton Group (Formerly NetReference, Inc.) TITLE:Senior Consultant TEL;WORK;VOICE:(703) 742-9659 TEL;WORK;FAX:(703) 742-8038 ADR;WORK:;;45615 Willow Pond Plaza;Sterling;Va;20164;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:45615 Willow Pond Plaza=0D=0ASterling, Va 20164=0D=0AUSA EMAIL;PREF;INTERNET:ilazar@tbg.com REV:20000112T150132Z END:VCARD ------_=_NextPart_000_01BF612A.3E928780-- From owner-mpls@UU.NET Mon Jan 17 16:13:23 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08941 for ; Mon, 17 Jan 2000 16:13:23 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhykw17972; Mon, 17 Jan 2000 20:33:23 GMT Received: by mail-control.mail.uu.net id QQhykw08392 for mpls-outgoing; Mon, 17 Jan 2000 20:32:56 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhykw08387 for ; Mon, 17 Jan 2000 20:32:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhykw07496 for ; Mon, 17 Jan 2000 15:32:46 -0500 (EST) Received: from scallop.baynetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns5.baynetworks.com [194.133.90.101]) id QQhykw21664 for ; Mon, 17 Jan 2000 20:32:45 GMT Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by scallop.baynetworks.com (8.9.1/8.9.1) with ESMTP id VAA15735; Mon, 17 Jan 2000 21:35:59 +0100 (MET) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id PAA21263; Mon, 17 Jan 2000 15:27:50 -0500 (EST) Received: from bubba.engeast (bubba [192.168.136.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA22400; Mon, 17 Jan 2000 15:32:34 -0500 for Received: by bubba.engeast (SMI-8.6/SMI-SVR4) id PAA08410; Mon, 17 Jan 2000 15:32:34 -0500 Date: Mon, 17 Jan 2000 15:32:34 -0500 From: dwilder@baynetworks.com (David Wilder) Message-Id: <200001172032.PAA08410@bubba.engeast> To: Bugallo@ucayali.unired.net.pe, bugalloh@metrored.com.ar, jrstuart@telefonica.com.pe Subject: Re: Books or courses Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk I would recommend starting w/ the following 2 drafts to get familiar w/ MPLS: A Framework for MPLS Multiprotocol Label Switching Architecture Then you can move on to reading the LDP. Finaly, read the CR-LDP & RSVP specs. Dave ****************************************************************** Opinion: The best book are the drafts , auto-learning , this is a personal opinion. I dont know any especialized MPLS book , but, I think that you have to read MPLS I-D, BGP RFCs. Jesus Rodriguez Stuart Network Solutions Telefonica del Peru Comunicaciones de Empresa jrstuart@telefonica.com.pe +51-1- 210-4835 Fax : +51-1-422-0591 "Bugallo, Hernán" wrote: > Hello all! > I would like to understand the technology more easily, and learn how it is > applied in MPLS. > Would have you, some type of training or course, which wanted to share > comigo? > I am thankful to all. > > Hernán Bugallo. > Tecnologia & Networking. > MetroRED Telecomunicaciones > Paseo Colon 505-5š Piso (Buenos Aires)-ARGENTINA. > C.P.:(1063). Tel: +(5411) +4344-7700 +(7829) -- From owner-mpls@UU.NET Mon Jan 17 17:16:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09688 for ; Mon, 17 Jan 2000 17:16:04 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhylc13732; Mon, 17 Jan 2000 22:13:44 GMT Received: by mail-control.mail.uu.net id QQhylc28845 for mpls-outgoing; Mon, 17 Jan 2000 22:13:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhylc28840 for ; Mon, 17 Jan 2000 22:13:14 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhylc19006 for ; Mon, 17 Jan 2000 17:13:06 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhylc12979 for ; Mon, 17 Jan 2000 22:12:34 GMT Received: from chmetz-pc.cisco.com (englewood-dhcp-66.cisco.com [171.68.79.66]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id OAA00649; Mon, 17 Jan 2000 14:06:42 -0800 (PST) Message-Id: <4.2.0.58.20000117164855.00c83cb0@sj-email.cisco.com> X-Sender: chmetz@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 17 Jan 2000 17:08:13 -0500 To: dwilder@baynetworks.com (David Wilder) From: Chris Metz Subject: Re: Books or courses Cc: Bugallo@ucayali.unired.net.pe, bugalloh@metrored.com.ar, jrstuart@telefonica.com.pe, mpls@UU.NET In-Reply-To: <200001172032.PAA08410@bubba.engeast> 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 RAA09688 Hi- Two books with MPLS content: Metz, C., “IP Switching: Protocols and Architectures”, McGraw-Hill, 1999 Davie, et al., “Switching in IP Networks”, Morgan Kaufmann, 1998 Other good MPLS references: http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ December 1999 issue of IEEE Communications (Have to be an IEEE member) - http://www.comsoc.org/ci/public/1999/dec/index.html Vendor documentation from those that are implementing. Thanks ... At 03:32 PM 1/17/2000 -0500, David Wilder wrote: >I would recommend starting w/ the following 2 drafts to get familiar w/ >MPLS: >A Framework for MPLS >Multiprotocol Label Switching Architecture > >Then you can move on to reading the LDP. > >Finaly, read the CR-LDP & RSVP specs. > >Dave > >****************************************************************** > > Opinion: > The best book are the drafts , auto-learning , this is a personal > opinion. I > dont know any especialized MPLS book , but, I think that you have > to read MPLS > I-D, BGP RFCs. > > Jesus Rodriguez Stuart > > Network Solutions > Telefonica del Peru > Comunicaciones de Empresa > jrstuart@telefonica.com.pe > > +51-1- 210-4835 > Fax : +51-1-422-0591 > > > > "Bugallo, Hernán" wrote: > > > Hello all! > > I would like to understand the technology more easily, and > learn how it is > > applied in MPLS. > > Would have you, some type of training or course, which wanted > to share > > comigo? > > I am thankful to all. > > > > Hernán Bugallo. > > Tecnologia & Networking. > > MetroRED Telecomunicaciones > > Paseo Colon 505-5š Piso (Buenos Aires)-ARGENTINA. > > C.P.:(1063). Tel: +(5411) +4344-7700 +(7829) > > -- > > > > Chris Metz Lead IP Architect Solutions Integration Service Provider Line of Business Cisco Systems email: chmetz@cisco.com offic phone: 212-714-4207 home office: 914-241-0423 pager: 800-365-4578 From owner-mpls@UU.NET Mon Jan 17 18:08:40 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10047 for ; Mon, 17 Jan 2000 18:08:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhylg16625; Mon, 17 Jan 2000 23:06:34 GMT Received: by mail-control.mail.uu.net id QQhylg08097 for mpls-outgoing; Mon, 17 Jan 2000 23:06:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhylg07983 for ; Mon, 17 Jan 2000 23:06:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhylg19281; Mon, 17 Jan 2000 18:06:02 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhylg10751; Mon, 17 Jan 2000 23:06:02 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Jan 17 18:05:18 EST 2000 Received: from dnrc.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA23758; Mon, 17 Jan 2000 18:05:17 -0500 (EST) Message-ID: <38839FD3.34430465@dnrc.bell-labs.com> Date: Mon, 17 Jan 2000 18:03:47 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: Ping Pan , RSVP , mpls , diffserv , te-wg , Henning Schulzrinne , Ellen Hahne Subject: Re: A new draft on inter-domain level resource management References: <200001172049.PAA24260@anchor.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > > You should be clear in your discussions of BGRP what problem it is you > are trying to solve. BGRP is trying to solve the scalability problems > that arrise when using MPLS for microflows. This is what is commonly > referred to as QoS routing. > Hi, Curtis, BGRP is not a routing protocol. It uses the information provided by BGP4 (specifically, AS_PATH and NEXT_HOP attributes) to set up reservation trunks in the backbone. First, it involves only with BGP border routers. Second, it further reduces the number of "flows" a border router has to maintain. I think QoS routing is to periodically advertise link/resource information throughout the network, which is not really what we are targeting here. Sorry about the confusion. > [ aside: > > This is why I have insisted that we not confuse the term "QoS routing" > with "traffic engineering". The two have similarities, but some very > significant differences. Traffic engineeering as it is currently > practiced by ISPs is not concerned with microflows (even very large > ones) and in a stable network would be expected to generate zero > setups despite huge numbers (could be hundreds of thousands or > millions) of microflows appearing and going away per second. > For traffic engineering, there could be many long-lived "flows" that established by the ISP's. The cost of setting them up in terms of processing CPU cycles and storage space may not be a big deal, but the cost of maintain these "flows" may be a big problem for the routers. Soft-state is a good idea to allow the routers to adjust to route changes. But the side-effect here is that soft-state requires the routers to maintain a copy of all the states. If there are thousands or millions of microflows that need to refresh, I doubt the routers can sustain the CPU cost. > For traffic engineered backbones, the total number of LSPs is bounded > by the number of LSRs in the network and the number of classes of > service offerred. Most providers estimate the total number of LSPs > that will be needed in their network to be on the order of 10^3 or > 10^4. The number going through any one LSR should be even smaller. > The setup rate should normally be zero or very close to zero except in > response to network failure. Actually, as being pointed out in RFC2430 (PASTE by Tony Li and Yokov Rekhter), the number of trunks (or LSP's, or reservations) is N * (N-1) * C, where C is the number of service classes, N is the number of MPLS-speaking routers. This is the N**2 problem we are talking about here. In case of intra-domain, N is the number of border routers at backbone edge, and is in the range of ~100. To setup a full-meshed network to support traffic engineering, the ISP needs indeed 10^3 or 10^4 trunks. The current RSVP/LDP should have no problem for intra-domain. But to setup such trunks over multiple domains, we will have problem here. As pointed out in our draft, we have thousands of AS's and routes over the network. To provide a similar level of traffic engineering functionality in multi-domain environment would require millions of trunks. We proposed a new protocol here to provide trunk setup mechanism for inter-domain only. When routers use BGRP to setup inter-domain trunks, the border routers will interface with intra-domain signaling protocols to set up internal trunks. BGRP is hopping between the border routers to trigger LSP setups. > > Some of those estimating higher than 10^4 LSPs tend to be interested > in voice and counting on doing one LSP per T1 voice trunk (not even > aggregating to trunk group) rather than engineering IP networks. > Those who believe that MPLS traffic engineering should be used solely > to provide more efficient routing through provider backbones may > consider this broken by design (though it may be essential to some > VoMPLS approaches, not that it would be the first time something > broken by design was proposed within or outside the IETF). > IMHO, I hope the ISP's consider traffic in terms of service classes and bandwidth only (as being defined in DiffServ), not in terms of application. The end users at network edge can choose any service class to carry their voice depending on how much they are willing to pay. > ... end of aside] > > > A question for the MPLS WG is "is this a problem the MPLS WG is trying > to solve?" Perhaps the MPLS deployment WG in the OPs area can help > provide an answer. > I have the same question. That's why I send the note to multiple lists. ;-) > Curtis Regards, -- Ping Pan http://www.cs.columbia.edu/~pingpan From owner-mpls@UU.NET Mon Jan 17 19:19:53 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10607 for ; Mon, 17 Jan 2000 19:19:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyll24617; Tue, 18 Jan 2000 00:18:46 GMT Received: by mail-control.mail.uu.net id QQhyll20748 for mpls-outgoing; Tue, 18 Jan 2000 00:18:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhyll20743 for ; Tue, 18 Jan 2000 00:18:21 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyll24446 for ; Mon, 17 Jan 2000 19:18:19 -0500 (EST) Received: from gateway.metrored.com.ar by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gateway.metrored.com.ar [200.47.48.198]) id QQhyll24201 for ; Tue, 18 Jan 2000 00:18:17 GMT Received: by GATEWAY with Internet Mail Service (5.5.2448.0) id ; Mon, 17 Jan 2000 21:18:49 -0300 Message-ID: From: =?iso-8859-1?Q?=22Bugallo=2C_Hern=E1n=22?= To: "'dwilder@baynetworks.com'" , Bugallo@ucayali.unired.net.pe, =?iso-8859-1?Q?=22Bugallo=2C_Hern=E1n=22?= , jrstuart@telefonica.com.pe Cc: mpls@UU.NET Subject: RE: Books or courses Date: Mon, 17 Jan 2000 21:18:46 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA10607 Thank you very much, Thanks, Best regards Hernán Bugallo. Tecnologia & Networking. MetroRED Telecomunicaciones Paseo Colon 505-5š Piso (Buenos Aires)-ARG. C.P.:(1063). Tel: +(5411) +4344-7700 +(7829) > -----Mensaje original----- > De: dwilder@baynetworks.com [SMTP:dwilder@baynetworks.com] > Enviado el: lunes 17 de enero de 2000 17:33 > Para: Bugallo@ucayali.unired.net.pe; bugalloh@metrored.com.ar; > jrstuart@telefonica.com.pe > CC: mpls@UU.NET > Asunto: Re: Books or courses > > I would recommend starting w/ the following 2 drafts to get familiar w/ > MPLS: > A Framework for MPLS > Multiprotocol Label Switching Architecture > > Then you can move on to reading the LDP. > > Finaly, read the CR-LDP & RSVP specs. > > Dave > > ****************************************************************** > > Opinion: > The best book are the drafts , auto-learning , this is a personal > opinion. I > dont know any especialized MPLS book , but, I think that you have to > read MPLS > I-D, BGP RFCs. > > Jesus Rodriguez Stuart > > Network Solutions > Telefonica del Peru > Comunicaciones de Empresa > jrstuart@telefonica.com.pe > > +51-1- 210-4835 > Fax : +51-1-422-0591 > > > > "Bugallo, Hernán" wrote: > > > Hello all! > > I would like to understand the technology more easily, and learn > how it is > > applied in MPLS. > > Would have you, some type of training or course, which wanted to > share > > comigo? > > I am thankful to all. > > > > Hernán Bugallo. > > Tecnologia & Networking. > > MetroRED Telecomunicaciones > > Paseo Colon 505-5š Piso (Buenos Aires)-ARGENTINA. > > C.P.:(1063). Tel: +(5411) +4344-7700 +(7829) > > -- > > > From owner-mpls@UU.NET Tue Jan 18 02:00:00 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18397 for ; Tue, 18 Jan 2000 01:59:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyml00083; Tue, 18 Jan 2000 06:58:53 GMT Received: by mail-control.mail.uu.net id QQhyml25805 for mpls-outgoing; Tue, 18 Jan 2000 06:58:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyml25797 for ; Tue, 18 Jan 2000 06:58:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyml26667; Tue, 18 Jan 2000 01:58:28 -0500 (EST) From: host8@crescotek.com Received: from smtc.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtc.net [208.233.32.10]) id QQhyml29595; Tue, 18 Jan 2000 06:58:28 GMT Received: from LocalHost ([208.26.26.3]) by smtc.net (8.8.4/8.8.4) with SMTP id BAA08913; Tue, 18 Jan 2000 01:44:17 -0500 Message-Id: <200001180644.BAA08913@smtc.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain MessageID: <3ga8iqwwkyj76fb.180120000147@LocalHost> Date: Tue, 18 Jan 2000 01:47:33 X-Mailer: Internet Mail Service [14.2.15.24] (Linux; I) Sensitivity: Restricted References: 0A64156C4 Subject: SERIOUS INVESTORS CHECK THIS OUT! (j739r0) To: X-Accept-Language: en X-See-Also: 0D634C9DD Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >======================================> January 18, 2000 =>=>=> SERIOUS INVESTORS CHECK THIS OUT! This newsletter is considered by many to be an industry leader Hundreds of hours of research go into finding growth companies that offer serious growth potential. +++++++++++++++++++++++++++++++++++++++ Sign up for your chance to WIN $5000 and receive a free trial subscription to our Stock - Investment Newsletters at http://www.stocktip.bizland.com +++++++++++++++++++++++++++++++++++++++ Well stock fans, it doesn't get any better than what we are witnessing right now in this sizzling stock market. We would like to introduce you to National Law Library ( OTC BB: ELAW ). Recently their stock price and volume has increased. Read on and your will see why we think that this is a company on the move. Please read our disclaimer at the bottom of this News Launch. >======================================> THIS WEEK'S PICK: National Law Library (OTC: BB ELAW ) National Law Library (OTC: BB ELAW ) OUTSTANDING: 23,600,000 FLOAT: 1,800,000 RECENT PRICE: $3.75 >======================================> =>=>=> ABOUT THE COMPANY National Law Library (ELAW) is an on-line virtual law library service that allows lawyers and judges fast, easy and portable access to regulations, statutes, and case law. By utilizing ELAW’s patented LITIDEX search engine legal professionals can access needed information and research faster, easier, and less expensively than ever before. Typically ELAW charges $35-$50 per month for their service. This is a tiny fraction of what the major competitors charge for similar services. ELAW can provide superior performance at much lower prices because they are a true “virtual service”. They have no publishing or CD ROM production expenses. The company also delivers only the facts. No legal opinions are offered thereby eliminating legal expense and the associated liability. ELAW is currently operating in 43 states including New York and should be in all 50 states this quarter. That is up from 6 states of November 1999. =>=>=> MOMENTUM IS RISING: Lois Law (LOIS) is a similar company and it has 20.9 million outstanding shares and 4 million in float. LOIS has had a huge stock run-up in price the last month. Current price: $30 ELAW is currently performing above its 10-day moving average line, indicating short-term momentum. A positive divergence from this point of reference indicates an uptrend. If the stock is below its 50 or 200-day moving average lines, but above its 10-day line, it is a good sign for short-term strength that further signals increasing momentum. If this positive divergence occurs on heavy relative volume, then a trend reversal could be underway so watch for continued upside momentum. At Stock Pick Of The Month we feel ELAW is ready to make a run! =>=>=> ELAW IS POSITIONED FOR EXPLOSIVE GROWTH: The company anticipates second year sales of $15,000,000 and net earnings of over $7,000,000. The company is fully reporting and is debt free. =>=>=> MARKET SUMMARY: The market for legal research is huge and growing. There are almost 1,000,000 lawyers in the U.S. Today with about 40,000 new lawyers entering the job market each year. Civil litigation has increased 28% since 1984 and criminal litigation has increased a staggering 55% over the same period. The need for access to accurate, up-to-date information is more acute today than ever before. Conservative estimates for the on-line legal information is estimated to be about 1.8 billion in 1998 growing to 2.7 billion by 2002. There are currently approximately 12-15 companies providing on-line services with Westlaw R and Lexis R being the largest. By providing information faster and less expensively, ELAW is poised to be a major player in this lucrative market. =>=>=> COMPETITIVE ADVANTAGES: National Law Library has several key competitive advantages over the current and future competition. the Litidex Search Engine: This proprietary, patented search engine gives ELAW a huge advantage over the competition. It would cost a start up company several million dollars and 2-3 years to develop a similar search engine. =>=>=> NO DEBT: National Law Library is debt free and has already spent the bulk of the research & development costs. =>=>=> EASE OF USE: ELAW’s service requires no software downloads or CD ROMS. This makes their information available from any computer by just entering your password. =>=>=> PRICE: ELAW charges $34.95 - $49.95 per month. Competitors charge from $200 - $10,000 plus per month? ELAW has no download fees or per use charges. ELAW also requires no long term contracts and they offer Twenty-four Hour on-line technical support. =>=>=> NEW EDITIONS TO IT'S BOARD OF DIRECTORS: ELAW has made some significant additions to it's board of directors which are as follows: W. Paul Thayer, former Deputy Secretary of Defense under the Reagan Administration. Mr Thayer is also a retired NASA astronaut and former chairman of Ling-Temco-Vought where he increased annual sales from 195MM to 800MM (million). He was also Chairman of the Chamber of Commerce of the United States. Mr Thayer received the Distinguished Flying Cross and two presidential citations while in the Navy. Capt. Eugene A. Cernan, USN Retired. Current Chairman of Johnson Engineering Corp. and a Former NASA astronaut. While with NASA Capt Cernan flew several Gemini and Apollo missions. He was the last astronaut to walk on the moon as commander of the Apollo XVII mission. George A. Roberts, former chairman of Teledyne Corporation and the first president of the Metal Powder Industries Federation. =>=>=> CONCLUSION: National Law Library is poised for substantial growth. As in other industries companies that provide superior service at better prices generally flourish. National Law Library has definitive technical, marketing management and cost advantage that should result in ELAW becoming a dominant company in the on-line information resource market. +++++++++++++++++++++++++++++++++++++++ Sign up for your chance to WIN $5000 and receive a free trial subscription to our Stock - Investment Newsletters at http://www.stocktip.bizland.com +++++++++++++++++++++++++++++++++++++++ =>=>=> DISCLAIMER: All bulletins published by Stock Pick Of The Month are paid advertisements by the Company and/or another party and has been sent to you for no charge. This is a service provided by Stock Pick Of The Month to public companies so they can disseminate recent significant developments, which potentially can affect their share price. This is not an offer to buy and sell any security, which can only be made through a registered representative. The information contained herein is based upon sources that we consider reliable but is not guaranteed by Stock Pick Of The Month. Stock Pick Of The Month makes no warrantee as to the accuracy or completeness of the above information. Certain of the statements contained in our news releases are Forward-looking statements. While these statements reflect the Corporation's current beliefs, they are subject to uncertainties and risks that could cause actual results to differ materially. These factors include, but are not limited to, the demand for the Corporations products and services, economic and competitive conditions. Stock Pick Of The Month may act as a consultant to the companies reviewed in this publication and may receive compensation in cash or stock for promotional or public relations services, including web site development. The compensation received by Stock Pick Of The Month from the companies reported upon should be viewed by readers as a potential conflict of interest. Furthermore, investing in Micro-cap or Small-cap securities is highly speculative and carries a high degree of risk. The stocks of these companies profiled by Stock Pick Of The Month may experience huge gains in a short time frame upon dissemination of this report. Consult a professional broker for advice on trading and investing. Stock Pick Of The Month may buy or sell the featured stocks at anytime. Stock Pick Of The Month has been paid $1500 for their profile of National Law Library (OTC: BB ELAW ) >======================================> +++++++++++++++++++++++++++++++++++++++++++++++++++ For Removal Please reply with Remove in the subject or call toll free 877-202-0942 and you will be permanently removed from future mailings. +++++++++++++++++++++++++++++++++++++++++++++++++++ From owner-mpls@UU.NET Tue Jan 18 06:17:15 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27781 for ; Tue, 18 Jan 2000 06:17:15 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhynd01674; Tue, 18 Jan 2000 11:15:41 GMT Received: by mail-control.mail.uu.net id QQhynd16258 for mpls-outgoing; Tue, 18 Jan 2000 11:15:05 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhync16163 for ; Tue, 18 Jan 2000 11:14:49 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhync14041; Tue, 18 Jan 2000 06:14:49 -0500 (EST) Received: from bells.cs.ucl.ac.uk by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: bells.cs.ucl.ac.uk [128.16.5.31]) id QQhync01642; Tue, 18 Jan 2000 11:14:48 GMT Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 18 Jan 2000 11:14:23 +0000 To: Ping Pan cc: curtis@avici.com, Ping Pan , RSVP , mpls , diffserv , te-wg , Henning Schulzrinne , Ellen Hahne Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management In-reply-to: Your message of "Mon, 17 Jan 2000 18:03:47 EST." <38839FD3.34430465@dnrc.bell-labs.com> Date: Tue, 18 Jan 2000 11:14:23 +0000 Message-ID: <9755.948194063@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-mpls@UU.NET Precedence: bulk In message <38839FD3.34430465@dnrc.bell-labs.com>, Ping Pan typed: hmm - interesting - thouhg i am still not sure why you can't work on an evolutionary path with RSVP rather than a whole new protocol but alternatively, what i'd like is to do a joint re-design of inter-domain routing, and inter-domain signaling rather than just pile more and more things into BGP and new signaling protocols...one possibility: to use NIMROD architecture http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html to exchange two types of thing: 1/ tag a map for a region (aka core, or trunk area) with current traffic load advertisement (what one wishes to export as effective available capacity -the map based approach alows you to scale state and size of exchanges...the use of IP or AS numbers or MPLS labels as the means of description of flows or aggregations is, imho, doomed to fail... 2/ tag requests for class based trunk adaptive sized DELTAs in capacity requests from routers at the edge of such a region - delta's allow you to scale the message rate, as well as the state - as the rate of edge device requests increases (iptel call setup or teardown rate goes up), you just modify the deltas to anticipate the desired trunk sizes...rsvp can be modified to do this relatively easily (documents on aggregate reservations only need modest changes in identifying who is requesting what of whom...) some discussion from noel chiappa and others might ensue (pnni too...?) cheers jon From owner-mpls@UU.NET Tue Jan 18 08:09:19 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28796 for ; Tue, 18 Jan 2000 08:09:19 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhynk26525; Tue, 18 Jan 2000 13:08:39 GMT Received: by mail-control.mail.uu.net id QQhynk05106 for mpls-outgoing; Tue, 18 Jan 2000 13:08:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhynk05096 for ; Tue, 18 Jan 2000 13:08:03 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhynk17537; Tue, 18 Jan 2000 08:08:02 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhynk26077; Tue, 18 Jan 2000 13:08:02 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Jan 18 08:07:14 EST 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.42.208]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id IAA09197; Tue, 18 Jan 2000 08:07:10 -0500 (EST) Message-ID: <388465B2.C85E8CF3@research.bell-labs.com> Date: Tue, 18 Jan 2000 08:08:02 -0500 From: Ping Pan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Jon Crowcroft CC: Ping Pan , curtis@avici.com, RSVP , mpls , diffserv , te-wg , Henning Schulzrinne , Ellen Hahne Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management References: <9755.948194063@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jon Crowcroft wrote: > > hmm - interesting - thouhg i am still not sure why you can't work on > an evolutionary path with RSVP rather than a whole new protocol > We've tried very hard to address the scaling problem with RSVP in the past year or so. Lou Berger, George Swallow, Lixia (and her students) and us have tried to enhance RSVP soft-state properties in various drafts. At this point, I believe RSVP (and its LSP extension) will have no problem whatsoever to handle intra-domain requirements. But RSVP does have the N**2 problem. When you look at the data we had gathered in Section-2 of our draft, any signaling protocol with N**2 property would be difficult work in inter-domain environment. One of the issues in RSVP is the notion of "route-pinning" at PATH processing time. This forces the routers to remember every reservation sender. At RESV processing time, the routers need to map the RESV to the previous PATH. This means that the routers need to maintain N**2 states. I think this is designed to prevent reservation looping problem. (BTW, Bob Braden told me a couple of years ago that during the RSVP design, people had thought about not storing PATH at routers, but...) In BGRP, we still use the two-pass reservation mechanism. But the PROBE messages (equivalent to RSVP PATH) gather the route information, and the receivers use the gathered routing data to construct sink-trees. At reservation time, the routers need only to remember sink-tree information, which is O(N). Later, -- Ping Pan htpp://www.cs.columbia.edu/~pingpan From owner-mpls@UU.NET Tue Jan 18 12:20:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03127 for ; Tue, 18 Jan 2000 12:20:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyob10174; Tue, 18 Jan 2000 17:20:26 GMT Received: by mail-control.mail.uu.net id QQhyob26638 for mpls-outgoing; Tue, 18 Jan 2000 17:20:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyob26621 for ; Tue, 18 Jan 2000 17:19:53 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyob03712 for ; Tue, 18 Jan 2000 12:19:50 -0500 (EST) Received: from hermes.balink.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: baisgate.balink.com [199.45.32.51]) id QQhyob11694 for ; Tue, 18 Jan 2000 17:19:49 GMT Received: by HERMES with Internet Mail Service (5.5.2448.0) id ; Tue, 18 Jan 2000 12:14:50 -0500 Message-ID: <4F8C08CC6E76D311AD1F00508B78724907EA0E@HERMES> From: "Martin, Christian" To: "'mpls@uu.net'" Subject: List Archives Date: Tue, 18 Jan 2000 12:14:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Greetings, Can someone please point me to the archives for this list? TIA, Chris From owner-mpls@UU.NET Tue Jan 18 12:29:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03253 for ; Tue, 18 Jan 2000 12:29:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyob17791; Tue, 18 Jan 2000 17:29:47 GMT Received: by mail-control.mail.uu.net id QQhyob27406 for mpls-outgoing; Tue, 18 Jan 2000 17:29:13 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyob27401 for ; Tue, 18 Jan 2000 17:29:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyob04874 for ; Tue, 18 Jan 2000 12:29:06 -0500 (EST) Received: from hawaii.globewebs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hawaii.globewebs.com [199.202.42.148]) id QQhyob15515 for ; Tue, 18 Jan 2000 17:29:06 GMT Received: from cahqsms01.teleglobe.ca (cahqsms01.Teleglobe.CA [192.168.10.10]) by hawaii.globewebs.com (8.8.8/8.8.8) with ESMTP id MAA16741; Tue, 18 Jan 2000 12:28:50 -0500 (EST) Received: by cahqsms01-bkp.Teleglobe.CA with Internet Mail Service (5.5.2448.0) id ; Tue, 18 Jan 2000 12:29:05 -0500 Message-ID: From: "Hamza, Ahmed" To: "'Martin, Christian'" , "'mpls@uu.net'" Subject: RE: List Archives Date: Tue, 18 Jan 2000 12:29:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03253 There are two archive sites. http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html ftp://ftpeng.cisco.com/ftp/mpls/mail/mailindex.html Regards, ---------------------------------------- Ahmed Hamza Senior Advisor, ATM Technology Teleglobe Inc Tel. (514) 868-8936 Fax. (514) 868-7598 Email : Ahmed.Hamza@teleglobe.ca ---------------------------------------- -----Message d'origine----- De: Martin, Christian [ mailto:CMartin@mercury.balink.com ] Date: 18 janvier, 2000 12:15 Ā: 'mpls@uu.net' Objet: List Archives Greetings, Can someone please point me to the archives for this list? TIA, Chris From owner-mpls@UU.NET Tue Jan 18 12:34:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03390 for ; Tue, 18 Jan 2000 12:34:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhynz23745; Tue, 18 Jan 2000 16:49:23 GMT Received: by mail-control.mail.uu.net id QQhynz16158 for mpls-outgoing; Tue, 18 Jan 2000 16:48:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhynz16144 for ; Tue, 18 Jan 2000 16:48:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhynz29138 for ; Tue, 18 Jan 2000 11:48:17 -0500 (EST) Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQhynz20141 for ; Tue, 18 Jan 2000 16:48:16 GMT Received: by smtp2.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Jan 2000 16:48:10 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1612A2@monk.datcon.co.uk> From: Nick Weeds To: "'rohit@ficon-tech.com'" , "'lberger@labn.net'" , "'mpls@uu.net'" Subject: LSP merge & RSVP Date: Tue, 18 Jan 2000 16:47:58 -0000 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I would like to confirm the mechanics of LSP merging when LSPs are set up using RSVP. It appears that this area has been discussed on the mailing list before, but the mailing list archive and the current drafts don't appear to state the mechanism to be used. Interoperability is unlikely unless a common mechanism is used. Suppose we have the following setup: A \ \ C===D===E / / B Suppose that both A and B send Path messages. The Path messages have identical RSVP SESSION objects specifying tunnel endpoint address E, but different Sender Templates (specifying different LSP IDs). Suppose that LSP merging at C is possible - C is capable of LSP merging - Shared Explicit style is used - Both Path messages have "Merge permitted" flag in Session Attributes set - Explicit Route objects in the Path messages are compatible - QoS parameters are compatible. I believe that LSP merging is signalled as follows. - C forwards both Path messages to D. - D forwards both Path messages to E. - E decides to merge LSPs. It assigns a single incoming label and sends a single Resv to D. This Resv specifies Shared Explicit style, and a FlowSpec suitable for the merged LSP. It contains two FilterSpecs, one for A and one for B. It contains a Label object for each FilterSpec, but specifies identical label values for A and B. - D assigns a single incoming label and sends a single Resv to C. This Resv also specifies identical label values for A and B. - C is the merge point. It assigns two incoming labels, one for A and one for B. It sends one Resv to A and one Resv to B. Each Resv contains a single FilterSpec and a single Label. Is this correct? This approach seems to be consistent with normal RSVP behaviour, and draft-ietf-mpls-rsvp-lsp-tunnel allows identical label values in a Resv message. The alternative would be that C merges the two Path messages and sends a single Path message to D. - C forwards a single Path message to D. - D forwards a single Path message to E. - E assigns a single incoming label and sends a single Resv to D. This Resv contains a single FilterSpec and a single Label. - D assigns a single incoming label and sends a single Resv to C. This Resv contains a single FilterSpec and a single Label. - C assigns two labels, one for A and one for B. It sends one Resv to A and one Resv to B. Each Resv contains a single FilterSpec and a single Label. The alternative approach is less consistent with normal RSVP behaviour (Path messages are never merged in normal RSVP), but it could probably be made to work. The responsibilities of the merge point and the egress point are quite different with the two approaches, so interoperability is unlikely unless the two implementations agree on a common approach. Nick. From owner-mpls@UU.NET Tue Jan 18 12:43:09 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03575 for ; Tue, 18 Jan 2000 12:43:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyoc24096; Tue, 18 Jan 2000 17:43:11 GMT Received: by mail-control.mail.uu.net id QQhyoc28475 for mpls-outgoing; Tue, 18 Jan 2000 17:42:35 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyoc28470 for ; Tue, 18 Jan 2000 17:42:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyoc29594 for ; Tue, 18 Jan 2000 12:42:29 -0500 (EST) Received: from hermes.balink.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: baisgate.balink.com [199.45.32.51]) id QQhyoc23485 for ; Tue, 18 Jan 2000 17:42:29 GMT Received: by HERMES with Internet Mail Service (5.5.2448.0) id ; Tue, 18 Jan 2000 12:37:29 -0500 Message-ID: <4F8C08CC6E76D311AD1F00508B78724907EA0F@HERMES> From: "Martin, Christian" To: "'Hamza, Ahmed'" , "Martin, Christian" , "'mpls@uu.net'" Subject: RE: List Archives Date: Tue, 18 Jan 2000 12:37:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03575 Ahmed, Many Thanks! It appears that the Cisco link is broken, but the cell-relay link is good. Regards, Chris >-----Original Message----- >From: Hamza, Ahmed [mailto:Ahmed.Hamza@teleglobe.ca] >Sent: Tuesday, January 18, 2000 11:29 AM >To: 'Martin, Christian'; 'mpls@uu.net' >Subject: RE: List Archives > > >There are two archive sites. > >http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html > >ftp://ftpeng.cisco.com/ftp/mpls/mail/mailindex.html > >Regards, >---------------------------------------- >Ahmed Hamza >Senior Advisor, ATM Technology > Teleglobe Inc > Tel. (514) 868-8936 > Fax. (514) 868-7598 > Email : Ahmed.Hamza@teleglobe.ca > ---------------------------------------- > >-----Message d'origine----- >De: Martin, Christian [ mailto:CMartin@mercury.balink.com > ] >Date: 18 janvier, 2000 12:15 >Ā: 'mpls@uu.net' >Objet: List Archives > > >Greetings, > >Can someone please point me to the archives for this list? > >TIA, >Chris > From owner-mpls@UU.NET Tue Jan 18 13:41:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04450 for ; Tue, 18 Jan 2000 13:41:05 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyog00121; Tue, 18 Jan 2000 18:41:05 GMT Received: by mail-control.mail.uu.net id QQhyog11196 for mpls-outgoing; Tue, 18 Jan 2000 18:40:36 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyog11188 for ; Tue, 18 Jan 2000 18:40:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyog14005 for ; Tue, 18 Jan 2000 13:40:10 -0500 (EST) Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQhyog29332 for ; Tue, 18 Jan 2000 18:40:10 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Jan 2000 13:39:07 -0500 Message-ID: From: "Agranoff, Saul" To: "'mpls@uu.net'" Subject: RE: LSP merge & RSVP Date: Tue, 18 Jan 2000 13:39:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I think there are some problems here... See below. > -----Original Message----- > From: Nick Weeds [mailto:NPW@datcon.co.uk] > Sent: Tuesday, January 18, 2000 11:48 AM > To: 'rohit@ficon-tech.com'; 'lberger@labn.net'; 'mpls@uu.net' > Subject: LSP merge & RSVP > Importance: Low > > > I would like to confirm the mechanics of LSP merging when > LSPs are set up > using RSVP. It appears that this area has been discussed on > the mailing > list before, but the mailing list archive and the current drafts don't > appear to state the mechanism to be used. Interoperability > is unlikely > unless a common mechanism is used. > > Suppose we have the following setup: > > A > \ > \ > C===D===E > / > / > B > > Suppose that both A and B send Path messages. The Path messages have > identical RSVP SESSION objects specifying tunnel endpoint > address E, but > different Sender Templates (specifying different LSP IDs). > > Suppose that LSP merging at C is possible > - C is capable of LSP merging > - Shared Explicit style is used Shared Explicit is not known in Path messages. Furthermore, Shared Explicit is a term for RESOURCE sharing (i.e. 'reservations'), not for LABEL sharing. I see no reason why FF-styled flows cannot use shared labels, if we can nail down the rules. > - Both Path messages have "Merge permitted" flag in Session > Attributes set > - Explicit Route objects in the Path messages are compatible "Compatible" is an interesting term. The Explicit Route List must be IDENTICAL from C onward, and also must contain all STRICT subobjects, consisting of full 32-bit IP addresses, all the way to the destination LSR's address. If there are any loose objects or any subnets in the Explicit Route List, or if the Explicit Route List is partially specified, then all bets are off. > - QoS parameters are compatible. Again, "compatible" is interesting. Can we define "compatibility" here? > > I believe that LSP merging is signalled as follows. > - C forwards both Path messages to D. > - D forwards both Path messages to E. > - E decides to merge LSPs. > It assigns a single incoming label and sends a single > Resv to D. E cannot assign the same label to both flows unless it knows that there is at least one merge-capable LSR upstream, where the two flows are conjoined (not sure if this is the right term, but in this case E must know that EITHER C or D is merge-capable.) How does E know this? It isn't in the protocol, is it? In fact, unless the RECORD_ROUTE object is used, E doesn't even KNOW that the upstream links are in common. Perhaps a way to solve this is to force the use of RECORD_ROUTE (if merging is to be allowed) AND TO ADD A 'MERGE-CAPABLE' BIT to the 'Flags' section of the RECORD_ROUTE subobject? If we did this, then LSR 'E' could do as you say, by analyzing the RECORD_ROUTE objects in the two Path State Blocks. > This Resv specifies Shared Explicit style, and a FlowSpec > suitable for the merged LSP. Again, SE/FF is a decision as to whether both flows are going to be active at the same time. If both senders are sending independently of each other, it is my understanding that FF style must be used. But I don't think this changes the label-merge scenario you're proposing. > It contains two FilterSpecs, one for A and one for B. > It contains a Label object for each FilterSpec, but > specifies identical label values for A and B. > - D assigns a single incoming label and sends a single Resv > to C. This Resv also specifies identical label values > for A and B. > - C is the merge point. > It assigns two incoming labels, one for A and one for B. > It sends one Resv to A and one Resv to B. > Each Resv contains a single FilterSpec and a single Label. > > Is this correct? This approach seems to be consistent with > normal RSVP > behaviour, and draft-ietf-mpls-rsvp-lsp-tunnel allows > identical label values > in a Resv message. > > The alternative would be that C merges the two Path messages > and sends a > single Path message to D. > - C forwards a single Path message to D. > - D forwards a single Path message to E. > - E assigns a single incoming label and sends a single Resv > to D. This Resv contains a single FilterSpec and a single > Label. > - D assigns a single incoming label and sends a single Resv > to C. This Resv contains a single FilterSpec and a single > Label. > - C assigns two labels, one for A and one for B. > It sends one Resv to A and one Resv to B. > Each Resv contains a single FilterSpec and a single Label. > > The alternative approach is less consistent with normal RSVP > behaviour (Path > messages are never merged in normal RSVP), but it could > probably be made to > work. This approach may work. It may offend the RFC2205 purists. It seems like it HELPS the scaling properties of RSVP. There is still the issue of how to generate the SENDER_TSPEC for the 'merged Path' message. The SE/FF question is normally made at the egress point. But let's say that we could decide at node C whether FF or SE style is appropriate. (In one case the resulting TSPEC is additive, while in the other case it's some kind of LUB calculation) But: Let's say that one flow is up and established, and the second 'Path' message starts. This could cause the SENDER_TSPEC in the 'Path' messages from C-to-D to 'increase'. This COULD result in some resource reservation failing somewhere downstream, which COULD cut off the already-established LSP. Somewhat farfetched? I'm not sure. > > The responsibilities of the merge point and the egress point are quite > different with the two approaches, so interoperability is > unlikely unless > the two implementations agree on a common approach. > > Nick. > I agree with Nick. We need guidelines and rules for Label Merging if any interoperability is a goal. There are also some holes in the operational rules which need to be solved. Saul Agranoff Harris & Jeffries, Inc. From owner-mpls@UU.NET Tue Jan 18 15:13:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05368 for ; Tue, 18 Jan 2000 15:13:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyom24335; Tue, 18 Jan 2000 20:13:53 GMT Received: by mail-control.mail.uu.net id QQhyom02590 for mpls-outgoing; Tue, 18 Jan 2000 20:13:20 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyom02571 for ; Tue, 18 Jan 2000 20:13:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyom16937 for ; Tue, 18 Jan 2000 15:13:17 -0500 (EST) Received: from coltrane.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQhyom22109 for ; Tue, 18 Jan 2000 20:13:17 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Jan 2000 20:13:12 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1612A4@monk.datcon.co.uk> From: Nick Weeds To: "'Agranoff, Saul'" Cc: "'rohit@ficon-tech.com'" , "'lberger@labn.net'" , "'mpls@uu.net'" Subject: RE: LSP merge & RSVP Date: Tue, 18 Jan 2000 20:12:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Saul, Thanks for your comments. Key points before launching into details: - I was under the impression that setup of multipoint-to-point LSPs using RSVP is a "solved" problem (and probably even supported in some existing products). I was trying to understand existing solutions, not propose new solutions. Maybe I was wrong and it's still an open problem. - I did realize that there are detailed questions to answer whichever approach is followed. I deliberately avoided discussing the details in order to focus on the basic question: do we forward all Path messages then send back Resvs with FilterSpecs specifying identical labels, or do we merge the Paths into a single Path message. I still want to concentrate on answers to the key questions: - Is LSP merge using RSVP a "solved" problem ? - If so, what is the basic mechanism ? More detailed comments follow below... > -----Original Message----- > From: Agranoff, Saul [mailto:saula@hjinc.com] > Sent: 18 January 2000 18:39 > To: 'mpls@uu.net' > Subject: RE: LSP merge & RSVP > > > I think there are some problems here... See below. > > > -----Original Message----- > > From: Nick Weeds [mailto:NPW@datcon.co.uk] > > Sent: Tuesday, January 18, 2000 11:48 AM > > To: 'rohit@ficon-tech.com'; 'lberger@labn.net'; 'mpls@uu.net' > > Subject: LSP merge & RSVP > > Importance: Low > > > > > > I would like to confirm the mechanics of LSP merging when > > LSPs are set up > > using RSVP. It appears that this area has been discussed on > > the mailing > > list before, but the mailing list archive and the current > drafts don't > > appear to state the mechanism to be used. Interoperability > > is unlikely > > unless a common mechanism is used. > > > > Suppose we have the following setup: > > > > A > > \ > > \ > > C===D===E > > / > > / > > B > > > > Suppose that both A and B send Path messages. The Path > messages have > > identical RSVP SESSION objects specifying tunnel endpoint > > address E, but > > different Sender Templates (specifying different LSP IDs). > > > > Suppose that LSP merging at C is possible > > - C is capable of LSP merging > > - Shared Explicit style is used > > Shared Explicit is not known in Path messages. True enough. If reservation style is important, then we must wait until the Resv message to decide what to do. This is OK with approach #1. It is a problem for approach #2. > Furthermore, Shared Explicit is a term for RESOURCE sharing > (i.e. 'reservations'), not for LABEL sharing. I see no > reason why FF-styled flows cannot use shared labels, if we > can nail down the rules. I get the impression that label sharing for FF style reservations isn't really the expected behaviour. Also, you could argue that FF style bars resource sharing, that label sharing forces resource sharing, and that FF style therefore bars label sharing. > > - Both Path messages have "Merge permitted" flag in Session > > Attributes set > > - Explicit Route objects in the Path messages are compatible > > "Compatible" is an interesting term. The Explicit Route List > must be IDENTICAL from C onward, and also must contain all > STRICT subobjects, consisting of full 32-bit IP addresses, all > the way to the destination LSR's address. > > If there are any loose objects or any subnets in the Explicit > Route List, or if the Explicit Route List is partially > specified, then all bets are off. In fact with approach #1 the merge decision needn't go into such details. Suppose that the merge decision is postponed until the Resv is processed, and that the merge decision "zips back" from the egress point to the merge point. - At the egress point the Explicit Route Object is effectively empty, so detailed ERO conditions are unnecessary. - Transit points make merge decisions in order starting at the penultimate node and progressing towards the ingress nodes (because this is the order that they process the Resv). - Each transit point will merge the two Paths based on - whether the two Paths have the same outgoing interface and outgoing label - whether the two Paths have the same incoming interface. These considerations pretty much determine the LSP merge action. Of course, different EROs might well result in different outgoing interfaces and therefore no LSP merging - but it's still possible that different EROs will end up using the same outgoing interface. With approach #2 the EROs must be checked in detail before merging the Path messages. > > - QoS parameters are compatible. > > Again, "compatible" is interesting. Can we define "compatibility" > here? Let's come back to this later, when some of the more basic questions have been answered. In the meantime, I think it's clear that if one Path specifies RSVP COS Service and the other specifies IntServ Controlled Load Service then they aren't compatible. This would be a problem even when there is no LSP merging. > > I believe that LSP merging is signalled as follows. > > - C forwards both Path messages to D. > > - D forwards both Path messages to E. > > - E decides to merge LSPs. > > It assigns a single incoming label and sends a single > > Resv to D. > > E cannot assign the same label to both flows unless it knows > that there is at least one merge-capable LSR upstream, where > the two flows are conjoined (not sure if this is the right term, > but in this case E must know that EITHER C or D is merge-capable.) > > How does E know this? It isn't in the protocol, is it? Good question. I don't think it's in the protocol. It might be possible to fiddle around with the "merge permitted" flag in Session Attributes, but I don't wish to advocate this. (The "merge permitted" flag claims to control RSVP Session merging not LSP merging. I really don't want to introduce the additional complication of RSVP session merging.) In the short term, E would probably have to rely on configuration information and/or rules of thumb. eg "Don't send back merged labels if the incoming interface is ATM" or "Don't send back merged labels if unless the incoming interface is configured to do so." I agree that it would be nice to do better... > In fact, unless the RECORD_ROUTE object is used, E doesn't > even KNOW that the upstream links are in common. > > Perhaps a way to solve this is to force the use of RECORD_ROUTE > (if merging is to be allowed) AND TO ADD A 'MERGE-CAPABLE' BIT > to the 'Flags' section of the RECORD_ROUTE subobject? > > If we did this, then LSR 'E' could do as you say, by analyzing > the RECORD_ROUTE objects in the two Path State Blocks. > > > > This Resv specifies Shared Explicit style, and a FlowSpec > > suitable for the merged LSP. > > Again, SE/FF is a decision as to whether both flows are going > to be active at the same time. If both senders are sending > independently of each other, it is my understanding that > FF style must be used. But I don't think this changes the > label-merge scenario you're proposing. The SE/FF question doesn't affect the basic scenario I'm describing. I agree that using SE for LSP merging is stretching the original meaning of SE style reservations quite a bit... > > It contains two FilterSpecs, one for A and one for B. > > It contains a Label object for each FilterSpec, but > > specifies identical label values for A and B. > > - D assigns a single incoming label and sends a single Resv > > to C. This Resv also specifies identical label values > > for A and B. > > - C is the merge point. > > It assigns two incoming labels, one for A and one for B. > > It sends one Resv to A and one Resv to B. > > Each Resv contains a single FilterSpec and a single Label. > > > > Is this correct? This approach seems to be consistent with > > normal RSVP > > behaviour, and draft-ietf-mpls-rsvp-lsp-tunnel allows > > identical label values > > in a Resv message. > > > > The alternative would be that C merges the two Path messages > > and sends a > > single Path message to D. > > - C forwards a single Path message to D. > > - D forwards a single Path message to E. > > - E assigns a single incoming label and sends a single Resv > > to D. This Resv contains a single FilterSpec and a single > > Label. > > - D assigns a single incoming label and sends a single Resv > > to C. This Resv contains a single FilterSpec and a single > > Label. > > - C assigns two labels, one for A and one for B. > > It sends one Resv to A and one Resv to B. > > Each Resv contains a single FilterSpec and a single Label. > > > > The alternative approach is less consistent with normal RSVP > > behaviour (Path > > messages are never merged in normal RSVP), but it could > > probably be made to > > work. > > This approach may work. It may offend the RFC2205 purists. > It seems like it HELPS the scaling properties of RSVP. I suspect that approach #2 would involve a variety of nasty problems because of deviation from RFC2205. Approach #2 probably doesn't affect the scaling of LSP setup - even if with Path message merging it would typically be necessary to send a new merged Path message every time a new ingress is added. However, it might help the scaling of soft state refreshes. > There is still the issue of how to generate the SENDER_TSPEC > for the 'merged Path' message. The SE/FF question is normally > made at the egress point. But let's say that we could decide > at node C whether FF or SE style is appropriate. (In one case > the resulting TSPEC is additive, while in the other case it's > some kind of LUB calculation) > > But: Let's say that one flow is up and established, and the > second 'Path' message starts. This could cause the SENDER_TSPEC > in the 'Path' messages from C-to-D to 'increase'. This COULD > result in some resource reservation failing somewhere downstream, > which COULD cut off the already-established LSP. > > Somewhat farfetched? I'm not sure. Sounds like a significant problem to me. > > > > The responsibilities of the merge point and the egress > point are quite > > different with the two approaches, so interoperability is > > unlikely unless > > the two implementations agree on a common approach. > > > > Nick. > > > > I agree with Nick. We need guidelines and rules for Label Merging if > any interoperability is a goal. There are also some > holes in the operational rules which need to be solved. > > Saul Agranoff > Harris & Jeffries, Inc. > From owner-mpls@UU.NET Tue Jan 18 16:08:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05985 for ; Tue, 18 Jan 2000 16:08:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyoq02300; Tue, 18 Jan 2000 21:08:15 GMT Received: by mail-control.mail.uu.net id QQhyoq12731 for mpls-outgoing; Tue, 18 Jan 2000 21:07:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyoq12518 for ; Tue, 18 Jan 2000 21:07:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyoq25951 for ; Tue, 18 Jan 2000 16:07:24 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhyoq29213 for ; Tue, 18 Jan 2000 21:07:24 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Tue, 18 Jan 2000 16:07:23 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CDC6@email.quarrytech.com> From: "Abes, Andi" To: Nick Weeds , "'Agranoff, Saul'" Cc: "'mpls@uu.net'" Subject: RE: LSP merge & RSVP Date: Tue, 18 Jan 2000 16:07:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I've been batteling the same question for a while, and IMHO: - if the aim in merging path message is to reduce refresh traffic, a tunnel (hierarchy) can be used to between C-D-E, so that D is isolated from refresh messages (at least to some extent) made by A and B. This, of course, brings up the whole issue of hierarchies through RSVP signalling, which is a little neglected in the current draft. - Deciding to merge at any point other than the egress will make management and policy control a living hell - any router along the can will have to be configured/signaled if to merge and what. In the classic RSVP scheme, only the egress points need to maintain policy information regarding mergin. More over, the source of the traffic might indicate different policy (temporal or other, that doesn't mandate using different Tunnel ID's). Andi > -----Original Message----- > From: Nick Weeds [mailto:NPW@datcon.co.uk] > Sent: Tuesday, January 18, 2000 3:13 PM > To: 'Agranoff, Saul' > Cc: 'rohit@ficon-tech.com'; 'lberger@labn.net'; 'mpls@uu.net' > Subject: RE: LSP merge & RSVP > > > Saul, > > Thanks for your comments. > > Key points before launching into details: > - I was under the impression that setup of multipoint-to-point > LSPs using RSVP is a "solved" problem (and probably even > supported in some existing products). > I was trying to understand existing solutions, not propose > new solutions. > Maybe I was wrong and it's still an open problem. > - I did realize that there are detailed questions to answer > whichever approach is followed. I deliberately avoided > discussing the details in order to focus on the basic > question: do we forward all Path messages then send back > Resvs with FilterSpecs specifying identical labels, or > do we merge the Paths into a single Path message. > > I still want to concentrate on answers to the key questions: > - Is LSP merge using RSVP a "solved" problem ? > - If so, what is the basic mechanism ? > > More detailed comments follow below... > > > -----Original Message----- > > From: Agranoff, Saul [mailto:saula@hjinc.com] > > Sent: 18 January 2000 18:39 > > To: 'mpls@uu.net' > > Subject: RE: LSP merge & RSVP > > > > > > I think there are some problems here... See below. > > > > > -----Original Message----- > > > From: Nick Weeds [mailto:NPW@datcon.co.uk] > > > Sent: Tuesday, January 18, 2000 11:48 AM > > > To: 'rohit@ficon-tech.com'; 'lberger@labn.net'; 'mpls@uu.net' > > > Subject: LSP merge & RSVP > > > Importance: Low > > > > > > > > > I would like to confirm the mechanics of LSP merging when > > > LSPs are set up > > > using RSVP. It appears that this area has been discussed on > > > the mailing > > > list before, but the mailing list archive and the current > > drafts don't > > > appear to state the mechanism to be used. Interoperability > > > is unlikely > > > unless a common mechanism is used. > > > > > > Suppose we have the following setup: > > > > > > A > > > \ > > > \ > > > C===D===E > > > / > > > / > > > B > > > > > > Suppose that both A and B send Path messages. The Path > > messages have > > > identical RSVP SESSION objects specifying tunnel endpoint > > > address E, but > > > different Sender Templates (specifying different LSP IDs). > > > > > > Suppose that LSP merging at C is possible > > > - C is capable of LSP merging > > > - Shared Explicit style is used > > > > Shared Explicit is not known in Path messages. > > True enough. If reservation style is important, then we must > wait until the Resv message to decide what to do. > This is OK with approach #1. > It is a problem for approach #2. > > > Furthermore, Shared Explicit is a term for RESOURCE sharing > > (i.e. 'reservations'), not for LABEL sharing. I see no > > reason why FF-styled flows cannot use shared labels, if we > > can nail down the rules. > > I get the impression that label sharing for FF style > reservations isn't really the expected behaviour. > Also, you could argue that FF style bars resource sharing, > that label sharing forces resource sharing, and that FF > style therefore bars label sharing. > > > > - Both Path messages have "Merge permitted" flag in Session > > > Attributes set > > > - Explicit Route objects in the Path messages are compatible > > > > "Compatible" is an interesting term. The Explicit Route List > > must be IDENTICAL from C onward, and also must contain all > > STRICT subobjects, consisting of full 32-bit IP addresses, all > > the way to the destination LSR's address. > > > > If there are any loose objects or any subnets in the Explicit > > Route List, or if the Explicit Route List is partially > > specified, then all bets are off. > > In fact with approach #1 the merge decision needn't go into such > details. Suppose that the merge decision is postponed until the > Resv is processed, and that the merge decision "zips back" from > the egress point to the merge point. > - At the egress point the Explicit Route Object is effectively > empty, so detailed ERO conditions are unnecessary. > - Transit points make merge decisions in order starting at the > penultimate node and progressing towards the ingress nodes > (because this is the order that they process the Resv). > - Each transit point will merge the two Paths based on > - whether the two Paths have the same outgoing interface and > outgoing label > - whether the two Paths have the same incoming interface. > These considerations pretty much determine the LSP merge action. > Of course, different EROs might well result in different outgoing > interfaces and therefore no LSP merging - but it's still > possible that different EROs will end up using the same outgoing > interface. > > With approach #2 the EROs must be checked in detail before merging > the Path messages. > > > > - QoS parameters are compatible. > > > > Again, "compatible" is interesting. Can we define "compatibility" > > here? > > Let's come back to this later, when some of the more basic > questions have been answered. > In the meantime, I think it's clear that if one Path specifies > RSVP COS Service and the other specifies IntServ Controlled > Load Service then they aren't compatible. This would be a > problem even when there is no LSP merging. > > > > I believe that LSP merging is signalled as follows. > > > - C forwards both Path messages to D. > > > - D forwards both Path messages to E. > > > - E decides to merge LSPs. > > > It assigns a single incoming label and sends a single > > > Resv to D. > > > > E cannot assign the same label to both flows unless it knows > > that there is at least one merge-capable LSR upstream, where > > the two flows are conjoined (not sure if this is the right term, > > but in this case E must know that EITHER C or D is merge-capable.) > > > > How does E know this? It isn't in the protocol, is it? > > Good question. > > I don't think it's in the protocol. It might be possible > to fiddle around with the "merge permitted" flag in Session > Attributes, but I don't wish to advocate this. > (The "merge permitted" flag claims to control RSVP Session > merging not LSP merging. I really don't want to introduce > the additional complication of RSVP session merging.) > > In the short term, E would probably have to rely on configuration > information and/or rules of thumb. > eg "Don't send back merged labels if the incoming interface is ATM" > or "Don't send back merged labels if unless the incoming interface > is configured to do so." > I agree that it would be nice to do better... > > > In fact, unless the RECORD_ROUTE object is used, E doesn't > > even KNOW that the upstream links are in common. > > > > Perhaps a way to solve this is to force the use of RECORD_ROUTE > > (if merging is to be allowed) AND TO ADD A 'MERGE-CAPABLE' BIT > > to the 'Flags' section of the RECORD_ROUTE subobject? > > > > If we did this, then LSR 'E' could do as you say, by analyzing > > the RECORD_ROUTE objects in the two Path State Blocks. > > > > > > > This Resv specifies Shared Explicit style, and a FlowSpec > > > suitable for the merged LSP. > > > > Again, SE/FF is a decision as to whether both flows are going > > to be active at the same time. If both senders are sending > > independently of each other, it is my understanding that > > FF style must be used. But I don't think this changes the > > label-merge scenario you're proposing. > > The SE/FF question doesn't affect the basic scenario I'm describing. > I agree that using SE for LSP merging is stretching the original > meaning of SE style reservations quite a bit... > > > > It contains two FilterSpecs, one for A and one for B. > > > It contains a Label object for each FilterSpec, but > > > specifies identical label values for A and B. > > > - D assigns a single incoming label and sends a single Resv > > > to C. This Resv also specifies identical label values > > > for A and B. > > > - C is the merge point. > > > It assigns two incoming labels, one for A and one for B. > > > It sends one Resv to A and one Resv to B. > > > Each Resv contains a single FilterSpec and a single Label. > > > > > > Is this correct? This approach seems to be consistent with > > > normal RSVP > > > behaviour, and draft-ietf-mpls-rsvp-lsp-tunnel allows > > > identical label values > > > in a Resv message. > > > > > > The alternative would be that C merges the two Path messages > > > and sends a > > > single Path message to D. > > > - C forwards a single Path message to D. > > > - D forwards a single Path message to E. > > > - E assigns a single incoming label and sends a single Resv > > > to D. This Resv contains a single FilterSpec and a single > > > Label. > > > - D assigns a single incoming label and sends a single Resv > > > to C. This Resv contains a single FilterSpec and a single > > > Label. > > > - C assigns two labels, one for A and one for B. > > > It sends one Resv to A and one Resv to B. > > > Each Resv contains a single FilterSpec and a single Label. > > > > > > The alternative approach is less consistent with normal RSVP > > > behaviour (Path > > > messages are never merged in normal RSVP), but it could > > > probably be made to > > > work. > > > > This approach may work. It may offend the RFC2205 purists. > > It seems like it HELPS the scaling properties of RSVP. > > I suspect that approach #2 would involve a variety of nasty > problems because of deviation from RFC2205. > > Approach #2 probably doesn't affect the scaling of LSP setup - > even if with Path message merging it would typically be necessary > to send a new merged Path message every time a new ingress is > added. However, it might help the scaling of soft state refreshes. > > > There is still the issue of how to generate the SENDER_TSPEC > > for the 'merged Path' message. The SE/FF question is normally > > made at the egress point. But let's say that we could decide > > at node C whether FF or SE style is appropriate. (In one case > > the resulting TSPEC is additive, while in the other case it's > > some kind of LUB calculation) > > > > But: Let's say that one flow is up and established, and the > > second 'Path' message starts. This could cause the SENDER_TSPEC > > in the 'Path' messages from C-to-D to 'increase'. This COULD > > result in some resource reservation failing somewhere downstream, > > which COULD cut off the already-established LSP. > > > > Somewhat farfetched? I'm not sure. > > Sounds like a significant problem to me. > > > > > > > The responsibilities of the merge point and the egress > > point are quite > > > different with the two approaches, so interoperability is > > > unlikely unless > > > the two implementations agree on a common approach. > > > > > > Nick. > > > > > > > I agree with Nick. We need guidelines and rules for Label > Merging if > > any interoperability is a goal. There are also some > > holes in the operational rules which need to be solved. > > > > Saul Agranoff > > Harris & Jeffries, Inc. > > > From owner-mpls@UU.NET Tue Jan 18 16:30:59 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06116 for ; Tue, 18 Jan 2000 16:30:58 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyos15174; Tue, 18 Jan 2000 21:30:57 GMT Received: by mail-control.mail.uu.net id QQhyos17566 for mpls-outgoing; Tue, 18 Jan 2000 21:30:24 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyos17561 for ; Tue, 18 Jan 2000 21:30:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyos06872 for ; Tue, 18 Jan 2000 16:30:03 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhyos14437 for ; Tue, 18 Jan 2000 21:30:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Jan 18 16:28:40 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.40.218]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA29221; Tue, 18 Jan 2000 16:28:31 -0500 (EST) Message-ID: <3884DB89.CCFCB2CE@lucent.com> Date: Tue, 18 Jan 2000 16:30:49 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Multi-Protocol Label Switching WG CC: George Swallow , Vijay Srinivasan Subject: New version of LDP state draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, A new version of the LDP state draft has been generated based on WG last call comments. The draft should be available soon from the IETF ftp site. The draft version is draft-ietf-mpls-ldp-state-03.txt and will be temporarily available at: http://www.mindspring.com/~ewgray/draft-ietf-mpls-ldp-state-03.txt Changes to the draft were relatively minor, consisting mostly of correction of inconsistencies between figures and text description (of the IDLE state in particular) and one inconsistency between the state draft and the LDP specification on which it was based. We do not feel that there are any open last call issues that are not addressed in this version. Thanks! -- Eric Gray From owner-mpls@UU.NET Tue Jan 18 17:30:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06698 for ; Tue, 18 Jan 2000 17:30:56 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyow18439; Tue, 18 Jan 2000 22:30:57 GMT Received: by mail-control.mail.uu.net id QQhyow29218 for mpls-outgoing; Tue, 18 Jan 2000 22:30:25 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhyow29209 for ; Tue, 18 Jan 2000 22:30:21 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyow04418 for ; Tue, 18 Jan 2000 17:30:13 -0500 (EST) From: mbender19@asean-mail.com Received: from itcampeche.edu.mx by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: kukulcan.itcampeche.edu.mx [207.249.19.7]) id QQhyow17871 for ; Tue, 18 Jan 2000 22:30:12 GMT Received: from computer by itcampeche.edu.mx (SMI-8.6/SMI-SVR4) id RAA18935; Tue, 18 Jan 2000 17:09:16 -0600 Date: Tue, 18 Jan 2000 17:09:16 -0600 Message-Id: <200001182309.RAA18935@itcampeche.edu.mx> To: Subject: adv: Search Engine Registration MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Sender: owner-mpls@UU.NET Precedence: bulk To be removed: 888-800-6339 X1377 I saw your listing on the internet. I work for a company that specializes in getting clients web sites listed as close to the top of the major search engines as possible. Our fee is only $29.95 per month to submit your site at least twice a month to over 350 search engines and directories. To get started and put your web site in the fast lane, call our toll free number below. Mike Bender 888-532-8842 * To be removed call: 888-800-6339 X1377 From owner-mpls@UU.NET Tue Jan 18 17:53:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06947 for ; Tue, 18 Jan 2000 17:53:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyox29635; Tue, 18 Jan 2000 22:53:56 GMT Received: by mail-control.mail.uu.net id QQhyox00680 for mpls-outgoing; Tue, 18 Jan 2000 22:53:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyox00672 for ; Tue, 18 Jan 2000 22:53:15 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyox15816; Tue, 18 Jan 2000 17:53:13 -0500 (EST) From: money3@aichi.com Received: from challenge.go-tisk.si by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [193.189.186.43]) id QQhyox00651; Tue, 18 Jan 2000 22:53:12 GMT Received: from 193.189.186.43 by challenge.go-tisk.si via SMTP (950413.SGI.8.6.12/940406.SGI) id XAA28747; Tue, 18 Jan 2000 23:53:15 -0800 Received: from mailhost.executiv.com[alt.executiv.com[208.8.76.65]] by executiv101.com (8.8.5/8.6.5) with SMTP id GAA00154 for ; Tue, 18 Jan 2000 17:44:39 -0600 (EST) To: ezmoney6@aichi.com Message-ID: <200249362.EBY100599@executiv101.com> Date: Tue, 18 Jan 00 17:44:39 EST Subject: FREE ~ MAKE 1 MILLION DOLLARS FAST!! Reply-To: ezmoney6@aichi.com X-UIDL: 3447bri9h78989nnjhyrd9mkh098muht5 Comments: Authenticated sender is Sender: owner-mpls@UU.NET Precedence: bulk THIS IS NOT A CHAIN LETTER! ABSOLUTELY NO SELLING ~ NO INVESTMENT ~ NO PRODUCTS TO PURCHASE ~ NO RISK!!! If You're Serious About Making BIG Money, THIS IS YOUR CHANCE ~ TAKE ITSERIOUSLY! For all of the details, please send a blank email, with "1 Million" in the subject box, to: nowork101@bigfoot.com You are on our in house safe list. If you would like to be removed, please just hit reply, and put Remove in the subject box, and you will be removed Immediately! Thank you. Jean Cook P.O. Box 14040 Bradenton, Fl. 34209 From owner-mpls@UU.NET Tue Jan 18 18:09:19 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07110 for ; Tue, 18 Jan 2000 18:09:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyoy08209; Tue, 18 Jan 2000 23:09:20 GMT Received: by mail-control.mail.uu.net id QQhyoy08329 for mpls-outgoing; Tue, 18 Jan 2000 23:08:45 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyoy08085 for ; Tue, 18 Jan 2000 23:08:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyoy17185 for ; Tue, 18 Jan 2000 18:08:24 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhyoy08732 for ; Tue, 18 Jan 2000 23:08:24 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Tue, 18 Jan 2000 18:08:23 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CDCB@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Subject: LSP hierarchies using RSVP Date: Tue, 18 Jan 2000 18:08:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Ok, I've been trying to figure out how to use / setup Label hierarchies using RSVP, and in a joint effort (with Rohit), reached the following 2 possibilities, each having its merits. My problem though is that both these approaches are not documented in the drafts in a straight to the point way. I'd be happy to hear opinions. Opaque tunnels In this mode, an pre-existing LSP (that might have been signaled using RSVP), is used to transparently connect 2 RSVP speakers. The routers that construct the tunnel (the "core" routers) are unaware of any higher level labels exchanged across it. This has the following properties: The state the needs to be maintained in the "core" routers does not include the "edge" reservations. Only the ingress of the tunnel is responsible to perform admission control through for the tunnel. A network topology as depicted below, will not allow router "w" to create a reservation towards "y" that utilizes the tunnel (marked with "="), since router "B" can not perform admission control to the tunnel. +--+ +--+ +--+ +--+ +--+ |x |-----|A |=====|B |====|C |----|y | +--+ +--+ +--+ +--+ +--+ | | | +--+ |w | +--+ This scenario will work as follows (assuming the tunnel is pre-established): Router "x" will issue a path message, that includes a label request. Route "A" will intercept this message, and send it towards router "y" on the existing LSP. The message is sent with no "router-alert" of any kind, and thus router "B" will not be aware of it's existence. Router "C" receives this message and intercepts it (since it intercepts all IP packets with protocol == RSVP). It then records the state, and forwards the request towards "y". "y" allocates a label, and sends a RESV message to "C" "C" realizes that the RESV message will be sent on an LSP, and thus allocates a 2 level label stack. The top label is the LSP label, the higher label indicates "y". The message is sent to "A" Router "B" is not aware of the RESV message be forward through him. "A" receives the RESV message, and reserves the resources. The RESV messages passed to "x" will only include 1 label. "Admission controlled" tunnels This type of a tunnel allows for correct operation in the scenario described above. Each router along the "core" network performs admission control, and thus any of them can merge additional paths onto the tunnel. The way it works: "x" sends a Path with a label request towards "y" "A" intercepts it. It adds on a "router-alert" label as the top label. "B" intercepts it, since it is flagged with the router alert. It associates the request with the reservation currently in place for the tunnel by examining the lower level label. It forwards the Path downstream, after updating the current Path state for the tunnel. "C" performs the same type of processing the "B" performed and then forwards the request to "y". "y" performs its own admission control and issues back a label. "C" assigns a 2 level label stack. The top label is the existing LSP's label. The higher label identifies "y". As the RESV message traverses the tunnel, each router will receive it, since it's destined to him. The message is updated with the top label used by that router for the existing LSP. "A" realizes his the egress of the tunnel, and only passes 1 label to "x". pros: This method allows a "egress targeted" tree to be built and maintained, while consuming only needed resources. Additional senders can join in the middle of the tunnel and cause an increase in reservation only in those parts of it where it's needed Cons: This scheme requires the "core" routers to maintain state for every "outer" tunnel that traverses them From owner-mpls@UU.NET Tue Jan 18 18:42:00 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07509 for ; Tue, 18 Jan 2000 18:41:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhypa27315; Tue, 18 Jan 2000 23:42:01 GMT Received: by mail-control.mail.uu.net id QQhypa11107 for mpls-outgoing; Tue, 18 Jan 2000 23:41:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhypa11101 for ; Tue, 18 Jan 2000 23:41:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhypa11048; Tue, 18 Jan 2000 18:41:08 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: necom830.hpcl.titech.ac.jp [131.112.32.132]) id QQhypa25327; Tue, 18 Jan 2000 23:41:07 GMT From: Masataka Ohta Message-Id: <200001182338.IAA14823@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA14823; Wed, 19 Jan 2000 08:37:48 +0859 Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management To: pingpan@research.bell-labs.com (Ping Pan) Date: Wed, 19 Jan 0 8:37:47 JST Cc: J.Crowcroft@cs.ucl.ac.uk, pingpan@dnrc.bell-labs.com, curtis@avici.com, rsvp@ISI.EDU, mpls@UU.NET, diffserv@ietf.org, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com In-Reply-To: <388465B2.C85E8CF3@research.bell-labs.com>; from "Ping Pan" at Jan 18, 100 10:52 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-mpls@UU.NET Precedence: bulk Ping Pan; > > hmm - interesting - thouhg i am still not sure why you can't work on > > an evolutionary path with RSVP rather than a whole new protocol > > > > We've tried very hard to address the scaling problem with RSVP in the > past year or so. Lou Berger, George Swallow, Lixia (and her students) > and us have tried to enhance RSVP soft-state properties in various > drafts. At this point, I believe RSVP (and its LSP extension) will have > no problem whatsoever to handle intra-domain requirements. But RSVP does > have the N**2 problem. When you look at the data we had gathered in > Section-2 of our draft, any signaling protocol with N**2 property would > be difficult work in inter-domain environment. As I have pointed out in RSVP-related WGs and several research papers, RSVP has no scalability problem from the begining. So, I agree with you that it is very hard (impossible) to solve your problem, because the problem does not exist. > One of the issues in RSVP is the notion of "route-pinning" at PATH > processing time. This forces the routers to remember every reservation > sender. At RESV processing time, the routers need to map the RESV to the > previous PATH. No. As I pointed it out in some I-D and the INET'97 paper, the solution is to route RESV first and let PATH follows the route. Note that route stabilization is easy that route-pinning is not necessary at all. There are simple reasons why BGP like policy can not be applicable to resource reservation. But it seems to me that the topic is to hard for you to understand. Masataka Ohta From owner-mpls@UU.NET Tue Jan 18 23:34:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11587 for ; Tue, 18 Jan 2000 23:34:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhypu23405; Wed, 19 Jan 2000 04:34:28 GMT Received: by mail-control.mail.uu.net id QQhypu06697 for mpls-outgoing; Wed, 19 Jan 2000 04:33:51 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhypu06674 for ; Wed, 19 Jan 2000 04:33:38 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhypu10443 for ; Tue, 18 Jan 2000 23:33:33 -0500 (EST) Received: from samar.sasi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sasi.com [164.164.56.2]) id QQhypu22753 for ; Wed, 19 Jan 2000 04:33:27 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id KAA10428; Wed, 19 Jan 2000 10:04:44 +0530 (IST) Received: from hpd14.sasi.com ([10.0.16.14]) by samar.sasi.com; Wed, 19 Jan 2000 10:04:43 +0000 (IST) Received: from localhost (gbnaidu@localhost) by hpd14.sasi.com (8.9.1/8.9.1) with ESMTP id KAA03018; Wed, 19 Jan 2000 10:13:02 +0530 (IST) Date: Wed, 19 Jan 2000 10:13:02 +0530 (IST) From: "G.B.Naidu" To: ajithn@sg.ibm.com cc: mpls@UU.NET Subject: Re: interface index in MPLS implementation... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Ajith, Thanks a lot for the reply. As you said, all I want is to identify the interafce on which the packet has came in. Please see my comments below On Wed, 19 Jan 2000 ajithn@sg.ibm.com wrote: > > When a packet comes into your forwarder, there would be some place (depends > very much on your implementation) where you can identify the > interface from which it came in. It may part of your 'packet upcall' or it > may be a an attribute reachable from the 'buffer containing the packet' > but unfortunately this depends on your implementation, so can't answer more > specifically than that. I like to know how I can identify the interface from which packet came in. I am trying to implement MPLS on FreeBSD. Can someone please let me know how do I do this. > BTW, what router platform are you working on ? gated ? zebra ? or > something else ? It is not yet known. Mopstly it will be gated. We are yet findout from customer what's the routing protocols they would like to support on the system. Most probably BGP, OSPF, RSVP stuff. regards --gbnaidu > > best wishes > -- Ajith > > | Ajith Narayanan > | IBM Emerging Technology Centre > | ajithn@sg.ibm.com Tel: (65) 320-1939 I-VPN No: (61-11-8) 979-1939 > Fax: (65) 224-5260 > | IBM Singapore Pte Ltd, IBM Towers, 80 Anson Rd, Singapore 079907 > -- > > > "G.B.Naidu" on 01/17/2000 06:04:29 PM > > To: mpls@UU.NET > cc: (bcc: Ajith Narayanan/Singapore/IBM) > Subject: interface index in MPLS implementation... > > > > > Hi > > How is the interface is identified in MPLS implementation? Is it through > interface name or interface index? > > We are trying to have index number in forwarding tables. I would like to > know how do I find out the interface index of the interface on which the > packet came in(Incoming packet)? > > Thank you > -- GB > > > > > From owner-mpls@UU.NET Wed Jan 19 01:25:55 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13771 for ; Wed, 19 Jan 2000 01:25:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyqb16794; Wed, 19 Jan 2000 06:25:55 GMT Received: by mail-control.mail.uu.net id QQhyqb00103 for mpls-outgoing; Wed, 19 Jan 2000 06:25:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyqb00098 for ; Wed, 19 Jan 2000 06:25:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyqb17504 for ; Wed, 19 Jan 2000 01:25:30 -0500 (EST) From: markk@sg.ibm.com Received: from ausmtp02.au.ibm.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ausmtp02.au.ibm.COM [202.135.136.105]) id QQhyqb16408 for ; Wed, 19 Jan 2000 06:25:23 GMT Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id RAA220692; Wed, 19 Jan 2000 17:25:35 +1100 Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f03n07e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id RAA43960; Wed, 19 Jan 2000 17:25:16 +1100 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA25686B.0023449A ; Wed, 19 Jan 2000 17:25:13 +1100 X-Lotus-FromDomain: IBMSG@IBMAU To: "G.B.Naidu" cc: ajithn@sg.ibm.com, mpls@UU.NET Message-ID: Date: Thu, 27 Jan 2000 14:17:30 +0800 Subject: Re: interface index in MPLS implementation... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk > I like to know how I can identify the interface from which packet came in. > I am trying to implement MPLS on FreeBSD. Can someone please let me know > how do I do this. one possible way is to use the IP_RECVIF socket options in the recvmsg() call to return the interface index info. I believe this socket option should be available on FreeBSD. For details on how to use it, you can refer to Stevens's Unix Network Programming book (2nd edition), chapter 13 and 20. However, be cautioned that this option is not available in all unix platform. or alternatively you can try create multiple sockets binding to different interfaces as what is being done by Jim Leu's linux implementation (though personally I never get it to work for multicast case). Regards, Kheng Kok --------------------------- Mar Kheng Kok IBM Emerging Technology Centre Tel: 320-1086 (Direct) Fax: 224-5260 Internet: markk@sg.ibm.com From owner-mpls@UU.NET Wed Jan 19 09:25:08 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29277 for ; Wed, 19 Jan 2000 09:25:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyrh09084; Wed, 19 Jan 2000 14:25:07 GMT Received: by mail-control.mail.uu.net id QQhyrh26777 for mpls-outgoing; Wed, 19 Jan 2000 14:24:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyrh26772 for ; Wed, 19 Jan 2000 14:24:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyrh11268 for ; Wed, 19 Jan 2000 09:24:36 -0500 (EST) Received: from albatross.wise.edt.ericsson.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.36]) id QQhyrh08635 for ; Wed, 19 Jan 2000 14:24:35 GMT Received: from penguin.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se [153.88.253.23]) by albatross.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA08012 for ; Wed, 19 Jan 2000 15:11:41 +0100 (MET) Received: from met.fr (galymede.tech.met.fr [137.58.3.8]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA16110 for ; Wed, 19 Jan 2000 15:08:20 +0100 (MET) Received: from breton ([137.58.85.35]) by met.fr (8.9.1/8.9.0) with ESMTP id PAA02941 for ; Wed, 19 Jan 2000 15:08:28 +0100 (MET) Received: from esf.ericsson.se (localhost [127.0.0.1]) by breton (8.8.8+Sun/8.8.8) with ESMTP id PAA07699 for ; Wed, 19 Jan 2000 15:05:03 +0100 (MET) Message-ID: <3885C48F.1D2E1411@esf.ericsson.se> Date: Wed, 19 Jan 2000 15:05:03 +0100 From: " Francois.Paillet" X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: LLC/SNAP encapsulation Content-Type: multipart/alternative; boundary="------------81F64565012FF1C876884FC5" Sender: owner-mpls@UU.NET Precedence: bulk --------------81F64565012FF1C876884FC5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Excuse-me if a lot of e-mails have been written about this issue, but I've some doubts about the chapter 7 ("Use of VPI/VCIs") in the draft-ietf-mpls-atm-02.txt (Is it the last version ? Its expiration date is October 1999). These doubts concern the encapsulation of non-labelled packets between ATM-LC interfaces, here are my questions: - Does LDP have to be carried on a VPI/VCI connection with LLC/SNAP encapsulation ? Does the draft forbid to use a NULL-encapsulation connection to bear LDP ? - If yes, what's the reason ? If a LSR only supports IP protocol at layer 3 (no other protocol such as IPX, ...), it seems to be useless to add the LLC/SNAP encapsulation, doesn't it ? Thank in advance for your responses. Best regards, Francois Paillet. -- Francois PAILLET Ericsson (MET) Tel : 33 1 64 47 66 10 19, avenue Carnot Fax : 33 1 64 47 50 33 91348 Massy Cedex mailto:francois.paillet@esf.ericsson.se FRANCE --------------81F64565012FF1C876884FC5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Excuse-me if a lot of e-mails have been written about this issue,
but I've some doubts about the chapter 7 ("Use of VPI/VCIs") in the draft-ietf-mpls-atm-02.txt (Is it the last version ? Its
expiration date is October 1999).
These doubts concern the encapsulation of non-labelled packets
between ATM-LC interfaces, here are my questions:

- Does LDP have to be carried on a VPI/VCI connection with LLC/SNAP encapsulation ? Does the draft forbid to use a NULL-encapsulation
connection to bear LDP ?

- If yes, what's the reason ? If a LSR only supports IP protocol at
layer 3 (no other protocol such as IPX, ...), it seems to be useless
to add the LLC/SNAP encapsulation, doesn't it ?
 

Thank in advance for your responses.
Best regards,

Francois Paillet.
 

--
Francois PAILLET                                Ericsson (MET)
Tel : 33 1 64 47 66 10                          19, avenue Carnot
Fax : 33 1 64 47 50 33                          91348 Massy Cedex
mailto:francois.paillet@esf.ericsson.se         FRANCE
  --------------81F64565012FF1C876884FC5-- From owner-mpls@UU.NET Wed Jan 19 10:48:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00972 for ; Wed, 19 Jan 2000 10:48:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyrn05834; Wed, 19 Jan 2000 15:48:33 GMT Received: by mail-control.mail.uu.net id QQhyrn11079 for mpls-outgoing; Wed, 19 Jan 2000 15:48:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhyrn11070 for ; Wed, 19 Jan 2000 15:48:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyrn22812; Wed, 19 Jan 2000 10:48:03 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhyrn05350; Wed, 19 Jan 2000 15:48:02 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Jan 19 10:47:32 EST 2000 Received: from dnrc.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA25536; Wed, 19 Jan 2000 10:47:31 -0500 (EST) Message-ID: <3885DC3B.E050189F@dnrc.bell-labs.com> Date: Wed, 19 Jan 2000 10:46:03 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Masataka Ohta CC: Ping Pan , J.Crowcroft@cs.ucl.ac.uk, curtis@avici.com, rsvp@isi.edu, mpls@UU.NET, diffserv@ietf.org, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management References: <200001182338.IAA14823@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > > As I have pointed out in RSVP-related WGs and several research papers, > RSVP has no scalability problem from the begining. > Huh? Please provide the pointers to your draft. > So, I agree with you that it is very hard (impossible) to solve > your problem, because the problem does not exist. > Man. This is deep! > > There are simple reasons why BGP like policy can not be applicable to > resource reservation. But it seems to me that the topic is to hard > for you to understand. > In the past few years, sir, you have been insulting many people in public without much technical input. It's not the topic too hard for me to understand, rather it's your attitude that is too hard for me to understand. Please provide meaningful technical input NICELY. Thank you! - Ping From owner-mpls@UU.NET Wed Jan 19 10:49:26 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00996 for ; Wed, 19 Jan 2000 10:49:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyrn01006; Wed, 19 Jan 2000 15:49:24 GMT Received: by mail-control.mail.uu.net id QQhyrn11104 for mpls-outgoing; Wed, 19 Jan 2000 15:48:45 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyrn11097 for ; Wed, 19 Jan 2000 15:48:38 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyrn03972 for ; Wed, 19 Jan 2000 10:48:34 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQhyrn05835 for ; Wed, 19 Jan 2000 15:48:33 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA24160; Wed, 19 Jan 2000 08:06:14 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA28410; Wed, 19 Jan 2000 10:48:30 -0500 (EST) Message-Id: <200001191548.KAA28410@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: " Francois.Paillet" cc: mpls@UU.NET Subject: Re: LLC/SNAP encapsulation In-reply-to: Your message of Wed, 19 Jan 2000 15:05:03 +0100. <3885C48F.1D2E1411@esf.ericsson.se> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.5 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Jan 2000 10:48:30 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Francois> Does LDP have to be carried on a VPI/VCI connection with LLC/SNAP Francois> encapsulation? Yes. Francois> Does the draft forbid to use a NULL-encapsulation connection to Francois> bear LDP? Yes. Francois> What's the reason ? If a LSR only supports IP protocol at layer 3 Francois> (no other protocol such as IPX, ...), it seems to be useless to Francois> add the LLC/SNAP encapsulation, doesn't it? Supporting the LLC/SNAP encapsulation on the control VPI/VCI is no big deal, and it just makes everything simpler if there is only one encapsulation and everybody uses it. (If both are allowed, then for interoperability, both must be required. Then there has to be a way, possibly configuration, to determine which is being used. In this particular case, it just seemed simplest to require the LLC/SNAP encapsulation, and it's hard to see any downside to it.) From owner-mpls@UU.NET Wed Jan 19 11:01:42 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01180 for ; Wed, 19 Jan 2000 11:01:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyro09196; Wed, 19 Jan 2000 16:01:37 GMT Received: by mail-control.mail.uu.net id QQhyro13091 for mpls-outgoing; Wed, 19 Jan 2000 16:01:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyro12970 for ; Wed, 19 Jan 2000 16:01:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyro24841 for ; Wed, 19 Jan 2000 11:00:44 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQhyro13870 for ; Wed, 19 Jan 2000 16:00:43 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA19054; Wed, 19 Jan 2000 08:00:39 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jan 2000 08:00:39 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE41351545@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "' Francois.Paillet'" , mpls@UU.NET Subject: RE: LLC/SNAP encapsulation Date: Wed, 19 Jan 2000 07:58:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Francois, I think since the default connection ( VPI=0, VCI=32 ) is used for LDP but MAY also be used for any other non-Labeled packet (e.g. IPX), then for interoperability between different vendor products you MUST use LLC/SNAP. -Shahram -----Original Message----- From: Francois.Paillet [mailto:francois.paillet@esf.ericsson.se] Sent: Wednesday, January 19, 2000 9:05 AM To: mpls@UU.NET Subject: LLC/SNAP encapsulation Hi, Excuse-me if a lot of e-mails have been written about this issue, but I've some doubts about the chapter 7 ("Use of VPI/VCIs") in the draft-ietf-mpls-atm-02.txt (Is it the last version ? Its expiration date is October 1999). These doubts concern the encapsulation of non-labelled packets between ATM-LC interfaces, here are my questions: - Does LDP have to be carried on a VPI/VCI connection with LLC/SNAP encapsulation ? Does the draft forbid to use a NULL-encapsulation connection to bear LDP ? - If yes, what's the reason ? If a LSR only supports IP protocol at layer 3 (no other protocol such as IPX, ...), it seems to be useless to add the LLC/SNAP encapsulation, doesn't it ? Thank in advance for your responses. Best regards, Francois Paillet. -- Francois PAILLET Ericsson (MET) Tel : 33 1 64 47 66 10 19, avenue Carnot Fax : 33 1 64 47 50 33 91348 Massy Cedex mailto:francois.paillet@esf.ericsson.se FRANCE From owner-mpls@UU.NET Wed Jan 19 11:08:09 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01229 for ; Wed, 19 Jan 2000 11:08:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyro18686; Wed, 19 Jan 2000 16:08:02 GMT Received: by mail-control.mail.uu.net id QQhyro17668 for mpls-outgoing; Wed, 19 Jan 2000 16:07:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyro17572 for ; Wed, 19 Jan 2000 16:07:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyro25791 for ; Wed, 19 Jan 2000 11:07:14 -0500 (EST) Received: from mail.cs.umn.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cs.umn.edu [128.101.35.200]) id QQhyro18032 for ; Wed, 19 Jan 2000 16:07:09 GMT Received: from exa.cs.umn.edu (sinha@exa.cs.umn.edu [160.94.120.45]) by mail.cs.umn.edu (8.9.3/8.9.3) with ESMTP id KAA21635 for ; Wed, 19 Jan 2000 10:07:08 -0600 (CST) Received: from localhost (sinha@localhost) by exa.cs.umn.edu (8.9.1/8.9.0) with ESMTP id KAA06172 for ; Wed, 19 Jan 2000 10:07:08 -0600 (CST) X-Authentication-Warning: exa.cs.umn.edu: sinha owned process doing -bs Date: Wed, 19 Jan 2000 10:07:08 -0600 (CST) From: Vishal Sinha To: mpls@UU.NET Subject: draft-ietf-mpls-label-encaps-07 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, While going through the 'draft-ietf-mpls-label-encaps-07', I did not understood how are we going to differentiate labeled packets and unlabeled packets. From what I understood, the labeled packets use the protocol id 0x0281 (unicast) and 0x0283 (multicast) but there is no mention for unlabeled packet's protocol id. Moreover, the unlabeled packets can be of type IP and ISO. Shouldn't we have a separate protocol id for both of them? Please enlighten me. Thanks, Vishal From owner-mpls@UU.NET Wed Jan 19 11:31:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01596 for ; Wed, 19 Jan 2000 11:31:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyrq03936; Wed, 19 Jan 2000 16:31:08 GMT Received: by mail-control.mail.uu.net id QQhyrq25019 for mpls-outgoing; Wed, 19 Jan 2000 16:30:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyrq24999 for ; Wed, 19 Jan 2000 16:30:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyrq29350 for ; Wed, 19 Jan 2000 11:30:42 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQhyrq27501 for ; Wed, 19 Jan 2000 16:30:41 GMT Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA20212; Wed, 19 Jan 2000 08:30:35 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jan 2000 08:30:35 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE41351546@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Vishal Sinha'" , mpls@UU.NET Subject: RE: draft-ietf-mpls-label-encaps-07 Date: Wed, 19 Jan 2000 08:28:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I think since the other PIDs are not related to this document they are not mentioned. But if you want PID for IP is: 0x0021, and in fact there is a PID for any other protocol which you can find it in RFC-1700. Now what if a L3 protocol is encapsulated in MPLS. Then the way to find that L3 protocol I think is by partitioning the label space between those protocols. -Shahram > -----Original Message----- > From: Vishal Sinha [mailto:sinha@cs.umn.edu] > Sent: Wednesday, January 19, 2000 11:07 AM > To: mpls@UU.NET > Subject: draft-ietf-mpls-label-encaps-07 > > > Hi, > > While going through the 'draft-ietf-mpls-label-encaps-07', I did not > understood how are we going to differentiate labeled packets > and unlabeled > packets. > > From what I understood, the labeled packets use the protocol id > 0x0281 (unicast) and 0x0283 (multicast) but there is no mention for > unlabeled packet's protocol id. > Moreover, the unlabeled packets can be of type IP and > ISO. Shouldn't we have a separate protocol id for both of them? > > Please enlighten me. > > Thanks, > > Vishal > From owner-mpls@UU.NET Wed Jan 19 11:33:43 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01620 for ; Wed, 19 Jan 2000 11:33:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyrq05868; Wed, 19 Jan 2000 16:33:43 GMT Received: by mail-control.mail.uu.net id QQhyrq25760 for mpls-outgoing; Wed, 19 Jan 2000 16:33:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyrq25728 for ; Wed, 19 Jan 2000 16:33:10 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyrq10691 for ; Wed, 19 Jan 2000 11:33:07 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhyrq05297 for ; Wed, 19 Jan 2000 16:33:07 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Wed, 19 Jan 2000 11:33:02 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CDCC@email.quarrytech.com> From: "Abes, Andi" To: Shahram Davari , "'Vishal Sinha'" , mpls@UU.NET Subject: RE: draft-ietf-mpls-label-encaps-07 Date: Wed, 19 Jan 2000 11:33:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Actually, If the LSP's are setup using RSVP, you can signall the L3PID during the setup phase. LDP/CR-LDP do not yet have such an option. Andi. > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, January 19, 2000 11:28 AM > To: 'Vishal Sinha'; mpls@UU.NET > Subject: RE: draft-ietf-mpls-label-encaps-07 > > > Hi, > > I think since the other PIDs are not related to this document > they are not > mentioned. But if you want PID for IP is: 0x0021, and in fact > there is a PID > for any other protocol which you can find it in RFC-1700. Now > what if a L3 > protocol is encapsulated in MPLS. Then the way to find that > L3 protocol I > think is by partitioning the label space between those protocols. > > -Shahram > > > -----Original Message----- > > From: Vishal Sinha [mailto:sinha@cs.umn.edu] > > Sent: Wednesday, January 19, 2000 11:07 AM > > To: mpls@UU.NET > > Subject: draft-ietf-mpls-label-encaps-07 > > > > > > Hi, > > > > While going through the 'draft-ietf-mpls-label-encaps-07', I did not > > understood how are we going to differentiate labeled packets > > and unlabeled > > packets. > > > > From what I understood, the labeled packets use the protocol id > > 0x0281 (unicast) and 0x0283 (multicast) but there is no mention for > > unlabeled packet's protocol id. > > Moreover, the unlabeled packets can be of type IP and > > ISO. Shouldn't we have a separate protocol id for both of them? > > > > Please enlighten me. > > > > Thanks, > > > > Vishal > > > From owner-mpls@UU.NET Wed Jan 19 14:08:24 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03711 for ; Wed, 19 Jan 2000 14:08:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhysa01231; Wed, 19 Jan 2000 19:08:05 GMT Received: by mail-control.mail.uu.net id QQhysa11671 for mpls-outgoing; Wed, 19 Jan 2000 19:07:36 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhysa11579 for ; Wed, 19 Jan 2000 19:07:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhysa01442 for ; Wed, 19 Jan 2000 14:07:28 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQhysa00682 for ; Wed, 19 Jan 2000 19:07:27 GMT Received: from spectacle.cisco.com (spectacle-hme0.cisco.com [161.44.128.131]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA27404; Wed, 19 Jan 2000 14:07:17 -0500 (EST) Received: (rschmitt@localhost) by spectacle.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id OAA05162; Wed, 19 Jan 2000 14:07:17 -0500 (EST) Date: Wed, 19 Jan 2000 14:07:17 -0500 (EST) Message-Id: <200001191907.OAA05162@spectacle.cisco.com> From: Robert Schmitt To: Joan Cucchiara Cc: tnadeau@cisco.com, amlambert@cisco.com, mpls@UU.NET Subject: LDP MIB Protocol Session Tables Sender: owner-mpls@UU.NET Precedence: bulk Joan.. In reference to recent correspondence about the mplsLdpSessionPeerAddressEntry OBJECT-TYPE whose DESCRIPTION is "An entry in this table represents information on session's for a single next hop address which was advertised in an Address Message from the LDP peer. The information contained in a row is read-only." If the premise is accepted that this is an appropriate DESCRIPTION, along with the newly specified INDEX, then the DESCRIPTIONS for the synonomous ATM and Frame Relay Tables would appear to be not correct. These DESCRIPTIONS are as follows, for both ATM and Frame Relay: "An entry in this table represents information on a single session between an LDP Entity and LDP Peer. The information contained in a row is read-only." To be consistent, these should read An entry in this table represents information on a single Label Range that is associated with a session. I would like to be sure that the premise is correct, which is not the case as we speak. Thank you +----------------------------------+------------------------------+ | | | Robert Schmitt | | | rschmitt@cisco.com (w) ||| ||| | Chelmsford, MA ||||| ||||| | 978-244-3076 ..:|||||||:...:|||||||:.. | RSCH@prodigy.net (h) C i s c o S y s t e m s | 603-673-7571 +----------------------------------+------------------------------+ ================================================================ -- -- MPLS LDP ATM Session Information -- mplsLdpAtmSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpAtmSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Sessions between the LDP Entities and LDP Peers using ATM as the underlying media. Each row represents a single session. NOTE: this table cannot use the 'AUGMENTS' clause because there is not necessarily a one-to-one mapping between this table and the mplsLdpSessionTable." ::= { mplsLdpSessionObjects 2 } mplsLdpAtmSessionEntry OBJECT-TYPE SYNTAX MplsLdpAtmSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on a single session between an LDP Entity and LDP Peer. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpPeerIndex, mplsLdpSessionIndex, mplsLdpSessionAtmLabelRangeLowerBoundVpi, mplsLdpSessionAtmLabelRangeLowerBoundVci } ::= { mplsLdpAtmSessionTable 1 } MplsLdpAtmSessionEntry ::= SEQUENCE { mplsLdpSessionAtmLabelRangeLowerBoundVpi AtmVpIdentifier, mplsLdpSessionAtmLabelRangeLowerBoundVci AtmVcIdentifier, mplsLdpSessionAtmLabelRangeUpperBoundVpi AtmVpIdentifier, mplsLdpSessionAtmLabelRangeUpperBoundVci AtmVcIdentifier } ================================================================ -- -- MPLS LDP Frame Relay Session Information -- mplsLdpFrameRelaySessionTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpFrameRelaySessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Sessions between the LDP Entities and LDP Peers using Frame Relay as the underlying media. Each row represents a single session. NOTE: this table cannot use the 'AUGMENTS' clause because there is not necessarily a one-to-one mapping between this table and the mplsLdpSessionTable." ::= { mplsLdpSessionObjects 3 } mplsLdpFrameRelaySessionEntry OBJECT-TYPE SYNTAX MplsLdpFrameRelaySessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on a single session between an LDP Entity and LDP Peer. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpPeerIndex, mplsLdpSessionIndex, mplsLdpFrSessionMinDlci } ::= { mplsLdpFrameRelaySessionTable 1 } MplsLdpFrameRelaySessionEntry ::= SEQUENCE { mplsLdpFrSessionMinDlci Integer32, mplsLdpFrSessionMaxDlci Integer32, mplsLdpFrSessionLen INTEGER } ================================================================ > mplsLdpSessionPeerAddressEntry OBJECT-TYPE > SYNTAX MplsLdpSessionPeerAddressEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents information on > session's for a single next hop address which was > advertised in an Address Message from the LDP peer. > The information contained in a row is read-only." > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpSessionPeerNextHopAddressType, > mplsLdpSessionPeerNextHopAddress > } > ::= { mplsLdpSessionPeerAddressTable 1 } > > MplsLdpSessionPeerAddressEntry ::= SEQUENCE { > mplsLdpSessionPeerNextHopAddressType AddressFamilyNumbers, > mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr > } mplsLdpSessionPeerAddressEntry OBJECT-TYPE SYNTAX MplsLdpSessionPeerAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents information on session's for a single next hop address which was advertised in an Address Message from the LDP peer. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpPeerIndex, mplsLdpSessionIndex } ::= { mplsLdpSessionPeerAddressTable 1 } MplsLdpSessionPeerAddressEntry ::= SEQUENCE { mplsLdpSessionPeerNextHopAddressType AddressFamilyNumbers, mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr } >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Piers, I do think you are correct and those NextHop objects should be included in the index. And yes, we have removed the SessionIndex from the MIB, so your table appears to be correct. Thanks, Joan > -----Original Message----- > From: Piers Finlayson [mailto:pdf@datcon.co.uk] > Sent: Monday, January 17, 2000 10:24 AM > To: 'Joan Cucchiara' > Cc: 'mpls@uu.net' > Subject: RE: LDP MIB update? > > > Joan, > > I think there may be a problem with the > mplsLdpSessionPeerAddressTable in > the LDP MIB. > > The mplsLdpSessionPeerAddressTable extends the > mplsLdpSessionTable in the > same way as the mplsLdpFrameRelaySessionTable and the > mplsLdpAtmSessionTable. They all use the same indexes as the > mplsLdpSessionTable, but the Protocol Session Table indexes > are extended to > include > > mplsLdpSessionAtmLabelRangeLowerBoundVpi and > mplsLdpSessionAtmLabelRangeLowerBoundVpi in the ATM case > > mplsLdpFrSessionMinDlci in the Frame Relay case. > > These additional indexes allow multiple rows to exist in the Protocol > Session Tables for a single entry in the mplsLdpSessionTable. this is > important because there may be several label ranges for a > single session. > > I think there may also be multiple peer next hop addresses > per session. > This means that the two fields > mplsLdpSessionPeerNextHopAddressType > mplsLdpSessionPeerNextHopAddress > > should be added to the index so that rows in this table can also be > accessed. > > > If you make this change, the ASN.1 for > mplsLdpSessionPeerAddressEntry will > become > > ... > > mplsLdpSessionPeerAddressEntry OBJECT-TYPE > SYNTAX MplsLdpSessionPeerAddressEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents information on > session's for a single next hop address which was > advertised in an Address Message from the LDP peer. > The information contained in a row is read-only." > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpPeerIndex, > mplsLdpSessionIndex > mplsLdpSessionPeerNextHopAddressType > mplsLdpSessionPeerNextHopAddress > } > ::= { mplsLdpSessionPeerAddressTable 1 } > > MplsLdpSessionPeerAddressEntry ::= SEQUENCE { > mplsLdpSessionPeerNextHopAddressType > AddressFamilyNumbers, > mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr > } > > The individual fields also have to become "not-accessible" > > ... > > However, in your email of 3 December 1999 you describe new > indexing for the > mplsLdpSessionTable. I assume, therefore that > mplsLdpSessionPeerAddressEntry becomes > > ... > > mplsLdpSessionPeerAddressEntry OBJECT-TYPE > SYNTAX MplsLdpSessionPeerAddressEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents information on > session's for a single next hop address which was > advertised in an Address Message from the LDP peer. > The information contained in a row is read-only." > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpSessionPeerNextHopAddressType, > mplsLdpSessionPeerNextHopAddress > } > ::= { mplsLdpSessionPeerAddressTable 1 } > > MplsLdpSessionPeerAddressEntry ::= SEQUENCE { > mplsLdpSessionPeerNextHopAddressType > AddressFamilyNumbers, > mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr > } > > ... > > > Is this correct? > > Thanks, > Piers > > --------------------------------------------------------- > Piers Finlayson > > ATM, MPLS and Telecoms Group > Data Connection Ltd. > > Tel: +44 20 8366 1177 Fax: +44 20 8363 4478 > Email: pdf@datcon.co.uk Web: http://www.datcon.co.uk > --------------------------------------------------------- > From owner-mpls@UU.NET Wed Jan 19 15:11:44 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04651 for ; Wed, 19 Jan 2000 15:11:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyse09848; Wed, 19 Jan 2000 20:11:19 GMT Received: by mail-control.mail.uu.net id QQhyse20646 for mpls-outgoing; Wed, 19 Jan 2000 20:10:38 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyse20641 for ; Wed, 19 Jan 2000 20:10:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyse10271 for ; Wed, 19 Jan 2000 15:10:29 -0500 (EST) Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQhyse15573 for ; Wed, 19 Jan 2000 20:10:28 GMT Received: by BRIXCORP2 with Internet Mail Service (5.5.1960.3) id ; Wed, 19 Jan 2000 15:08:32 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB0CE262@BRIXCORP2> From: Joan Cucchiara To: "'Robert Schmitt'" , Joan Cucchiara Cc: tnadeau@cisco.com, amlambert@cisco.com, mpls@UU.NET Subject: RE: LDP MIB Protocol Session Tables Date: Wed, 19 Jan 2000 15:08:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Robert, Yes, I agree the description needs to be reworded, as this MIB table, mplsLdpAtmSessionTable, represents one OR MORE label range intersections of the ATM Session Parameters between the entity and peer for a session. As you point out the indexing will remain as it is. (This is also the reason that this table cannot use "AUGMENTS".) Similar problem with the description for the FR Session Table. I don't believe these problems are related to the mplsLdpSessionPeerAddressTable issue which will require additional indices and also a better description. Thanks, -Joan > -----Original Message----- > From: Robert Schmitt [mailto:rschmitt@cisco.com] > Sent: Wednesday, January 19, 2000 2:07 PM > To: Joan Cucchiara > Cc: tnadeau@cisco.com; amlambert@cisco.com; mpls@uu.net > Subject: LDP MIB Protocol Session Tables > > > > > Joan.. > > In reference to recent correspondence about the > mplsLdpSessionPeerAddressEntry OBJECT-TYPE > > whose DESCRIPTION is > "An entry in this table represents information on > session's for a single next hop address which was > advertised in an Address Message from the LDP peer. > The information contained in a row is read-only." > > If the premise is accepted that this is an appropriate DESCRIPTION, > along with the newly specified INDEX, then the DESCRIPTIONS for the > synonomous ATM and Frame Relay Tables would appear to be not correct. > These DESCRIPTIONS are as follows, for both ATM and Frame Relay: > > "An entry in this table represents information on a > single session between an LDP Entity and LDP Peer. > The information contained in a row is read-only." > > To be consistent, these should read > > An entry in this table represents information on a > single Label Range that is associated with a session. > > I would like to be sure that the premise is correct, which is not > the case as we speak. > > Thank you > > +----------------------------------+------------------------------+ > | | | Robert Schmitt > | | | rschmitt@cisco.com (w) > ||| ||| | Chelmsford, MA > ||||| ||||| | 978-244-3076 > ..:|||||||:...:|||||||:.. | RSCH@prodigy.net (h) > C i s c o S y s t e m s | 603-673-7571 > +----------------------------------+------------------------------+ > > > > > ================================================================ > -- > -- MPLS LDP ATM Session Information > -- > > mplsLdpAtmSessionTable OBJECT-TYPE > SYNTAX SEQUENCE OF MplsLdpAtmSessionEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of Sessions between the LDP Entities and > LDP Peers using ATM as the underlying media. > Each row represents a single session. > > NOTE: this table cannot use the 'AUGMENTS' > clause because there is not necessarily a one-to-one > mapping between this table and the mplsLdpSessionTable." > ::= { mplsLdpSessionObjects 2 } > > mplsLdpAtmSessionEntry OBJECT-TYPE > SYNTAX MplsLdpAtmSessionEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents information on a > single session between an LDP Entity and LDP Peer. > The information contained in a row is read-only." > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpPeerIndex, > mplsLdpSessionIndex, > mplsLdpSessionAtmLabelRangeLowerBoundVpi, > mplsLdpSessionAtmLabelRangeLowerBoundVci > > } > ::= { mplsLdpAtmSessionTable 1 } > > MplsLdpAtmSessionEntry ::= SEQUENCE { > mplsLdpSessionAtmLabelRangeLowerBoundVpi AtmVpIdentifier, > mplsLdpSessionAtmLabelRangeLowerBoundVci AtmVcIdentifier, > mplsLdpSessionAtmLabelRangeUpperBoundVpi AtmVpIdentifier, > mplsLdpSessionAtmLabelRangeUpperBoundVci AtmVcIdentifier > } > ================================================================ > > -- > -- MPLS LDP Frame Relay Session Information > -- > > mplsLdpFrameRelaySessionTable OBJECT-TYPE > SYNTAX SEQUENCE OF MplsLdpFrameRelaySessionEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of Sessions between the LDP Entities and > LDP Peers using Frame Relay as the underlying media. > Each row represents a single session. > > NOTE: this table cannot use the 'AUGMENTS' > clause because there is not necessarily a one-to-one > mapping between this table and the mplsLdpSessionTable." > ::= { mplsLdpSessionObjects 3 } > > mplsLdpFrameRelaySessionEntry OBJECT-TYPE > SYNTAX MplsLdpFrameRelaySessionEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents information on a > single session between an LDP Entity and LDP Peer. > The information contained in a row is read-only." > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpPeerIndex, > mplsLdpSessionIndex, > mplsLdpFrSessionMinDlci > } > ::= { mplsLdpFrameRelaySessionTable 1 } > > MplsLdpFrameRelaySessionEntry ::= SEQUENCE { > mplsLdpFrSessionMinDlci Integer32, > mplsLdpFrSessionMaxDlci Integer32, > mplsLdpFrSessionLen INTEGER > } > ================================================================ > > mplsLdpSessionPeerAddressEntry OBJECT-TYPE > > SYNTAX MplsLdpSessionPeerAddressEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "An entry in this table represents information on > > session's for a single next hop address which was > > advertised in an Address Message from the LDP peer. > > The information contained in a row is read-only." > > INDEX { mplsLdpEntityLdpId, > > mplsLdpEntityIndex, > > mplsLdpPeerLdpId, > > mplsLdpSessionPeerNextHopAddressType, > > mplsLdpSessionPeerNextHopAddress > > } > > ::= { mplsLdpSessionPeerAddressTable 1 } > > > > MplsLdpSessionPeerAddressEntry ::= SEQUENCE { > > mplsLdpSessionPeerNextHopAddressType > AddressFamilyNumbers, > > mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr > > } > > mplsLdpSessionPeerAddressEntry OBJECT-TYPE > SYNTAX MplsLdpSessionPeerAddressEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in this table represents information on > session's for a single next hop address which was > advertised in an Address Message from the LDP peer. > The information contained in a row is read-only." > INDEX { mplsLdpEntityLdpId, > mplsLdpEntityIndex, > mplsLdpPeerLdpId, > mplsLdpPeerIndex, > mplsLdpSessionIndex > } > ::= { mplsLdpSessionPeerAddressTable 1 } > > MplsLdpSessionPeerAddressEntry ::= SEQUENCE { > mplsLdpSessionPeerNextHopAddressType > AddressFamilyNumbers, > mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr > } > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Piers, > > I do think you are correct and > those NextHop objects should be included in the index. > And yes, we have removed the SessionIndex > from the MIB, so your table appears to be correct. > > Thanks, Joan > > > -----Original Message----- > > From: Piers Finlayson [mailto:pdf@datcon.co.uk] > > Sent: Monday, January 17, 2000 10:24 AM > > To: 'Joan Cucchiara' > > Cc: 'mpls@uu.net' > > Subject: RE: LDP MIB update? > > > > > > Joan, > > > > I think there may be a problem with the > > mplsLdpSessionPeerAddressTable in > > the LDP MIB. > > > > The mplsLdpSessionPeerAddressTable extends the > > mplsLdpSessionTable in the > > same way as the mplsLdpFrameRelaySessionTable and the > > mplsLdpAtmSessionTable. They all use the same indexes as the > > mplsLdpSessionTable, but the Protocol Session Table indexes > > are extended to > > include > > > > mplsLdpSessionAtmLabelRangeLowerBoundVpi and > > mplsLdpSessionAtmLabelRangeLowerBoundVpi in the ATM case > > > > mplsLdpFrSessionMinDlci in the Frame Relay case. > > > > These additional indexes allow multiple rows to exist in > the Protocol > > Session Tables for a single entry in the > mplsLdpSessionTable. this is > > important because there may be several label ranges for a > > single session. > > > > I think there may also be multiple peer next hop addresses > > per session. > > This means that the two fields > > > mplsLdpSessionPeerNextHopAddressType > > mplsLdpSessionPeerNextHopAddress > > > > should be added to the index so that rows in this table can also be > > accessed. > > > > > > If you make this change, the ASN.1 for > > mplsLdpSessionPeerAddressEntry will > > become > > > > ... > > > > mplsLdpSessionPeerAddressEntry OBJECT-TYPE > > SYNTAX MplsLdpSessionPeerAddressEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "An entry in this table represents information on > > session's for a single next hop address which was > > advertised in an Address Message from the LDP peer. > > The information contained in a row is read-only." > > INDEX { mplsLdpEntityLdpId, > > mplsLdpEntityIndex, > > mplsLdpPeerLdpId, > > mplsLdpPeerIndex, > > mplsLdpSessionIndex > > mplsLdpSessionPeerNextHopAddressType > > mplsLdpSessionPeerNextHopAddress > > } > > ::= { mplsLdpSessionPeerAddressTable 1 } > > > > MplsLdpSessionPeerAddressEntry ::= SEQUENCE { > > mplsLdpSessionPeerNextHopAddressType > > AddressFamilyNumbers, > > mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr > > } > > > > The individual fields also have to become "not-accessible" > > > > ... > > > > However, in your email of 3 December 1999 you describe new > > indexing for the > > mplsLdpSessionTable. I assume, therefore that > > mplsLdpSessionPeerAddressEntry becomes > > > > ... > > > > mplsLdpSessionPeerAddressEntry OBJECT-TYPE > > SYNTAX MplsLdpSessionPeerAddressEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "An entry in this table represents information on > > session's for a single next hop address which was > > advertised in an Address Message from the LDP peer. > > The information contained in a row is read-only." > > INDEX { mplsLdpEntityLdpId, > > mplsLdpEntityIndex, > > mplsLdpPeerLdpId, > > mplsLdpSessionPeerNextHopAddressType, > > mplsLdpSessionPeerNextHopAddress > > } > > ::= { mplsLdpSessionPeerAddressTable 1 } > > > > MplsLdpSessionPeerAddressEntry ::= SEQUENCE { > > mplsLdpSessionPeerNextHopAddressType > > AddressFamilyNumbers, > > mplsLdpSessionPeerNextHopAddress MplsLdpGenAddr > > } > > > > ... > > > > > > Is this correct? > > > > Thanks, > > Piers > > > > --------------------------------------------------------- > > Piers Finlayson > > > > ATM, MPLS and Telecoms Group > > Data Connection Ltd. > > > > Tel: +44 20 8366 1177 Fax: +44 20 8363 4478 > > Email: pdf@datcon.co.uk Web: http://www.datcon.co.uk > > --------------------------------------------------------- > > > From owner-mpls@UU.NET Wed Jan 19 15:28:00 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04802 for ; Wed, 19 Jan 2000 15:28:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhysf26910; Wed, 19 Jan 2000 20:27:50 GMT Received: by mail-control.mail.uu.net id QQhysf25165 for mpls-outgoing; Wed, 19 Jan 2000 20:27:29 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhysf25160 for ; Wed, 19 Jan 2000 20:27:28 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhysf00044 for ; Wed, 19 Jan 2000 15:27:19 -0500 (EST) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQhysf19332 for ; Wed, 19 Jan 2000 20:27:18 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA18141; Wed, 19 Jan 2000 15:27:17 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA29242; Wed, 19 Jan 2000 15:27:16 -0500 (EST) Message-Id: <200001192027.PAA29242@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Cc: swallow@cisco.com Subject: Draft of revised charter Date: Wed, 19 Jan 2000 15:27:16 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Folks, Attached is a draft of the revised MPLS charter. The goals and milestones section is far from complete. I've listed a few items where I know that there are people committed to doing the work. Please send ideas for further goals and other comments to the list. Thanks, George & Vijay ====================================================================== Multiprotocol Label Switching (mpls) Charter Problem Statement: Label switching in conjunction with network layer routing has emerged as an important new technology. It is actively being applied to applications such as traffic engineering and virtual private networks. Among the problems this technology is expected to address are the following: 1. Greater flexibility in delivering routing services Using labels to identify particular traffic which are to receive special services, e.g. QoS. Using labels to provide forwarding along an explicit path different from the one constructed by destination-based forwarding. 2. Scalability of network layer routing Using labels as a means to aggregate forwarding information, while working in the presence of routing hierarchies. 3. Simplify integration of routers with cell switching based technologies a) making cell switches behave as peers to routers (thus reducing the number of routing peers that a router has to maintain), b) by making information about physical topology available to Network Layer routing procedures, and c) by employing common addressing, routing, and management procedures. 4. Simplify integration of routers with optical cross-connect based technologies a) making optical cross connects behave as peers to routers (thus reducing the number of routing peers that a router has to maintain), b) by making information about physical topology available to Network Layer routing procedures, and c) by employing common addressing, routing, and management procedures. High Level Requirements 1. The solution should be general with respect to data link technologies. Specific optimizations for particular media will be considered. 2. The solution must be compatible with existing internetwork technologies and routing protocols. 3. The solution should support a wide range of forwarding granularities associated with a given label, from a single application flow to a group of topologically related destinations. 4. The solution should support operations, administration, and maintenance facilities at least as extensive as those supported in IP networks. 5. The solution should provide stable routing. The protocols defined by MPLS must provide protocol mechanism(s) to either prevent the formation of loops and/or contain the amount of (networking) resources that could be consumed due to the presence of such loops. 6. The solution should be very scalable. Scalability issues will be considered and analyzed. Charter Statement: The working group is responsible for standardizing a base technology for using label switching in conjunction with network layer routing and for the implementation of that technology over various link level technologies, which may include Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,... This includes procedures and protocols for the distribution of labels between routers, encapsulations, multicast considerations, and the use of labels to support higher layer resource reservation and QoS mechanisms. The working group will also specify a control plane for optical cross connects. In this environment specific wave lengths or Lambdas are used instead of labels. Objectives: 1. Specify standard protocol(s) for maintenance and distribution of label binding information to support unicast destination-based routing. 2. Specify standard protocol(s) for maintenance and distribution of label binding information to support multicast routing. 3. Specify standard protocol(s) for maintenance and distribution of label binding information to support hierarchy of routing knowledge (e.g., complete segregation of intra and inter-domain routing). 4. Specify standard protocol(s) for maintenance and distribution of label binding information to support explicit paths in support of applications such as Traffic Engineering. 5. Specify standard protocols and procedures to support the fast recovery of Label Switched Paths. 6. Specify extensions to the protocols and procedures used for signaling explicit routes and to effect fast recovery of LSPs for use in Optical Cross Connects. 7. Specify standard procedures of carrying label information over various link level technologies including ATM. 8. Define the use of Differentiated and Integrated Services in an MPLS environment. 9. Specify standard protocols and procedures to support operations, administration, and maintenance facilities. Coordination: The working group will coordinate its activities with other working groups as appropriate. For specific technologies, the WG will cooperate with the appropriate standards bodies such as OIF, ITU-T, ANSI, etc. Goals and Milestones: Mar 00 - Produce a document which defines support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks (Standards Track). Aug 00 - Produce a document which defines operation with RSVP for unicast destinations. (Standards Track). Dec 00 - Produce specifications for a MPLS control plane for optical cross-connects (Standards Track). From owner-mpls@UU.NET Wed Jan 19 16:02:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05248 for ; Wed, 19 Jan 2000 16:02:05 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhysi09963; Wed, 19 Jan 2000 21:01:54 GMT Received: by mail-control.mail.uu.net id QQhysi29279 for mpls-outgoing; Wed, 19 Jan 2000 21:01:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhysi29189 for ; Wed, 19 Jan 2000 21:01:25 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhysi17779; Wed, 19 Jan 2000 16:01:22 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: necom830.hpcl.titech.ac.jp [131.112.32.132]) id QQhysi17573; Wed, 19 Jan 2000 21:01:21 GMT From: Masataka Ohta Message-Id: <200001192100.GAA18692@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA18692; Thu, 20 Jan 2000 06:00:36 +0900 Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management To: pingpan@dnrc.bell-labs.com (Ping Pan) Date: Thu, 20 Jan 0 6:00:35 JST Cc: mohta@necom830.hpcl.titech.ac.jp, pingpan@research.bell-labs.com, J.Crowcroft@cs.ucl.ac.uk, curtis@avici.com, rsvp@isi.edu, mpls@UU.NET, diffserv@ietf.org, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com In-Reply-To: <3885DC3B.E050189F@dnrc.bell-labs.com>; from "Ping Pan" at Jan 20, 100 12:52 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-mpls@UU.NET Precedence: bulk Ping; > > As I have pointed out in RSVP-related WGs and several research papers, > > RSVP has no scalability problem from the begining. > > > > Huh? Please provide the pointers to your draft. That could have been a fair request if you had provided the pointers to papers or something like that describing the (non-existing) scalability problem in detail. So far, even though there are a lot of proposals to try to get around the problem in vain, I have never seen anyone who had done so, which is another evidence that there is no problem. Instead, I wrote drafts and published papers and pointers are given. > > There are simple reasons why BGP like policy can not be applicable to > > resource reservation. But it seems to me that the topic is to hard > > for you to understand. > > > > In the past few years, sir, you have been insulting many people in > public without much technical input. It's not the topic too hard for me > to understand, rather it's your attitude that is too hard for me to > understand. Please provide meaningful technical input NICELY. That's your problem. Masataka Ohta From owner-mpls@UU.NET Wed Jan 19 17:27:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06141 for ; Wed, 19 Jan 2000 17:27:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhysn01340; Wed, 19 Jan 2000 22:26:46 GMT Received: by mail-control.mail.uu.net id QQhysn20274 for mpls-outgoing; Wed, 19 Jan 2000 22:26:24 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhysn20266 for ; Wed, 19 Jan 2000 22:26:21 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhysn29378 for ; Wed, 19 Jan 2000 17:26:19 -0500 (EST) Received: from goliath.dacor.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.dacor.net [205.133.75.2]) id QQhysn08615 for ; Wed, 19 Jan 2000 22:26:19 GMT Received: from veda-home.com (adsl-77.dacor.net [205.133.74.77]) by goliath.dacor.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C9SNYL31; Wed, 19 Jan 2000 17:26:35 -0500 Message-ID: <38863B5E.75C1A3A7@veda-home.com> Date: Wed, 19 Jan 2000 17:31:58 -0500 From: Telecom Tom Organization: The Veda Home Company X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m) X-Accept-Language: en-US, es, de, fr MIME-Version: 1.0 To: Voice Over MPLS , mpls@UU.NET Subject: Re: MPLS based DSLAMs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Antti, Instead of MPLS-based DSLAMs, could we have MPLS-based DSLARs (DSL access routers)? If so, could these be used as iPOPs (Internet POPs) for direct connections between the customer premises and transit ISPs, doing away with local/access ISPs? The old and new models look like this: Old model with local/access ISP ------------------------------- Cust <-> ILEC <-> access <-> ILEC <-> transit <-> Internet prem CO ISP CO ISP POP cloud New model without local/access ISP ---------------------------------- Cust <-> LEC <-> iPOP <-> Internet prem CO cloud So at the ILEC CO or CLEC wire center/headend, the new model would put an MPLS-based DSLAR to route traffic between the end customer and the Internet. The access ISP, er, goes on a long vacation, or better, evolves to something else like a CLEC or server-farm operator offering VoD and thin-client applications. So is this DSLAR/iPOP a realistic application of MPLS that supports end-to-end QoS and usage reporting/charging? --Regards, TT ------------------------------------------------ Tom Nelson Scott tom.scott@veda-home.com The Veda Home Company Bowling Green, Ohio USA "In IP We Trust" "E Pluribus Unix" ------------------------------------------------ -------- Original Message -------- Subject: MPLS based DSLAMs Date: Tue, 11 Jan 2000 17:18:47 -0500 From: "Antti Kankkunen" Reply-To: "Voice Over MPLS" To: "Voice Over MPLS" CC: , , Thomas and others, a related comment below. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas > Wolfram > Sent: Saturday, January 08, 2000 7:05 AM > To: mpls@UU.NET; vompls@lists.integralaccess.com > Subject: RE: prime time MPLS/fiber > > But I think if you would want to use framed MPLS to replace > cell ATM in an xDSL access network extending MPLS to the CPE > could make sense. There the CPE isn't connected directly to the > operator LSR having all the internet routes anyway. Perhaps > several hundred CPEs are connected to DSLAMs and you have > perhaps the LERs of several ISPs connected to the PoP. You > could also have other service gateways connected to the > PoP. All these ISP LERs route into the internet, i.e. to the > same set of destinations. You wouldn't use MPLS on the local > loop to pre-label the packets for transport through the core > network but through the access network. By using different labels > the customer could even choose to send different traffic to > the same destination via different ISPs though he has only > one physical xDSL link. > I.e. I think you could use MPLS for the same purpose ATM is > used in the access networks today. > There is already some effort in progress to address the kinds of applications you describe above. In their Paris meeting early February, the DSL Forum will hold a BOF session on MPLS and its relevance to the DSL/DSLAM architectures being addressed in the DSL Forum set of recommendations. Please see http://www.adsl.com/adsl_forum.html (Click on Meetings & Events / Meeting Information) You need to be a DSL Forum member to attend the BOF session. The session is held on the evening of either 2/9 or 2/10. Below please find a quote from an e-mail from Greg Wetzel of Covad describing the BOF session. ===Beginning of quote from Greg Wetzel== The technical committee chair, Gavin Young, agreed just last week to hold a BoF on MPLS at the technical committee meeting in Paris. It will be chaired by Martin Jackson, a member of the DSL Forum board of directors. The BoF will be either Wed or Thu evening from 5:30-7:30pm. An agenda will be forthcoming shortly, but will include a 45 min MPLS tutorial from David Allan, Nortel, chair of the Architecture Working Group, and an hour on the discussion of how MPLS fits into the DSL Forum set of recommendations. ===End of quote==================== Best regards, Antti K. --- You are currently subscribed to vompls as: tom.scott@veda-home.com To subscribe: vompls-request@lists.integralaccess.com In body: subscribe (unsubscribe) Archive: http://sonic.sparklist.com/scripts/lyris.pl?enter=vompls From owner-mpls@UU.NET Wed Jan 19 18:14:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06409 for ; Wed, 19 Jan 2000 18:14:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhysq06405; Wed, 19 Jan 2000 23:13:56 GMT Received: by mail-control.mail.uu.net id QQhysq02205 for mpls-outgoing; Wed, 19 Jan 2000 23:13:38 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhysq02168 for ; Wed, 19 Jan 2000 23:13:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhysq04737; Wed, 19 Jan 2000 18:13:19 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQhysq27635; Wed, 19 Jan 2000 23:13:18 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id SAA15247; Wed, 19 Jan 2000 18:12:45 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id SAA26231; Wed, 19 Jan 2000 18:14:33 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200001192314.SAA26231@curtis-lt.avici.com> To: Masataka Ohta cc: pingpan@dnrc.bell-labs.com (Ping Pan), pingpan@research.bell-labs.com, J.Crowcroft@cs.ucl.ac.uk, curtis@avici.com, rsvp@isi.edu, mpls@UU.NET, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com Reply-To: curtis@avici.com Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management In-reply-to: Your message of "Thu, 20 Jan 0 6:00:35 JST ." <200001192100.GAA18692@necom830.hpcl.titech.ac.jp> Date: Wed, 19 Jan 2000 18:14:33 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200001192100.GAA18692@necom830.hpcl.titech.ac.jp>, Masataka Ohta wr ites: > > > > As I have pointed out in RSVP-related WGs and several research papers, > > > RSVP has no scalability problem from the begining. > > > > Huh? Please provide the pointers to your draft. > > That could have been a fair request if you had provided the pointers > to papers or something like that describing the (non-existing) > scalability problem in detail. I'm familiar with the scalability problems that Ping is referring to. The problem of too much state and too high a setup rate in connection oriented protocols is well known. For example, RFC1932 (published in 1996) states: ATM offers QoS and traffic management capabilities that are well suited for certain types of services. It may be advantageous to use separate ATM VC for such services. Other IP services such as DNS, are ill suited for connection oriented delivery, due to their normal very short duration (typically one packet in each direction). Short duration transactions, even many using TCP, may also be poorly suited for a connection oriented model due to setup and state overhead. Most people who have been active in the IETF routing and transport areas are very much aware that there are scaling problems associated with providing end-to-end connections (scaling withn regard to connection state and setup rate) or even virtual paths at too fine a granularity. The question I raised was whether we want to try to solve the problem of scaling virtual paths at a fine granularity. The implication was that we might be better off taking a fundamentally different approach which doesn't pose these scaling problems. For example, currently using plain old IP forwarding at boundaries between traffic engineered MPLS networks avoids the scaling problems. In the past I've suggested that we pass only the traffic classification in the MPLS stack when crossing these boundaries and do an IP lookup, combining the lookup and classification to get traffic on the tunnel in the MPLS domain receiving the packet. Pings work does have merit and it does seem clear (to me at least) that BGP will be involved in any solution to the problem of interdomain QoS. I'm not sure it is the right approach. Maybe you don't understand the problem but Ping does and I do. I'm just questioning whether we can cleverly avoid it rather than try to solve it. It is very clear that you haven't looked at the web pages and drafts that Ping referenced (or couldn't understand them). > So far, even though there are a lot of proposals to try to get > around the problem in vain, I have never seen anyone who had > done so, which is another evidence that there is no problem. > > Instead, I wrote drafts and published papers and pointers are given. I didn't see any URLs. Given your past history (readers may recall RFC1932 was discussed in the IP over ATM WG at about the last time Ohta was insulting people who didn't agree with his "Conventional IP over ATM") I won't be going out of my way to look for them. Please provide the URLs and provide some technical comments of substance or shut up. Please stop insulting people. Curtis ps- diffserv dropped at Brian's request. Any other WG chairs care to declare this out of scope? From owner-mpls@UU.NET Wed Jan 19 19:41:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06826 for ; Wed, 19 Jan 2000 19:41:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhysw22191; Thu, 20 Jan 2000 00:41:29 GMT Received: by mail-control.mail.uu.net id QQhysw20127 for mpls-outgoing; Thu, 20 Jan 2000 00:41:05 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhysw20080 for ; Thu, 20 Jan 2000 00:40:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhysw28018; Wed, 19 Jan 2000 19:40:56 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: necom830.hpcl.titech.ac.jp [131.112.32.132]) id QQhysw21747; Thu, 20 Jan 2000 00:40:55 GMT From: Masataka Ohta Message-Id: <200001200038.JAA19500@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA19500; Thu, 20 Jan 2000 09:38:21 +0900 Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management To: curtis@avici.com Date: Thu, 20 Jan 0 9:38:20 JST Cc: mohta@necom830.hpcl.titech.ac.jp, pingpan@dnrc.bell-labs.com, pingpan@research.bell-labs.com, J.Crowcroft@cs.ucl.ac.uk, rsvp@isi.edu, mpls@UU.NET, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com In-Reply-To: <200001192314.SAA26231@curtis-lt.avici.com>; from "Curtis Villamizar" at Jan 20, 100 8:22 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-mpls@UU.NET Precedence: bulk Curtis; Thank you for your attempt to provide some pointer for the first time in the long history of misunderstanding. However, your attempt does not affect the fact that Ping did not gave pointers to his problem in his mail. > > > > As I have pointed out in RSVP-related WGs and several research papers, > > > > RSVP has no scalability problem from the begining. > > > > > > Huh? Please provide the pointers to your draft. > > > > That could have been a fair request if you had provided the pointers > > to papers or something like that describing the (non-existing) > > scalability problem in detail. > > I'm familiar with the scalability problems that Ping is referring to. Worse, you misunderstand the problem, which should be attributed to Ping who did not give any pointers. > The problem of too much state and too high a setup rate in connection > oriented protocols is well known. For example, RFC1932 (published in > 1996) states: > > ATM offers QoS and traffic management capabilities that are well > suited for certain types of services. It may be advantageous to > use separate ATM VC for such services. Other IP services such as > DNS, are ill suited for connection oriented delivery, due to their > normal very short duration (typically one packet in each > direction). Short duration transactions, even many using TCP, may > also be poorly suited for a connection oriented model due to setup > and state overhead. We are working on resource reserved communication, which is expected to have long (if you think 3 minutes of telephony call long) duration. Ping mentioned multicast, which means DNS and TCP are inappropriate examples, routing of which needs considerable amount of time and control packets regardless of how resource is reserved. > Most people who have been active in the IETF routing and transport > areas are very much aware that there are scaling problems associated > with providing end-to-end connections (scaling withn regard to > connection state and setup rate) or even virtual paths at too fine a > granularity. Thank you again for demonstrating the confusion caused by the lack of pointers to the problem. > Maybe you don't understand the problem but Ping does and I do. I'm You should, like me, better give minimal technical reasoning hopefully founded by published research papers, if you want to say someone is insulting himself by expressing silly opinions. But, first of all, you should ask Ping what his problem is. Masataka Ohta From owner-mpls@UU.NET Wed Jan 19 20:57:30 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07310 for ; Wed, 19 Jan 2000 20:57:29 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhytb22873; Thu, 20 Jan 2000 01:57:17 GMT Received: by mail-control.mail.uu.net id QQhytb04860 for mpls-outgoing; Thu, 20 Jan 2000 01:56:59 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhytb04846 for ; Thu, 20 Jan 2000 01:56:49 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhytb03431; Wed, 19 Jan 2000 20:56:48 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQhytb22450; Thu, 20 Jan 2000 01:56:48 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id UAA22495; Wed, 19 Jan 2000 20:56:09 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id UAA26620; Wed, 19 Jan 2000 20:57:57 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200001200157.UAA26620@curtis-lt.avici.com> To: Masataka Ohta cc: curtis@avici.com, pingpan@dnrc.bell-labs.com, pingpan@research.bell-labs.com, J.Crowcroft@cs.ucl.ac.uk, rsvp@isi.edu, mpls@UU.NET, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com Reply-To: curtis@avici.com Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management In-reply-to: Your message of "Thu, 20 Jan 0 9:38:20 JST ." <200001200038.JAA19500@necom830.hpcl.titech.ac.jp> Date: Wed, 19 Jan 2000 20:57:56 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200001200038.JAA19500@necom830.hpcl.titech.ac.jp>, Masataka Ohta wr ites: > > However, your attempt does not affect the fact that Ping did not gave > pointers to his problem in his mail. Section 2 of the internet-draft cited by Ping is entitled "Problem Definition". I did not agree that the problem needed to be solved, but the statement of the problem seemed very clear to me. The fact remains that Ping gave two URLs. One was to the draft itself and the other was: http://www.cs.columbia.edu/~pingpan/projects/bgrp.html And you gave none. > > I'm familiar with the scalability problems that Ping is referring to. > > Worse, you misunderstand the problem, which should be attributed > to Ping who did not give any pointers. What I described matches the section in Ping's draft. See below. > > Most people who have been active in the IETF routing and transport > > areas are very much aware that there are scaling problems associated > > with providing end-to-end connections (scaling withn regard to > > connection state and setup rate) or even virtual paths at too fine a > > granularity. > > Thank you again for demonstrating the confusion caused by the > lack of pointers to the problem. The description of the problem was in the draft that Ping suggested we consider. You may be confused because you didn't read the cited draft or web pages before sending your insults to the mailing list. Curtis ps- I will not be publicly responding to any further mail from Ohta on this. I express my appologies to the 3 WGs that remain on the Cc for my contribution to the noise so far. From owner-mpls@UU.NET Wed Jan 19 21:11:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07400 for ; Wed, 19 Jan 2000 21:11:34 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhytc08030; Thu, 20 Jan 2000 02:11:30 GMT Received: by mail-control.mail.uu.net id QQhytc13861 for mpls-outgoing; Thu, 20 Jan 2000 02:11:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhytc13829 for ; Thu, 20 Jan 2000 02:11:01 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhytc04496; Wed, 19 Jan 2000 21:10:57 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: necom830.hpcl.titech.ac.jp [131.112.32.132]) id QQhytc07588; Thu, 20 Jan 2000 02:10:55 GMT From: Masataka Ohta Message-Id: <200001200206.LAA19946@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA19946; Thu, 20 Jan 2000 11:06:39 +0900 Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management To: curtis@avici.com Date: Thu, 20 Jan 0 11:06:38 JST Cc: mohta@necom830.hpcl.titech.ac.jp, pingpan@dnrc.bell-labs.com, pingpan@research.bell-labs.com, J.Crowcroft@cs.ucl.ac.uk, rsvp@isi.edu, mpls@UU.NET, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com In-Reply-To: <200001200157.UAA26620@curtis-lt.avici.com>; from "Curtis Villamizar" at Jan 20, 100 11:00 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-mpls@UU.NET Precedence: bulk Curtis; > > However, your attempt does not affect the fact that Ping did not gave > > pointers to his problem in his mail. > > Section 2 of the internet-draft cited by Ping is entitled "Problem I wrote: > > However, your attempt does not affect the fact that Ping did not gave > > pointers to his problem in his mail. > And you gave none. I gave a lot several times including this time. > What I described matches the section in Ping's draft. And does contradict with Ping's mail. So? > The description of the problem was in the draft that Ping suggested we > consider. You may be confused because you didn't read the cited draft > or web pages before sending your insults to the mailing list. It seems to me that you are saying people should read my paper just because I cited it in my mail. Thank you very much, but it is better to just ignore the entire thread. > ps- I will not be publicly responding to any further mail from Ohta on > this. I express my appologies to the 3 WGs that remain on the Cc for > my contribution to the noise so far. Don't mind. That's not your but Ping's fault. Masataka Ohta From owner-mpls@UU.NET Wed Jan 19 23:22:51 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10117 for ; Wed, 19 Jan 2000 23:22:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhytl15075; Thu, 20 Jan 2000 04:22:45 GMT Received: by mail-control.mail.uu.net id QQhytl11124 for mpls-outgoing; Thu, 20 Jan 2000 04:22:20 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhytl11110 for ; Thu, 20 Jan 2000 04:22:09 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhytl13651; Wed, 19 Jan 2000 23:22:03 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhytl04212; Thu, 20 Jan 2000 04:22:02 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Jan 19 23:21:24 EST 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.42.72]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id XAA20704; Wed, 19 Jan 2000 23:21:20 -0500 (EST) Message-ID: <38868D77.DF0968D6@research.bell-labs.com> Date: Wed, 19 Jan 2000 23:22:15 -0500 From: Ping Pan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Masataka Ohta CC: curtis@avici.com, pingpan@dnrc.bell-labs.com, J.Crowcroft@cs.ucl.ac.uk, rsvp@isi.edu, mpls@UU.NET, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management References: <200001200206.LAA19946@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > > I wrote: > > > > However, your attempt does not affect the fact that Ping did not gave > > > pointers to his problem in his mail. > I did give the pointer to my draft. In the draft, I gave 27 references. What is your problem here? > > It seems to me that you are saying people should read my paper > just because I cited it in my mail. > > Thank you very much, but it is better to just ignore the entire thread. > Oh, boy! You're one of kind... I wish you do ignore the entire thread and leave us alone. > > ps- I will not be publicly responding to any further mail from Ohta on > > this. I express my appologies to the 3 WGs that remain on the Cc for > > my contribution to the noise so far. > > Don't mind. > > That's not your but Ping's fault. > Excuse me? Once again, regardless of the noise, I do wish people to read about our work at http://www.cs.columbia.edu/~pingpan/projects/bgrp.html Here is the situation: we have investigated the scaling problem in reservation protocols, proposed a solution, and wanted to hear sensible ideas from all of you to improve the work. At the same time, we are very busy to iron out some of the protocol details before the actual implementation. I have no desire and have no time to waste on some personal attacks from Ohta-son. From now on, I will not response to Ohta's mails (surely he will have more to come, unfortunately.) Sorry about all this! - Ping From owner-mpls@UU.NET Thu Jan 20 13:26:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11106 for ; Thu, 20 Jan 2000 13:26:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyvp00304; Thu, 20 Jan 2000 18:26:12 GMT Received: by mail-control.mail.uu.net id QQhyvp03688 for mpls-outgoing; Thu, 20 Jan 2000 18:25:41 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyvp03681 for ; Thu, 20 Jan 2000 18:25:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyvp14151 for ; Thu, 20 Jan 2000 13:25:31 -0500 (EST) Received: from mailgate.fore.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.fore.com [169.144.68.6]) id QQhyvp21888 for ; Thu, 20 Jan 2000 18:25:31 GMT Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA24253 for ; Thu, 20 Jan 2000 13:25:28 -0500 (EST) Received: from shell.fore.com (shell.fore.com [169.144.2.67]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA29817 for ; Thu, 20 Jan 2000 13:25:31 -0500 (EST) Received: from fore.com (red-dhcp-223.fore.com [169.144.16.223]) by shell.fore.com (8.8.8+Sun/8.8.8) with ESMTP id NAA19163 for ; Thu, 20 Jan 2000 13:20:19 -0500 (EST) Message-ID: <3887530E.369D2BB3@fore.com> Date: Thu, 20 Jan 2000 13:25:18 -0500 From: Debashis Basak X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: draft-basak-mpls-oxc-issues-00.txt Content-Type: multipart/mixed; boundary="------------5F2DF190AA5E30180287F9D0" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------5F2DF190AA5E30180287F9D0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following draft has been recently submitted to the Internet-drafts directory. It is yet to be reflected on the server. -debashis --------------5F2DF190AA5E30180287F9D0 Content-Type: text/plain; charset=us-ascii; name="draft-basak-mpls-oxc-issues-00.txt" Content-Disposition: inline; filename="draft-basak-mpls-oxc-issues-00.txt" Content-Transfer-Encoding: 7bit Internet Draft Debashis Basak Expires: July, 2000 Marconi Daniel O. Awduche UUNet (MCI WorldCom) John Drake Marconi Yakov Rekhter Cisco Multi-protocol Lambda Switching: Issues in Combining MPLS Traffic Engineering Control With Optical Crossconnects Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document describes domain specific enhancements needed to adapt MPLS traffic engineering control plane constructs to control optical crossconnects in emerging automatically switched optical transport networks. These enhancements are within the framework of Multiprotocol LAMBDA switching proposed in [1]. Specifically, this memo investigates the behavior of the MPLS based control plane technique for OXCs, and identifies enhancements required to both OXCs and to existing MPLS control constructs (routing and signaling protocols) to support the application to OXCs. Basak Expires July, 2000 [Page 1] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 1. Introduction Recently, a new paradigm for the design of control planes for OXCs intended for data-centric automatically switched optical transport networks was proposed in [1]. This new paradigm is termed Multiprotocol Lambda Switching and exploits recent advances in MPLS traffic engineering control plane technology to foster the expedited development and deployment of a new class of versatile OXCs that specifically address the optical transport needs of the Internet. This memo describes a number of domain specific enhancements required to map the MPLS control plane constructs to OXCs. The memo describes enhancements to OXCs and WDM devices to the support MPLS based control plane approach. It also discusses extensions to the existing MPLS control plane constructs to better accommodate the needs of the optical transport network elements. 2. Definitions The MPLS control plane has been used (adapted) earlier in conjunction with data planes with specific limitations e.g. ATM-LSRs, FR-LSRs. The adaptation of MPLS control plane to OXCs, resulting in OXC-LSRs, needs to consider specific limitations of the OXC data plane, as identified in [1]. This section presents some definitions that take into account such peculiarities of the OXC data plane. A termination-capable (TC) interface on a label switching router (LSR) is one which is capable of terminating an LSP and demultiplexing data carried by the LSP to make further routing/switching decisions. A point-to-point interface terminating on a router that implements MPLS is an example of a TC interface. A termination-incapable (TI) interface is one which is incapable of terminating LSPs and demultiplexing data carried by the LSP to make further routing/switching decisions. Thus, an LSP incoming on a TI interface of a network device cannot be carrying data destined to different egress points of the device. A fiber connected to an OXC is an example of a TI interface. For a given unidirectional link the interfaces associated with the link's endpoints may be of different types with respect to their ability to terminate an LSP. For example, for a link from a (frame- based) LSR (e.g., router) to an OXC, the interface with the OXC is TI while the one with the LSR is TC. The property of TI or TC is associated with the head of a link, as well, because in a given MPLS Basak Expires July, 2000 [Page 2] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 box it may be possible for an LSP to come in through one interface, be switched across the box, and then terminated at the far end (at the head of a link). If all the interfaces of an LSR are TI interfaces, we'll refer to such an LSR as a TI-LSR. An OXC-LSR today is an example of a TI-LSR (an ATM-LSR is another example of a TI-LSR). If an LSR has at least one TC interface, we'll refer to such an LSR as TC-LSR. A router that implements MPLS is an example of a TC-LSR. A single box may have TC and TI interfaces. For example, one could imagine an optical box that on some interfaces forwards data based on the wavelength/optical trail the data was received and on other interfaces based on the label information carried by packets. One can also envision a hybrid physical interface in which data on certain wavelengths/optical trails is forwarded based on the wavelength/optical trail the data was received and on other wavelengths/optical trails based on the label information carried by packets. Such physical interfaces may be considered as two separate logical interfaces, one TC and the other TI. A TI-LSR domain is a set of TI-LSRs which are mutually interconnected by TI interfaces. An OTN made of a mesh of today's OXC-LSRs is an example of a TI-LSR domain. The Edge set of an TI-LSR domain is the set of TC-LSRs which are interconnected to members of the domain by links with a TC interface on a TC-LSR and a TI interface on a TI-LSR. A TC-LSR which is a member of an Edge set of a TI-LSR domain is called an Edge LSR. Examples of Edge LSRs are access devices to an OTN. Figure 1 below depicts an example network with a single TI-LSR domain consisting of OXCs (O1 through O8) surrounded by an Edge set of TC-LSRs consisting of access routers (M0 through M4). By definition LSPs cannot start/terminate on the LSRs within a TI-LSR domain. LSPs can start/terminate at TC-LSR belonging to the Edge set or beyond. Basak Expires July, 2000 [Page 3] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 _________________ M0---/--O2-----O9 \ / / \ \ M1--|--O1 --O3--O4---O6-|---M3 \ \ / / M2--\--O5 -- O7 --O8--/---M4 \_______________/ TI-LSR domain Mk: A TC-LSR (access routers), Ox: A TI-LSR (OXC) Figure 1: A sample network with a TI-LSR domain surrounded by an Edge set of TC-LSRs. 3. Required Enhancements to OXCs and WDM devices to support MPLS The following contains the list of required enhancements to OXCs and other WDM devices to support MPL(ambda)S: - there should be a way to exchange control information between OXCs, either using the same links (fiber) that is used to carry data, or via a separate network. - an OXC must be able to provide the MPLS control plane with the information about the state of individual fibers attached to that OXC, as well as with the state of individual ligthpaths within each such fiber. - an edge LSR may not have build-in WDM capabilities, but rather may use external WDM device that acts as SONET-to-WDM multiplexor/demultiplexor. That still should allow that LSR to exchange control information with the OXCs. 4. Required Enhancements to the current MPLS control plane. The section describes enhancements to the MPLS TE control component (ISIS/OSPF and RSVP) in order to support MPL(ambda)S. The required enhancements are divided into two sets (A) and (B). A) The first set concerns enhancements to adapt to the peculiarities of OXCs: Basak Expires July, 2000 [Page 4] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 - the RSVP Label Object, in combination with already available IGP and RSVP information, should be able to provide sufficient information to program cross-connect matrix on OXCs. - when a pair of OXCs are connected by multiple links (fibers), an IGP needs to carry information about physical diversity of the fiber. - since bandwidth allocation on an OXC is discrete, an IGP should be able to carry the information about bandwidth granularity of a particular link. This information should allow support for multiple granularities within a single link, as well as for different granularities per priority. Additional requirements imposed by OXCs that can't perform wavelength translation are outside the scope of the discussion in this document. B) As indicated in [1], essential to the use of MPLS with OXCs is the ability to aggregate LSPs by using the notion of "nested" LSP. MPLS allows several ways to implement nested LSPs. One way to accomplish this is to have a single MPLS control plane, but allow this control plane to treat some of the LSPs created and maintained by the control plane as links for the purpose of establishing new LSPs (by the same control plane). That is the MPLS control plane could use an LSP as a link to form another LSP, and that other LSP, in turn, could be used as a link to form some other LSP, etc... Another way to accomplish this is to have multiple instances of the MPLS control plane, and allow LSPs created by one instance of the control plane to be used as links by some other instance of the control plane. Regardless of whether one uses a single or multiple instances of the MPLS control plane, the LSPs that are used as links could be established by either (a) means outside of the MPLS control plane (e.g., by configuration), or (b) by means of the MPLS control plane itself. The following contains the list of required enhancements to the MPLS TE control component (ISIS/OSPF and RSVP) in order to support the ability to aggregate LSPs in MPL(ambda)S: Basak Expires July, 2000 [Page 5] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 - an IGP should carry information about whether a particular link is termination capable (TC) or not (TI). OSPF should be able to take this information into account when computing paths for optical trails. - the LSP setup procedures should include support for an LSR at the edge of TI-LSR domain to aggregate multiple LSPs coming from outside of the TI-LSR domain into an LSP that is an optical trail. - an LSR should be able to advertise into an IGP a link that is formed out of an LSP originated by the LSR, and SPF/OSPF procedures should be able to use such a link for path computation. - one instance of MPLS should be able to present LSPs created/maintained by that instance as links to another instance of MPLS. The two instances may reside either on the same, or on different devices. Note that the ability to aggregate LSPs by nesting may be useful outside of the OXC environment as well. The enhancements specified above in support of aggregate LSPs have to implemented in such a way as to allow non-OXC environments. The specifications of the enhancements to the MPLS TE control component in support of MPL(ambda)S will be covered in a supplimentary document to follow. 5. Security Considerations Security considerations are for future study. 6. References [1] D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control With Optical Crossconnects", Internet Draft, Work in Progress. [2] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, "Requirements for Traffic Engineering Over MPLS," RFC-2702, September 1999. Basak Expires July, 2000 [Page 6] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 [3] D. Awduche, "MPLS and Traffic Engineering in IP Networks," IEEE Communications Magazine, December 1999. [4] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, and V. Srinivasan, "Extensions to RSVP for LSP Tunnels," Internet Draft, Work in Progress, 1999 [5] B. Jamoussi et al, "Constraint-Based LSP Setup using LDP," Internet Draft, Work in Progress, 1999 [6] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A. Viswanathan, "A Framework for Multiprotocol Label Switching," Internet Draft, Work in Progress, 1999 [7] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture," Internet Draft, Work in Progress, 1999 [8] T. Li, G. Swallow, D. Awduche, "IGP Requirements for Traffic Engineering with MPLS," Internet Draft, Work in Progress, 1999 [9] H. Smith and T. Li, "IS-IS extensions for Traffic Engineering," Internet Draft, Work in Progress, 1999 [10] D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF," Internet Draft, Work in Progress, 1999 7. Author's Addresses Debashis Basak Marconi 1000 FORE Drive Warrendale, PA 15086-7502 Phone: 724-742-7026 Email: dbasak@fore.com Daniel O. Awduche UUNET (MCI WorldCom) Loudoun County Parkway Ashburn VA Phone: 703-886-5277 Email: awduche@uu.net John Drake Marconi 1000 FORE Drive Warrendale, PA 15086-7502 Basak Expires July, 2000 [Page 7] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 Phone: 724-742-6798 Email: drake@fore.com Yakov Rekhter Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 Email: yakov@cisco.com Basak Expires July, 2000 [Page 8] --------------5F2DF190AA5E30180287F9D0-- From owner-mpls@UU.NET Thu Jan 20 15:44:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15001 for ; Thu, 20 Jan 2000 15:44:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyvy24993; Thu, 20 Jan 2000 20:43:37 GMT Received: by mail-control.mail.uu.net id QQhyvy28351 for mpls-outgoing; Thu, 20 Jan 2000 20:43:02 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhyvy28346 for ; Thu, 20 Jan 2000 20:42:51 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyvy02417 for ; Thu, 20 Jan 2000 15:42:49 -0500 (EST) Received: from mail.hq.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tlab-138-111-51-100.tellabs.com [138.111.51.100]) id QQhyvy12398 for ; Thu, 20 Jan 2000 20:42:48 GMT Received: from vsharma ([172.31.101.69] (may be forged)) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id OAA15674; Thu, 20 Jan 2000 14:42:44 -0600 (CST) Received: by localhost with Microsoft MAPI; Thu, 20 Jan 2000 15:45:48 -0500 Message-ID: <01BF635D.6BC3B6C0.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'swallow@cisco.com'" , "mpls@UU.NET" Subject: RE: Draft of revised charter Date: Thu, 20 Jan 2000 15:45:46 -0500 Organization: Tellabs Research Center, Cambridge X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi George, I would like to suggest adding the following as a milestone: Produce specifications for protocols and procedures that support LSP recovery, and suggest Aug. 00 as a possible target date. (The requirements document for supporting LSP recovery is already being worked on with a target date of March. I am hoping that other relevant documentation can be revised and polished by Aug.) Thanks, -Vishal On Wednesday, January 19, 2000 3:27 PM, swallow@cisco.com [SMTP:swallow@cisco.com] wrote: > Folks, > > Attached is a draft of the revised MPLS charter. The goals and > milestones section is far from complete. I've listed a few items > where I know that there are people committed to doing the work. > Please send ideas for further goals and other comments to the list. > > Thanks, > > George & Vijay > > ====================================================================== > > > Multiprotocol Label Switching (mpls) Charter > > > Problem Statement: > > Label switching in conjunction with network layer routing has emerged > as an important new technology. It is actively being applied to > applications such as traffic engineering and virtual private networks. > Among the problems this technology is expected to address are the > following: > > 1. Greater flexibility in delivering routing services > > Using labels to identify particular traffic which are to receive > special services, e.g. QoS. > > Using labels to provide forwarding along an explicit path different > from the one constructed by destination-based forwarding. > > 2. Scalability of network layer routing > > Using labels as a means to aggregate forwarding information, while > working in the presence of routing hierarchies. > > 3. Simplify integration of routers with cell switching based > technologies > > a) making cell switches behave as peers to routers (thus reducing > the number of routing peers that a router has to maintain), > > b) by making information about physical topology available to > Network Layer routing procedures, and > > c) by employing common addressing, routing, and management > procedures. > > 4. Simplify integration of routers with optical cross-connect based > technologies > > a) making optical cross connects behave as peers to routers (thus > reducing the number of routing peers that a router has to maintain), > > b) by making information about physical topology available to > Network Layer routing procedures, and > > c) by employing common addressing, routing, and management > procedures. > > High Level Requirements > > 1. The solution should be general with respect to data link > technologies. Specific optimizations for particular media will be > considered. > > 2. The solution must be compatible with existing internetwork > technologies and routing protocols. > > 3. The solution should support a wide range of forwarding > granularities associated with a given label, from a single > application flow to a group of topologically related destinations. > > 4. The solution should support operations, administration, and > maintenance facilities at least as extensive as those supported in > IP networks. > > 5. The solution should provide stable routing. The protocols defined > by MPLS must provide protocol mechanism(s) to either prevent the > formation of loops and/or contain the amount of (networking) resources > that could be consumed due to the presence of such loops. > > 6. The solution should be very scalable. Scalability issues will be > considered and analyzed. > > > Charter Statement: > > The working group is responsible for standardizing a base technology > for using label switching in conjunction with network layer routing > and for the implementation of that technology over various link level > technologies, which may include Packet-over-Sonet, Frame Relay, ATM, > Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,... > > This includes procedures and protocols for the distribution of labels > between routers, encapsulations, multicast considerations, and the use > of labels to support higher layer resource reservation and QoS > mechanisms. > > The working group will also specify a control plane for optical cross > connects. In this environment specific wave lengths or Lambdas are > used instead of labels. > > > Objectives: > > 1. Specify standard protocol(s) for maintenance and distribution of > label binding information to support unicast destination-based > routing. > > 2. Specify standard protocol(s) for maintenance and distribution of > label binding information to support multicast routing. > > 3. Specify standard protocol(s) for maintenance and distribution of > label binding information to support hierarchy of routing knowledge > (e.g., complete segregation of intra and inter-domain routing). > > 4. Specify standard protocol(s) for maintenance and distribution of > label binding information to support explicit paths in support of > applications such as Traffic Engineering. > > 5. Specify standard protocols and procedures to support the fast > recovery of Label Switched Paths. > > 6. Specify extensions to the protocols and procedures used for > signaling explicit routes and to effect fast recovery of LSPs > for use in Optical Cross Connects. > > 7. Specify standard procedures of carrying label information over > various link level technologies including ATM. > > 8. Define the use of Differentiated and Integrated Services in an MPLS > environment. > > 9. Specify standard protocols and procedures to support operations, > administration, and maintenance facilities. > > > Coordination: > > The working group will coordinate its activities with other working > groups as appropriate. For specific technologies, the WG will > cooperate with the appropriate standards bodies such as OIF, ITU-T, > ANSI, etc. > > > Goals and Milestones: > > Mar 00 - Produce a document which defines support of Differentiated > Services (Diff-Serv) over Multi-Protocol Label Switching > (MPLS) networks (Standards Track). > > Aug 00 - Produce a document which defines operation with RSVP for > unicast destinations. (Standards Track). > > Dec 00 - Produce specifications for a MPLS control plane for optical > cross-connects (Standards Track). > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Jan 21 06:47:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06868 for ; Fri, 21 Jan 2000 06:47:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyyh17075; Fri, 21 Jan 2000 11:47:19 GMT Received: by mail-control.mail.uu.net id QQhyyh04696 for mpls-outgoing; Fri, 21 Jan 2000 11:46:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyyh04691 for ; Fri, 21 Jan 2000 11:46:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyyh16503 for ; Fri, 21 Jan 2000 06:46:25 -0500 (EST) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQhyyh17592 for ; Fri, 21 Jan 2000 11:46:25 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06842; Fri, 21 Jan 2000 06:46:19 -0500 (EST) Message-Id: <200001211146.GAA06842@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-state-03.txt Date: Fri, 21 Jan 2000 06:46:19 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP State Machine Author(s) : C. Boscher, P. Cheval, L. Wu, E. Gray Filename : draft-ietf-mpls-ldp-state-03.txt Pages : 76 Date : 20-Jan-00 In the current LDP specification [4], there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This document provides state machine tables for ATM switch LSRs. We begin in section 2 by defining a list of terminologies. Then in section 3, we propose two sets of state machine tables for ATM switch LSRs which use downstream-on-demand mode, one method can be used for non-vc merge capable ATM LSRs, while the other one can be used for the vc-merge capable ATM LSRs. In section 4, we provides a state machine for downstream unsolicited mode ATM LSRs. We focus on the LDP state machines and the associated control blocks used for establishing and maintaining LSPs. We do not describe state machines for the 'LDP controller' which is in charge of LDP session initialization, address mapping messages management, routing interface, etc. which is defined in the LDP specification [4]. Even though the state machines in this document are specific for ATM-LSR, they can be easily adapted for other types of LSRs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-state-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-state-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-state-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: <20000120095631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-state-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-state-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000120095631.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Jan 21 11:03:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12488 for ; Fri, 21 Jan 2000 11:03:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyyy13233; Fri, 21 Jan 2000 16:03:07 GMT Received: by mail-control.mail.uu.net id QQhyyy22934 for mpls-outgoing; Fri, 21 Jan 2000 16:02:07 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyyy22844 for ; Fri, 21 Jan 2000 16:01:58 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyyy19837 for ; Fri, 21 Jan 2000 11:01:52 -0500 (EST) Received: from stimpy.motispd.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: stimpy.motispd.com [208.243.217.11]) id QQhyyy10855 for ; Fri, 21 Jan 2000 16:01:51 GMT Received: from pathannt (208.243.217.84) by stimpy.motispd.com (Worldmail 1.3.167); 21 Jan 2000 10:03:29 -0600 Message-ID: <01c801bf643a$0f18af60$54d9f3d0@pathannt> From: "Aijaz Pathan" To: Cc: Subject: MTU for tag/MPLS packets Date: Fri, 21 Jan 2000 10:05:11 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C5_01BF63F7.00E62D20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01C5_01BF63F7.00E62D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I was wondering if anyone had info/pointers to how a Tag/MPLS edge node = should handle change in the MTU size=20 because of addition of 4 bytes of tag header for Ethernet interfaces. = For example, if the incoming Ethernet packet is already of MTU length, = addition of the 4 bytes will cause it to be dropped when sent out = another Ethernet interface. In the book "Switching in IP networks" ( By Davie, Doolan, and Rekhter = ), section 5.3 says: "Tag switching uses the IP Path MTU Dsicovery procedures to ensure that = even after the shim layer is added to the packet, the resulting packet = size doesn't exceed the maximum packet size that could be transmitted = without fragmentation." What exactly are these "IP Path MTU Discovery procedures"? Is there any = other way of avoiding fragmentation? Thanks in advance. *****************************************************************=20 Aijaz Pathan = =20 Motorola IPO = =20 8303 N. Mopac Expway, St. A-400 =20 Austin, TX 78759 = =20 =20 Ph:512.583.2313 = =20 Fax:512.583.2350 = =20 Pager:888.442.5946 = =20 ****************************************************************** ------=_NextPart_000_01C5_01BF63F7.00E62D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,
 
I was wondering if anyone had info/pointers to how a Tag/MPLS edge = node=20 should handle change in the MTU size
because of addition of 4 bytes of tag header for Ethernet = interfaces. For=20 example, if the incoming Ethernet packet is already of MTU length, = addition of=20 the 4 bytes will cause it to be dropped when sent out another Ethernet=20 interface.
 
In the book "Switching in IP networks" ( By Davie, Doolan, and = Rekhter ),=20 section 5.3 says:
"Tag switching uses the IP Path MTU Dsicovery procedures to ensure = that=20 even after the shim layer is added to the packet, the resulting packet = size=20 doesn't exceed the maximum packet size that could be transmitted without = fragmentation."
 
What exactly are these "IP Path MTU Discovery procedures"? Is there = any=20 other way of avoiding fragmentation?
 
Thanks in advance.
 
*****************************************************************=20
           &nb= sp;           &nbs= p;          =20 Aijaz=20 Pathan           &= nbsp;           &n= bsp;           &nb= sp;       =20
           &nb= sp;           &nbs= p;          =20 Motorola=20 IPO           &nbs= p;            = ;            =       =20
           &nb= sp;        =20 8303 N. Mopac Expway, St.=20 A-400           &n= bsp;    =20
           &nb= sp;           &nbs= p;       =20 Austin, TX=20 78759           &n= bsp;           &nb= sp;           &nbs= p;  =20
           &nb= sp;           &nbs= p;      =20
           &nb= sp;           &nbs= p;        =20 Ph:512.583.2313         &nbs= p;            = ;            =     =20
           &nb= sp;           &nbs= p;       =20 Fax:512.583.2350         &nb= sp;           &nbs= p;            = ;   =20
           &nb= sp;           &nbs= p;     =20 Pager:888.442.5946         &= nbsp;           &n= bsp;          =20
****************************************************************** ------=_NextPart_000_01C5_01BF63F7.00E62D20-- From owner-mpls@UU.NET Fri Jan 21 11:21:11 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13118 for ; Fri, 21 Jan 2000 11:21:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyyz24493; Fri, 21 Jan 2000 16:20:54 GMT Received: by mail-control.mail.uu.net id QQhyyz29881 for mpls-outgoing; Fri, 21 Jan 2000 16:20:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhyyz29872 for ; Fri, 21 Jan 2000 16:20:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyyz15034 for ; Fri, 21 Jan 2000 11:20:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhyyz21787 for ; Fri, 21 Jan 2000 16:20:01 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jan 21 11:19:09 EST 2000 Received: from lucent.com (vasanthipc [135.180.130.137]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA10661; Fri, 21 Jan 2000 11:19:08 -0500 (EST) Message-ID: <388886C5.7E9263C4@lucent.com> Date: Fri, 21 Jan 2000 11:18:13 -0500 From: Vasanthi Thirumalai Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: Aijaz Pathan CC: mpls@UU.NET Subject: Re: MTU for tag/MPLS packets References: <01c801bf643a$0f18af60$54d9f3d0@pathannt> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Aijaz, You can find details of how MPLS handles the MTU issue by looking into section 3 of the label encaps draft. You can find this doc at: http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-07.txt IP Path MTU discovery is the procedure by which a host discovers the smallest MTU size of all the links along the path. If a router finds that a packet is too big to transmit, but it cannot fragment it because the 'don't fragment bit' is set, it sends an alerting message to the source of the packet. This feature is what is used in Path MTU discovery. You can find more details about it in RFC 1191. -Vasanthi > Aijaz Pathan wrote: > > Hi All, > > I was wondering if anyone had info/pointers to how a Tag/MPLS edge node should > handle change in the MTU size > because of addition of 4 bytes of tag header for Ethernet interfaces. For > example, if the incoming Ethernet packet is already of MTU length, addition of > the 4 bytes will cause it to be dropped when sent out another Ethernet > interface. > > In the book "Switching in IP networks" ( By Davie, Doolan, and Rekhter ), > section 5.3 says: > "Tag switching uses the IP Path MTU Dsicovery procedures to ensure that even > after the shim layer is added to the packet, the resulting packet size doesn't > exceed the maximum packet size that could be transmitted without > fragmentation." > > What exactly are these "IP Path MTU Discovery procedures"? Is there any other > way of avoiding fragmentation? > > Thanks in advance. > > ***************************************************************** > Aijaz > Pathan > Motorola > IPO > 8303 N. Mopac Expway, St. A-400 > Austin, TX > 78759 > > > Ph:512.583.2313 > > Fax:512.583.2350 > > Pager:888.442.5946 > ****************************************************************** -- ------------------------------------------------ Vasanthi Thirumalai Phone: 732-949-3787 Lucent Technologies Room : 2J-643 101 Crawfords Corner Holmdel, NJ-07733 ------------------------------------------------ From owner-mpls@UU.NET Fri Jan 21 11:26:29 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13198 for ; Fri, 21 Jan 2000 11:26:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyyz28258; Fri, 21 Jan 2000 16:26:10 GMT Received: by mail-control.mail.uu.net id QQhyyz00251 for mpls-outgoing; Fri, 21 Jan 2000 16:25:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhyyz00246 for ; Fri, 21 Jan 2000 16:25:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyyz15773 for ; Fri, 21 Jan 2000 11:25:39 -0500 (EST) Received: from pilot013.cl.msu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilot013.cl.msu.edu [35.9.5.113]) id QQhyyz27705 for ; Fri, 21 Jan 2000 16:25:34 GMT Received: from cse.msu.edu (vappala.user.msu.edu [35.10.17.48]) by pilot013.cl.msu.edu (8.9.1a/8.9.1) with ESMTP id LAA42058; Fri, 21 Jan 2000 11:25:32 -0500 Message-ID: <388889C6.9C55645@cse.msu.edu> Date: Fri, 21 Jan 2000 11:31:02 -0500 From: Vasu Vuppala X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Aijaz Pathan , mpls@UU.NET Subject: Re: MTU for tag/MPLS packets Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ajiaz, draft-ietf-mpls-label-encaps-07.txt discusses this issue. Path MTU discovery is explained in RFC1191 and RFC1435. Long, long time ago we had briefly discussed adding MTU TLV to LDP but it was not pursued due to the amount of control traffic it would generate with MTU changes. - vasu --- Aijaz Pathan wrote: > Hi All, > > I was wondering if anyone had info/pointers to how a Tag/MPLS edge > node should handle change in the MTU size > because of addition of 4 bytes of tag header for Ethernet interfaces. > For example, if the incoming Ethernet packet is already of MTU > length, addition of the 4 bytes will cause it to be dropped when sent > out another Ethernet interface. > > In the book "Switching in IP networks" ( By Davie, Doolan, and > Rekhter ), section 5.3 says: > "Tag switching uses the IP Path MTU Dsicovery procedures to ensure > that even after the shim layer is added to the packet, the resulting > packet size doesn't exceed the maximum packet size that could be > transmitted without fragmentation." > > What exactly are these "IP Path MTU Discovery procedures"? Is there > any other way of avoiding fragmentation? > > Thanks in advance. > From owner-mpls@UU.NET Fri Jan 21 12:48:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14644 for ; Fri, 21 Jan 2000 12:48:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzf19689; Fri, 21 Jan 2000 17:48:42 GMT Received: by mail-control.mail.uu.net id QQhyzf13708 for mpls-outgoing; Fri, 21 Jan 2000 17:48:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyzf13700 for ; Fri, 21 Jan 2000 17:48:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyzf04644; Fri, 21 Jan 2000 12:48:03 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhyzf15345; Fri, 21 Jan 2000 17:48:01 GMT Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jan 21 12:47:06 EST 2000 Received: from research.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA14328; Fri, 21 Jan 2000 12:47:05 -0500 (EST) Message-ID: <38889B40.AE8BF69@research.bell-labs.com> Date: Fri, 21 Jan 2000 12:45:36 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: curtis@avici.com CC: rsvp@isi.edu, mpls@UU.NET, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management References: <200001192314.SAA26231@curtis-lt.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > The question I raised was whether we want to try to solve the problem > of scaling virtual paths at a fine granularity. The implication was > that we might be better off taking a fundamentally different approach > which doesn't pose these scaling problems. Curtis: Good question. The way I look at this is the following: end users should have the option to ask networks for resource reservation, and the ISP's should have the ability to setup and maintain big bandwidth "pipes" among each other. End-user level reservation should be designed to handle applications such as telephony, TV, inter-active games, and mobile user communication. This type of reservation has short duration (less than a day) and small bandwidth usage (at most 1Mbps), but the networks need to respond the reservation setup requests very quickly (within a few seconds). (Note, I don't quite believe WEB traffic and pre-stored multimedia traffic request end-user reservations. I normally have no problem to hear music from RealPlayer from my office LAN. ;-)) Network-level reservations are used for an entirely different set of applications: business-to-business communication, Internet server access (such as Blockbuster on-line), data exchange among WEB proxy servers. The requirements for network-level reservation are thus different from end-user reservation: longer duration (weeks if not months), larger bandwidth, and more tolerant recovery time (probably in terms of minutes). I believe this is a good model for the future Internet. The potential for this type of network will make the 90's like minor-league games. But given the number of end users, networks and ISP's, and their growth rate, we have to have a hierarchical architecture for resource reservation. At end-user level, RSVP and YESSIR (another pet project that I am working on ;-)) will be good enough. Our proposed work, BGRP, is targeted to setup and maintain Big-Fat-Reservations (BFR) among ISP's. At network edge, it's up to the access routers to classify small end user reservations into the BFR pipes. Between ISP's, BGRP uses the bi-lateral agreement information to determine how/where to lay the pipes. > > Pings work does have merit and it does seem clear (to me at least) > that BGP will be involved in any solution to the problem of > interdomain QoS. I'm not sure it is the right approach. > Using BGP is to borrow the domain infrastructure for the hierarchical model. I don't think we should define another way to characterize large networks. (Let's not re-invent OSI addressing model for the Internet. ;-)) So yes, let's use BGP for the support of inter-domain QoS/CoS. The mechanism that we used in BGRP comes from the dozens of solutions that we could think of. For example, the reason for sending PROBE messages prior to reservation is due to the fact that the reservation senders really don't know the exact inter-domain routing path. This is because BGP is not driven by some fixed shorest-path algorithm, rather it's based on the local routing policies at border routers.... We love the hear more suggestions on better mechanism to achieve sink-tree aggregation for inter-domain traffic. Thanks alot for everything! My 2 cents, -- Ping Pan http://www.cs.columbia.edu/~pingpan From owner-mpls@UU.NET Fri Jan 21 12:58:55 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14746 for ; Fri, 21 Jan 2000 12:58:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzf21791; Fri, 21 Jan 2000 17:58:41 GMT Received: by mail-control.mail.uu.net id QQhyzf14121 for mpls-outgoing; Fri, 21 Jan 2000 17:58:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyzf14116 for ; Fri, 21 Jan 2000 17:58:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyzf27599 for ; Fri, 21 Jan 2000 12:57:56 -0500 (EST) Received: from ice.ip.qwest.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ice.ip.qwest.net [216.111.66.200]) id QQhyzf21190 for ; Fri, 21 Jan 2000 17:57:55 GMT Received: from ice.ip.qwest.net (localhost [127.0.0.1]) by ice.ip.qwest.net (8.9.3/8.9.3) with ESMTP id LAA23559; Fri, 21 Jan 2000 11:00:41 -0700 (MST) Message-Id: <200001211800.LAA23559@ice.ip.qwest.net> To: Vasu Vuppala cc: Aijaz Pathan , mpls@UU.NET From: Danny McPherson Reply-To: danny@ice.ip.qwest.net Subject: Re: MTU for tag/MPLS packets Date: Fri, 21 Jan 2000 11:00:41 -0700 Sender: owner-mpls@UU.NET Precedence: bulk > draft-ietf-mpls-label-encaps-07.txt discusses this issue. > > Path MTU discovery is explained in RFC1191 and RFC1435. > > Long, long time ago we had briefly discussed adding MTU TLV to LDP > but it was not pursued due to the amount of control traffic it would > generate with MTU changes. The amount of MTU changes? How often did folks envision actually expereincing "MTU changes"? It does seem a bit kludgey to include the MTU and the PMTU stuff does seems a better solution, but I really don't see MTU changes much (at all) in production networks. -danny From owner-mpls@UU.NET Fri Jan 21 13:40:01 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15427 for ; Fri, 21 Jan 2000 13:39:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzi19932; Fri, 21 Jan 2000 18:39:42 GMT Received: by mail-control.mail.uu.net id QQhyzi24681 for mpls-outgoing; Fri, 21 Jan 2000 18:39:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyzi24676 for ; Fri, 21 Jan 2000 18:39:03 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyzi02384 for ; Fri, 21 Jan 2000 13:38:46 -0500 (EST) Received: from pilot021.cl.msu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilot021.cl.msu.edu [35.9.5.121]) id QQhyzi19267 for ; Fri, 21 Jan 2000 18:38:45 GMT Received: from cse.msu.edu (vappala.user.msu.edu [35.10.17.48]) by pilot021.cl.msu.edu (8.9.1a/8.9.1) with ESMTP id NAA41842; Fri, 21 Jan 2000 13:38:31 -0500 Message-ID: <3888A8F2.33AAEA05@cse.msu.edu> Date: Fri, 21 Jan 2000 13:44:02 -0500 From: Vasu Vuppala X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: danny@ice.ip.qwest.net, Aijaz Pathan , mpls@UU.NET Subject: Re: MTU for tag/MPLS packets Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Danny, --- Danny McPherson wrote: > > > > draft-ietf-mpls-label-encaps-07.txt discusses this issue. > > > > Path MTU discovery is explained in RFC1191 and RFC1435. > > > > Long, long time ago we had briefly discussed adding MTU TLV to LDP > > but it was not pursued due to the amount of control traffic it > would > > generate with MTU changes. > > The amount of MTU changes? How often did folks envision actually > expereincing "MTU changes"? > My wording was off. By that, I did not mean changes to the MTU of a link, but the "MTU" of the path i.e. LSP, which would change with the topology. > It does seem a bit kludgey to include the MTU and the PMTU stuff > does seems a better solution, but I really don't see MTU changes > much (at all) in production networks. The problem with "PMTU stuff" is that it is specific to IP. There seems to be an interest in (directly) carrying other protocols over MPLS for bridging, LLC/SNAP, voice etc, and it does not work there. Another subtle and remote problem which had been discussed: PMTU is generally associated with a destination (on the source node) and not a "path", which makes sense for IP paths. With MPLS, there can be multiple paths between a source and a destination, and this may lead to problems (imagine two applications using the different paths). but the PMTU solution is good enough for the time being. - vasu From owner-mpls@UU.NET Fri Jan 21 13:48:23 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15515 for ; Fri, 21 Jan 2000 13:48:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzj21679; Fri, 21 Jan 2000 18:48:07 GMT Received: by mail-control.mail.uu.net id QQhyzj25376 for mpls-outgoing; Fri, 21 Jan 2000 18:47:34 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyzj25371 for ; Fri, 21 Jan 2000 18:47:32 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyzj11674 for ; Fri, 21 Jan 2000 13:47:16 -0500 (EST) Received: from drawbridge.ascend.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: drawbridge.ascend.com [198.4.92.1]) id QQhyzj24416 for ; Fri, 21 Jan 2000 18:47:16 GMT Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id KAA20850; Fri, 21 Jan 2000 10:40:33 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 21 Jan 2000 18:46:40 UT Received: from spud.ascend.com (spud [192.207.23.51]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id KAA26469; Fri, 21 Jan 2000 10:46:39 -0800 (PST) Received: from malisa2 ([152.148.90.98]) by spud.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id KAA18705; Fri, 21 Jan 2000 10:46:39 -0800 (PST) Message-Id: <4.2.2.20000121132755.00bc66e0@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 13:46:35 -0500 To: George Swallow From: "Andrew G. Malis" Subject: Re: Draft of revised charter Cc: mpls@UU.NET, swallow@cisco.com In-Reply-To: <200001192027.PAA29242@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk George, >Objectives: > > >8. Define the use of Differentiated and Integrated Services in an MPLS >environment. I suggest the above objective be changed to "aggregated QoS", as discussed in November. From the minutes: "Vijay asked if people are comfortable that the only QoS being discussed here is the DiffServ model. This question served to generate quite a bit of discussion. Bruce Davies said that he would like to see IntServ semantics included, as well as the explicit congestion notification work. Joel Halpern said that there are several issues that have gotten confused. He pointed out that all of the proposals we have looked at with interest aggregate QoS for scaling purposes. For the purposes of the charter, this could be listed as "based on aggregated QoS", which is more general than just DiffServ. Vijay withdrew his question." On a different charter topic, I think the charter should specifically mention that the WG plans to liaise with other standards bodies, especially in the optical area, such as OIF, ITU-T, ANSI, ODSI, etc.. This would prevent unnecessary duplication of effort, have the IETF output reviewed by other bodies that have the appropriate expertise, and prevent unintended interactions with other existing and developing standards. Optical is a new area for the IETF and it would be pure hubris for us to work in a vacuum, or just assume that the necessary interactions will take place automatically. Thanks, Andy From owner-mpls@UU.NET Fri Jan 21 13:59:59 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15661 for ; Fri, 21 Jan 2000 13:59:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzj28464; Fri, 21 Jan 2000 18:59:49 GMT Received: by mail-control.mail.uu.net id QQhyzj26300 for mpls-outgoing; Fri, 21 Jan 2000 18:59:14 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyzj26295 for ; Fri, 21 Jan 2000 18:59:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyzj04622 for ; Fri, 21 Jan 2000 13:58:54 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhyzj01583 for ; Fri, 21 Jan 2000 18:58:54 GMT Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id KAA20030; Fri, 21 Jan 2000 10:58:49 -0800 (PST) Message-Id: <4.2.2.20000121135533.00a49180@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 13:57:11 -0500 To: "Andrew G. Malis" , George Swallow From: Chip Sharp Subject: Re: Draft of revised charter Cc: mpls@UU.NET, swallow@cisco.com In-Reply-To: <4.2.2.20000121132755.00bc66e0@alpo.casc.com> References: <200001192027.PAA29242@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 01:46 PM 1/21/00 -0500, Andrew G. Malis wrote: >George, > >>Objectives: >> >> >>8. Define the use of Differentiated and Integrated Services in an MPLS >>environment. > >I suggest the above objective be changed to "aggregated QoS", as discussed >in November. From the minutes: > >"Vijay asked if people are comfortable that the only QoS being >discussed here is the DiffServ model. This question served to >generate quite a bit of discussion. Bruce Davies said that he would >like to see IntServ semantics included, as well as the explicit >congestion notification work. Joel Halpern said that there are >several issues that have gotten confused. He pointed out that all of >the proposals we have looked at with interest aggregate QoS for >scaling purposes. For the purposes of the charter, this could be >listed as "based on aggregated QoS", which is more general than just >DiffServ. Vijay withdrew his question." > > >On a different charter topic, I think the charter should specifically >mention that the WG plans to liaise with other standards bodies, >especially in the optical area, such as OIF, ITU-T, ANSI, ODSI, >etc.. This would prevent unnecessary duplication of effort, have the IETF >output reviewed by other bodies that have the appropriate expertise, and >prevent unintended interactions with other existing and developing >standards. Optical is a new area for the IETF and it would be pure hubris >for us to work in a vacuum, or just assume that the necessary interactions >will take place automatically. I believe that ITU-T should also liaise to IETF mpls before embarking on new adventures in MPLS. :-) BTW, ITU has assigned a number to I.ipatm: Y.1310 It is scheduled for approval in March. Chip >Thanks, >Andy > Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-mpls@UU.NET Fri Jan 21 14:21:13 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15918 for ; Fri, 21 Jan 2000 14:21:12 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzl11181; Fri, 21 Jan 2000 19:20:57 GMT Received: by mail-control.mail.uu.net id QQhyzl05485 for mpls-outgoing; Fri, 21 Jan 2000 19:20:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyzl05475 for ; Fri, 21 Jan 2000 19:20:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyzl15739 for ; Fri, 21 Jan 2000 14:20:03 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQhyzl10455 for ; Fri, 21 Jan 2000 19:20:03 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA10815; Fri, 21 Jan 2000 14:20:02 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA01544; Fri, 21 Jan 2000 14:20:02 -0500 (EST) Message-Id: <200001211920.OAA01544@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: "Andrew G. Malis" cc: George Swallow , mpls@UU.NET, swallow@cisco.com Subject: Re: Draft of revised charter In-reply-to: Your message of "Fri, 21 Jan 2000 13:46:35 EST." <4.2.2.20000121132755.00bc66e0@alpo.casc.com> Date: Fri, 21 Jan 2000 14:20:02 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Andy > >8. Define the use of Differentiated and Integrated Services in an MPLS > >environment. > > I suggest the above objective be changed to "aggregated QoS", as discussed > in November. From the minutes: > > "Vijay asked if people are comfortable that the only QoS being > discussed here is the DiffServ model. This question served to > generate quite a bit of discussion. Bruce Davies said that he would > like to see IntServ semantics included, as well as the explicit > congestion notification work. Joel Halpern said that there are > several issues that have gotten confused. He pointed out that all of > the proposals we have looked at with interest aggregate QoS for > scaling purposes. For the purposes of the charter, this could be > listed as "based on aggregated QoS", which is more general than just > DiffServ. Vijay withdrew his question." While I agree that most of what has been done so far is aggregated QoS, I see no need to limit the charter. We do have a albeit expired draft on MPLS and RSVP. I expect that effort to be revived. > On a different charter topic, I think the charter should specifically > mention that the WG plans to liaise with other standards bodies, especially > in the optical area, such as OIF, ITU-T, ANSI, ODSI, etc.. This would > prevent unnecessary duplication of effort, have the IETF output reviewed by > other bodies that have the appropriate expertise, and prevent unintended > interactions with other existing and developing standards. Optical is a > new area for the IETF and it would be pure hubris for us to work in a > vacuum, or just assume that the necessary interactions will take place > automatically. The charter already mentions all the above bodies, with the exception of teh ODSI (is the ODSI formally charter or still in the works?). According to Brian Carpenter the IETF prefers informal liaisons. Further it's actually up to the IAB to establish a formal one. So I think the wording in the charter supports what we need to do be it formal or informal. To state that we're going to establish a formal liaison would inappropriate as that's in the purve of the IAB. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jan 21 14:23:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15946 for ; Fri, 21 Jan 2000 14:23:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzl16281; Fri, 21 Jan 2000 19:22:40 GMT Received: by mail-control.mail.uu.net id QQhyzl05720 for mpls-outgoing; Fri, 21 Jan 2000 19:22:16 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhyzl05707 for ; Fri, 21 Jan 2000 19:22:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyzl07601 for ; Fri, 21 Jan 2000 14:22:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhyzl15788 for ; Fri, 21 Jan 2000 19:22:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jan 21 14:20:03 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.41.150]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA00108; Fri, 21 Jan 2000 14:19:53 -0500 (EST) Message-ID: <3888B268.208303C5@lucent.com> Date: Fri, 21 Jan 2000 14:24:24 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Chip Sharp CC: "Andrew G. Malis" , George Swallow , mpls@UU.NET Subject: Re: Draft of revised charter References: <200001192027.PAA29242@lir.cisco.com> <4.2.2.20000121135533.00a49180@dogwood.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Chip, This may be a bit of a stretch. I.ipatm does not attempt to define how MPLS works, nor does it try to define a new way to do what MPLS does. Asking one organization to liaise with another before selecting a protocol to use for its purposes is a little like asking a carpenter to liaise with a tool manufacturer before selecting a hammer. You wrote: > > At 01:46 PM 1/21/00 -0500, Andrew G. Malis wrote: > >... > > > > > >On a different charter topic, I think the charter should specifically > >mention that the WG plans to liaise with other standards bodies, > >especially in the optical area, such as OIF, ITU-T, ANSI, ODSI, > >etc.. This would prevent unnecessary duplication of effort, have the IETF > >output reviewed by other bodies that have the appropriate expertise, and > >prevent unintended interactions with other existing and developing > >standards. Optical is a new area for the IETF and it would be pure hubris > >for us to work in a vacuum, or just assume that the necessary interactions > >will take place automatically. > > I believe that ITU-T should also liaise to IETF mpls before embarking on > new adventures in MPLS. > :-) > > BTW, ITU has assigned a number to I.ipatm: Y.1310 > It is scheduled for approval in March. > Chip > > >Thanks, > >Andy > > > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- From owner-mpls@UU.NET Fri Jan 21 14:34:43 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16103 for ; Fri, 21 Jan 2000 14:34:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzm19165; Fri, 21 Jan 2000 19:34:28 GMT Received: by mail-control.mail.uu.net id QQhyzm06266 for mpls-outgoing; Fri, 21 Jan 2000 19:34:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhyzm06259 for ; Fri, 21 Jan 2000 19:34:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyzm09253 for ; Fri, 21 Jan 2000 14:34:01 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhyzm18782 for ; Fri, 21 Jan 2000 19:34:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jan 21 14:32:37 EST 2000 Received: from dnrc.bell-labs.com (ex-vpn65.pa.bell-labs.com [135.250.1.65]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA00378; Fri, 21 Jan 2000 14:32:32 -0500 (EST) Message-ID: <3888B4BE.92B677A6@dnrc.bell-labs.com> Date: Fri, 21 Jan 2000 11:34:22 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: "Andrew G. Malis" , mpls@UU.NET Subject: Re: Draft of revised charter References: <200001211920.OAA01544@lir.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 Swallow wrote: [..] > While I agree that most of what has been done so far is aggregated > QoS, I see no need to limit the charter. We do have a albeit expired > draft on MPLS and RSVP. I expect that effort to be revived. "aggregated QoS" in no way limits the charter. on the contrary, "Differentiated and Integrated Services" limits the charter to the models conventionally understood to be meant by those two terms. (even a per-flow intserv model can be viewed as aggregated QoS from the perspective of the application level) cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research Silicon Valley From owner-mpls@UU.NET Fri Jan 21 14:34:54 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16114 for ; Fri, 21 Jan 2000 14:34:51 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzm24314; Fri, 21 Jan 2000 19:34:41 GMT Received: by mail-control.mail.uu.net id QQhyzm06269 for mpls-outgoing; Fri, 21 Jan 2000 19:34:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhyzm06260 for ; Fri, 21 Jan 2000 19:34:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyzm09259 for ; Fri, 21 Jan 2000 14:34:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhyzm23812 for ; Fri, 21 Jan 2000 19:34:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jan 21 14:33:36 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.41.150]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA00396; Fri, 21 Jan 2000 14:33:27 -0500 (EST) Message-ID: <3888B597.ECB9865E@lucent.com> Date: Fri, 21 Jan 2000 14:37:59 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: "Andrew G. Malis" , mpls@UU.NET Subject: Re: Draft of revised charter References: <200001211920.OAA01544@lir.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 Swallow wrote: > > Andy > > > >8. Define the use of Differentiated and Integrated Services in an MPLS > > >environment. > > > > I suggest the above objective be changed to "aggregated QoS", as discussed > > in November. From the minutes: > > > > "Vijay asked if people are comfortable that the only QoS being > > discussed here is the DiffServ model. This question served to > > generate quite a bit of discussion. Bruce Davies said that he would > > like to see IntServ semantics included, as well as the explicit > > congestion notification work. Joel Halpern said that there are > > several issues that have gotten confused. He pointed out that all of > > the proposals we have looked at with interest aggregate QoS for > > scaling purposes. For the purposes of the charter, this could be > > listed as "based on aggregated QoS", which is more general than just > > DiffServ. Vijay withdrew his question." > > While I agree that most of what has been done so far is aggregated > QoS, I see no need to limit the charter. We do have a albeit expired > draft on MPLS and RSVP. I expect that effort to be revived. You would be in a position to know, but I was under the impression that RSVP-Tunnels pretty much covers the bases for RSVP-MPLS once you realize that the messages do not have to carry an explicit route object. I thought this point had been made once or twice already. Or did I miss something? ... > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jan 21 14:45:07 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16241 for ; Fri, 21 Jan 2000 14:45:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzm25338; Fri, 21 Jan 2000 19:44:48 GMT Received: by mail-control.mail.uu.net id QQhyzm06747 for mpls-outgoing; Fri, 21 Jan 2000 19:44:29 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhyzm06742 for ; Fri, 21 Jan 2000 19:44:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyzm10444 for ; Fri, 21 Jan 2000 14:44:08 -0500 (EST) Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQhyzm24792 for ; Fri, 21 Jan 2000 19:44:06 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA15901; Fri, 21 Jan 2000 14:44:05 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA07195; Fri, 21 Jan 2000 14:44:05 -0500 (EST) Message-Id: <200001211944.OAA07195@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: ewgray@lucent.com cc: mpls@UU.NET Subject: Re: Draft of revised charter In-reply-to: Your message of "Fri, 21 Jan 2000 14:37:59 EST." <3888B597.ECB9865E@lucent.com> Date: Fri, 21 Jan 2000 14:44:05 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Eric - > You would be in a position to know, but I was under the > impression that RSVP-Tunnels pretty much covers the bases > for RSVP-MPLS once you realize that the messages do not > have to carry an explicit route object. I thought this > point had been made once or twice already. This is pretty much the case for unicast traffic. Most of the technical guts of the RSVP draft was moved to the tunnels draft since the former was hung up on some multicast issues. There are a few issues that should be addressed for the unicast case. WF comes to mind. I'm not sure if there are others. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jan 21 15:09:48 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16565 for ; Fri, 21 Jan 2000 15:09:47 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzo14865; Fri, 21 Jan 2000 20:08:24 GMT Received: by mail-control.mail.uu.net id QQhyzo14903 for mpls-outgoing; Fri, 21 Jan 2000 20:08:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyzo14886 for ; Fri, 21 Jan 2000 20:08:02 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyzo22365 for ; Fri, 21 Jan 2000 15:08:01 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhyzo14520 for ; Fri, 21 Jan 2000 20:08:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jan 21 15:07:26 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.41.150]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA01341; Fri, 21 Jan 2000 15:07:19 -0500 (EST) Message-ID: <3888BD87.F4EE7A15@lucent.com> Date: Fri, 21 Jan 2000 15:11:51 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: mpls@UU.NET Subject: Re: Draft of revised charter References: <200001211944.OAA07195@lir.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, Ah! Thanks for the clarification. Then we can expect the next version of MPLS-RSVP to have solved the issues with multicast label switching with QoS, as well as some unresolved unicast issues? :-) You wrote: > > Eric - > > > You would be in a position to know, but I was under the > > impression that RSVP-Tunnels pretty much covers the bases > > for RSVP-MPLS once you realize that the messages do not > > have to carry an explicit route object. I thought this > > point had been made once or twice already. > > This is pretty much the case for unicast traffic. Most of the > technical guts of the RSVP draft was moved to the tunnels draft since > the former was hung up on some multicast issues. > > There are a few issues that should be addressed for the unicast case. > WF comes to mind. I'm not sure if there are others. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jan 21 15:11:16 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16612 for ; Fri, 21 Jan 2000 15:11:16 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzo12602; Fri, 21 Jan 2000 20:04:54 GMT Received: by mail-control.mail.uu.net id QQhyzo12504 for mpls-outgoing; Fri, 21 Jan 2000 20:04:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyzo12481 for ; Fri, 21 Jan 2000 20:04:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhyzo21876 for ; Fri, 21 Jan 2000 15:04:05 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhyzo06886 for ; Fri, 21 Jan 2000 20:04:05 GMT Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id MAA16668; Fri, 21 Jan 2000 12:04:01 -0800 (PST) Message-Id: <4.2.2.20000121145518.00b22d00@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 15:02:05 -0500 To: ewgray@lucent.com From: Chip Sharp Subject: Re: Draft of revised charter Cc: "Andrew G. Malis" , George Swallow , mpls@UU.NET In-Reply-To: <3888B268.208303C5@lucent.com> References: <200001192027.PAA29242@lir.cisco.com> <4.2.2.20000121135533.00a49180@dogwood.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I was referring to any work concerning MPLS that might be initiated in ITU, whether in SG13, SG11 or SG7. For example, if the ITU initiates work in the optical area and decides to use MPLS, I hope they will liaise with IETF. Chip At 02:24 PM 1/21/00 -0500, Eric Gray wrote: >Chip, > > This may be a bit of a stretch. I.ipatm does >not attempt to define how MPLS works, nor does it try >to define a new way to do what MPLS does. > > Asking one organization to liaise with another >before selecting a protocol to use for its purposes is >a little like asking a carpenter to liaise with a tool >manufacturer before selecting a hammer. > >You wrote: > > > > At 01:46 PM 1/21/00 -0500, Andrew G. Malis wrote: > > >... > > > > > > > > >On a different charter topic, I think the charter should specifically > > >mention that the WG plans to liaise with other standards bodies, > > >especially in the optical area, such as OIF, ITU-T, ANSI, ODSI, > > >etc.. This would prevent unnecessary duplication of effort, have the IETF > > >output reviewed by other bodies that have the appropriate expertise, and > > >prevent unintended interactions with other existing and developing > > >standards. Optical is a new area for the IETF and it would be pure hubris > > >for us to work in a vacuum, or just assume that the necessary interactions > > >will take place automatically. > > > > I believe that ITU-T should also liaise to IETF mpls before embarking on > > new adventures in MPLS. > > :-) > > > > BTW, ITU has assigned a number to I.ipatm: Y.1310 > > It is scheduled for approval in March. > > Chip > > > > >Thanks, > > >Andy > > > > > > > Support NetAid! http://www.netaid.org > > -------------------------------------------------- > > Chip Sharp Consulting Engineering > > Cisco Systems Telco Bio-region > > Reality - Love it or Leave it. > > -------------------------------------------------- Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-mpls@UU.NET Fri Jan 21 20:29:40 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19909 for ; Fri, 21 Jan 2000 20:29:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzaj01766; Sat, 22 Jan 2000 01:26:07 GMT Received: by mail-control.mail.uu.net id QQhzaj15379 for mpls-outgoing; Sat, 22 Jan 2000 01:25:44 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzaj15374 for ; Sat, 22 Jan 2000 01:25:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzaj23776 for ; Fri, 21 Jan 2000 20:25:33 -0500 (EST) Received: from turin.trillium.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: turin.trillium.com [206.216.108.218]) id QQhzaj09065 for ; Sat, 22 Jan 2000 01:25:32 GMT Received: from aiglos.trillium.com (unverified) by turin.trillium.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Fri, 21 Jan 2000 17:30:40 -0800 Received: from drogo.trillium.com.trillium.com (drogo [198.242.58.34]) by aiglos.trillium.com (8.9.3/8.9.3) with SMTP id RAA11065; Fri, 21 Jan 2000 17:25:25 -0800 (PST) Received: by drogo.trillium.com.trillium.com (SMI-8.6/SMI-SVR4) id RAA01254; Fri, 21 Jan 2000 17:29:07 -0800 Date: Fri, 21 Jan 2000 17:29:07 -0800 From: prem@trillium.com (Prem Shankar Sharma) Message-Id: <200001220129.RAA01254@drogo.trillium.com.trillium.com> To: mpls@UU.NET Subject: label map procedures Cc: prem@trillium.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: nI7HuswUfilIIxRf2LmqWA== Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, There seems to be some confusion around steps LMp.4 and LMp.5 in label map procedures in ldp specs. My interpretation was that the LSR was receiving many label maps for the same label request. The first label map is received and the label is made use of. The subsequent labels maps are just to inform/update the LSR abt. the change in the attributes for the lsp. BUT THE ONLY THING GOING AGAINST THAT WAS : How would LSR determine whether it is an update of the already issued (and satisfied) label request when LSR has already deleted the record of the outstanding label request as per LMp2? IF we had somehow maintained that record (or some other minimal info.) and would have used the msgId (or some other means) of the label req. msg. in the subsequent label maps, things would have solved. [If message id is used, then the same couldn't be re-used till that LSP goes away.] The current description of the label map, I feel, could not support the operation of non-merging LSRs. If the LMp 5. is considered in the context of the LSP than it could make sense. Even then it would require that the label request record or some minimal info. is maintained. Would like to hear your thoughts in this regard. Please let me know, if I missed something. Regards. Prem From owner-mpls@UU.NET Sat Jan 22 01:26:10 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25650 for ; Sat, 22 Jan 2000 01:26:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzbd26546; Sat, 22 Jan 2000 06:25:56 GMT Received: by mail-control.mail.uu.net id QQhzbd07920 for mpls-outgoing; Sat, 22 Jan 2000 06:25:40 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzbd07914 for ; Sat, 22 Jan 2000 06:25:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzbd01992 for ; Sat, 22 Jan 2000 01:25:28 -0500 (EST) Received: from 21cn.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [202.104.32.241]) id QQhzbd03696 for ; Sat, 22 Jan 2000 06:25:21 GMT Received: from 21cn.com([10.1.0.101]) by 21cn.com(JetMail 2.3.2.1) with SMTP id /aimcque/jmail.rcv/9/jm14388975e1; Sat, 22 Jan 2000 06:25:29 -0000 Received: from wodc7-1.corprelay.mail.uu.net([192.48.96.68]) by 21cn.com(JetMail 2.3.2.1) with SMTP id /aimcque/jmail.rcv/2/jm83889270c; Fri, 21 Jan 2000 20:09:42 -0000 Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhyzo14989; Fri, 21 Jan 2000 20:08:30 GMT Received: by mail-control.mail.uu.net id QQhyzo14903 for mpls-outgoing; Fri, 21 Jan 2000 20:08:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhyzo14886 for ; Fri, 21 Jan 2000 20:08:02 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhyzo22365 for ; Fri, 21 Jan 2000 15:08:01 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhyzo14520 for ; Fri, 21 Jan 2000 20:08:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jan 21 15:07:26 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.41.150]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA01341; Fri, 21 Jan 2000 15:07:19 -0500 (EST) Message-ID: <3888BD87.F4EE7A15@lucent.com> Date: Fri, 21 Jan 2000 15:11:51 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: mpls@UU.NET Subject: Re: Draft of revised charter References: <200001211944.OAA07195@lir.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, Ah! Thanks for the clarification. Then we can expect the next version of MPLS-RSVP to have solved the issues with multicast label switching with QoS, as well as some unresolved unicast issues? :-) You wrote: > > Eric - > > > You would be in a position to know, but I was under the > > impression that RSVP-Tunnels pretty much covers the bases > > for RSVP-MPLS once you realize that the messages do not > > have to carry an explicit route object. I thought this > > point had been made once or twice already. > > This is pretty much the case for unicast traffic. Most of the > technical guts of the RSVP draft was moved to the tunnels draft since > the former was hung up on some multicast issues. > > There are a few issues that should be addressed for the unicast case. > WF comes to mind. I'm not sure if there are others. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Sat Jan 22 08:44:53 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08447 for ; Sat, 22 Jan 2000 08:44:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzcg28491; Sat, 22 Jan 2000 13:44:39 GMT Received: by mail-control.mail.uu.net id QQhzcg22401 for mpls-outgoing; Sat, 22 Jan 2000 13:44:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzcg22396 for ; Sat, 22 Jan 2000 13:44:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzcg24895 for ; Sat, 22 Jan 2000 08:44:03 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhzcg28070 for ; Sat, 22 Jan 2000 13:44:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Sat Jan 22 08:42:41 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.43.156]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id IAA10282; Sat, 22 Jan 2000 08:42:28 -0500 (EST) Message-ID: <3889B4D5.45A65D5B@lucent.com> Date: Sat, 22 Jan 2000 08:47:01 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Prem Shankar Sharma CC: mpls@UU.NET Subject: Re: label map procedures References: <200001220129.RAA01254@drogo.trillium.com.trillium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Prem, We have been looking at this. Using the Message ID would work, but is not necessary. Worse than that, implementations are out there that already assume they can re-use the Message ID once the Label Request and Label Mapping transaction is complete. If we adopt a suggestion to use Message ID, we break implementations that are compliant with the current LDP specification. Since the current LDP specification is beyond last call, this is not a very good idea. To determine if a Label Mapping is an update of parameters received previously, simply look at the LABEL. If you've already been assigned this LABEL, then the Label Mapping is an update. It really is that simple. An LSR that attempts to re-use a LABEL for some other purpose (a different FEC, for example) without having sent a Label Withdraw and received a corresponding Label Release is in blatant violation of the protocol. Period. Note that you do not get to LMp.4 and LMp.5 unless you've detected a loop. If you've detected a loop, then some one or more of the parameters must have changed. The current issue with the entire LMp section is that it does not effectively support the case where more than one Label Request is outstanding at a time. Several of us (within Lucent) have been in touch with the members of the LDP design team and we are trying to work out a minimal delta to the specification to allow for this support. Support for multiple outstanding Label Requests MUST be provided in order to support non-merging LSRs. This support is absolutely required in a first version of LDP. Hopefully, we can count on the LDP design team to work with us a little more closely in trying to resolve this issue. Thanks! -- Eric Gray You wrote: > > Hi All, > > There seems to be some confusion around steps LMp.4 and LMp.5 in > label map procedures in ldp specs. > > My interpretation was that the LSR was receiving many label maps for > the same label request. The first label map is received and the label > is made use of. The subsequent labels maps are just to inform/update the > LSR abt. the change in the attributes for the lsp. BUT THE ONLY THING > GOING AGAINST THAT WAS : How would LSR determine whether it is an > update of the already issued (and satisfied) label request when LSR > has already deleted the record of the outstanding label request as per > LMp2? IF we had somehow maintained that record (or some other minimal > info.) and would have used the msgId (or some other means) of the label > req. msg. in the subsequent label maps, things would have solved. > [If message id is used, then the same couldn't be re-used till that > LSP goes away.] > > The current description of the label map, I feel, could not support the > operation of non-merging LSRs. > > If the LMp 5. is considered in the context of the LSP than it could make > sense. Even then it would require that the label request record or > some minimal info. is maintained. > > Would like to hear your thoughts in this regard. > > Please let me know, if I missed something. > > Regards. > Prem From owner-mpls@UU.NET Sat Jan 22 16:18:10 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11388 for ; Sat, 22 Jan 2000 16:18:09 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzdl01715; Sat, 22 Jan 2000 21:17:53 GMT Received: by mail-control.mail.uu.net id QQhzdl14741 for mpls-outgoing; Sat, 22 Jan 2000 21:17:27 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzdl14736 for ; Sat, 22 Jan 2000 21:17:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzdl19031 for ; Sat, 22 Jan 2000 16:17:20 -0500 (EST) Received: from mail.disney.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.disney.com [204.128.192.15]) id QQhzdl18926 for ; Sat, 22 Jan 2000 21:17:20 GMT Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (8.9.1/8.9.1) with SMTP id NAA28872 for ; Sat, 22 Jan 2000 13:17:41 -0800 (PST) Received: from 1crp232.corp.disney.com by pain.corp.disney.com with ESMTP for mpls@UU.NET; Sat, 22 Jan 2000 13:17:25 -0800 Received: by 1crp232.corp.disney.com with Internet Mail Service (5.5.2448.0) id ; Sat, 22 Jan 2000 13:17:18 -0800 Message-Id: From: "Holmes, David A." To: mpls@UU.NET Subject: MPLS Traffic Engineering in the Enterprise Date: Sat, 22 Jan 2000 13:17:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I am new to this mail group. I have been following the literature. Can anyone tell me if the MPLS traffic engineering control plane is envisioned to extend to user Ethernet switches in the Enterprise? My concern is controlling jitter in end-to-end real time applications such as h.323 videoconferencing. Such connections would be as follows: Enterprise ----> MPLS Provisioned Internet ---> Enterprise From owner-mpls@UU.NET Sat Jan 22 17:28:29 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11876 for ; Sat, 22 Jan 2000 17:28:29 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzdp21286; Sat, 22 Jan 2000 22:28:18 GMT Received: by mail-control.mail.uu.net id QQhzdp25686 for mpls-outgoing; Sat, 22 Jan 2000 22:28:02 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzdp25678 for ; Sat, 22 Jan 2000 22:27:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzdp04689; Sat, 22 Jan 2000 17:27:29 -0500 (EST) From: sentthis@bigvalue.zzn.com Received: from server by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: edm-ab3-16.netcom.ca [207.181.70.144]) id QQhzdp03528; Sat, 22 Jan 2000 22:27:26 GMT Message-Id: To: Subject: ADV: IMPROVE YOUR DOGS HEALTH IN JUST 8 DAYS!!! Date: Sat, 22 Jan 2000 12:02:34 Sender: owner-mpls@UU.NET Precedence: bulk You have been carefully selected to receive the following as a person interested in opportunities based upon your previous Internet postings or visits to one of our affiliate web sites. If you have received this message in error, please accept our apology as a responsible e-mailer. However, this is a ONE-TIME only announcement and is not intended as a SPAM letter, therefore you need not reply. You are automatically moved to our remove list. Also as a free service to you for having taken your time we have sent your e-mail address to 6 other remove lists to help ensure that you are not bothered again by e-mail that you find annoying again Once again, if you are not interested in the following e-mail, we sincerely apologize for the inconvenience. Thank you. Doesn't your dog deserve to feel his best everyday? Whether just a pup or an old veteran all dogs deserve a fighting chance to feel there best each and every day. If you are interested in changing your dogs health for the rest of your dogs life then please proceed to any of the links below or e-mail us at pets@bigvalue.zzn.com http://myk9s.tripod.com/ http://www.fortunecity.com/business/handcrafts/1131/ This message is sent in compliance of the new e-mail bill:SECTION 301.Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email has already been stopped at no cost to you. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident or otherwise wish to be removed from this list, further transmissions to you by the sender of this email has already been stopped at no cost to you. From owner-mpls@UU.NET Sun Jan 23 02:03:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23904 for ; Sun, 23 Jan 2000 02:03:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzey26485; Sun, 23 Jan 2000 07:03:40 GMT Received: by mail-control.mail.uu.net id QQhzey24952 for mpls-outgoing; Sun, 23 Jan 2000 07:03:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzey24943 for ; Sun, 23 Jan 2000 07:03:05 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzey19900; Sun, 23 Jan 2000 02:02:34 -0500 (EST) From: grantworld@mailcty.com Received: from mail01.homewknow.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: 98AC9243.ipt.aol.com [152.172.146.67]) id QQhzey25569; Sun, 23 Jan 2000 07:02:20 GMT Subject: Free Cash Grants, Never Repay! Up To $50,000 Date: Sat, 22 Jan 2000 19:00:00 Message-Id: <538.634402.228425@mail01.homewknow.com> To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk FREE CASH GRANTS, NEVER REPAY! You Can Get The Money You Need... To Start Your Home Business... To Consolidate Your Debt... To Go To college... To Start Your Home Business... Almost ANY Worthwhile Reason... Why? Foundations all over the United States GIVE away Millions of Dollars of CASH GRANTS every year. They must give this MONEY away, in order to maintain their tax free status. Who Can Apply? ANYONE can apply for a Grant from 18 years old and up! We Can Help! We will show you HOW & WHERE to get Grants. This MONEY has to be given away, WHY not to YOU? Grants from $500.00 to $50,000.00 are possible! GRANTS don't have to be paid back! Grants can be ideal for people who are or were bankrupt or just have bad credit. The Good News! DON'T pay $79.00 to $129.00 for this information and list. We Will Show You How To Apply For Your Grants, Where To Apply, And Exactly What To Say. We Help You Do It All For Just $29.95 . If You Pay With Credit Card, All Information Will Be Sent To Your Email Address Within 24 to 48 Hours! We Gladly Accept Credit Cards & Checks Via Web and Postal Mail: American Express Master Card Visa Don't Delay, This Is A Limited Time Offer At This Amazing Low Price! Get That Grant Before College Rush Time Coming Up! Interested, Please Visit Our Website Below And Place Your Order! ********** http://www.geocities.com/WallStreet/Brokerage/4482/ ********** To Order by postal mail, please send $29.95 Plus $2.00 S & H to the below address. Make payable to Grant Gold 2000. Grant Gold 2000 4196 Wenz Ct. Suite C Dayton, Ohio 45405 ********** From owner-mpls@UU.NET Sun Jan 23 21:44:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13979 for ; Sun, 23 Jan 2000 21:44:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzhy18397; Mon, 24 Jan 2000 02:42:22 GMT Received: by mail-control.mail.uu.net id QQhzhy20058 for mpls-outgoing; Mon, 24 Jan 2000 02:41:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzhy20049 for ; Mon, 24 Jan 2000 02:41:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzhy27504 for ; Sun, 23 Jan 2000 21:41:36 -0500 (EST) Received: from neopolis.t.u-tokyo.ac.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neopolis.t.u-tokyo.ac.jp [133.11.64.198]) id QQhzhy02446 for ; Mon, 24 Jan 2000 02:41:34 GMT Received: from sekipolis ([133.11.65.174]) by neopolis.t.u-tokyo.ac.jp (8.9.3/3.7W-01/12/00) with SMTP id LAA13297 for ; Mon, 24 Jan 2000 11:36:13 +0900 (JST) Message-ID: <00a001bf661d$76700200$ae410b85@t.utokyo.ac.jp> From: "Sheng-hung Shih" To: Subject: MPLS and Optical network!! Date: Mon, 24 Jan 2000 11:45:31 +0800 Organization: The University of Tokyo MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.3825.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all: I'm a master student and a rookie in the MPLS related field.I'm doing some research about MPLS and optical network.As the draft presented,MPLS can be combined with OXCs.But how can optical trails be labeled?And if we want to do explicit routing,how can we do push and pop toward the optical data trail? Thank you very much!! From owner-mpls@UU.NET Sun Jan 23 22:30:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14658 for ; Sun, 23 Jan 2000 22:30:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzib27181; Mon, 24 Jan 2000 03:29:43 GMT Received: by mail-control.mail.uu.net id QQhzib00101 for mpls-outgoing; Mon, 24 Jan 2000 03:29:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzib00094 for ; Mon, 24 Jan 2000 03:29:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzib00590 for ; Sun, 23 Jan 2000 22:29:00 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQhzib26717 for ; Mon, 24 Jan 2000 03:29:00 GMT Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Sun, 23 Jan 2000 21:27:59 -0600 Received: from zcard008.ca.nortel.com ([47.127.82.62]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DLZ5QBGR; Sun, 23 Jan 2000 22:27:52 -0500 Received: from nortelnetworks.com (CR306449-A [47.199.34.121]) by zcard008.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CS04XAKN; Sun, 23 Jan 2000 22:27:52 -0500 Message-ID: <388BC3FC.F59E94B4@nortelnetworks.com> Date: Sun, 23 Jan 2000 22:16:12 -0500 From: "Cheng-Yin Lee" X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,zh-CN,zh,zh-TW,af MIME-Version: 1.0 To: swallow@cisco.com CC: ewgray@lucent.com, mpls@UU.NET Subject: Re: Draft of revised charter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George Swallow wrote: > > You would be in a position to know, but I was under the > > impression that RSVP-Tunnels pretty much covers the bases > > for RSVP-MPLS once you realize that the messages do not > > have to carry an explicit route object. I thought this > > point had been made once or twice already. > > This is pretty much the case for unicast traffic. Most of the > technical guts of the RSVP draft was moved to the tunnels draft since > the former was hung up on some multicast issues. May i know what are these multicast issues? thanks, cyl From owner-mpls@UU.NET Sun Jan 23 23:15:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15757 for ; Sun, 23 Jan 2000 23:15:03 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzie19993; Mon, 24 Jan 2000 04:14:24 GMT Received: by mail-control.mail.uu.net id QQhzie10220 for mpls-outgoing; Mon, 24 Jan 2000 04:13:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzie10212 for ; Mon, 24 Jan 2000 04:13:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzie03651 for ; Sun, 23 Jan 2000 23:13:28 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhzie02766 for ; Mon, 24 Jan 2000 04:13:28 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp139-254.cisco.com [144.254.139.254]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id UAA28216; Sun, 23 Jan 2000 20:12:22 -0800 (PST) Message-Id: <4.2.2.20000124145740.00a9ec80@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 15:12:06 +1100 To: "Sheng-hung Shih" From: Jeremy Lawrence Subject: Re: MPLS and Optical network!! Cc: In-Reply-To: <00a001bf661d$76700200$ae410b85@t.utokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Sheng-Hung, At 11:45 01/24/2000 +0800, Sheng-hung Shih wrote: >Hi all: > I'm a master student and a rookie in the MPLS related field.I'm doing >some research about MPLS and optical network.As the draft presented,MPLS can >be combined with OXCs.But how can optical trails be labeled? On an ATM network, each link supports many different virtual circuits, and ATM MPLS treats each VCI on a link as a distinct label. Similarly, in an OXC network, each link supports many lightpaths, and MPLS (as proposed for OXCs) treats each lightpath wavelength on a link as a distinct label. >And if we want >to do explicit routing,how can we do push and pop toward the optical data >trail? In ATM MPLS network, the top-level label on a packet is applied by sending the packet on a virtual circuit with a chosen VCI. Similarly, in optical MPLS, the top-level label will be applied to a packet by sending it on a lightpath with a chosen wavelength. Hope this helps, Jeremy Lawrence From owner-mpls@UU.NET Mon Jan 24 00:11:03 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16437 for ; Mon, 24 Jan 2000 00:11:03 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzii18251; Mon, 24 Jan 2000 05:10:31 GMT Received: by mail-control.mail.uu.net id QQhzii20221 for mpls-outgoing; Mon, 24 Jan 2000 05:09:51 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzii20214 for ; Mon, 24 Jan 2000 05:09:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzii22447 for ; Mon, 24 Jan 2000 00:09:17 -0500 (EST) Received: from neopolis.t.u-tokyo.ac.jp by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neopolis.t.u-tokyo.ac.jp [133.11.64.198]) id QQhzii28650 for ; Mon, 24 Jan 2000 05:09:16 GMT Received: from sekipolis ([133.11.65.174]) by neopolis.t.u-tokyo.ac.jp (8.9.3/3.7W-01/12/00) with SMTP id OAA15015; Mon, 24 Jan 2000 14:03:33 +0900 (JST) Message-ID: <00e301bf6632$0c8676c0$ae410b85@t.utokyo.ac.jp> From: "Sheng-hung Shih" To: "Jeremy Lawrence" Cc: References: <4.2.2.20000124145740.00a9ec80@farley.cisco.com> Subject: Re: MPLS and Optical network!! Date: Mon, 24 Jan 2000 14:12:52 +0800 Organization: The University of Tokyo MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.3825.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > In ATM MPLS network, the top-level label on a packet is applied by > sending the packet on a virtual circuit with a chosen VCI. Similarly, > in optical MPLS, the top-level label will be applied to a packet by > sending it on a lightpath with a chosen wavelength. It seems like the hop-by-hop routing,isn't it?And the number of wavelength is also a problem. Sheng-hung Shih From owner-mpls@UU.NET Mon Jan 24 01:21:27 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18133 for ; Mon, 24 Jan 2000 01:21:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzin02183; Mon, 24 Jan 2000 06:18:54 GMT Received: by mail-control.mail.uu.net id QQhzin01449 for mpls-outgoing; Mon, 24 Jan 2000 06:18:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzin01444 for ; Mon, 24 Jan 2000 06:18:30 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzin26517 for ; Mon, 24 Jan 2000 01:17:53 -0500 (EST) Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhzin19777 for ; Mon, 24 Jan 2000 06:17:52 GMT Received: from jlawrenc-pc.cisco.com (oz-syd-dhcp139-254.cisco.com [144.254.139.254]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id WAA10648; Sun, 23 Jan 2000 22:17:03 -0800 (PST) Message-Id: <4.2.2.20000124171215.00aaf410@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 17:16:41 +1100 To: "Sheng-hung Shih" From: Jeremy Lawrence Subject: Re: MPLS and Optical network!! Cc: In-Reply-To: <00e301bf6632$0c8676c0$ae410b85@t.utokyo.ac.jp> References: <4.2.2.20000124145740.00a9ec80@farley.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 14:12 01/24/2000 +0800, Sheng-hung Shih wrote: > > In ATM MPLS network, the top-level label on a packet is applied by > > sending the packet on a virtual circuit with a chosen VCI. Similarly, > > in optical MPLS, the top-level label will be applied to a packet by > > sending it on a lightpath with a chosen wavelength. > It seems like the hop-by-hop routing,isn't it? The intended use of optical MPLS is not hop-by-hop routed MPLS, but explicitly routed MPLS. >And the number of >wavelength is also a problem. Well, 80 wavelengths is enough for one router to connect to 80 others across an OXC network (subject to a valid route being available for each lightpath), so this isn't too much of a problem. There are rumours of OXCs coming which support 1000+ wavelengths. Regards, Jeremy Lawrence From owner-mpls@UU.NET Mon Jan 24 02:19:06 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28647 for ; Mon, 24 Jan 2000 02:19:05 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzir18324; Mon, 24 Jan 2000 07:18:35 GMT Received: by mail-control.mail.uu.net id QQhzir11803 for mpls-outgoing; Mon, 24 Jan 2000 07:18:12 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzir11798 for ; Mon, 24 Jan 2000 07:18:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzir15072 for ; Mon, 24 Jan 2000 02:18:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQhzir17956 for ; Mon, 24 Jan 2000 07:18:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Jan 24 02:16:15 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.42.53]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id CAA25431; Mon, 24 Jan 2000 02:16:06 -0500 (EST) Message-ID: <388BFD40.59EA28CD@lucent.com> Date: Mon, 24 Jan 2000 02:20:32 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Cheng-Yin Lee CC: swallow@cisco.com, mpls@UU.NET Subject: Re: Draft of revised charter References: <388BC3FC.F59E94B4@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Cheng-Yin Lee wrote: > > George Swallow wrote: > > > You would be in a position to know, but I was under the > > > impression that RSVP-Tunnels pretty much covers the bases > > > for RSVP-MPLS once you realize that the messages do not > > > have to carry an explicit route object. I thought this > > > point had been made once or twice already. > > > > This is pretty much the case for unicast traffic. Most of the > > technical guts of the RSVP draft was moved to the tunnels draft since > > the former was hung up on some multicast issues. > May i know what are these multicast issues? > > thanks, > cyl Multicast issues in MPLS are manifold (and they just keep multiplying). Looping is a major problem in multicast in general, but it is much worse if using a technology which is not suited to TTL manipulation. Some hardware wants to use specific VCI numbers for each output interface when replicating data. How to reconcile this with Downstream Allocation is a small problem. There have been multiple proposals and one of the people who had been pursuing multicast issues in the past has joined a startup and may not have the time to pursue it further. And that's just the economical, political and one of the technical issues. Anyone who wants to, please feel free to chime in with additional technical, and other issues... -- Eric Gray From owner-mpls@UU.NET Mon Jan 24 04:34:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00321 for ; Mon, 24 Jan 2000 04:34:49 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzja22953; Mon, 24 Jan 2000 09:33:45 GMT Received: by mail-control.mail.uu.net id QQhzja03412 for mpls-outgoing; Mon, 24 Jan 2000 09:33:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzja03401 for ; Mon, 24 Jan 2000 09:33:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzja25321 for ; Mon, 24 Jan 2000 04:33:08 -0500 (EST) Received: from pop05.iname.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pop05.iname.net [165.251.8.70]) id QQhzja22498 for ; Mon, 24 Jan 2000 09:33:08 GMT Received: from kp (athei36-a122.otenet.gr [195.167.109.122]) by pop05.iname.net (8.9.3/8.9.3) with SMTP id EAA21599 for ; Mon, 24 Jan 2000 04:33:01 -0500 (EST) Message-ID: <002301bf664e$03f60400$38fea8c0@kp> Reply-To: "Constantine Protopapas" From: "Constantine Protopapas" To: Subject: IP vs ATM Date: Mon, 24 Jan 2000 11:33:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Disposition-Notification-To: "Constantine Protopapas" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am writing a study comparing IP vs. ATM for QoS-enabled backbones. My question concerns the bandwidth requirements of these 2 technologies. ATM's minimum (in the sence that it can function as it is designed) bandwidth is OC-3 (155 Mbps). However, it can also function at lower speeds (i know a case where it is implemented over E1 links). What are the bandwidth requirments of IP (and especially when MPLS is implemented) in order to assure QoS over time-sensitive applications (i am especially interested in voice). Constantine Protopapas Systems/Network Engineer Applied Science 62 Karpenisioti Str. GR 115 24 N. Filothei Athens GREECE tel: ++30-1-6998225 (office) ++30-1-6801391 (home) fax: ++30-1-6998983 mobile: ++30-97-7598043 e-mail: applied@otenet.gr (office) wiztech@hol.gr (home) From owner-mpls@UU.NET Mon Jan 24 07:28:44 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02847 for ; Mon, 24 Jan 2000 07:28:43 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzjl14618; Mon, 24 Jan 2000 12:28:03 GMT Received: by mail-control.mail.uu.net id QQhzjl05846 for mpls-outgoing; Mon, 24 Jan 2000 12:27:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzjl05838 for ; Mon, 24 Jan 2000 12:27:36 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzjl14855 for ; Mon, 24 Jan 2000 07:27:24 -0500 (EST) From: int877656545@888.nu Received: from 198.31.26.77 by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: 10-077.012.popsite.net [198.31.26.77]) id QQhzjl03067 for ; Mon, 24 Jan 2000 12:27:22 GMT Date: Mon, 24 Jan 2000 12:27:22 GMT Message-Id: Subject: att. pres./foreign sales/from Jose Carr/from Helen Astor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can you use a good distributor in South America? (So sorry if you already replied back to us, please reply again. Our computer malfunctioned). Jose Carr Helen Astor Only reply back to these email addresses below or your message will not reach us in our office. jose4@canoemail.com josecarr@mail.kmsp.com jose722@angelfire.com Or fax us at 5305098416 (U.S. fax number that we will get electronicaly ) include your email address and contact person please. From owner-mpls@UU.NET Mon Jan 24 09:49:56 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08935 for ; Mon, 24 Jan 2000 09:49:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzjv04551; Mon, 24 Jan 2000 14:48:13 GMT Received: by mail-control.mail.uu.net id QQhzjv28618 for mpls-outgoing; Mon, 24 Jan 2000 14:47:44 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzjv28613 for ; Mon, 24 Jan 2000 14:47:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzjv14499 for ; Mon, 24 Jan 2000 09:47:30 -0500 (EST) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQhzjv14458 for ; Mon, 24 Jan 2000 14:47: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 JAA08830; Mon, 24 Jan 2000 09:47:25 -0500 (EST) Message-Id: <200001241447.JAA08830@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: mpls@UU.NET From: The IESG Subject: Protocol Action: The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol to Proposed Standard Date: Mon, 24 Jan 2000 09:47:25 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol' as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are David Oran and Rob Coltun. Technical Summary This document specifies the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. This specification provides an indispensable framework for the implementation of long-lived session and QoS-sensitive session transfers over ATM. The assignment specified in this document is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol. However, the purpose of this specification is not limited to this support, and it should also be applicable to other purposes. Working Group Summary The working group supported this document and no issues were raised during IETF Last-Call Protocol Quality Rob Coltun has reviewed the spec for the IESG. There are currently no implementations of this spec. NTT lab. is planning implementing the git-uus protocol in the next version of our ATM SW. They are waiting IETF/ITU-T approvement and determination of the drafts. FORE is planning to implement MPLS/RSVP using git. From owner-mpls@UU.NET Mon Jan 24 16:46:35 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25970 for ; Mon, 24 Jan 2000 16:46:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzku28919; Mon, 24 Jan 2000 21:06:25 GMT Received: by mail-control.mail.uu.net id QQhzku12580 for mpls-outgoing; Mon, 24 Jan 2000 21:05:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzku12549 for ; Mon, 24 Jan 2000 21:05:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzku20979; Mon, 24 Jan 2000 16:05:35 -0500 (EST) Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQhzku11065; Mon, 24 Jan 2000 21:05:34 GMT Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.10) id ; Mon, 24 Jan 2000 16:05:34 -0500 Message-ID: <496A8683261CD211BF6C0008C733261A48CDF9@email.quarrytech.com> From: "Abes, Andi" To: MPLS mailing list Cc: lberger@labn.net, awduche@UU.NET, dhg@juniper.net, tony1@home.net, vijay@torrentnet.com, swallow@cisco.com Subject: FW: LSP hierarchies using RSVP Date: Mon, 24 Jan 2000 16:05:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, As the authors of the RSVP extensions draft, I would appreciate your comments on this mail, which was sent to the mailing list, but generated no responses. Do you agree with the statements made ? Do these assumptions fall with-in the use you intended for the extensions ? Do you think that incorporating some of this in the draft might make life easier on somebody that is attempting to use RSVP as a way to setup tunnels ?? If I'm completely off tack, please let me know. TIA for any comments, Andi. -----Original Message----- From: Abes, Andi [mailto:aabes@quarrytech.com] Sent: Tuesday, January 18, 2000 6:08 PM To: MPLS mailing list Subject: LSP hierarchies using RSVP Ok, I've been trying to figure out how to use / setup Label hierarchies using RSVP, and in a joint effort (with Rohit), reached the following 2 possibilities, each having its merits. My problem though is that both these approaches are not documented in the drafts in a straight to the point way. I'd be happy to hear opinions. Opaque tunnels In this mode, an pre-existing LSP (that might have been signaled using RSVP), is used to transparently connect 2 RSVP speakers. The routers that construct the tunnel (the "core" routers) are unaware of any higher level labels exchanged across it. This has the following properties: The state the needs to be maintained in the "core" routers does not include the "edge" reservations. Only the ingress of the tunnel is responsible to perform admission control through for the tunnel. A network topology as depicted below, will not allow router "w" to create a reservation towards "y" that utilizes the tunnel (marked with "="), since router "B" can not perform admission control to the tunnel. +--+ +--+ +--+ +--+ +--+ |x |-----|A |=====|B |====|C |----|y | +--+ +--+ +--+ +--+ +--+ | | | +--+ |w | +--+ This scenario will work as follows (assuming the tunnel is pre-established): Router "x" will issue a path message, that includes a label request. Route "A" will intercept this message, and send it towards router "y" on the existing LSP. The message is sent with no "router-alert" of any kind, and thus router "B" will not be aware of it's existence. Router "C" receives this message and intercepts it (since it intercepts all IP packets with protocol == RSVP). It then records the state, and forwards the request towards "y". "y" allocates a label, and sends a RESV message to "C" "C" realizes that the RESV message will be sent on an LSP, and thus allocates a 2 level label stack. The top label is the LSP label, the higher label indicates "y". The message is sent to "A" Router "B" is not aware of the RESV message be forward through him. "A" receives the RESV message, and reserves the resources. The RESV messages passed to "x" will only include 1 label. "Admission controlled" tunnels This type of a tunnel allows for correct operation in the scenario described above. Each router along the "core" network performs admission control, and thus any of them can merge additional paths onto the tunnel. The way it works: "x" sends a Path with a label request towards "y" "A" intercepts it. It adds on a "router-alert" label as the top label. "B" intercepts it, since it is flagged with the router alert. It associates the request with the reservation currently in place for the tunnel by examining the lower level label. It forwards the Path downstream, after updating the current Path state for the tunnel. "C" performs the same type of processing the "B" performed and then forwards the request to "y". "y" performs its own admission control and issues back a label. "C" assigns a 2 level label stack. The top label is the existing LSP's label. The higher label identifies "y". As the RESV message traverses the tunnel, each router will receive it, since it's destined to him. The message is updated with the top label used by that router for the existing LSP. "A" realizes his the egress of the tunnel, and only passes 1 label to "x". pros: This method allows a "egress targeted" tree to be built and maintained, while consuming only needed resources. Additional senders can join in the middle of the tunnel and cause an increase in reservation only in those parts of it where it's needed Cons: This scheme requires the "core" routers to maintain state for every "outer" tunnel that traverses them From owner-mpls@UU.NET Mon Jan 24 18:34:50 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29297 for ; Mon, 24 Jan 2000 18:34:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzle13858; Mon, 24 Jan 2000 23:32:58 GMT Received: by mail-control.mail.uu.net id QQhzle08261 for mpls-outgoing; Mon, 24 Jan 2000 23:32:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzle08256 for ; Mon, 24 Jan 2000 23:32:31 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzle01237 for ; Mon, 24 Jan 2000 18:32:22 -0500 (EST) Received: from min.ecn.purdue.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: min.ecn.purdue.edu [128.46.200.41]) id QQhzle28116 for ; Mon, 24 Jan 2000 23:32:22 GMT Received: from localhost (koo@localhost) by min.ecn.purdue.edu (8.9.3/8.9.3moyman) with ESMTP id SAA02131 for ; Mon, 24 Jan 2000 18:32:21 -0500 (EST) Date: Mon, 24 Jan 2000 18:32:21 -0500 (EST) From: "Simon G. M. Koo" To: mpls@UU.NET Subject: Simulation software Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am new to the MPLS group. I would like to know if there is any simulation software available to measure the performance of network running MPLS? I am currently working on routing decision and some control problems on networks running MPLS. Any pointer suggested? Thanks. Simon Koo From owner-mpls@UU.NET Tue Jan 25 08:52:42 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26021 for ; Tue, 25 Jan 2000 08:52:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhznj04141; Tue, 25 Jan 2000 13:50:42 GMT Received: by mail-control.mail.uu.net id QQhznj14893 for mpls-outgoing; Tue, 25 Jan 2000 13:50:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhznj14888 for ; Tue, 25 Jan 2000 13:50:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhznj07833 for ; Tue, 25 Jan 2000 08:49:55 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQhznj03247 for ; Tue, 25 Jan 2000 13:49:55 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Tue, 25 Jan 2000 07:49:13 -0600 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DKPQL5XR; Tue, 25 Jan 2000 08:49:09 -0500 Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D1J3J5ZC; Tue, 25 Jan 2000 08:49:06 -0500 Message-ID: <388DA99C.9236D2B0@americasm01.nt.com> Date: Tue, 25 Jan 2000 08:48:12 -0500 From: "Philip Matthews" Organization: Nortel Networks X-Mailer: Mozilla 4.08 [en] (X11; U; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Draft of revised charter References: <200001192027.PAA29242@lir.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit [Resend, as it seems that the original message did not make it to the list for some reason.] ---- I have a question about the proposed charter revision. Should the new charter contain some words about the division of work between the MPLS WG and the TE WG? At the Washington meeting, there were some drafts that were presented to both the MPLS and TE groups, while other drafts were presented to what I felt was the wrong group. Perhaps some words in the charter that state that certain areas of investigation are left to the TE WG would help at future meetings? - Philip Matthews Nortel Networks Ottawa, Ontario From owner-mpls@UU.NET Tue Jan 25 14:10:11 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06393 for ; Tue, 25 Jan 2000 14:10:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzoe28696; Tue, 25 Jan 2000 19:08:12 GMT Received: by mail-control.mail.uu.net id QQhzoe18840 for mpls-outgoing; Tue, 25 Jan 2000 19:07:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzoe18827 for ; Tue, 25 Jan 2000 19:07:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzoe13047 for ; Tue, 25 Jan 2000 14:07:35 -0500 (EST) Received: from seattle.3com.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: seattle.3com.com [129.213.128.97]) id QQhzoe20411 for ; Tue, 25 Jan 2000 19:07:35 GMT Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id LAA01366; Tue, 25 Jan 2000 11:07:29 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id LAA06686; Tue, 25 Jan 2000 11:07:29 -0800 (PST) Received: from oahu.nsd.3com.com (oahu.nsd.3com.com [129.213.48.11]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id LAA05069; Tue, 25 Jan 2000 11:07:28 -0800 (PST) From: Barani Subbiah Received: (from bsubbiah@localhost) by oahu.nsd.3com.com (8.8.2/8.8.5) id LAA06557; Tue, 25 Jan 2000 11:11:23 -0800 (PST) Date: Tue, 25 Jan 2000 11:11:23 -0800 (PST) Message-Id: <200001251911.LAA06557@oahu.nsd.3com.com> To: mpls@UU.NET, David.A.Holmes@disney.com Subject: Re: MPLS Traffic Engineering in the Enterprise Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: Jng749K+ENqrAbploCPZlA== Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Check the IEEE 802.1 P/Q standard which specifies QoS issues in Enterprise LAN. The solution could be that 802.1 P/Q -> MPLS -> 802.1 P/Q (QoS per Eth. frame) -> QoS per IP packet or LSP -> QoS per Eth frame. Barani. > From owner-mpls@UU.NET Sat Jan 22 13:18:57 2000 > Return-Path: > Received: from new-york.3com.com (new-york.nsd.3com.com [129.213.96.114]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id NAA02051 for ; Sat, 22 Jan 2000 13:18:57 -0800 (PST) > Received: from seattle.3com.com (seattle.3com.com [129.213.157.13]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id NAA28888 for ; Sat, 22 Jan 2000 13:18:56 -0800 (PST) > Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id NAA21670 for ; Sat, 22 Jan 2000 13:18:56 -0800 (PST) > Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzdl01825; Sat, 22 Jan 2000 21:17:57 GMT > Received: by mail-control.mail.uu.net id QQhzdl14741 for mpls-outgoing; Sat, 22 Jan 2000 21:17:27 GMT > Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzdl14736 for ; Sat, 22 Jan 2000 21:17:26 GMT > Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzdl19031 for ; Sat, 22 Jan 2000 16:17:20 -0500 (EST) > Received: from mail.disney.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.disney.com [204.128.192.15]) id QQhzdl18926 for ; Sat, 22 Jan 2000 21:17:20 GMT > Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (8.9.1/8.9.1) with SMTP id NAA28872 for ; Sat, 22 Jan 2000 13:17:41 -0800 (PST) > Received: from 1crp232.corp.disney.com by pain.corp.disney.com with ESMTP for mpls@UU.NET; Sat, 22 Jan 2000 13:17:25 -0800 > Received: by 1crp232.corp.disney.com with Internet Mail Service (5.5.2448.0) id ; Sat, 22 Jan 2000 13:17:18 -0800 > Message-Id: > From: "Holmes, David A." > To: mpls@UU.NET > Subject: MPLS Traffic Engineering in the Enterprise > Date: Sat, 22 Jan 2000 13:17:17 -0800 > X-Mailer: Internet Mail Service (5.5.2448.0) > Sender: owner-mpls@UU.NET > Precedence: bulk > Status: RO > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Content-MD5: yq+cBrupsxbo407h/MXT8g== > Content-Length: 406 > > > I am new to this mail group. I have been following the literature. Can > anyone tell me if the MPLS traffic engineering control plane is envisioned > to extend to user Ethernet switches in the Enterprise? My concern is > controlling jitter in end-to-end real time applications such as h.323 > videoconferencing. Such connections would be as follows: > > > Enterprise ----> MPLS Provisioned Internet ---> Enterprise > From owner-mpls@UU.NET Tue Jan 25 16:07:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07829 for ; Tue, 25 Jan 2000 16:07:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzom01960; Tue, 25 Jan 2000 21:05:22 GMT Received: by mail-control.mail.uu.net id QQhzom09011 for mpls-outgoing; Tue, 25 Jan 2000 21:05:00 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzom08891 for ; Tue, 25 Jan 2000 21:04:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzom11218 for ; Tue, 25 Jan 2000 16:04:36 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQhzom01308 for ; Tue, 25 Jan 2000 21:04:36 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Tue, 25 Jan 2000 15:03:19 -0600 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DKPQM6GF; Tue, 25 Jan 2000 16:03:08 -0500 Received: from americasm01.nt.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D1J3J75Z; Tue, 25 Jan 2000 16:03:08 -0500 Message-ID: <388E0F8C.EBB92D96@americasm01.nt.com> Date: Tue, 25 Jan 2000 16:03:08 -0500 From: "Cheng-Yin Lee" Organization: Nortel Networks X-Mailer: Mozilla 4.6C-CCK-MCD [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ewgray@lucent.com CC: swallow@cisco.com, mpls@UU.NET Subject: Re: Draft of revised charter References: <388BC3FC.F59E94B4@nortelnetworks.com> <388BFD40.59EA28CD@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > Cheng-Yin Lee wrote: > > > > George Swallow wrote: > > > This is pretty much the case for unicast traffic. Most of the > > > technical guts of the RSVP draft was moved to the tunnels draft since > > > the former was hung up on some multicast issues. > > May i know what are these multicast issues? > > Multicast issues in MPLS are manifold (and they > just keep multiplying). > > Looping is a major problem in multicast in general, > but it is much worse if using a technology which is > not suited to TTL manipulation. Agree, but there are feasible ways to overcome this. I can point you to some work on this if you're interested. > Some hardware wants to use specific VCI numbers for > each output interface when replicating data. How to > reconcile this with Downstream Allocation is a small > problem. Doesn't sound like a lot of problems then :-) ? thanks, cyl From owner-mpls@UU.NET Tue Jan 25 19:06:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10474 for ; Tue, 25 Jan 2000 19:06:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzoy05032; Wed, 26 Jan 2000 00:04:00 GMT Received: by mail-control.mail.uu.net id QQhzoy10652 for mpls-outgoing; Wed, 26 Jan 2000 00:03:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzoy10470 for ; Wed, 26 Jan 2000 00:03:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzoy21933 for ; Tue, 25 Jan 2000 19:02:19 -0500 (EST) Received: from smtp10.atl.mindspring.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp10.atl.mindspring.net [207.69.200.246]) id QQhzoy19192 for ; Wed, 26 Jan 2000 00:02:17 GMT Received: from go.com (user-38ldc28.dialup.mindspring.com [209.86.176.72]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with SMTP id TAA08055 for ; Tue, 25 Jan 2000 19:02:09 -0500 (EST) Date: Tue, 25 Jan 2000 19:01:01 -0500 From: "Michele Richter" Message-ID: To: =?ISO-8859-1?Q?=9D=9D?= Subject: Fulfill your potential X-Mailer: eMerge 1.61 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 If you wish to be removed from our mailing list we will gladly do so. Please send an e-mail with the word "remove" in the subject line to: mrichter31@go.com. Our intention is not to annoy, but to bring you this proven money making opportunity...read on ******************************************************************* WORK AT HOME USING YOUR COMPUTER!!! ******************************************************************** Dear Friend, You can earn $46,000 or more in next the 90 days sending e-mail. Seem impossible? Read on for details (no, there is no 'catch')... ---------------------------------------------------------------------------- "AS SEEN ON NATIONAL T.V." Thank you for your time and Interest. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the internet, a major nightly news program recently devoted an entire show to the investigation of the program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are, absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show has been truly remarkable. So many people are participating that those involved are doing, much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. "HERE IT IS BELOW" ================================================ *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $46,000 in less than 90 days! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This multi-level e-mail order marketing program works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 3,500,000 millionaires in the WORLD, 20% ( 700,000) made their fortune in the last several years in MLM. Moreover, statistics show that over 100 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump (A MULTI-BILLIONAIRE, ONE OF THE WEALTHIEST MEN IN THE WORLD) made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response "That's why I'm sitting up here and you are all sitting out there!" With network marketing you have two sources of income. Direct commissions from sales you make yourself and commissions from sales made by people you introduce to the business. Residual income is the secret of the wealthy. It means investing time or money once and getting paid again and again and again. In network marketing, it also means getting paid for the work of others. This program is currently being utilized in more than 50 different countries across the world. The enclosed INF0RMATION is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for INF0RMATION on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 100,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I am telling you like it is, I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $46,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $46,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 100,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work, you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $46,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are if financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke P.S. Do you have any idea what 11,700 $5 bills ($58,000) look like piled up on a kitchen table? IT'S AWESOME! A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received INF0RMATION that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS! I have retired from the program after sending out over 1,600,000 programs. Now I have several offices that make this and several other programs here and over seas. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 100,000 or more...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, INF0RMATION, materials and opportunity to become financially independent, IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $46,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Because of the global nature of the internet, you will be able to recruit new multi-level business partners from all over the world, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere. This is what you MUST do: 1. Order all 5 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the five reports. You will need all five reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the five reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "g" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the five reports, take this advertisement and REM0VE the name and address under REPORT #5. This person has made it through the cycle and is no doubt counting their $46,000! Also, change the name of the company, the address, and the REM0VE e-mail address on the top of this document to your own. c. Move the name and address under REPORT #4 down to REPORT #5. d. Move the name and address under REPORT #3 down to REPORT #4. e. Move the name and address under REPORT #2 down to REPORT #3. f. Move the name and address under REPORT #1 down to REPORT #2. g. Insert your name/address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $25). You obviously already have an Internet connection and e-mail is FREE! To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing INF0RMATION which includes how to send bulk e-mails, where to find thousands of free classified ads and much, much more. In addition you will be provided with INF0MATION on Internet Marketing Clubs such as INTERNET MARKETING RESOURCES(IMR): This is one the premiere internet marketing clubs on the INTERNET. This club provides a forum where internet marketers from all over the world can exchange ideas and secrets on Internet Marketing. In addition, members of this club are provided free internet marketing tools and services for the Do-Yourself-Internet-Marketer. They will provide you with free bulk e-mail software and up to 1,000,000 fresh e-mail addresses each week. This club will provide you with hundreds of free resources which include: How to obtain free web sites, how to obtain top rankings in search engines for your web-site, how to send bulk e-mail into AOL and Compuserve, how to market your products on newsgroups, free classified ads, electronic malls, bulletin boards, banner ads and much more. There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.3% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.3% response, that is only 6 orders for REPORT #1. Those 6 people respond by sending out 2,000 programs each for a total of 12,000. Out of those 0.3%, 36 people respond and order REPORT #2. Those 36 mail out 2,000 programs each for a total of 72,000. The 0.3% response to that is 216 orders for REPORT #3. Those 216 send out 2,000 programs each for a 432,000 total. The 0.3% response to that is 1,296 orders for REPORT #4. Those 1,296 send out 2,000 programs each for a 2,592,000 total. The 0.3% response to that is 7,776 orders for REPORT #5. That's 7,776 $5 bills for you. CASH!!! Your total income in this example is $30 + $180 + $1,080+ $6,480 + $38,880 for a total of $46,650!!! REMEMBER FRIEND, THIS IS ASSUMING 1,994 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an internet connection and e-mail is FREE!!! REPORT #2 and #5 will show you the best methods for bulk emailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists and show you how to send out 1,000,000 e-mails for free. METHOD #2 - PLACING FREE ADS ON THE INTERNET 1. Advertising on the 'Net is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 6 people to participate on your first level. (Placing a lot of FREE ads on the internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 6 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 6 members with $5 ($5 x 6).............$30 2nd level--6 members from those 6 ($5 x 36).............$180 3rd level--6 members from those 36 ($5 x 216)....... $1,080 4th level--6 members from those 216 ($5 x 1,296).. $6,480 5th level-6 members from those 1,296 ($5 x 7,776)... $38,880 ----------- THIS ----------------------$46,650 Remember friends, this assumes that the people who participate only recruit 6 people each. Think for a moment what would happen if they got 20 people to participate! Many people will get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ *** Order Each REPORT by NUMBER and NAME *** Notes: ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT CHEQUES NOT ACCEPTED ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL Make sure the cash is concealed by wrapping it in at least two sheets of paper. On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: ______________________________________________________ REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: Michele Richter P.O. Box 4534 Fort Lauderdale, FL. 33338-4534 ______________________________________________________ REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Paul Bowen 1105 Amble Lane Clearwater, FL 33755 ______________________________________________________ REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: Renee Lewis 1584 Huron Church Road Suite 105 Windsor, ON N9C 2L1 ______________________________________________________ REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Ray Jones 113 Thunder Lane Mena, AZ 71953-7714 ______________________________________________________ REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: American United Analysis 3915 Mission Ave. Suite #7 PMB #414 Oceanside, Ca. 92054-7801 ______________________________________________________ There currently more than 175,000,000 people online worldwide! ******* TIPS FOR SUCCESS ******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the five reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO PRODUCE! 2. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP! 3. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST YOU ANYTHING TO ADVERTISE! 4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF MULTI-LEVEL MARKETING TO DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD! 5. YOUR ONLY EXPENSES OTHER THAN YOUR INITIAL $25 INVESTMENT IS YOUR TIME! 6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE PROFIT! 7. THIS PROGRAM WILL CHANGE YOUR LIFE FOREVER. ******* T E S T I M O N I A L S ******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. Fred Dellaca, Westport, New Zealand My name is Mitchell. My wife, Jody, and I live in Chicago, IL. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the program I grumbled to Jody about receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Jody totally ignored my supposed intelligence and jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Jody in her "hobby." I did have seven more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM. Mitchell Wolf MD., Chicago, IL The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Sincerely yours, Pam Hedland Halmstad, Sweden Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I surprised when I found my medium-size post office box crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where people live. There simply isn't a better investment with a faster return. Dan Sondstrom, Alberta, Canada I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program, ..11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! Mohamed, Cairo, Egypt This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Sam Lee Suva, Fiji Islands ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE TIME FOR YOUR TURN DECISIVE ACTION YIELDS POWERFUL RESULTS PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) 1-(800)827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings and results are highly dependant on your activities and advertising. This letter constitutes no guarantees stated nor implied. In the event that it is determined that this letter constitutes a guarantee of any kind, that guarantee is now void. Any testimonials or amounts of earnings listed in this letter may be factual or non-verifiable. If you have any question of the legality of this letter contact the Office of Associate Director for Marketing Practices Federal Trade Commission Bureau of Consumer Protection in Washington DC. From owner-mpls@UU.NET Tue Jan 25 23:37:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16445 for ; Tue, 25 Jan 2000 23:37:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzpq19054; Wed, 26 Jan 2000 04:33:23 GMT Received: by mail-control.mail.uu.net id QQhzpq27233 for mpls-outgoing; Wed, 26 Jan 2000 04:33:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzpq27227 for ; Wed, 26 Jan 2000 04:32:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzpq19510 for ; Tue, 25 Jan 2000 23:32:45 -0500 (EST) From: atlage@peoplepc.com Received: from c004.sfo.cp.net by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: c004-h006.c004.sfo.cp.net [209.228.14.77]) id QQhzpq00794 for ; Wed, 26 Jan 2000 04:32:44 GMT Received: (cpmta 15349 invoked from network); 25 Jan 2000 20:31:04 -0800 Received: from 2Cust10.tnt7.ind1.da.uu.net (HELO patricks) (63.29.241.138) by smtp.peoplepc.com with SMTP; 25 Jan 2000 20:31:04 -0800 X-Sent: 26 Jan 2000 04:31:04 GMT Message-ID: <00c101bf67b5$90b6bde0$d2f21d3f@patricks> To: Subject: EARN $100,000 PER YEAR SENDING E-MAIL!!! Date: Tue, 25 Jan 2000 23:18:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit **************************************************************************** ** HERE IS THE INFO YOU REQUESTED, THIS IS NOT SPAM, YOU ARE RECEIVING THIS E-MAIL BECAUSE YOU OR SOMEONE ELSE REQUESTED THIS INFORMATION FOR YOU. IF YOU WISH TO BE PERMANENTLY REMOVED FROM OUR MAILING LIST, PLEASE SEND AN E-MAIL WITH THE WORD "REMOVE" IN THE SUBJECT LINE TO: webtrash@usa.com OUR COMPANY DOES NOT SUPPORT THE SENDING OF UNSOLICITED E-MAILS. **************************************************************************** ** EARN $100,000 PER YEAR SENDING E-MAIL!!! **************************************************************************** ** Dear Friend, You can earn $46,000 or more in next the 90 days sending e-mail, seem impossible? Read on for details (no, there is no 'catch')... ---------------------------------------------------------------------------- ---------------------------------------- "AS SEEN ON NATIONAL T.V." Thank you for your time and Interest. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see, if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are, absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show have been truly remarkable. So many people are participating that those involved are doing, much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of it lately. You will understand once you experience it. "HERE IT IS BELOW" =================================================================== =================================================================== *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $46,000 in less than 90 days! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEYMAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This multi-level e-mail order marketing program works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump (A MULTI- BILLIONAIRE, ONE OF THE WEALTHIEST MEN IN THE WORLD) made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response "That's why I'm sitting up here and you are all sitting out there!" With network marketing you have two sources of income. Direct commissions from sales you make yourself and commissions from sales made by people you introduce to the business. Residual income is the secret of the wealthy. It means investing time or money once and getting paid again and again and again. In network marketing, it also means getting paid for the work of others. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. My name is Jonathan Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 100,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I am telling you like it is, I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $46,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $46,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 100,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much-needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work, you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $46,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are if financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Jonathan Rourke P.S. Do you have any idea what 11,700 $5 bills ($58,000) look like piled up on a kitchen table? IT'S AWESOME! A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS! I have retired from the program after sending out over 1,600,000 programs. Now I have several offices that make this and several other programs here and over seas. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 100,000 or more...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent, IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $46,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Because of the global nature of the internet, you will be able to recruit new multi-level business partners from all over the world, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere: This is what you MUST do: 1. Order all 5 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the five reports. You will need all five reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the five reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "g" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the five reports, take this advertisement and remove the name and address under REPORT #5. This person has made it through the cycle and is no doubt counting their $46,000! Also, change the name of the company, the address, and the remove e-mail address on the top of this document to your own. c. Move the name and address under REPORT #4 down to REPORT #5. d. Move the name and address under REPORT #3 down to REPORT #4. e. Move the name and address under REPORT #2 down to REPORT #3. f. Move the name and address under REPORT #1 down to REPORT #2. g. Insert your name/address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $25). You obviously already have an Internet connection and e-mail is FREE! To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails, where to find thousands of free classified ads and much, much more. In addition you will be provided with information on Internet Marketing Clubs such as INTERNET MARKETING RESOURCES (IMR): This is one the premiere internet marketing clubs on the INTERNET. This club provides a forum where internet marketers from all over the world can exchange ideas and secrets on Internet Marketing. In addition, members of this club are provided free internet marketing tools and services for the Do-Yourself-Internet- Marketer. They will provide you with free bulk e-mail software and up to 1,000,000 fresh e-mail addresses each week. This club will provide you with hundreds of free resources which include: How to obtain free web sites, how to obtain top rankings in search engines for your web-site, how to send bulk e-mail into AOL and Compuserve, how to market your products on newsgroups, free classified ads, electronic malls, bulletin boards, banner ads and much more. There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.3% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.3% response, that is only 6 orders for REPORT #1. Those 6 people respond by sending out 2,000 programs each for a total of 12,000. Out of those 0.3%, 36 people respond and order REPORT #2. Those 36 mail out 2,000 programs each for a total of 72,000. The 0.3% response to that is 216 orders for REPORT #3. Those 216 send out 2,000 programs each for a 432,000 total. The 0.3% response to that is 1,296 orders for REPORT #4. Those 1,296 send out 2,000 programs each for a 2,592,000 total. The 0.3% response to that is 7,776 orders for REPORT #5. That's 7,776 $5 bills for you. CASH!!! Your total income in this example is $30 + $180 + $1,080 + $6,480 +$38,880 for a total of $46,650!!! REMEMBER FRIEND, THIS IS ASSUMING 1,994 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an internet connection and e-mail is FREE!!! REPORT #2 and #5 will show you the best methods for bulk e-mailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists and show you how to send out 1,000,000 e-mails for free. METHOD #2 - PLACING FREE ADS ON THE INTERNET 1. Advertising on the 'Net is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 6 people to participate on your first level. (Placing a lot of FREE ads on the internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 6 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 6 members with $5 ($5 x 6).............$30 2nd level--6 members from those 6 ($5 x 36).............$180 3rd level--6 members from those 36 ($5 x 216)....... $1,080 4th level--6 members from those 216 ($5 x 1,296).. $6,480 5th level-6 members from those 1,296 ($5 x 7,776)... $38,880 ----------- THIS TOTALS ----------------------$46,650 Remember friends, this assumes that the people who participate only recruit 6 people each. Think for a moment what would happen if they got 20 people to participate! Many people will get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ *** Order Each REPORT by NUMBER and NAME *** Notes: - ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT - CHECKES NOT ACCEPTED - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure the cash is concealed by wrapping it in at least two sheets of paper - On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: ______________________________________________________ REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: MSP Marketing PO Box 870 Greenfield, IN 46140-0870 ______________________________________________________ REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: American United Securities 3915 Mission Avenue Suite 7 PMB 414 Oceanside, Ca. 92054-7801 ______________________________________________________ REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: MLH Enterprises 1450 N. Santa Fe Suite C PMB 525 Vista, Ca. 92083 ______________________________________________________ REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: ROJ Inc. PO BOX 5052 Oceanside, Ca. 92051-5052 ______________________________________________________ REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Marketing Unlimited PO BOX 2312 Carlsbad, Ca. 92008 ______________________________________________________ ______________________________________________________ There are currently more than 175,000,000 people online worldwide! ******* TIPS FOR SUCCESS ******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the five reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO PRODUCE! 2. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP! 3. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST YOU ANYTHING TO ADVERTISE! 4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF MULTI-LEVEL MARKETING TO DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD! 5. YOUR ONLY EXPENSES OTHER THAN YOUR INITIAL $25 INVESTMENT IS YOUR TIME! 6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE PROFIT! 7. THIS PROGRAM WILL CHANGE YOUR LIFE FOREVER. ******* T E S T I M O N I A L S ******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. Steven Bardfield, Portland, OR My name is Mitchell. My wife, Jody, and I live in Chicago, IL. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the program I grumbled to Jody about receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Jody totally ignored my supposed intelligence and jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Jody in her "hobby." I did have seven more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM. Mitchell Wolf MD., Chicago, IL The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Sincerely yours, Charles Morris, Esq. Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size post office box crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where people live. There simply isn't a better investment with a faster return. Paige Willis, Des Moines, IA I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program, ...11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! Violet Wilson, Johnstown, PA This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Kerry Ford, Centerport, NY ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE TIME FOR YOUR TURN DECISIVE ACTION YIELDS POWERFUL RESULTS PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) 1-(800)827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings and results are highly dependant on your activities and advertising. This letter constitutes no guarantees stated nor implied. In the event that it is determined that this letter constitutes a guarantee of any kind, that guarantee is now void. Any testimonials or amounts of earnings listed in this letter may be factual or fictitious. If you have any question of the legality of this letter contact the Office of Associate Director for Marketing Practices Federal Trade Commission Bureau of Consumer Protection in Washington DC. From owner-mpls@UU.NET Wed Jan 26 01:43:18 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19709 for ; Wed, 26 Jan 2000 01:43:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzpy17880; Wed, 26 Jan 2000 06:40:43 GMT Received: by mail-control.mail.uu.net id QQhzpy18280 for mpls-outgoing; Wed, 26 Jan 2000 06:40:28 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzpy18272 for ; Wed, 26 Jan 2000 06:40:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzpy27984; Wed, 26 Jan 2000 01:40:10 -0500 (EST) From: partime@tm.net.my Received: from unknown by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: sja-181-180.tm.net.my [202.188.181.180]) id QQhzpy29741; Wed, 26 Jan 2000 06:40:07 GMT Message-Id: Subject: Partime Jobs Date: Wed, 26 Jan 2000 11:05:18 To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk Dear friend, I had come across this opportunity where i earn money simply doing nothing. Suitable for those who like to earn additional income at home. Worth a look! http://www.mValue.com/register_email.jsp?ref=pschang From owner-mpls@UU.NET Wed Jan 26 03:33:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00047 for ; Wed, 26 Jan 2000 03:33:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzqf18903; Wed, 26 Jan 2000 08:27:23 GMT Received: by mail-control.mail.uu.net id QQhzqf08849 for mpls-outgoing; Wed, 26 Jan 2000 08:27:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzqf08844 for ; Wed, 26 Jan 2000 08:27:03 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzqf05890 for ; Wed, 26 Jan 2000 03:27:00 -0500 (EST) From: David.Paraje@aucs-europe.com Received: from unetxgw4.aucs-europe.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: unet4.aucs-europe.com [195.206.94.21]) id QQhzqf18568 for ; Wed, 26 Jan 2000 08:27:00 GMT Message-Id: Received: by unetxgw4.hoofddorp.aucs-europe.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jan 2000 09:24:21 +0100 To: mpls@UU.NET Subject: NETBios/MPLS Problem Date: Wed, 26 Jan 2000 09:24:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, I wanna know if anyone have worked in a environment with NETBios/MPLS. I have a network based on MPLS and have some VPNs but one of this wants a Windows Networks. The connectivity between them is good but packet greater than 1500/2000by (i dont know exactly) fails. I think is something like a problem with MTU. Any Clue? Any help? Thank in advance. Regards From owner-mpls@UU.NET Wed Jan 26 10:25:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05436 for ; Wed, 26 Jan 2000 10:25:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzrh20275; Wed, 26 Jan 2000 15:23:25 GMT Received: by mail-control.mail.uu.net id QQhzrh25513 for mpls-outgoing; Wed, 26 Jan 2000 15:23:09 GMT Received: from npiserve0.corp.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: npiserve0.corp.us.uu.net [153.39.201.152]) id QQhzrh25504 for ; Wed, 26 Jan 2000 15:23:05 GMT Received: from uu.net by npiserve0.corp.us.uu.net with ESMTP (peer crosschecked as: al2pc117-124.corp.us.uu.net [153.39.117.124]) id QQhzrh09610; Wed, 26 Jan 2000 10:22:57 -0500 (EST) Message-ID: <388F1163.5ECDCB2D@uu.net> Date: Wed, 26 Jan 2000 10:23:15 -0500 From: Mohammed Hendaz Organization: UUNET X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Simon G. M. Koo" CC: mpls@UU.NET Subject: Re: Simulation software References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Simon, you can take a look at : www.wandl.com Mohammed. "Simon G. M. Koo" wrote: > Hi, > > I am new to the MPLS group. I would like to know if there is any > simulation software available to measure the performance of network > running MPLS? I am currently working on routing decision and some > control problems on networks running MPLS. Any pointer suggested? > > Thanks. > > Simon Koo From owner-mpls@UU.NET Wed Jan 26 12:59:08 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07783 for ; Wed, 26 Jan 2000 12:59:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzrr11439; Wed, 26 Jan 2000 17:57:06 GMT Received: by mail-control.mail.uu.net id QQhzrr21605 for mpls-outgoing; Wed, 26 Jan 2000 17:56:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzrr21598 for ; Wed, 26 Jan 2000 17:56:24 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzrr11200 for ; Wed, 26 Jan 2000 12:56:20 -0500 (EST) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQhzrr10699 for ; Wed, 26 Jan 2000 17:56:19 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07731; Wed, 26 Jan 2000 12:56:16 -0500 (EST) Message-Id: <200001261756.MAA07731@ietf.org> To: IETF-Announce:; Cc: mpls@UU.NET From: The IESG SUBJECT: Last Call: Use of Label Switching on Frame Relay Networks Specification to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 26 Jan 2000 12:56:16 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has received a request from the Multiprotocol Label Switching Working Group to consider the following two Internet-Drafts as Proposed Standards: o Use of Label Switching on Frame Relay Networks Specification o MPLS using ATM VC Switching 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 February 9, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-fr-03.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-atm-02.txt From owner-mpls@UU.NET Wed Jan 26 13:04:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08019 for ; Wed, 26 Jan 2000 13:04:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzrs03684; Wed, 26 Jan 2000 18:02:12 GMT Received: by mail-control.mail.uu.net id QQhzrs24744 for mpls-outgoing; Wed, 26 Jan 2000 18:01:54 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzrs24532 for ; Wed, 26 Jan 2000 18:01:43 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzrs12335 for ; Wed, 26 Jan 2000 13:01:33 -0500 (EST) From: nMpYK0Y7U@yes.net Received: from gate.mcdermott.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gate.mcdermott.com [131.184.96.33]) id QQhzrs14984 for ; Wed, 26 Jan 2000 18:01:29 GMT Received: from NDAs93p3L (PPPa78-AtlantaD5-5R2038.saturn.bbn.com [4.14.22.109]) by gate.mcdermott.com (8.9.3/8.8.7) with SMTP id LAA28204; Wed, 26 Jan 2000 11:59:14 -0600 (CST) DATE: 26 Jan 00 12:15:23 PM Message-ID: TO: yahoo.com@gate.mcdermott.com SUBJECT: Satellite Owners! Must See! Sender: owner-mpls@UU.NET Precedence: bulk THIS IS A ONE TIME MAILING You were sent this email because it was believed it would benefit you in some way If you do not want this email - simply delete it - TEST YOUR SATELLITE CHANNELS - DO THEY WORK? TEST THEM AND SEE Your satellite receiver - if you have Direct Tv - came with a little credit card sized programming card known as a smart card. We can, for testing purposes only, program your card to receive any and all channels offered by your satellite company without you having to pay an additional monthly fee. You will receive blacked out sporting events, pay per views, premium channels and unlimited, unrestricted access to ANY channel offered by your satellite company after we program your card. We can only program H cards. These are the cards that say "DSS ACCESS CARD" on them and they are blue. We can NOT program Dish Network cards. This service is provided for testing purposes only. To receive an order form and for more informaton - Please Call 1-770-621-5852 (24hours a day, 7 days a week). From owner-mpls@UU.NET Wed Jan 26 20:55:35 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14387 for ; Wed, 26 Jan 2000 20:55:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzsx14002; Thu, 27 Jan 2000 01:51:53 GMT Received: by mail-control.mail.uu.net id QQhzsx26815 for mpls-outgoing; Thu, 27 Jan 2000 01:51:35 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzsx26810 for ; Thu, 27 Jan 2000 01:51:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzsx23506 for ; Wed, 26 Jan 2000 20:51:14 -0500 (EST) Received: from knuicsvr1.kyungpook.ac.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: knuicsvr1.kyungpook.ac.kr [155.230.15.253]) id QQhzsx01421 for ; Thu, 27 Jan 2000 01:51:13 GMT Received: from atmrouter (tenet17.kyungpook.ac.kr [155.230.13.240]) by knuicsvr1.kyungpook.ac.kr (8.8.8H1/8.8.8) with SMTP id KAA14138 for ; Thu, 27 Jan 2000 10:43:45 +0900 (KST) Message-ID: <000f01bf6869$2fb4dc20$f00de69b@knu.ac.kr> From: "Soonho Choo" To: "MPLS" Subject: LDP discovery in ATM-LSR Date: Thu, 27 Jan 2000 10:52:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA14387 Hi, all. I've a question about LDP discovery messages. The current LDP draft specifies that "... LDP Link Hellos are sent as UDP packets addressed to the well-known LDP discovery port for the all routers on this subnet group multicast address ..." When ATM switches are used as LSRs (ATM-LSR), how can ATM-LSRs best conform this specification? Any remarks are appreciated. Thanks. ~~~~~~~~~~~~~~~~~~~~~~~ Soonho Choo Telecommunication Networks Lab. Kyungpook National University ----- shchoo@ngit.kyungpook.ac.kr ~~~~~~~~~~~~~~~~~~~~~~~ From owner-mpls@UU.NET Wed Jan 26 22:59:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17506 for ; Wed, 26 Jan 2000 22:59:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhztf01684; Thu, 27 Jan 2000 03:56:31 GMT Received: by mail-control.mail.uu.net id QQhztf18572 for mpls-outgoing; Thu, 27 Jan 2000 03:55:56 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhztf18567 for ; Thu, 27 Jan 2000 03:55:48 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhztf04891 for ; Wed, 26 Jan 2000 22:55:40 -0500 (EST) Received: from blaze.hcltech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [204.160.253.201]) id QQhztf13827 for ; Thu, 27 Jan 2000 03:55:38 GMT Received: from sreeram ([192.168.201.23]) by blaze.hcltech.com (8.9.3/8.8.7) with ESMTP id JAA24637 for ; Thu, 27 Jan 2000 09:26:00 +0530 Message-Id: <200001270356.JAA24637@blaze.hcltech.com> From: "Sreemoolanathan B Iyer" To: mpls@UU.NET Date: Thu, 27 Jan 2000 09:33:10 +0530 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Sending mapping for REC-NEW-FEC X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT In the Recognise New FEC in the Label Distribution Procedures in ldp-06.txt (Appendix A.1.6), according to FEC.1, for downstream unsolicited independent control, for each peer we are supposed to send a label mapping. No distinction is made for the next hop. Are we supposed to send it to the next hop also ? We can imagine a case where sending a label mapping to the next hop can be useful. If the current next hop is using conservative mode, he will release the label, on receiving the mappnig. On the other hand, if he is using request_never & liberal modes and if at a later point of time the network topology changes drastically so that we become his next hop for the FEC, the current next hop would never be sending us a label_request at that time. If such a situation is possible, sending label mapping to the current next hop could be useful. Is this assumption correct ? Sree. From owner-mpls@UU.NET Thu Jan 27 03:05:11 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01370 for ; Thu, 27 Jan 2000 03:05:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhztv25000; Thu, 27 Jan 2000 07:57:56 GMT Received: by mail-control.mail.uu.net id QQhztv00619 for mpls-outgoing; Thu, 27 Jan 2000 07:57:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhztv00609 for ; Thu, 27 Jan 2000 07:57:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhztv20527; Thu, 27 Jan 2000 02:56:39 -0500 (EST) Received: from imc01.ex.nus.edu.sg by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: imc01.ex.nus.edu.sg [137.132.14.60]) id QQhztv24252; Thu, 27 Jan 2000 07:56:37 GMT Received: by imc01.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jan 2000 15:49:15 +0800 Message-ID: From: P A Centre Visitor Subject: RE: IEEE ICON' 2000 Conference - Call for Papers, Tutorials ... Date: Thu, 27 Jan 2000 15:48:17 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk Dear All >The 8th IEEE International Conference On Networks will be held from >September 5- 8, 2000 in Singapore. ]The aim of the conference is to >provide >an international forum for experts to promote, share and discuss various >>issues and developments in the broad field of computer and communication networks. >>We thus seek and solicit your contributions >in the form of original/unpublished papers, tutorials, and topics for >special sessions/panel discussions. More information on the scope of the conference and the guidelines for the submission of contributions can >>>be obtained at this web site : http://www.comp.nus.edu.sg/~icon/ > >We look forward to your participation. Thank you. > >Icon 2000 organizing Committee Best Regards Catherine Kua (Mrs) ICON Secretariat c/o Professional Activities Centre Faculty of Engineering Tel: (65) 8745113 Fax: (65) 8745097 Email: engpac@nus.edu.sg From owner-mpls@UU.NET Thu Jan 27 05:58:03 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02265 for ; Thu, 27 Jan 2000 05:58:03 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzuh05463; Thu, 27 Jan 2000 10:48:14 GMT Received: by mail-control.mail.uu.net id QQhzuh01841 for mpls-outgoing; Thu, 27 Jan 2000 10:47:42 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzuh01836 for ; Thu, 27 Jan 2000 10:47:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzuh09695 for ; Thu, 27 Jan 2000 05:47:23 -0500 (EST) Received: from web3506.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web3506.mail.yahoo.com [204.71.203.73]) id QQhzuh04893 for ; Thu, 27 Jan 2000 10:47:22 GMT Message-ID: <20000127104722.28455.qmail@web3506.mail.yahoo.com> Received: from [194.145.59.6] by web3506.mail.yahoo.com; Thu, 27 Jan 2000 02:47:22 PST Date: Thu, 27 Jan 2000 02:47:22 -0800 (PST) From: David Curren Subject: MPLS and Tag Switching To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Can someone help me understanding the major differences between Tag Switching and MPLS. The reason for this question is that Cisco says that there is no diference between both technologies. Regards, Dave __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-mpls@UU.NET Thu Jan 27 06:09:01 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02371 for ; Thu, 27 Jan 2000 06:09:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzui25675; Thu, 27 Jan 2000 11:05:15 GMT Received: by mail-control.mail.uu.net id QQhzui05400 for mpls-outgoing; Thu, 27 Jan 2000 11:04:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzui05370 for ; Thu, 27 Jan 2000 11:04:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzui13093 for ; Thu, 27 Jan 2000 06:04:38 -0500 (EST) Received: from malmo.trab.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQhzui14814 for ; Thu, 27 Jan 2000 11:04:38 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.9.1/TRAB-primary-2) with ESMTP id MAA13171; Thu, 27 Jan 2000 12:04:35 +0100 (MET) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jan 2000 12:04:34 +0100 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D02254123@trab-hermes.haninge.trab.se> From: Nhat Thanh Hoang To: "'David Curren'" , mpls@UU.NET Subject: RE: MPLS and Tag Switching Date: Thu, 27 Jan 2000 12:04:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA02371 Hi, David Let me try to explain briefly: The MPLS technique is based on label switching i.e. on each LSR (MPLS enable router), it makes its routing decision on the incoming label of the packet. In addition, MPLS encompasses a lot of other features. Actually there is no difference between Label Switching and Tag Swithing, except the name of tag instead of label in Cisco's MPLS enabled Router which calls Tag Switching. Tag Switching is implementation (approach) of MPLS techinque. I hope it would help, otherwise the other experts will elucidate for you. regards, Nhat Thanh *********************************************************************** Telia Research AB Email Nhat.T.Hoang@telia.se Nhat Thanh Hoang Telephone at work: 08-713 8178 Krögarvägen 14 Mobile phone: 070-5242628 14552 Norsborg Sweden Home: 08-531 86 543 *********************************************************************** Can someone help me understanding the major differences between Tag Switching and MPLS. The reason for this question is that Cisco says that there is no diference between both technologies. Regards, Dave __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-mpls@UU.NET Thu Jan 27 06:35:28 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02547 for ; Thu, 27 Jan 2000 06:35:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzuk13074; Thu, 27 Jan 2000 11:32:57 GMT Received: by mail-control.mail.uu.net id QQhzuk12070 for mpls-outgoing; Thu, 27 Jan 2000 11:32:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzuk12065 for ; Thu, 27 Jan 2000 11:32:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzuk15198 for ; Thu, 27 Jan 2000 06:32:14 -0500 (EST) Received: from sj-mailhub-3.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-3.cisco.com [171.68.224.215]) id QQhzuk12318 for ; Thu, 27 Jan 2000 11:32:14 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id DAA06606; Thu, 27 Jan 2000 03:50:43 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id GAA22381; Thu, 27 Jan 2000 06:31:53 -0500 (EST) Message-Id: <200001271131.GAA22381@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: "Sreemoolanathan B Iyer" cc: mpls@UU.NET Subject: Re: Sending mapping for REC-NEW-FEC In-reply-to: Your message of "Thu, 27 Jan 2000 09:33:10 +0530." <200001270356.JAA24637@blaze.hcltech.com> Date: Thu, 27 Jan 2000 06:31:53 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Sree, > In the Recognise New FEC in the Label Distribution Procedures in > ldp-06.txt (Appendix A.1.6), according to FEC.1, for downstream > unsolicited independent control, for each peer we are supposed to > send a label mapping. No distinction is made for the next hop. Are > we supposed to send it to the next hop also ? Yes. Bob > We can imagine a case where sending a label mapping to the next > hop can be useful. If the current next hop is using conservative > mode, he will release the label, on receiving the mappnig. On the > other hand, if he is using request_never & liberal modes and if at a > later point of time the network topology changes drastically so that > we become his next hop for the FEC, the current next hop would > never be sending us a label_request at that time. If such a situation > is possible, sending label mapping to the current next hop could be > useful. > > Is this assumption correct ? > > Sree. > > From owner-mpls@UU.NET Thu Jan 27 06:42:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02570 for ; Thu, 27 Jan 2000 06:42:36 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzuk03317; Thu, 27 Jan 2000 11:35:37 GMT Received: by mail-control.mail.uu.net id QQhzuk12148 for mpls-outgoing; Thu, 27 Jan 2000 11:35:05 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzuk12134 for ; Thu, 27 Jan 2000 11:34:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzuk15427 for ; Thu, 27 Jan 2000 06:34:43 -0500 (EST) From: lijianping@mail.zhongxing.com Received: from mail.zhongxing.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) id QQhzuk02564 for ; Thu, 27 Jan 2000 11:34:34 GMT Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 48256873.003F8BA1 ; Thu, 27 Jan 2000 19:34:05 +0800 X-Lotus-FromDomain: ZTE_LTD To: mpls@UU.NET cc: ewgray@lucent.com, christophe.boscher@alcatel.fr Message-ID: <48256873.003F6BBF.00@mail.zhongxing.com> Date: Thu, 27 Jan 2000 19:32:42 +0800 Subject: About LDP NAK Sender: owner-mpls@UU.NET Precedence: bulk Hi,All In the "LDP STATE MACHINE",there is an event of LDP NAK. The first time I read it I think it is a kind of Notification message. But there haven't a status code to define LDP NAK. And in the "draft-ietf-mpls-ldp-state-03",page 59, it write: If an LSR receives an LDP-NAK from a downstream LSR: Use the Downstream LDP Request ID and Downstream Session Identifier to locate a Downstream_LSP_control_block and pass the event `LDP Downstream NAK' to its state machine. I think the notify message have not the REQUEST message id , So perhaps the LDP NAK event is not trigged by a notify message? If I miss something , please let me know! Thanks a lot! From owner-mpls@UU.NET Thu Jan 27 07:16:09 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02915 for ; Thu, 27 Jan 2000 07:16:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzum24937; Thu, 27 Jan 2000 12:13:00 GMT Received: by mail-control.mail.uu.net id QQhzum19164 for mpls-outgoing; Thu, 27 Jan 2000 12:12:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzum19104 for ; Thu, 27 Jan 2000 12:12:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzum19293 for ; Thu, 27 Jan 2000 07:12:15 -0500 (EST) Received: from sj-mailhub-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-2.cisco.com [171.69.43.88]) id QQhzum04917 for ; Thu, 27 Jan 2000 12:12:15 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id EAA21997; Thu, 27 Jan 2000 04:15:31 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id HAA22475; Thu, 27 Jan 2000 07:12:12 -0500 (EST) Message-Id: <200001271212.HAA22475@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: "Sreemoolanathan B Iyer" cc: mpls@UU.NET Subject: Re: Sending mapping for REC-NEW-FEC In-reply-to: Your message of "Thu, 27 Jan 2000 06:31:53 EST." <200001271131.GAA22381@rhthomas-sun2.cisco.com> Date: Thu, 27 Jan 2000 07:12:12 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Sree, To address the second question in your email: > > In the Recognise New FEC in the Label Distribution Procedures in > > ldp-06.txt (Appendix A.1.6), according to FEC.1, for downstream > > unsolicited independent control, for each peer we are supposed to > > send a label mapping. No distinction is made for the next hop. Are > > we supposed to send it to the next hop also ? > > Yes. > > Bob > > > > > We can imagine a case where sending a label mapping to the next > > hop can be useful. If the current next hop is using conservative > > mode, he will release the label, on receiving the mappnig. On the > > other hand, if he is using request_never & liberal modes and if at a > > later point of time the network topology changes drastically so that > > we become his next hop for the FEC, the current next hop would > > never be sending us a label_request at that time. If such a situation > > is possible, sending label mapping to the current next hop could be > > useful. > > > > Is this assumption correct ? When LSRs use DU with liberal label retention an LSR can react to a change in next hop for a destination without interaction with other LSRs, assuming the new next hop had previously advertised the label for the destination. When LSRs use DoD with conservative label retention an LSR must interact with the new next hop to request a label for the destination and the old next hop (assuming it still has a session with it) to release the old label. Bob From owner-mpls@UU.NET Thu Jan 27 08:17:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04607 for ; Thu, 27 Jan 2000 08:17:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzuq02861; Thu, 27 Jan 2000 13:14:21 GMT Received: by mail-control.mail.uu.net id QQhzuq03342 for mpls-outgoing; Thu, 27 Jan 2000 13:13:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzuq03268 for ; Thu, 27 Jan 2000 13:13:30 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzuq29348 for ; Thu, 27 Jan 2000 08:13:26 -0500 (EST) Received: from blaze.hcltech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [204.160.253.201]) id QQhzuq11416 for ; Thu, 27 Jan 2000 13:13:23 GMT Received: from sreeram ([192.168.201.23]) by blaze.hcltech.com (8.9.3/8.8.7) with ESMTP id SAA30875; Thu, 27 Jan 2000 18:43:41 +0530 Message-Id: <200001271313.SAA30875@blaze.hcltech.com> From: "Sreemoolanathan B Iyer" To: rhthomas@cisco.com Date: Thu, 27 Jan 2000 18:43:44 +0530 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Sending mapping for REC-NEW-FEC CC: mpls@UU.NET X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Bob, I also have a related question. Bob Thomas wrote: > > > We can imagine a case where sending a label mapping to the next > > > hop can be useful. If the current next hop is using conservative > > > mode, he will release the label, on receiving the mappnig. On the > > > other hand, if he is using request_never & liberal modes and if at a > > > later point of time the network topology changes drastically so that > > > we become his next hop for the FEC, the current next hop would > > > never be sending us a label_request at that time. If such a situation > > > is possible, sending label mapping to the current next hop could be > > > useful. > > > > > When LSRs use DU with liberal label retention an LSR can react > to a change in next hop for a destination without interaction > with other LSRs, assuming the new next hop had previously > advertised the label for the destination. > So we can make the assumption that in recognise new fec, the mapping is sent to the next hop also to take care of the DU-liberal situation. To quote from my earlier question, if L1 comes to know about a new FEC, and also that L2 is its next hop for that FEC, it will still send a label mapping to L2. So if at later point of time, L1 becomes the next hop of L2 for the same FEC, things will work properly since L2 will already be having a mapping for the FEC from L1. Now, my doubt is, shouldn't the same be applicable to label mapping also ? According to LMp 17, if we know the MsgSource to be the next hop, we send the mapping to all peers except the MsgSource. Again assuming DU & liberal retention, if L1 receives a label mapping from L2 which is its next hop, L1 would propagate it to all its peers except L2. Now, if later L1 becomes the next hop for L2 for the same FEC, wouldn't we run into trouble because L2 would never receive a label mapping from L1 ? Sree. From owner-mpls@UU.NET Thu Jan 27 09:16:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05858 for ; Thu, 27 Jan 2000 09:16:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzuu09937; Thu, 27 Jan 2000 14:14:23 GMT Received: by mail-control.mail.uu.net id QQhzuu14327 for mpls-outgoing; Thu, 27 Jan 2000 14:13:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzuu14253 for ; Thu, 27 Jan 2000 14:13:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzuu06574 for ; Thu, 27 Jan 2000 09:13:20 -0500 (EST) Received: from kickme.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kickme.cisco.com [198.92.30.42]) id QQhzuu09234 for ; Thu, 27 Jan 2000 14:13:20 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id GAA18102; Thu, 27 Jan 2000 06:05:16 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA22750; Thu, 27 Jan 2000 09:13:16 -0500 (EST) Message-Id: <200001271413.JAA22750@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: "Sreemoolanathan B Iyer" cc: mpls@UU.NET Subject: Re: Sending mapping for REC-NEW-FEC In-reply-to: Your message of "Thu, 27 Jan 2000 18:43:44 +0530." <200001271313.SAA30875@blaze.hcltech.com> Date: Thu, 27 Jan 2000 09:13:15 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Sree, > I also have a related question. > > Bob Thomas wrote: > > > > We can imagine a case where sending a label mapping to > the next > > > hop can be useful. If the current next hop is using > conservative > > > mode, he will release the label, on receiving the > mappnig. On the > > > other hand, if he is using request_never & > liberal modes and if at a > > > later point of time the network > topology changes drastically so that > > > we become his next > hop for the FEC, the current next hop would > > > never be > sending us a label_request at that time. If such a situation > > > > is possible, sending label mapping to the current next hop > could be > > > useful. > > > > > > > > When LSRs use DU with liberal label retention an LSR can react > > to a change in next hop for a destination without interaction > > with other LSRs, assuming the new next hop had previously > > advertised the label for the destination. > > > > So we can make the assumption that in recognise new fec, the > mapping is sent to the next hop also to take care of the DU-liberal > situation. > > To quote from my earlier question, if L1 comes to know about a > new FEC, and also that L2 is its next hop for that FEC, it will still > send a label mapping to L2. So if at later point of time, L1 becomes > the next hop of L2 for the same FEC, things will work properly > since L2 will already be having a mapping for the FEC from L1. > > Now, my doubt is, shouldn't the same be applicable to label > mapping also ? According to LMp 17, if we know the MsgSource > to be the next hop, we send the mapping to all peers except the > MsgSource. Again assuming DU & liberal retention, if L1 receives a > label mapping from L2 which is its next hop, L1 would propagate it > to all its peers except L2. > > Now, if later L1 becomes the next hop for L2 for the same FEC, > wouldn't we run into trouble because L2 would never receive a label > mapping from L1 ? In DU mode label advertisement by an LSR is triggered by learning a new route. The procedures for independent and ordered control differ in detail (see FEC.n, Section A.1.6). If using independent control L1 would advertise the label when it learned the route. In this case, L2 would have L1's label should L1 becomes L2's next hop for FEC. For ordered control, if L2 is L1's next hop for the FEC, L1 would delay advertising the label until it received a label from L2. If L1 learned L2's label before it learned the route, it would retain L2's label and advertise its label to L2 when it later learned the route. If L1 learned the route before it learned the label from L2, the LMp.17 loop as it currently stands would omit advertisement of L1's label to L2. There is some work in progress to suggest modification to the LMp.17 loop to deal with omissions relating to the non-merge case. This work will be expanded to address the issue you raise. Thanks for pointing this out, Bob From owner-mpls@UU.NET Thu Jan 27 10:40:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07682 for ; Thu, 27 Jan 2000 10:40:47 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzva17193; Thu, 27 Jan 2000 15:37:23 GMT Received: by mail-control.mail.uu.net id QQhzva27253 for mpls-outgoing; Thu, 27 Jan 2000 15:37:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzva27248 for ; Thu, 27 Jan 2000 15:36:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzva24092 for ; Thu, 27 Jan 2000 10:36:50 -0500 (EST) Received: from stimpy.motispd.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: stimpy.motispd.com [208.243.217.11]) id QQhzva16632 for ; Thu, 27 Jan 2000 15:36:49 GMT Received: from pathannt (208.243.217.84) by stimpy.motispd.com (Worldmail 1.3.167); 27 Jan 2000 09:38:32 -0600 Message-ID: <006501bf68ed$90b1c310$54d9f3d0@pathannt> From: "Aijaz Pathan" To: "Nhat Thanh Hoang" , "'David Curren'" , References: <778DFE9B4E3BD111A74E08002BA3DC0D02254123@trab-hermes.haninge.trab.se> Subject: Re: MPLS and Tag Switching Date: Thu, 27 Jan 2000 09:34:42 -0800 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit David, As Nhat correctly pointed out, there are additional features supported by MPLS. The label format in the data plane is exactly similar for both tag switching and MPLS, and hence the compliance by Cisco. However, there might be another angle to it. Cisco IOS supports TDP (Tag Distribution Protocol) as the control protocol for distributing labels, which they say will be replaced by standard LDP and RSVP with extensions. So I think "Tag" implies TDP as control and MPLS implies LDP for most people (Although it should not). BTW, Can anyone from Cisco confirm this, and also which versions of the Cisco Router IOS supports TDP vs. LDP vs. RSVP? That would be of great help to atleast the 3 of us. Thanks -Aijaz ----- Original Message ----- From: Nhat Thanh Hoang To: 'David Curren' ; Sent: Thursday, January 27, 2000 3:04 AM Subject: RE: MPLS and Tag Switching Hi, David Let me try to explain briefly: The MPLS technique is based on label switching i.e. on each LSR (MPLS enable router), it makes its routing decision on the incoming label of the packet. In addition, MPLS encompasses a lot of other features. Actually there is no difference between Label Switching and Tag Swithing, except the name of tag instead of label in Cisco's MPLS enabled Router which calls Tag Switching. Tag Switching is implementation (approach) of MPLS techinque. I hope it would help, otherwise the other experts will elucidate for you. regards, Nhat Thanh *********************************************************************** Telia Research AB Email Nhat.T.Hoang@telia.se Nhat Thanh Hoang Telephone at work: 08-713 8178 Krögarvägen 14 Mobile phone: 070-5242628 14552 Norsborg Sweden Home: 08-531 86 543 *********************************************************************** Can someone help me understanding the major differences between Tag Switching and MPLS. The reason for this question is that Cisco says that there is no diference between both technologies. Regards, Dave __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-mpls@UU.NET Thu Jan 27 10:42:11 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07706 for ; Thu, 27 Jan 2000 10:42:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzuz00286; Thu, 27 Jan 2000 15:26:32 GMT Received: by mail-control.mail.uu.net id QQhzuz26821 for mpls-outgoing; Thu, 27 Jan 2000 15:26:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzuz26746 for ; Thu, 27 Jan 2000 15:26:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzuz19853 for ; Thu, 27 Jan 2000 10:25:43 -0500 (EST) Received: from mrelay1.swift.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: www.swift.com [149.134.97.1]) id QQhzuz08246 for ; Thu, 27 Jan 2000 15:25:42 GMT Received: from bemsl01.swift.com by mrelay1.swift.com (Sun Internet Mail Server sims.3.5.1998.11.13.11.10) with ESMTP id <0FP00000204K2M@mrelay1.swift.com> for mpls@UU.net; Thu, 27 Jan 2000 14:26:44 +0000 (GMT) Received: from swift.com ([149.134.20.153]) by bemsl01.swift.com (Sun Internet Mail Server sims.3.5.1999.07.30.00.05.p8) with ESMTP id <0FP00000204J1J@bemsl01.swift.com> for mpls@UU.net; Thu, 27 Jan 2000 14:26:43 +0000 (GMT) Date: Thu, 27 Jan 2000 15:25:23 +0100 From: Dirk Maeckelberghe Subject: LDP label integrity To: mpls@UU.NET Message-id: <38905553.2F4897CE@swift.com> Organization: S.W.I.F.T. sc MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD SWIFT-W42 (WinNT; I) Content-type: multipart/mixed; boundary="------------C90051C7B55FBE83D5197BE0" X-Accept-Language: en Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------C90051C7B55FBE83D5197BE0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Can someone please inform me on the mechanisms proposed to ensure the integrity of labels exchanged with LDP ? Is there an option to use keyed MD5 ? Can someone point me to documents describing the security aspects of an MPLS based network ? Thank you, Dirk --------------C90051C7B55FBE83D5197BE0 Content-Type: text/x-vcard; charset=us-ascii; name="Dirk.Maeckelberghe.vcf" Content-Description: Card for Dirk Maeckelberghe Content-Disposition: attachment; filename="Dirk.Maeckelberghe.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Maeckelberghe;Dirk tel;work:S.W.I.F.T. s.c. x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:Dirk.Maeckelberghe@swift.com fn:Dirk Maeckelberghe end:vcard --------------C90051C7B55FBE83D5197BE0-- From owner-mpls@UU.NET Thu Jan 27 11:09:52 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08668 for ; Thu, 27 Jan 2000 11:09:52 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzvc07631; Thu, 27 Jan 2000 16:07:15 GMT Received: by mail-control.mail.uu.net id QQhzvc03605 for mpls-outgoing; Thu, 27 Jan 2000 16:06:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzvc03568 for ; Thu, 27 Jan 2000 16:06:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzvc27840 for ; Thu, 27 Jan 2000 11:06:45 -0500 (EST) From: Jean.Conti@swisscom.com Received: from gd2w07.swissptt.ch by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: outmail2.swisscom.com [138.190.3.29]) id QQhzvc28914 for ; Thu, 27 Jan 2000 16:06:44 GMT Received: from sbe2173.swissptt.ch (138.190.170.55) by gd2w08.swissptt.ch (MX V5.1-A AnHp) with SMTP; Thu, 27 Jan 2000 17:06:22 +0100 Received: by gd2zdk.swissptt.ch with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jan 2000 16:49:00 +0100 Message-ID: To: pathan@motispd.com, Nhat.T.Hoang@telia.se, mpls@UU.NET Subject: RE: MPLS and Tag Switching Date: Thu, 27 Jan 2000 16:48:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA08668 Hi, I would very much appreciate having a complete listing of the additional features supported by MPLS Even partial answer will help Thanks in advance for your support, jean Jean Conti Swisscom Ltd Major Accounts Consulting & Design 49, rte de Meyrin CH-1211 Geneva 2 (Switzerland) Tel: +41 22 797 9716 Fax: +41 22 797 9996 Mobile: +41 79 236 1208 Email: jean.conti@swisscom.com -----Message d'origine----- De: Aijaz Pathan [mailto:pathan@motispd.com] Date: jeudi, 27. janvier 2000 18:35 Ā: Nhat Thanh Hoang; 'David Curren'; mpls@UU.NET Objet: Re: MPLS and Tag Switching David, As Nhat correctly pointed out, there are additional features supported by MPLS. The label format in the data plane is exactly similar for both tag switching and MPLS, and hence the compliance by Cisco. However, there might be another angle to it. Cisco IOS supports TDP (Tag Distribution Protocol) as the control protocol for distributing labels, which they say will be replaced by standard LDP and RSVP with extensions. So I think "Tag" implies TDP as control and MPLS implies LDP for most people (Although it should not). BTW, Can anyone from Cisco confirm this, and also which versions of the Cisco Router IOS supports TDP vs. LDP vs. RSVP? That would be of great help to atleast the 3 of us. Thanks -Aijaz ----- Original Message ----- From: Nhat Thanh Hoang To: 'David Curren' ; Sent: Thursday, January 27, 2000 3:04 AM Subject: RE: MPLS and Tag Switching Hi, David Let me try to explain briefly: The MPLS technique is based on label switching i.e. on each LSR (MPLS enable router), it makes its routing decision on the incoming label of the packet. In addition, MPLS encompasses a lot of other features. Actually there is no difference between Label Switching and Tag Swithing, except the name of tag instead of label in Cisco's MPLS enabled Router which calls Tag Switching. Tag Switching is implementation (approach) of MPLS techinque. I hope it would help, otherwise the other experts will elucidate for you. regards, Nhat Thanh *********************************************************************** Telia Research AB Email Nhat.T.Hoang@telia.se Nhat Thanh Hoang Telephone at work: 08-713 8178 Krögarvägen 14 Mobile phone: 070-5242628 14552 Norsborg Sweden Home: 08-531 86 543 *********************************************************************** Can someone help me understanding the major differences between Tag Switching and MPLS. The reason for this question is that Cisco says that there is no diference between both technologies. Regards, Dave __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-mpls@UU.NET Thu Jan 27 11:56:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09624 for ; Thu, 27 Jan 2000 11:56:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzvf09246; Thu, 27 Jan 2000 16:53:16 GMT Received: by mail-control.mail.uu.net id QQhzvf09432 for mpls-outgoing; Thu, 27 Jan 2000 16:52:53 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzvf09427 for ; Thu, 27 Jan 2000 16:52:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzvf06953 for ; Thu, 27 Jan 2000 11:52:43 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQhzvf01515 for ; Thu, 27 Jan 2000 16:52:43 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id LAA26136; Thu, 27 Jan 2000 11:52:41 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id LAA34378; Thu, 27 Jan 2000 11:54:36 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200001271654.LAA34378@curtis-lt.avici.com> To: David Curren cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS and Tag Switching In-reply-to: Your message of "Thu, 27 Jan 2000 02:47:22 PST." <20000127104722.28455.qmail@web3506.mail.yahoo.com> Date: Thu, 27 Jan 2000 11:54:36 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20000127104722.28455.qmail@web3506.mail.yahoo.com>, David Curren wr ites: > Can someone help me understanding the major > differences between Tag Switching and MPLS. > The reason for this question is that Cisco says that > there is no diference between both technologies. > > Regards, > Dave A bit of history (IMNSHO): 1) There were discussions on the int-serv mailing list about switching IP that preceeded any vendor's announcement of product. See archives if you want to confirm. 2) Four products followed, though clearly some developments had begun prior to the open discussions on the mailing list. These were: Ipsilon IP switching, Cisco TAG, IBM ARIS, Toshiba CSR. 3) The MPLS WG formed to try to converge. The initial goal was to solve the minor problem of patricia trie lookup instruction cycles using a tag that facilitated array lookup. 4) The patricia trie lookup is no longer considered a problem in modern architectures. IP lookup hardware capable of line rate OC192c has been developed by a number of router vendors. 5) Traffic engineering replaced the prior reason for the MPLS WG to exist except in the view of 1) companies that wanted to breath addition life into older hardware that couldn't forward fast enough, 2) ATM (and FR) vendors that thought it might breath new life into a dying market for ATM. 6) The MPLS WG produced LDP which was useless for TE, later MPLS-RSVP which addressed TE, still later CR-LDP which addressed TE using additions to LDP. To the extent that Cisco TAG has evolved to be LDP like what Cisco told you had some truth to it. Though they are similar and share some common heritage: TAG != MPLS Curtis From owner-mpls@UU.NET Thu Jan 27 12:42:02 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10505 for ; Thu, 27 Jan 2000 12:42:00 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzvi03653; Thu, 27 Jan 2000 17:39:04 GMT Received: by mail-control.mail.uu.net id QQhzvi19738 for mpls-outgoing; Thu, 27 Jan 2000 17:38:44 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzvi19733 for ; Thu, 27 Jan 2000 17:38:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzvi15058 for ; Thu, 27 Jan 2000 12:38:36 -0500 (EST) Received: from ns01.newbridge.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns01.newbridge.com [192.75.23.67]) id QQhzvi03184 for ; Thu, 27 Jan 2000 17:38:36 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id MAA12712 for ; Thu, 27 Jan 2000 12:33:22 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA0YIJ4i; Thu Jan 27 12:33:14 2000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Thu, 27 Jan 2000 12:38:12 -0500 Received: from pcswb ([138.120.49.67]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA5A1E; Thu, 27 Jan 2000 12:38:05 -0500 Message-Id: <4.2.2.20000127123652.00a52b80@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 27 Jan 2000 12:37:37 -0500 To: curtis@avici.com From: "Scott W Brim" Subject: Re: MPLS and Tag Switching Cc: mpls@UU.NET In-Reply-To: <200001271654.LAA34378@curtis-lt.avici.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:54 01/27/2000 -0500, Curtis Villamizar wrote: >A bit of history (IMNSHO): Let's not forget egress tagging in Arpanet. ...Scott From owner-mpls@UU.NET Thu Jan 27 13:10:57 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11191 for ; Thu, 27 Jan 2000 13:10:56 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzvk19135; Thu, 27 Jan 2000 18:03:48 GMT Received: by mail-control.mail.uu.net id QQhzvk25189 for mpls-outgoing; Thu, 27 Jan 2000 18:03:25 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzvk25133 for ; Thu, 27 Jan 2000 18:03:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzvk20331 for ; Thu, 27 Jan 2000 13:03:13 -0500 (EST) Received: from auemlsrv.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQhzvk18643 for ; Thu, 27 Jan 2000 18:03:12 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA18761 for ; Thu, 27 Jan 2000 13:03:12 -0500 (EST) Received: from mvjok.mv.lucent.com (h135-13-160-24.lucent.com [135.13.160.24]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id NAA18752 for ; Thu, 27 Jan 2000 13:03:11 -0500 (EST) Received: by mvjok.mv.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA02683; Thu, 27 Jan 2000 13:03:10 -0500 Cc: mpls@UU.NET, Christophe Boscher , Liwen Wu , Pierrick Cheval Received: from lucent.com by mvjok.mv.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA02659; Thu, 27 Jan 2000 13:02:57 -0500 Message-ID: <3890894B.EE8121DA@lucent.com> Date: Thu, 27 Jan 2000 13:07:07 -0500 From: Eric Gray X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: lijianping@mail.zhongxing.com Original-CC: mpls@UU.NET, Christophe Boscher , Liwen Wu , Pierrick Cheval Subject: Re: About LDP NAK References: <48256873.003F6BBF.00@mail.zhongxing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lijianping, Check out section 2, page 2 "Terminology" where we define LDP-NAK as "LDP Notification message used to reject an LDP message." Also, check out section 3.4.6 ("Status TLV") on page 42 of the LDP specification. You'll find there that the Satus TLV has a Message ID field in it. Consequently, a Notification message (which MUST have a Status TLV) will have a Message ID in it (unless it does not pertain to a message specifically - as in shutdown Notification). You wrote: > > Hi,All > In the "LDP STATE MACHINE",there is an event of LDP NAK. > The first time I read it I think it is a kind of Notification > message. But there haven't a status code to define LDP NAK. > > And in the "draft-ietf-mpls-ldp-state-03",page 59, it write: > > If an LSR receives an LDP-NAK from a downstream LSR: > > Use the Downstream LDP Request ID and Downstream Session Identifier to > locate a Downstream_LSP_control_block and pass the event `LDP Downstream > NAK' to its state machine. > > I think the notify message have not the REQUEST message id , So perhaps > the LDP NAK event is not trigged by a notify message? > > If I miss something , please let me know! > > Thanks a lot! You're welcome! Hopefully, this helps... -- Eric Gray From owner-mpls@UU.NET Thu Jan 27 13:33:42 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11598 for ; Thu, 27 Jan 2000 13:33:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzvl03723; Thu, 27 Jan 2000 18:27:02 GMT Received: by mail-control.mail.uu.net id QQhzvl00720 for mpls-outgoing; Thu, 27 Jan 2000 18:26:36 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzvl00712 for ; Thu, 27 Jan 2000 18:26:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzvl23544 for ; Thu, 27 Jan 2000 13:26:20 -0500 (EST) Received: from auemlsrv.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQhzvl03093 for ; Thu, 27 Jan 2000 18:26:20 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA17737 for ; Thu, 27 Jan 2000 13:26:19 -0500 (EST) Received: from mvjok.mv.lucent.com (h135-13-160-24.lucent.com [135.13.160.24]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id NAA17730 for ; Thu, 27 Jan 2000 13:26:19 -0500 (EST) Received: by mvjok.mv.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA03090; Thu, 27 Jan 2000 13:24:47 -0500 Cc: mpls@UU.NET, Bob Thomas Received: from lucent.com by mvjok.mv.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA03078; Thu, 27 Jan 2000 13:24:36 -0500 Message-ID: <38908E5E.9F7FE194@lucent.com> Date: Thu, 27 Jan 2000 13:28:46 -0500 From: Eric Gray X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Dirk Maeckelberghe Original-CC: mpls@UU.NET, Bob Thomas Subject: Re: LDP label integrity References: <38905553.2F4897CE@swift.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dirk, Please read the draft, in particular, the security section. The draft is available at: http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-mpls-ldp-06.txt What is specified is an approach to avoid successful insertion of TCP segments by a deliberate attacker. The approach was originally specified for BGP. Dirk Maeckelberghe wrote: > > Can someone please inform me on the mechanisms proposed to ensure the > integrity of labels exchanged with LDP ? > Is there an option to use keyed MD5 ? > Can someone point me to documents describing the security aspects of an > MPLS based network ? > > Thank you, > > Dirk > > -------------------------------------------------------------------------------- > > Dirk Maeckelberghe > > Dirk Maeckelberghe > > Work: S.W.I.F.T. s.c. > Additional Information: > Last Name Maeckelberghe > First NameDirk > Version 2.1 From owner-mpls@UU.NET Thu Jan 27 13:46:59 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11830 for ; Thu, 27 Jan 2000 13:46:58 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzvm12708; Thu, 27 Jan 2000 18:40:09 GMT Received: by mail-control.mail.uu.net id QQhzvm02071 for mpls-outgoing; Thu, 27 Jan 2000 18:39:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzvm02051 for ; Thu, 27 Jan 2000 18:39:37 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzvm25746 for ; Thu, 27 Jan 2000 13:39:19 -0500 (EST) Received: from wacko.redbacknetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wacko.redbacknetworks.com [155.53.130.200]) id QQhzvm12036 for ; Thu, 27 Jan 2000 18:39:19 GMT Received: from tradrat.redbacknetworks.com (tradrat.redbacknetworks.com [155.53.190.107]) by wacko.redbacknetworks.com (8.9.3/8.9.3) with ESMTP id KAA17762; Thu, 27 Jan 2000 10:39:17 -0800 (PST) Received: (from tor@localhost) by tradrat.redbacknetworks.com (8.8.8/8.6.9) id KAA24459; Thu, 27 Jan 2000 10:39:17 -0800 (PST) Date: Thu, 27 Jan 2000 10:39:17 -0800 From: Rene Tio To: Aijaz Pathan Cc: Nhat Thanh Hoang , "'David Curren'" , mpls@UU.NET Subject: Re: MPLS and Tag Switching Message-ID: <20000127103917.C24322@tradrat.redbacknetworks.com> References: <778DFE9B4E3BD111A74E08002BA3DC0D02254123@trab-hermes.haninge.trab.se> <006501bf68ed$90b1c310$54d9f3d0@pathannt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <006501bf68ed$90b1c310$54d9f3d0@pathannt>; from Aijaz Pathan on Thu, Jan 27, 2000 at 09:34:42AM -0800 Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Jan 27, 2000 at 09:34:42AM -0800, Aijaz Pathan wrote: [...] > "Tag" implies TDP as control and MPLS implies LDP for most people (Although > it should not). From what I understand, before a certain release if you configure "tag-switching" on a cisco box you are configuring the cisco-proprietary tag switching (i.e., TDP, etc.) After certain releases, "tag-switching" will configure MPLS (i.e., LDP.) This provides for easy migration (assuming cisco will auto-detect between LDP and TDP so you won't have to flash-cut the entire network.) What those releases are only a cisco release wizard will be able to tell. R. From owner-mpls@UU.NET Thu Jan 27 14:21:14 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12481 for ; Thu, 27 Jan 2000 14:21:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzvp13256; Thu, 27 Jan 2000 19:18:52 GMT Received: by mail-control.mail.uu.net id QQhzvp12518 for mpls-outgoing; Thu, 27 Jan 2000 19:18:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzvp12510 for ; Thu, 27 Jan 2000 19:18:28 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzvp02302 for ; Thu, 27 Jan 2000 14:18:15 -0500 (EST) Received: from kickme.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kickme.cisco.com [198.92.30.42]) id QQhzvp06454 for ; Thu, 27 Jan 2000 19:18:15 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA12087; Thu, 27 Jan 2000 11:08:42 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA19660; Thu, 27 Jan 2000 14:16:36 -0500 (EST) Message-Id: <200001271916.OAA19660@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: David Curren cc: mpls@UU.NET Subject: Re: MPLS and Tag Switching In-reply-to: Your message of Thu, 27 Jan 2000 02:47:22 -0800. <20000127104722.28455.qmail@web3506.mail.yahoo.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.5 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 27 Jan 2000 14:16:35 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Do you know the old saying, "A camel is a horse designed by a committee"? Think of MPLS as Tag Switching with humps ;-) Fortunately, most of the humps are optional! Anyway, it's hardly unusual for a technology to grow a few humps as it evolves. Sure, to be interoperable in the control plane with other MPLS implementations, TDP must be replaced by LDP (aka TDPv2), but the user isn't going to see much of a difference, as these two protocols are nearly equivalent functionally. (No change to the forwarding plane is needed at all.) On a given router, LDP can be running on one interface while TDP is running on another, and label switching can still be done between the two interfaces. MPLS and Tag Switching really are the same technology; "tag switching" is just the name that was used before the standards were available. If you read Curtis' little history of MPLS, don't take it too seriously. His theories about the goals, motives, and thoughts of the people involved in the MPLS effort are not very accurate. From owner-mpls@UU.NET Thu Jan 27 17:17:20 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15904 for ; Thu, 27 Jan 2000 17:17:18 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzwa20808; Thu, 27 Jan 2000 22:14:58 GMT Received: by mail-control.mail.uu.net id QQhzwa18475 for mpls-outgoing; Thu, 27 Jan 2000 22:14:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzwa18466 for ; Thu, 27 Jan 2000 22:14:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzwa14345 for ; Thu, 27 Jan 2000 17:14:12 -0500 (EST) Received: from 21cn.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [202.104.32.241]) id QQhzwa13569 for ; Thu, 27 Jan 2000 22:13:48 GMT Received: from 21cn.com([10.1.0.101]) by 21cn.com(JetMail 2.3.2.1) with SMTP id /aimcque/jmail.rcv/2/jm173890d0bb; Thu, 27 Jan 2000 22:14:14 -0000 Received: from wodc7-2.corprelay.mail.uu.net([192.48.96.69]) by 21cn.com(JetMail 2.3.2.1) with SMTP id /aimcque/jmail.rcv/2/jm5b38906b5f; Thu, 27 Jan 2000 12:14:07 -0000 Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzum25073; Thu, 27 Jan 2000 12:13:05 GMT Received: by mail-control.mail.uu.net id QQhzum19164 for mpls-outgoing; Thu, 27 Jan 2000 12:12:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzum19104 for ; Thu, 27 Jan 2000 12:12:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzum19293 for ; Thu, 27 Jan 2000 07:12:15 -0500 (EST) Received: from sj-mailhub-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-mailhub-2.cisco.com [171.69.43.88]) id QQhzum04917 for ; Thu, 27 Jan 2000 12:12:15 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id EAA21997; Thu, 27 Jan 2000 04:15:31 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id HAA22475; Thu, 27 Jan 2000 07:12:12 -0500 (EST) Message-Id: <200001271212.HAA22475@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: "Sreemoolanathan B Iyer" cc: mpls@UU.NET Subject: Re: Sending mapping for REC-NEW-FEC In-reply-to: Your message of "Thu, 27 Jan 2000 06:31:53 EST." <200001271131.GAA22381@rhthomas-sun2.cisco.com> Date: Thu, 27 Jan 2000 07:12:12 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Sree, To address the second question in your email: > > In the Recognise New FEC in the Label Distribution Procedures in > > ldp-06.txt (Appendix A.1.6), according to FEC.1, for downstream > > unsolicited independent control, for each peer we are supposed to > > send a label mapping. No distinction is made for the next hop. Are > > we supposed to send it to the next hop also ? > > Yes. > > Bob > > > > > We can imagine a case where sending a label mapping to the next > > hop can be useful. If the current next hop is using conservative > > mode, he will release the label, on receiving the mappnig. On the > > other hand, if he is using request_never & liberal modes and if at a > > later point of time the network topology changes drastically so that > > we become his next hop for the FEC, the current next hop would > > never be sending us a label_request at that time. If such a situation > > is possible, sending label mapping to the current next hop could be > > useful. > > > > Is this assumption correct ? When LSRs use DU with liberal label retention an LSR can react to a change in next hop for a destination without interaction with other LSRs, assuming the new next hop had previously advertised the label for the destination. When LSRs use DoD with conservative label retention an LSR must interact with the new next hop to request a label for the destination and the old next hop (assuming it still has a session with it) to release the old label. Bob From owner-mpls@UU.NET Thu Jan 27 17:31:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16131 for ; Thu, 27 Jan 2000 17:31:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzwb25277; Thu, 27 Jan 2000 22:29:58 GMT Received: by mail-control.mail.uu.net id QQhzwb19535 for mpls-outgoing; Thu, 27 Jan 2000 22:29:31 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzwb19530 for ; Thu, 27 Jan 2000 22:29:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzwb17268 for ; Thu, 27 Jan 2000 17:29:22 -0500 (EST) Received: from pilot004.cl.msu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilot004.cl.msu.edu [35.9.5.104]) id QQhzwb01280 for ; Thu, 27 Jan 2000 22:29:20 GMT Received: from vappala (vappala.user.msu.edu [35.10.17.48]) by pilot004.cl.msu.edu (8.9.1a/8.9.1) with ESMTP id RAA30396; Thu, 27 Jan 2000 17:29:12 -0500 Message-ID: <000501bf6916$ba517200$30110a23@user.msu.edu> From: "Vasu Vuppala" To: , Subject: Re: NETBios/MPLS Problem Date: Thu, 27 Jan 2000 17:34:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, I have not worked with NetBIOS/MPLS but here is a shot. Be aware that the fragmentation solution in MPLS works only for IP packets. If NetBIOS is not running over TCP/IP and the packets are sent over an MPLS LSP/VPN, you will run into problems. The solution is to run NetBIOS over TCP/IP or adjust the MTU of each machine. - vasu --- David.Paraje@aucs-europe.com wrote: > Hi, > > I wanna know if anyone have worked in a environment with > NETBios/MPLS. > I have a network based on MPLS and have some VPNs but one of this > wants a Windows Networks. The connectivity between them is good but packet > greater than 1500/2000by (i dont know exactly) fails. I think is something > like a problem with MTU. > > Any Clue? Any help? > > Thank in advance. > > Regards > From owner-mpls@UU.NET Thu Jan 27 18:13:28 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16639 for ; Thu, 27 Jan 2000 18:13:27 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzwe21686; Thu, 27 Jan 2000 23:11:08 GMT Received: by mail-control.mail.uu.net id QQhzwe29253 for mpls-outgoing; Thu, 27 Jan 2000 23:10:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzwe29248 for ; Thu, 27 Jan 2000 23:10:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzwe24792 for ; Thu, 27 Jan 2000 18:10:23 -0500 (EST) Received: from mailman.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQhzwe21043 for ; Thu, 27 Jan 2000 23:10:22 GMT Received: from jlawrenc-pc.cisco.com (jlawrenc-isdn.cisco.com [144.254.141.30]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA11597 for ; Thu, 27 Jan 2000 15:10:20 -0800 (PST) Message-Id: <4.2.2.20000128094953.00a9f430@farley.cisco.com> X-Sender: jlawrenc@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jan 2000 10:10:03 +1100 To: mpls@UU.NET From: Jeremy Lawrence Subject: Re: MPLS and Tag Switching In-Reply-To: <200001271654.LAA34378@curtis-lt.avici.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 11:54 01/27/2000 -0500, Curtis Villamizar wrote: [...] >To the extent that Cisco TAG has evolved to be LDP like what Cisco >told you had some truth to it. The truth doesn't stop with LDP. :) Notice the similarities between the current "Label Stack Encoding" draft http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-07.txt and the first published "Tag Switching: Tag Stack Encodings" draft http://infonet.aist-nara.ac.jp/member/nori-d/mlr/id/draft-rosen-tag-stack-00.txt The original header format has survived, with the only changes to it being the assignment of some originally "reserved" bits, and the "CoS" field has being renamed. The assignment of reserved bits happened in rev 2 of the Tag Stack draft http://infonet.aist-nara.ac.jp/member/nori-d/mlr/id/draft-rosen-tag-stack-02.txt and shipping Tag Switching code has always used the header format which became the MPLS Label Stack Encoding. Other similar examples can be found in Noritoshi Demizu's wonderful archive http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ Jeremy Lawrence From owner-mpls@UU.NET Thu Jan 27 20:57:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17678 for ; Thu, 27 Jan 2000 20:57:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzwp20844; Fri, 28 Jan 2000 01:54:42 GMT Received: by mail-control.mail.uu.net id QQhzwp25969 for mpls-outgoing; Fri, 28 Jan 2000 01:54:16 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQhzwp25961 for ; Fri, 28 Jan 2000 01:54:08 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzwp07614 for ; Thu, 27 Jan 2000 20:54:06 -0500 (EST) From: lijianping@mail.zhongxing.com Received: from mail.zhongxing.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) id QQhzwp20287 for ; Fri, 28 Jan 2000 01:53:50 GMT Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 48256874.000A6419 ; Fri, 28 Jan 2000 09:53:29 +0800 X-Lotus-FromDomain: ZTE_LTD To: ewgray@lucent.com cc: mpls@UU.NET Message-ID: <48256874.000A4438.00@mail.zhongxing.com> Date: Fri, 28 Jan 2000 09:52:08 +0800 Subject: some question about ldp-state-machine Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have still some questions about ldp-state-machine,that is: 1. in the section 3.2.2.8, in the downstream-lsp-control-block's state machine, State: ESTABLISHED Event: LDP Downstream NAK New State: ESTABLISHED Actions It is a protocol error from the downstream LDP peer. 2. in the section 3.2.2.8, in the downstream-lsp-control-block's state machine, status ESTABLISHED, there is no actions to DOWNSTREAM LOST event. Why? I think in the environment like the following, will meet the event DOWNSTREAM LOST in the downstream-lsp-control-block, status ESTABLISHED: A -----------------------> B LSR A and LSR B have already had an operational session, the LSP between A and B is established. Now we disconnect the link of A and B, so LSR A's downstream-lsp-control-block will receive UPSTREAM LOST,and LSR B's upstream-lsp-control-block will receive DOWNSTREAM LOST. So how to process it? Can I process it like the actions of event LDP Downstream NAK in status RESPONSE-AWAITED? And in the status ESTABLISHED there will also meet the event LDP Downstream NAK , How to process it? Perhaps my point is not right, if I miss something, please let me know. Thanks a lot! Lijianping. From owner-mpls@UU.NET Thu Jan 27 22:11:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19144 for ; Thu, 27 Jan 2000 22:11:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzwu29831; Fri, 28 Jan 2000 03:01:24 GMT Received: by mail-control.mail.uu.net id QQhzwu09570 for mpls-outgoing; Fri, 28 Jan 2000 03:00:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzwu09560 for ; Fri, 28 Jan 2000 03:00:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzwu16090 for ; Thu, 27 Jan 2000 22:00:44 -0500 (EST) Received: from ns.chinanet.cn.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [202.97.7.6]) id QQhzwu23140 for ; Fri, 28 Jan 2000 03:00:36 GMT Received: from router.cn.net ([202.97.3.141]) by ns.chinanet.cn.net (8.9.3/8.9.3) with SMTP id LAA29379; Fri, 28 Jan 2000 11:00:55 +0800 (CST) Date: Fri, 28 Jan 2000 11:00:55 +0800 (CST) Message-Id: <200001280300.LAA29379@ns.chinanet.cn.net> X-Sender: zhouws@publicf.bta.net.cn X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Jeremy Lawrence From: zhouws@publicf.bta.net.cn (zhouws) Subject: Re: MPLS and Optical network!! Cc: Sender: owner-mpls@UU.NET Precedence: bulk At 17:16 00-1-24 +1100, Jeremy Lawrence wrote: >At 14:12 01/24/2000 +0800, Sheng-hung Shih wrote: >> > In ATM MPLS network, the top-level label on a packet is applied by >> > sending the packet on a virtual circuit with a chosen VCI. Similarly, >> > in optical MPLS, the top-level label will be applied to a packet by >> > sending it on a lightpath with a chosen wavelength. >> It seems like the hop-by-hop routing,isn't it? > >The intended use of optical MPLS is not hop-by-hop routed MPLS, >but explicitly routed MPLS. I have been wondering what issue the optical MPLS will solve? (The only possible approach is for the future network,which will consist of a optical core and routers at edge,and these routers are full-meshed with optical wavelength.) But if the high end router could keep up with the optical bandwith increasing,any need to add this feature on optical network? (Another possible approach is routers interconnected fully or partial-fully meshed via dark fibers.) rds ---- zhou wanshu > >>And the number of >>wavelength is also a problem. > >Well, 80 wavelengths is enough for one router to connect to 80 >others across an OXC network (subject to a valid route being >available for each lightpath), so this isn't too much of a problem. >There are rumours of OXCs coming which support 1000+ wavelengths. > >Regards, > >Jeremy Lawrence > > > From owner-mpls@UU.NET Thu Jan 27 22:30:42 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19397 for ; Thu, 27 Jan 2000 22:30:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzwv13349; Fri, 28 Jan 2000 03:28:47 GMT Received: by mail-control.mail.uu.net id QQhzwv17679 for mpls-outgoing; Fri, 28 Jan 2000 03:28:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzwv17674 for ; Fri, 28 Jan 2000 03:28:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzwv17236 for ; Thu, 27 Jan 2000 22:28:08 -0500 (EST) From: bie.jiuling@mail.zhongxing.com Received: from mail.zhongxing.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) id QQhzwv12781 for ; Fri, 28 Jan 2000 03:27:52 GMT Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 48256874.0012FEAB ; Fri, 28 Jan 2000 11:27:28 +0800 X-Lotus-FromDomain: ZTE_LTD To: mpls@UU.NET Message-ID: <48256874.0012DEDC.00@mail.zhongxing.com> Date: Fri, 28 Jan 2000 11:26:06 +0800 Subject: VPN draft status query Sender: owner-mpls@UU.NET Precedence: bulk Hi Could someone tell me about current status of following drafts and anywhere to find updated version? Files include: draft-casey-vpn-mpls-00.txt draft-li-mpls-vpn-00.txt draft-heinanen-generic-vpn-mpls-00.txt draft-jamieson-mpls-vpn-00.txt draft-heinanen-mpls-vpn-01.txt draft-muthukrishnan-corevpn-arch-00.txt. Thanks a lot! Seado From owner-mpls@UU.NET Fri Jan 28 00:41:32 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21341 for ; Fri, 28 Jan 2000 00:41:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzxe14314; Fri, 28 Jan 2000 05:39:08 GMT Received: by mail-control.mail.uu.net id QQhzxe08894 for mpls-outgoing; Fri, 28 Jan 2000 05:38:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzxe08889 for ; Fri, 28 Jan 2000 05:38:49 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzxe27361 for ; Fri, 28 Jan 2000 00:38:34 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQhzxe09536 for ; Fri, 28 Jan 2000 05:38:34 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id AAA12829 for ; Fri, 28 Jan 2000 00:38:33 -0500 (EST) Received: from mvjok.mv.lucent.com (h135-13-160-24.lucent.com [135.13.160.24]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id AAA12815 for ; Fri, 28 Jan 2000 00:38:33 -0500 (EST) Received: by mvjok.mv.lucent.com (SMI-8.6/EMS-1.5 sol2) id AAA27376; Fri, 28 Jan 2000 00:38:22 -0500 Cc: mpls@UU.NET Received: from lucent.com by mvjok.mv.lucent.com (SMI-8.6/EMS-1.5 sol2) id AAA27358; Fri, 28 Jan 2000 00:37:59 -0500 Message-ID: <38912C30.5DD7AE41@lucent.com> Date: Fri, 28 Jan 2000 00:42:08 -0500 From: Eric Gray X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: lijianping@mail.zhongxing.com Original-CC: mpls@UU.NET Subject: Re: some question about ldp-state-machine References: <48256874.000A4438.00@mail.zhongxing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lijianping, Where do you find a section 3.2.2.8? The currently posted version is numbered such that 3.2.2 is followed by 3.2.3 as the very next numbered sub-section. Also, please see comments embedded below. You wrote: > > Hi, > I have still some questions about ldp-state-machine,that is: > > 1. in the section 3.2.2.8, in the downstream-lsp-control-block's > state machine, > > State: ESTABLISHED > Event: LDP Downstream NAK > New State: ESTABLISHED > Actions It is a protocol error from the downstream LDP peer. This is correct. We have already received a Label Mapping for this LSP, hence the LSP is ESTABLISHED. If we now get a Notify for this same LSP, the downstream LSR has goofed. More over, the only way that I can associate an LSP with a Notify message is by the Label Request message ID - which I no longer have if I have received a Label Mapping (thus completing the request/response transaction). So I might have no choice but to ignore the "event". (note: not all implementations will get rid of the Label Request Message ID - even though it is not useful; hence it is not an internal error to get to this point - even if it might be silly) > > 2. in the section 3.2.2.8, in the downstream-lsp-control-block's > state machine, status ESTABLISHED, there is no actions to DOWNSTREAM LOST > event. > > Why? Assuming you are actually referring to section 3.2.3.8.3, it appears to have been left out. Oops! > I think in the environment like the following, will meet the event > DOWNSTREAM LOST > in the downstream-lsp-control-block, status ESTABLISHED: > > A -----------------------> B > LSR A and LSR B have already had an operational session, the LSP between A > and B is established. > Now we disconnect the link of A and B, so LSR A's > downstream-lsp-control-block will > receive UPSTREAM LOST,and LSR B's upstream-lsp-control-block will receive > DOWNSTREAM LOST. > So how to process it? > > Can I process it like the actions of event LDP Downstream NAK in status > RESPONSE-AWAITED? No. That would produce the protocol error addressed above. You don't send Notify messages to peers when you have sent a Label Mapping for the associated LSPs already. > And in the status ESTABLISHED there will also meet the event LDP Downstream > NAK , No. Getting a Notify message from the downstream peer that has already sent a Label Mapping should not have any effect (see above). In many implementations, it CANNOT have any effect. > How to process it? The correct way to process a downstream lost event is exactly the same as a LDP Withdraw (see toward the bottom of page 52). My suggested fix at this point is to copy the action for LDP Withdraw while changing the event to Dowstream Lost. To better understand how this works, you have to realize that the LDP Session Control state machine would pass a "Downstream Lost" event to every Downstream LSP control block associated with a lost LDP peer. This is on the harry edge of LDP specification "turf" since the session control state machine is defined there. Out of curiosity, where were you during last call? :-) > > Perhaps my point is not right, if I miss something, please let me know. > > Thanks a lot! > > Lijianping. -- Eric Gray From owner-mpls@UU.NET Fri Jan 28 00:58:42 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21369 for ; Fri, 28 Jan 2000 00:58:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzxf17853; Fri, 28 Jan 2000 05:56:08 GMT Received: by mail-control.mail.uu.net id QQhzxf09633 for mpls-outgoing; Fri, 28 Jan 2000 05:55:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzxf09628 for ; Fri, 28 Jan 2000 05:55:50 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzxf28266 for ; Fri, 28 Jan 2000 00:55:38 -0500 (EST) Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQhzxf17478 for ; Fri, 28 Jan 2000 05:55:37 GMT Received: from emailid-pc.cisco.com (beijing-dhcp-181-116.cisco.com [171.70.181.116]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id VAA11393; Thu, 27 Jan 2000 21:53:15 -0800 (PST) Message-Id: <4.1.20000128135014.00b8f950@omega.cisco.com> X-Sender: ali@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 28 Jan 2000 13:51:44 +0800 To: zhouws@publicf.bta.net.cn (zhouws), Jeremy Lawrence From: Andy Li Subject: Re: MPLS and Optical network!! Cc: In-Reply-To: <200001280300.LAA29379@ns.chinanet.cn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Redundancy :-) Today's DWDM cannot provide end2end re-routing. It also helps for bandwidth broker to sell lambda. Best Andy At 11:00 1/28/2000 +0800, zhouws wrote: >At 17:16 00-1-24 +1100, Jeremy Lawrence wrote: >>At 14:12 01/24/2000 +0800, Sheng-hung Shih wrote: >>> > In ATM MPLS network, the top-level label on a packet is applied by >>> > sending the packet on a virtual circuit with a chosen VCI. Similarly, >>> > in optical MPLS, the top-level label will be applied to a packet by >>> > sending it on a lightpath with a chosen wavelength. >>> It seems like the hop-by-hop routing,isn't it? >> >>The intended use of optical MPLS is not hop-by-hop routed MPLS, >>but explicitly routed MPLS. > >I have been wondering what issue the optical MPLS will solve? >(The only possible approach is for the future network,which will consist of >a optical core and routers at edge,and these routers are full-meshed with >optical wavelength.) > >But if the high end router could keep up with the optical bandwith >increasing,any need to add this feature on optical network? >(Another possible approach is routers interconnected fully or partial-fully >meshed via dark fibers.) > >rds >---- >zhou wanshu > > > >> >>>And the number of >>>wavelength is also a problem. >> >>Well, 80 wavelengths is enough for one router to connect to 80 >>others across an OXC network (subject to a valid route being >>available for each lightpath), so this isn't too much of a problem. >>There are rumours of OXCs coming which support 1000+ wavelengths. >> >>Regards, >> >>Jeremy Lawrence >> >> >> > > From owner-mpls@UU.NET Fri Jan 28 04:36:51 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04822 for ; Fri, 28 Jan 2000 04:36:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzxu04836; Fri, 28 Jan 2000 09:33:48 GMT Received: by mail-control.mail.uu.net id QQhzxu20285 for mpls-outgoing; Fri, 28 Jan 2000 09:33:32 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzxu20280 for ; Fri, 28 Jan 2000 09:33:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzxu12334 for ; Fri, 28 Jan 2000 04:33:08 -0500 (EST) Received: from irmgard.exp-math.uni-essen.de by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: irmgard.exp-math.uni-essen.de [132.252.150.18]) id QQhzxu04402 for ; Fri, 28 Jan 2000 09:33:08 GMT Received: from pacific (pacific.exp-math.uni-essen.de [132.252.150.214]) by irmgard.exp-math.uni-essen.de (8.9.3/8.9.3) with SMTP id KAA21770 for ; Fri, 28 Jan 2000 10:33:06 +0100 Received: by localhost with Microsoft MAPI; Fri, 28 Jan 2000 10:40:13 +0100 Message-ID: <01BF697C.0EB88C60.wu@exp-math.uni-essen.de> From: wu Reply-To: "wu@exp-math.uni-essen.de" To: "'mpls@uu.net'" Subject: MPLS header Date: Fri, 28 Jan 2000 10:40:12 +0100 Organization: iem X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Please help a new MPLS man to know that 1) Which length/format was the MPLS header specified (not label stack entry only), where to find the document? Is ARIS header 24 bytes, right? I see the TDP has 16 bytes in message "hello", is LDP similar? 2) How large is the audio/video traffic packet payload size usually in MPLS? Is it 48 octets for the compatibility, or saving fragmentation, to underlying ATM? deh-min wu IEM University Essen From owner-mpls@UU.NET Fri Jan 28 05:53:11 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05201 for ; Fri, 28 Jan 2000 05:53:11 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzxz03714; Fri, 28 Jan 2000 10:50:49 GMT Received: by mail-control.mail.uu.net id QQhzxz01543 for mpls-outgoing; Fri, 28 Jan 2000 10:50:32 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzxz01538 for ; Fri, 28 Jan 2000 10:50:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzxz16484 for ; Fri, 28 Jan 2000 05:50:21 -0500 (EST) Received: from drawbridge.ascend.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: drawbridge.ascend.com [198.4.92.1]) id QQhzxz10289 for ; Fri, 28 Jan 2000 10:50:20 GMT Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id CAA12195; Fri, 28 Jan 2000 02:40:11 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 28 Jan 2000 10:46:21 UT Received: from spud.ascend.com (spud [192.207.23.51]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id CAA06453; Fri, 28 Jan 2000 02:46:19 -0800 (PST) Received: from amalis ([152.148.173.50]) by spud.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id CAA06452; Fri, 28 Jan 2000 02:46:17 -0800 (PST) Message-Id: <4.2.2.20000128054236.018a2950@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jan 2000 05:46:04 -0500 To: bie.jiuling@mail.zhongxing.com From: "Andrew G. Malis" Subject: Re: VPN draft status query Cc: mpls@UU.NET In-Reply-To: <48256874.0012DEDC.00@mail.zhongxing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Seado, draft-muthukrishnan-corevpn-arch-00.txt has been replaced by draft-muthukrishnan-mpls-corevpn-arch-00.txt, which came out earlier this month. Regards, Andy ------- At 11:26 AM 1/28/00 +0800, bie.jiuling@mail.zhongxing.com wrote: >Hi > >Could someone tell me about current status of following drafts and anywhere >to find updated version? Files include: >draft-casey-vpn-mpls-00.txt >draft-li-mpls-vpn-00.txt >draft-heinanen-generic-vpn-mpls-00.txt >draft-jamieson-mpls-vpn-00.txt >draft-heinanen-mpls-vpn-01.txt >draft-muthukrishnan-corevpn-arch-00.txt. > >Thanks a lot! >Seado From owner-mpls@UU.NET Fri Jan 28 14:12:00 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24220 for ; Fri, 28 Jan 2000 14:11:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzzg12660; Fri, 28 Jan 2000 19:08:16 GMT Received: by mail-control.mail.uu.net id QQhzzg09250 for mpls-outgoing; Fri, 28 Jan 2000 19:07:38 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzzg09230 for ; Fri, 28 Jan 2000 19:07:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzzg11820 for ; Fri, 28 Jan 2000 14:07:19 -0500 (EST) Received: from phoebe.eim.surrey.ac.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: phoebe.eim.surrey.ac.uk [131.227.74.4]) id QQhzzg11750 for ; Fri, 28 Jan 2000 19:07:19 GMT Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by phoebe.eim.surrey.ac.uk with smtp (Exim 3.03 #1) id 12EGjl-0003eF-00 for mpls@UU.NET; Fri, 28 Jan 2000 19:07:17 +0000 Date: Fri, 28 Jan 2000 19:07:17 +0000 (GMT) From: Panos Trimintzios To: mpls@UU.NET Subject: setting ER-LSPs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi everybody, As far as I have read about the ER-LSPs they reflect the administrator's decisions/policies (right?) in order (not only) to do TE. If that is true then could someone use a management protocol (eg. SNMP) to set an ER-LSP? If yes why do we prefer signalling (CR-LDP or extendent RSVP), If not why? thanks Panos Trimintzios Centre for Communication Systems Research University of Surrey, UK From owner-mpls@UU.NET Fri Jan 28 15:48:51 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26726 for ; Fri, 28 Jan 2000 15:48:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzzm21349; Fri, 28 Jan 2000 20:44:59 GMT Received: by mail-control.mail.uu.net id QQhzzm24534 for mpls-outgoing; Fri, 28 Jan 2000 20:44:38 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzzm24529 for ; Fri, 28 Jan 2000 20:44:27 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzzm25384 for ; Fri, 28 Jan 2000 15:44:14 -0500 (EST) From: csrinivasan@tachion.com Received: from tnnt2.tachion.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQhzzm20804 for ; Fri, 28 Jan 2000 20:44:14 GMT Received: by TNNT2 with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jan 2000 15:46:33 -0500 Message-ID: <61A4353FCA87D311AE1E009027AE9AE507BACF@TNNT2> To: p.trimintzios@eim.surrey.ac.uk Cc: mpls@UU.NET Subject: RE: setting ER-LSPs Date: Fri, 28 Jan 2000 15:46:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF69D0.C2B823E8" 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_01BF69D0.C2B823E8 Content-Type: text/plain; charset="ISO-8859-1" Panos Trimintzios wrote: > As far as I have read about the ER-LSPs they reflect > the administrator's decisions/policies (right?) in > order (not only) to do TE. > If that is true then could someone use a management > protocol (eg. SNMP) to set an ER-LSP? Yes, one could use SNMP to configure the ERLSP. Please see http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-01.txt and http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-00.txt for more details. > If yes why do we prefer signalling (CR-LDP or extendent RSVP), > If not why? Even if you have decided on the path through the network, it is easier to talk to the LSR at one end of the ERLSP (via SNMP) and instruct it to set up the ERLSP via LDP/RSVP than to talk SNMP to each switch along the path. BTW, the above MIBs allow you to take both approaches. Cheenu ------_=_NextPart_001_01BF69D0.C2B823E8 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: setting ER-LSPs

Panos Trimintzios wrote:
> As far as I have read about the ER-LSPs they = reflect
> the administrator's decisions/policies (right?) = in
> order (not only) to do TE.
> If that is true then could someone use a = management
> protocol (eg. SNMP) to set an ER-LSP?

Yes, one could use SNMP to configure the ERLSP. = Please see
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te= -mib-01.txt
and
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ls= r-mib-00.txt
for more details.

> If yes why do we prefer signalling (CR-LDP or = extendent RSVP),
> If not why?

Even if you have decided on the path through the = network, it
is easier to talk to the LSR at one end of the ERLSP = (via
SNMP) and instruct it to set up the ERLSP via = LDP/RSVP than
to talk SNMP to each switch along the path. BTW, the = above
MIBs allow you to take both approaches.

Cheenu

------_=_NextPart_001_01BF69D0.C2B823E8-- From owner-mpls@UU.NET Fri Jan 28 16:42:45 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27702 for ; Fri, 28 Jan 2000 16:42:42 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzzq21732; Fri, 28 Jan 2000 21:37:42 GMT Received: by mail-control.mail.uu.net id QQhzzq05210 for mpls-outgoing; Fri, 28 Jan 2000 21:37:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQhzzq05205 for ; Fri, 28 Jan 2000 21:37:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzzq02795 for ; Fri, 28 Jan 2000 16:37:00 -0500 (EST) Received: from phoebe.eim.surrey.ac.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: phoebe.eim.surrey.ac.uk [131.227.74.4]) id QQhzzq21194 for ; Fri, 28 Jan 2000 21:36:59 GMT Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by phoebe.eim.surrey.ac.uk with smtp (Exim 3.03 #1) id 12EJ4a-0004jW-00; Fri, 28 Jan 2000 21:36:56 +0000 Date: Fri, 28 Jan 2000 21:36:56 +0000 (GMT) From: Panos Trimintzios To: csrinivasan@tachion.com cc: p.trimintzios@eim.surrey.ac.uk, mpls@UU.NET Subject: RE: setting ER-LSPs In-Reply-To: <61A4353FCA87D311AE1E009027AE9AE507BACF@TNNT2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi again, On Fri, 28 Jan 2000 csrinivasan@tachion.com wrote: > Panos Trimintzios wrote: > > As far as I have read about the ER-LSPs they reflect > > the administrator's decisions/policies (right?) in > > order (not only) to do TE. > > If that is true then could someone use a management > > protocol (eg. SNMP) to set an ER-LSP? > > Even if you have decided on the path through the network, it > is easier to talk to the LSR at one end of the ERLSP (via > SNMP) and instruct it to set up the ERLSP via LDP/RSVP than > to talk SNMP to each switch along the path. BTW, the above > MIBs allow you to take both approaches. > > Cheenu > 1. Why it is "easier" to talk to one end of ER-LSP (via SNMP) and then signal the setup, since the signaling requires (for both CR-LDP and ext-RSVP) to go all the way to the other end of the ER-LSP and then back to where it began, and possibly again notify (via SNMP) the administrator process. Is there any work that has been done to test this? Isn't more complicated to use [SNMP + (LDPorRSVP)] than to use only [SNMP]? 2. Someone could argue against the above by giving details about the "weaknesses" of SNMP (eg not suitable for real-time operations, unreliability(UDP) etc). Comming back to my original question we can see that I have asked if we could use a management protocol, not necessarily SNMP, but another more suitable, lets say XXXP (one example that comes to my mind is COPS-PR). So I repeat my argument/questions in 1. , by replacing SNMP with XXXP. Regards, Panos Trimintzios Centre for Communication Systems Research University of Surrey, UK From owner-mpls@UU.NET Fri Jan 28 17:04:48 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28066 for ; Fri, 28 Jan 2000 17:04:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzzr27269; Fri, 28 Jan 2000 21:46:51 GMT Received: by mail-control.mail.uu.net id QQhzzr06051 for mpls-outgoing; Fri, 28 Jan 2000 21:46:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzzr06046 for ; Fri, 28 Jan 2000 21:46:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzzr07667 for ; Fri, 28 Jan 2000 16:46:15 -0500 (EST) From: csrinivasan@tachion.com Received: from tnnt2.tachion.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQhzzr26791 for ; Fri, 28 Jan 2000 21:46:14 GMT Received: by TNNT2 with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jan 2000 16:48:34 -0500 Message-ID: <61A4353FCA87D311AE1E009027AE9AE507BAD2@TNNT2> To: p.trimintzios@eim.surrey.ac.uk Cc: mpls@UU.NET Subject: RE: setting ER-LSPs Date: Fri, 28 Jan 2000 16:48:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF69D9.6C58EC90" 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_01BF69D9.6C58EC90 Content-Type: text/plain; charset="ISO-8859-1" > > Panos Trimintzios wrote: > > > As far as I have read about the ER-LSPs they reflect > > > the administrator's decisions/policies (right?) in > > > order (not only) to do TE. > > > If that is true then could someone use a management > > > protocol (eg. SNMP) to set an ER-LSP? > > > > Even if you have decided on the path through the network, it > > is easier to talk to the LSR at one end of the ERLSP (via > > SNMP) and instruct it to set up the ERLSP via LDP/RSVP than > > to talk SNMP to each switch along the path. BTW, the above > > MIBs allow you to take both approaches. > > > > Cheenu > > > > 1. Why it is "easier" to talk to one end of ER-LSP (via SNMP) > and then signal the setup, since the signaling requires > (for both CR-LDP and ext-RSVP) to go all the way to the other > end of the ER-LSP and then back to where it began, and > possibly again notify (via SNMP) the administrator process. > Is there any work that has been done to test this? > Isn't more complicated to use [SNMP + (LDPorRSVP)] than to > use only [SNMP]? The amount work to be done to configure the LSRs along the path is probably the same in either case. I meant "easier" from the point of view of the one writing the network management application since invoking a signaled setup involves one SET request and talking to all the individual LSPs along the path involves multiple SETs. > 2. Someone could argue against the above by giving details > about the "weaknesses" of SNMP (eg not suitable for real-time > operations, unreliability(UDP) etc). Comming back to > my original question we can see that I have asked if we > could use a management protocol, not necessarily SNMP, > but another more suitable, lets say XXXP (one example that > comes to my mind is COPS-PR). > So I repeat my argument/questions in 1. , by replacing SNMP > with XXXP. This wasn't what I meant. Cheenu ------_=_NextPart_001_01BF69D9.6C58EC90 Content-Type: text/html; charset="ISO-8859-1" RE: setting ER-LSPs

> > Panos Trimintzios wrote:
> > > As far as I have read about the ER-LSPs they reflect
> > > the administrator's decisions/policies (right?) in
> > > order (not only) to do TE.
> > > If that is true then could someone use a management
> > > protocol (eg. SNMP) to set an ER-LSP?
> >
> > Even if you have decided on the path through the network, it
> > is easier to talk to the LSR at one end of the ERLSP (via
> > SNMP) and instruct it to set up the ERLSP via LDP/RSVP than
> > to talk SNMP to each switch along the path. BTW, the above
> > MIBs allow you to take both approaches.
> >
> > Cheenu
> >
>
> 1. Why it is "easier" to talk to one end of ER-LSP (via SNMP)
>    and then signal the setup, since the signaling requires
>    (for both CR-LDP and ext-RSVP) to go all the way to the other
>    end of the ER-LSP and then back to where it began, and
>    possibly again notify (via SNMP) the administrator process.
>    Is there any work that has been done to test this?
>    Isn't more complicated to use [SNMP + (LDPorRSVP)] than to
>    use only [SNMP]?

The amount work to be done to configure the LSRs along the path
is probably the same in either case. I meant "easier" from the
point of view of the one writing the network management application
since invoking a signaled setup involves one SET request and
talking to all the individual LSPs along the path involves
multiple SETs.

> 2. Someone could argue against the above by giving details
>    about the "weaknesses" of SNMP (eg not suitable for real-time
>    operations, unreliability(UDP) etc). Comming  back to
>    my original question we can see that I have asked if we
>    could use a management protocol, not necessarily SNMP,
>    but another more suitable, lets say XXXP (one example that
>    comes to my mind is COPS-PR).
>    So I repeat my argument/questions in 1. , by replacing SNMP
>    with XXXP.

This wasn't what I meant.

Cheenu



------_=_NextPart_001_01BF69D9.6C58EC90-- From owner-mpls@UU.NET Fri Jan 28 17:09:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28150 for ; Fri, 28 Jan 2000 17:09:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzzs08425; Fri, 28 Jan 2000 22:04:49 GMT Received: by mail-control.mail.uu.net id QQhzzs12031 for mpls-outgoing; Fri, 28 Jan 2000 22:04:19 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzzs11952 for ; Fri, 28 Jan 2000 22:04:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzzs06493 for ; Fri, 28 Jan 2000 17:04:03 -0500 (EST) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQhzzs10606 for ; Fri, 28 Jan 2000 22:04:03 GMT Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by crufty; Fri Jan 28 17:02:50 EST 2000 Received: from harlem.dnrc.bell-labs.com (harlem [135.180.161.4]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA16909; Fri, 28 Jan 2000 17:02:49 -0500 (EST) Received: from harlem (localhost [127.0.0.1]) by harlem.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA24857; Fri, 28 Jan 2000 17:02:49 -0500 (EST) Message-Id: <200001282202.RAA24857@harlem.dnrc.bell-labs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Panos Trimintzios cc: csrinivasan@tachion.com, mpls@UU.NET Subject: Re: setting ER-LSPs In-reply-to: p.trimintzios's message of Fri, 28 Jan 2000 21:36:56 +0000. X-Face: 6EzJk{'&1/p{lUq-+`;9F`/XdI~2yjDHodR2<-uPO/_~cc_x|r8$L;SD!,G-7 MV6;qA4E&14(B;h%'FID2C0tv}=sn3"{RL>A{Xe)a1)UQ>nE<5'q"X^/idKXU'cHuz!S 7Zlg(Et^=WsJ$FruR$t>Bj'K}4JkdQO)E$dm!zQEYaJn6*4UsQ(`_Sq"fh(0m%$w7X:3 -b$*!+mC%#z86 X-Organization: Helsinki, Nice, New York Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jan 2000 17:02:49 -0500 From: Petri Aukia Sender: owner-mpls@UU.NET Precedence: bulk >1. Why it is "easier" to talk to one end of ER-LSP (via SNMP) > and then signal the setup Some of the key issues for arguing for actual network protocols instead of just centralized control are a) Atomicity. In controlling the network from the core it is not as obvious how to create a path in a way that is robust against different network and device failures. It is easy to see that a trivial implementation could leave the network in an unsuitable state, given one of many modalities of failure. b) The edge initiated protocols are naturally suitable for different configurations of control, not only directed from the core, but just as well initiated by the edge, a regional mid-level entity, a protective local configuration in case of core failure, etc. For the alternative approaches, such as the regionalized control the edge initiation seems to provide a cleaner trust model. >2. Someone could argue against the above by giving details > about the "weaknesses" of SNMP Someone could, and not without merit. Peba -- Petri Aukia Room 4c-504 Lucent Technologies Tel: (732) 949 3697 101 Crawfords Corner Road, Fax: (732) 834 5379 Holmdel NJ 07733 email: peba@dnrc.bell-labs.com From owner-mpls@UU.NET Fri Jan 28 17:52:24 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28985 for ; Fri, 28 Jan 2000 17:52:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzzv03401; Fri, 28 Jan 2000 22:48:28 GMT Received: by mail-control.mail.uu.net id QQhzzv17784 for mpls-outgoing; Fri, 28 Jan 2000 22:47:59 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQhzzv17779 for ; Fri, 28 Jan 2000 22:47:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQhzzv11470 for ; Fri, 28 Jan 2000 17:47:49 -0500 (EST) Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQhzzv05732 for ; Fri, 28 Jan 2000 22:47:48 GMT Received: from pluris.com (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA08962; Fri, 28 Jan 2000 14:46:56 -0800 (PST) Message-ID: <38921C4E.C8E47384@pluris.com> Date: Fri, 28 Jan 2000 14:46:38 -0800 From: Bora Akyol X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@UU.NET, erosen@cisco.com Subject: Valid Operations on MPLS Labels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit What are valid operations that can be performed on MPLS labels? Yes sounds simple, but is it really? 1. SWAP: Lookup on incoming label, determine egress interface, outgoing label, swap labels, update TTL. 2. PUSH: Look up on incoming label, determine egress interface, swap topmost label and push one or more labels. Fix TTL in top most label. 3. POP: This is where the MPLS arch document is confusing. Assuming that Penultimate hop popping is not used: So far we know that we have to lookup on incoming label, determine operation (in this case POP), pop topmost label. If it reveals an IP packet, we do a route lookup and everything is OK. If it reveals an MPLS packet underneath, then what are valid operations that can be performed on the label that emerges after the topmost label is popped. I would like to know whether a swap or a push can follow a pop. I am willing to do another lookup on the resultant packet, but don't want to get into a recursive pop or push paradigm. Any thoughts? Bora From owner-mpls@UU.NET Fri Jan 28 18:34:38 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29655 for ; Fri, 28 Jan 2000 18:34:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQhzzy26152; Fri, 28 Jan 2000 23:30:50 GMT Received: by mail-control.mail.uu.net id QQhzzy27608 for mpls-outgoing; Fri, 28 Jan 2000 23:30:17 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQhzzy27597 for ; Fri, 28 Jan 2000 23:30:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQhzzy18902 for ; Fri, 28 Jan 2000 18:30:09 -0500 (EST) Received: from hercules by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQhzzy25598 for ; Fri, 28 Jan 2000 23:30:08 GMT Received: from pc131 by hercules (SMI-8.6/ncore-main9-99) id PAA25097; Fri, 28 Jan 2000 15:30:10 -0800 From: "Rajeev Manur" To: "'Bora Akyol'" , , Subject: RE: Valid Operations on MPLS Labels Date: Fri, 28 Jan 2000 15:30:08 -0800 Message-ID: <0F8929E5ED5FD311B892005004CED4A609DE71@tonga.ncorenetworks.com> 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: <0F8929E5ED5FD311B892005004CED4A62F27A3@tonga.ncorenetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit we could also have any combination of these like SWAP followed by a PUSH, POP followed by a SWAP POP and GO ( which is slightly different from POP ) etc. we could also have POP & PUSH ( MPLS --> IP --> MPLS ) with regards, Rajeev. Force10 Networks Santa Clara -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora Akyol Sent: Friday, January 28, 2000 2:47 PM To: mpls@UU.NET; erosen@cisco.com Subject: Valid Operations on MPLS Labels What are valid operations that can be performed on MPLS labels? Yes sounds simple, but is it really? 1. SWAP: Lookup on incoming label, determine egress interface, outgoing label, swap labels, update TTL. 2. PUSH: Look up on incoming label, determine egress interface, swap topmost label and push one or more labels. Fix TTL in top most label. 3. POP: This is where the MPLS arch document is confusing. Assuming that Penultimate hop popping is not used: So far we know that we have to lookup on incoming label, determine operation (in this case POP), pop topmost label. If it reveals an IP packet, we do a route lookup and everything is OK. If it reveals an MPLS packet underneath, then what are valid operations that can be performed on the label that emerges after the topmost label is popped. I would like to know whether a swap or a push can follow a pop. I am willing to do another lookup on the resultant packet, but don't want to get into a recursive pop or push paradigm. Any thoughts? Bora From owner-mpls@UU.NET Fri Jan 28 20:22:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00716 for ; Fri, 28 Jan 2000 20:22:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiaaf19068; Sat, 29 Jan 2000 01:18:50 GMT Received: by mail-control.mail.uu.net id QQiaaf18395 for mpls-outgoing; Sat, 29 Jan 2000 01:18:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiaaf18382 for ; Sat, 29 Jan 2000 01:18:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiaaf27095 for ; Fri, 28 Jan 2000 20:17:50 -0500 (EST) From: lijianping@mail.zhongxing.com Received: from mail.zhongxing.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) id QQiaaf18458 for ; Sat, 29 Jan 2000 01:17:41 GMT Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 48256875.00071626 ; Sat, 29 Jan 2000 09:17:24 +0800 X-Lotus-FromDomain: ZTE_LTD To: ewgray@lucent.com cc: mpls@UU.NET Message-ID: <48256875.0006F1E7.00@mail.zhongxing.com> Date: Sat, 29 Jan 2000 09:15:49 +0800 Subject: difference between propage and send Sender: owner-mpls@UU.NET Precedence: bulk Hi, In the "ldp-state-machine", there appear two word :propagate and send. Can I think it as the following? Propagate a message is: already having a message, and send it. Send a message is: construct a new message, and send it. State: ESTABLISHED Event: Internal Downstream Withdraw New State: Depends on the action routine. Actions: If it uses independent mode, set its state to `IDLE' and create a internal `LDP Request' and send to its own state machine. Else Disconnect the upstream label from the downstream label. Propagate the LDP-WITHDRAW upstream and go to state `RELEASE_AWAITED'. Send the event `Internal Destroy' to the Next_Hop_Trigger_Block's state machine if the LSR was in the middle of switching over to the better next hop. State: ESTABLISHED Event: Internal Downstream NAK New State: Depends on the action routine. Actions: If it uses independent mode, set its state to `IDLE' and create a internal `LDP Request' and send to its own state machine. Else Disconnect the upstream label from the downstream label Send an LDP-WITHDRAW upstream and go to state `RELEASE_AWAITED'. Send the event `Internal Destroy' to the Next_Hop_Trigger_Block's state machine if the LSR was in the middle of switching over to the better next hop. Any marks is apperatiated. Thanks! Lijianping. From owner-mpls@UU.NET Fri Jan 28 22:45:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03720 for ; Fri, 28 Jan 2000 22:45:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiaao27291; Sat, 29 Jan 2000 03:38:10 GMT Received: by mail-control.mail.uu.net id QQiaao10250 for mpls-outgoing; Sat, 29 Jan 2000 03:37:38 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiaao10245 for ; Sat, 29 Jan 2000 03:37:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiaao01887 for ; Fri, 28 Jan 2000 22:37:18 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQiaao26769 for ; Sat, 29 Jan 2000 03:37:18 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id WAA11938; Fri, 28 Jan 2000 22:37:17 -0500 Date: Fri, 28 Jan 2000 22:37:17 -0500 From: "J. Noel Chiappa" Message-Id: <200001290337.WAA11938@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: Re: MPLS and Optical network!! Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Jeremy Lawrence >> And the number of wavelength is also a problem. > Well, 80 wavelengths is enough for one router to connect to 80 > others across an OXC network (subject to a valid route being available > for each lightpath), so this isn't too much of a problem. There are > rumours of OXCs coming which support 1000+ wavelengths. Yes, but to connect each of 80 routers to each of 80 others takes (if I remember the equation right) (N * (N-1))/2 total connections, or over 3000 virtual links. And the number gets much bigger very quickly (e.g. 100 takes almost 5000 - it *is* an exponential). Now, depending on the exact topology of the connectivity mesh of fibers and OXC switches between them, some of those virtual links can be carried on the same wavelength, since no parts of the paths of the two (or more) of them will be congruent (and exactly how many depends on the topology). So that will reduce the total number of wavelength you need to provide all N^2 (roughly) virtual links. Still, it's going to be a significant number. In other words, modelling (at the internetwork layer) an OXC substrate as a giant Ethernet, where every device connected to it can talk directl to every other device connected to it, doesn't really work as the OXC substrate gets larger. (Which is sort of related to one of my favourite rants, about why you really want to have route selection at the internetwork layer only, but let's skip that rathole.) What exactly will work? Hmm, good question.... Noel From owner-mpls@UU.NET Sat Jan 29 00:49:14 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04897 for ; Sat, 29 Jan 2000 00:49:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiaaw19176; Sat, 29 Jan 2000 05:40:09 GMT Received: by mail-control.mail.uu.net id QQiaaw00942 for mpls-outgoing; Sat, 29 Jan 2000 05:39:38 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiaaw00937 for ; Sat, 29 Jan 2000 05:39:26 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiaaw12569 for ; Sat, 29 Jan 2000 00:39:23 -0500 (EST) Received: from ice.ip.qwest.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ice.ip.qwest.net [216.111.66.200]) id QQiaaw18659 for ; Sat, 29 Jan 2000 05:39:22 GMT Received: from ice.ip.qwest.net (localhost [127.0.0.1]) by ice.ip.qwest.net (8.9.3/8.9.3) with ESMTP id WAA09932 for ; Fri, 28 Jan 2000 22:42:23 -0700 (MST) Message-Id: <200001290542.WAA09932@ice.ip.qwest.net> X-Mailer: exmh version 2.0.2 2/24/98 To: mpls@UU.NET From: Danny McPherson Reply-To: danny@ice.ip.qwest.net Subject: Re: MPLS and Optical network!! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jan 2000 22:42:23 -0700 Sender: owner-mpls@UU.NET Precedence: bulk > Yes, but to connect each of 80 routers to each of 80 others takes (if I > remember the equation right) (N * (N-1))/2 total connections, or over 3000 > virtual links. And the number gets much bigger very quickly (e.g. 100 takes > almost 5000 - it *is* an exponential). and then came hierarchy and spatial reuse. > Now, depending on the exact topology of the connectivity mesh of fibers and > OXC switches between them, some of those virtual links can be carried on the > same wavelength, since no parts of the paths of the two (or more) of them will > be congruent (and exactly how many depends on the topology). So that will > reduce the total number of wavelength you need to provide all N^2 (roughly) > virtual links. Still, it's going to be a significant number. Ahh, and this would require some type of intelligent connection management and calculations to setup the required protect path, _when it's required. > In other words, modelling (at the internetwork layer) an OXC substrate as a > giant Ethernet, where every device connected to it can talk directl to every > other device connected to it, doesn't really work as the OXC substrate gets > larger. Nesting of lightpaths, that's interesting. I think spatial reuse of wavelengths will have to suffice for now, though, as suggested above, providing shared-path protection for backup connections would certainly be more capacity efficient than dedicated-path protection alone. Though this would require a bit of engineering in order to ensure complete diversity of wavelengths sharing a path, and assume accommodation of only a single failure .. unless some [more intelligent mechanism] were able to accommodate multiple failures, if alternative routes/capacity were available. > (Which is sort of related to one of my favourite rants, about why you really > want to have route selection at the internetwork layer only, but let's skip > that rathole.) The proposal(s) I've seen only deal with "automation" of connection management for lightpath (no opto-electronic conversions) and optical signal termination. It's done today, just offline, and arguably, less efficiently. -danny From owner-mpls@UU.NET Sat Jan 29 07:50:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18725 for ; Sat, 29 Jan 2000 07:50:05 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiabz00093; Sat, 29 Jan 2000 12:46:12 GMT Received: by mail-control.mail.uu.net id QQiabz15571 for mpls-outgoing; Sat, 29 Jan 2000 12:45:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiabz15566 for ; Sat, 29 Jan 2000 12:45:21 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiabz02420 for ; Sat, 29 Jan 2000 07:45:12 -0500 (EST) Received: from mail.xandl.cso.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.xandl.cso.net [194.106.242.34]) id QQiabz05573 for ; Sat, 29 Jan 2000 12:45:11 GMT Received: from amarhold ([194.106.242.46]) by mail.xandl.cso.net (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100) with SMTP id AAA259; Sat, 29 Jan 2000 13:50:32 +0100 Reply-To: From: "Alexander Marhold" To: "'J. Noel Chiappa'" , Subject: RE: MPLS and Optical network!! Date: Sat, 29 Jan 2000 13:44:51 +0100 Message-ID: <000701bf6a56$a42604f0$2ef26ac2@amarhold.cisco.com> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <200001290337.WAA11938@ginger.lcs.mit.edu> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit > > Well, 80 wavelengths is enough for one router to connect to 80 > > others across an OXC network (subject to a valid route > being available > > for each lightpath), so this isn't too much of a > problem. There are > > rumours of OXCs coming which support 1000+ wavelengths. > > Yes, but to connect each of 80 routers to each of 80 others > takes (if I > remember the equation right) (N * (N-1))/2 total connections, > or over 3000 > virtual links. And the number gets much bigger very quickly > (e.g. 100 takes > almost 5000 - it *is* an exponential). Well that was also my first thought and I also wanted to immediately answer,BUT Label merge --- which is done in MPLs and 80 wavelengths (labels) PER INTERFACE in the OXC means that every router can have up to 80 LSPīs reachable via each of its interfaces. MPLS overcomes the underlying any-to-any-connectivity a normal Layer 2 has. And the wavelength is only the outer most label, i.e. labels designating forwarding to a certain interface which is done in MPLS-VPN do not need to be included in that calculation. So IMHO with 80 labels you can build up quite a usable optical Core with best regards Alexander __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ __/ __/ Dipl.Ing. Alexander Marhold MBA __/ CCIE #3324, CCNP, CCNA, CCDP, CCDA, CCSI #20642 __/ PRO IN __/ Mobile: ++43-(0)664-16 28 234 __/ From owner-mpls@UU.NET Sat Jan 29 09:34:25 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19918 for ; Sat, 29 Jan 2000 09:34:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiacg18102; Sat, 29 Jan 2000 14:31:33 GMT Received: by mail-control.mail.uu.net id QQiacg06015 for mpls-outgoing; Sat, 29 Jan 2000 14:31:00 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiacg05998 for ; Sat, 29 Jan 2000 14:30:47 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiacg07925 for ; Sat, 29 Jan 2000 09:30:41 -0500 (EST) Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQiacg22756 for ; Sat, 29 Jan 2000 14:30:40 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id QAA17788; Sat, 29 Jan 2000 16:30:38 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <14482.63886.10694.336710@lohi.eng.telia.fi> Date: Sat, 29 Jan 2000 16:30:38 +0200 (EET) To: Cc: "'J. Noel Chiappa'" , Subject: RE: MPLS and Optical network!! In-Reply-To: <000701bf6a56$a42604f0$2ef26ac2@amarhold.cisco.com> References: <200001290337.WAA11938@ginger.lcs.mit.edu> <000701bf6a56$a42604f0$2ef26ac2@amarhold.cisco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA19918 Alexander Marhold writes: > Label merge --- which is done in MPLs and 80 wavelengths (labels) PER > INTERFACE in the OXC means > that every router can have up to 80 LSPīs reachable via each of its > interfaces. how do you merge wavelenghts? -- juha From owner-mpls@UU.NET Sat Jan 29 09:36:13 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19932 for ; Sat, 29 Jan 2000 09:36:12 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiacf15664; Sat, 29 Jan 2000 14:26:33 GMT Received: by mail-control.mail.uu.net id QQiacf05882 for mpls-outgoing; Sat, 29 Jan 2000 14:26:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiacf05868 for ; Sat, 29 Jan 2000 14:25:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiacf07697 for ; Sat, 29 Jan 2000 09:25:32 -0500 (EST) Received: from qhars002.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19]) id QQiacf15054 for ; Sat, 29 Jan 2000 14:25:32 GMT Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Sat, 29 Jan 2000 14:25:20 +0000 Received: from zvb1c004.corpemea.baynetworks.com (ZVB1C004 [141.251.160.84]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DY9XYPJN; Sat, 29 Jan 2000 14:25:21 -0000 Received: from nortelnetworks.com (LANDERSS2 [141.251.192.176]) by zvb1c004.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DBYCYL8H; Sat, 29 Jan 2000 15:25:16 +0100 Message-ID: <3892F703.57B493C7@nortelnetworks.com> Date: Sat, 29 Jan 2000 15:19:47 +0100 From: "Loa Andersson" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Alexander.Marhold@xandl.cso.net CC: "'J. Noel Chiappa'" , mpls@UU.NET Subject: Re: MPLS and Optical network!! References: <000701bf6a56$a42604f0$2ef26ac2@amarhold.cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Alexander Marhold wrote: [... snip ...] > Label merge --- which is done in MPLs and 80 wavelengths (labels) PER > INTERFACE in the OXC means > that every router can have up to 80 LSPīs reachable via each of its > interfaces. > > MPLS overcomes the underlying any-to-any-connectivity a normal Layer 2 has. True enough, if you can make it happen. Can you give a hint on how you do the label mergining - OEO, swapping the labels in optics, ... ? > > And the wavelength is only the outer most label, i.e. labels designating > forwarding to a certain interface which is done in MPLS-VPN do not need to > be included in that calculation. > > So IMHO with 80 labels you can build up quite a usable optical Core Yes, a useful optical core given that you have a couple of "minor" problems solved. > > with best regards > > Alexander /Loa -- Loa Andersson Regional Director, EMEA St Eriksgatan 115A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 e-mail: loa.andersson@nortelnetworks.com From owner-mpls@UU.NET Sat Jan 29 10:29:13 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20547 for ; Sat, 29 Jan 2000 10:29:13 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiaci08174; Sat, 29 Jan 2000 15:14:57 GMT Received: by mail-control.mail.uu.net id QQiaci15328 for mpls-outgoing; Sat, 29 Jan 2000 15:14:21 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiaci15321 for ; Sat, 29 Jan 2000 15:14:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiaci12597 for ; Sat, 29 Jan 2000 10:14:01 -0500 (EST) Received: from mail.xandl.cso.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.xandl.cso.net [194.106.242.34]) id QQiaci12545 for ; Sat, 29 Jan 2000 15:13:56 GMT Received: from amarhold ([194.106.242.46]) by mail.xandl.cso.net (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100) with SMTP id AAA143; Sat, 29 Jan 2000 16:19:23 +0100 Reply-To: From: "Alexander Marhold" To: "'Loa Andersson'" Cc: "'J. Noel Chiappa'" , , "Juha Heinanen (E-mail)" Subject: RE: MPLS and Optical network!! Date: Sat, 29 Jan 2000 16:13:44 +0100 Message-ID: <000801bf6a6b$704554a0$2ef26ac2@amarhold.cisco.com> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <3892F703.57B493C7@nortelnetworks.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit > Alexander Marhold wrote: > [... snip ...] > > > Label merge --- which is done in MPLs and 80 wavelengths > (labels) PER > > INTERFACE in the OXC means > > that every router can have up to 80 LSPīs reachable via each of its > > interfaces. > > > > MPLS overcomes the underlying any-to-any-connectivity a > normal Layer 2 has. > > True enough, if you can make it happen. Can you give a hint on how you > do > the label mergining - OEO, swapping the labels in optics, ... ? > > my point of view is the following start: - the labelled packet enters the optical core with label A and thus wavelength l1 on each switch: - the optical packet will be forwarded according to outgoing interface and a wavelength l2 (note that in these intermediate hops the wavelength and the labelheader within the transported frame does not match) optical egress: - the packet arrives with a wavelength of l5: as the egress knows the label correspondent to the wavelength l5 the packets will be forwarded with a new label given by the optical egress router It is very clear that no label Push or Pop can be done in the optical core So for me the operation is pretty similar to MPLS over ATM But if I missed something important pls let me know regards Alexander From owner-mpls@UU.NET Sat Jan 29 10:46:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20783 for ; Sat, 29 Jan 2000 10:46:46 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiack22356; Sat, 29 Jan 2000 15:44:53 GMT Received: by mail-control.mail.uu.net id QQiack16783 for mpls-outgoing; Sat, 29 Jan 2000 15:44:21 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiack16778 for ; Sat, 29 Jan 2000 15:44:17 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiack14321 for ; Sat, 29 Jan 2000 10:43:59 -0500 (EST) Received: from qhars002.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19]) id QQiack26398 for ; Sat, 29 Jan 2000 15:43:59 GMT Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Sat, 29 Jan 2000 15:43:34 +0000 Received: from zvb1c004.corpemea.baynetworks.com (ZVB1C004 [141.251.160.84]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DY9XYQQF; Sat, 29 Jan 2000 15:43:35 -0000 Received: from nortelnetworks.com (LANDERSS2 [141.251.192.176]) by zvb1c004.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DBYCYL88; Sat, 29 Jan 2000 16:43:29 +0100 Message-ID: <38930958.64DEA199@nortelnetworks.com> Date: Sat, 29 Jan 2000 16:38:00 +0100 From: "Loa Andersson" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Alexander.Marhold@xandl.cso.net CC: "Loa Andersson" , "'J. Noel Chiappa'" , mpls@UU.NET, "Juha Heinanen (E-mail)" Subject: Re: MPLS and Optical network!! References: <000801bf6a6b$704554a0$2ef26ac2@amarhold.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alexander, in what you describe everything sent on wavelength l1 at the ingress will show up on wavelength l5 at the egress. You are back at the original problem (N*N "connections" to connect N egress point to N ingress points). And you haven't done any wavelength merging. /Loa Alexander Marhold wrote: > > my point of view is the following > > start: > - the labelled packet enters the optical core with label A and thus > wavelength l1 > on each switch: > - the optical packet will be forwarded according to outgoing interface and a > wavelength l2 > (note that in these intermediate hops the wavelength and the labelheader > within the transported frame does not match) > optical egress: > - the packet arrives with a wavelength of l5: > as the egress knows the label correspondent to the wavelength l5 > the packets will be forwarded with a new label given by the optical egress > router > > It is very clear that no label Push or Pop can be done in the optical core > > So for me the operation is pretty similar to MPLS over ATM > > But if I missed something important pls let me know > > regards > Alexander -- Loa Andersson Regional Director, EMEA St Eriksgatan 115A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 e-mail: loa.andersson@nortelnetworks.com From owner-mpls@UU.NET Sat Jan 29 11:38:28 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21305 for ; Sat, 29 Jan 2000 11:38:28 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiacm07698; Sat, 29 Jan 2000 16:08:16 GMT Received: by mail-control.mail.uu.net id QQiacm25404 for mpls-outgoing; Sat, 29 Jan 2000 16:08:01 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiacm25395 for ; Sat, 29 Jan 2000 16:07:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiacm13257 for ; Sat, 29 Jan 2000 11:07:42 -0500 (EST) Received: from alemail1.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [192.11.221.161]) id QQiacm07295 for ; Sat, 29 Jan 2000 16:07:42 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA24747 for ; Sat, 29 Jan 2000 11:07:42 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA24743; Sat, 29 Jan 2000 11:07:41 -0500 (EST) Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA15340; Sat, 29 Jan 2000 11:07:41 -0500 (EST) Message-ID: <38931002.A9F7C484@lucent.com> Date: Sat, 29 Jan 2000 11:06:26 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Alexander.Marhold@xandl.cso.net, "'J. Noel Chiappa'" , mpls@UU.NET Subject: Re: MPLS and Optical network!! References: <200001290337.WAA11938@ginger.lcs.mit.edu> <000701bf6a56$a42604f0$2ef26ac2@amarhold.cisco.com> <14482.63886.10694.336710@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yes, you can't merge with pure analog wavelengths, However with O-E-O, think of four OC48 multiplexed into one OC192. Yangguang > > how do you merge wavelenghts? > > -- juha From owner-mpls@UU.NET Sat Jan 29 11:54:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21361 for ; Sat, 29 Jan 2000 11:54:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiacp21652; Sat, 29 Jan 2000 16:47:37 GMT Received: by mail-control.mail.uu.net id QQiacp27459 for mpls-outgoing; Sat, 29 Jan 2000 16:47:05 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiacp27453 for ; Sat, 29 Jan 2000 16:47:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiacp15423 for ; Sat, 29 Jan 2000 11:46:57 -0500 (EST) Received: from mail.xandl.cso.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.xandl.cso.net [194.106.242.34]) id QQiacp21210 for ; Sat, 29 Jan 2000 16:46:57 GMT Received: from amarhold ([194.106.242.46]) by mail.xandl.cso.net (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100) with SMTP id AAA246; Sat, 29 Jan 2000 17:52:27 +0100 Reply-To: From: "Alexander Marhold" To: "'Loa Andersson'" Cc: Subject: RE: MPLS and Optical network!! Date: Sat, 29 Jan 2000 17:46:46 +0100 Message-ID: <000001bf6a78$70bc9490$2ef26ac2@amarhold.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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <38930958.64DEA199@nortelnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Alexander, > > in what you describe everything sent on wavelength l1 at the ingress > will show up on wavelength l5 at the egress. You are back at the > original problem (N*N "connections" to connect N egress point to > N ingress points). And you haven't done any wavelength merging. > No, what I meant but did not describe well is that at every hop labels for the specific egress will be merged as is done in ATM with vc-merge prerequiste is a per interface label-space (wavelength space)) so l5 is the wavelength (label) for all packets going to that egress independent of where it came from, as I assume that to be a pure destination based core. so what the OXC would have to do: Step 1: get a packet with wavelength l4 on interface 1 Step 2: he knows that this will be forwarded as l5 on interface 2 step 3: convert wavelength of packet to l5 Step 4a: if outgoing interface and wavelength is free ---> send Step 4b: if outgoing interface is used, mirror packet in an optical queue and goto Step 3a But what seems to be my wrong assumption is that currently there is no OXC which can convert wavelengths on the fly between input and output interface, whereas delaying an optical packet until the output interface and wavelength is free seems to be possible at least in an engineering state. Can eventually someone more knowledgeable on optical tell me how far (in months or years) my "vision" of an OXC with above described steps and capabilities is away so I apologize for the possible confusion on the discussion regards Alexander From owner-mpls@UU.NET Sat Jan 29 12:06:00 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21486 for ; Sat, 29 Jan 2000 12:05:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiacp26923; Sat, 29 Jan 2000 16:58:56 GMT Received: by mail-control.mail.uu.net id QQiacp27849 for mpls-outgoing; Sat, 29 Jan 2000 16:58:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiacp27842 for ; Sat, 29 Jan 2000 16:58:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiacp18444 for ; Sat, 29 Jan 2000 11:58:15 -0500 (EST) Received: from ns.psi.calva.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ns.psi.calva.net [195.134.198.2]) id QQiacp00727 for ; Sat, 29 Jan 2000 16:58:15 GMT Received: from jc (jc-mac.planete.net [194.2.222.120]) by ns.psi.calva.net (8.8.6/8.8.6) with ESMTP id RAA26077; Sat, 29 Jan 2000 17:56:04 +0100 (MET) Message-Id: <4.2.2.20000129175206.00cd4160@pop.calvacom.fr> X-Sender: caronj@pop.calvacom.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 29 Jan 2000 17:55:49 +0100 To: From: Jacques Caron Subject: RE: MPLS and Optical network!! Cc: "'Loa Andersson'" , In-Reply-To: <000001bf6a78$70bc9490$2ef26ac2@amarhold.cisco.com> References: <38930958.64DEA199@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, In my opinion, what you are describing is a frame/packet switch that supports multiple wavelengths, not an OXC. The former buffers packets/frames before (queuing and) resending them (like a router or a FR switch or an ATM switch doing VC-merge). The latter just changes wavelength of the signal, so there is no latency, and very minimal "intelligence". And probably better scalability to higher speeds and/or number of wavelengths. Jacques. At 17:46 29/01/00 , Alexander Marhold wrote: > > Alexander, > > > > in what you describe everything sent on wavelength l1 at the ingress > > will show up on wavelength l5 at the egress. You are back at the > > original problem (N*N "connections" to connect N egress point to > > N ingress points). And you haven't done any wavelength merging. > > >No, what I meant but did not describe well is that at every hop labels for >the specific egress will be merged as is done in ATM with vc-merge > prerequiste is a per interface label-space (wavelength space)) >so l5 is the wavelength (label) for all packets going to that egress >independent of where it came from, as I assume that to be a pure destination >based core. > >so what the OXC would have to do: >Step 1: get a packet with wavelength l4 on interface 1 >Step 2: he knows that this will be forwarded as l5 on interface 2 >step 3: convert wavelength of packet to l5 >Step 4a: if outgoing interface and wavelength is free ---> send >Step 4b: if outgoing interface is used, mirror packet in an optical queue >and goto Step 3a > >But what seems to be my wrong assumption is that currently there is no OXC >which can convert wavelengths on the fly between input and output interface, >whereas delaying an optical packet until the output interface and wavelength >is free seems to be possible at least in an engineering state. > >Can eventually someone more knowledgeable on optical tell me how far (in >months or years) my "vision" of an OXC with above described steps and >capabilities is away > >so I apologize for the possible confusion on the discussion > >regards > >Alexander --- Jacques Caron PSINetworks Europe Network Engineer PSINet Europe Regional Peering Coordinator Planete.net IT Manager Mail: 8/10 rue Nieuport - 78140 Velizy - France Phone: +33 (0)1 34 63 19 71 - Fax: +33 (0)1 34 63 19 51 From owner-mpls@UU.NET Sat Jan 29 12:12:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21510 for ; Sat, 29 Jan 2000 12:12:54 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiacq07073; Sat, 29 Jan 2000 17:11:56 GMT Received: by mail-control.mail.uu.net id QQiacq06052 for mpls-outgoing; Sat, 29 Jan 2000 17:11:25 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiacq06047 for ; Sat, 29 Jan 2000 17:11:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiacq16770 for ; Sat, 29 Jan 2000 12:11:18 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQiacq02798 for ; Sat, 29 Jan 2000 17:11:18 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA18994 for ; Sat, 29 Jan 2000 12:11:18 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA18988; Sat, 29 Jan 2000 12:11:17 -0500 (EST) Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA20783; Sat, 29 Jan 2000 12:11:16 -0500 (EST) Message-ID: <38931EEA.82F840D1@lucent.com> Date: Sat, 29 Jan 2000 12:10:02 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Alexander.Marhold@xandl.cso.net CC: "'Loa Andersson'" , mpls@UU.NET Subject: Re: MPLS and Optical network!! References: <000001bf6a78$70bc9490$2ef26ac2@amarhold.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > But what seems to be my wrong assumption is that currently there is no OXC > which can convert wavelengths on the fly between input and output interface, > whereas delaying an optical packet until the output interface and wavelength > is free seems to be possible at least in an engineering state. > Optical packet? do you mean checking, buffering packets in analog domain? There are some research going on this path. However, for commercial usage, I think at least 5-10 years away. OXC is still the old circuit switch idea. So far, no packet forwarding look-up is done on fly for each packet. I surely hope it will do. Yangguang From owner-mpls@UU.NET Sat Jan 29 18:36:53 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24281 for ; Sat, 29 Jan 2000 18:36:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiadq27535; Sat, 29 Jan 2000 23:35:17 GMT Received: by mail-control.mail.uu.net id QQiadq10121 for mpls-outgoing; Sat, 29 Jan 2000 23:34:46 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiadq10114 for ; Sat, 29 Jan 2000 23:34:26 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiadq10940 for ; Sat, 29 Jan 2000 18:34:22 -0500 (EST) Received: from qhars002.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19]) id QQiadq02121 for ; Sat, 29 Jan 2000 23:34:22 GMT Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Sat, 29 Jan 2000 23:34:09 +0000 Received: from zvb1c004.corpemea.baynetworks.com (ZVB1C004 [141.251.160.84]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DY9XYW94; Sat, 29 Jan 2000 23:34:08 -0000 Received: from nortelnetworks.com (LANDERSS2 [141.251.192.168]) by zvb1c004.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DBYCYL97; Sun, 30 Jan 2000 00:34:06 +0100 Message-ID: <389377A2.F0F9C75C@nortelnetworks.com> Date: Sun, 30 Jan 2000 00:28:34 +0100 From: "Loa Andersson" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Yangguang Xu CC: Juha Heinanen , Alexander.Marhold@xandl.cso.net, "'J. Noel Chiappa'" , mpls@UU.NET Subject: Re: MPLS and Optical network!! References: <200001290337.WAA11938@ginger.lcs.mit.edu> <000701bf6a56$a42604f0$2ef26ac2@amarhold.cisco.com> <14482.63886.10694.336710@lohi.eng.telia.fi> <38931002.A9F7C484@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I thought that what Alexander wanted to do was to get away from the OEO, if for no other reason because it is expensive. /Loa Yangguang Xu wrote: > > Yes, you can't merge with pure analog wavelengths, However with O-E-O, think of > four OC48 multiplexed into one OC192. > > Yangguang > > > > > how do you merge wavelenghts? > > > > -- juha -- Loa Andersson Regional Director, EMEA St Eriksgatan 115A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 e-mail: loa.andersson@nortelnetworks.com From owner-mpls@UU.NET Sat Jan 29 23:21:20 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27850 for ; Sat, 29 Jan 2000 23:21:16 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiaej15125; Sun, 30 Jan 2000 04:20:18 GMT Received: by mail-control.mail.uu.net id QQiaej01994 for mpls-outgoing; Sun, 30 Jan 2000 04:20:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiaej01979 for ; Sun, 30 Jan 2000 04:19:59 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiaej29184 for ; Sat, 29 Jan 2000 23:19:43 -0500 (EST) Received: from siroccosystems.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gatekeeper.siroccosystems.com [38.149.123.2]) id QQiaej14678 for ; Sun, 30 Jan 2000 04:19:42 GMT Received: by gatekeeper.siroccosystems.com id <115201>; Sat, 29 Jan 2000 23:26:33 -0500 Message-Id: <00Jan29.232633est.115201@gatekeeper.siroccosystems.com> From: Richard Barnett To: "'mpls@uu.net'" Subject: MPLS and Optical Networks MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 29 Jan 2000 23:26:27 -0500 Sender: owner-mpls@UU.NET Precedence: bulk It would seem that to be able to use a passive optical core (i.e. no O-E-O conversions) as a scalable interconnect, it probably needs to exhibit the following characteristics: - Dynamic switching capability (i.e. data units such as packets and cells are individually routed in the optical domain). This is likely to be optical TDM but would ideally be based on packet/frame/cell header information. - Wavelength interchange capability. - Some form of optical switch forming an optical cross-connect. Unfortunately, OTDM wavelength interchanging cross-connects are not going to be available for a little while. In the absence of such devices, passive optical networks will probably behave more like flexible leased lines that could be used to interconnect host devices and routers/switches albeit with known scalability issues. In this context, it may be that extending MPLS to the enterprise would have considerable relevance as it would allow the enterprise routers/switches to implement policy-based routing and then choose the appropriate LSP for transit to the optical edge device. The optical edge device could then map the LSP to the appropriate outgoing lambda to cross the optical core to the target router/switch. These router/switches are then themselves interconnected across the optical core via LSPs to form a virtual network topology on top of the optical network. The use of routers/switches in this way should solve the scalability issues until such time as more capable optical cores can be deployed. Richard. ------------------------------------------------------------- Richard Barnett VP of System Architecture, Sirocco Systems. Tel: 203 269 9919 x 126 Fax: 203 269 8291 Email: richard.barnett@siroccosystems.com From owner-mpls@UU.NET Sun Jan 30 11:43:41 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09763 for ; Sun, 30 Jan 2000 11:43:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiagg15960; Sun, 30 Jan 2000 16:42:40 GMT Received: by mail-control.mail.uu.net id QQiagg08404 for mpls-outgoing; Sun, 30 Jan 2000 16:42:08 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiagg08394 for ; Sun, 30 Jan 2000 16:41:49 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiagg10026; Sun, 30 Jan 2000 11:41:43 -0500 (EST) Received: from mail.cs.tsinghua.edu.cn by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cs.tsinghua.edu.cn [166.111.68.3]) id QQiagg10671; Sun, 30 Jan 2000 16:41:40 GMT Received: from s1000e.cs.tsinghua.edu.cn ([166.111.68.50]) by mail.cs.tsinghua.edu.cn (Netscape Mail Server v2.02) with SMTP id AAA272; Fri, 28 Jan 2000 12:25:31 +0800 Received: from 166.111.10.188 by s1000e.cs.tsinghua.edu.cn (SMI-8.6/SMI-SVR4) id LAA17777; Fri, 28 Jan 2000 11:27:36 +0800 Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by mx8.263.net (Postfix) with ESMTP id BCCEF1C6CC582; Tue, 18 Jan 2000 08:03:33 +0800 (CST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02211; Mon, 17 Jan 2000 18:08:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02136 for ; Mon, 17 Jan 2000 18:05:56 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10032 for ; Mon, 17 Jan 2000 18:06:00 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Jan 17 18:05:18 EST 2000 Received: from dnrc.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA23758; Mon, 17 Jan 2000 18:05:17 -0500 (EST) Message-ID: <38839FD3.34430465@dnrc.bell-labs.com> Date: Mon, 17 Jan 2000 18:03:47 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: Ping Pan , RSVP , mpls , diffserv , te-wg , Henning Schulzrinne , Ellen Hahne References: <200001172049.PAA24260@anchor.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: A new draft on inter-domain level resource management X-Mailman-Version: 1.0 List-Id: X-BeenThere: diffserv@ietf.org Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > > You should be clear in your discussions of BGRP what problem it is you > are trying to solve. BGRP is trying to solve the scalability problems > that arrise when using MPLS for microflows. This is what is commonly > referred to as QoS routing. > Hi, Curtis, BGRP is not a routing protocol. It uses the information provided by BGP4 (specifically, AS_PATH and NEXT_HOP attributes) to set up reservation trunks in the backbone. First, it involves only with BGP border routers. Second, it further reduces the number of "flows" a border router has to maintain. I think QoS routing is to periodically advertise link/resource information throughout the network, which is not really what we are targeting here. Sorry about the confusion. > [ aside: > > This is why I have insisted that we not confuse the term "QoS routing" > with "traffic engineering". The two have similarities, but some very > significant differences. Traffic engineeering as it is currently > practiced by ISPs is not concerned with microflows (even very large > ones) and in a stable network would be expected to generate zero > setups despite huge numbers (could be hundreds of thousands or > millions) of microflows appearing and going away per second. > For traffic engineering, there could be many long-lived "flows" that established by the ISP's. The cost of setting them up in terms of processing CPU cycles and storage space may not be a big deal, but the cost of maintain these "flows" may be a big problem for the routers. Soft-state is a good idea to allow the routers to adjust to route changes. But the side-effect here is that soft-state requires the routers to maintain a copy of all the states. If there are thousands or millions of microflows that need to refresh, I doubt the routers can sustain the CPU cost. > For traffic engineered backbones, the total number of LSPs is bounded > by the number of LSRs in the network and the number of classes of > service offerred. Most providers estimate the total number of LSPs > that will be needed in their network to be on the order of 10^3 or > 10^4. The number going through any one LSR should be even smaller. > The setup rate should normally be zero or very close to zero except in > response to network failure. Actually, as being pointed out in RFC2430 (PASTE by Tony Li and Yokov Rekhter), the number of trunks (or LSP's, or reservations) is N * (N-1) * C, where C is the number of service classes, N is the number of MPLS-speaking routers. This is the N**2 problem we are talking about here. In case of intra-domain, N is the number of border routers at backbone edge, and is in the range of ~100. To setup a full-meshed network to support traffic engineering, the ISP needs indeed 10^3 or 10^4 trunks. The current RSVP/LDP should have no problem for intra-domain. But to setup such trunks over multiple domains, we will have problem here. As pointed out in our draft, we have thousands of AS's and routes over the network. To provide a similar level of traffic engineering functionality in multi-domain environment would require millions of trunks. We proposed a new protocol here to provide trunk setup mechanism for inter-domain only. When routers use BGRP to setup inter-domain trunks, the border routers will interface with intra-domain signaling protocols to set up internal trunks. BGRP is hopping between the border routers to trigger LSP setups. > > Some of those estimating higher than 10^4 LSPs tend to be interested > in voice and counting on doing one LSP per T1 voice trunk (not even > aggregating to trunk group) rather than engineering IP networks. > Those who believe that MPLS traffic engineering should be used solely > to provide more efficient routing through provider backbones may > consider this broken by design (though it may be essential to some > VoMPLS approaches, not that it would be the first time something > broken by design was proposed within or outside the IETF). > IMHO, I hope the ISP's consider traffic in terms of service classes and bandwidth only (as being defined in DiffServ), not in terms of application. The end users at network edge can choose any service class to carry their voice depending on how much they are willing to pay. > ... end of aside] > > > A question for the MPLS WG is "is this a problem the MPLS WG is trying > to solve?" Perhaps the MPLS deployment WG in the OPs area can help > provide an answer. > I have the same question. That's why I send the note to multiple lists. ;-) > Curtis Regards, -- Ping Pan http://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-mpls@UU.NET Sun Jan 30 11:43:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09775 for ; Sun, 30 Jan 2000 11:43:55 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiagg16672; Sun, 30 Jan 2000 16:43:24 GMT Received: by mail-control.mail.uu.net id QQiagg08444 for mpls-outgoing; Sun, 30 Jan 2000 16:42:47 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiagg08424 for ; Sun, 30 Jan 2000 16:42:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiagg10085; Sun, 30 Jan 2000 11:42:24 -0500 (EST) Received: from mail.cs.tsinghua.edu.cn by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cs.tsinghua.edu.cn [166.111.68.3]) id QQiagg11161; Sun, 30 Jan 2000 16:42:21 GMT Received: from s1000e.cs.tsinghua.edu.cn ([166.111.68.50]) by mail.cs.tsinghua.edu.cn (Netscape Mail Server v2.02) with SMTP id AAA278; Fri, 28 Jan 2000 12:25:42 +0800 Received: from 166.111.10.188 by s1000e.cs.tsinghua.edu.cn (SMI-8.6/SMI-SVR4) id LAA17781; Fri, 28 Jan 2000 11:27:51 +0800 Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by mx2.263.net (Postfix) with ESMTP id 71E2B1CB50264; Tue, 18 Jan 2000 22:01:45 +0800 (CST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28650; Tue, 18 Jan 2000 08:06:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28619 for ; Tue, 18 Jan 2000 08:06:53 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28793 for ; Tue, 18 Jan 2000 08:08:02 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Jan 18 08:07:14 EST 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.42.208]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id IAA09197; Tue, 18 Jan 2000 08:07:10 -0500 (EST) Message-ID: <388465B2.C85E8CF3@research.bell-labs.com> Date: Tue, 18 Jan 2000 08:08:02 -0500 From: Ping Pan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Jon Crowcroft CC: Ping Pan , curtis@avici.com, RSVP , mpls , diffserv , te-wg , Henning Schulzrinne , Ellen Hahne Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management References: <9755.948194063@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Version: 1.0 List-Id: X-BeenThere: diffserv@ietf.org Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jon Crowcroft wrote: > > hmm - interesting - thouhg i am still not sure why you can't work on > an evolutionary path with RSVP rather than a whole new protocol > We've tried very hard to address the scaling problem with RSVP in the past year or so. Lou Berger, George Swallow, Lixia (and her students) and us have tried to enhance RSVP soft-state properties in various drafts. At this point, I believe RSVP (and its LSP extension) will have no problem whatsoever to handle intra-domain requirements. But RSVP does have the N**2 problem. When you look at the data we had gathered in Section-2 of our draft, any signaling protocol with N**2 property would be difficult work in inter-domain environment. One of the issues in RSVP is the notion of "route-pinning" at PATH processing time. This forces the routers to remember every reservation sender. At RESV processing time, the routers need to map the RESV to the previous PATH. This means that the routers need to maintain N**2 states. I think this is designed to prevent reservation looping problem. (BTW, Bob Braden told me a couple of years ago that during the RSVP design, people had thought about not storing PATH at routers, but...) In BGRP, we still use the two-pass reservation mechanism. But the PROBE messages (equivalent to RSVP PATH) gather the route information, and the receivers use the gathered routing data to construct sink-trees. At reservation time, the routers need only to remember sink-tree information, which is O(N). Later, -- Ping Pan htpp://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-mpls@UU.NET Sun Jan 30 11:44:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09798 for ; Sun, 30 Jan 2000 11:44:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiagg17107; Sun, 30 Jan 2000 16:43:46 GMT Received: by mail-control.mail.uu.net id QQiagg08474 for mpls-outgoing; Sun, 30 Jan 2000 16:43:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiagg08465 for ; Sun, 30 Jan 2000 16:43:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiagg05642; Sun, 30 Jan 2000 11:42:51 -0500 (EST) Received: from mail.cs.tsinghua.edu.cn by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cs.tsinghua.edu.cn [166.111.68.3]) id QQiagg11449; Sun, 30 Jan 2000 16:42:48 GMT Received: from s1000e.cs.tsinghua.edu.cn ([166.111.68.50]) by mail.cs.tsinghua.edu.cn (Netscape Mail Server v2.02) with SMTP id AAA296; Fri, 28 Jan 2000 12:25:51 +0800 Received: from 166.111.10.188 by s1000e.cs.tsinghua.edu.cn (SMI-8.6/SMI-SVR4) id LAA17783; Fri, 28 Jan 2000 11:27:55 +0800 Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by mx6.263.net (Postfix) with ESMTP id 1522A1C8501CB; Wed, 19 Jan 2000 08:18:41 +0800 (CST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16250; Tue, 18 Jan 2000 18:40:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16222 for ; Tue, 18 Jan 2000 18:40:01 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07503 for ; Tue, 18 Jan 2000 18:41:07 -0500 (EST) From: Masataka Ohta Message-Id: <200001182338.IAA14823@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA14823; Wed, 19 Jan 2000 08:37:48 +0859 Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management To: pingpan@research.bell-labs.com (Ping Pan) Date: Wed, 19 Jan 0 8:37:47 JST CC: J.Crowcroft@cs.ucl.ac.uk, pingpan@dnrc.bell-labs.com, curtis@avici.com, rsvp@ISI.EDU, mpls@UU.NET, diffserv@ietf.org, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com In-Reply-To: <388465B2.C85E8CF3@research.bell-labs.com>; from "Ping Pan" at Jan 18, 100 10:52 pm X-Mailer: ELM [version 2.3 PL11] X-Mailman-Version: 1.0 List-Id: X-BeenThere: diffserv@ietf.org Sender: owner-mpls@UU.NET Precedence: bulk Ping Pan; > > hmm - interesting - thouhg i am still not sure why you can't work on > > an evolutionary path with RSVP rather than a whole new protocol > > > > We've tried very hard to address the scaling problem with RSVP in the > past year or so. Lou Berger, George Swallow, Lixia (and her students) > and us have tried to enhance RSVP soft-state properties in various > drafts. At this point, I believe RSVP (and its LSP extension) will have > no problem whatsoever to handle intra-domain requirements. But RSVP does > have the N**2 problem. When you look at the data we had gathered in > Section-2 of our draft, any signaling protocol with N**2 property would > be difficult work in inter-domain environment. As I have pointed out in RSVP-related WGs and several research papers, RSVP has no scalability problem from the begining. So, I agree with you that it is very hard (impossible) to solve your problem, because the problem does not exist. > One of the issues in RSVP is the notion of "route-pinning" at PATH > processing time. This forces the routers to remember every reservation > sender. At RESV processing time, the routers need to map the RESV to the > previous PATH. No. As I pointed it out in some I-D and the INET'97 paper, the solution is to route RESV first and let PATH follows the route. Note that route stabilization is easy that route-pinning is not necessary at all. There are simple reasons why BGP like policy can not be applicable to resource reservation. But it seems to me that the topic is to hard for you to understand. Masataka Ohta _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-mpls@UU.NET Sun Jan 30 11:45:01 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09809 for ; Sun, 30 Jan 2000 11:45:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiagg11704; Sun, 30 Jan 2000 16:43:02 GMT Received: by mail-control.mail.uu.net id QQiagg08421 for mpls-outgoing; Sun, 30 Jan 2000 16:42:27 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiagg08411 for ; Sun, 30 Jan 2000 16:42:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiagg05618; Sun, 30 Jan 2000 11:42:09 -0500 (EST) Received: from mail.cs.tsinghua.edu.cn by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cs.tsinghua.edu.cn [166.111.68.3]) id QQiagg11013; Sun, 30 Jan 2000 16:42:03 GMT Received: from s1000e.cs.tsinghua.edu.cn ([166.111.68.50]) by mail.cs.tsinghua.edu.cn (Netscape Mail Server v2.02) with SMTP id AAA275; Fri, 28 Jan 2000 12:25:37 +0800 Received: from 166.111.10.188 by s1000e.cs.tsinghua.edu.cn (SMI-8.6/SMI-SVR4) id LAA17779; Fri, 28 Jan 2000 11:27:47 +0800 Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by mx8.263.net (Postfix) with ESMTP id 4B8181CBFCB9A; Tue, 18 Jan 2000 20:35:51 +0800 (CST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26371; Tue, 18 Jan 2000 06:13:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26341 for ; Tue, 18 Jan 2000 06:13:41 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27762 for ; Tue, 18 Jan 2000 06:14:48 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 18 Jan 2000 11:14:23 +0000 To: Ping Pan CC: curtis@avici.com, Ping Pan , RSVP , mpls , diffserv , te-wg , Henning Schulzrinne , Ellen Hahne Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management In-reply-to: Your message of "Mon, 17 Jan 2000 18:03:47 EST." <38839FD3.34430465@dnrc.bell-labs.com> Date: Tue, 18 Jan 2000 11:14:23 +0000 Message-ID: <9755.948194063@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailman-Version: 1.0 List-Id: X-BeenThere: diffserv@ietf.org Sender: owner-mpls@UU.NET Precedence: bulk In message <38839FD3.34430465@dnrc.bell-labs.com>, Ping Pan typed: hmm - interesting - thouhg i am still not sure why you can't work on an evolutionary path with RSVP rather than a whole new protocol but alternatively, what i'd like is to do a joint re-design of inter-domain routing, and inter-domain signaling rather than just pile more and more things into BGP and new signaling protocols...one possibility: to use NIMROD architecture http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html to exchange two types of thing: 1/ tag a map for a region (aka core, or trunk area) with current traffic load advertisement (what one wishes to export as effective available capacity -the map based approach alows you to scale state and size of exchanges...the use of IP or AS numbers or MPLS labels as the means of description of flows or aggregations is, imho, doomed to fail... 2/ tag requests for class based trunk adaptive sized DELTAs in capacity requests from routers at the edge of such a region - delta's allow you to scale the message rate, as well as the state - as the rate of edge device requests increases (iptel call setup or teardown rate goes up), you just modify the deltas to anticipate the desired trunk sizes...rsvp can be modified to do this relatively easily (documents on aggregate reservations only need modest changes in identifying who is requesting what of whom...) some discussion from noel chiappa and others might ensue (pnni too...?) cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-mpls@UU.NET Sun Jan 30 12:04:41 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10116 for ; Sun, 30 Jan 2000 12:04:40 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiagh16702; Sun, 30 Jan 2000 16:52:09 GMT Received: by mail-control.mail.uu.net id QQiagh09106 for mpls-outgoing; Sun, 30 Jan 2000 16:51:34 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiagh09100 for ; Sun, 30 Jan 2000 16:51:33 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiagh06154; Sun, 30 Jan 2000 11:51:23 -0500 (EST) Received: from mail.cs.tsinghua.edu.cn by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cs.tsinghua.edu.cn [166.111.68.3]) id QQiagh16018; Sun, 30 Jan 2000 16:51:20 GMT Received: from s1000e.cs.tsinghua.edu.cn ([166.111.68.50]) by mail.cs.tsinghua.edu.cn (Netscape Mail Server v2.02) with SMTP id AAA299; Fri, 28 Jan 2000 12:25:55 +0800 Received: from 166.111.10.188 by s1000e.cs.tsinghua.edu.cn (SMI-8.6/SMI-SVR4) id LAA17785; Fri, 28 Jan 2000 11:28:05 +0800 Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by mx8.263.net (Postfix) with ESMTP id E69321C925002; Thu, 20 Jan 2000 01:16:59 +0800 (CST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21411; Wed, 19 Jan 2000 10:46:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21380 for ; Wed, 19 Jan 2000 10:46:53 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00963 for ; Wed, 19 Jan 2000 10:48:02 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Jan 19 10:47:32 EST 2000 Received: from dnrc.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA25536; Wed, 19 Jan 2000 10:47:31 -0500 (EST) Message-ID: <3885DC3B.E050189F@dnrc.bell-labs.com> Date: Wed, 19 Jan 2000 10:46:03 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Masataka Ohta CC: Ping Pan , J.Crowcroft@cs.ucl.ac.uk, curtis@avici.com, rsvp@isi.edu, mpls@UU.NET, diffserv@ietf.org, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management References: <200001182338.IAA14823@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Version: 1.0 List-Id: X-BeenThere: diffserv@ietf.org Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > > As I have pointed out in RSVP-related WGs and several research papers, > RSVP has no scalability problem from the begining. > Huh? Please provide the pointers to your draft. > So, I agree with you that it is very hard (impossible) to solve > your problem, because the problem does not exist. > Man. This is deep! > > There are simple reasons why BGP like policy can not be applicable to > resource reservation. But it seems to me that the topic is to hard > for you to understand. > In the past few years, sir, you have been insulting many people in public without much technical input. It's not the topic too hard for me to understand, rather it's your attitude that is too hard for me to understand. Please provide meaningful technical input NICELY. Thank you! - Ping _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-mpls@UU.NET Sun Jan 30 12:49:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10334 for ; Sun, 30 Jan 2000 12:49:39 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiagl12755; Sun, 30 Jan 2000 17:48:45 GMT Received: by mail-control.mail.uu.net id QQiagl19352 for mpls-outgoing; Sun, 30 Jan 2000 17:48:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiagl19347 for ; Sun, 30 Jan 2000 17:48:06 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiagl13943 for ; Sun, 30 Jan 2000 12:48:02 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQiagl16581 for ; Sun, 30 Jan 2000 17:48:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sun Jan 30 12:46:12 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.43.22]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA19533; Sun, 30 Jan 2000 12:46:01 -0500 (EST) Message-ID: <389479E5.5CAA5E71@lucent.com> Date: Sun, 30 Jan 2000 12:50:29 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Rajeev Manur CC: Bora Akyol , mpls@UU.NET, erosen@cisco.com Subject: Re: Valid Operations on MPLS Labels References: <0F8929E5ED5FD311B892005004CED4A609DE71@tonga.ncorenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora/Rajeev, Considering the "pop" operation by itself, there are essentially two things you could do with it. This makes "pop" effectively two distinct instructions: pop-1 and pop-2. In one - call it pop-1 - the incoming label maps to: o select logical output interface o pop top label(s) o forward remaining packet via selected interface In the other, the incoming label maps to: o pop top label(s) o perform label-switch/swap based on the new top label (or - if the last label is removed - use routing based on the following IP header) In the latter case, you have potential for recursion (at least, you do if the last label has not been removed). Also, if you consider the various combinations of "pop", "swap" and "push", you also need to include "pop label(s) and push label(s)" as a single instruction. In this case, you do not need to perform a lookup (label switch/swap) based on the result since anything you might find can as easily be done in the original "pop/push". In this case, you would not get recursion. However, in every case, the complexity of the operation to be performed is limited to the complexity your implementation is willing to accept since all of these potential operations must be bound to a label by the LSR implementation that will ultimately have to do them. If you don't want to implement complex pop/push and swap operations, then don't. After all, the specifications point out that an "LSR" can allocate implicit NULL labels to its peers and never even see labels. Of course, such an "LSR" needs to be surrounded by fairly tolerant neighbors... Rajeev Manur wrote: > > we could also have any combination of these like > SWAP followed by a PUSH, > POP followed by a SWAP > POP and GO ( which is slightly different from POP ) etc. > > we could also have POP & PUSH ( MPLS --> IP --> MPLS ) > > with regards, > Rajeev. > > Force10 Networks > Santa Clara > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora > Akyol > Sent: Friday, January 28, 2000 2:47 PM > To: mpls@UU.NET; erosen@cisco.com > Subject: Valid Operations on MPLS Labels > > What are valid operations that can be performed on MPLS labels? > > Yes sounds simple, but is it really? > > 1. SWAP: Lookup on incoming label, determine egress interface, outgoing > label, swap labels, update TTL. > > 2. PUSH: Look up on incoming label, determine egress interface, swap > topmost label and push one or more labels. Fix TTL in top most label. > > 3. POP: This is where the MPLS arch document is confusing. Assuming that > Penultimate hop popping is not used: > So far we know that we have to lookup on incoming label, determine > operation (in this case POP), pop topmost label. > > If it reveals an IP packet, we do a route lookup and everything is OK. > > If it reveals an MPLS packet underneath, then what are valid operations > that can be performed on the label that emerges after the topmost label > is popped. I would like to know whether a swap or a push can follow a > pop. I am willing to do another lookup on the resultant packet, but > don't want to get into a recursive pop or push paradigm. > > Any thoughts? > > Bora From owner-mpls@UU.NET Sun Jan 30 12:53:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10353 for ; Sun, 30 Jan 2000 12:53:32 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiagl15096; Sun, 30 Jan 2000 17:52:45 GMT Received: by mail-control.mail.uu.net id QQiagl19562 for mpls-outgoing; Sun, 30 Jan 2000 17:52:14 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiagl19553 for ; Sun, 30 Jan 2000 17:52:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiagl09961 for ; Sun, 30 Jan 2000 12:52:01 -0500 (EST) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQiagl18542 for ; Sun, 30 Jan 2000 17:52:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sun Jan 30 12:51:19 EST 2000 Received: from lucent.com (ewgray.lra.lucent.com [135.255.43.22]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA19604; Sun, 30 Jan 2000 12:51:00 -0500 (EST) Message-ID: <38947B11.F6C6929@lucent.com> Date: Sun, 30 Jan 2000 12:55:29 -0500 From: Eric Gray Reply-To: ewgray@lucent.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: lijianping@mail.zhongxing.com CC: mpls@UU.NET Subject: Re: difference between propage and send References: <48256875.0006F1E7.00@mail.zhongxing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lijianping, Yes, this is the meaning of "propagate". A key distinction in LDP is the existence of TLVs in the LDP message to be propagated - some of these may need to be "blind forwarded" (meaning irrespective of whether or not they are understood) in the message being propagated. You wrote: > > Hi, > > In the "ldp-state-machine", there appear two word :propagate and send. > Can I think it as the following? > Propagate a message is: already having a message, and send it. > Send a message is: construct a new message, and send it. > > State: ESTABLISHED > Event: Internal Downstream Withdraw > New State: Depends on the action routine. > Actions: > If it uses independent mode, set its state to `IDLE' and create a > internal `LDP Request' and send to its own state machine. > Else Disconnect the upstream label from the downstream label. > Propagate the LDP-WITHDRAW upstream and go to state `RELEASE_AWAITED'. > Send the event `Internal Destroy' to the Next_Hop_Trigger_Block's state > machine if the LSR was in the middle of switching over to the better next > hop. > > State: ESTABLISHED > Event: Internal Downstream NAK New > State: Depends on the action routine. > Actions: > If it uses independent mode, set its state to `IDLE' and create a > internal `LDP Request' and send to its own state machine. > Else Disconnect the upstream label from the downstream label Send > an LDP-WITHDRAW upstream and go to state `RELEASE_AWAITED'. Send the > event `Internal Destroy' to the Next_Hop_Trigger_Block's state machine if > the LSR was in the middle of switching over to the better next hop. > > Any marks is apperatiated. > Thanks! > Lijianping. From owner-mpls@UU.NET Sun Jan 30 13:32:45 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10590 for ; Sun, 30 Jan 2000 13:32:44 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiago03032; Sun, 30 Jan 2000 18:32:08 GMT Received: by mail-control.mail.uu.net id QQiago29082 for mpls-outgoing; Sun, 30 Jan 2000 18:31:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiago29073 for ; Sun, 30 Jan 2000 18:31:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiago16300 for ; Sun, 30 Jan 2000 13:31:23 -0500 (EST) Received: from morris.canarie.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: server.canarie.ca [209.217.86.48]) id QQiago06531 for ; Sun, 30 Jan 2000 18:31:22 GMT Received: from micky (slip129-37-170-134.pq.ca.prserv.net [129.37.170.134]) by morris.canarie.ca (8.9.3+Sun/8.9.3) with SMTP id NAA28884; Sun, 30 Jan 2000 13:31:14 -0500 (EST) Reply-To: From: "Bill St. Arnaud" To: "Yangguang Xu" , Cc: "'Loa Andersson'" , Subject: RE: MPLS and Optical network - one possible solution is burst switching Date: Sun, 30 Jan 2000 13:30:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38931EEA.82F840D1@lucent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Optical burst switching will probably be the best solution for addressing your requirements. The MPLS packet label is carried out of band in a separate wavelength. Packet switching to different wavelengths and wavelength merging is done at the optical level. The OXC decodes in the optical domain the burst label. The main data channels are put through a small time delay fiber so that burst label can be decoded and OXC wavelength switch can be set up. Lots of development in the labs in this area - see OFC conference in Baltimore. But I don't know if it is still the right approach to MPLS optical networking. Bill Bill St. Arnaud Senior Director Network Projects CANARIE bill.st.arnaud@canarie.ca +1 613 785-0426 > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yangguang > Xu > Sent: January 29, 2000 12:10 PM > To: Alexander.Marhold@xandl.cso.net > Cc: 'Loa Andersson'; mpls@UU.NET > Subject: Re: MPLS and Optical network!! > > > > > But what seems to be my wrong assumption is that currently > there is no OXC > > which can convert wavelengths on the fly between input and > output interface, > > whereas delaying an optical packet until the output interface > and wavelength > > is free seems to be possible at least in an engineering state. > > > > Optical packet? do you mean checking, buffering packets in analog > domain? There > are some research going on this path. However, for commercial > usage, I think at > least 5-10 years away. > > OXC is still the old circuit switch idea. So far, no packet > forwarding look-up > is done on fly for each packet. I surely hope it will do. > > Yangguang > From owner-mpls@UU.NET Sun Jan 30 16:44:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11800 for ; Sun, 30 Jan 2000 16:44:07 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiaha06114; Sun, 30 Jan 2000 21:43:28 GMT Received: by mail-control.mail.uu.net id QQiaha00422 for mpls-outgoing; Sun, 30 Jan 2000 21:42:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiaha00415 for ; Sun, 30 Jan 2000 21:42:55 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiaha22706 for ; Sun, 30 Jan 2000 16:42:36 -0500 (EST) Received: from siroccosystems.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gatekeeper.siroccosystems.com [38.149.123.2]) id QQiaha29170 for ; Sun, 30 Jan 2000 21:42:36 GMT Received: by gatekeeper.siroccosystems.com id <115201>; Sun, 30 Jan 2000 16:49:22 -0500 Message-Id: <00Jan30.164922est.115201@gatekeeper.siroccosystems.com> From: Richard Barnett To: "'Bill.St.Arnaud@canarie.ca'" Cc: mpls@UU.NET Subject: RE: MPLS and Optical network - one possible solution is burst swi tching MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 30 Jan 2000 16:49:12 -0500 Sender: owner-mpls@UU.NET Precedence: bulk Bill, > The MPLS packet label is carried out of band in a separate wavelength. > Packet switching to different wavelengths and wavelength > merging is done at > the optical level. The OXC decodes in the optical domain the > burst label. > The main data channels are put through a small time delay > fiber so that > burst label can be decoded and OXC wavelength switch can be set up. > It's a very interesting approach but I think that a possible problem with this is where contention occurs at the egress port - i.e. if multiple packets are received that need to egress on the same port and wavelength at the same time. Some sort of optical buffering and queue control would be needed to resolve this if I understand the situation correctly. An OTDM approach would avoid this problem at the cost of relatively static bandwidth allocation. This may not suit all applications but its simplicity does have attractions. Richard. ------------------------------------------------------------- Richard Barnett VP of System Architecture, Sirocco Systems. Tel: 203 269 9919 x 126 Fax: 203 269 8291 Email: richard.barnett@siroccosystems.com From owner-mpls@UU.NET Sun Jan 30 18:43:31 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12459 for ; Sun, 30 Jan 2000 18:43:30 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiahi24134; Sun, 30 Jan 2000 23:42:53 GMT Received: by mail-control.mail.uu.net id QQiahi21056 for mpls-outgoing; Sun, 30 Jan 2000 23:42:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiahi21049 for ; Sun, 30 Jan 2000 23:42:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiahi29242 for ; Sun, 30 Jan 2000 18:41:46 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiahi23388 for ; Sun, 30 Jan 2000 23:41:45 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id SAA23144; Sun, 30 Jan 2000 18:41:44 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id SAA01724; Sun, 30 Jan 2000 18:43:40 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200001302343.SAA01724@curtis-lt.avici.com> To: Alexander.Marhold@xandl.cso.net cc: "'J. Noel Chiappa'" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS and Optical network!! In-reply-to: Your message of "Sat, 29 Jan 2000 13:44:51 +0100." <000701bf6a56$a42604f0$2ef26ac2@amarhold.cisco.com> Date: Sun, 30 Jan 2000 18:43:40 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <000701bf6a56$a42604f0$2ef26ac2@amarhold.cisco.com>, "Alexander Marh old" writes: > > Label merge --- which is done in MPLs and 80 wavelengths (labels) PER > INTERFACE in the OXC means > that every router can have up to 80 LSPīs reachable via each of its > interfaces. I don't think label merge will work very well at the optical layer. It might be possible to do TDM and merge lightsources. You'd have to very carefully sync clocks at the senders, know the propogation delays very exactly. A mismatch in clocks and both signals are gone. The lasers would have to be shut off completely when not sending. Optical switching times are still too slow for TDM where the optical switch participates. Is anyone actually taking such an approach? I doubt it but if so, I a may have blown a patent by publishing first (this email). It is an obvious idea though. :-) You still have the issue of efficiently multiplexing (spacial reuse) without going to electrical to accomplish color conversions. There was a recent article in one of the journals (Nov or Dec in an IEEE or ACM journal, don't recall, and don't have it here) in which the placement of these devices was discussed. Without these the efficiency with which wavelengths are used drops rapidly beyond 3-4 optical hops. As soon as you find yourself needing to go to O-E-O you might want put some intellegnece there to improve network protocol scaling and to allow packet buffering and more efficient use of the available lambdas. The majority of the cost of going O-E-O is the conversion. The additional cost is not very high. That more intellegent device would very likely be a router. Unless I'm totally out of it, we're quite a long way from all optical wavelegth conversion and buffering light packets. Curtis From owner-mpls@UU.NET Sun Jan 30 20:57:45 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13268 for ; Sun, 30 Jan 2000 20:57:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiahr25211; Mon, 31 Jan 2000 01:56:49 GMT Received: by mail-control.mail.uu.net id QQiahr12767 for mpls-outgoing; Mon, 31 Jan 2000 01:56:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiahr12762 for ; Mon, 31 Jan 2000 01:56:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiahr06979 for ; Sun, 30 Jan 2000 20:56:13 -0500 (EST) Received: from mail.rdc1.sfba.home.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ha1.rdc1.sfba.home.com [24.0.0.66]) id QQiahr24804 for ; Mon, 31 Jan 2000 01:56:12 GMT Received: from home.net ([24.5.203.21]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000131015612.RZOE12979.mail.rdc1.sfba.home.com@home.net>; Sun, 30 Jan 2000 17:56:12 -0800 Message-ID: <3894EBBC.D6DA32E7@home.net> Date: Sun, 30 Jan 2000 17:56:12 -0800 From: Tony Li Organization: Li Consulting X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: Alexander.Marhold@xandl.cso.net, "'J. Noel Chiappa'" , mpls@UU.NET Subject: Re: MPLS and Optical network!! References: <200001302343.SAA01724@curtis-lt.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Unless I'm totally out of it, we're quite a long way from all optical > wavelegth conversion and buffering light packets. I concur. Where we should be going is to extend our signaling protocol so that we can automate traffic engineering for both the MPLS and optical planes. This implies that the OXCs participate (possibly through a proxy) in the signaling protocols, that optical plane configuration information is carried in our IGPs, and that traffic engineering path computation also consider optical path establishment as well as LSP establishment. My $.02, Tony From owner-mpls@UU.NET Mon Jan 31 01:08:33 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17263 for ; Mon, 31 Jan 2000 01:08:33 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiaii22478; Mon, 31 Jan 2000 06:07:12 GMT Received: by mail-control.mail.uu.net id QQiaii02911 for mpls-outgoing; Mon, 31 Jan 2000 06:06:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiaii02883 for ; Mon, 31 Jan 2000 06:06:31 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiaii22957 for ; Mon, 31 Jan 2000 01:06:20 -0500 (EST) Received: from mail.xandl.cso.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.xandl.cso.net [194.106.242.34]) id QQiaii21915 for ; Mon, 31 Jan 2000 06:06:19 GMT Received: from amarhold ([194.106.242.46]) by mail.xandl.cso.net (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100) with SMTP id AAA94; Mon, 31 Jan 2000 07:11:37 +0100 Reply-To: From: "Alexander Marhold" To: "'Richard Barnett'" , Cc: Subject: RE: MPLS and Optical network Date: Mon, 31 Jan 2000 07:05:58 +0100 Message-ID: <000b01bf6bb1$3f46a100$2ef26ac2@amarhold.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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <00Jan30.164922est.115201@gatekeeper.siroccosystems.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Many thanks for all who responded to me and to the group and clarified the topic So in my opinion the point is now: 1. Currently we have only a OXC which can switch a wavelength from input to output without wavelength conversion and with no packet recognition. (a wavelength circuit switch) that means in a label way, that the value of the incoming label needs to be the same as the ougoing label on an OXC (with control plane). (label = wavelength) ---> leads to a practical maximum of number of LSPs = number of wavelengths (currently about 80) then you have the possibility to optical switch to any redundant path in case of link failure (theoretically you can also have more LSPs if you have more optical paths and interfaces through your core, but the restriction is that no 2 LSPs with the same label(wavelength) may cross a single link. So imho the interesting issue would be finding an optimizing algorithm which has the above mentioned constraints.) 2. wavelength conversion on the fly, which would allow more flexibility label invalue can be different of label outvalue is not available yet 3. optical packet recognition and wavelength conversion and buffering is future and would lead to an pure optical router, which can have Mpls but it seems to be not considered in the efforts of the MPLS-WG now. regards Alexander __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ __/ __/ Dipl.Ing. Alexander Marhold MBA __/ CCIE #3324, CCNP, CCNA, CCDP, CCDA, CCSI #20642 __/ PRO IN __/ Mobile: ++43-(0)664-16 28 234 __/ > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Richard > Barnett > Sent: Sunday, January 30, 2000 10:49 PM > To: 'Bill.St.Arnaud@canarie.ca' > Cc: mpls@UU.NET > Subject: RE: MPLS and Optical network - one possible solution is burst > switching > > > Bill, > > > The MPLS packet label is carried out of band in a separate > wavelength. > > Packet switching to different wavelengths and wavelength > > merging is done at > > the optical level. The OXC decodes in the optical domain the > > burst label. > > The main data channels are put through a small time delay > > fiber so that > > burst label can be decoded and OXC wavelength switch can be set up. > > > > It's a very interesting approach but I think that a possible > problem with > this is where contention occurs at the egress port - i.e. if multiple > packets are received that need to egress on the same port and > wavelength at > the same time. Some sort of optical buffering and queue > control would be > needed to resolve this if I understand the situation > correctly. An OTDM > approach would avoid this problem at the cost of relatively > static bandwidth > allocation. This may not suit all applications but its > simplicity does have > attractions. > > Richard. > > ------------------------------------------------------------- > Richard Barnett > VP of System Architecture, Sirocco Systems. > Tel: 203 269 9919 x 126 Fax: 203 269 8291 > Email: richard.barnett@siroccosystems.com > From owner-mpls@UU.NET Mon Jan 31 09:10:30 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03921 for ; Mon, 31 Jan 2000 09:10:30 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajo25981; Mon, 31 Jan 2000 14:09:14 GMT Received: by mail-control.mail.uu.net id QQiajo28431 for mpls-outgoing; Mon, 31 Jan 2000 14:08:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiajo28425 for ; Mon, 31 Jan 2000 14:08:35 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiajo24419 for ; Mon, 31 Jan 2000 09:08:34 -0500 (EST) Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQiajo25470 for ; Mon, 31 Jan 2000 14:08:34 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 31 Jan 2000 09:07:36 -0500 Message-ID: From: "Kullberg, Alan" To: mpls@UU.NET Subject: RE: Valid Operations on MPLS Labels Date: Mon, 31 Jan 2000 09:07:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Here's an example where LSR-B would perform a POP, SWAP, and then PUSH. In the following set of LSRs, A & B and B & C are LDP targeted peers. An LSP has been setup from A to B to C. In addition, there are 2 other LSPs, one from A to B using 1, 2, & 3, and another from B to C using 4, 5, & 6. The ABC LSP uses label stacking between A & B and B & C. Assuming no PHP, when B receives a labeled packet, there are 2 labels. The A123B level label is POPped, then a SWAP of the ABC level label, then a PUSH of the B456C level label. A B C \ / \ / 1---2---3 4---5---6 Alan > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Friday, January 28, 2000 5:47 PM > To: mpls@UU.NET; erosen@cisco.com > Subject: Valid Operations on MPLS Labels > > > What are valid operations that can be performed on MPLS labels? > > Yes sounds simple, but is it really? > > 1. SWAP: Lookup on incoming label, determine egress > interface, outgoing > label, swap labels, update TTL. > > 2. PUSH: Look up on incoming label, determine egress interface, swap > topmost label and push one or more labels. Fix TTL in top most label. > > 3. POP: This is where the MPLS arch document is confusing. > Assuming that > Penultimate hop popping is not used: > So far we know that we have to lookup on incoming label, determine > operation (in this case POP), pop topmost label. > > If it reveals an IP packet, we do a route lookup and everything is OK. > > If it reveals an MPLS packet underneath, then what are valid > operations > that can be performed on the label that emerges after the > topmost label > is popped. I would like to know whether a swap or a push can follow a > pop. I am willing to do another lookup on the resultant packet, but > don't want to get into a recursive pop or push paradigm. > > Any thoughts? > > Bora > > > > From owner-mpls@UU.NET Mon Jan 31 09:26:20 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04264 for ; Mon, 31 Jan 2000 09:26:20 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajp10695; Mon, 31 Jan 2000 14:25:33 GMT Received: by mail-control.mail.uu.net id QQiajp29822 for mpls-outgoing; Mon, 31 Jan 2000 14:25:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiajp29811 for ; Mon, 31 Jan 2000 14:24:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiajp00778 for ; Mon, 31 Jan 2000 09:24:41 -0500 (EST) Received: from blaze.hcltech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [204.160.253.201]) id QQiajp10042 for ; Mon, 31 Jan 2000 14:24:37 GMT Received: from netlab.hcltech.com ([192.168.201.56]) by blaze.hcltech.com (8.9.3/8.8.7) with ESMTP id TAA21729; Mon, 31 Jan 2000 19:54:39 +0530 Message-ID: <38959AED.B9E07AD3@netlab.hcltech.com> Date: Mon, 31 Jan 2000 19:53:41 +0530 From: Pathangi N Janardhanan Organization: Hcl Technologies India Ltd. X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Kullberg, Alan" CC: mpls@UU.NET Subject: Re: Valid Operations on MPLS Labels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > Here's an example where LSR-B would perform a POP, SWAP, and then PUSH. > In the following set of LSRs, A & B and B & C are LDP targeted peers. This could be modelled as a POP followed by a SWAP if the operations can be defined for label stacks, rather than single labels. That way the maximum number of operations would always be two. Jana > An LSP has been setup from A to B to C. In addition, there are 2 other > LSPs, one from A to B using 1, 2, & 3, and another from B to C using 4, > 5, & 6. The ABC LSP uses label stacking between A & B and B & C. > Assuming no PHP, when B receives a labeled packet, there are 2 labels. > The A123B level label is POPped, then a SWAP of the ABC level label, > then a PUSH of the B456C level label. > > A B C > \ / \ / > 1---2---3 4---5---6 > > Alan > > > -----Original Message----- > > From: Bora Akyol [mailto:akyol@pluris.com] > > Sent: Friday, January 28, 2000 5:47 PM > > To: mpls@UU.NET; erosen@cisco.com > > Subject: Valid Operations on MPLS Labels > > > > > > What are valid operations that can be performed on MPLS labels? > > > > Yes sounds simple, but is it really? > > > > 1. SWAP: Lookup on incoming label, determine egress > > interface, outgoing > > label, swap labels, update TTL. > > > > 2. PUSH: Look up on incoming label, determine egress interface, swap > > topmost label and push one or more labels. Fix TTL in top most label. > > > > 3. POP: This is where the MPLS arch document is confusing. > > Assuming that > > Penultimate hop popping is not used: > > So far we know that we have to lookup on incoming label, determine > > operation (in this case POP), pop topmost label. > > > > If it reveals an IP packet, we do a route lookup and everything is OK. > > > > If it reveals an MPLS packet underneath, then what are valid > > operations > > that can be performed on the label that emerges after the > > topmost label > > is popped. I would like to know whether a swap or a push can follow a > > pop. I am willing to do another lookup on the resultant packet, but > > don't want to get into a recursive pop or push paradigm. > > > > Any thoughts? > > > > Bora > > > > > > > > -- ----- Pathangi N Janardhanan HCL Technologies India Ltd., D-12 & 12-B, 3rd South Street, SIDCO Industrial Estate, Ambattur Chennai - 600 058 India Phone Off : + 91 44 230711/6230712 ext. 2535 Phone Res: +91 44 3743690 Fax : +91 44 6244213 e-mail : janar@netlab.hcltech.com From owner-mpls@UU.NET Mon Jan 31 09:41:02 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04833 for ; Mon, 31 Jan 2000 09:41:01 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajq04062; Mon, 31 Jan 2000 14:39:17 GMT Received: by mail-control.mail.uu.net id QQiajq00427 for mpls-outgoing; Mon, 31 Jan 2000 14:39:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiajq00422 for ; Mon, 31 Jan 2000 14:38:51 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiajq27873 for ; Mon, 31 Jan 2000 09:38:37 -0500 (EST) Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQiajq18308 for ; Mon, 31 Jan 2000 14:38:37 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 31 Jan 2000 09:37:39 -0500 Message-ID: From: "Kullberg, Alan" To: mpls@UU.NET Subject: RE: Valid Operations on MPLS Labels Date: Mon, 31 Jan 2000 09:37:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Pathangi N Janardhanan [mailto:janar@netlab.hcltech.com] > Sent: Monday, January 31, 2000 9:24 AM > To: Kullberg, Alan > Cc: mpls@UU.NET > Subject: Re: Valid Operations on MPLS Labels > > > Hi, > > > Here's an example where LSR-B would perform a POP, SWAP, > and then PUSH. > > In the following set of LSRs, A & B and B & C are LDP > targeted peers. > > This could be modelled as a POP followed by a SWAP if the operations > can be defined for label stacks, rather than single labels. That way > the maximum number of operations would always be two. I don't think so. What if another LSP between A & B is also using the A123B LSP for a tunnel for the A to B leg and then goes from B to another LSR D (connected directly to B) In this case, the ABC LSP and the ABD LSP are sharing the A123B LSP for tunneling between A & B. Thus, when a packet is received at B with the A123B label on top, the label must be POPped followed by an ILM lookup on the next level label, which may be the ABC label or the ABD label. When it is the ABC label, a SWAP followed by a PUSH B456C label is performed. When it is the ABD label, a just a SWAP is performed. Since multiple LSPs (and hence, multiple different labels) can share an LSP for tunneling between 2 LSRs, I think the label stack must be processed label by label. D | A B C \ / \ / 1---2---3 4---5---6 Alan > > Jana > > > An LSP has been setup from A to B to C. In addition, there > are 2 other > > LSPs, one from A to B using 1, 2, & 3, and another from B > to C using 4, > > 5, & 6. The ABC LSP uses label stacking between A & B and B & C. > > Assuming no PHP, when B receives a labeled packet, there > are 2 labels. > > The A123B level label is POPped, then a SWAP of the ABC level label, > > then a PUSH of the B456C level label. > > > > A B C > > \ / \ / > > 1---2---3 4---5---6 > > > > Alan > > > > > -----Original Message----- > > > From: Bora Akyol [mailto:akyol@pluris.com] > > > Sent: Friday, January 28, 2000 5:47 PM > > > To: mpls@UU.NET; erosen@cisco.com > > > Subject: Valid Operations on MPLS Labels > > > > > > > > > What are valid operations that can be performed on MPLS labels? > > > > > > Yes sounds simple, but is it really? > > > > > > 1. SWAP: Lookup on incoming label, determine egress > > > interface, outgoing > > > label, swap labels, update TTL. > > > > > > 2. PUSH: Look up on incoming label, determine egress > interface, swap > > > topmost label and push one or more labels. Fix TTL in top > most label. > > > > > > 3. POP: This is where the MPLS arch document is confusing. > > > Assuming that > > > Penultimate hop popping is not used: > > > So far we know that we have to lookup on incoming label, > determine > > > operation (in this case POP), pop topmost label. > > > > > > If it reveals an IP packet, we do a route lookup and > everything is OK. > > > > > > If it reveals an MPLS packet underneath, then what are valid > > > operations > > > that can be performed on the label that emerges after the > > > topmost label > > > is popped. I would like to know whether a swap or a push > can follow a > > > pop. I am willing to do another lookup on the resultant > packet, but > > > don't want to get into a recursive pop or push paradigm. > > > > > > Any thoughts? > > > > > > Bora > > > > > > > > > > > > > > -- > ----- > Pathangi N Janardhanan > HCL Technologies India Ltd., > D-12 & 12-B, 3rd South Street, > SIDCO Industrial Estate, > Ambattur Chennai - 600 058 > India > > Phone Off : + 91 44 230711/6230712 ext. 2535 > Phone Res: +91 44 3743690 > Fax : +91 44 6244213 > e-mail : janar@netlab.hcltech.com > From owner-mpls@UU.NET Mon Jan 31 09:53:55 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05336 for ; Mon, 31 Jan 2000 09:53:53 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajr02807; Mon, 31 Jan 2000 14:52:37 GMT Received: by mail-control.mail.uu.net id QQiajr01219 for mpls-outgoing; Mon, 31 Jan 2000 14:52:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiajr01213 for ; Mon, 31 Jan 2000 14:52:17 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiajr02813 for ; Mon, 31 Jan 2000 09:52:04 -0500 (EST) Received: from blaze.hcltech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [204.160.253.201]) id QQiajr17887 for ; Mon, 31 Jan 2000 14:52:00 GMT Received: from netlab.hcltech.com ([192.168.201.56]) by blaze.hcltech.com (8.9.3/8.8.7) with ESMTP id UAA22092; Mon, 31 Jan 2000 20:22:19 +0530 Message-ID: <3895A16A.FF228C01@netlab.hcltech.com> Date: Mon, 31 Jan 2000 20:21:22 +0530 From: Pathangi N Janardhanan Organization: Hcl Technologies India Ltd. X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Kullberg, Alan" CC: mpls@UU.NET Subject: Re: Valid Operations on MPLS Labels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > > Since multiple LSPs (and hence, multiple different labels) can share > an LSP for tunneling between 2 LSRs, I think the label stack must be > processed label by label. Yes, the processing of incoming label stack must be performed on a label by label basis, what I was refering to was the outgoing labels, we could model a SWAP and PUSH on the outgoing side as a single SWAP of the appropriate label stack. > > > > If it reveals an MPLS packet underneath, then what are valid > > > > operations > > > > that can be performed on the label that emerges after the > > > > topmost label > > > > is popped. I would like to know whether a swap or a push > > can follow a > > > > pop. I am willing to do another lookup on the resultant > > packet, but > > > > don't want to get into a recursive pop or push paradigm. > > > > considering a stack of depth greater than 2, we may have to recurisvely POP labels if we are the egress for more than one level. Jana From owner-mpls@UU.NET Mon Jan 31 09:59:58 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05612 for ; Mon, 31 Jan 2000 09:59:58 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajr06169; Mon, 31 Jan 2000 14:57:38 GMT Received: by mail-control.mail.uu.net id QQiajr01459 for mpls-outgoing; Mon, 31 Jan 2000 14:57:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiajr01453 for ; Mon, 31 Jan 2000 14:57:21 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiajr03534 for ; Mon, 31 Jan 2000 09:57:14 -0500 (EST) Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQiajr21166 for ; Mon, 31 Jan 2000 14:57:14 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 31 Jan 2000 09:56:16 -0500 Message-ID: From: "Kullberg, Alan" To: mpls@UU.NET Subject: RE: Valid Operations on MPLS Labels Date: Mon, 31 Jan 2000 09:56:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Jana, I agree that the label SWAP and PUSH on the outgoing side could be done in a single operation. I misunderstood your original message. Alan > -----Original Message----- > From: Pathangi N Janardhanan [mailto:janar@netlab.hcltech.com] > Sent: Monday, January 31, 2000 9:51 AM > To: Kullberg, Alan > Cc: mpls@UU.NET > Subject: Re: Valid Operations on MPLS Labels > > > Hi, > > > > > Since multiple LSPs (and hence, multiple different labels) can share > > an LSP for tunneling between 2 LSRs, I think the label stack must be > > processed label by label. > > Yes, the processing of incoming label stack must be performed on a > label by label basis, what I was refering to was the outgoing labels, > we could model a SWAP and PUSH on the outgoing side as a single SWAP > of the appropriate label stack. > > > > > > If it reveals an MPLS packet underneath, then what are valid > > > > > operations > > > > > that can be performed on the label that emerges after the > > > > > topmost label > > > > > is popped. I would like to know whether a swap or a push > > > can follow a > > > > > pop. I am willing to do another lookup on the resultant > > > packet, but > > > > > don't want to get into a recursive pop or push paradigm. > > > > > > > considering a stack of depth greater than 2, we may have to > recurisvely POP labels if we are the egress for more than one level. > > Jana > From owner-mpls@UU.NET Mon Jan 31 10:06:24 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05918 for ; Mon, 31 Jan 2000 10:06:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajs11455; Mon, 31 Jan 2000 15:05:18 GMT Received: by mail-control.mail.uu.net id QQiajs07542 for mpls-outgoing; Mon, 31 Jan 2000 15:05:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiajs07528 for ; Mon, 31 Jan 2000 15:05:01 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiajs04712 for ; Mon, 31 Jan 2000 10:04:49 -0500 (EST) Received: from farley.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: farley.cisco.com [171.71.153.30]) id QQiajs25864 for ; Mon, 31 Jan 2000 15:04:48 GMT Received: from rching-nt (rching-dsl4.cisco.com [10.19.4.205]) by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id HAA26250 for ; Mon, 31 Jan 2000 07:04:47 -0800 (PST) Message-Id: <4.1.20000131070223.00c0a220@farley.cisco.com> X-Sender: rching@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 31 Jan 2000 07:03:59 -0800 To: mpls@UU.NET From: Robert Ching Subject: remove rching@cisco.com from the mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Please remove rching@cisco.com from the mailing list. From owner-mpls@UU.NET Mon Jan 31 10:24:39 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06731 for ; Mon, 31 Jan 2000 10:24:38 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajt06779; Mon, 31 Jan 2000 15:22:34 GMT Received: by mail-control.mail.uu.net id QQiajt10787 for mpls-outgoing; Mon, 31 Jan 2000 15:22:08 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiajt10755 for ; Mon, 31 Jan 2000 15:22:02 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiajt11727 for ; Mon, 31 Jan 2000 10:22:00 -0500 (EST) Received: from tns04.tns-inc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.tns-inc.com [38.164.22.4]) id QQiajt05965 for ; Mon, 31 Jan 2000 15:21:55 GMT Received: from tns-inc.com (port67.ctccom.net [166.90.188.67]) by tns04.tns-inc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DXJ44H7K; Mon, 31 Jan 2000 10:14:11 -0500 Message-ID: <3895A876.6EEF0930@tns-inc.com> Date: Mon, 31 Jan 2000 10:21:26 -0500 From: Andrew Bender X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: Alexander.Marhold@xandl.cso.net, "'J. Noel Chiappa'" , curtis@avici.com, Tony Li Subject: Re: MPLS and Optical network!! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Are the obstacles to use of Lithium Niobate or nonlinear optical materials really that great? As for buffering, perhaps ferroelectrics (BaTiO3) and creative use of tuned "delay lines" or refractors could be applied to the buffering problem... relaxation time, variable PDUs obviously complicate this, at a minimum. I suspect that a some closed loop between upstream and dowstream O-E-O stages would be more immediately practical. Wow. I probably just blew a load of patentable stuff... (or maybe not!) :P Regards, Andrew Bender tns-inc.com > From tony1@home.net Mon Jan 31 07:02:39 2000 > Date: Sun, 30 Jan 2000 17:56:12 -0800 > From: Tony Li > To: curtis@avici.com > Cc: Alexander.Marhold@xandl.cso.net, 'J. Noel Chiappa' , > mpls@UU.NET > Subject: Re: MPLS and Optical network!! > > > Unless I'm totally out of it, we're quite a long way from all optical > > wavelegth conversion and buffering light packets. > > I concur. > > Where we should be going is to extend our signaling protocol so that we can > automate traffic engineering for both the MPLS and optical planes. This implies > that the OXCs participate (possibly through a proxy) in the signaling protocols, > that optical plane configuration information is carried in our IGPs, and that > traffic engineering path computation also consider optical path establishment as > well as LSP establishment. > > My $.02, > Tony > > From owner-mpls@UU.NET Mon Jan 31 10:26:00 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06808 for ; Mon, 31 Jan 2000 10:25:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajt08261; Mon, 31 Jan 2000 15:24:40 GMT Received: by mail-control.mail.uu.net id QQiajt10895 for mpls-outgoing; Mon, 31 Jan 2000 15:24:22 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiajt10886 for ; Mon, 31 Jan 2000 15:24:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiajt12067 for ; Mon, 31 Jan 2000 10:24:07 -0500 (EST) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [208.197.169.254]) id QQiajt07780 for ; Mon, 31 Jan 2000 15:24:06 GMT Received: from oleary-lt (wcom-dial-53.juniper.net [172.16.14.118]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id HAA03815; Mon, 31 Jan 2000 07:23:24 -0800 (PST) Message-Id: <4.2.0.58.20000131072138.0095ded0@pobox3.juniper.net> X-Sender: doleary@pobox3.juniper.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 31 Jan 2000 07:23:18 -0800 To: Tony Li , curtis@avici.com From: "dave o'leary" Subject: Re: MPLS and Optical network!! Cc: Alexander.Marhold@xandl.cso.net, "'J. Noel Chiappa'" , mpls@UU.NET In-Reply-To: <3894EBBC.D6DA32E7@home.net> References: <200001302343.SAA01724@curtis-lt.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 05:56 PM 1/30/00 -0800, Tony Li wrote: > > Unless I'm totally out of it, we're quite a long way from all optical > > wavelegth conversion and buffering light packets. > >I concur. Curtis and Tony agree on something! :-) >Where we should be going is to extend our signaling protocol so that we can >automate traffic engineering for both the MPLS and optical planes. This >implies >that the OXCs participate (possibly through a proxy) in the signaling >protocols, >that optical plane configuration information is carried in our IGPs, and that >traffic engineering path computation also consider optical path >establishment as >well as LSP establishment. indeed, exactly. of course, given the optical networking hype, it is time to start loading the next B Ark. Are you going to stop by NANOG, or do you have real work to do? dave From owner-mpls@UU.NET Mon Jan 31 11:15:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08599 for ; Mon, 31 Jan 2000 11:15:26 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajw24651; Mon, 31 Jan 2000 16:14:01 GMT Received: by mail-control.mail.uu.net id QQiajw21302 for mpls-outgoing; Mon, 31 Jan 2000 16:13:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiajw21297 for ; Mon, 31 Jan 2000 16:13:41 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiajw15705 for ; Mon, 31 Jan 2000 11:13:40 -0500 (EST) Received: from gorilla.mchh.siemens.de by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQiajw09473 for ; Mon, 31 Jan 2000 16:13:39 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 RAA05863; Mon, 31 Jan 2000 17:12:44 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA19218; Mon, 31 Jan 2000 17:13:39 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id <1A5NHVG0>; Mon, 31 Jan 2000 17:13:54 +0100 Message-ID: <3B59676F9ADBD211B5360060086E64EE45E7B4@MCHH237E> From: Theimer Thomas To: "'Tony Li'" , curtis@avici.com Cc: mpls@UU.NET Subject: RE: MPLS and Optical network!! Date: Mon, 31 Jan 2000 17:13:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > Where we should be going is to extend our signaling protocol so that we > can > automate traffic engineering for both the MPLS and optical planes. This > implies > that the OXCs participate (possibly through a proxy) in the signaling > protocols, > that optical plane configuration information is carried in our IGPs, and > that > traffic engineering path computation also consider optical path > establishment as > well as LSP establishment. > [Theimer Thomas] Why do you think that it's necessary for OXCs to be in the same IGP routing domain as routers ? OXCs are not used for any kind of hop-hop forwarding, so there is no immediate need for them to share their topology information with routers. I would expect that initially the optical domain will have a control plane that is independent from the layer 3 control plane of routers. Of course, there is traffic engineering in the optical domain, and there is traffic engineering in the layer 3 domain, but why do they have to be integrated ??? After all, the granularities and LSP characteristics are completely different in both domains. In many cases, both domains will also be operated by separate or even independent organisations. That is not to say that both domains may use the same protocols and principles for signalling and routing (e.g. MPLS). Routers may even be able to talk to OXCs and request additional optical trails. But that still doesn't require an integrated IGP routing domain, that includes all routers and IXCs. Perhaps I'm missing something ? Thomas From owner-mpls@UU.NET Mon Jan 31 11:29:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08862 for ; Mon, 31 Jan 2000 11:28:59 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajx03974; Mon, 31 Jan 2000 16:28:56 GMT Received: by mail-control.mail.uu.net id QQiajx22179 for mpls-outgoing; Mon, 31 Jan 2000 16:28:34 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiajx22174 for ; Mon, 31 Jan 2000 16:28:30 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiajx17942 for ; Mon, 31 Jan 2000 11:28:09 -0500 (EST) Received: from ntserver4.ftrc.fujitsu.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [193.119.135.150]) id QQiajx03322 for ; Mon, 31 Jan 2000 16:28:08 GMT Received: by NTSERVER4 with Internet Mail Service (5.5.2448.0) id ; Mon, 31 Jan 2000 16:27:20 -0000 Message-ID: From: John Hopkins To: "'mpls@UU.NET'" Subject: minimising wavelength conversion in MPLambdaS systems Date: Mon, 31 Jan 2000 16:27:13 -0000 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I have been considering label(lambda) allocation in MPLmS systems supporting wavelength re-use. One issue is how to minimise the number of nodes along a lambda-switched lightpath where wavelength conversion occurs (or alternatively how to maximise the number of nodes though which the lightpath can traverse transparently). Another issue is how to determine the most appropriate lambda to use for a particular lightpath, and wether lambda-assignment should be integrated with the process of determing a route for the LmSP, or be a follow-on activity from determing the route. Maxmimum lambda-reuse in the network would be a goal in order to support more LmSPs than the number of available wavelengths. In ordinary MPLS, LSRs swap input and output labels and it is assumed that there is negliable cost in changing an input label (e.g. VPI/VCI) to an output label. When a wavelength is used as a label, lambda-swapping between different lamba-in and lambda-out implies a wavelength conversion device, which is a scarce resource. In future all optical networks, wavelength conversion will very likely be required at some locations, such as Optical Cross Connects (OXC) sites. However in simpler ring-based optical networks where an optical path may traverse a number of relatively low-cost Optical Add-Drop-Mux (OADM) devices it is very advantageous if the same wavelength can be used along an entire lightpath traversing many nodes transparently (i.e. with the same lambda-in and lamba-out). Even in OXC or OADM systems supporting wavelength conversion, it is desirable to use it sparingly. This would require that the source node has either :- a) the knowledge of other nodes' optical switching limitations (e.g. advertised lambda add/drop/passthru range), AND the currrent status of other nodes' wavelength usage. This is the information needed by a source node to compute the most appropriate lambda for the lightpath (e.g. using minimal number of required wavelength conversions as one constraint), or b) there is some type of crankback mechanism in MPLmS LDP which can be invoked when one node on the setup path discovers that the lightpath cannot be established because the initial lambda allocated for the lightpath by the source node is already in use by another lightpath at that node, or c) require that each OADM node supports wavelength conversion (ugh) so that blocking can be avoided by a wavelength conversion. I prefer the 1st approach for a ring-based network, complemented by wavelength conversion at OXC sites between rings. One possible soultion would invlove the following :- 1) a distributed wavelength usage database for the optical domain (so that source nodes have the information to compute a lambda that will not lead to blocking on the lightpath) This could involve protocol support to distribute wavelength usage status updates between all MPLmS aware nodes in an optical domain, possibly piggybacking these status updates in IGP protocol messages. The idea would be that each node periodically (or following changes in lightpath topology) sends status updates describing wavelength allocation on its interfaces. (One issue is how to keep this information up to date.) If this information is received by all nodes in an optical domain (such as a ring), then all nodes in the domain have a domain-wide view of lightpath assignments and lambda usage and are in a position to compute 'optimal' routes and lambda-assignments for new lightpaths. That is to say they would be in a position to compute a non-blocking shortest lightpath with minimal (hopefully zero) requirement for wavelength conversion. Either these two processes could be seperate (e.g. route determination firstbased on shortest-path, followed by lamnda-assignement) or the! ! ! ! y could be integrated in a multiple-constraint search for non-blocking path. 2) a wider distribution of lambda-range advertisements than just neigbour-to-neighbour . Basic MPLS LDP initialisation supports the exchange of this information between adjecent LSRs which is fine if all nodes can swap labels. However this won't work when non-adjacent ingress/egress nodes are the only ones add/dropping the lambda, and there is a desire for the intervening transit nodes to pass the lambda through transparently. Without this information about distant nodes, there is a danger that a lambda-could be assigned for a lightpath that is non-blocking at all intervening nodes, but which can't be dropped by the egress node because it is outside its advertised lambda-range. A possible solution is extension of the LmDP initialisation phase to broadcast/flood lambda-range advertisements to all nodes in a domain. This then allows a source node to know the lambda-swapping limititations of all the nodes through which a lightpath may traverse, and take this into account when establishing the route and lambda that the lightpath should use. Note that this is only nec! ! ! ! essary if nodes on the path have differing capabilities, e.g. can add/drop different subsets of the complete range of lambdas supported in a network, but this may be a likely situation. Any thoughts? John Hopkins From owner-mpls@UU.NET Mon Jan 31 11:34:37 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09024 for ; Mon, 31 Jan 2000 11:34:37 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajy26710; Mon, 31 Jan 2000 16:34:33 GMT Received: by mail-control.mail.uu.net id QQiajy22433 for mpls-outgoing; Mon, 31 Jan 2000 16:34:06 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiajy22425 for ; Mon, 31 Jan 2000 16:33:55 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiajy24637; Mon, 31 Jan 2000 11:33:37 -0500 (EST) From: grantgold@excte.com Received: from mail01.homewknow.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: ABDCD6BB.ipt.aol.com [171.220.214.187]) id QQiajy08374; Mon, 31 Jan 2000 16:33:28 GMT Subject: FREE NO REPAY CASH GRANTS, UP TOO $50,000! Date: Mon, 31 Jan 2000 04:30:35 Message-Id: <370.842326.437713@mail01.homewknow.com> To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk FREE CASH GRANTS, NEVER REPAY! You Can Get The Money You Need... To Start Your Home Business... To Consolidate Your Debt... To Go To college... To Start Your Home Business... Almost ANY Worthwhile Reason... Why? Foundations all over the United States GIVE away Millions of Dollars of CASH GRANTS every year. They must give this MONEY away, in order to maintain their tax free status. Who Can Apply? ANYONE can apply for a Grant from 18 years old and up! We Can Help! We will show you HOW & WHERE to get Grants. This MONEY has to be given away, WHY not to YOU? Grants from $500.00 to $50,000.00 are possible! GRANTS don't have to be paid back! Grants can be ideal for people who are or were bankrupt or just have bad credit. The Good News! DON'T pay $79.00 to $129.00 for this information and list. We Will Show You How To Apply For Your Grants, Where To Apply, And Exactly What To Say. We Help You Do It All For Just $32.95. If You Pay With Credit Card, All Information Will Be Sent To Your Email Address Within 24 to 48 Hours! We Gladly Accept Credit Cards & Checks Via Web and Postal Mail: American Express Master Card Visa Don't Delay, This Is A Limited Time Offer At This Amazing Low Price! Get That Grant Before College Rush Time Coming Up! Interested, Please Visit Our Website Below And Place Your Order! ********** http://www.geocities.com/Eureka/Network/3801/ ********** To Order by postal mail, please send $32.95 Plus $2.00 S & H. Make payable to Grant Gold 2000. Grant Gold 2000 4196 Wenz Ct. Suite C Dayton, Ohio 45405 ********** From owner-mpls@UU.NET Mon Jan 31 11:46:57 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09220 for ; Mon, 31 Jan 2000 11:46:56 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiajz07820; Mon, 31 Jan 2000 16:46:57 GMT Received: by mail-control.mail.uu.net id QQiajz23307 for mpls-outgoing; Mon, 31 Jan 2000 16:46:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiajz23289 for ; Mon, 31 Jan 2000 16:46:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiajz29143 for ; Mon, 31 Jan 2000 11:45:58 -0500 (EST) Received: from hermes.research.kpn.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQiajz07124 for ; Mon, 31 Jan 2000 16:45:57 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #35196) with ESMTP id <01JLD2UYFVGW000LO7@research.kpn.com> for mpls@UU.NET; Mon, 31 Jan 2000 17:45:55 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Mon, 31 Jan 2000 17:45:54 +0100 Content-return: allowed Date: Mon, 31 Jan 2000 17:45:51 +0100 From: "Metz, E.T." Subject: RE: MPLS and Optical network!! To: "'Theimer Thomas'" Cc: mpls@UU.NET Message-id: <59063B5B4D98D311BC0D0001FA7E452206F1BD@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk >> I would expect that initially the optical domain will have a control plane that is >> independent from the layer 3 control plane of routers. This would mean going back to a situation similar to the IP/ATM overlay model. I think eventually multiple control planes will/can run on an OXC depending on the situation. If the OXC is deployed in an all-IP network I see no use for other control planes than IP (or MPLS for that matter). If the OXC is multi-purpose, multiple control planes may run on it. >> Of course, there is traffic engineering in the optical domain, and there is traffic >> engineering in the layer 3 domain, but why do they have to be integrated ??? After all, >> the granularities and LSP characteristics are completely different in both domains. If both serve the same purpose, I think they should be integrated. You could also integrate e.g. IP and ATM traffic engineering, but I haven't seen much of that. Doing it right the first time has some clear advantages ... (assuming there is a need of course). >> In many cases, both domains will also be operated by separate or even independent >> organisations. Not necessarily true in all situations, large providers may want to deploy very large IP backbones on a wholly owned infrastructure. >> That is not to say that both domains may use the same protocols and principles for >> signalling and routing (e.g. MPLS). Routers may even be able to talk to OXCs and request >> additional optical trails. But that still doesn't require an integrated IGP routing >> domain, that includes all routers and IXCs. Now I'm confused, this seems to be the opposite of the statements above ... both domains use the same principles and protocols, but they are not integrated ??? cheers, Eduard >> Perhaps I'm missing something ? >> Thomas From owner-mpls@UU.NET Mon Jan 31 12:32:42 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10545 for ; Mon, 31 Jan 2000 12:32:41 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiakc20514; Mon, 31 Jan 2000 17:32:38 GMT Received: by mail-control.mail.uu.net id QQiakc04090 for mpls-outgoing; Mon, 31 Jan 2000 17:32:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiakc04078 for ; Mon, 31 Jan 2000 17:31:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiakc00716 for ; Mon, 31 Jan 2000 12:31:44 -0500 (EST) Received: from gorilla.mchh.siemens.de by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQiakc06189 for ; Mon, 31 Jan 2000 17:31:43 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 SAA17157; Mon, 31 Jan 2000 18:30:45 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA09307; Mon, 31 Jan 2000 18:31:41 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id <1A5NHV4L>; Mon, 31 Jan 2000 18:31:56 +0100 Message-ID: <3B59676F9ADBD211B5360060086E64EE45E7B7@MCHH237E> From: Theimer Thomas To: "'Metz, E.T.'" Cc: mpls@UU.NET Subject: RE: MPLS and Optical network!! Date: Mon, 31 Jan 2000 18:31:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > >> Of course, there is traffic engineering in the optical domain, and > there > is traffic > >> engineering in the layer 3 domain, but why do they have to be > integrated > ??? After all, > >> the granularities and LSP characteristics are completely different in > both domains. > > If both serve the same purpose, I think they should be integrated. You > could > also integrate e.g. IP and ATM traffic engineering, but I haven't seen > much > of that. Doing it right the first time has some clear advantages ... > (assuming there is a need of course). [Theimer Thomas] What are the advantages ? Why do we have to make things more complex than they need to be (at least initially) ? I can see a lot of benefits in separating the two domains, in terms of fault isolation and scalability. You would need at least one additional level of hierarchy in the IGP domain if you integrate both domains, and that would probably export only an abstracted view of the optical domain anyway. So why don't we solve the optical intradomain problem first, and then think about possible extensions, rather than trying to solve everything at once. > >> That is not to say that both domains may use the same protocols and > principles for > >> signalling and routing (e.g. MPLS). Routers may even be able to talk to > OXCs and request > >> additional optical trails. But that still doesn't require an integrated > IGP routing > >> domain, that includes all routers and IXCs. > > Now I'm confused, this seems to be the opposite of the statements above > ... > both domains use the same principles and protocols, but they are not > integrated ??? [Theimer Thomas] That is exactly my point. Routers should talk to routers, and OXCs should talk to OXCs. They may both talk some dialect of MPLS, but they can be in different and independent domains. Everyone just seems to imply that a fully integrated control plane model is the only desirable option. I don't think so, and I am still looking for arguments why a fully integrated model is needed at all. Perhaps a data centric IP only network might be such an example where it makes sense. Thomas From owner-mpls@UU.NET Mon Jan 31 12:37:22 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10659 for ; Mon, 31 Jan 2000 12:37:21 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiakc23278; Mon, 31 Jan 2000 17:37:18 GMT Received: by mail-control.mail.uu.net id QQiakc04295 for mpls-outgoing; Mon, 31 Jan 2000 17:36:46 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiakc04288 for ; Mon, 31 Jan 2000 17:36:40 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiakc07189 for ; Mon, 31 Jan 2000 12:36:35 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiakc09251 for ; Mon, 31 Jan 2000 17:36:35 GMT Received: from mjork-pc (mjork-pc.avici.com [10.1.2.168]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id MAA03610 for ; Mon, 31 Jan 2000 12:36:33 -0500 (EST) Message-Id: <4.1.20000131120723.00b1a3f0@mailhost.avici.com> X-Sender: mjork@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 31 Jan 2000 12:36:34 -0500 To: mpls@UU.NET From: Markus Jork Subject: PHP and architecture draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk I just noticed that the architecture draft (draft-ietf-mpls-arch-06.txt) seems to be somewhat out of sync with reality. The section on penultimate hop popping says: "Initial label distribution protocol negotiations MUST allow each LSR to determine whether its neighboring LSRS are capable of popping the label stack. A LSR MUST NOT request a label distribution peer to pop the label stack unless it is capable of doing so." Looking at the current label distribution protocols (RSVP and LDP), none of them seems to provide the allegedly mandatory feature to figure out whether a peer is capable of doing PHP. So what should we do about this issue: a) agree that I have misread the I-Ds and just ignore my message, b) change the "MUST" in the architecure document to a "SHOULD" c) or just ignore this section of the architecture document? Fixing the signalling protocols to provide the feature seems to be too bothersome. Markus From owner-mpls@UU.NET Mon Jan 31 13:09:28 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11456 for ; Mon, 31 Jan 2000 13:09:25 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiake29037; Mon, 31 Jan 2000 18:09:21 GMT Received: by mail-control.mail.uu.net id QQiake13446 for mpls-outgoing; Mon, 31 Jan 2000 18:08:46 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiake13439 for ; Mon, 31 Jan 2000 18:08:44 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiake05659 for ; Mon, 31 Jan 2000 13:08:33 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQiake11540 for ; Mon, 31 Jan 2000 18:08:33 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id NAA21269; Mon, 31 Jan 2000 13:08:29 -0500 Date: Mon, 31 Jan 2000 13:08:29 -0500 From: "J. Noel Chiappa" Message-Id: <200001311808.NAA21269@ginger.lcs.mit.edu> To: J.Hopkins@fujitsu.co.uk, mpls@UU.NET Subject: Re: minimising wavelength conversion in MPLambdaS systems Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: John Hopkins > wether lambda-assignment should be integrated with the process of > determing a route for the LmSP, or be a follow-on activity from > determing the route. Well, given your goals, it would be greatly superior for it to be integrated. If not, it could take a while for the algorithm to stumble across a path which also happens to meet the additional wavelength allocation constraints (which will not be available to the initial path selection algorithm). This will especially true as the network size gets larger, and the number of potential paths increases. Indeed, in many routing architectures, you may never get to the path that meets your additional constraint - the routing algorithm won't explore that far in the solution space. > it is very advantageous if the same wavelength can be used along an > entire lightpath traversing many nodes transparently (i.e. with the > same lambda-in and lamba-out) Well, this is certainly more painful to do in a Destination Vector routing architecture (i.e. one that hands out routing tables). Their local decision-making characteristic (in which the decisions about the path are made by a number of independent nodes in parallel) are fundamentally at odds with the global nature of the optimization you're trying to do. (Which doesn't mean it's impossible, because classic Bellman-Ford algorithms minimize path length - a global characteristic - with a local algorithm.) But certain capabilities (e.g. making one pair's path slightly longer to allow another pair to have a path without frequency conversion) can't really be done in DV systems. I would recommend a Map Distribution based routing architecture (i.e. one that distributes network maps as the basic data). > a distributed wavelength usage database for the optical domain ... > (One issue is how to keep this information up to date.) As long as the network is small, this is not an issue. Existing Link-State routing algorithms (a subset of MD algorithms) do this all the time. Noel From owner-mpls@UU.NET Mon Jan 31 13:19:25 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11738 for ; Mon, 31 Jan 2000 13:19:22 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiakf05299; Mon, 31 Jan 2000 18:19:19 GMT Received: by mail-control.mail.uu.net id QQiakf14254 for mpls-outgoing; Mon, 31 Jan 2000 18:18:48 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiakf14249 for ; Mon, 31 Jan 2000 18:18:45 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiakf06900 for ; Mon, 31 Jan 2000 13:18:45 -0500 (EST) Received: from mail.xandl.cso.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.xandl.cso.net [194.106.242.34]) id QQiakf04803 for ; Mon, 31 Jan 2000 18:18:43 GMT Received: from amarhold ([194.106.242.47]) by mail.xandl.cso.net (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100) with SMTP id AAA248; Mon, 31 Jan 2000 19:24:08 +0100 Reply-To: From: "Alexander Marhold" To: "'John Hopkins'" , Subject: RE: minimising wavelength conversion in MPLambdaS systems (was MPLS and Optical) Date: Mon, 31 Jan 2000 19:18:32 +0100 Message-ID: <001301bf6c17$95747c30$2ff26ac2@amarhold.cisco.com> 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 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit John ! What you describe in 1) > 1) a distributed wavelength usage database for the > optical domain (so that source nodes have the information to > compute a lambda that will not lead to blocking on the lightpath) > This could involve protocol support to distribute > wavelength usage status updates between all MPLmS aware nodes > in an optical domain, possibly piggybacking these status > updates in IGP protocol messages. The idea would be that each > node periodically (or following changes in lightpath > topology) sends status updates describing wavelength > allocation on its interfaces. for me your algo looks quite similar to traffic engineering in normal MPLS where the tunnelheadend knows the topology, gets reservation status via ISIS or via OSPF and establishes a path via RSVP. If you take one priority per wavelength and a fictive bandwidth of 1 and a reservation of 1, the headend has the almost the same task as in traffic engineering,only he is not allowed to kickoff another tunnel and he has to look from priority 1 to n to find a possible path through the network. Different is that the priority equals to the label value which is then the same for the whole path. So eventually using a Virtual Switch Controller and the VSI-interface to the OXC a pretty similar algo as in traffic engineering can be used to find a path through the network. The VSCīs could be connected either via the outband network or via one "control" wavelength. When in near future wavelength conversion on the fly is easier the algo can be extended to use that possibility. regards Alexander __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ __/ __/ Dipl.Ing. Alexander Marhold MBA __/ CCIE #3324, CCNP, CCNA, CCDP, CCDA, CCSI #20642 __/ PRO IN __/ Mobile: ++43-(0)664-16 28 234 __/ > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of John > Hopkins > Sent: Monday, January 31, 2000 5:27 PM > To: 'mpls@UU.NET' > Subject: minimising wavelength conversion in MPLambdaS systems > > > Hi All, > > I have been considering label(lambda) allocation in > MPLmS systems supporting wavelength re-use. > > One issue is how to minimise the number of nodes along > a lambda-switched lightpath where wavelength conversion > occurs (or alternatively how to maximise the number of nodes > though which the lightpath can traverse transparently). > > Another issue is how to determine the most appropriate > lambda to use for a particular lightpath, and wether > lambda-assignment should be integrated with the process of > determing a route for the LmSP, or be a follow-on activity > from determing the route. Maxmimum lambda-reuse in the > network would be a goal in order to support more LmSPs than > the number of available wavelengths. > > In ordinary MPLS, LSRs swap input and output labels and > it is assumed that there is negliable cost in changing an > input label (e.g. VPI/VCI) to an output label. When a > wavelength is used as a label, lambda-swapping between > different lamba-in and lambda-out implies a wavelength > conversion device, which is a scarce resource. In future all > optical networks, wavelength conversion will very likely be > required at some locations, such as Optical Cross Connects > (OXC) sites. However in simpler ring-based optical networks > where an optical path may traverse a number of relatively > low-cost Optical Add-Drop-Mux (OADM) devices it is very > advantageous if the same wavelength can be used along an > entire lightpath traversing many nodes transparently (i.e. > with the same lambda-in and lamba-out). Even in OXC or OADM > systems supporting wavelength conversion, it is desirable to > use it sparingly. > > This would require that the source node has either :- > a) the knowledge of other nodes' optical switching > limitations (e.g. advertised lambda add/drop/passthru range), > AND the currrent status of other nodes' wavelength usage. > This is the information needed by a source node to compute > the most appropriate lambda for the lightpath (e.g. using > minimal number of required wavelength conversions as one > constraint), or > b) there is some type of crankback mechanism in MPLmS > LDP which can be invoked when one node on the setup path > discovers that the lightpath cannot be established because > the initial lambda allocated for the lightpath by the source > node is already in use by another lightpath at that node, or > c) require that each OADM node supports wavelength > conversion (ugh) so that blocking can be avoided by a > wavelength conversion. > > I prefer the 1st approach for a ring-based network, > complemented by wavelength conversion at OXC sites between > rings. One possible soultion would invlove the following :- > > 1) a distributed wavelength usage database for the > optical domain (so that source nodes have the information to > compute a lambda that will not lead to blocking on the lightpath) > This could involve protocol support to distribute > wavelength usage status updates between all MPLmS aware nodes > in an optical domain, possibly piggybacking these status > updates in IGP protocol messages. The idea would be that each > node periodically (or following changes in lightpath > topology) sends status updates describing wavelength > allocation on its interfaces. (One issue is how to keep this > information up to date.) If this information is received by > all nodes in an optical domain (such as a ring), then all > nodes in the domain have a domain-wide view of lightpath > assignments and lambda usage and are in a position to compute > 'optimal' routes and lambda-assignments for new lightpaths. > That is to say they would be in a position to compute a > non-blocking shortest lightpath with minimal (hopefully zero) > requirement for wavelength conversion. Either these two > processes could be seperate (e.g. route determination > firstbased on shortest-path, followed by lamnda-assignement) or the! > ! > ! > ! > y could be integrated in a multiple-constraint search for > non-blocking path. > > 2) a wider distribution of lambda-range advertisements > than just neigbour-to-neighbour . > Basic MPLS LDP initialisation supports the exchange of > this information between adjecent LSRs which is fine if all > nodes can swap labels. However this won't work when > non-adjacent ingress/egress nodes are the only ones > add/dropping the lambda, and there is a desire for the > intervening transit nodes to pass the lambda through > transparently. Without this information about distant nodes, > there is a danger that a lambda-could be assigned for a > lightpath that is non-blocking at all intervening nodes, but > which can't be dropped by the egress node because it is > outside its advertised lambda-range. A possible solution is > extension of the LmDP initialisation phase to broadcast/flood > lambda-range advertisements to all nodes in a domain. This > then allows a source node to know the lambda-swapping > limititations of all the nodes through which a lightpath may > traverse, and take this into account when establishing the > route and lambda that the lightpath should use. Note that > this is only nec! > ! > ! > ! > essary if nodes on the path have differing capabilities, e.g. > can add/drop different subsets of the complete range of > lambdas supported in a network, but this may be a likely situation. > > Any thoughts? > > John Hopkins > From owner-mpls@UU.NET Mon Jan 31 14:55:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14435 for ; Mon, 31 Jan 2000 14:55:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiakl14525; Mon, 31 Jan 2000 19:55:00 GMT Received: by mail-control.mail.uu.net id QQiakl28076 for mpls-outgoing; Mon, 31 Jan 2000 19:54:28 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiakl28066 for ; Mon, 31 Jan 2000 19:54:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiakl20490 for ; Mon, 31 Jan 2000 14:54:05 -0500 (EST) Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQiakl04603 for ; Mon, 31 Jan 2000 19:54:01 GMT Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 31 Jan 2000 13:53:05 -0600 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D9DTF60Z; Mon, 31 Jan 2000 14:53:00 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXA2X0Z; Mon, 31 Jan 2000 14:52:59 -0500 Message-ID: <3895E81A.7758EAA8@americasm01.nt.com> Date: Mon, 31 Jan 2000 14:52:58 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS: draft-ashw-mpls-te-feed-01.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit You will find an updated copy of this draft in: http://www.ietf.org/internet-drafts/draft-ashw-mpls-te-feed-01.txt I have tried to address Joel's concern about flooding fed-back information and talked a bit about Toni's concern about a race condition between fed-back and flooded information. Other issues or concerns? Peter From owner-mpls@UU.NET Mon Jan 31 15:37:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15220 for ; Mon, 31 Jan 2000 15:37:45 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiako02050; Mon, 31 Jan 2000 20:37:41 GMT Received: by mail-control.mail.uu.net id QQiako09134 for mpls-outgoing; Mon, 31 Jan 2000 20:37:08 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiako09124 for ; Mon, 31 Jan 2000 20:37:04 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiako26586 for ; Mon, 31 Jan 2000 15:36:52 -0500 (EST) Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQiako09662 for ; Mon, 31 Jan 2000 20:36:52 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id PAA21955; Mon, 31 Jan 2000 15:36:50 -0500 Date: Mon, 31 Jan 2000 15:36:50 -0500 From: "J. Noel Chiappa" Message-Id: <200001312036.PAA21955@ginger.lcs.mit.edu> To: mpls@UU.NET Subject: RE: MPLS and Optical network Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: "Alexander Marhold" > optical packet recognition ... and buffering is future and would lead > to an pure optical router Actually, I had a chat with an optical expert (someone who'd worked with Edwin? Land, IIRC) who struck me as very sharp, and his take was that for fundamental reasons of physics, we're unlikely to ever see pure optical processing. His explanation (which sounds plausible to me) is that photons interact more weakly than do electrons, so it takes longer (timewise) for two photons to complete an interaction. So you'll never get the speed (and thus size) out of all-optical components that you will out of electronic components. Now, maybe some genius will figure out a way around this (like the multiple wavelength pure optical amplifiers - now *there's* a major stroke of genius), but until I see the counterexample, I think his reasoning is powerful. Noel From owner-mpls@UU.NET Mon Jan 31 15:59:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15539 for ; Mon, 31 Jan 2000 15:59:24 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiakp22853; Mon, 31 Jan 2000 20:59:20 GMT Received: by mail-control.mail.uu.net id QQiakp10976 for mpls-outgoing; Mon, 31 Jan 2000 20:58:48 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiakp10953 for ; Mon, 31 Jan 2000 20:58:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiakp07526 for ; Mon, 31 Jan 2000 15:58:31 -0500 (EST) Received: from ntserver4.ftrc.fujitsu.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [193.119.135.150]) id QQiakp22253 for ; Mon, 31 Jan 2000 20:58:30 GMT Received: by NTSERVER4 with Internet Mail Service (5.5.2448.0) id ; Mon, 31 Jan 2000 20:57:42 -0000 Message-ID: From: John Hopkins To: "'J. Noel Chiappa'" Cc: "'mpls@UU.NET'" , "'Alexander Marhold'" Subject: RE: minimising wavelength conversion in MPLmS systems Date: Mon, 31 Jan 2000 20:57:36 -0000 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-mpls@UU.NET Precedence: bulk Hi Noel, I appreciate your point. Integrating wavelength routing and wavelength allocation would yield more search space than performing a distinct shortest path route determination followed by a wavelength allocation for the returned route. i.e. An integrated routing/wavelength allocation scheme would provide superior results by exploring alternative routes on which non-blocking lambdas may be available. In a ring network there are not many routes to consider (there are 2 ways around the ring), so the extra effort of introducing an additional constraint in the search is not onerous. Obviously the search space could get much larger in more complicated topologies. The chances of finding a non-blocking wavelength will be greatly decreased in a very large network, so necessitating means to avoid blocking, i.e. wavelength conversion or searches of multiple alternative routes. However that may still be missing the bigger picture - if one is optimising only for the next lightpath being setup, and there are in fact a whole sequence of lightpaths being established to create a lambda-mesh then it may not help. i.e. after optimally routing & wavelength allocating a couple of lightpaths independently you may have created blocking conditions for subsequent lightpaths that could have been avoided had you considered the entire sequence before hand. Of course one could extend this argument and conclude that a distributed architecture with each MPLmS node setting up lightpaths independently of one other is always going to yield non-optimal results, but that is probably overly pessimistic. There is at least one paper "Dynamic wavelength allocation in all-optical ring networks" by O. Gerstel & S. Kutton (see http://www.research.ibm.com/wdm/route/dyn.ps.Z) that considers a heuristic-based wavelength allocation strategy for rings in which wavelength conversion is not possible. By intelligently allocating wavelengths to routes based on the length of the lightpath (no of hops) they aim to get a lot of wavelength re-use and avoid the problem above. Distributed MPLmS control on each OADM using a shortest path route determination procedure for each lightpath setup request, followed by such a heuristic for wavelength allocation would probably work well for creating router meshes in a ring network, but might not handle other applications well. It may be extendable using hierarchy, i.e. local lambda routing/allocation for lightpath segments in each ring uing such a heuristic together with exploitation of lambda-swapping/wavelength conversion on OXCs to interconnect rings. I would recommend a Map Distribution based routing architecture (i.e. one that distributes network maps as the basic data). > a distributed wavelength usage database for the optical domain ... > (One issue is how to keep this information up to date.) As long as the network is small, this is not an issue. Existing Link-State routing algorithms (a subset of MD algorithms) do this all the time. Sounds good. I am wondering if there is a way to support hierarchy in such maps in order that scaling can be achieved. i.e. map for each ring, and an abbreviated map for the network interconnecting rings, etc. i.e. something like hierarchy in pnni. I am thinking that wavelength allocation could be an important problem that the map would help to solve in a local domain such as a ring, but providing that wavelength conversion is available at the ndoe (e.g. OXC) interconnecting rings then it is not necessary for the source node to know wavelength usage outside its domain. Cheers, John Hopkins > -----Original Message----- > From: J. Noel Chiappa [SMTP:jnc@ginger.lcs.mit.edu] > Sent: 31 January 2000 18:08 > To: J.Hopkins@fujitsu.co.uk; mpls@UU.NET > Cc: jnc@ginger.lcs.mit.edu > Subject: Re: minimising wavelength conversion in MPLambdaS systems> > > > From: John Hopkins > > > wether lambda-assignment should be integrated with the process of > > determing a route for the LmSP, or be a follow-on activity from > > determing the route. > > Well, given your goals, it would be greatly superior for it to be integrated. > If not, it could take a while for the algorithm to stumble across a path which > also happens to meet the additional wavelength allocation constraints (which > will not be available to the initial path selection algorithm). This will > especially true as the network size gets larger, and the number of potential > paths increases. Indeed, in many routing architectures, you may never get to > the path that meets your additional constraint - the routing algorithm won't > explore that far in the solution space. > > > it is very advantageous if the same wavelength can be used along an > > entire lightpath traversing many nodes transparently (i.e. with the > > same lambda-in and lamba-out) > > Well, this is certainly more painful to do in a Destination Vector routing > architecture (i.e. one that hands out routing tables). Their local > decision-making characteristic (in which the decisions about the path are made > by a number of independent nodes in parallel) are fundamentally at odds with > the global nature of the optimization you're trying to do. (Which doesn't mean > it's impossible, because classic Bellman-Ford algorithms minimize path length > - a global characteristic - with a local algorithm.) > > But certain capabilities (e.g. making one pair's path slightly longer to allow > another pair to have a path without frequency conversion) can't really be done > in DV systems. I would recommend a Map Distribution based routing architecture > (i.e. one that distributes network maps as the basic data). > > > a distributed wavelength usage database for the optical domain ... > > (One issue is how to keep this information up to date.) > > As long as the network is small, this is not an issue. Existing Link-State > routing algorithms (a subset of MD algorithms) do this all the time. > > Noel From owner-mpls@UU.NET Mon Jan 31 16:44:14 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16429 for ; Mon, 31 Jan 2000 16:44:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiaks20027; Mon, 31 Jan 2000 21:44:06 GMT Received: by mail-control.mail.uu.net id QQiaks21687 for mpls-outgoing; Mon, 31 Jan 2000 21:43:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiaks21680 for ; Mon, 31 Jan 2000 21:43:24 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiaks14364 for ; Mon, 31 Jan 2000 16:43:23 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiaks12695 for ; Mon, 31 Jan 2000 21:43:22 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id QAA19632; Mon, 31 Jan 2000 16:43:21 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id QAA02734; Mon, 31 Jan 2000 16:45:18 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200001312145.QAA02734@curtis-lt.avici.com> To: Theimer Thomas cc: "'Tony Li'" , curtis@avici.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS and Optical network!! In-reply-to: Your message of "Mon, 31 Jan 2000 17:13:51 +0100." <3B59676F9ADBD211B5360060086E64EE45E7B4@MCHH237E> Date: Mon, 31 Jan 2000 16:45:18 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3B59676F9ADBD211B5360060086E64EE45E7B4@MCHH237E>, Theimer Thomas wr ites: > > Where we should be going is to extend our signaling protocol so that we > > can > > automate traffic engineering for both the MPLS and optical planes. This > > implies > > that the OXCs participate (possibly through a proxy) in the signaling > > protocols, > > that optical plane configuration information is carried in our IGPs, and > > that > > traffic engineering path computation also consider optical path > > establishment as > > well as LSP establishment. > > [Theimer Thomas] Why do you think that it's necessary for OXCs to > be in the same IGP routing domain as routers ? OXCs are not used > for any kind of hop-hop forwarding, so there is no immediate need > for them to share their topology information with routers. The IP community has been down this road before with IP over ATM. When you hear that MPLS is not just ATM all over again but with bigger cells but rather a goal is to not make the same mistakes made in ATM, the decoupling of IP from the underlying layer 2 was one of those mistakes. To make network routing scalable a full mesh is not a feasible approach. Beyond some size, routing hierarchy must be introduced, meaning that routers are stategically placed within the topology. In this case traffic engineered paths may traverse more than one optical domain or region. An example is where regional or metro optical domains exists and routers sit at the edge of these and are part of a national (or larger) optical domain. There may be a full mesh within the higher level domain and there may be full meshes within each regional optical domain. The routers at these boeders may do OEO, buffering, and routing, or in a vision in of all optical they may in effect splice lambdas between domains, avoiding the OEO. Even with that vision, connecting a few hundred routers together in an optical full mesh (without putting full fledged routers in the middle) has the problem of needing N-1 interfaces per router for a mesh of N routers. ISP networks have a core with order low 10s of core routers. It is feasible to terminate 10s of lambdas there to accommodate the core and terminate lambdas to the high 10s of routers in the adjacent region. As you can imagine some big routers are needed. Altogether there are order 1000 access routers in the larger ISPs (terminating order 10s of thousands of CPE routers plus racks of dial equipment) so N and N-1 are big. It is not feasible to terminate on the order of 1000 lambdas on these access routers plus the IGP would either be unstable or converge slowly. The only way the order 1000 lambdas could be terminated cost effectively is if some form of optical TDM worked. If not, then big routers in the middle can't be avoided. (Of course, not that I want to see them avoided. :) > That is not to say that both domains may use the same protocols and > principles for signalling and routing (e.g. MPLS). Routers may even > be able to talk to OXCs and request additional optical trails. But > that still doesn't require an integrated IGP routing domain, that > includes all routers and IXCs. The IGP provides feedback if the layout is at all dynamic. If the layout of active and backup paths is entirely done offline, then the IGP still serves to reduce the number of IGP adjacencies and keep the IGP flooding as efficient as it can be. The optical paths serve as "shortcuts" across the IGP. > Perhaps I'm missing something ? Perhaps not. Or at least very little. > Thomas Curtis From owner-mpls@UU.NET Mon Jan 31 17:30:51 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17207 for ; Mon, 31 Jan 2000 17:30:50 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiakw10384; Mon, 31 Jan 2000 22:30:48 GMT Received: by mail-control.mail.uu.net id QQiakw03287 for mpls-outgoing; Mon, 31 Jan 2000 22:30:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiakw03279 for ; Mon, 31 Jan 2000 22:30:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiakw20945 for ; Mon, 31 Jan 2000 17:30:23 -0500 (EST) Received: from bells.cs.ucl.ac.uk by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: bells.cs.ucl.ac.uk [128.16.5.31]) id QQiakw17216 for ; Mon, 31 Jan 2000 22:30:22 GMT Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 31 Jan 2000 22:30:16 +0000 To: "J. Noel Chiappa" cc: mpls@UU.NET Subject: Re: MPLS and Optical network In-reply-to: Your message of "Mon, 31 Jan 2000 15:36:50 EST." <200001312036.PAA21955@ginger.lcs.mit.edu> Date: Mon, 31 Jan 2000 22:30:13 +0000 Message-ID: <8891.949357813@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-mpls@UU.NET Precedence: bulk In message <200001312036.PAA21955@ginger.lcs.mit.edu>, "J. Noel Chiappa" typed: >> > From: "Alexander Marhold" >> >> > optical packet recognition ... and buffering is future and would lead >> > to an pure optical router >> >>Actually, I had a chat with an optical expert (someone who'd worked with >>Edwin? Land, IIRC) who struck me as very sharp, and his take was that for >>fundamental reasons of physics, we're unlikely to ever see pure optical >>processing. >> two points of disagreement 1/ quantum computing 2/ stubornness i put it 2 years before someone does some decent header processing in pure optical components. buffering is easy btw, but thats another story...the issue is to forget about the cost of memory. think about throwing 7 orders of magnitude too much at the proble but it costing 9 orders of magnitude less. >>His explanation (which sounds plausible to me) is that photons interact more >>weakly than do electrons, so it takes longer (timewise) for two photons to >>complete an interaction. So you'll never get the speed (and thus size) out of >>all-optical components that you will out of electronic components. >> >>Now, maybe some genius will figure out a way around this (like the multiple >>wavelength pure optical amplifiers - now *there's* a major stroke of genius), >>but until I see the counterexample, I think his reasoning is powerful. >> >> Noel cheers jon From owner-mpls@UU.NET Mon Jan 31 17:33:08 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17306 for ; Mon, 31 Jan 2000 17:33:08 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiakw12187; Mon, 31 Jan 2000 22:33:10 GMT Received: by mail-control.mail.uu.net id QQiakw03462 for mpls-outgoing; Mon, 31 Jan 2000 22:32:50 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiakw03452 for ; Mon, 31 Jan 2000 22:32:41 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiakw21284 for ; Mon, 31 Jan 2000 17:32:24 -0500 (EST) Received: from mlsrv1.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiakw11643 for ; Mon, 31 Jan 2000 22:32:24 GMT Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id RAA22554; Mon, 31 Jan 2000 17:32:23 -0500 (EST) Received: from curtis-lt.avici.com (localhost [127.0.0.1]) by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id RAA02818; Mon, 31 Jan 2000 17:34:20 -0500 (EST) (envelope-from curtis@curtis-lt.avici.com) Message-Id: <200001312234.RAA02818@curtis-lt.avici.com> To: John Hopkins cc: "'mpls@UU.NET'" Reply-To: curtis@avici.com Subject: Re: minimising wavelength conversion in MPLambdaS systems In-reply-to: Your message of "Mon, 31 Jan 2000 16:27:13 GMT." Date: Mon, 31 Jan 2000 17:34:19 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , John Hopkins wri tes: [...snip...] > > Any thoughts? > > John Hopkins John, For dynamic layout, the traffic engineering extensions would need to advertise a bitmap of lambdas (with a bitmap size so that the bitmap is extensible rather than fixed size). There is already some interesting work in the area of optimally routing LSPs and the harder problem of optimally routing active and backup paths. Lakshman has two good papers on the Infocom web sight. For example his Minimum Interference Routing Algorithm (MIRA) is shown to produce significantly better results than Widest Shortest Path (WSP). I havn't done a tour of the literature to find the best published algorithms to do optical routing (I don't think there is much). The problem gets a lot harder if you add the restrictions that you have to take the same wavelength. If you put OEOs into the mesh, the chances of not finding a path is reduced but it gets even harder to compute optimal paths. For example, here is a naive way to compute paths. Foreach wavelength, determine which links are available. Sort the links and compute a digest over the set of links. Look in a cache for an SPF result matching the digest. If none is found, do an SPF. The link costs can be set using something like MIRA (costs need only be determined once) with the costs taking into account how many lambdas remain on each link. The cache of SPF results at least reduces the number of SPF that must be computed. Each unique SPF produces a best route. The best of these can be choosen. This already sounds close to infeasible for a very high number of lambdas. Adding OEOs makes the problem still more complex. Offline computations might be required. The disadvantage is that these typically cover single failures and require lengthy recomputation when multiple failures do occur. [Multiple fiber cuts all too often happen. Sometimes lots of capacity disappears at the same time. Train derailments along railway right of ways (Amtrak near West Orange). Bridge repairs (Raritan River). Floods putting facilities under water (St Louis area). Exploding rat in the primary to backup power cutover switch (Bay Area). Emergency power shut down due to gas line leak. Fiber cut due to gas line repair. These are some of the most massive and better known ones in the last few years. The list goes on. People in Internet operations (or telco) know about tons of multiple fiber failures.] Those are some of my thoughts on this. Any pointers to papers on algorithms for layout through optical cores would be greatly appreciated. Curtis ps- I thought IRTF did research. Isn't MPLS in the IETF? From owner-mpls@UU.NET Mon Jan 31 21:17:58 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20427 for ; Mon, 31 Jan 2000 21:17:57 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiall13815; Tue, 1 Feb 2000 02:17:51 GMT Received: by mail-control.mail.uu.net id QQiall16706 for mpls-outgoing; Tue, 1 Feb 2000 02:17:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiall16701 for ; Tue, 1 Feb 2000 02:17:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiall12660 for ; Mon, 31 Jan 2000 21:17:18 -0500 (EST) Received: from inet-tsb.toshiba.co.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: inet-tsb.toshiba.co.jp [202.33.96.40]) id QQiall13411 for ; Tue, 1 Feb 2000 02:17:16 GMT Received: from tis2.tis.toshiba.co.jp by inet-tsb.toshiba.co.jp (8.8.8/3.3W9-04/12/95) id LAA13476; Tue, 1 Feb 2000 11:16:59 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id LAA29868; Tue, 1 Feb 2000 11:16:57 +0900 (JST) Received: by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id LAA04647; Tue, 1 Feb 2000 11:16:56 +0900 (JST) To: mjork@avici.com Cc: mpls@UU.NET Subject: Re: PHP and architecture draft In-Reply-To: Your message of "Mon, 31 Jan 2000 12:36:34 -0500" <4.1.20000131120723.00b1a3f0@mailhost.avici.com> References: <4.1.20000131120723.00b1a3f0@mailhost.avici.com> X-Mailer: Mew version 1.92 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002010216.LAA04647@toshiba.co.jp> Date: Tue, 01 Feb 2000 11:18:22 +0900 From: Yoshihiro Ohba X-Dispatcher: imput version 980905(IM100) Lines: 34 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Markus, The issue was once discussed on the mailing list, and the following paragraph was added to section 5 of the LDP specification. - Section 2.16 of the MPLS architecture [ARCH] requires that the initial label distribution protocol negotiation between peer LSRs enable each LSR to determine whether its peer is capable of popping the label stack. This version of LDP assumes that LSRs support label popping for all link types except ATM and Frame Relay. A future version may specify means to make this determination part of the session initiation negotiation. Hope this helps. Yoshihiro Ohba > I just noticed that the architecture draft (draft-ietf-mpls-arch-06.txt) > seems to be somewhat out of sync with reality. > The section on penultimate hop popping says: > "Initial label distribution protocol negotiations MUST allow each LSR to determine whether its neighboring LSRS are capable of popping the label stack. A LSR MUST NOT request a label distribution peer to pop the label stack unless it is capable of doing so." > Looking at the current label distribution protocols (RSVP and LDP), none of > them seems to provide the allegedly mandatory feature to figure out whether > a peer is capable of doing PHP. > So what should we do about this issue: > a) agree that I have misread the I-Ds and just ignore my message, > b) change the "MUST" in the architecure document to a "SHOULD" > c) or just ignore this section of the architecture document? > Fixing the signalling protocols to provide the feature seems to be too bothersome. > Markus From owner-mpls@UU.NET Mon Jan 31 21:59:14 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21723 for ; Mon, 31 Jan 2000 21:59:14 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQialn04607; Tue, 1 Feb 2000 02:59:10 GMT Received: by mail-control.mail.uu.net id QQialn18678 for mpls-outgoing; Tue, 1 Feb 2000 02:58:50 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQialn18673 for ; Tue, 1 Feb 2000 02:58:49 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQialn15525 for ; Mon, 31 Jan 2000 21:58:35 -0500 (EST) From: tran2@indiatimes.com Received: from sparc.eunet.si by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: sparc.EUnet.si [193.77.2.66]) id QQialn28589 for ; Tue, 1 Feb 2000 02:58:35 GMT Received: from comp6 (98AABC47.ipt.aol.com [152.170.188.71]) by sparc.eunet.si (SInet) with SMTP id EAA25078; Tue, 1 Feb 2000 04:06:52 +0100 Date: Tue, 1 Feb 2000 04:06:52 +0100 Message-Id: <200002010306.EAA25078@sparc.eunet.si> To: reps@hotmail.com Subject: Only 14 Good Reps Needed ... Sender: owner-mpls@UU.NET Precedence: bulk

ONLY 14 GOOD REPS NEEDED
We are looking to train 14 individuals to work from their
home in the Travel Industry distributing information
and promoting corporate awareness.

Huge Compensation Plan Available - For The Right Person
Enjoy Working From The Comfort Of Your Own Home

Click Here Now

From owner-mpls@UU.NET Mon Jan 31 22:17:07 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21882 for ; Mon, 31 Jan 2000 22:17:06 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQialp13478; Tue, 1 Feb 2000 03:17:03 GMT Received: by mail-control.mail.uu.net id QQialp27560 for mpls-outgoing; Tue, 1 Feb 2000 03:16:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQialp27554 for ; Tue, 1 Feb 2000 03:16:36 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQialp08615 for ; Mon, 31 Jan 2000 22:16:35 -0500 (EST) Received: from morris.canarie.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: server.canarie.ca [209.217.86.48]) id QQialp07635 for ; Tue, 1 Feb 2000 03:16:35 GMT Received: from micky (slip-32-102-134-150.on.ca.prserv.net [32.102.134.150]) by morris.canarie.ca (8.9.3+Sun/8.9.3) with SMTP id WAA04889; Mon, 31 Jan 2000 22:16:27 -0500 (EST) Reply-To: From: "Bill St. Arnaud" To: "Andrew Bender" , Cc: , "'J. Noel Chiappa'" , , "Tony Li" Subject: There will be lots of papers at OFC on all optical routing Date: Mon, 31 Jan 2000 22:15:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3895A876.6EEF0930@tns-inc.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Andrew: If you are planning to attend OFC (Baltimore March) I think you will find a number of research papers along the topics you discuss. All optical label "burst" switching is not that far off, particularly for wavelength steering. However, I still think OEO will rule because of greater degree of flexibility. Optical label switching is actually very limited (e.g queue management, error detection, buffer overflow detection, etc) and until we have optical computers it has little advantage. Bill Bill St. Arnaud Senior Director Network Projects CANARIE bill.st.arnaud@canarie.ca +1 613 785-0426 > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Andrew > Bender > Sent: January 31, 2000 10:21 AM > To: mpls@UU.NET > Cc: Alexander.Marhold@xandl.cso.net; 'J. Noel Chiappa'; > curtis@avici.com; Tony Li > Subject: Re: MPLS and Optical network!! > > > Are the obstacles to use of Lithium Niobate or nonlinear optical > materials really that great? > > As for buffering, perhaps ferroelectrics (BaTiO3) and creative use of > tuned "delay lines" or refractors could be applied to the buffering > problem... relaxation time, variable PDUs obviously complicate this, > at a minimum. I suspect that a some closed loop between upstream and > dowstream O-E-O stages would be more immediately practical. > > Wow. I probably just blew a load of patentable stuff... (or maybe > not!) :P > > Regards, > Andrew Bender > tns-inc.com > > > From tony1@home.net Mon Jan 31 07:02:39 2000 > > Date: Sun, 30 Jan 2000 17:56:12 -0800 > > From: Tony Li > > To: curtis@avici.com > > Cc: Alexander.Marhold@xandl.cso.net, 'J. Noel Chiappa' > , > > mpls@UU.NET > > Subject: Re: MPLS and Optical network!! > > > > > Unless I'm totally out of it, we're quite a long way from all optical > > > wavelegth conversion and buffering light packets. > > > > I concur. > > > > Where we should be going is to extend our signaling protocol so > that we can > > automate traffic engineering for both the MPLS and optical > planes. This implies > > that the OXCs participate (possibly through a proxy) in the > signaling protocols, > > that optical plane configuration information is carried in our > IGPs, and that > > traffic engineering path computation also consider optical path > establishment as > > well as LSP establishment. > > > > My $.02, > > Tony > > > > > From owner-mpls@UU.NET Mon Jan 31 22:17:11 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21893 for ; Mon, 31 Jan 2000 22:17:10 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQialp08114; Tue, 1 Feb 2000 03:17:11 GMT Received: by mail-control.mail.uu.net id QQialp27563 for mpls-outgoing; Tue, 1 Feb 2000 03:16:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQialp27555 for ; Tue, 1 Feb 2000 03:16:37 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQialp08605 for ; Mon, 31 Jan 2000 22:16:23 -0500 (EST) Received: from morris.canarie.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: server.canarie.ca [209.217.86.48]) id QQialp13006 for ; Tue, 1 Feb 2000 03:16:23 GMT Received: from micky (slip-32-102-134-150.on.ca.prserv.net [32.102.134.150]) by morris.canarie.ca (8.9.3+Sun/8.9.3) with SMTP id WAA04881; Mon, 31 Jan 2000 22:16:19 -0500 (EST) Reply-To: From: "Bill St. Arnaud" To: "Richard Barnett" Cc: Subject: RE: MPLS and Optical network - a number of alternate solutions Date: Mon, 31 Jan 2000 22:15:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <00Jan30.164922est.115201@gatekeeper.siroccosystems.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Richard: I note with interest that you are with Sirocco which has announced an edge optical device. MPLS and MPLmS and there many variants are not the only possible solutions for controlling wavelengths: Here are the MPLS solutions: 1. OEO where the SONET OC-x is the actual channel mapped to the LSP. This is the most common implementation of todays "optical" switches. 2. Wavelength routing and TE with MPLmS. Again OEO to decode label and forward packets. Control of wavelengths is for provisioning and TE purposes. 3. Label "burst" switching for initially wavelength steering and maybe in the future per flow or per packet forwarding in an all optical environment. All the above solutions are generally intended for single domain IGP networks. We are also exploring non-MPLS solution for EGP peering and interconnection using concepts developed in distributed IX: 1. Wavelength Route Arbiter to manage optical peers, wavelength re-use, disconnects and autonmous joins in distributed optical IX cloud with BGP speaking peers 2. iBGP mapping to wavelengths for exterior transit of optical connected networks Bill Bill St. Arnaud Senior Director Network Projects CANARIE bill.st.arnaud@canarie.ca +1 613 785-0426 > -----Original Message----- > From: Richard Barnett [mailto:richard.barnett@siroccosystems.com] > Sent: January 30, 2000 4:49 PM > To: 'Bill.St.Arnaud@canarie.ca' > Cc: mpls@UU.NET > Subject: RE: MPLS and Optical network - one possible solution is burst > switching > > > Bill, > > > The MPLS packet label is carried out of band in a separate wavelength. > > Packet switching to different wavelengths and wavelength > > merging is done at > > the optical level. The OXC decodes in the optical domain the > > burst label. > > The main data channels are put through a small time delay > > fiber so that > > burst label can be decoded and OXC wavelength switch can be set up. > > > > It's a very interesting approach but I think that a possible problem with > this is where contention occurs at the egress port - i.e. if multiple > packets are received that need to egress on the same port and > wavelength at > the same time. Some sort of optical buffering and queue control would be > needed to resolve this if I understand the situation correctly. An OTDM > approach would avoid this problem at the cost of relatively > static bandwidth > allocation. This may not suit all applications but its simplicity > does have > attractions. > > Richard. > > ------------------------------------------------------------- > Richard Barnett > VP of System Architecture, Sirocco Systems. > Tel: 203 269 9919 x 126 Fax: 203 269 8291 > Email: richard.barnett@siroccosystems.com > > From owner-mpls@UU.NET Mon Jan 31 23:00:57 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23390 for ; Mon, 31 Jan 2000 23:00:56 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQials04275; Tue, 1 Feb 2000 04:00:52 GMT Received: by mail-control.mail.uu.net id QQials00331 for mpls-outgoing; Tue, 1 Feb 2000 04:00:31 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQials00135 for ; Tue, 1 Feb 2000 04:00:23 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQials20176 for ; Mon, 31 Jan 2000 23:00:21 -0500 (EST) Received: from pilot006.cl.msu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilot006.cl.msu.edu [35.9.5.106]) id QQials03838 for ; Tue, 1 Feb 2000 04:00:18 GMT Received: from cse.msu.edu ([35.10.17.48]) by pilot006.cl.msu.edu (8.9.1a/8.9.1) with ESMTP id XAA53970; Mon, 31 Jan 2000 23:00:02 -0500 Message-ID: <3893B89B.4EF8202B@cse.msu.edu> Date: Sat, 29 Jan 2000 23:05:47 -0500 From: Vasu Vuppala X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Markus Jork , mpls@UU.NET Subject: Re: PHP and architecture draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Markus, check http://cell.onecall.net/mhonarc/mpls/1999-Jun/msg00008.html and follow the thread. - vasu --- Markus Jork wrote: > I just noticed that the architecture draft (draft-ietf-mpls-arch-06.txt) > seems to be somewhat out of sync with reality. > The section on penultimate hop popping says: > > "Initial label distribution protocol negotiations MUST allow each LSR to > determine whether its neighboring LSRS are capable of popping the label > stack. A LSR MUST NOT request a label distribution peer to pop the label > stack unless it is capable of doing so." > > Looking at the current label distribution protocols (RSVP and LDP), none of > them seems to provide the allegedly mandatory feature to figure out whether > a peer is capable of doing PHP. > > So what should we do about this issue: > a) agree that I have misread the I-Ds and just ignore my message, > b) change the "MUST" in the architecure document to a "SHOULD" > c) or just ignore this section of the architecture document? > Fixing the signalling protocols to provide the feature seems to be too > bothersome. > > Markus > From owner-mpls@UU.NET Mon Jan 31 23:13:30 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23519 for ; Mon, 31 Jan 2000 23:13:30 -0500 (EST) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQials05270; Tue, 1 Feb 2000 04:13:32 GMT Received: by mail-control.mail.uu.net id QQials07871 for mpls-outgoing; Tue, 1 Feb 2000 04:13:11 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQials07862 for ; Tue, 1 Feb 2000 04:13:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQials21283 for ; Mon, 31 Jan 2000 23:12:58 -0500 (EST) From: markk@sg.ibm.com Received: from ausmtp01.au.ibm.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ausmtp01.au.ibm.COM [202.135.136.97]) id QQials04782 for ; Tue, 1 Feb 2000 04:12:48 GMT Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id PAA135804 for ; Tue, 1 Feb 2000 15:12:12 +1100 Received: from d73mta04.au.ibm.com (f06n04s [9.185.166.98]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id PAA39764 for ; Tue, 1 Feb 2000 15:12:40 +1100 Received: by d73mta04.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256878.00172077 ; Tue, 1 Feb 2000 15:12:36 +1100 X-Lotus-FromDomain: IBMSG@IBMAU To: Markus Jork cc: mpls@UU.NET Message-ID: Date: Tue, 1 Feb 2000 12:11:49 +0800 Subject: Re: PHP and architecture draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi Markus, There is indeed a discrepancy between the requirements stated in the architecture draft and what actually is available from LDP/RSVP. In fact this issue has been discussed at length in the mailing list, around June 1999. Basically, it is generally felt that the negotiation is not necessary and the implicit null label can be used in the label mapping msg to "implicitly" signal to the peer to pop the label stack. Rgds Kheng Kok --------------------------------------------- Mar Kheng Kok IBM Emerging Technology Centre Tel: 320-1086 (Direct) Fax: 224-5260 Internet: markk@sg.ibm.com Markus Jork on 02/01/2000 01:36:34 AM To: mpls@UU.NET cc: (bcc: Kheng Kok Mar/Singapore/IBM) Subject: PHP and architecture draft I just noticed that the architecture draft (draft-ietf-mpls-arch-06.txt) seems to be somewhat out of sync with reality. The section on penultimate hop popping says: "Initial label distribution protocol negotiations MUST allow each LSR to determine whether its neighboring LSRS are capable of popping the label stack. A LSR MUST NOT request a label distribution peer to pop the label stack unless it is capable of doing so." Looking at the current label distribution protocols (RSVP and LDP), none of them seems to provide the allegedly mandatory feature to figure out whether a peer is capable of doing PHP. So what should we do about this issue: a) agree that I have misread the I-Ds and just ignore my message, b) change the "MUST" in the architecure document to a "SHOULD" c) or just ignore this section of the architecture document? Fixing the signalling protocols to provide the feature seems to be too bothersome. Markus